See also: Deploying Windows 7 Using Windows Deployment Services (WDS): Step-by-Step – Part I

After reviewing Post I about installing and configuring Windows Deployment Services, we’ve also review the process of capturing a customized Windows 7 image and upload it to WDS.

To image is already available and we can use it to deploy on workstations from a PXE boot; but to achieve the full unattended process we have to create the unattended files, basically the files where the installation process can request answers about the installation process (product key, user name and password, computer name, etc).

To create these answer files, two of them, we are going to use a tool included in WAIK 2.0: Windows System Image Manager.

1. Preparing WISM for Unattended Deployment

The use of Windows System Image Manager (WISM) is based on loading an operating system image, the application will review the answers involved on the deployment and we can set the answers as we need it.

1.1 Open WSIM console, which you can find on WAIK program menu.

1.2 Right click on select a distribution share, create new distribution share.

This will be the working folder.

1.3 For WISM to work properly with the image, we’ll need to export it from WDS to the distribution share.

To export the image, we can access the WDS console, explore the “Install Images” section, right click on the image and select “Export”.

1.4 Now getting back to the WSIM console. Right click on “Windows Image”, and select a “windows image”, then browse to “Dis share ref_001” and select the image we exported earlier from the WDS console.

1.5 Now WSIM will need to create a catalog file, so select yes at the next window.

1.6 Now it will begin the catalog process, this will take more than a few minutes depending on how big the WIM is.

Now you will see in the windows image panel components, and packages, in my case. In the packages part you can choose to run certain updates, language packs, hotfixes, and versions during the installation process of the OS. We are going to focus only on unattended part of the WDS deploy.

2. Creating the WDSClientUnattend.xml

Here’s an example file of WDSClientUnattend.xml.

Now that we have our reference image loaded into WSIM, I am going to show you how to create the unattended file for the first booting process. I will refer to this file as WDSClientUnattend.xml. We will need to create two .xml files for total automation. There are a few components we need to add for the unattended pre install environment.

Here are the things we are going to add.

1. Regional – Language settings during setup
2. Domain credentials
3. Create partition
4. Modify partition
5. Then validating the answer file.

Setting the regional-language

2.1 In the WSIM console look for the “Windows Image” pane, the expand components. Since I am doing this on a 64 bit, will show that first.  Browse to the “windows-international-core-winpe” node. Right click on this and select “Add Setting to Pass 1 windowsPE”.

2.2 Now we’ll see this added to your answer file. Also look in the properties pane right next to the answer file, and notice this is where we’ll make any changes to the settings of each component you add. For this component we’ll add “en-us” to everything except “layeredDriver”.

The “layeredDriver” is optional, and only used for Japanese and Korean keyboards.

2.3 Now we need to expand “windows-international-core-pe”, select “SetupUILanguage”, then in the properties pane add “en-us” to the “UILanguage”.

Domain Credentials

2.4 Browse to “windows-setup\WindowsDeploymentServices” in the components, then right click on “login”, and add this to 1 pass windowsPE. Now expand login in the answer file pane, and select “credentials”. Now put in your domain credentials for the network install.

Create Partition

2.5 Browse to “windows-setup\WindowsDeploymentServices” then right click on “ImageSelection” and add to 1 pass windowsPE. Now select install to in the answer file pane, then in properties set “DiskID” to “1”, and “PartitionID” to “1” also.

Modify Partition

2.6 On the modify partition properties set “active” to “true”, “format” to “NTFS”, “label” to “WINDOWS”, “letter” to “C”, “Order” to “1”, and “PartitionID” to “1”.

Image Selection

2.7 Add “Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection” to your answer file. In the properties of “installImage” add the file name of the image we’ve captured, image group where we stored it in WDS, and image name the way you have it setup in the WDS console.

2.8 Next select “InstallTo”, and set “DiskID” to “0”, and “PartitionID” to “1”. This will install the image to disk 0, on partition 1.

Validate the answer file

2.9 To validate the answer file we can access to Tools, and selecting “Validate Answer File”. In our case should not complete without any errors.

If it does, you’ll see in the error description what went wrong.

2.10 Save the file as “WDSClientUnattend.xml” in the “E:\RemoteInstall\WdsClientUnattend” folder created by WDS.

NOTE:

The unattended file WDSClientUnattend must be associated to the WDS Server and not to any particular image. If you are inserting a value in the Image you’ll be deploying, that means every time you are using the PXE boot and contacting the WDS Server, the image selection will be always the same.

So, if we want to choose the image when the installation process starts, we must remove “Microsoft-Windows-Setup\WindowsDeploymentServices\ImageSelection” section from our answer file.

3. Adding the WDSClientUnattend.xml to the WDS server

3.1 Open up the WDS console, and right click on your server and select “Properties”.

3.2 Click on the client tab, and check “Enable unattended installation” then browse for the “WDSClientUnattend.xml” we created in the previous step. Selecting the appropriate architecture.

This will automate the booting process in the deployment process. Now we need to automate the OOBE which is the actual installation of the WIM.

4. Creating the OOBEunattend xml for Installation/OOBE settings

Here’s an example file of OOBEUnattend.xml.

This is the second part which will unattended the actual installation of our reference image, the OOBE part. This file I will be calling OOBEUnattend.xml. I will show you how to:

• Set the computer name and time zone
• Skip the EULA, and setup network location
• Create a login, and set a password

Computer name and time zone

4.1 Open WISM console, then go to file, and open a new answer file. Browse to the Components section and right click on “Microsoft-Windows-Shell-Setup” and select “Add Setting to Pass 4 specialize”

4.2 Here we want to configure the time zone, computer name (add an asterisk * for random name), and any other settings we want to setup in the properties pane.

4.3 Now right click on “Microsoft-Windows-International-Core” and select “Add Setting to Pass 7 oobeSystem”

4.4 Now set everything to “en-us” except for “UIlanguageFallback”. Leave that blank.

Setup Network location, and EULA skip

4.5 Find “Microsoft-Windows-Shell-Setup” in the components, and add “OOBE” to “Add Setting to Pass 7 oobeSystem”. Fill in the settings that you want in the properties.

Login and password

4.6 Browse to, and expand “Microsoft-Windows-Shell-Setup”, expand “UserAccounts”, “LocalAccounts”, “LocalAccounts” again, then add “password” to “Add Setting to Pass 7 oobeSystem”.

4.7 Click on “LocalAccount” in the answer file, and add the information in its properties.

4.8 Then do the same for the password. Also feel free to play around with the shell setup in the specialize part of the file for a more personal install.

Validate and add to reference deploy image

4.9 Validate the answer file as mentioned before. And save the file to the folder we’ve created for unattended images “E:\RemoteInstall\WdsClientUnattend”.

5. Associating OOBEUnattend.xml to the Install Image

5.1 Open the WDS console and expand “install images”, click on “captures” then right click on the image name “Ref_001”, and select properties.

5.2 At the bottom of the properties window we’ll see “Allow image to install in unattended mode” check that. Now browse for the file created in the step above in “E:\RemoteInstall\WdsClientUnattend”. Apply and select ok.

6. Deploying an unattended custom image with WDS

We have everything in place now for a complete unattended deployment of Windows 7.

6.1 Boot up the computer with F12 for a network boot.

6.2 The computer will find your WDS server and ask you to hit F12, do so quickly or you may miss it. Now select the boot image, “Windows 7 (x64)” in my case.

Windows will load files after booting

Since the deployment will not require any user intervention, the next window appearing should be this one.

Hope you found this information useful.

See also: Deploying Windows 7 Using Windows Deployment Services (WDS): Step-by-Step – Part I

See also: Deploying Windows 7 Using Windows Deployment Services (WDS): Step-by-Step – Part II 

We had a good look about the possibilities about Windows deployment; regarding Windows 7 we’ve completed a guide using Microsoft Deployment Toolkit 2010 (MDT 2010 beta) to capture and deploy unattended installations of Windows 7 with Office 2007 (Post I, Post II and Post III). Also we’ve reviewed how to implement unattended installations of Windows Vista using Windows Deployment Services (Post I, Post II and Post III).

But we didn’t take a look about deploying Windows 7 using Windows Deployment Services (WDS). Now we have a good chance to do that, providing a simple step by step procedure.

Why Using WDS?

Deploying operating systems using technologies like Microsoft Deployment Toolkit 2010 or even System Center Configuration Manager are far more scalable that we can offer using WDS. But there’s always the cost/benefit analysis we should take before deciding to use always the most scalable and dynamic technology available.

Having a robust platform for deployment requires, as always, bigger costs for maintain it; and if there’s no trade off which we can see it in the short term, why bother? Example: We are using one operating system image as a baseline for our branch office with around 15 users; and we usually have to deploy one operating system to users per month. Should we need to allocate considerate hardware and efforts to maintain MDT or SCCM? Probably those technologies will be far more expensive than just using a simple one or even manual deployments.

Windows Deployment Services is a simple and straight forward technology to achieve fast and unattended deployments. Just loading a WIM file and the operating system is available over the network.

So, let’s take a look about a simple step-by-step process to achieve unattended deployments of Windows 7 using WDS.

Prerequisites for WDS

• Active Directory and DNS server in place. The computer running WDS must be a member of an Active Directory.
• An active DHCP server on the network
• An NTFS partition on the server with the WDS role to store your OS images.
• Windows Automated Installation Kit (WAIK). This is an optional component that we can use to create unattended files.

1. Installing the WDS role on Windows Server 2008

1.1 Installing WDS in Windows Server 2008 is quite simple, just add it as a Server Role from Server Manager.

Besides the core components in WDS, Windows Server 2008 has the multicasting feature for the deployment. Transport Server option gives us that functionality.

1.2 Click on next and then Install.

2. Configure WDS for first use

WDS also has a simple procedure to configure the server, just running a wizard and you’ll be good to go.

2.1 In Administrative tasks open the WDS up in mmc, expand “Servers” then right click on the root name, and “configure server”.

2.2 We’ll need to create a path for the storing of our images. E:\RemoteInstall.

2.3 PXE answer policy, every time a machine boots from the network you can decide if they are going to receive an automatic answer or wait for an administrator decision.

2.4 Uncheck “add images now” select next.

If we have the DHCP server on the same operating system running WDS, we’ll also need to access the WDS server properties and select on the DHCP tab both options: “Do not listen on port 67” and “Configure DHCP option 60 to ‘PXEClient’.

In our case the DHCP role is placed on a different server and those options are not checked.

3. Adding Boot and Default Windows 7 Images

Every environment we are trying to deploy will always need boot images; fortunately we just have to select the boot images included on Windows 7 DVD.

3.1 Right click on “boot images” and select add boot image

3.2 Using a Windows 7 DVD, we can easily find the boot.wim file in “sources” folder.

.

3.3 Now we can leave the image name to its default or we can change it.

3.4 Confirm settings then continue.

For adding the Windows 7 operating system image is the same procedure to run, but using the “Install Images” folder in WDS console.

3.5 Adding the default Install Image Right click on Install Images in the WDS console and select Add Image.

3.6 Creating a new image group.

.

3.7 Browse again in “sources” folder and select install.wim.

.

3.8 Now we are given a choice of all the available versions of the installation media; install.wim contains all the versions available of Windows 7.

.

We can select just one version to avoid allocating unnecessary space in the hard drive.

Once completed we’ll have available a boot image, plus a default and clean image of Windows 7 to be installed over the network.

4. Capture Boot Image

There’s an important note regarding boot images; to capture a Windows 7 operating system that you’ve already deployed, you’ll need to create a new media set of this boot.wim file.

4.1 Add a new boot image, the same procedure shown above. Open up the WDS console and right click on “boot images” and select “add boot image”.

4.2 Change the name, and description to identify which image is for booting and for capturing; click on “Finish”.

Once the wizard complete, we’ll see the image added to “Boot images”.

4.3 Now select the image name right click, then select “Create Capture Boot Image”.

5. Install, configure, and Sysprep the reference machine

To deploy a customized image of Windows 7 using WDS we must capture it first from an already deployed image.

An operating system by default is not ready to be captured, before doing that we must prepare the image. Sysprep is the tool in charge of removing all the particular components in an installation (computer name, SID, OS product key, etc) and makes this image suitable for capturing.

5.1 We can find sysprep tool in “C:\Windows\system32\sysprep”. Running sysprep.exe will pop a simple GUI, where we can select the options OOBE, Generalize and Reboot after completion.

We can also use the command line: “sysprep /oobe /generalize /reboot”.

Once selected, we’ll see a process running that is going to take a few seconds and the following reboot.

6. Capturing the reference machine

6.1 After sysprep has rebooted our reference machine, boot from PXE network boot, using F12.

The computer will require for an IP address to the DHCP Server which will redirect it to a Boot Server available on the network, in this case WDS. After finding it, it will require a second F12 selection.

It is important to note that if we missed this sequence, we should reboot the machine as soon as possible. If Windows operating system starts, the sysprep clean up performed earlier will be lost and you won’t be available to capture the image.

6.2 Select “Capture (x64)” and press enter

6.3 After this we’ll see the WDS wizard, select next.

6.4 Now select the volume to capture, C:\, and create the image name file.

If we don’t see any volume available to capture, is because the sysprep process did not completed normally and we must run it again.

6.5 Now we will see the screen asking you where to store the WIM file. Select “upload Image to WDS server”, providing the IP address or FQDN. It will also require domain credentials to access the server.

6.6 Select the Image Group you’ve created to store the image. If you don’t have any group created in WDS, you’ll receive the error of no group available.

Now the WDS will create your custom reference image of your client machine.

The process usually takes a while, depending on the operating system characteristics you are capturing.

On the next post we’ll see how to create unattended files with some examples and deploying a this captured Windows 7 image in a full unattended process.

See also: Deploying Windows 7 Using Windows Deployment Services (WDS): Step-by-Step – Part II

These tools were consolidated by one command-line: DISM.exe (more info on Post I about MDT 2010). Meaning that the Windows PE management (like customizing, adding drivers or inserting Hyper-V integration components to those images) that you executed on previous versions of WAIK, has significant changes.

On this post we’ll be reviewing how to add the Hyper-V Integration Components to a Windows Preinstallation Environment (Windows PE) image, including the new Windows PE 3.0.

Why should I need to add the Hyper-V Integration Components to Windows PE?

The Integration Components of Hyper-V are a set of drivers that are a significant performance change that you can apply to virtual machines for them to be able to install synthetic devices instead of emulated devices.

Some of the drivers that are installed using the Integration Components are: Video driver, network driver (with this you avoid using Hyper-V’s Legacy Network adapter), storage driver, VMBUS (transport for synthetic devices), time sync (time synchronization with the host), etc.

Adding Hyper-V Integration Components 

As I mentioned before, I prepared a set of MDT 2010 posts about LTI deployments with Windows 7, so I’m going to take the LiteTouch PE image created on that deployment instead of a common Windows PE image (boot.wim). But again, this process will work the same as using a Windows PE raw image.

Since I have already a LiteTouch image added to my Windows Deployment Services (WDS) as a boot image, I’m going to export it, mount the image to be able to apply all changes there, and then import it again to WDS.

1. Mounting Boot Image

1.1. Open the Windows Deployment Services Console and Export the image.

1.2. I’m going to place it on C:\Temp.

1.3. Create the folder where you are going to mount it. In my case C:\Temp\mount.

1.4. Run “cmd” as Administrator, place it in “cd C:\Program Files\Windows AIK\Tools\Servicing”.

1.5. Mount the image using this command line:
Dism.exe /mount-wim /wimfile:”C:\Temp\Lite Touch Windows PE.WIM” /index:1 /mountdir:”C:\Temp\mount”

/index:1 states that you want to use the first image inside the WIM file. A WIM file for operating systems, like Windows 7 for example, contain several images: Ultimate, Enterprise, Starter, etc.

2. Uncompressing Drivers from Integration Components

Now that the image is mounted and ready to be modified, we are going to uncompress the files we need from the Hyper-V Integration Components.

2.1. Since I’m using a virtual machine, I’m going to attach the Integration Components media and extract the files from there.

2.2. From the media of the IC, copy this two files to a local folder:

D:\support\amd64\Windows6.0-KB951634-x64.msu
D:\support\x86\Windows6.0-KB951634-x86.msu

We are going to use the Expand command line to extract the drivers within those updates. Place the cmd window in C:\Windows\System32\ and create a folder to store this temporary files. C:\Temp\source

2.3. Insert:
expand.exe –F:* “C:\Temp\Windows6.0-KB951634-x64.msu” “C:\Temp\source”.

Repeat the step for the x86 update.

Now we are going to also extract the drivers included in the .CAB files that we took from the MSU file.

2.4 Create another temporary folder for these drivers. C:\Temp\source\drivers.

2.5. Insert:
expand.exe -F:* "C:\Temp\source\Windows6.0-KB951634-x64.cab" "C:\Temp\source\drivers".

Inside C:\Temp\source\drivers are all the files we need to insert x64 environments. You can repeat the step 2.5 using the x86 update.

3. Injecting the drivers

You will notice that hundreds of files have been uncompressed, but we are not going to add them all, we are just going to inject the ones that we need.

Here are all the necessary drivers and the command lines to execute:

dism /image:"C:\Temp\mount" /add-driver  /driver:"C:\Temp\source\drivers\amd64_wnetvsc.inf_31bf3856ad364e35_6.0.6001.18016_none_b337f91d87dbf1d0\wnetvsc.inf"

dism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_ws3cap.inf_31bf3856ad364e35_6.0.6001.18016_none_f2e1ba67fcb48f61\ws3cap.inf" /forceunsigned

dism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_wstorflt.inf_31bf3856ad364e35_6.0.6001.18016_none_1cadbbeed0ad55a3\wstorflt.inf" /forceunsigned

dism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_wstorvsc.inf_31bf3856ad364e35_6.0.6001.18016_none_836399a4204c4863\wstorvsc.inf" /forceunsigned

dism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_wvmbus.inf_31bf3856ad364e35_6.0.6001.18016_none_959a72f36267838a
\wvmbus.inf" /forceunsigned

dism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_wvmbushid.inf_31bf3856ad364e35_6.0.6001.18016_none_4ccff81064c7c78f
\wvmbushid.inf" /forceunsigned

dism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_wvmic.inf_31bf3856ad364e35_6.0.6001.18016_none_5dfb8c2804cc9e9a
\wvmic.inf" /forceunsigned

 

Injecting drivers

Note that on most of them, the /forceunsigned parameter was necessary. If you don’t use it, this error will appear: “Error 50 The request is not supported”

4. Committing and Unmounting the Boot Image

Now we have are image ready to use it, so we are going to commit the changes and unmount it.

4.1. From cmd:
Dism /unmount-wim /Mountdir:"C:\Temp\mount" /commit

5. Deploying the Image

On C:\Temp you’ll find the WIM file modified and ready to be added to WDS.

5.1. Open the WDS Console, select “Add Boot Image” and complete the wizard.

On the new boot image, I’m adding the Integration Components description

5.2. Boot the new virtual machine from the network and select the image you just added.

And the new virtual machine should be fully functional with the Hyper-V Integration Components included.

How you can you test it? In my case, I’m connecting with RDP to the Hyper-V host and the mouse from inside the virtual machine is working perfectly; if the IC components are not present a message will appear saying that the “Mouse session could not be captured”.

Adding Drivers Using WAIK 1.1 Tools

If you were wondering how to execute the procedure using the WAIK 1.0 or 1.1 tools, here it is:

1. Mount the WIM file using imagex tool:
imagex /mountrw “C:\Temp\Lite Touch Windows PE.WIM” 2 “C:\Temp\mount”

2. Inject drivers using peimg tool:
peimg /inf=C:\Temp\source\drivers\*.inf /image=”C:\Temp\mount”

*.inf is representing all the previous drivers that we added above. Repeat the command line for each file.

3. Commit changes:
imagex /unmount /commit C:\Temp\mount

4. Add the new “Lite Touch Windows PE.WIM” on WDS as a “Boot Image”

Enjoy!

Cheers!

Event Viewer from WDS Server

Event 257: An error occurred trying to start the Windows Deployment Services server.

Event 258: An error occurred trying to start the Windows Deployment Services image server.

Event 266: An error occurred while to refreshing settings.

Event 513: An error occurred trying to initialize provider WDSImgSrv from C:\Windows\system32\WdsImgSrv.dll. Windows Deployment Services server will be shutdown.

Disclaimer
Please note that the following possible reasons, are related when all those events appear simultaneously and with the same descriptions.

Event ID 513 can also appear regarding to a PXE provider error: “An error occurred while trying to initialize provider WDSPXE from C:\Windows\system32\wdspxe.dll. Windows Deployment Services server will be shutdown”. This particular error could happen for several reasons, like installing on the same server a System Center Configuration Manager PXE provider that replaces the WDS.

Possible Reasons

Those particular errors appeared when there were changes on Active Directory that did not were performed smoothly:

- Changing a Global Catalog from Domain Controller.
- Shutting down an active Domain Controller.

Solution

To solve this, you need to insert manually the FQDN of the domain controller working as a Global Catalog.

1 – Open the WDS snap-in and access server properties.

2 – Click on "Advanced".  And you should see the following:

3 - Insert the FQDN of a Domain Controller and the Global Catalog nearest to WDS and currently active (preferred in same site). Most likely will be the same DC on both options.

4 – Start the WDS Server.

More Background about WDS and Active Directory Integration

The PXE provider delivered with Windows Deployment Services is called BINL (implemented in Binlsvc.dll) and has a direct integration with Active Directory services in many ways:

• BINL prefers to use domain controllers and global catalogs that are available within the same Active Directory site as the PXE server (local).
• A writeable domain controller for the domain where the Windows Deployment Services PXE server resides will be leveraged when querying for selected attributes.
• The WDS PXE provider uses the DSGetDcName() API. It passes the DS_GC_SERVER_REQUIRED flag whenever it needs to locate a global catalog.
• When attempting to locate computer account objects, the default search order is for BINL to search global catalogs before searching domain controllers.
• And of course, BINL connects directly with AD when trying to create Computer objects within the domain; or querying for other attributes.

Example of BINL handling PXE requests and integrating with AD

For more info, check "Deploying and Managing the Windows Deployment Services Update".

Hope it helps!

Cheers!

If want to learn about troubleshooting wds then go through the testking 642-873 tutorials and testking 70-291 study guide for complete information and become IT expert using testking 70-432 training products

Note: All of the data about the components and values used on these two XML files, are explained on Part III about WDS Deployment.

WDSClientUnattend

Download example here.
(Change file extension from .doc to .xml to start using it or you can still open it as a Word file).

Part of WDSClientUnattend.xml

AutoAttend

Download example here.
(Change file extension from .doc to .xml to start using it or you can still open it as a Word file).

Part of AutoAttend.xml

Hope that you find it useful!

Cheers!

Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part I)

Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part II)

Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part III)

For those using Windows Server 2003 SP1, we reviewed that among the requirements for WDS installation there was installing Windows Automated Installation Kit. This kit also gives us an important tool for the unattended files creation, the Windows System Image Manager.

So, it’s recommended for any other platform used on WDS to download this kit and install the System Image Manager. This tool it’s not a requirement for creating the unattended files.

Installing WAIK

Preparing the Files Using System Image Manager

System Image Manager provides us the way to, using the .wim (or .clg) file for an installation, select the components that are necessary within the answer files. This way we can be sure that the answer options selected are used on the right place at the right time:

1. Open System Image Manager for Start Menu.
   

2. Click on File and click on Select Windows Image.

3. Select the .wim file that we previously created or just use the file from the installation media (install.wim).

   1. You can also select the catalog files (.clg): these are the specific files for each Windows Vista version (Home Ed, Enterprise, Ultimate, etc).

4. To start creating, on the File menu select New answer file.

Adding a .wim or .clg files is not a requirement, but you won’t be able to validate or check the errors on unattended files that is not using an OS image as a reference.

For more information, visit the site Windows System Image Manager Technical Reference.

We’ll create two files that are necessary for a complete unattended image installation: WDSClientUnattend.xml and AutoUnattend.xml.

Note: All of the components that we’ll add here are associated to 32bit images because the installation file selected has that architecture. If we uploaded a 64bit image, you’ll see an answer file with x64 components.

WDSClientUnattend

Download WDSClientUnattend.xml example here.
(Change file extension from .doc to .xml to start using it or you can still open it as a Word file).

This is the first file used by WDS to respond to all the first configurations on the Windows PE: Disk partitions (creating, modifying) and selecting the image from WDS that we are going to install.

As you can imagine, all the components that we will add will go on Windows PE cycle:

• x86_Microsoft-Windows-International-Core-WinPE_6.0.6000.16385_neutral\
  SetupUILanguage

• x86_Microsoft-Windows-Setup_6.0.6000.16385_neutral\DiskConfiguration\
  Disk\CreatePartitions\CreatePartition

• x86_Microsoft-Windows-Setup_6.0.6000.16385_neutral\DiskConfiguration\
  Disk\CreatePartitions\ModifyPartition

• x86_Microsoft-Windows-Setup_6.0.6000.16385_neutral\DiskConfiguration\
  ImageInstall\OSImage\InstallTo

• x86_Microsoft-Windows-Setup_6.0.6000.16385_neutral\DiskConfiguration\
  WindowsDeploymentServices\ImageSelection\InstallImage

• x86_Microsoft-Windows-Setup_6.0.6000.16385_neutral\DiskConfiguration\
  WindowsDeploymentServices\ImageSelection\InstallTo

• x86_Microsoft-Windows-Setup_6.0.6000.16385_neutral\DiskConfiguration\
  WindowsDeploymentServices\Login\Credentials

Here’s an example of all the components and values that can be inserted on the answer file. On the values I have set in here I’m doing the following:

- Setup and keyboard language: English
- Delete and create a single NTFS partition on root disk.
- The partition will take the complete size of the HD.
- Label: system.
- Installation Group: VistaInstallation. This is the group that we created when we uploaded the image.
- File: Install.wim. This is the name of the installation file that we uploaded.
- Image Name: This is the description name that we used on the installation that we uploaded.
- User and domain name that will be used to login and choose available images. No higher privileges needed on the user.

To confirm that the answer file has no errors, click on Tools and Validate Answer File. All the errors will be displayed and explained on the lower panel.

Once the file is validated click on Save and use the name WDSClientUnattend. This file must be stored inside the folder of installation files created by default: /RemoteInstall/WDSClientUnattend.xml

AutoUnattend

Download AutoUnattend.xml example here.
(Change file extension from .doc to .xml to start using it or you can still open it as a Word file).

This is the file that we are using to answer all the Vista configurations: Product key, computer name, domain joining, local users and passwords, etc.

The components that need to be added are the following:

Cycle 4: Specialize

• x86_Microsoft-Windows-Shell-Setup_6.0.6000.16385_Neutral

• x86_Microsoft-Windows-UnattendedJoin_neutral\Identification\Credentials

Cycle 7: OobeSystem

• x86_Microsoft-Windows-International-Core_6.0.6000.16385_Neutral

• x86_Microsoft-Windows-Shell-Setup_6.0.6000.16385_Neutral\OOBE

• x86_Microsoft-Windows-Shell-Setup_6.0.6000.16385_Neutral\Themes

• x86_Microsoft-Windows-Shell-Setup_6.0.6000.16385_Neutral\UserAccounts\AdministratorPassword

• x86_Microsoft-Windows-Shell-Setup_6.0.6000.16385_Neutral\UserAccounts\
  LocalAccounts\LocalAccount\Password

Here’s an example of the values selected:

- ComputerName: If you set the value “*” on the computer name will be selected randomly (using RegisteredOwner value).
- The user name inserted in “Credentials” will be the user that will join the computer to the domain. No higher privileges needed for this user, but remember a normal user can only join 10 computers to the domain.
- ProtectYourPc: If 1 establishes that the updates will be automatically downloaded and installed.
- LocalAccount: User added here will be created locally and in this example is also member of the Administrators group.

To confirm that the answer file has no errors, click on Tools and Validate Answer File. All the errors will be displayed and explained on the lower panel.

Once the file is validated click on Save and use the name AutoUnattend. You can locate this answer file on any folder.

Note: A good thing about System Image Manager is that for each component that you have here, you can access to the description of it. If you have any doubt on the values that you are placing, take a look to the help file.

Associating Unattended Files

Now that we have the both files necessary, all we need is to associate each file to the images we are going to install:

1. Associating WDSClientUnattend.

a) Open the WDS console on your server.

b) On the servers listed on the snap-in, right click on the server name and select Properties.

c) Open Client and select Enable Unattended Installations.

d) According to the architecture where you created the image, browse for the WDSClientUnattend.xml file.

2. Associating AutoUnattend

a) On the Installation Images, open VistaInstallation.

b) Right click on the image that you uploaded and select Properties.

c) Select the option Allow image to install in unattended mode.

d) Click on Select File and browse for AutoUnattend.xml.

And there you go; you have the complete environment to install full and unattended images of Windows Vista.

You have to remember that at the moment of booting a client machine, once you’ve selected the WindowsPE image to boot, the complete installation process will not require any user intervention. If you have to select on clients different disk options or partitions, you can deselect the option where you choose the WDSClientUnattend file; with this you’ll get to manually introduce any changes on image selection and disk management.

Common Issue on x64 images and WDS

I’ve encountered that there are some scenarios that the 64bits images are not available for selection on a deployment, even though you have correctly uploaded to the WDS Server and the client supports x64 architecture.

The problem is that when the client connects to the WDS Server (soon after you pressed F12 to boot from the network) it doesn’t notify that it is x64 compatible client. And for the server, the client is just x86 compatible and the rest of the images do not apply for it.

To solve it:

1. Open a cmd on the WDS Server

2. Insert WDSUTIL /set-server /architecturediscovery:yes

And the next time any client contacts the WDS Server, will first notify about if is x64 compatible.

Hope you find this guide useful.

Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part I).
Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part II).

Cheers

There are two main steps to take and complete a full image and unattended deployment:

1. Creating the base image to deploy: OS, programs and other special configurations + uploading it to the WDS server.

2. Making an unattended file to be used with that image.

Creating the Base Image

Note: On this series of posts we are only considering to deploy Windows Vista or Windows Server 2008 images. The files used on WDS Native mode as unattended files are only valid to those operating systems, if you want to make unattended deployment with Windows XP or 2003 OS; you will need to use RIS or WDS Legacy Mode.

The first step it’s pretty simple, it consists on installing the operating system with all the features, programs and configurations that you want. But there are some considerations first:

After you complete the image, there’s a process where you release all the specific data involving the computer where it’s installed, like the Security Identifier (SID), computer name, etc. Here are some of the things that the image won’t keep after the release process:

· Computer name
· Owner and Company name
· SID
· Domain or workgroup membership
· TCP/IP Settings
· Regional and keyboard settings
· Specific hardware drivers. This refers to specific computer hardware, like video or audio drivers. But if you only applied drivers used on the Windows installation, the same will apply for the deployment, but any other external driver installed will be unavailable.
· Any saved network connections (wireless networks saved)
· OS product key. This is an important note, since no matter if your product has been activated; the key is reset after this process.

But here are some of the things that are kept after this release process:

· Programs and features installed (pretty obvious to say that at this moment right?)
· Local Users and Groups created.
· Product Keys used for programs installed. Meaning if you have Microsoft Office installed, the key used will remain as the same on the deployments.
· Windows updates installed
· User Profiles: Since all the profiles configuration are basically data stored on the Users folders, all that information will be uploaded within the image.
· Printers installed.

All the uploading process is made from the client side; but we must first prepare the WDS server to be ready to receive images.

First, we are going to add a boot image that will be specially to capture operating system images.

1. Go to WDS Console and let’s upload a second boot image; it can be the same that we added on the first post using the boot.wim from a Vista or Windows Server 2008 media.

2. Instead of naming it Windows PE, use a name like “Image Capture”.

3. After the process completes, right click on the image you just added and select “Create Capture Boot Image”

Now we have set our WDS server, let’s prepare the client using the sysprep tool and upload the image:

1. On the Vista or Windows 2008 client open a “cmd” as administrator and insert “cd c:windowssystem32sysprep”.

2. Run “sysprep /oobe /generalize /reboot”.

This process will require for a few second and after it completes the OS will automatically reboot.

3. Soon as the machine is rebooting, press F12 to select different devices to boot.

4. Select to boot from the network card connected to the LAN

Now the client is communicating with the DHCP server to require an IP and a boot image, the DHCP will forward the request to the WDS. You will be prompted to press F12 one more time.

5. Since we have two boot images, let’s select “Image Capture”

The boot image will start to load.

6. A image capture wizard will start, click on “Next”

7. Now let’s select the volume we want to capture, in our case C:. And put a name for the image that will be uploaded as long with a description.

It’s important to note that if the sysprep process did not completed properly no volume will be available to select.

8. On the next window you must select where the .wim file will be temporary stored locally. Select to keep it on the root C: (this file it’s not uploaded within the image).

9. Select the option “Load the image to a WDS server”; put the name of the server and click on “Connect”

10. You will be prompted with credentials, use a privileged account on the domain or local administrator account of the WDS server.

11. Now select the image group name where you want to store the new image and click on Finish.

Here the process of the image compression and preparation starts, this could take several minutes (~30 mins to ~1hr) depending on the image size and the hardware involved. After this process, the image is uploaded to the WDS server.

After it completes, check on the WDS console, the image should be uploaded and ready to be deployed.

Still we have not configured any unattended file, so the image can be deployed but the entire OS configuration should be entered manually, like on normal OS installation but all the programs will be installed.

For the unattended files preparation and configuration take a look to the third post of WDS.

Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part I)
Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part III)

Cheers!

Introduction

Deploying operating systems it’s always a hard thing to do. Annoying, uncomfortable, but necessary for every environment. Why? Because every desktop computer on every organization has their own life cycle (even servers, a longer one, but cycle at last).

Even if your organization doesn’t have many desktops and even if those desktops don’t seem to need an image refresh in several months; the dynamics of today’s technology makes your base operating systems to change: Updates available, service packs, a new version of your organization’s software, newer operating systems, etc. And don’t forget the consequences of any user’s intervention: overloading the hard drive, personal software installation, etc; transforming always into a need to a fresh new installation. No need to keep enumerating things that normally happens; you probably know all of them.

Common Base Image Life Cycle

The bottom line is that a good and automated system to deploy your full operating systems images will significantly (and I do mean significantly) improve your daily tasks: Making an awkward job of following the installations steps for maybe 2 or 3 hours and transforming it to 30mins of a complete unattended provisioning. Here’s where Windows Deployment Services comes to play.

First of all I want to thank a friend of mine, Leonardo, who made a great “How To”, in Spanish, for WDS with Windows Server 2003 SP1, here’s the link to see it. Also you can find the Microsoft document “Deploying and Managing the Windows Deployment Services Update on Windows Server 2003”.

Requirements

- Windows Server 2008 or Windows Server 2003 SP2 * for the WDS server .

- Active Directory and DNS up and working.

- DHCP server available and authorized by Active Directory on your network. Linux DHCP servers do not need to be authorized by AD.

- On the client side: NICs PXE compliant.
Almost all of Network Adapter that are available for several years now are in fact PXE compliant, so I think you don’t have to worry about that.

(Optional) And if we want to create our own unattended files:

- Windows Automated Installation Kit (WAIK).
We will use of this kit the Windows System Image Manager to create our Unattended Files for installation. Here’s the link to download the DVD image for installation.

Hardware Requirements

- Processor: No special specs on processor characteristics, but of course to WDS work properly you will need a Pentium III 800 MHz or higher.

- Memory: 256mb minimum.

- HD: Recommended 30 GB of free space on the disk that will be used for images storing.
It always depends on the images amount of images you will use to deploy. For example, I have over 5 full Vista images (meaning operating system, Office 2007 and several other applications) and less than 10 GB of disk space used.

Installation

To install WDS on a Windows Server 2003 SP2 you only need to add the component from “Add or Remove Programs”

To install it on Windows Server 2008  it is practically the same procedure, just add the Windows Deployment Services role from the “Add Role Wizard“. After that, all the configurations tasks are the same, since it is the same snap-in; and you’ll get bonus options using WDS on W2K8, like multicasting transmissions. I’ll comment this on the next posts.

* To install Windows Deployment Services on Windows Server 2003 SP1 first you must install the “Remote Installation Service” (RIS) component, you will not need to configure anything special with this component. After that, you have to use WAIK media: in the options you will find the Windows Deployment Services for installation.

Configuration

Once installed, access the “Windows Deployment Services” snap-in.

On the console, to get started right-click on the listed server and select “Configure Server”.

Here are the considerations you need to have to configure your server properly.

Configuring the Server

- After you selected the folder where you are going to store all the images for WDS, you need to check on the DHCP settings. The wizard will explain you about this option.

Since in my example I have a Microsoft-DHCP Server working on a different server from the WDS, these two options will remain unchecked. If you have both, WDS and DHCP, on the same server you should check both options.

- Response Configurations: This is where you set to which clients you will respond when you receive a PXE request.

The difference between known clients and unknown is set on if the Computer Object exists on Active Directory.

If you want to create the computer objects before running WDS on that computer, you should have the GUID of that computer and include that information on the computer object. When you create the object on Active Directory, using “Active Directory Users and Computers” you need to set that “This is a managed computer” and insert the GUID.

Selecting this option can be really annoying if you want to improve your deployment, because you have to add the object first on Active Directory every time that you want to deploy an image, but it’s of course the more secure option to apply.

Or you can use the option “For unknown clients, notify administrator and respond after approval”. With this option, all the unknown clients that request to boot from PXE will appear to you in“Pending Devices” on your console, from there you can approve or decline them.

Or simply use the option “Respond to all (unknown and known) computer clients” and when you don’t need WDS, you can just stop the service to avoid any rogue clients.

On the final step of the wizard, select to start adding images now are we are ready to go!

Adding Boot Images

Before creating a complete image to be deployed with WDS, we need to add first a Windows Pre-Installation image (WindowsPE). With this image we provide the server with a pre installation environment needed for all installations. WindowsPE comes, as all the new operating systems, in a WIM format, included in the Vista or Windows 2008 installation media.

1 - To add the image, expand the server options on the console and on the “Boot Images” select “Add Boot Image”. Remember that this WindowsPE that we are adding will be the same for all the operating systems that we are going to use with WDS.

2 - Select “Browse” and check on the Vista or Windows 2008 installation media for the folder “Sources” and the file “boot.wim”. This is our WindowsPE.

3 - Select the name for this image and click on “Next”

Note: You can also use, of course, the x64 WindowsPE. Will be discussing it later.

4 - Review the summary and click on “Next”.

And now the Windows Pre-Installation Environment is available to boot from your network.

A clean Vista installation?

The procedure to add a clean Vista installation to WDS it’s pretty simple and practically the same procedure as for the boot image. As a good practice you should always have a clean Vista installation available on your server, here are some reasons:

1 – The unattended files that you may use on full images deployment also apply to clean installations.
2 – WDS use a smart storage method, which does not duplicate any installation files. Meaning that if you save a clean installation of Vista and you add later a full Vista image with several applications included, all the new information that is stored are the differential (delta) files between those two.
3 – Rearm activations: If you use the command line “slmgr –rearm” on the Vista installations to reset back your grace period back to 30 days, you should know that Vista only allows 3 times to run this command. But when you deploy a full image, the times that you can run this command line reduces according to the time when the image was created. But using the clean WIM file extracted from the Vista media, does not have that drawback when you run the rearm command.
4 – Having a clean installation always available that you can deploy any time will help you when you need to make changes to the default installation image or when you need to start a new one from the scratch.

Here are the steps (again, you have to use the Vista installation media):

1 – On the WDS console, right click on “Install Images” and select “Add Image Group”

2 – Select the name that you are going to use for this group. For Example: VistaInstallation.

3 – Right click on “Install Images” again and select “Add Install Image”. When the wizard starts select to use the group you’ve just created and click “Next”.

4 – On the next window, browse the Vista media for the folder “Sources” and select the file “install.wim” and click “Next”

5 – Since the Vista installations always include all the versions on the same file, we should select only the one that apply for our case. In my case, Windows Vista Ultimate. Click “Next”

6 – On the summary window click “Next” and the image will start to upload to your server.

At this point we have all the necessary components to deploy a clean image for Vista from the network; but the installation remains attended. So, the disk configuration and the Vista options (language, product key, computer name, etc) still need to be manually inserted.

We’ll be reviewing in the next posts a complete unattended installation for Windows Vista and also making a personalize installation of the operating system.

Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part II)
Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part III) 

Cheers!