Image vs Unattended | Pro's and Con's

[WannaXP]

I'm responsible for the unattended installs at my medium to large company that has 10,000 workstations and laptops. I've used Ghost in the past and I'll say I don't necessarily have a favorite. I'm with schalti in that I feel they both have their shortcomings.

M$ should FINALLY update their setupapi.dll such as it scans subdirectories. Integrating a large number of drivers has been a terrible mess since first version of Windows 2000. For 5 years now M$ was unable to add this feature...

oempnpdriverspath=<dir1>;<dir2>;<dir3>......

---> oempnpdriverspath=<dir1>

AMEN to that!!!

Fero

[wamatt]

If its for one PC or two PC's imaging is superior:

Also I have a method to move an image to ANY hardware using a combination of slipstream and imaging. Hal etc can different completely.

1. Install fresh slipstream on new machine

2. Load WinPE/"Any recovery cd" and copy /windows/system32/drivers folder and the HKLM/System/CurrentControlSet/Enum reg key to another HD/partition/usb drive etc.

3. Restore image from old machine onto new.

4. Boot WinPE/"Recovery cd" copy back drivers and reg key

5. Reboot

Compare the time for this (30 minutes) to days/weeks preparing unattented. For personal use unattended is NOT the way to go.

[pianoman]

piano man we are saying that if you have more than one machine and they don't have exactly the same hardware then you can't use that zip file for both machines.

Why not? So long as the HAL does not change, I use the same image. Working on how to handle that. SysPrep with -pnp drives a full PNP process, and I place the correct drivers for that machine in dirs specified in OemPnpDriverPath.

I doubt there is anything which can be done with a scripted install than an image install can no deliver, but it does require thinking outside of the box. (Not saying one does not modify the install of the origional image - like to get rid of bundled software)

PNP can be your friend...

Ya'll have fun with your scripting, I'll stick to building imaging technologies. Don't stop scripting... M$ keeps adding more stuff to the install that I don't want in the image! so I can learn from ya'll.

PianoMan

[Raja]

This reply is in specific for Cableguy and all those who are involved in developing SOE’s for medium to large organizations.

I have been designing and developing SOE's for corporate environment for 5 years and am convinced that both imaging and unattended have their strengths, so the best option in my experience is to use both.

Imaging results in quicker deployment times but is a maintenance nightmare for an SOE engineer. Unattended build process on contrary is easy to scale and maintain but deployment times are much longer in comparison to Imaging. From business point of view time is money hence the preference is always for imaging. This point can be successfully argued by those in favour of Unattended process, as the time in question is unattended time which means, once started, the process runs on its own without any intervention hence the dollar value is same for both the processes. Unfortunately Businesses/Management generally get billed for the total build time than being billed for only the time the technician has spent in actually triggering the unattended process and as a result Imaging is favourite with them as with in less than 10 minutes the pc is ready for deployment at much smaller a cost than that of unattended process.

Unattended process is best suited for corporate needs where a customised build process is needed to cater for different hardware platforms, or any other variables that are to be set so as to get different resulting image. As for an example, your organization may have 3000 computers (different hardware models from different manufacturers) installed across different regions, business divisions needing different configuration or applications. For such a diverse setup Unattended build process is the way to go but having said that the time required getting the task completed (even if it is unattended task) is on average 5-6 times more than a combination of Sysprep/ghost.

Imaging is ideally suited where hardware models are identical, set of needed applications is the same, and one set of customisation is applied across all computers. This works well in training and educational institutions if hardware models are the same. Having said that I would still use unattended process for development of the SOE for its benefit and use imaging only for deployment in such an environment.

Now to conclude, I have always used the unattended process for development of SOE’s and for deployment depending on the scenario I will either continue to use Unattended or convert the unattended solution into an imaging solution by flick of a switch.

I hope this information is enough to set your imagination running as far as you want it to and see how all this could be accomplished. OR feel free to ask any questions. I am not a regular visitor to the forum so may not be able to reply straight away. You can MSN me at (rajakohli at hotmail dot com) or write to (rkohli at energy dot com dot au)

Cheers

Raja

[dlevens]

Raja, we meet again.

Just to add to this discussion I agree that both combined can be very powerful.

IMAGING

-----------

I started out with this process for a large company and have discovered many of the problems with HAL and drivers can be overcome. After many hours of trial and error this seems to be the most successful when:

1. You build your master image on a box that installs using HAL ACPI Uniprocessor PC

2. Then change that HAL in device manager to Advanced Configuration and Power Interface (ACPI) PC

3. Then Sysprep

Doing this solves the HAL problems between old systems, new systems, laptops and even hyperthreading cpu. This is because the Advanced Configuration and Power Interface (ACPI) PC HAL works on all hardware. Once you deploy your image via ghost to a new box that would normal use the uni or multi hal all you do in XP is go to device manager and rollback driver on the HAL and reboot. You do the exact same process on hyperthreading boxes but you have to reboot twice. First reboot puts you on uni hal second reboot puts you to multi hal.

If you build your master image in fat32 you can even open the image with ghost explorer and replace the 3 HAL files to be anything you want if you want but note that if it is anything but Advanced Configuration and Power Interface (ACPI) PC then you have to be careful where you deploy it to. laptops will not boot if you chave the hal to uni or multi. And multi hals will not work on uni.

I am still tweaking the process but need to find a way to format using oformat and convert to ntfs as cleanly as possible. Since I use sysprep I cannot use the unattended FileSystem = ConvertNTFS since that is not valid for sysprep. I am still trying to solve this as I need fat32 to be able to open my image in ghost explorer and add and remove files without having to ghost the ram image to my test box then delete or add files and then sysprep all over again. Keeping my images fat32 and then converting allows me to add drivers or files by opening the image up in ghost explorer and making the changes direct.

This process allows one image to work on all hardware using imaging as a solution. For drivers I recommend keeping windows 2000 seperate from windows xp but you can pretty much combine all of the drivers needed to cover all laptos and desktops. You can seperate the drivers in folders by hardware type and throw all sound, lan, video etc in the root of that folder.

UNATTENDED

----------------

I need some guidance on how to get started building my first unattended image for windows xp slipstreamed to sp2. I can definately see how this process is easiest to maintain and best to use for building your master images.

Can anyone point me to a guide with a step by step best practice for doing unattended? I can already I would need to copy my slip stream XP SP2 cd to a folder then modify and somehow remake the iso. Ideally if someone has a guide with a nice unattended template to get me started that would be most helpful.

Dennis

[argon007]

HD Image PRO's

1. You don't have to reinstall the computer..

2. It is recommended the simple user to use, because they don't have batch experience.

HD Image CON's

1. It is difficult to update the software, because the software factory often update the software.

2. You have to format HD.

Unattended CD PRO's

1. You don't have to stay on the computer all day, just put the cd in your cdrom and go out, when you got back, you got everything, cool?

2. It is easy to update your CD for CDRW user, because you can rewrite cd in many times... when you update the software.

3. You don't have to format the HD's...(I always format the HD because I have backup file in second HD.)

Unattended CD CON's

1. It is not recommended for learner and user who don't understand batch.

2. You have to wait for long time.

3. You have to test it on your computer when you don't have VMWare or Virtual PC. When you got error, you must fix it. too trouble!

[Raja]

Hi Dennise

There is a guide available at the following link. See if this gets you going, write to me if you have any specific questions will be more than glad to help.

Cheers

Raja

http://unattended.msfn.org/xp/downloads.htm

[FALCON_GEEK]

I've done both Unattended disk and imaging. I got things i like and hate about both. Unattended is easy but takes SOOO! long.

Ghost-i just really don't like sysprep, its kinda anoying and can cause problems when making an image.

Im still looking for a way to image quickly without using sysprep but so far am very unsuccessful.

For all you imagers out there take a look at G4U its a unix FBSD based Ghost program, very simple, but has all the drivers on the disk and supports one image with any hardware. It seems to make me less angry than norton.

[fly]

I can't be the only one who has gotten a single image working over multiple HALs, can I?

Just use devcon to swap the HAL with RunOnceEx...

[Bezalel]

I use imaging only when I need to deploy a specific application that has a complex manual installation procedure. Other then that I use unattended installs because it handles differant hardware better. When I was manufacturing identical PCs I used imaging but I always made my images with an unattended install.

[Shamwari]

dlevens

Excellent post, I support 10 000 PCs which are rebuilt on a regular basis, and I can confirm that you can use one image for all hardware. We use an unattended install to create the image, and I would just like to add some advice to those trying to achieve this:

Add the following to your unattend.txt/winnt.sif

[Unattended]
	ComputerType = "Advanced Configuration and Power Interface (ACPI) PC", Retail

You will then have an image that when syspreped will work on any acpi compliant PC (we are still supporting PC over 4 years old)

Any PC that has problems imaging with this image can have the unattended install forced on it, and we know it will be identical to the image.

If you change software versions regularly, keep the software installs outside the image, i.e. in runonceex first map a drive, and then install add on software over the network.

The advantage of an image is that it is a 32bit environment, so you can add as many drivers as you wish without hitting the DOS limitations of an unattended network installation.

The second thing you need to do to deal with different mass storage devices is add the following to your sysprep.inf

[Sysprep]
BuildMassStorageSection = Yes

cableguy_uk:

Both installs have their uses, but in my opinion, if you can create a "universal image", it beat the unattended install hands down in both speed and robustness. However, to create a good image, in my opinion, you need a good unattended installation to create it. It is alot easier changing things in one place, untill you have an unattended install you are satisfied with. At this point you sysprep the result, create your image, and freeze development on both.

Kind regards and good luck.

[fly]

dlevens

Excellent post, I support 10 000 PCs which are rebuilt on a regular basis, and I can confirm that you can use one image for all hardware. We use an unattended install to create the image, and I would just like to add some advice to those trying to achieve this:

Add the following to your unattend.txt/winnt.sif

[Unattended]
	ComputerType = "Advanced Configuration and Power Interface (ACPI) PC", Retail

What about hyper-threading? You really should be switching to the proper HAL.

Here's the code I use to switch HALs. I'm sure there is a better way to detect the proper HAL than using smBIOSd.exe, but it works.

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'
' File:	 HAL.vbs
' Updated:  July 2005
' Version:  1.0
' Author:   Zac Holmes
'
' Purpose:  This script is designed to run at the end of the Sysprep process.
'		   It updates the HAL from a standard ACPI HALL to either a 
'			Uniprocessor or Multiprocessor HAL, based on Dell model number
'			shown below.
'
' Notes:	This script requires the following executables:
'			devcon.exe
'			smbiosd.exe
'
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Option Explicit

' Set variables
Dim oShell, oFSO
Dim sOutputFile, aBiosString, iBiosRecords, sCurBiosString, sAPIC
Dim sUniArray, sMultiArray, sModel

' Setup arrays
' sUniArray is for Dell models with a Uniprocessor
' sMultiArray is for Dell models with a Multiprocessor (Hyperthreading included)
sUniArray = array("GX260")
sMultiArray = array("GX270", "GX280")

'**Start Encode**
' The line above exists if there is a desire to encode the script for security reasons.
' To encode the script, download the script encoder via the link below.
' http://www.msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp

Set oShell = WScript.CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")

' Run SMBios to find settings
sOutputFile = oShell.ExpandEnvironmentStrings("%TEMP%") & "\Bios.TXT"
oShell.Run "CMD.Exe /C c:\tcs\sysprep\SMBiosD.Exe > " & sOutputFile,0,True

' Read temp file into an Array
aBiosString = Split(UCase(oFSO.OpenTextFile(sOutputFile,1,False).ReadAll),vbCrlf)
iBiosRecords = CStr(UBound(aBiosString)+1)

' Delete temp file
oFSO.DeleteFile sOutputFile

' Search for arrays listed above in the SMBiosD output
For Each sCurBiosString in aBiosString 
	For Each sModel in sUniArray ' Find the exception we're looking for (Uniprocessor)	
		If Instr(1,Ucase(sCurBiosString),sModel,vbBinaryCompare) <> 0 Then
		  sAPIC = "Uni"
		  Exit For
		End If
	Next
	For Each sModel in sMultiArray ' Find the exception we're looking for (Multiprocessor)
		If Instr(1,Ucase(sCurBiosString),sModel,vbBinaryCompare) <> 0 Then
		  sAPIC = "Multi"
		  Exit For
		End If
	Next
Next
' Do stuff with results
If sAPIC = "Uni" Then 'For ACPI Uniprocessor
  oShell.Run "C:\tcs\sysprep\DevCon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_up !acpiapic_mp",0, True
  oShell.Run "C:\tcs\sysprep\DevCon update c:\windows\inf\hal.inf acpiapic_up",0, True
ElseIf sAPIC = "Multi" Then 'For ACPI Multiprocessor
  oShell.Run "C:\tcs\sysprep\DevCon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up",0, True
  oShell.Run "C:\tcs\sysprep\DevCon update c:\windows\inf\hal.inf acpiapic_mp",0, True
'Else 'for standard ACPI HAL
'  oShell.Run "C:\tcs\sysprep\DevCon sethwid @ROOT\ACPI_HAL\0000 := +acpipic_up !acpiapic_mp",0, True
'  oShell.Run "C:\tcs\sysprep\DevCon update c:\windows\inf\hal.inf acpipic_up",0, True
End If

wscript.quit

I have this script run at initial logon as part of RunOnceEx.