Step-by-Step: Adding Hyper-V Integration Components to Windows PE using WAIK 2.0 Tools
February 28, 2009 at 12:55 pm | In Hyper-V, Microsoft Deployment Toolkit (MDT), WAIK, Windows Deployment Services (WDS) | 6 CommentsTags: Hyper-V, Injecting Drivers, Microsoft Deployment Toolkit (MDT) 2010, WAIK, Windows Deployment Services (WDS)
For those that have been using Windows Automated Installation Kit (WAIK) 2.0 released recently (download link here) or using Microsoft Deployment Toolkit 2010 Beta 1, that works only with WAIK 2.0 (check these articles of mine about MDT 2010: Post I, Post II and Post III); maybe you’ve noticed that the management tools that were included with WAIK 1.1 (and 1.0) disappeared in this new version.

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" /forceunsigneddism /image:"C:\Temp\mount" /add-driver /driver:"C:\Temp\source\drivers\amd64_wvmbushid.inf_31bf3856ad364e35_6.0.6001.18016_none_4ccff81064c7c78f
\wvmbushid.inf" /forceunsigneddism /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!
Troubleshooting WDS: Event ID 257 – 258 – 266 – 513
January 14, 2009 at 12:58 pm | In Windows Deployment Services (WDS) | 4 CommentsTags: Troubleshooting, Windows Deployment Services (WDS)
Windows Deployment Services depends and works directly with Active Directory and DHCP, meaning that if any of those two servers are significantly modified, then probably you will not be able to start the WDS service and get the events ID:
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!
Windows Deployment Services (WDS): Unattended Installation Files Examples
January 10, 2009 at 5:33 pm | In Windows Deployment Services (WDS) | 1 CommentTags: Image Deployment, Unattended Files, Windows Deployment Services (WDS)
After completing three posts about unattended deployment of full operating systems with WDS (Part I, Part II and Part III), I had pending this post about the examples of the unattended files. So here they are.
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)
Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part III)
December 12, 2008 at 7:01 pm | In Windows Deployment Services (WDS) | 12 CommentsTags: Image Deployment, Windows Deployment Services (WDS)
At this point we’ve already installed and properly configured Windows Deployment Server on Windows 2003/Windows 2008 (Part I); and we created a full image (programs and features installed) on our Windows Vista and uploaded it to the server (Part II); the only thing missing is creating the answer files that will be used on the images to achieve the full unattended installation of our operating system.
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:
-
Open System Image Manager for Start Menu.

-
Click on File and click on Select Windows Image.
-
Select the .wim file that we previously created or just use the file from the installation media (install.wim).
-
You can also select the catalog files (.clg): these are the specific files for each Windows Vista version (Home Ed, Enterprise, Ultimate, etc).
-
-
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
Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part II)
December 12, 2008 at 6:46 pm | In Windows Deployment Services (WDS) | 13 CommentsTags: Image Deployment, Windows Deployment Services (WDS)
Ok then, after completing the first configurations made on the Part I of this guide we can perform a clean but attended network installation of Windows Vista.
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!
Installing and Configuring WDS (Windows Deployment Services): Full Images Deployment (Part I)
December 12, 2008 at 6:41 pm | In Windows Deployment Services (WDS) | 12 CommentsTags: Image Deployment, Windows Deployment Services (WDS)
I’ve prepared a complete guide to configure a WDS Server on Windows Server 2008 or Windows Server 2003 to deploy complete operating systems images, this is the first part. In this post I’ll be setting the WDS requirements, installation, first configurations and images needed.
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!
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.

Computer geek, totally fan of the latest's IT platform solutions. Since 2006 I've been mentioned as Microsoft Student Partner, I continue working with them, collaborating on different academic and technological events. On this blog, you'll find most of the experience I have evaluating, designing, implementing and managing those technologies.

