Jump to content

Noise

Member
  • Posts

    419
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Noise

  1. It would be a smart move by Microsoft. On a personal level I hope so because that means that v/n-lite support will move off of these boards and that would make me extremely happy. It would mean decreased traffic to msfn.org, which translates to less ad revenue. That said, if n-lite support drops from this board I will definitely step up to help support msfn.
  2. Have you tried unregistering the DLL? regsvr32 /u sfc_os.dll Not sure if it will work, but it's worth a try.
  3. RegShot and Process Monitor (RegMon) are the tools you need. http://sourceforge.net/projects/regshot/ http://technet.microsoft.com/en-us/sysinte...s/bb896645.aspx
  4. Thanks for the info Cluberti. I'm intimately familiar with PXE booting and WIM images, so I guess I'm half-way there. A couple questions though... How are drivers integrated (Updated NVidia Drivers, IntelINF, etc)? Do we peimg /inf or something similar? How is the default user profile modified like at T-12 in unattended installations?
  5. I've deployed literally over a hundred thousand WinNT/2k/XP/2003 systems using scripted deployments and they all worked perfectly. The same deployment works for Intel/Amd CPU's - Nvidia/AMD/Intel chipsets. As long as the drivers were in the OemPnPDriversPath. Using scripted deployments you can also easily modify the Default User profile. Sure, scripting a deployment is a pain compared to imaging - but the rock-solid, efficient Windows installation you get is worth the effort. I've been an adamant hater of using images for Windows deployments since 1994. Now, I haven't had to do a Vista/2008/Win7 deployment yet. Is it true that you can ONLY deploy using imaging? Is there no scripted solution like in Windows 2003 and earlier? I can't imagine that Microsoft would screw up that bad... well, yes I can imagine that - but I hope it isn't true.
  6. You'll need to use the SpyBlast.inf that's included with the package to do the install. Here is the command: rundll32 setupapi,InstallHinfSection DefaultInstall 128 .\SpyBlast.infYou'll need to figure out how to code this so it get's in to the RunOnce registry area. It shouldn't be too hard.
  7. You sir, either have a Virus or adware installed on your system. Please take appropriate action to scan your system for Malware.
  8. I'm pretty sure you can't. You might want to try installing from a USB Flash Drive, they're faster and more easily modified.
  9. Remember that %BCDFILE% is a variable (forgive me if you already understand this, just covering the bases here). You need to define it in the batch file. Take the above code I posted, paste it in to notepad, add the following line to the beginning of the file: SET BCDFILE=C:\TEMP\BCD Then save the whole thing as "MAKEBCD.CMD". Change the patch to a working directory if you want, but keep the filename BCD with no extension (and dont put it in the root of drive C: - you'll screw up your system). And remember, you need to run these commands using the special command prompt that got installed when you installed the WAIK (it's in the start menu, I forgot exactly what they called it). There's a ton of information about this in the WAIK documentation.
  10. The WIM's go in to the \Boot directory. As defined by: Bcdedit /store "%BCDFILE%" /set %guid1% device ramdisk=[boot]\Boot\winpe_x86.wim The for /f "tokens=1-3" line is meant for a Batch file. If you run that command manually you have to replace %%a with %a and %%c with %c. The double percent signs are necessary when you run the command in a cmd/bat file.
  11. echo *** Creating WinPE BCD (boot configuration data) File Bcdedit /createstore "%BCDFILE%" Bcdedit /store "%BCDFILE%" /create {ramdiskoptions} /d "Ramdisk options" Bcdedit /store "%BCDFILE%" /set {ramdiskoptions} ramdisksdidevice boot Bcdedit /store "%BCDFILE%" /set {ramdiskoptions} ramdisksdipath \boot\boot.sdi rem 32Bit for /f "tokens=1-3" %%a in ('Bcdedit /store "%BCDFILE%" /create /d "Windows 32 Bit" /application osloader') do set guid1=%%c Bcdedit /store "%BCDFILE%" /set %guid1% systemroot \Windows Bcdedit /store "%BCDFILE%" /set %guid1% detecthal Yes Bcdedit /store "%BCDFILE%" /set %guid1% winpe Yes Bcdedit /store "%BCDFILE%" /set %guid1% description "Windows 32 Bit" Bcdedit /store "%BCDFILE%" /set %guid1% osdevice ramdisk=[boot]\Boot\winpe_x86.wim,{ramdiskoptions} Bcdedit /store "%BCDFILE%" /set %guid1% device ramdisk=[boot]\Boot\winpe_x86.wim,{ramdiskoptions} rem 64Bit for /f "tokens=1-3" %%a in ('Bcdedit /store "%BCDFILE%" /create /d "Windows 64 Bit" /application osloader') do set guid2=%%c Bcdedit /store "%BCDFILE%" /set %guid2% systemroot \Windows Bcdedit /store "%BCDFILE%" /set %guid2% detecthal Yes Bcdedit /store "%BCDFILE%" /set %guid2% winpe Yes Bcdedit /store "%BCDFILE%" /set %guid2% description "Windows 64 Bit" Bcdedit /store "%BCDFILE%" /set %guid2% loadoptions ramdisk=[boot]\Boot\winpe_x64.wim,\"DISABLE_INTEGRITY_CHECKS" Bcdedit /store "%BCDFILE%" /set %guid2% osdevice ramdisk=[boot]\Boot\winpe_x64.wim,{ramdiskoptions} Bcdedit /store "%BCDFILE%" /set %guid2% device ramdisk=[boot]\Boot\winpe_x64.wim,{ramdiskoptions} rem Setup Bootmanager Bcdedit /store "%BCDFILE%" /create {bootmgr} /d "Windows VISTA BootManager" Bcdedit /store "%BCDFILE%" /set {bootmgr} timeout 10 Bcdedit /store "%BCDFILE%" /set {bootmgr} displayorder %guid1% %guid2% Bcdedit /store "%BCDFILE%" /enum all
  12. http://www.microsoft.com/downloads/details...;displaylang=en Get the Waik. Read. Pray.
  13. You can do it but it's pretty difficult. You need to have the two versions of Windows PE in WIM files, then specify them using BCDEdit. I've done this before so I could boot either the 64 bit or 32 bit version of WinPE 2.1 off the same disk (with a 10 second timeout defaulting to the 32 bit).
  14. You could probably do it with an autoit script. It might be "glitchy" until you work out the bugs, but it will work. Also you might be able to make a custom ADM file for this, so the settings are provided by Active Directory Group Policies.
  15. Oh man, I know exactly what you are going through! A couple months ago I had to deploy 68 of these DL380 G5's and ran in to the same problem. The problem is that those On-Board Broadcom NIC's aren't PnP devices - they are tied to a virtual bus created by the drivers. You need to use a program called NetSet03 from Microsoft. You are in for about two days of hacking to get this working. You can read more about it here. By the way, WinPE isn't alone with this, you will have the same issues with Server 2003 - Pot assignment is completely random. I never did figure out how it was assigning ports, but I suspect it was the first port to receive a DHCP request was the first to be assigned. This drove me nuts for days. I even tried to use the CONREP.EXE hardware configuration utility from HP to hard-code the NIC's in WinPE (it doesn't help). Good luck.
  16. Well, you need to decompress that setup.exe and get to the .sys and .inf files inside it. I use UniExtract for this type of job - it usually figures it out. Just right-click setup.exe and Uniextract to a subdirectory. WinRar might be able to do it too - check by right-clicking setup.exe and checking if WinRar can extract it. Also, you're using your OemPnPDriversPath setting wrong. The OemPnPDriversPath setting is relative to your $OEM$ directory.
  17. Seriously Kingsc, I'm not trying to be a jerk here - you are going about this the wrong way. Direct editing of the default user hive is a BAD THING. You may hack it enough to get it where you think it will work, but later on you will find you have a very buggy Windows installation. Things like certificate stores and network authentication will break, all kinds of bad things happen - they just may not happen right away. When you join a domain the default registry hive will be in the NETLOGON share. The default user registry hive is probably one of the most complex things in windows, it's not as simple as you may think. If you don't do a scripted installation then you should research group policies and create custom ADM files. Or make a logon script that simply loads HKCU entries when people logon. But directly messing around with the ntuser.dat file IS NOT the way to do what you want.
  18. [Version] Signature = "$Windows NT$" [DefaultInstall] AddReg = REGEntries.AddReg [REGEntries.AddReg] HKLM,%RunOnce% HKLM,%RunOnce%,"MyEntry",,"MyFile.bat" [Strings] RunOnce="SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
  19. The batch file needs to go in to %SystemRoot%\System32 if you don't want to specify a path.
  20. You are asking for a world of hurt by trying to manually mess with the default user hive. The only way to properly do what you want is through a scripted installation, setting the registry at T-12. The default user hive contains unique placeholders for SIDS, and other registry setting that get populated when a new user logs on. It also contains registry ACL's that won't transfer to another account properly if you use a hive from another user. This is why good administrators don't deploy XP with images.
  21. Click Start, Selct Run, Type the following: ECHO 192.168.1.100 ADC1 #PRE #DOM:MYDOMAIN > %SystemRoot%\System32\Drivers\etc\LMHOSTS Replace the IP Address with the actual IP Address of your server you ant to authenticate to. Replace ADC1 with the actual name of that server. Replace MYDOMAIN with the name of your domain.
  22. You probably have a subnet mask of 255.255.252.0. To answer your question your next IP Address would be 10.0.0.255.
  23. The fact is, that up until Vista - no professionally done windows deployment should be done with images. You're not "fighting the past" - you dealing with valuable lessons learned. And it sounds like the policy makers where you work know what they're doing. Just because you think you know how to do images properly on XP/2003 doesn't mean that is the best way to install those OS's. Speaking from literally 10,000 Windows installations here; scripted deployments are far more stable and have better performance than imaged installations.
  24. No, it won't work that on XP. The pointers in boot.ini will be all wrong. Install XP in SATA mode (no legacy emulation) but update your installation source first. Use this as a guide.
  25. I dont use Metzen's approach because it just adds another step of complexity. And I like being able to slipstream hotfixes in to my source. In reality I don't care about the extra 5 minutes it would save. Once an install is started I'm off to the liquor store anyhow. When I get back the install is done. 20 minutes, 35 minutes, either way I end up with a beer.
×
×
  • Create New...