Jump to content

jmmdss

Member
  • Content Count

    10
  • Joined

  • Last visited

  • Donations

    $0.00 

Community Reputation

0 Neutral

About jmmdss

  1. 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 {r
  2. 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\
  3. 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
  4. 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"
  5. 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.
  6. 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
  7. 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 ba
  8. 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\.
  9. 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;%
  10. 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 so
×
×
  • Create New...