About advanced Windows Image Deployment Provisioning templates in LDMS 9.0

Applies to LANDesk Management Suite 9.0

Note: If you just want the templates, scroll to the bottom.

Purpose

This article will discuss some advanced options for deploying Windows.  With very few modifications this template should work for deploying Windows XP, or Windows 7 (x86 or x64).

This document is for use with deploying images captured using ImageW v2.  This template will not work for Ghost, ImageX or other utilities.

Difficulties with Imaging

With Windows 7 the process for preparing and deploying images has changed dramatically.  There are very distinct differences to deploying XP vs. Windows 7.  In particular XP has different boot code than Windows 7 and it uses a boot.ini file.  Windows 7 uses a BCD file.  XP generally has the boot partition and the OS partition as the same partition, where Windows 7 will usually have a 100 MB boot partition with the OS on a different partition.  In the case of Windows 7 the boot partition is optional, and may not be there.  To further complicate matters the sysprep answer file for Windows 7 is architecture dependent (32 bit Windows needs a 32 bit answer file and 64 bit Windows needs a 64 bit answer file).

Another problem is that when you are deploying a script you don't necessarily have control over how many partitions are on the device until you clean it.  This can cause drive letters to change.  For example, if you have a 1 partition device being imaged with a Windows 7 install that has 2 partitions you will see that when you go into WinPE your single partition is labeled C and your CD-ROM device is labeled D.  When you format and lay down the image you get two new partitions.  In the scenario of Windows 7 with a boot partition your boot partition would now be labeled C and your OS partition would be E (because D is already given out).  If you try to inject the Unattend.xml file to the C drive it won't work, because it is NOT the OS drive like you would expect.  If you have 2 partitions already and then image you will probably have a C drive boot partition, a D drive OS partition and an E drive CD-Rom.  Do you inject your unattend.xml into the C drive, D drive or E drive?  The answer is that it depends on the amount of partitions on the incoming drive and whether WinPE recognizes the CD-ROM drive or not.

Solutions in OSD (not Provisioning)

Our OSD tools are very simple to use.  You fill in a few boxes, select a few options and you get a customized deployment script that will work on your OS and architecture type, regardless of number of partitions.  It would seem that there must be a lot of differences between, for example, a Windows XP x86 image deployment script and a Windows 7 x64 image with boot partition deployment script.  In reality there isn't much difference at all.  The most notable difference is actually where and in what format we save the unattend.xml (or sysprep.inf) file.  All the other lines of code end up being very nearly the same if you have the same options selected.

That brings us to the question of what OSD does to make it so simple?  The answer is in two executables and a script that are run.  The first executable is FixWindows and the second is FixUnattend.  The script that is run is a DiskPart script called rmvol.txt.  Each handles one aspect of the complexity of OS Deployment when handling multiple OSes.

FixWindows will dynamically determine if the device is using Windows XP style booting (boot.ini) or Windows 7 style booting (BCD).  For Windows 7 it will also determine if there is a separate boot partition or if the boot partition and OS partition are the same.  It will then make sure the bootsector is set up correctly and that the boot file has all the appropriate information.  One additional benefit is that it will automatically remove the drive letter assignment for all hard drive partitions except the OS partition, which it will label the C drive.  This is true regardless of number of partitions that you come in with.  This utility is gold for someone who is working with a mixed OS environment, or any scenario where the number of partitions won't be 100% consistent across all hardware!

FixUnattend is a little simpler, but takes care of the 32-bit vs. 64-bit unattend.xml for Windows 7 issue (sysprep.inf for Windows XP is unaffected).  All of our unattend.xml files are created for 32-bit installs.  If you are running a 64-bit install you need to change the tags from Architecture="x86" to Architecture="amd64".  Other than that the XMLs are identical.  FixUnattend will determine the architecture of the newly imaged OS.  If the new OS is 32-bit then the unattend.xml is left alone.  If it is 64-bit then FixUnattend will convert every line that points to the 32-bit architecture to say 64-bit instead.  In this way one unattend.xml file can be used for both 32 and 64-bit images.

Rmvol.txt simply removes all the drive letter assignments at the beginning of the OS Deployment process.  This will make it so that we start off in a known state (no drive letters are assigned, we will give the first disk's first partition the letter C, next partition D, and move on from there).  This utility ensures that we don't have the CD-ROM drive taking over a drive letter that we need and that we can easily map a drive letter to an exact partition.  FixWindows.exe relies on this being run at the beginning of the script.

Difficulties in Provisioning

Provisioning, by comparison, has nothing pre-made for you.  The idea is you can do whatever you want.  There are no limits to how things are set up.  The down side is that nothing is pre-made for you, the idea is you can do whatever you want, and there are no limits to how things are set up.  By its very nature provisioning is supposed to be about you doing what you want without any guidance or suggestions.  This means that all the useful fixes and tweaks that are found in OSD are not there, because you might not want to use them.

Solution to difficulties in Provisioning

The good news is that we can use the OSD utilities within Provisioning!  We just need to explicitly state that we want to use them.  To use the attached OS Deployment template please follow the instructions listed:

  1.  Download the template and (if desired) sample unattend.xml file.

  2.  Create and assign values to the following variables (or replace the variables in the templates with their real values):

NOTE: Variables are case sensitive

a - lddomain - The domain in the environment.  This will be used along with the lduser and ldpass to map a drive to the imaging share.

b - lduser - The username that will be used with lddomain and ldpass to map a drive to the imaging share.

c - ldpass - The password that corresponds to lduser.

d - ImageShare - The unc path of the share where the image is stored.  Should be in format \\server\share.

e - Win7ProdKey - Only needed if you are using the attached unattend.xml.  This is the Windows 7 product key in the format 12345-67890-ABCDE-12345-67890.

f - owner - Only needed if you are using the attached unattend.xml.  This will fill in the Owner field on the computer properties.

g - organization - Only needed if you are using the attached unattend.xml.  This will fill in the organization field on the computer properties.

  3.  If using the attached unattend.xml import it to be used in the template.

  4.  Go to the Post OS Installation section of the template to the Inject Win 7 Unattend File action and select the file you imported in the previous action, or select the unattend.xml file you would like to use.

  5.  Schedule and run the template.

Detailed Information

The attached OSD template will run the following sequence of actions:

Run the Diskpart script rmvol.txt.  Rmvol.txt is already included in the WinPE image under X:\LDClient, so there is no need to do anything special other than an execute file command.

1. Run a Remove all partitions action.
2. Map a drive to the image utility share (where ImageW v2 is located.  This should be %coreIP%\ldmain, unless ImageW has been moved).
3. Map a drive to the image storage share (where you save your .tbi files).
4. Actually deploy the image.
5. Extend the final partition (so the OS partition utilizes all available space).
6. Download FixWindows.exe and all dependencies it requires.
7. Execute FixWindows.exe.
8. Inject the unattend.xml file (in the example it is for Windows 7).
9. Run HII.  This action is set to proceed if it fails because if you have no drivers set up for a piece of hardware this will fail.
10. Download and execute FixUnattend.exe.
11. Run Configure Target OS.

By running this sequence of actions we get the robust solutions available in standard OS Deployment while maintaining the advantages of Provisioning!  Additionally if you make the following changes this can become an OS Deployment script for XP instead of Windows 7.

1. Change the target OS for the template from Windows 7 to the desired version of Windows.
2. Remove and re-add the HII action.  This will apply the change of OS to that action.
3. Choose the appropriate sysprep answer file in the Inject Script action.

Conclusion:

With simple minor edits this template should be able to be seamlessly integrated into a larger end to end provisioning template without worrying about what OS, architecture, hardware, number of partitions, etc.

Note: The attached templates are only valid for 9.0