jmmdss

I was able to get WinPE 2.1 (included in the newly released Windows AIK) working recently with MS TFTP + pxelinux. One problem I found is that I had to add bootmgr.exe to the tftproot (I was having problems and found Robin's comment on this page). Otherwise, I basically just followed the MS documentation (I skipped the debug section) here: http://technet2.microsoft.com/WindowsVista...3.mspx?mfr=true I don't know if it matters, but the following commands I made Boot start with an uppercase letter: Bcdedit –store c:\BCD –set {ramdiskoptions} ramdisksdidevice Boot Bcdedit –store c:\BCD –set {ramdiskoptions} ramdisksdipath \Boot\boot.sdi Also, I don't think this matters either, but I added a Fonts folder inside Boot and put wgl4_boot.ttf in it. I renamed pxeboot.n12 to pxeboot.0. Here's the relevant part of my pxelinux.cfg\default file: DEFAULT vesamenu.c32 PROMPT 0 # Boot WinPE 2.1 LABEL WinPE KERNEL Boot/pxeboot.0

Actually, I don't think that it would work under HKLM, but I haven't tried it. You could always give it a shot I guess. However, if you modify the Default User profile, it should apply to all newly-created profiles on the machine. I use images rather than unattended installs, but it seems like you should be able to run a vbscript similar to the one below to modify the profile: Set oShell = Wscript.CreateObject("Wscript.Shell") Set oFSO = Wscript.CreateObject("Scripting.FileSystemObject") enableLogoff Function enableLogoff On Error Resume Next defaultUserDat = "C:\Documents and Settings\Default User\ntuser.dat" regPath = oShell.ExpandEnvironmentStrings("%windir%") & "\system32\reg.exe" If oFSO.FileExists(regPath) And oFSO.FileExists(defaultUserDat) Then tempHive = "HKEY_USERS\def" command = regPath & " load " & tempHive & " """ & defaultUserDat & """" oShell.Run command, 0, TRUE tempLogoffPath = tempHive & "\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\StartMenuLogoff" oShell.RegWrite tempLogoffPath, 1, "REG_DWORD" command = regPath & " unload " & tempHive oShell.Run command, 0, TRUE End If End Function

Well, you could configure the setting in a domain GPO, since it looks like you're in a domain environment. Otherwise, you may want to try setting the following value in the Default User profile. [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] "StartMenuLogoff"=dword:00000001

h0dg3s, One possible way to do this would be with Group Policy. In my initial tests it seems to work. Start > Run > gpedit.msc User Configuration > Administrative Templates > Start Menu and Taskbar Set Add Logoff to the Start Menu to Enabled and make sure Remove Logoff on the Start Menu is "Not configured"

Thanks for the suggestions! Well now I feel really stupid. I'm using VMWare Server remotely, so I haven't had a chance to test on actual hardware. If I shut down the virtual machine right after mini-setup completes and then power it on (without allowing it to do a "soft" reset), the image boots normally the first time. I'm starting to think this may just be a VMWare bug... though I'm not sure how. I've always used it to build/test my images. I'll have to try on a real box to know for sure.

Edit: It seems like my issue was a VMWare Server bug, as when I had a chance to try it on a real box, the problem did not occur. Thanks again to those who assisted. ------------------- I've prepared a master image with the following HAL: Advanced Configuration and Power Interface (ACPI) PC - ACPIPIC_UP Then, on the target machine, I boot into WinPE, pull down the image, and modify sysprep.inf to use the appropriate HAL. I reboot, sysprep completes the mini-setup wizard and initiates another restart. The system fails to boot the OS at this point... however, if I physically reset at this point, it comes up with "Windows Failed to Start Something Something..." I select Boot Normally and the system boots fine. I log in and see that the correct HAL is being used. So for some reason the first time it boots after mini-setup completes, it is failing. The next and subsequent times it boots fine. Has anyone seen this before? If I take out the HAL update lines (UpdateUPHAL or UpdateHAL) this doesn't happen, so it must be due to the HAL replacement. It also does not seem to happen when the master image is a ACPI Multiprocessor HAL and I change to ACPI Uniprocessor HAL. Any ideas? Also, I'm using the -pnp switch when I run sysprep if that matters. Thanks for any help or ideas!

Thanks for the post. That didn't seem to do the trick for this particular issue. For some reason I had to use -pnp switch with sysprep.exe, even though the video drivers should be PNP... Anyway, it only adds about 1.5 to 2 minutes to deploy time, unlike the 5-10 stated in the MS docs, so I'm happy with this solution. Oh, I also tried UpdateInstalledDrivers in sysprep.inf, which didn't work in case anyone else has a similar issue. By the way, it seems like I was wrong thinking that DevicePath and OemPnpDriversPath did different things. It appears that sysprep simply populates DevicePath based on what you have in OemPnpDriversPath when it runs.

I think that $oem$ should be on the same level as i386 for flat images. It's been awhile since I used RIS though. If you use a riprep image, I don't know the preferred way to do this, but in the past, I've just put the Drivers folder inside Setup\English\Images\<Image name>\i386\Mirror1\UserData\.

So the driver folders (ex. C:\Drivers\000_chipset) exist on the machine after imaging? Your OemPnpDriversPath looks okay to me. I haven't used quotes around the value, but I doubt it would make a difference. One person said they had problems with OemPnpDriversPath with RIS and used the DevicePath string in the registry instead. [HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath] With your folders, the value of DevicePath should be: %SystemRoot%\inf;%systemdrive%\Drivers\000_chipset;%systemdrive%\Drivers\001_network;%systemdrive%\Drivers\002_graphics;%systemdrive%\Drivers\003_audio;%systemdrive%\Drivers\004_SATA In fact, you should have these paths in the registry value after imaging as a result of OemPnpDriversPath. If you don't, that might explain why the drivers aren't installing.

I was working on an issue today where a syspreped image would find new hardware during every startup and prompt me to reboot to complete installation. No unknown devices were listed in Device Manager. I was using the DevicePath registry value (instead of OemPnpDriverPaths in sysprep.inf) to specify driver paths. I eventually found out the drivers not being installed were intel 945g video drivers. What's weird is I have an unattended CD with the same exact drivers, and it works fine. The only difference is I'm using OemPnpDriversPath in winnt.sif to specify the driver locations. For some reason, I thought both methods were equivalent and that the answer file simply updated DevicePath. Does anyone know what the difference is between these methods? I've heard people say DevicePath was better.