Fencer128

I fail to see how anyone has determined that the server kernel is more "optimised/better" than the xp kernel. Does anyone actually know what the kernel differences between 5.1 and 5.2 are? Failing that, what the kernel is defined as? I suspect that comparing XP kernel features of 5.1 with those of server's 5.2 will show minimum differences in shared abilities. Most of the differences will probably involve server type operations that fall outside the remit of XP or a client OS. Apart from the fact the server is more secure out of the box than xp, and has the ability to run as a server os with many server-side services (the obvious) - I see no real difference between server and xp at all. As for vista - maybe I'm wrong but I thought it was mostly new code? - no legacy kernel code from server brought into Vista. From this perspective I find it difficult to understand why so many people think server 2003 is "better" than XP for client duties? It seems it's assumed just because server's kernel has a 0.1 increment version number over XP's. How can you compare chalk and cheese when you're a mouse? Cheers, Andy EDIT: IMHO this is such an ambiguous poll that I acually feel guilty for bumping it

Hi, I'm a little confused as to what disk has the active primary partition on it - anyhow I believe your problem is that the NTFS bootloader has been referenced via the MBR of the active primary partition. To remove the OS choice screen you'll need to "reset" the MBR. Now, I'm not sure what the best move is for you from this point forward. ** Don't try anything until you are sure you know what you are doing as it could make your system unbootable! ** It could be something as simple as using a DOS boot disk and typing FDISK /MBR. It could also be a case of using the recovery console and FIXMBR. I really don't know as I've never had to do it myself. I would do a little research on these options. Good luck, Andy

Hi, Does the HAL type of the client you're PXE booting from match the HAL type of the machine you created the RIPREP image on? http://support.microsoft.com/?kbid=309283 Good luck, Andy

Hi, I see your point. The problem we have is that we pay for a supposed quality of support that we rarely receive from them. Our job description does not involve fixing the hardware directly (too many boxes and too few staff - that's why we purchase extended on-site warranties). Dell just can't meet that level of service. Our current supplier can. I would possibly buy Dell for my home, as I can fix it myself if it goes wrong - but as the numbers scale it becomes a different proposition. Cheers, Andy

Hi, Please check out the tutorial that I linked! Failing that have a look in the README file in the DriverPack Base folder. It has a link to "Installation Instructions". It does not say to extract the DriverPacks. You should not do this and it is almost certainly the cause of your problem. Andy

That is correct. No it is not normal. I use method 2 (I don't use the other methods). If you try method 2 and you still have an empty DPFiles folder then you are doing something wrong. In this case follow the instructions in the tutorial exactly (linked in my previous post). Good luck, Andy

Hi, You don't give too much detail in your first post - so I'm going to go from the start. Once you have extracted the DP Base package, be sure to pace the driver packs that you want included in your build into the "DriverPacks" directory. Now run the slipstreamer, as you did previously. If you now check the UWXPCD_ROOT folder you should find everything in order. I don't see what you are trying to show with BTS_DPs_finish.cmd or the output from run_me.cmd - they look fine and there are no errors. Good luck, Andy BTW - There is a tutorial on how to do all of this: http://www.uawiki.org/doku.php?id=wxp:ua:d...rpacks:tutorial You can get to it by checking out the sticked "BTS DriverPacks Related Articles" post at the top of the main forum...

Hi, I would imagine that you will need a "flat" image, as opposed to a binary ghost image. Something like using RIS and RISETUP for example. The ghost image you have already has drivers installed for the system on which you built it. Moving to different hardware will confuse the OS as all of a sudden many of the drivers are incorrect. Also, BTS driver packs only work during the installation of the OS. Even though you can choose to "keep the drivers" for after the installation, Windows will not search these by default and so hardware using these will not be detected IIRC. Good luck, Andy

Hi, I think BTS has put together the packs with Win XP in mind. You mention Win 2k. Maybe that's part of the problem? Cheers, Andy

Hi, Thanks for the info, but please see this thread stickied at the top of the main forum: http://www.msfn.org/board/index.php?showtopic=61474 BTS will be more likely to pick up on the driver if you follow his rules. Cheers, Andy

Hi, Just to be certain, you should place the $OEM$ folder at the same level as the i386 folder. The last time I checked (a couple of days ago) the documentation was agreeing on this: http://support.microsoft.com/default.aspx?...kb;en-us;314479 See the section under "RIS Installations". I do not use an OEMFilesPath key, I just used to use OEMPnPDriversPath. I use RIS every day and always have $OEME$ alongside i386. Doesn't work otherwise. Yes - it is confusing! Good luck, Andy

Hi, Haven't used RIPREP images in a long time, but as far as I recall - you are correct. You need a RISETUP file set on the RIS server to use RIPREP images. It is most likely because of the interaction between the RIS and the groveller services. I expect it is to save space, as you suggest. Cheers, Andy

Hi, That sounds like you haven't disabled driver signing in the sif file, or you have a damaged installation source. You should not have this issue if you installed BTS packs correctly. Good luck, Andy

@salating I don't think they are purposely chosen to work with Windows 2000 - though I expect many will. Only option is to try it and see. I f you have problems then try removing drivers you definitely don't use and go from there. Good luck, Andy

Why not extract it from your CD? Andy

Hi, We sort of do that here, though I'm not involved with the Ghost aspect at all. I do know that RIS itself does not actually distribute the image to the PCs. RIS is used here to launch Ghost (via the Tools menu), which then allows Ghost to distribute the image to the box. RIS does not handle multicasting either as far as I'm aware (which is why we have a use for Ghost). RISETUP only used to create flat RIS images. It is of no use if you use Ghost. Cheers, Andy p.s. This would have been better placed in the Unattended RIS Installation sub-forum...

Hi, Just in case - you should make sure that your $OEM$ folder is alongside the i386 folder, and not within it. Cheers, Andy

Hi, Have you thought of setting the %MACHINENAME% variable through the RIS menu, and then doing a domain join via your SIF ile? This would negate your Welcome screen problem and remove a reboot too. Andy

What signature issue? Andy

Hi, There is a tutorial on creating your own driver packs here: http://www.uawiki.org/doku.php?id=wxp:ua:d...rpacks:overview Good luck, Andy

Hi, Are you sure portcls.sys isn't copied anywhere? If you're using the BTS packs then I would expect you to find it in: C:\Windows\System32\Drivers\ Please can you confirm? Thanks, Andy EDIT: This is slightly worrying. Please can you tell me if you're using a plain Windows XP SP2 CD? If you've done any other modifications before applying BTS driver packs then please state. Thanks.

Hi, I'm not quite sure what you mean? Which driver packs are you using? This will obviously greatly effect the length of OEMPnPDriversPath. The max length limit for a registry entry is 1023 characters for win2k (if memory serves). As such, you may still run into this limitation with ristndrd.sif. The limit is 4096 for xp. Please supply more info. Cheers, Andy

For a CD install this is correct, but for a network install the $oem$ dir should be inside the i386 dir. The OemFilesPath statement should point to the root of the i386 dir in your distribution share. Without this statement, the $oem$ dir and all subdirs will be ignored. The driver dir should in fact be in the \$oem$\$1 dir. Regards Yep - I forgot. $1 it is. However, for a RIS install the $OEM$ folder should be alongside the i386 folder NOT inside it. Check out http://www.windowsitpro.com/Windows/Articl...0280/20280.html for verification of this. For a network (non-RIS) install - whatever that is - then the $OEM$ should be placed within i386, apparently. Never had a chance to try this so don't know if it's correct. I haven't created any special path entries in any sif file so I don't think I'm doing anything out of the ordinary. Andy

Hi, I would move the "Drivers" folder into $OEM$. That will work. Make sure $OEM$ is at the same level as i386 - not inside it. MS documentation is wrong in this account as it tells you to place $OEM$ inside i386. This is incorrect. $OEM$ should be alongside i386. Good luck, Andy

Yep, I get that too. I run a seperate batch file straight after BTS_cleanup has completed. It deletes the D folder again. This time it is successful... Cheers, Andy