How to Deploy Hyper-V Hosts with Windows Deployment Services

You can find any number of ways to deploy physical systems. Once upon a time, I enjoyed the process of starting with install media and going through all the motions to get a completely fresh environment. Who doesn’t like that new operating system smell? But, I haven’t got that kind of patience anymore. Even if you do, sometimes you need to need to deploy too many systems to use any media method. Sometimes you just get bored of it and want to get it over with. Out of all the techniques that I’ve tried, I always return to Windows Deployment Services (WDS). Some of the other options appear to offer more (like VMM), but they invariably promise more than they deliver. WDS produces consistent, repeatable, reliable results.

This guide is part of a 2-part series. The other guide focuses on How to Deploy Hyper-V Guests.

Applicability of this Article

WDS applies more or less universally to all Windows Server deployments. If a book doesn’t already exist on WDS, a very long one could be written. This article makes no attempt to cover the entire topic. Later on the page, you’ll find a “Choosing a WDS Deployment Style” heading that goes into some detail on the options that are available to you. A quick intro of my intent for this article:

• How to use a single physical system to build a source image that can then be redeployed to other hardware of the same type.
• How to capture an image of a single physical system to build a source image that can really only be redeployed back to the same system. You can also use this technique to convert a system between BIOS and UEFI mode — which also means switching a Hyper-V guest from Generation 1 to Generation 2 or vice versa.

This article will not cover how to create a completely generic image that can be deployed to any system. I’ll tackle that topic in an upcoming article on using WDS for Hyper-V guests.

Even though I’m tying all of this to Hyper-V, that’s certainly not the limit of WDS or any of these techniques. I focus on Hyper-V because I believe that most Hyper-V deployments are done the hard way and then needlessly protected by backup. WDS makes the whole thing easier. You can deploy a new host in a few clicks. If you lose a host, you can redeploy it from WDS and restore guests from backup more quickly than you can muck through a bare metal restore or a new install from media.

Warning: If you place your virtual machines on the C: drive, I would avoid using this method to capture an already-deployed Hyper-V host. The entire contents of the C: drive are included.

Prerequisites for Windows Deployment Services

I find WDS easy to set up and configure, although it may not look that way at first glance. You’ll need a few things to get started.

• A Windows Server GUI system. I don’t believe that WDS works on Server Core at all. You can manage it remotely using RSAT (Remote Server Administration Tools) but only from Server SKUs. Windows 10 RSAT does not contain the WDS tools.
• An Active Directory domain that contains the WDS system and the Hyper-V host(s). WDS can work without a domain, but people who choose workgroup mode prefer doing things the hard way. I don’t want to ruin anything for them by providing a how-to.
• Enough local storage on an NTFS volume to hold at least one installation image. The system running WDS must be able to access the storage location through a drive letter. WDS is not cluster-aware, so I recommend that you avoid CSVs.
• A DHCP system. I only use Windows-based but it would be possible to use others.
• Install images for Windows Server and/or Hyper-V Server. You can start with physical media or downloaded ISOs.
• Every system that will receive an image from a WDS server must be PXE-capable. Your network infrastructure must allow PXE booting.

Installing Windows Deployment Services

Windows Deployment Services ships as an innate role of Windows Server. I will be demonstrating on WS2016. All currently-supported versions provide it and you follow nearly the same process on each of them.

1. Start in Server Manager. Use the Add roles and features link on the main page (Dashboard) or on the Manage drop-down.
2. Click Next on the introductory page.
3. Choose Role-based or feature-based installation.
   
4. On the assumption that you’re running locally, you’ll only have a single server to choose from. If you’ve added others, choose accordingly.
   
5. Check Windows Deployment Services.
   
6. Immediately upon selecting Windows Deployment Services, you’ll be asked if you’d like to include the management tools. Unless you will always manage from another server, leave the box checked and click Add Features.
   
7. Click Next on the Select server roles page and then click Next on the Select server features page (unless you wish to pick other things; no others are needed for this walkthrough).
8. You’ll receive another informational screen explaining that WDS requires further configuration for successful operation. Read through for your own edification. You can use the mentioned command line tools if you like, but that won’t be necessary.
9. You will be asked to select the components to install. Leave both Deployment Server and Transport Server checked.
   
10. Click Install on the final screen and wait for the installation to finish.

You’ve finished the installation portion.

Initial WDS Configuration

Under Administrative Tools on the WDS host (now further named “Windows Administrative Tools” on the Start menu in Server 2016), you’ll now find Windows Deployment Services. Open that up to begin initial WDS configuration.

1. Right-click on the newly installed server (it will have a yellow triangle overlay icon) and click Configure Server.
   
2. The initial wizard screen discusses the prerequisites. It mentions a DNS server, which I neglected to mention. That’s because I only work with Active Directory systems, and you can’t AD without DNS.
3. On the next screen, choose Integrated with Active Directory.
   
4. Choose a location to store the images that this server will deploy. The location that you specify must be accessible via a drive letter that’s local to the WDS system. The wizard will automatically create a REMINST share on the specified folder to make it available to deploying systems.
   
5. Choose the client response action. If you’re not sure what to pick, don’t worry. You can easily change this option later.
   1. Do not respond to any client computers. You could set this option to give yourself more time to configure the server.
   2. Respond only to known client computers. This option requires the most hands-on management. You must determine the hardware ID of computers that this host will respond to and configure them in Active Directory. I’ll show you how to do that in a moment. If you use Active Directory-Based Activation or KMS and you can’t isolate your PXE network, this setting ensures that your licenses aren’t given to unauthorized systems.
   3. Respond to all client computers (known and unknown), with optional Require administrator approval for unknown computers. This option can be dangerous but reduces administrative effort. Even if you aren’t using automatic key deployments and/or can limit the scope of PXE booting to secured networks, I still recommend that you set the Require administrator approval option. If WDS deploys to a computer without a pre-staged account, it gets a generic name and gets placed in the domain’s default computer OU. That requires even more busy work to clean up than the other choices.
      
6. WDS will perform configuration.
   
7. The final screen allows you to jump into image selection. I avoid this option because it’s not the same process that you’ll use with an active WDS server. If you choose to do so, then you will need to provide the path to a location that contains an operating system’s boot.wim and install.wim.
   

Now your WDS system can listen for and respond to PXE requests, but doesn’t know about any clients and doesn’t have anything to deploy.

Choosing a WDS Deployment Style

WDS applies to far more than Hyper-V, and I can’t possibly cover all possible options. I’m going to narrow the operational scope down to two operating systems: Hyper-V Server (the thing that everyone calls “Hyper-V Core”) and Windows Server with the Hyper-V role. I’m not going to make any distinction here between Core or GUI mode for Windows Server. My demonstrations will be for Windows Server with Hyper-V with a full GUI. You’ll follow essentially the same directions no matter which of these you choose. You can also go back later and add in any of the others if you want to have more options.

You have a larger decision to make, though. Do you want to use completely generic images or do you want to retain a customized image for your hyper-v hosts?

The Case for Generic Images

Most WDS installations that I’ve encountered make use of generic images. Essentially, you simply provide unmodified WIM files directly from Microsoft’s original deployment media. This approach provides multiple benefits:

• It’s what everyone does. I’m generally resistant to the bandwagon effect, but anyone that has any experience with WDS will instantly understand your environment if you stick to generic images. If you get stuck, other people will have an easier time helping you if you use generic images.
• WDS allows you to build out separate driver package groups to match up with physical systems. Driver variances are a big reason that people resist centralized deployment systems. WDS solves most of that problem while still allowing you to use generic images.
• Maintenance is simpler.

The Case for Specific Images

I use machine-specific images in my lab quite a bit. I’m on the fence about doing anything like this in production, although it certainly has some appeal.

• It works like a checkpointing system for a physical box. You can break the machine and then revert it to almost exactly the same previous state. It’s not very fast, but no worse than any other bare metal technique that I’ve used.
• For systems that don’t change, it’s a semi-backup.
• You can convert a system from BIOS mode to UEFI mode and from UEFI mode to BIOS mode. Incidentally, it also means that you can freely convert from a Hyper-V Generation 1 VM to a Generation 2 VM and back again.

Mixing it Up

To a degree, you can have your cake and eat it, too. WDS doesn’t care how many separate images it stores. You can build all the different deployments that you want and prop them up to your heart’s content. As long as you can keep them all straight, then everything will be fine.

You can also build a reference system and then store it as a generic image. I often use this approach to get around some limitations. WDS relies on WIM images, which can accept some types of drivers, applications, and updates, but not all. If I need a package that can only be installed to a live system, then I start with a live system. Keeping those applications updated can be challenging, but it’s usually better than rebuilding a server from media.

Creating WDS Boot Images

You create WDS install images differently depending on the desired outcome. However, all methods depend on one single root: you require a boot image. Boot images are small start-up stubs that take the hand-off from PXE to start up a computer. In the case of WDS, a boot image should match the operating system it will deploy. You can obtain one easily.

1. Just find the DVD or ISO for the operating system that you want to install. Look in its Sources folder for a file named boot.wim. That’s what you want.
   
2. On your WDS server, right-click the Boot Images node and click Add Boot Image.
   
3. On the first page of the wizard, browse to the image file. You can load it right off the DVD as it will be copied to the local storage that you picked when you configured WDS.
   
4. You’re given an opportunity to change the boot image’s name and description. I would take that opportunity because the default Microsoft Windows Setup (x##) won’t tell you much when you have multiples.
   
5. You will then be presented with a confirmation screen. Clicking Next starts the file copy to the local source directory. After that completes, just click Finish.

Your boot image will then appear in the list in the right pane.

 Linking Systems to Active Directory Accounts in WDS

This section is technically optional. If you follow this part, new systems will deploy with a computer name that you select and into the Active Directory OU that you select. If you skip this part, computers will deploy with a generic name into the default OU (usually Computers). I always use these steps to pre-stage my computer accounts and then leave them linked.

1. 1. Gather the system’s BIOS UUID.
      1. If it’s a Windows system and it’s already deployed, you can collect its UUID from an elevated PowerShell prompt with: gwmi Win32_ComputerSystemProduct | select UUID.
      2. If it’s a Linux system and it’s already deployed… well… you can’t push Linux with WDS so this article is probably not very helpful for you. But you can still get its BIOS UUID by installing the dmidecode package from your distribution’s repository and running: sudo dmidecode -s system-uuid.
      3. If the system is physical and not yet deployed, you can set it to boot to PXE and start it up. When you see something like the following, record the GUID:
         

         PXE GUID

      4. If the system is a Hyper-V guest and not yet deployed, you can extract its GUID using WMI. That’s non-trivial enough that I wrote an entire script to not only extract the UUID but to update an Active Directory computer account with it. If the Hyper-V VM in question was copied from another, then it likely has an identical UUID which will cause problems. I have a PowerShell script and an EXE utility that will allow you to modify the UUID.
      5. If the system is a guest on another hypervisor, search for a technique to determine the UUID. You can usually try the PXE method with a VM as well.
   2. Decide on a name for the system, if you don’t already have one in mind/in production. If it doesn’t already exist, create that computer account in Active Directory in the desired OU.
   3. On the computer account’s properties sheet in Active Directory Users and Computers, switch to the Attribute Editor tab.
   4. Double-click the netbootGUID item. Leave the drop-down on Hexadecimal. Paste/type in the UUID without spaces or dashes.
      
   5. If you look at it in the list, it will have reversed a bunch of the characters. I don’t know why it does this, but that’s how WDS works:
      
   6. In WDS, click on Active Directory Prestaged Devices. You should now see your new/updated device on the list. Double-click it to check the UUID. If it’s incorrect, just paste over the correct UUID. You don’t need to worry about braces or dashes; it will figure it out. You can’t use spaces, though. Remember that when you open it, WDS will have reversed several of the characters. Don’t try to make it stop. If you succeed, it won’t match when it boots.
      
   7. Switch to the Boot tab. Set the PXE mode to whatever suits you; just make sure that you pick something that allows you to start in PXE mode or you’ll have trouble following the rest of this article. Select a boot image or it won’t work at all.
      

WDS does include an Add Device “wizard”. It’s not very smart, though. You need to know the distinguished name (DN) of the target OU. That’s not tough. But, you can only use it to add devices. You can’t work with systems that exist in the directory but don’t have their netbootGUID property set. If you install ADUC on the WDS system, then it injects a new dialog into the new computer account wizard. That dialog allows you to set the GUID more easily but doesn’t let you set the boot.wim. The way that I showed you is a bit clumsier, but it’s easier overall and universally applicable.

Preparing a System to use as a WDS Image

In this article, I will cover the creation of hardware-specific images. It will include images that are locked to a single computer and images that apply to any computer of that type. I will save a discussion on completely generic WDS image creation for an article on using WDS to deploy virtual machines.

1. Plan what you want in your image beside Windows Server. Consider:
   1. Roles and Features (including Hyper-V)
   2. Software packages — updating these will be a chore, but is that worse than needing to install fresh on a new server build? That question isn’t rhetorical. You need to decide.
   3. Drivers — same as software packages, but with a twist. Some driver packages can be automatically applied by WDS during deployment
   4. Dormant files — BIOS updates, automated scripts, etc. These sorts of things can also be pushed into a WIM
   5. Make sure everything that you want to keep is/will be on the C: drive. Each indexed image in a WIM file can only contain one file system layout. Make sure that anything that you don’t want to keep it off of/will not be placed on the C: drive. For instance, if you’re capturing an existing Hyper-V host, don’t leave any VMs on it (unless you really want them in the image…?).
2. Install the system and get it exactly the way that you want it to be saved. Domain membership state doesn’t really matter, but later steps will be easier if it’s in the domain.
3. Decide now if you want it to be completely generic or locked to this specific piece of hardware.
   1. If you want it to to be locked to this piece of hardware, you’re done with this section.
   2. If you want it to be genericized for all computers of the same hardware type, open an elevated command prompt and run: C:Windowssystem32Sysprepsysprep.exe /generalize /oobe /shutdown.
4. You need to be able to access the computer’s console, whether physically or by some out-of-band technique, to proceed.

Pick one of the following two paths to take, depending on what you chose in step 3.

Capturing a Specific System for WDS

I need to be very clear about what we’re doing: we are capturing the image of a system as it is currently installed and saving it for WDS to redeploy back to the exact same system at a later date. This is uncommon, atypical, nonstandard, apocryphal, frowned upon, side-eye-inducing, and generally weird. This is what I use for my lab Hyper-V hosts for a variety of reasons. If you later try to deploy it to another system… I don’t know what will happen. For Hyper-V virtual machines, I also use this when I want to make a Generation 1 VM into a Generation 2 VM. Sometimes I have to disjoin/rejoin the system after conversion, but the process has always worked well for me.

1. Decide how you will save the captured image: local disk, USB-attached disk, or network.
   1. For a local disk, you don’t have to do anything unless there is a reason that it wouldn’t load in the Windows Server repair console. It’s perfectly fine to have it write to its own C: drive even if you’re capturing the C: drive, provided that C: has enough room to hold a copy of itself. You’re just saving a file with the current contents of the partition; you don’t need a completely empty disk or anything like that. If possible, choose this route as it will be the fastest. You can boot the system normally and transfer the file over the network later if that’s its ultimate destination.
   2. For USB-connected storage, get the device at least ready. I’ve had some servers that wouldn’t boot at all if a non-bootable USB disk was attached anywhere. The disk needs to be formatted as NTFS and has enough room to hold the contents of C: in a single file.
   3. For a network target, you might need to load the network driver. I would plan for that to happen, as I’ve had a server auto-detect its network once but then at the next iteration, the same server would not.
      1. You could just have a disk ready (USB or CD or whatever) with the files on hand. You’ll need the raw .inf, .cat, and .sys files; an installer won’t work.
      2. If the system is booted into Windows, or another just like it, all you need to do is look at the currently-installed driver
         
      3. Look in C:WindowsSystem32DriverStoreFileRepository for a folder that starts with the same name as the driver’s primary file. If you want, you can copy the driver files out of that location to external media. If you’re going to be capturing from the same system, you’ll have an opportunity to load the driver right from that location later. Just make sure that you remember the driver’s file name so that you can find it.
         
2. At the system console, boot the computer to install media. You can use a DVD or follow the instructions in the first half of the linked article to create a bootable USB install disk.
3. When you get to the Install Now screen, click Repair Your Computer instead.
   
4. Click the Troubleshoot option:
   
5. Click Command Prompt.
   
6. Next, you need to determine which drive letter holds what you normally think of as the C: drive. I’m betting on D: or E:. Type dir e: and press [Enter]. You can also use DISKPART, which you’ll see a couple of steps down.
   
7. If that doesn’t work, go through the drive letters until you find it.
8. Now that you have your source, you need to determine your target.
   1. If it’s a local or USB-attached disk, you could scan drive letters like you did for the C: drive. You can also use DISKPART. Type diskpart and wait for the interface to load. Then type list volume and look at the output for the drive that you want to use, as well as the letter that’s assigned to it. exit when done (I don’t have an external USB so my output is underwhelming):
      
   2. If you want to use a network target, first check to see if you have an IP with ipconfig. If you get absolutely nothing, that’s because your network driver wasn’t loaded. If you got an IP, skip past these next sub-directions.
      1. Your goal is to run drvload with the .inf file for your network adapter. If you have it on external storage and know the drive letter/path, then drvload z:driverdriverfile.inf will have you on your way.
      2. If you don’t have it on external storage, then hopefully you took my advice in step 1 and know the local path for the pre-existing driver. Make certain to use tab completion, and load it with something that looks like this: drvload E:WindowsSystem32DriverStoreFileRepositorye1d65x64.inf_amd64_2de580a425dabd06e1d65x64.inf. You should be rewarded with a message that the driver loaded:
         
      3. Now you need to start the DHCP service: net start dhcp.
      4. You should find yourself with an IP. If you don’t, then it’s likely an issue with the DHCP server. If you haven’t got a DHCP server, then… all of this will ultimately be for naught anyway. If you just want to give it a manual IP: netsh int ipv4 set address “Ethernet” static 192.168.25.147 255.255.255.0 192.168.25.1 (substitute in a valid IP, mask, and gateway for your network, of course).
      5. Start the Workstation service so you can talk to an SMB server: net start workstation. I was not ever able to get DNS resolution to work. If you want to even attempt it, you’ll need to start the DNS client: net start dnscache
   3. Map a drive for the target. I was not able to use DNS on my system, so I went by IP: net use w:192.168.25.27System.
   4. You will be prompted for credentials. Remember to use DOMAINuser or credentials that are local to the target system.
      
9. At this point, you have your target. All of the hard work is done! Save your system’s image:

   dism /Capture-Image /CaptureDir:E: /ImageFile:W:SVHV02Capture.wim /Name:"SVHV02"

10. Relax, find something else to do. This will take some time.
    
11. You can now exit back to the previous screen when you can shut down or continue to boot into the already-installed environment.
12. The generated WIM file needs to be placed somewhere that the WDS server can reach it. I’ll cover adding images to the WDS server’s repository after I explain how to capture a generic image.

Once the image is added to the WDS server’s list, you can boot this server in PXE mode and reinstall the exact image that you just captured.

Capturing a System to use as a Generic Template in WDS

This section seems similar to the preceding section but has many differences. First and foremost, this practice is common. WDS has a built-in process for it, which might make things a bit easier. Primarily, the difference is the purpose of the captured image. You start with a specific system and turn it into a generic image. It’s useful when you have a particular hardware type — in my case, Dell PowerEdge T20s — and building an image directly from media will not suffice. For instance, you might need or want to have some pre-installed software that can’t be applied to an offline image.

You have two options. One is to sysprep the system and then follow the instructions from the previous system. The benefit to that route is that you have more options as to the location of the saved image. The second is to allow the WDS server to capture the image. That will place the image directly in the WDS server’s image repository, saving you a few steps. It also transfers the image over the network, which might not be optimal. However, WDS’s normal deployment mode is via network, so if it’s not good enough for capture, it’s probably not good enough for deployment, either.

Note: After doing this, UEFI (including Generation 2 VMs) may fail to boot to the WDS server. I followed the instructions posted by “jpdand” on the Microsoft forums to solve the problem.

To capture using the WDS server:

1. In WDS, start in the Boot Images section. Instructions for creating boot images were presented in an earlier section. Find the boot image for the operating system that you want to capture. Right-click it and click Create Capture Image.
   
2. Give the boot image an obvious name. Save it to a location outside the normal WDS tree because it will first create a clone of the image and then import it back into the store… don’t ask me why it can’t do it all at once.
   
3. WDS will take a few minutes to build the image. When it completes, check Add image to the Windows Deployment Server now, then click Finish.
   
4. It will have pre-populated the source location with the file that you created. Click Next.
   
5. It will also pre-populate the name and description. Change if you like, then click Next.
   
6. Click Next and Finish to complete the process. WDS will import the file back into the boot images. It takes time because it is de-duplicating it against the ones that it already has.
7. The captured image should now appear in your boot list.
   
8. Find the pre-staged item that matches your source system (alternatively, you can set the server to respond to unknown clients). On the Boot tab, select the image that you just imported.
   
9. Optional: If you will be uploading the captured image directly to the WDS server, you’ll want to create an install image group to contain the uploaded image (unless you already have a group ready). Just right-click on the Install Images tree node and click Add Image Group. You get a small dialog to enter the name. I’m creating a Windows Server 2016 image, so I called mine “WS2016”. Whatever you do, I recommend you create install image groups based on the operating system type for reasons that I’ll explain in a later section.
10. You’ll need to be at the console of the source system so that you can configure it for PXE boot and connect it to WDS during the PXE cycle.
11. Sysprep the source system. At an elevated prompt, run: sysprep /oobe /generalize /reboot. Substitute in “shutdown” for “reboot” if you need to do other things before it starts.
12. Ensure that the system boots in PXE mode.
13. Select the appropriate boot image. I’m not sure why it shows all of them since you manually selected one, but…
    
14. You will be brought to the first page of a wizard. Click Next.
15. A drop-down box will be presented that shows all of the located sysprepped volumes. Usually, there’s only one. It probably will not show a drive letter of C:, so don’t worry about that. Choose the drive letter, then enter a name and a description for the final install image (it can be the same as the boot image that you created earlier if you want).
    
16. Now you need to decide where to place the created image. You can browse to a local location or a network location. Most of the drive letters that you see will belong to the boot image and are not writable, so be careful. If you want to save the image to the same drive that’s being imaged, it’s the Volume to capture from the previous page. If you want to upload to the WDS server, then enter the name of that server and click Connect. Then, choose one of the install image groups to hold it. Note: If you enter something for the WDS server, it will do the file save and then transmit it; this is not an either/or dialog. I filled out all the fields of the dialog to show you what it looks like. Myself, I will clear the upload box and perform the import of the WDS image later.
    
17. Relax, find something else to do. This will take some time. When the process completes and you click Finish, the system will reboot to its sysprepped state.
18. If you didn’t upload it directly, the generated WIM file needs to be placed somewhere that the WDS server can reach it. I’ll cover adding images to the WDS server’s repository in the next section.
19. Retarget the boot.wim file for this server (undo step 8).

Once the image is added to the WDS server’s list, you can boot this server in PXE mode and reinstall the exact image that you just captured.

Adding Install Images to a WDS Server

One way or another, you should have at least one install image now. Install images contain the operating system that will be installed along with anything else that you placed inside the image. Adding images is a very simple process.

1. First, you need an install group, if you don’t already have one. WDS will deduplicate the images inside an install group, so organize them by the operating system. You can create the install image groups separately, or while you are importing an install image. To create one separately, right-click Install Images and click Add Image Group. You’ll get a small dialog where you can enter the name for your group.
2. To add an image, right-click Install Images and click Add Install Image.
   
3. Choose or create the image group to add the image to.
   
4. Locate the install image file that was saved from a previous section.
   
5. Since we created WIMs from live systems, they only contain a single image. If you like the name that you chose, leave the Use the default name and description for each of the selected images box checked.
   
6. If you didn’t leave that box checked, you’re now looking at a screen that asks you to enter a name and description. I didn’t do that, so I have no screen shot.
7. After that, just Next and Finish. The file will be imported. It will take some time as it prepares/calculates deduplication info.

That’s all it takes to add images. Now, when systems boot, they’ll have each of these items as possible install images… maybe. You can override that.

Setting Install Image Filters

So, I showed you how to create an image just for a specific machine. You really don’t want other machines installing that image, do you? Use filters to lock an image to machines that match particular criteria.

1. In WDS, click Active Directory Prestaged Devices. Find the computer object that you want to scope to. Open its Properties dialog. On the General page, highlight its Device Id. Copy it to the clipboard, then close the dialog.
2. In the Install Images list on your WDS server, find the image that you want to modify. Right-click on it and click Properties.
3. Switch to the Filters tab.
4. Click Add.
5. Set the Filter type to UUID and leave the Operator at Equal to. Paste the Device Id that you copied to the text box and click Add.
   
6. You can add other filters if you like. If you want to change an existing filter, for instance, to add another UUID, then you edit the existing filter. The dialog won’t allow you to add another instance of the same filter.
   

Now, when the system with that UUID connects to the PXE server, it, and only it, will be able to choose that install image.

Look through the tabs for other options. For instance, on User Permissions, you can restrict an image so that only certain Active Directory user accounts can install it.

Install an Image from a WDS Server

And now, the moment that you’ve been working up to installing an image from your WDS system.

1. Pre-flight check:
   1. A DHCP server is available and visible to the layer 2 network that the target server is connected to
   2. The WDS server allows connections (PXE Response tab of the server’s properties dialog)
   3. You have configured the pre-staged device account
   4. You have configured the boot.wim and scoped the pre-staged device to it
   5. You have an install image for this server and, if you enable a filter, it matches the server
   6. You have access to the server’s console, directly or via an out-of-band management tool
   7. The server is set to PXE boot
2. Boot the server in PXE mode. It should connect to the server and start downloading the boot file. Depending on how you set your process, it may jump right into the download or you may need to press a specific key.
   
3. You will then be taken to some screens that look similar to a regular media-based install. Start with the language selection. If you are booting a UEFI/Generation 2 VM and it fails to reach this point, you may have some troubleshooting ahead of you. I followed many articles before learning that the WDS server sometimes corrupts its own files. I fixed that with the instructions by “jpdand” on the Microsoft forums.
   
4. You will be prompted for domain credentials. Remember that install images can be scoped to specific accounts/groups, so choose accordingly.
   
5. Next, you will choose the image to install.
   
6. From this point onward, everything will work like a standard install of your chosen operating system. You’ll set up partitions and choose which to install to, etc. I’m assuming you’ve done all that before and don’t need my help.

Once the install has completed, your system will boot. It will be a member of the domain, have the name that you assigned, and be in the VLAN that you assigned. Any software and settings that were in the original image will be present in the newly-installed environment. Networking often needs some help, unless you’re using DHCP.

That’s it! Windows Deployment Service takes some effort to fully set up and configure, but once it’s done, you’ll be very glad that you have it. No more digging for install media!

This guide is part of a 2-part series. The other guide focuses on How to Deploy Hyper-V Guests.