WDS vs. Symantec GSS 2.5 & Universal Imaging Utility

genXrcist

Hey guys/gals,

At work we have the licensing for Symantec's Ghost Solution Suite 2.5 and Binary Research's Universal Imaging Utility and from what I read, the two in conjunction should be able to create a Zero-touch installation environment with one master image for all PCs and for all OS's. Has anyone used these products or done this before?

Also, if we were to purchase SCCM then it too could be used to create a ZTI (in conjunction with WDS)with one master image for all PCs (only for Windows 7 though). Has anyone done this?

Any thoughts on comparing the two solutions?

Thanks!

eansdad

I guess it would depend on what you want to run OS wise. If your planning on moving to an all Win 7 environment the WDS would be fine if not then stick with what you have. I went from Ghost 11.2 to WDS since we are moving to Win 7 and I control apps with group policy.

Hyper-Me

How many machines are we talking here?

Zero-Touch is cool but unless we are talking thousands upon thousands of machines that need to be imaged routinely, it can be overkill. It's not exactly time consuming to PXE boot a few dozen machines, especially if you have some peons to help.

I guess what i'm getting at here is weigh the time you save with ZTI vs. the time it takes to script/configure a thoroughly working ZTI setup.

Claymoore

I admit I haven't used the latest version of Ghost and I haven't heard of the Binary Research product.

That being said, I would stick with the native MS deployment tools. I switched my old company off an earlier version of Ghost to WDS on Server 2003 a few years ago and never looked back. All of our Windows 7 deployment projects nationwide are using a combination of SCCM, MDT and WDS. You can do Zero-Touch deployments with SCCM, and you can also fully automate Lite-Touch deployments in MDT. If you combine WDS from Server 2008 R2 with SCCM you can do some massive multicast deployments, provided the network team isn't afraid of multicast. I also like the ability to use thin images and then deploy applications and updated drivers through the task sequences in MDT and SCCM.

forkvoid

GSS 2.5 doesn't like Vista/Win7. I switched to WDS for that very reason, which turned out to be way more awesome. Highly recommend going to WDS(it'll save you licensing fees for GSS, too!)

genXrcist

Good points everyone and I agree with them all. WDS with WAIK, MDT & if I can get purchase approval, SCCM really sound like the way to go.

Does anyone have experience packaging XP as a WIM?

forkvoid

genXrcist wrote: »

Good points everyone and I agree with them all. WDS with WAIK, MDT & if I can get purchase approval, SCCM really sound like the way to go.

Does anyone have experience packaging XP as a WIM?

Yes, it's extremely simple. Worked with Ghost? Instead of taking your snapshot of it using Ghost, do it with a boot image using WDS. Works great.

genXrcist

forkvoid wrote: »

Yes, it's extremely simple. Worked with Ghost? Instead of taking your snapshot of it using Ghost, do it with a boot image using WDS. Works great.

Ok sorry, I should have clarified. I meant how do I create a WIM with the drivers for an oobe installation of XP?

forkvoid

genXrcist wrote: »

Ok sorry, I should have clarified. I meant how do I create a WIM with the drivers for an oobe installation of XP?

XP doesn't have a way to pull the drivers from a store like Win7/Vista. Look into MySysprep(for HAL picking) and Sysprep Driver Scanner(for automatic driver loading). Build the image, sysprep and load up with WDS. With XP, you're basically doing a flat image instead of a staged approach like Win7 allows.

stevets

I've been using WDS to deploy Win 7 images to 3 different machine types that total about 300 individual workstations. It works extremely well once you have everything setup. I especially like being able to approve and name machines as they attempt their first PXE boot.

Combine that with a solid answer file, and you have very quick deployments. I have all of our base applications installed into the image (office and our EMR) and then use group policy to push out everything else.

The trouble I had with the whole process was getting the default user profile setup. Since the <copyprofile> option doesn't really work too well, I ended up creating several new GPO's to handle the desktop background, shortcuts, drive mappings, etc. It ended up being a much better move in my opinion (and an excellent learning experience), simply because it leaves us in a position to adjust so many more things on the fly without having to re-image all of the machines.

Lamini

Havent played too much with WDS (in other words, Im biased to SGSS+UIU), but to contrast, Ive had one master image I used XP+SGSS2.5+UIU on lets see, about 7 different computers. Binary research just released the W7 support just recently didnt they (several months ago), so Im sure theres more tweaking to do. I am seeing a lot of good reviews on the new(er) (still working on mcse) WDS which is a good thing (its free).

Hyper-Me

Try to get 2008 R2 for your WDS needs. Dynamic driver provisioning is some cool stuff.

genXrcist

Thanks everyone for the replies. Couple of questions:

Stevets, for Group Policy are you just using login scripts?

Lamini, I've got the new version of UIU and will test it with Windows 7 to see how well it works. Will post back and let you know.

Hyper-Me, we've got Server 2K8 Std R2 for production but also Technet, do I need a certain version for Dynamic driver provisioning? What is that all about?

Hyper-Me

genXrcist wrote: »

Thanks everyone for the replies. Couple of questions:

Stevets, for Group Policy are you just using login scripts?


Hyper-Me, we've got Server 2K8 Std R2 for production but also Technet, do I need a certain version for Dynamic driver provisioning? What is that all about?

You can install software with Group Policy either by using software deployment GPOs or via logon scripts. I'd test what you feel is more reliable for your scenario.


As for my question, Dynamic Driver Provisioning lets you put the drivers for your environment on the server, and after the machine images and is running through the mini-setup phase (where it detects devices) it will pull the drivers off of the server that it needs. This saves you the time of extracting an image, iinjecting drivers and loading the image back. Any version of 2008 R2 will do this.

stevets

genXrcist wrote: »

Thanks everyone for the replies. Couple of questions:

Stevets, for Group Policy are you just using login scripts?


Hyper-Me, we've got Server 2K8 Std R2 for production but also Technet, do I need a certain version for Dynamic driver provisioning? What is that all about?

Well, prior to deploying all of these Windows 7 boxes, we were relying on login scripts quite heavily. Since we upgraded our domain controllers to 2008 R2, and began utilizing WDS, I've tried to move us away from that.

Right now, none of the Win 7 boxes rely on login scripts. In the past, the main function of the login script was to map the network drives. In our current configuration, the drives are mapped by using a GP Preference GPO. We've also begun utilizing group policy for many other tasks that were otherwise difficult to accomplish for one reason or another. Once you really begin to see and understand the benefits of GP, you'll never want to go back.

To give some input on your last question...My experience with drivers in WDS on 2008 & 2008 R2 is limited to the boot images. In 2008 (pre R2) you can't use WDS to inject PE drivers into a boot image. This is especially problematic if WDS doesn't have a driver for the NIC on a machine you are trying to image. The only solution you had was to download the WAIK and mount the wim file with imagex and drop the network driver into the correct folder. A huge pain in the butt.

With 2008 R2, you can add/create driver packages and select specific drivers that you want to use with your images right inside the WDS management console. It makes life soooo much easier, and fixes one of the biggest flaws (imo) that WDS had pre R2.

genXrcist

Hyper-Me wrote: »

You can install software with Group Policy either by using software deployment GPOs or via logon scripts. I'd test what you feel is more reliable for your scenario.


As for my question, Dynamic Driver Provisioning lets you put the drivers for your environment on the server, and after the machine images and is running through the mini-setup phase (where it detects devices) it will pull the drivers off of the server that it needs. This saves you the time of extracting an image, iinjecting drivers and loading the image back. Any version of 2008 R2 will do this.

Whoa, this is sweet!! I don't think I recall reading/hearing about this in my studies. Would I use WSIM for this? This sounds like what stevets was explaining below in his last paragraph, am I right?

stevets wrote: »

Well, prior to deploying all of these Windows 7 boxes, we were relying on login scripts quite heavily. Since we upgraded our domain controllers to 2008 R2, and began utilizing WDS, I've tried to move us away from that.

Right now, none of the Win 7 boxes rely on login scripts. In the past, the main function of the login script was to map the network drives. In our current configuration, the drives are mapped by using a GP Preference GPO. We've also begun utilizing group policy for many other tasks that were otherwise difficult to accomplish for one reason or another. Once you really begin to see and understand the benefits of GP, you'll never want to go back.

To give some input on your last question...My experience with drivers in WDS on 2008 & 2008 R2 is limited to the boot images. In 2008 (pre R2) you can't use WDS to inject PE drivers into a boot image. This is especially problematic if WDS doesn't have a driver for the NIC on a machine you are trying to image. The only solution you had was to download the WAIK and mount the wim file with imagex and drop the network driver into the correct folder. A huge pain in the butt.

With 2008 R2, you can add/create driver packages and select specific drivers that you want to use with your images right inside the WDS management console. It makes life soooo much easier, and fixes one of the biggest flaws (imo) that WDS had pre R2.

Oh believe me, I'm a GPO believer but we're still in 2K3 here at work and I tend to forget that there are like an additional 800 GPO's in 2K8.

I remember back in the spring of '09 when I first cracked open WDS that I had to use imagex for injecting drivers and honestly, it was such a pain that I said screw it and went back to Ghost. I'm taking a fresh look at WDS now and am excited to hear from an experienced person that that major flaw has been remedied.

---

Thank you both for your replies, I've found them to be very helpful!!!

genXrcist

forkvoid wrote: »

XP doesn't have a way to pull the drivers from a store like Win7/Vista. Look into MySysprep(for HAL picking) and Sysprep Driver Scanner(for automatic driver loading). Build the image, sysprep and load up with WDS. With XP, you're basically doing a flat image instead of a staged approach like Win7 allows.

To do this in an environment with let's say, 20 different PC models and/or HAL's would be quite complicated right?

Also, the following is from my old employers instructions on how to automate the driver installation so that one Ghost image could be used with multiple HAL's. What are everyone's thoughts on this?

---

The bulk of the driver installations will be handled by sysprep and, in most cases, it will not be necessary to go through the installation routine yourself. The first step will be to download all available drivers for all hardware models the image is to support. It is important to keep track of all the drivers needed, I would recommend setting up a spreadsheet to track the downloaded files, driver versions and what models of machines are compatible with what driver files\versions.

Preparing Drivers for Sysprep

Most driver packages you download will include a setup.exe and associated files to aid in installation and, in many cases, to install related applications (e.g., ATI Control Panel). Sysprep, however, can’t use these setup routines and instead relies on the .inf file (usually found in a subfolder) to do driver installation. To prepare the driver files for sysprep, you will want to locate the folder that contains the .inf and copy the contents of that folder (including subfolders) to a folder that sysprep will search.

1. Create a folder called ‘drv’ in the root of c:
2. Create subfolders in c:\drv that have numbers for names starting with 0 (c:\drv\0, c:\drv\1, etc.). The first level of folders will be used to organize the driver types that are to be used and will not contain any drivers (for example, c:\drv\1 is for NIC drivers, c:\drv\2 is for video drivers, etc.). You will also want to create subfolders inside the first set of numbered folders to contain the actual drivers (using the example above, c:\drv\2\0 would contain the ATI mobility video driver, c:\drv\2\1 would contain the Nvidia mobility driver, etc). There is a limit to the number of characters that can be in the driver path, so using numbered folders will keep you from reaching that limit. You will want to include a readme.txt at each level to easily keep track of what is in each folder.
3. Sysprep will not search subfolders that are not specified in the path we create later, so the driver’s .inf (and related files) must be in the second numbered folder, no deeper (so c:\drv\1\1\ati\driver.inf is wrong). Copy the driver files (those in the same folder as the inf) and any subfolders below that level into the appropriate folder and document this in the readme.txt that is in the parent folder. Repeat until all drivers needed are in place.
4. In the sysprep.inf, add all of the folders that contain drivers to the OemPnPdriversPath= section so that it looks like this:

OemPnPdriversPath= \drv\1\0;\drv\1\1;\drv\1\2;\drv\1\3;\drv\1\4;\drv\1\5;\drv\2\0


Drivers that can’t be installed via Sysprep

Some driver packages may not extract out to the raw driver files, but instead force you to run their installation routine. These drivers cannot be installed via the standard sysprep method. In this situation you can either run the installation routine (if it is compatible with the hardware you are making the image on), or it will have to be scripted to run on first boot after the mini-setup is run. For this we have created a program (Install_System_Drivers.exe) that will read the WMI information from a machine during boot and can run an installation routine for any specific model of machine. The program relies on a DriverList.ini file that has a section for each model type. All you need to do is add a line in the appropriate section that references the driver or application that you need to install. For example:

[T61]
Command_1="C:\drv\0\5\infinst_autol.exe",-a -s,Intel Chipset

This entry will run the Intel chipset driver install located at c:\drv\0\5, with the –a and –s switches, if the machine is detected as a Lenovo T61. While many applications and drivers can be installed this way, it is recommended that you limit the number you install to keep the initial boot time as short as possible and to avoid any conflicts or problems.

To kick off the Install_System_Drivers.exe application, add an entry to the [GuiRunOnce] section of sysprep that calls the executable (it is best to place the executable and ini file in the c:\Program Files\SourceFiles\sysprep folder). For example:

[GuiRunOnce]
Command0="c:\Program Files\SourceFiles\sysprep\Install_System_Drivers.exe"

forkvoid

genXrcist wrote: »

To do this in an environment with let's say, 20 different PC models and/or HAL's would be quite complicated right?

Also, the following is from my old employers instructions on how to automate the driver installation so that one Ghost image could be used with multiple HAL's. What are everyone's thoughts on this?

---

The bulk of the driver installations will be handled by sysprep and, in most cases, it will not be necessary to go through the installation routine yourself. The first step will be to download all available drivers for all hardware models the image is to support. It is important to keep track of all the drivers needed, I would recommend setting up a spreadsheet to track the downloaded files, driver versions and what models of machines are compatible with what driver files\versions.

Preparing Drivers for Sysprep

Most driver packages you download will include a setup.exe and associated files to aid in installation and, in many cases, to install related applications (e.g., ATI Control Panel). Sysprep, however, can’t use these setup routines and instead relies on the .inf file (usually found in a subfolder) to do driver installation. To prepare the driver files for sysprep, you will want to locate the folder that contains the .inf and copy the contents of that folder (including subfolders) to a folder that sysprep will search.

1. Create a folder called ‘drv’ in the root of c:
2. Create subfolders in c:\drv that have numbers for names starting with 0 (c:\drv\0, c:\drv\1, etc.). The first level of folders will be used to organize the driver types that are to be used and will not contain any drivers (for example, c:\drv\1 is for NIC drivers, c:\drv\2 is for video drivers, etc.). You will also want to create subfolders inside the first set of numbered folders to contain the actual drivers (using the example above, c:\drv\2\0 would contain the ATI mobility video driver, c:\drv\2\1 would contain the Nvidia mobility driver, etc). There is a limit to the number of characters that can be in the driver path, so using numbered folders will keep you from reaching that limit. You will want to include a readme.txt at each level to easily keep track of what is in each folder.
3. Sysprep will not search subfolders that are not specified in the path we create later, so the driver’s .inf (and related files) must be in the second numbered folder, no deeper (so c:\drv\1\1\ati\driver.inf is wrong). Copy the driver files (those in the same folder as the inf) and any subfolders below that level into the appropriate folder and document this in the readme.txt that is in the parent folder. Repeat until all drivers needed are in place.
4. In the sysprep.inf, add all of the folders that contain drivers to the OemPnPdriversPath= section so that it looks like this:

OemPnPdriversPath= \drv\1\0;\drv\1\1;\drv\1\2;\drv\1\3;\drv\1\4;\drv\1\5;\drv\2\0


Drivers that can’t be installed via Sysprep

Some driver packages may not extract out to the raw driver files, but instead force you to run their installation routine. These drivers cannot be installed via the standard sysprep method. In this situation you can either run the installation routine (if it is compatible with the hardware you are making the image on), or it will have to be scripted to run on first boot after the mini-setup is run. For this we have created a program (Install_System_Drivers.exe) that will read the WMI information from a machine during boot and can run an installation routine for any specific model of machine. The program relies on a DriverList.ini file that has a section for each model type. All you need to do is add a line in the appropriate section that references the driver or application that you need to install. For example:

[T61]
Command_1="C:\drv\0\5\infinst_autol.exe",-a -s,Intel Chipset

This entry will run the Intel chipset driver install located at c:\drv\0\5, with the –a and –s switches, if the machine is detected as a Lenovo T61. While many applications and drivers can be installed this way, it is recommended that you limit the number you install to keep the initial boot time as short as possible and to avoid any conflicts or problems.

To kick off the Install_System_Drivers.exe application, add an entry to the [GuiRunOnce] section of sysprep that calls the executable (it is best to place the executable and ini file in the c:\Program Files\SourceFiles\sysprep folder). For example:

[GuiRunOnce]
Command0="c:\Program Files\SourceFiles\sysprep\Install_System_Drivers.exe"

Sysprep Driver Scanner automates the OemPnpDriverPath by recursing a folder and adding every INF to the path.

As for those packages that require a setup--not true. Read the readme that comes with the packages to find how to extract the files, then it's just another inf/cat/dll set.

As for the HALs, not really. There's only a handful, and only three used today: ACPI, ACPI Uniprocessor, ACPI Multiprocessor. When building your image, set the HAL to ACPI and run MySysprep. When it boots back up and goes into mini-setup, MySysprep will determine the correct HAL. Downgrading from ACPI Uni/Multi to ACPI breaks things, while upgrading works fine. ACPI is the lowest that they all can use.

EDIT: Just saw the program your old employer wrote--if you extract the files from the package and use Sysprep Driver Scanner to add them to the path, Windows will pick only the drivers it needs, making that program unnecessary.

genXrcist

forkvoid wrote: »

Sysprep Driver Scanner automates the OemPnpDriverPath by recursing a folder and adding every INF to the path.

As for those packages that require a setup--not true. Read the readme that comes with the packages to find how to extract the files, then it's just another inf/cat/dll set.

As for the HALs, not really. There's only a handful, and only three used today: ACPI, ACPI Uniprocessor, ACPI Multiprocessor. When building your image, set the HAL to ACPI and run MySysprep. When it boots back up and goes into mini-setup, MySysprep will determine the correct HAL. Downgrading from ACPI Uni/Multi to ACPI breaks things, while upgrading works fine. ACPI is the lowest that they all can use.

EDIT: Just saw the program your old employer wrote--if you extract the files from the package and use Sysprep Driver Scanner to add them to the path, Windows will pick only the drivers it needs, making that program unnecessary.

Wow, that all makes sense. But even with only 3 HAL's I was thinking that multiple PC models meant taking the time to extract all the drivers for each system and then putting them all onto one HDD on the Master Image. Of course it would take a long time but it's still better than maintaining 20 different images.

Thanks for the info, I'm going to give those utilities a go!

forkvoid

genXrcist wrote: »

Wow, that all makes sense. But even with only 3 HAL's I was thinking that multiple PC models meant taking the time to extract all the drivers for each system and then putting them all onto one HDD on the Master Image. Of course it would take a long time but it's still better than maintaining 20 different images.

Thanks for the info, I'm going to give those utilities a go!

Yes, it will still require you to have the drivers stored locally on the disk, as XP can't pull from the network during mini-setup. I supported 16 models and my drive store was 2GB(I went through and found each model that used the same device and then added the newest driver for that device only, usually the manufacturer driver instead of the OEM).

Lamini

GenXrist

waking up an old thread here... did you have any luck?

genXrcist

Sorry but I no longer work for that employer as of Nov of 2010 so I never made any more headway on that. Where I'm at now has converted over to WDS entirely but for the XP images we're just recreating each model from what they used to have in Ghost. I would like to spend some time to work this out but it's not slowing our team down enough that it's worth investing my time in it.

Thanks for asking though!

SilverGenius

I tried to get WDS/MDT working to deploy XP. I could never get it working just right and didn't want to spend a lot of time on trying to make it work so we just install of an unattended cd. Most of the machines are Windows 7 now though and Windows 7 is very simple to deploy with WDS/MDT.