Jump to content

I had a thought about imaging versus bare metal with WinPE2...


GTOOOOOH

Recommended Posts

Ok, so my problem is time versus consistency. Some people on here use images for OS deployment and they get around HAL issues with XP in various ways. So, let's say I want to go that route and I tackle the HAL issue. Ok... the next real issue for me is image consistency. How can you, or CAN YOU at all keep an image up to date with MS patches, virus dat's, new tweaks/settings, application installations, etc, etc with as little work as slipstreaming?

Ideally I would love to dump an XP WIM on any machine, and have it have the same patch levels virus dat's, etc, etc as a bare metal would have that has been slipstreamed and has post installation tasks attached? I realize I can attach post installation tasks to an image, but what about MS patches, OS tweaks, virus DAT levels INSIDE the image? Any thoughts? Best practices?

Link to comment
Share on other sites


An XP image is an XP image - unlike a Vista WIM, you can't edit it the same way. Again, just as with your other post about this issue, if you need to modify the image regularly after creation, an "image" is definitely not the way to go long-term.

Link to comment
Share on other sites

An XP image is an XP image - unlike a Vista WIM, you can't edit it the same way. Again, just as with your other post about this issue, if you need to modify the image regularly after creation, an "image" is definitely not the way to go long-term.

I know and it's so frustrating, I keep thinking about Vista, and whatever platform MS comes out with next. The fact that you can deploy without HAL issues or having to try and overcome HAL issues is a big time saver in a largely mixed environment, and yet I still won't be able to take advantage of it. I actually had a question about HAL scripts and such. When I look in the registry of a machine that I've booted with WinPE2, you know that key that tells you the HardwareID for the HAL? Every multiprocessor machine I look at, just says acpiapic... so, isn't that wrong? Because in Windows the same machine is listed as an MP_ACPI or something like that?

Link to comment
Share on other sites

Didn't you just post elsewhere that images where a waste of time and you only used UA installs?

That aside. I personally don't worry about it until I have to build a new image. This depends upon the group the image is made for, anywhere from once a year to 3 times a year.

You could have scripts built into your image that would install any updates found in a folder structure on first boot. And either have them available on the network, or copy them to the machine after imaging. If you are using WIM's you could add append this folder to the image and apply it separately to the machine.

Link to comment
Share on other sites

Didn't you just post elsewhere that images where a waste of time and you only used UA installs?

I did post that because of the high security environment I manage and compliancy with several regulatory groups we must maintain certain standards. My point is that I used to use images and because of the new standards we traded time for compliancy, and now that my new method is set, I have some time to explore some hybrid of images/uai. Best of both worlds ya know, speed AND compliancy.

Also, my next step in speed improvement is building individual driver packs for each model computer we have rather then relying on the bloat of the current driverpacks system. I've already done this for several of our models and it's a great time saver to have my scripts in PE read the BIOS through a WMI AutoIT script, then push the specific DP for the machine as well as any manufacturer related items. It's working great and cut out 10-15min from the install.

Edited by GTOOOOOH
Link to comment
Share on other sites

  • 2 weeks later...

Funny... I tell people that I do Unattended installs and they look at me funny. "Really? Why not Images?"

Then I tell them that I support...

49 models of Hardware across 4 Different Manufactures (HP, IBM, VMware, Dell) times 3 different Operating systems... (win2k3-32 bit, win2k3-64 bit, win2k)...

5 different Service Pack versions... (win2k3-sp1 (32 and 64 bit), win2k3-sp2 (32 and 64 bit), win2k-sp4)...

6 different OS versions - win2k3 Standard (32 and 64 bit), win2k3 Enterprise (32 and 64 bit), win2k Standard and Win2k Advanced.

... and follow that up with... Who has time for images?

Oh did I mention that I am the ONLY person in my company that engineers automated Server OS installs?

Actually... In my environment, images are a bottle neck as thay have to be copied to many distribution servers around the globe.

Unattended installs take a bit longer but are much easier to manage and cost alot less in bandwidth.

Why copy gigs of image data when I can just update drivers when necessary (megs or less). The Install Binaries never change.

Once the OS is on... It's all post scripting.

Hotfixes are installed as part of the post scripting piece.

The big win here is that everything is installed ther 1st time... every time. There is no roll back or cleanup of an image.

Clean install everytime. I call this "Tier 1" thinking. Every host is a fresh build whith no margin of error.

Net net... on a newer server... I can get the OS, hotfixes, and baseline Applications (driver support packs, Antivirus, monitoring software, etc...) on a server is about 40 minutes.

The only thing I don't automate is the nic teaming due to the multitude of possible configs we use.

The question was raised about version consistancy...

All applications are packaged (hot fixes too) so I know exactly what is going to be on the box and how it will be configured.

Chris

Link to comment
Share on other sites

Hi,

I totally agree with ChrisBaksa in that sense that there is no problem what so ever to maintain scripted installs (UA) for large numbers of models and manufacturers. The only limit that we are about to hit, is the 4096 char. limit of the OEMPnPDriversPath entry but still, ways around that to.... big drawback is all the hotfixes the way I see it. Yes, all of ours is also automated, but takes to long to deploy them anyway.... it's not such much of a security issue for me, rather time issue since users wants their PC or servers yesterday (test & dev).

Still, for me atleast UA has been the best way to move forward when dealing with XP and 2003. With Vista and 2008, then combination of UA as well with custom made images (I strongly recommend BDD LiteTouch for example) is very powerful, because of the consistency for building the custom image, still getting the benefit of releasing your own custom image to the enterprise getting speed up and highly customized.

The big benefit so far, with our Vista deployment approach, is the separete driver packages, only WinPE needs to contain all the drivers nowadays for NIC and storage, so we dont have to test all models, each time we add new drivers.....

We are running approx 30 models for our laptops/desktops and workstation ~ 54.000 pc's on one single UA image using RIS based on WinXP and SP2

We are running approx 10 models for our servers ~ 4.500 servers on one single UA image using RIS based on Win2003 and SP2

Keep trucking...

Link to comment
Share on other sites

Hi,

I totally agree with ChrisBaksa in that sense that there is no problem what so ever to maintain scripted installs (UA) for large numbers of models and manufacturers. The only limit that we are about to hit, is the 4096 char. limit of the OEMPnPDriversPath entry but still, ways around that to.... big drawback is all the hotfixes the way I see it. Yes, all of ours is also automated, but takes to long to deploy them anyway.... it's not such much of a security issue for me, rather time issue since users wants their PC or servers yesterday (test & dev).

Still, for me atleast UA has been the best way to move forward when dealing with XP and 2003. With Vista and 2008, then combination of UA as well with custom made images (I strongly recommend BDD LiteTouch for example) is very powerful, because of the consistency for building the custom image, still getting the benefit of releasing your own custom image to the enterprise getting speed up and highly customized.

The big benefit so far, with our Vista deployment approach, is the separete driver packages, only WinPE needs to contain all the drivers nowadays for NIC and storage, so we dont have to test all models, each time we add new drivers.....

We are running approx 30 models for our laptops/desktops and workstation ~ 54.000 pc's on one single UA image using RIS based on WinXP and SP2

We are running approx 10 models for our servers ~ 4.500 servers on one single UA image using RIS based on Win2003 and SP2

Keep trucking...

You know you could just slipstream all your hotfixes right?

Link to comment
Share on other sites

You know you could just slipstream all your hotfixes right?

Yup. You could.

However, at our firm all applications and hotfixes are packaged.

All servers get the cummulative hotfix packagee applied. So I really dont need to manage the OS binaries by slipstreaming.

This gets me out of the game of what hotfixes were applied and what was replaced. It's all done in the hotfix package.

Again... a few extra minutes for install... but much less management in the long run. No confusion.

Br4tt3 - You mentioned the PNP path limit.

I got around that. I keep and INI file that has a heading with the model. Each line is a path to the required PNP driver for that model.

I have a script that walks the section of the ini and build the PNP path for that model only (dynamically)

In the same step it Xcopies the folders to the local host before setup is run.

This mean I get only the drivers I need and nothing more in a very controlled fashion.

This works for Unattend as well as Sysprep (images). you just need to reseal when you go the sysprep method.

Example:

[HP DL 360G5]

SSD=Compaq\SSD\7.91

Network=Compaq\Network\Broadcom\NC37xx-380x\3.4.10.0

Network=Compaq\Network\Intel\NC61x-71x\8.9.1.0

Network=Compaq\Network\Broadcom\NC67x-77x\10.39.0.0

Network=Compaq\Network\Intel\NC360T\9.7.38.0

Network=Compaq\Network\Emulex\2.40.a2

Not much in this example as the Product Support Pack (SSD's) do the rest.

Chris

Link to comment
Share on other sites

I got around that. I keep and INI file that has a heading with the model. Each line is a path to the required PNP driver for that model.

I have a script that walks the section of the ini and build the PNP path for that model only (dynamically)

In the same step it Xcopies the folders to the local host before setup is run.

This mean I get only the drivers I need and nothing more in a very controlled fashion.

Wild, I just built something similar, but I used the DriverPacks program/method, heavily customized/rewritten.

Mine reads the BIOS, determines the machine type, based on that, it walks an INI, if it finds a match it ROBOCOPY's the filenames listed in the INI to the typical DriverPacks location I use. The files listed are 7Zip packages I build, and are simply 1 file per driver. So, 1 file is for a modem for that specific model, 1 for audio, 1 for the chipset, etc... then I just let DriverPacks take over and do the rest, works perfectly everytime. The other cool thing, no duplicate drivers, I keep a manifest of what drivers I've already packaged, and if a different model computer uses the same hardware, I just copy/paste that package info from 1 spot in the INI to the corresponding spot.

Works wonders!!

Link to comment
Share on other sites

Wild, I just built something similar, but I used the DriverPacks program/method, heavily customized/rewritten.

Mine reads the BIOS, determines the machine type, based on that, it walks an INI, if it finds a match it ROBOCOPY's the filenames listed in the INI to the typical DriverPacks location I use. The files listed are 7Zip packages I build, and are simply 1 file per driver. So, 1 file is for a modem for that specific model, 1 for audio, 1 for the chipset, etc... then I just let DriverPacks take over and do the rest, works perfectly everytime. The other cool thing, no duplicate drivers, I keep a manifest of what drivers I've already packaged, and if a different model computer uses the same hardware, I just copy/paste that package info from 1 spot in the INI to the corresponding spot.

Works wonders!!

Nice. I would love to see that snipped of code.

The expanded driver layout I use also serves for other applications/processes.

P2V, V2P, Image restores, Image restores to dissimilar hardware.

By having the drivers all expanded, the other apps can detect and use them when they are executed.

Kills 2 birds with one stone.

Chris

Link to comment
Share on other sites

Nice. I would love to see that snipped of code.

It's going to cost you big time!!!! :P

NOTE! - All code is written in AutoIT - !NOTE

Alright, so first thing, since I use DP's I have the typical OEM directory on the root of my install source. I also have an OEM2 that's for MY DP's, and in the sources directory where the boot.wim resides I keep my .ini files. That being said, onto the code...

MODELS.INI - This is the file it checks after reading the BIOS to see if the models/models section matches what it found in the BIOS, if so it reads the model specific section/filename entry for what custom DP files it needs to use rather then the OEM\DP files which are only used if it doesn't find the specific model entry in this file. Get it? Another thing I need to mention, since some of these DP's are actually program installs, I've also packaged them to be unattended as well, so, something like the HP DriveGuard software you'll see below is a scripted app installation. You'll see below from the T61 section that's where I really got granular with packaging the drivers individually as well as apps. From this point forward, that's the way I do all the drivers/apps, singular.

[models]
models=2510p,6710b,8710w,dc7800p,t61

[2510p]
Filename=dpricoh4in1R5C83x84x.7z,dpricoh4in1R5C83x84x.ini,dphplaptops.7z,dphpdriveguard.7z,dphpdrive
guard.ini,dphpfingerprintreader.7z,dphpfingerprintreader.ini,dphpprotecttools.7z,dphpprotecttools.in
i
,dphpquicklaunch.7z,dphpquicklaunch.ini

[6710b]
Filename=dphplaptops.7z,dphpdriveguard.7z,dphpdriveguard.ini,dphpfingerprintreader.7z,dphpfingerprin
treader.ini,dphpprotecttools.7z,dphpprotecttools.ini,dphpquicklaunch.7z,dphpquicklaunch.ini,dpricoh4
i
n1R5C83x84x.7z,dpricoh4in1R5C83x84x.ini

[8710w]
Filename=dphplaptops.7z,dphpdriveguard.7z,dphpdriveguard.ini,dphpfingerprintreader.7z,dphpfingerprin
treader.ini,dphpprotecttools.7z,dphpprotecttools.ini,dphpquicklaunch.7z,dphpquicklaunch.ini,dpricoh4
i
n1R5C83x84x.7z,dpricoh4in1R5C83x84x.ini

[dc7800p]
Filename=dphpdesktops.7z,dphplightscribe.7z,dphplightscribe.ini,dphpprotecttools.7z,dphpprotecttools
.ini

[t61]
Filename=dpibmatmeltpm.7z,dpibmACPIPowerManagement.7z,dpibmACPIPowerManagement.ini,dpibmActiveProtec
tionSystem.7z,dpibmActiveProtectionSystem.ini,dpibmFingerPrintReader.7z,dpibmFingerPrintReader.ini,d
p
ibmaccessconnections.7z,dpibmaccessconnections.ini,dpibmmodem.7z,dpibmPowerManager.7z,dpibmPowerMana
g
er.ini,dpibmTX61SoundMaxAudio.7z,dpibmTX61SoundMaxAudio.ini,dpibmBlueTooth.7z,dpibmBlueTooth.ini,dpI
n
telGM965chipset.7z,dpIntelGM965chipset.ini,dpIntelPro1000a.7z,dpricoh4in1R5C83x84x.7z,dpricoh4in1R5C
8
3x84x.ini,dpSecureDigital6040501.7z,dpibmSmartCard.7z,dpNvidia614115666.7z,dpIntelVideo1.7z,dpIntelP
r
oWiFi1.7z,dpUltraNav751725.7z,dpUltraNav751725.ini,dpibmUltraNavUtility.7z,dpibmUltraNavUtility.ini,
d
pDisableTurboMemory.7z,dpIntelVideo2.7z

NEXT!!!!! I'll show you the BIOS capture coding that reads the BIOS, then does everything I mentioned above, parsing the INI copying the necessary files, and then building a customized manifest.ini for that model based on what was read from the first ini file. It does this for any INI files MENTIONED in the model specific section, I do that because in those INI files I put the command-line switches for the applications specific packages, since most of them are InstallShield packages it's setup.exe /S /v/qn.

Func Model()

$wbemFlagReturnImmediately = 0x10
$wbemFlagForwardOnly = 0x20
$colItems = ""

$objWMIService = ObjGet("winmgmts:\\localhost\root\CIMV2")
$colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystemProduct", "WQL", _
$wbemFlagReturnImmediately + $wbemFlagForwardOnly)

For $objItem In $colItems
$biosinfo[0] = $objItem.Vendor; =====================================================MANUFACTURER, ALWAYS AVAILABLE===================================================================
$biosinfo[1] = $objItem.Name
$biosinfo[2]= $objItem.Version
Next

If $biosinfo[0] <> "Lenovo" And $biosinfo[0] <> "IBM" Then $biosinfo[2] = $biosinfo[1]

For $m = 1 To $allmodels[0]
$model = StringInStr($biosinfo[2], $allmodels[$m])

If $model <> 0 Then
$foundit = "1"
ExitLoop
EndIf
Next

If $foundit = "1" Then

$filename = IniRead($path & "\sources\models.ini", $allmodels[$m], "Filename","")
RunWait(@COMSPEC & " /c x:\windows\system32\robocopy y:\oem\bin c:\temp\oem\bin /e /z", "x:\windows\system32")
FileCopy("y:\oem\ATICCC.ins", "c:\temp\oem\ATICCC.ins", 9)
FileCopy("y:\oem\DPM711.7z", "c:\temp\oem\DPM711.7z", 9)

$filename = StringSplit($filename, ",")
$inicounter = 1

For $filecount = 1 To $filename[0]
FileCopy("y:\oem2\" & $filename[$filecount], "c:\temp\oem\" & $filename[$filecount], 9)
$inifile = StringInStr($filename[$filecount], ".ini")
If $inifile <> 0 Then
IniWrite("c:\temp\manifest.ini", "inis", $inicounter, $filename[$filecount])
$inicounter = $inicounter+1
EndIf
Next

Else; ======================================================================GENERAL DRIVER PACK USED, MODEL NOT SPECIFIC========================================================================================
RunWait(@COMSPEC & " /c x:\windows\system32\robocopy y:\oem c:\temp\oem /e /z", "x:\windows\system32")
EndIf

;WriteMif()
Return

EndFunc

This last piece of code is run on XP's first boot where it automatically logs in as the Administrator account, and after the DP cleanup runs. This checks for the manifest.ini, and if it exists, it knows that packaged apps have to be installed.

If FileExists("c:\temp\manifest.ini") Then
$CountLines = _FileCountLines("c:\temp\manifest.ini")
$CountLines = $CountLines-1
For $iniloop = 1 To $CountLines
$inis = INIRead("c:\temp\manifest.ini", "inis", $iniloop,"")
$ininame = StringTrimRight($inis, 4)
$CountLines2 = _FileCountLines("c:\temp\oem\" & $inis)
$CountLines2 = $CountLines2-1
For $installloop = 1 To $CountLines2
$installfile = INIRead("c:\temp\oem\" & $inis, "installs", $installloop,"")
$msifile = StringInStr($installfile, ".msi")
If $msifile <> 0 Then
RunWait(@ComSpec & " /c C:\WINDOWS\system32\msiexec /i c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop & "\" & $installfile, "c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop, @SW_HIDE)
Else
RunWait(@ComSpec & " /c c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop & "\" & $installfile, "c:\windows\system32\elcishd\drvrs\d\d\" & $ininame & "\" & $installloop, @SW_HIDE)
EndIf
Next
Next
EndIf

That's it, looking at the system it's simple as all hell, but as you know, getting simple is the hardest thing to do.

Link to comment
Share on other sites

We have done something similar.

The first feture we use is that winpe can read a pqi image directly after image load. no need for reboot

The second feture is vbscript and the wmi provider.

Our installer uses wmi to detect vendor and modell. It loads the image to the disk. Then it uses the information about the machine to copy

\\server\drivershare\vendor\model\driver.cab to c:\install\drivers and finaly extract the cab.

Downside is that we have to create the cabs. On the other hand we only have one path for each type of driver in sysprep regardelss of how many types we support.

To make the image creation easier we use a four step method.

1. install os + service pack. Only changes when we aply a new SP

2. install apps and patches. Changes often, Scripted generation

3. Gui config. Changes rarly, manual config

4. Defrag and sysprep. No changes, Scripted.

To change an app in the clone takes a few hours. Currently we are working on implementing release windows for our clones to make it easier for the apps people to plan their relases and changes

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...