In a previous post I demonstrated the many benefits of installing a NAT switch to push your Hydration lab to the next level. I also covered some use cases that included MDT, but I missed a big one about how to keep those benefits if you have nothing else than MDT ? In this post I will cover this particular scenario.
The big picture
So let’s draw the edges of our context: you have a PC with ADK and MDT installed… and that’s all!!.. To be able to build and capture a reference image or just to deploy Windows to a VM you’ve probably thought of activating the Hyper-v role, and then after, of creating an MDT lab with one dedicated VM to host MDT and another one as a target to deploy Windows..??
Please… Do yourself a favor… Forget about that !!!!
This kind of lab is outdated and can be refactored to just one single target VM! Using the magic of NAT switch. You will enjoy developing your deployment solution from your host PC and test it against your Hyper-v VM (Guest). You will also be able to deploy to a real network by just adding a Bridge network (read my previous post for further details), and even doing crazy stuffs like doing VM snap shot from a task sequence (teaser…coming later…). Now that you envision the possibilities, let’s build that power lab!
Setting up NAT switch
I will assume that you’ve already enabled Hyper-v (If you need guidance you can use this) and will start by enabling the NAT switch using PowerShell. To do so, open an elevated Powershell ISE, click on the ‘new’ icon button, and past the following code in the upper window:
$NatNicIP = '192.168.10.1'
$NatNicSubnet = '192.168.10.0'
$NatNicPrefixLenght = '24'
$NatName = 'Nat-Network'
New-VMSwitch -Name $NatName -SwitchType Internal
# Get the MAC Address of the VM Adapter bound to the virtual switch
$MacAddress = (Get-VMNetworkAdapter -ManagementOS -SwitchName Nat-Network).MacAddress
# Use the MAC Address of the Virtual Adapter to look up the Adapter in the Net Adapter list
$Adapter = Get-NetAdapter | Where-Object { (($_.MacAddress -replace '-','') -eq $MacAddress) }
New-NetIPAddress –IPAddress $NatNicIP -PrefixLength $NatNicPrefixLenght -InterfaceIndex $Adapter.ifIndex
New-NetNat –Name $('Item-' + $NatName) –InternalIPInterfaceAddressPrefix $($NatNicSubnet+ '/' + $NatNicPrefixLenght)
Note: The script is the same as the one from my NAT switch post. Feel free to change IP and subnet to your convenience. Further details are available here.
When all parameters are adjusted to your needs, click on the green execute button to launch the program, this should be enough to get your NAT switch in shape.
Tweaking MDT
The main difference with this lab scenario and the hydration one is the lack of DHCP which means that we will need to assign a static IP during the WinPE part of the deployment but also during the Windows installation.
For the WinPE part, IP assignation will be done by creating an unattend.xml file (idea by Andew Barnes, Thanks to him)
Copy/past the following xml into a text file and save it as Unattend.xml
Note: Info provided here are based on an x64 Architecture (Does anyone still care about x86 nowdays ?!!). If you need to adapt it for x86, you can use C:\Program Files\Microsoft Deployment Toolkit\Templates\Unattend_PE_x86.xml as a starting point.
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State">
<Display>
<ColorDepth>32</ColorDepth>
<HorizontalResolution>1024</HorizontalResolution>
<RefreshRate>60</RefreshRate>
<VerticalResolution>768</VerticalResolution>
</Display>
<RunSynchronous>
<RunSynchronousCommand wcm:action="add">
<Description>Set Static IP</Description>
<Order>1</Order>
<Path>netsh interface ip set address Ethernet static 192.168.10.10 255.255.255.0 192.168.10.1</Path>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
<Description>Lite Touch PE</Description>
<Order>2</Order>
<Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
</RunSynchronousCommand>
</RunSynchronous>
</component>
</settings>
</unattend>
As you can see, the IP address is provided by using the netsh command between the <RunSynchronous command> tags. The defined IP address of the virtual machine is set to 192.168.10.10 but can be changed to whatever you want, it just needs to stay in the subnet defined by the NAT switch.
Inside your deployment share folder, create a sub folder called WinPe-Extra and place the Unattend.xml file in it.
On the MDT Workbench, right click on your deployment share and click on Properties. On the properties window, click on the Windows PE tab, select the proper platform and pick the Features tab, edit the “Extra directory to add” field by adding %DeployRoot%\WinPe-extra (Take extra care as it often crash the MDT console). This way the unattend.xml will replace the original embedded one in the windows PE boot image.
To make the IP address survive the first Windows boot. It should be applied to the network adapter. this part is natively supported by MDT and will be delivered by adding a few properties to your rules aka CustomSetting.ini.
Open the MDT Workbench, right click on your deployment share and click on Properties. On the properties window, click on the Rules tab and add the following properties to the [Default] section:
OSDAdapterCount=1
OSDAdapter0EnableDHCP=FALSE
OSDAdapter0IPAddressList=192.168.10.10
OSDAdapter0SubnetMask=255.255.255.0
OSDAdapter0Gateways=192.168.10.1
OSDAdapter0DNSServerList=9.9.9.9
Making your rules looking more or less like this:
Last thing to get the job done: click on Edit Bootstrap.ini button and check that it is properly configured: the DeployRoot property should point to your Host PC NAT switch address. if you’ve used the script above to set up your switch, then this is the value from the first line:
$NatNicIP = '192.168.10.1'
So your DeployRoot property should looks something like DeployRoot=\\192.168.10.1\DeploymentShare$
Of course you should also have shared your deployment folder (otherwise, why calling it a deployment share ?!) and have created an account that have read access to it. As this is the basic of MDT I won’t cover it here, but if you feel alone on that mater, here is what you should do.
Ok, so now you are ready, enjoy editing and deploying all the ways from host to VM and beyond. See you in the next episode.