First, let's get the easy part out of the way: you should not enable Hyper-V as part of your reference image.  Doing so will get you in an unsupported nested virtualisation scenario. 

When I create a reference image for my customers, I am mindful of the fact someone has to maintain that reference image.  I am also fully aware that individual may not have the time to continuously update that image or create several reference images for the different server roles his / her team manages.  As such, here is a simple guideline I recommend when choosing what goes into a reference image for all your servers (whether these servers will host Hyper-V roles or other roles):  Determine what roles, features and applications are common to ALL your servers and only include these elements in your reference image.  Now, if you read this last statement carefully, you will realise I am recommending a very lightweight reference image.  This is indeed the case.  There are pros and cons to this approach. 

Pros

• Lightweight image - smaller image size
• Easier to maintain - updating the image would usually mean running the task sequence to get its updates from a WSUS server as I described in my last post.

Cons

• Increased number of deployment images or templates - you essentially would need to a template or image for each type of server you want to deploy.  In the case of Hyper-V hosts, that's not an issue if you are using SCVMM because in fact the simple image we created in the last post is the lean and mean Hyper-V server image we want to see in production environment to provide maximum stability and uptime.  In the case of other types of server roles, you would want to have a deployment template (or MDT deployment task sequence) per server role.  I will not discuss this approach since it's not relevant to Hyper-V / VMM bare-metal deployment.
• Increased deployment time - when you do not include all the components or applications needed for a given server in the reference image, then you will need another mechanism to provide these at deployment time or post deployment.  For instance, if you do not include the System Center Operations Manager agent as part of your reference image, then you will need to push it to the server (and ensure it gets pushed quickly) post deployment. 

With that in mind, I recommend the following components to be part of every reference image:

• Server OS (ok that one is obvious)
• Latest updates from MS Update or a corporate WSUS server
• SCOM Agent
• Backup agent

Some customers will include an anti-malware agent as well.  I question the value of an anti-malware agent on a stripped-down Hyper-V host installed with the Server Core option.  But many organisations do not have a choice in this matter, as this is typically something they have to do to address some sort of governance.

Now that this is out of the way, let me show you how to add Failover Clustering and / or hotfixes to your image.

Adding Roles and / or Features to the reference image

MDT makes it incredibly easy to add a built-in Windows Server role or feature to your image.  To add the Failover Clustering feature, we will edit the Task Sequence we created in the last post.

Open up the properties window for the task sequence and navigate to the Task Sequence tab.  From there, scroll down to the Windows Update (Pre-Application Installation) step.  With that step highlighted, click the Add button and select Roles then select Install Roles and Features.  This will another step to the task sequence.

Next, from the Properties tab, select the OS for which you want to enable a feature.  In my case, this is Windows Server 2012 R2 Core from the Select the operating system for which roles are to be installed dropdown list.

Seem familiar?  I told you this was going to be easy :)  This is the list of roles / features available on Windows Server 2012 R2 Core.  Here, the MDT Deployment Workbench allows you to select whichever role / feature to enable. In our case, we are interested in the Failover Clustering feature.  Go ahead and select that.  Notice that since I am installing the Server Core version of the OS, I won't install any management tools for Failover Clustering.

That's it!  Click OK when done.  Make sure the Install Roles and Features step is between the two Windows Update steps.  This ensures all Failover Clustering updates are includes are part of the "post" update process.

Adding Hotfixes to the reference image.

Next, the hotfixes, I recommend you have a look at this KB support article and determine which Hotfixes are needed in your Windows Server 2012 R2 WFC environment and which ones you'd like to apply as part of your reference image.  Again, this assumes your reference image is one which will be used for hosts participating in a Windows Failover Clustering (WFC) cluster.

From KB2920151, I am going to show you how to include the hotfix associated with KB2966407 installed as part of the reference image we created in the last post.

First, download the hotfix and extract it.  This should provide you with an .msu file.  Next, open up the MDT Deployment Workbench.  With the deployment share expanded, highlight Packages and click the Import OS Packages from the Actions pane.

From the Import Package Wizard, specify the folder containing the .msu file or files you downloaded for all the hotfixes needed.  Follow the wizard and accept all defaults.  Once finished, you should see the hotfix appearing in the Name pane.

Next, just update the Deployment Share to rebuild the .ISO file and restart the build and capture process as you did in the last post.  Your VM will now include all the updates from MS Update / WSUS as well as the hotfixes you explicitly add as MDT packages.

Hope you found this helpful.  Please leave me your feedback as I use this to determine which articles I write about next.

1. Overview
2. Configuring DHCP Services
3. Configuring WDS
4. Configuring WSUS
5. Selecting an imaging tool

Installing ADK 8.1

The download link to the ADK I referenced above will download a lightweight download tool called adksetup.  Once you have downloaded the tool, run adksetup with an account that has local Administrator privileges on the computer / server where you will install ADK / MDT.  The first screen will prompt you on whether you want to simply download the entire ADK toolkit (~ 3 GB download) or install the components you need.  Since I do not need all ADK components, I will simply choose the installation path shown here.

The next two screen will prompt for Customer Experience Improvement Program (CEIP) settings and license agreements.  Review these and select the desired settings, then click Next to continue.

For our purposes, we only need the components chosen here.  Click Install to continue.

That's it!  With the ADK 8.1 installed on your system, MDT will be able to leverage it.  Let's install MDT 2013 next.

Installing MDT 2013

MDT is a simple download and installation.  In fact, I recommend you simply accept the default installation parameters.  Once MDT 2013 has been installed, launch the Deployment Workbench.  In the next section, we detail how to build a reference image suitable for bare-metal deployment of Hyper-V hosts using MDT 2013.

Step 1 - Creating a Windows Server 2012 R2 Deployment Share

Follow these steps to build an image.  I show you the steps needed to build a reference image containing Windows Server 2012 R2 Server Core, including all updates obtained from the WSUS server I showed you how to setup in part 4 of this series.  The image would also include the failover clustering feature.  You may want to consider adding the .NET 3.5 feature as well if you are installing any tools on your Hyper-V host that require it.  An example of a tools I've come across which require it include backup agent software for Hyper-V.  We are installing Server Core as this is the recommended installation and default installation for Windows Server 2012 and higher.  A reminder to keep you Hyper-V host image as lean as possible.  Even once the host is deployed, the installation should to be very lean to minimize any downtime associated with having to update applications on your Hyper-V hosts.  In fact, about the only tools I recommend to my customers to install are backup agents if you environment requires it and monitoring agents such as the System Center Operations Manager agent software.

Let's start.

Open the Deployment Workbench.  From the Actions pane, select New Deployment Share.

From the Path window, enter a path where you will save the Deployment Share such as D:\WS2012.  This path can be a local path or a UNC path.  Also note that MDT supports DFS-R shares.  To configure MDT with DFS-R, you can find the details in MDT's online help by searching for "Configuring Distributed File System Replication".

From the Share window, enter a share name and click Next.  For the share name, MDT defaults to a hidden share (a share ending with the $ sign).  This is optional.  I highly recommend you keep the share name very short.  Otherwise, you will come across an issue at deployment time with errors about reaching the max characters in the deployment share path. 

From the Descriptive Name window, enter a description and click Next.

From the Options window, I recommend you unselect all options.  You can go through all the desired options to configure the deployment later.  Click Next to continue.

Click Next from the Summary window.

From the Confirmation window, click Finish.

You have now created the deployment share.  We now import the OS files.

Step 2 - Importing Operating System Files

The next step is to import the operating system files.  This step involves adding the source files from the Windows Server 2012 or 2012 R2 media ISO file to the MDT deployment share.  We add the source media as our baseline on top of which we add configuration items such as environmental roles / features required, OS patches, hotfixes, etc.  To begin, highlight the Operating Systems folder from the deployment share, and click the Import Operating System link from the Actions pane.

From the OS Type wizard window, select Full set of source files and click next.  This is the option to select if you are using the source media provided by Microsoft.  MDT can be used as a deployment tool as well, not just for image engineering.  The other two options in this window are for deployment engineering.  Since we are using SCVMM for the deployment of our server image, we do not need to be concerned about the two remaining options.

Next supply the source directory from the Source window.  This is the top level folder for your CD / DVD drive or your mounted ISO file

From the Destination folder, enter a directory name where the media's contents will be copied to.  Keep this folder name short.  I have come across deployment errors with MDT where this directory name was too long.

From the Summary window, click next.  This begins the copy of the entire contents of the Windows Server media to the deployment share.

Now that the OS source files have been imported, we can proceed with creating a Build & Capture Task Sequence.

Step 3 - Build & Capture Task Sequence

A Task Sequence in MDT is a grouping of sequenced actions that can be used to deploy an operating system, along with supporting applications, updates and drivers, on a target host.  In our case, we want to create a task sequence to ultimately use it for Hyper-V bare metal deployment.  To that end, we create a task sequence which will contain a server image we can later integrate as part of SCVMM's bare metal deployment process. A reminder that our image is to contain the following components:

• The Windows Server 2012 / 2012 R2 source media
• All OS Critical, Security, Update and Update rollups released up to the date of the image creation
• Any hotfixes required such as failover clustering and Hyper-V recommended hotfixes
• (Optional) Additional software such as backup agents or monitoring agents that we wish to add to the image.  This is optional because most agent management servers typically can "push" these agents to hosts and there are benefits to doing server-managed agent deployments.  I typically try to avoid adding such agents to the Hyper-V image itself to keep it lean and reduce dependencies on other tools which will require their own updating process which may not be aligned with Microsoft's OS updates frequency.

The Build & Capture Task Sequence will produce a single WIM (Windows Imaging Format) file which we will then convert to a VHD / VHDX file we later import into SCVMM. 

Let's begin...

From the Task Sequences folder, click New Task Sequence from the Actions pane.

From the General Settings window, enter a Task Sequence ID, a Task Sequence Name and optionally a Task sequence comments entry and click Next to continue.

From the Select Template window, select the Standard Server Task Sequence template and click Next.

From the Select OS window, select the OS installation you need for your image.  You may have a different list than I do here as I am basing my screen captures on an MSDN source media.  The reason you may see multiple selections here is simple: Microsoft can bundle different catalog items on a single DVD / ISO media.  What this means is that the installation media is the same, but the deployment license (and subsequently the product key) will be different.  What is important to understand here is you need to select the catalog for which you have a product key and license.  The other option you need to make here is whether to select the full GUI or Server Core installation.  Since this image will ultimately be used for Hyper-V servers, the option I am selecting is Server Core.  I strongly recommend you stay with Server Core for Hyper-V hosts, and all Windows Server hosts which support Server Core.

From the Specify Product Key, select the appropriate option relative to the licensing of your Windows Server media.  If you are using VL (Volume Licensed) media and you have a KMS (Key Management Server), then select Do not specify a product key at this time.  Otherwise, enter the MAK product key or retail key and click Next.

From the OS Settings window, enter the Full Name, Organisation and IE Home Page info and click Next.

Enter the Admin Password and click Next.  Note that this password is hashed in the Unattend.xml file produced as a result of configuration wizard.  If you do not wish to have this password stored in the unattend file, then select the Do not specify an Administrator password at this time and you will be prompted to enter one during the Build and Capture of the WIM file.  Keep in mind this can be overridden by SCVMM's Guest OS Profile so this password is only for your build environment.

Click Finish from the Confirmation window.

You now have a task sequence!  In order to enable this task sequence to get its updates, you need to do two things.  The first is accomplished by editing the task sequence.  From the task sequence's properties, navigate to the Task Sequence tab.  Then scroll down to the State Restore group.  From there, highlight the Windows Update (Pre Application Installation) step.  From the Options pane, ensure the Disable this step is unchecked.  Repeat the same for the Windows Update (Post-Application Install) step.  So why do it twice you ask?  The rationale is to update the OS prior to any application installation (Install Applications step) and then again after the application install.  For instance, assume you install an application requiring .NET 3.5 as part of the Install Applications step.  Well, you would want to ensure any compatibility updates are applied (this is done in the Pre-Application Installation step) and then all the subsequent security updates (this is accomplished with the Post-Application Installation step).

So now we have a task sequence configured to install the OS and update it from Microsoft Update.  If you want the task sequence to instead reach out to the WSUS server we built earlier in this blog series, it's very simple.  Here's how.  You need to add an entry to the CustomSettings.ini file.  This is accomplished from the Deployment Workbench's UI.  With the Deployment Share highlighted, click on the Properties link from the Actions pane.

From the share's Properties window, navigate to the Rules tab.  There, add the WSUSServer=https://wsusserver:8530 property and replace wsusserver with the FQDN of your WSUS server or IP address.  By default, WSUS installs on the TCP port 8530 this is why I added it here. 

Before I go on: MDT has a very rich set of properties you can use as part of image engineering.  I won't get into the hundreds of options here of course, but I will list the settings exactly how I use them in a very simple test environment.  The online MDT help (accessible by pressing F1) is fantastic and details every one of these in detail.  Here's what I have in my configuration:

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
_SMSTSOrgName=Contoso Corp
OSInstall=Y

SkipCapture=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES
SkipUserData=YES
SkipRoles=YES
SkipApplications=YES
SkipTimeZone=YES
SkipLocaleSelection=YES
SkipComputerBackup=YES

WSUSServer=https://wsus:8530

ComputerBackupLocation=NETWORK
BackupShare=\\build\ws2012r2u1\Captures
BackupDir=%OSDComputerName%
SLShare=\\build\ws2012r2u1\Logs

TimeZoneName=Eastern Standard Time
KeyboardLocale=en-us

Now that everything is ready, you can update the Deployment Share.  Simply click the Update Deployment Share and accept the defaults in the wizard the follows.  The first time you do this will take a long time to generate a boot.wim and boot.iso files.

You should now have a boot.iso file located at the boot folder of your deployment share (so in this example it would be under D:\WS2012\Boot - the file should be a bit less than 300 MB in size.  We will use this file to boot a blank VM in Hyper-V on a Windows 8.1 PC.  The only requirements for this VM is to have network connectivity to the PC / server / VM hosting your MDT deployment share.  In the VM's settings, you will point to the ISO file you created in the previous step.

Once you have configured the VM's settings, you can power on the VM.  The VM should start up from the CD ROM.  The first screen post startup you will see is the MDT welcome wizard shown here.

If you have a DHCP server on your network like I do here, then you can simply click the Run the Deployment Wizard to install a new Operating System button.  Otherwise, if you are using a static IP address, click the Configure with static IP address button.  Remember that in either case, this IP needs to be able to reach the MDT server's deployment share and resolve its name.  If DNS isn't working, you will not get very far.  It is a good idea at this point to press the F8 button to bring up a command prompt and ensure you have an IP address (using the ipconfig command), and that DNS resolution is working (using ping, nslookup, etc.).  Anyway, clicking next will show you task sequences available on your deployment share.  Select the one you created earlier in this post and click next.

The next step is important, you should not enter any domain info.  If you do, the MDT wizard will not show you the capture option for this VM.  I typically leave it at default, and click next.

Finally, select the Capture an image of this reference computer.  By default, the File name is equivalent to the VM.  Click Begin at the next screen and watch MDT does its thing!  This process can take anywhere from 45 mins to 4 hours depending on which version of Windows Server you are using (Windows Server 2012 would take longer to build than 2012 R2 Update 1 for instance due to the increased number of updates available to 2012 vs. 2012 R2 Update 1).

Once MDT has finished creating the WIM, navigate to the deployment share under the Captures folder (in our case, D:\WS2012\Captures.  We now have a fully sysprepped and updated WIM file.  Now, SCVMM expects a VHD / VHDX file and now a WIM for bare metal provisioning and / or VM disks.  We will now use the WIM2VHD tool to convert it to a usable VHDX file.  First, grab the tool at https://gallery.technet.microsoft.com/scriptcenter/Convert-WindowsImageps1-0fe23a8f then run it either using the GUI (with the -showui command) or pass the necessary parameters via command line (ex. .\Convert-WindowsImage.ps1 -showui) - you should see the WIM2VHD UI.  The fields are self-explanatory.  Click Make my VHD when ready

You should now have a VHD / VHDX file ready for consumption by SCVMM!  I usually take this same file and use it as part of my VM templates and / or bare metal provisioning.  The process is the same to get to the VHD / VHDX file. 

I hope this has been helpful :)

WSUS will be integrated with the bare-metal reference image development process.  We will be creating a fully updated server image.  There are two common approaches to updating a reference image.  One is to have the image reach out to Microsoft Update for all the updates, and the other is with WSUS.  Most organizations opt to leverage WSUS primarily since it allows up to be selective about which updates to integrate into their environment and which types of updates as well.  For instance, an organization may choose to delay the addition of a service pack into their imaging process until their test their line of business applications with it, but will choose to quickly integrate all security updates and critical operating system updates into their imaging process.  These decisions are not available through an automated imaging process with Microsoft Update.  They are with WSUS.

So let's begin!  First you need to add the WSUS role to your Windows Server.  If you already have a WSUS server in your organization, you can skip this part.  To add the WSUS role on a Windows Server 2012 / R2 server using PowerShell:

Install-WindowsFeature UpdateServices -IncludeManagementTools

This adds the role, and installs and performs an initial configuration of the WSUS role with a WID database (Windows Internal Database).  For the purposes of a server imaging environment, this database is sufficiently sized.  Next, open the WSUS Management Console.  This will begin several configuration steps.  The first one is to specify where updates will be stored.  Specify a path with enough disk space to store all the updates needed as part of your server imaging process and click Run to continue.  This process takes several minutes.  Once finished, click the Close button.

The next window you will see should be the Windows Server Update Services Configuration Wizard.  Click Next at the Before You Begin window

If this is the first WSUS server in your organization, click Next, otherwise, you can have this WSUS server installation sync its content from an upstream WSUS server here.

Next, specify any proxy server settings you use to access the Internet if any and click Next to continue.

Next, click the Start Connecting button to connect to Microsoft Update.  This process is needed to retrieve an update list of products that can be updated and associated languages.  For instance, if you installing WSUS on Windows Server 2012, this step will allow fetch an updated product catalog listing that includes Windows Server 2012 R2 so that your imaging process can include updates to 2012 or 2012 R2.  This process takes several minutes. 

Next, choose which languages are applicable in your environment and click Next.  By default, only updates in English are downloaded.

Next, choose the products for which you want updates downloaded.  In this Products pane, you will notice certain products are already pre-selected if you scroll down.  For the purpose of updating our reference image, you may want only the updates for Windows Server 2012 / 2012 R2 to be downloaded.  To do this, click the All Products checkbox twice.  This selects all products and then deselects all products. 

Scroll down near the bottom of the list to select Windows Server 2012 / 2012 R2

Next, select the types of updates you want downloaded.  As a minimum, I recommend Critical and Security updates to always be included in your images.  The Updates is another classification you may want to consider as well. 

Next, specify whether to download updates manually by initiating a manual sync or automatically.  Click Next and accept all remaining defaults from the wizard after this window. Once finished, the wizard will launch the WSUS management snap-in.

From the Update Services snap-in, click on Automatic Approvals

Next, select which types of updates you want to be automatically approved.  This is an optional step if your organization wants to test and approve every single update released by Microsoft.  In my reference image build environments, I choose to auto-approve all Critical and Security updates and manually approve Updates classifications.  Ensure this policy is applicable on all computers.  Since the reference image build and capture must be done by non-domain joined computers, this is an important step.

Finally, click on Synchronize Now to sync the WSUS server with MS Update.  By default, WSUS will only download meta data about the updates when you do this.  It only downloads the actual updates the first time a client computer requests that update.  This is done to reduce the amount of disk space needed on the WSUS server.

That's it!  Your WSUS server installation is ready to be part of your reference image development process.  Next, I will walk you through the actual process of developing a server image and importing it to SCVMM. 

We are almost there!

Till next time.

Adiy

Before we begin, let me describe some of the rationale to why I pick this approach.

Bare-metal provisioning with SCVMM requires a Windows Server 2012 / R2 image consisting of a VHD / VHDX file.  This VHD / VHDX file can typically be developed in one of two ways:

1. From source media: typically this is an ISO file downloaded from Microsoft's Volume Licensing site for production environments or MSDN for development / test environments.  The issue I have with this approach is it provides an out-of-date image file.  You still have to update the Hyper-V host once it's on the network.  This process can increase the time needed to deploy a host by up to an hour currently on Windows Server 2012 (due to the number of updates released since the OS has been released).  This is unacceptable to many of my customers and I agree this is not acceptable.  Technically, you can still update this image using the dism command or VMST (Virtual Machine Servicing Toolkit).  Using dism requiring additionally scripting to add to your environment and VMST still does not support SCVMM 2012 SP1 or R2
2. From another existing VM: this approach is popular with some of the customers I've worked with, especially ones who are used to building VMs on competing platforms.  Using this approach, you create a VM manually, and then using the WSUS server in your environment to update it, sysprep the VM and prepare it for use by SCVMM.  All of these things are manual in nature and require scripting to automate.

MDT offers a way to combine both approaches.  Here's why I pick it to generate a reference image for use in SCVMM bare-metal provisioning:

• I still begin by the source media so I know it has a known steady state. 
• It integrates with the WSUS we created in part 4 of this series to provide the image with latest and approved updates.
• It is a repeatable process using MDT's task sequences.  This is a big win with customers!  Customers typically have a process in place to update their server images say on quarterly basis.  Updating the server image using this approach essentially means the execution of an MDT Task Sequence.  This process takes less than 2 minutes to kick off the task sequence to create an updated reference image periodically.
• It's a fully customizable image.  While I am in general against creating a heavily customized server image, there are good use cases for adding say certain Windows Server roles or features in the customized image.  One example is the failover clustering feature in Windows Server 2012 / R2.  While SCVMM will add this feature if it's not already in the image, it doesn't update the image with failover clustering-specific updates from Microsoft Update.  Integrating this feature into your reference image, along with the WSUS / Microsoft Update integration ensure features common to your server build are fully updated.
• MDT allows you to easily build a WinPE image containing hardware-specific drivers needed for bare-metal provisioning.  SCVMM does not have any built-in functionality to update your WinPE image with hardware-specific drivers.  MDT takes care of this easily.

Now that you know why MDT is a great for your bare-metal server builds, let's see how to do this and integrate it with SCVMM.  You will need to download the following components:

• Microsoft's Assessment and Deployment Kit version 8.0 or 8.1.  Either version will be fine for the purpose of creating a reference image.  If you are installing MDT on your SCVMM Management Server, then you already have a version of ADK installed.  SCVMM 2012 SP1 requires version 8.0 and SCVMM 2012 R2 requires 8.1.  I generally don't recommend placing your MDT build environment on your Management Server, but it's technically possible.  If you are not installing MDT on the SCVMM Management Server, then pick ADK 8.1 as it's the latest.  It's also the version needed if your bare-metal Hyper-V hosts will be 2012 R2.
• Microsoft Deployment Toolkit 2012 Update 1 or 2013.  2012 Update 1 is compatible with ADK 8.0 and Windows Server 2012 while 2013 is compatible with ADK 8.1 and Windows Server 2012 AND Windows Server 2012 R2.  Again, if you are installing MDT on a build environment PC or server, then pick the latest version.
• You will need the WIM2VHD script to convert the WIM file output from MDT to a VHD/VHDX file consumable by SCVMM 2012 SP1 / 2012 R2.  You can get it from TechNet Gallery here.

In the next post, we use MDT and ADK to build a reference image.

Till next time,

Adiy

1. Part 1 - Overview
2. Part 2 - Configuring DHCP

Windows Deployment Services (WDS) is a Windows Server role which provides the PXE services needed by SCVMM.  Once WDS is configured, it can be integrated and managed with SCVMM.  In this post, we discuss how to enable the WDS role and configure it for SCVMM's consumption.

I am going to install and configure the WDS role on the same host where I installed the DHCP server service in my previous post.  This is not a pre-requisite, but it makes configuration slightly easier.

First, install the WDS feature and management tools.  If you are using Windows Server core (and you should maximize Windows Server Core deployments in your organisation), you do not need the management tools of course to be installed on this same host.  To install the role and associated management tools, open an elevated PowerShell command prompt and enter the following command

 Install-WindowsFeature WDS -IncludeManagementTools

Next, open the Windows Deployment Services management snap-in.  You will see the following message indicating that WDS is not configured yet. 

To configure the server, highlight the server hostname and select Configure Server from the Action menu.  This launches the Windows Deployment Services Configuration Wizard.  This wizard is pretty simple.  The following windows may require your input.  Otherwise, you can accept the defaults.

The Install Options window asks you to choose whether to have WDS integrated with AD or not.  There are many reasons to integrate WDS with AD and I have not come across a use case of any of them with respect to SCVMM.  SCVMM will work fine with the Standalone server option.

If you have a separate DHCP Server installed on the same server as WDS such as our case, you will want to leave this window to its defaults.  If DHCP is not installed on the same host, you will want to uncheck the second option and configure the DHCP PXEClient option manually as I discussed in the previous post.

For SCVMM, you need to configure WDS to not respond to any client computers.  What this does once the WDS server has been integrated with SCVMM is to forward the PXE requests to the SCVMM Management Server.

That's it.  Accept default in this wizard otherwise.  When asked about where to install WDS content (which defaults to C:\RemoteInstall), you can point it to folder on your system.  The WDS Wizard will warn you if you are installing it on the system drive.

Once the wizard has completed, ensure the WDS service is started.  If you have installed WDS on the same host where DHCP is installed, you should now see the PXEClient option under the Server Options from the DHCP management snap-in.

Your WDS server is now ready for integration with SCVMM.  You can now add it to SCVMM.

From the SCVMM Console, navigate to the Fabric workspace.  From the ribbon, select Add Resources and then select PXE Server.

From the Add PXE Server window, add the PXE Server hostname and the Run As account.  The Run As account needs to have local administrator privileges on the target PXE server.

You can check the SCVMM jobs log to ensure everything installed correctly.  Once the PXE Server has been added to SCVMM, you will see the System Center Virtual Machine Manager Agent service added on the WDS / PXE Server

To ensure the VMM OSD (Operating System Deployment) provider has been integrated correctly with WDS, you run the following command from an elevated prompt on the WDS Server

wdsutil /get-server /show:config

Navigate to the WDS PXE Providers section.  You should see the VMMOSDProvider at the top of that list like this:

WDS PXE Providers:
     Name: VMMOSDProvider
     Path: C:\RemoteInstall\DCMgr\bin\OSDPxeProvider.dll
     Order: 1
     Critical: Yes

     Name: WDSDCPXE
     Path: C:\Windows\system32\wdsdcpxe.dll
     Order: 2
     Critical: No

You are done!  WDS is now ready for bare-metal deployment with SCVMM.  In the next post, I will discuss how to develop a fully patched reference image for deployment.

Till next time.

Adiy

The DHCP Server is the first server contacted by a Hyper-V host after it has been powered-on by the SCVMM Management server.  If the Hyper-V host has been configured to boot from LAN, it will attempt to PXE boot from LAN by first obtaining an IP address from the DHCP server.  The DHCP server must already have an existing DHCP scope and configured with the following Server or Scope Options:

1. Option 43: Vendor Specific Info: must be set to 01 04 00 00 00 00 FF.  
2. Option 67: Bootfile Name: this is the boot file name used by the Windows Deployment Services (WDS) role.  Enter boot\x86\wdsnbp.com as the value here
3. Option 66: Boot Server Host Name: IP address or hostname of WDS Server.  If you are entering a hostname, ensure the DHCP Scope has a DNS Server value
4. Option 60: PXEClient.  I am adding this one as a reference in case you do not use Windows Server 2012 or 2012 R2 WDS on the same host running the DHCP Server service.  If you are using 2012 / 2012 R2, the WDS Server service adds this DHCP option automatically if configured correctly and is installed on the same server where the DHCP Server service is running.  We discuss the WDS Server configuration in the next post of this series

Once the DHCP server's Scope or Server Options have been configured, you should see something like this.  Again, the Option 60 value does not show up yet since I have not configured the WDS role yet and I intend to configure it on the same host as the DHCP server I have in my lab here.  We will cover this next.

Finally, while I describe how to configure the DHCP Server service in Windows Server 2012 R2 here, the same parameters can be configured in Windows Server 2012 and 2008R2.  I have not personally tried this configuration with previous releases but I expect they would work the same as long as the DHCP scope and options are configured correctly.

Till next time.

Adiy

[View:https://www.youtube.com/watch?v=E6FZiTAdEGg:0:0]

Till next time

Adiy

Till next time

Adiy

First, let's walk through the list of pre-requisites in order to accomplish this.

As described in the following graph, the bare-metal provisioning in SCVMM begins when the SCVMM Management server triggers the bare-metal deployment on a Hyper-V host by communicating with the host's BMC (Baseboard Management Controller) using the IPMI or SMASH protocols.  This powers-on the server.  From there, the process is as follows:

1. The server initiates the boot from LAN by obtaining an IP address from a DHCP server.  For this to happen, the server must be configured to boot from LAN in its BIOS or UEFI configuration. 
2. The DHCP server will provide the Hyper-V host with an IP address and a set of DHCP configuration options.  One of these options is the IP address of the PXE boot server configured and integrated with SCVMM.  We cover the configuration of the DHCP server in a future post in this series.
3. The PXE server is hosted on a Windows Server running the Windows Deployment Services (WDS) role.  The WDS server is configured with SCVMM integration so it passes the info of the Hyper-V host to the SCVMM Management Server.  We cover the WDS configuration in a future post in this series as well.
4. The SCVMM Management Server determines the required drivers and reference image needed by the Hyper-V host from the SCVMM Library
5. The SCVMM Library deploys the reference image VHD or VHDX file over the network to the Hyper-V host. 
6. Once the VHD / VHDX file has been copied to the Hyper-V host, the SCVMM Management Server finalizes the Hyper-V server's configuration including parameters such as MPIO and Failover Clustering feature installation.  The Hyper-V is now available from the SCVMM Management Console and can be added to existing clusters or to create a new cluster.

The next post is in this series discusses how to configure the DHCP Server service in Windows Server to provide PXE / WDS integration.

Till next time.

Adiy