NAT switch is a new feature introduced with the release of Hyper-V that shipped with Windows 10/Sever 2016. This commodity basically allow machines from your private LAN to go to the interweb by translating there private IP addresses to the public one exposed by your ISP.There is already a significant amount of literature about it here and there, but not yet anything that truly demonstrate how this can help you to improve your daily job!
As you may know my job is all about deployment, I carry on my laptop everywhere with me so I built a lab on it (My lab is a customized version of Johan’s Hydration kit). Using the NAT switch feature I was able to transform my lab from something useful to something super powerful. interested… read on !
Note: All this article was written using Johan’s Hydration kit as the base line environment, but starting from something else should not be a big deal (refer to Johan’s article for further details). The lab basically consist of two VMs. One is DC01 (AD+DNS+DHCP) , the other being CM01 (SCCM+MDT), I also have a bunch of empty virtual machine used to deploy Windows. As this is out of this blog post scope, I wont speak on how to deploy the Hydration and will assume that you already know the various in and out of this great toolkit.
Now let’s empower your job with the following benefits:
Benefit 1: One card to rule them all
Previously when building my lab, I was always configuring a public and a private hyper-v switch that I then bound to my various VMs. That’s no more the case with NAT switch. By creating only one switch adapter, I can do mostly everything:
- All VMs can see each others.
- All VMs can connect to the internet.
- All VMs can talk to the host using network IP address.
How To:
Make sure you’ve removed all Public, Private or Internal switch before proceeding. Open a Powershell ISE console with admin right and paste the following code:
$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)
Edit $NatNicIP and $NatNicSubnet according to the following rules:
- Both should be on the same subnet as you Hydration Lab (For example my Config Manager server is located at 192.168.10.210/24)
- Both should not overlap the subnet provided by the DHCP of your ISP Box (For example my ISP Box use the subnet 192.168.1.0/24)
Change also the $NatNicPrefixLenght according to your needs. (This is the network mask)
Note: You may perhaps need to change IP addresses from your VMs to be able to follow those rules, remember that you’ll also need to edit DHCP scope and AD sites on DC01, and SCCM boundaries on CM01. If you’ve not yet deployed your Hydration and are planning to, Mattias Benninge and Jérôme Bezet-Torres have written tools to customize all aspect of the kit including IP addresses here and there.
After executing the script, a new network adapter should appears on your host.
Bind all you VMs to this new adapter in your Hyper-V console. You’ll need open the settings page of each VMs.
After that, opening a browser to surf the web should works on all VMs bound to this NIC. You can also ping and share folders with all others VMs.
You can Ping and connect to your host using either the Nat-Switch IP address or the ISP router’s one. Also remember to only use IP address, not netbios or FQDN names between Host and VMs.
From your host, you can now ping and share folders with all your VMs using there own IP addresses.
Benefit 2: Get Ride of your Router VM
My Laptop only support 16 Go Ram, so optimizing RAM consumption is a requirement. Previously, to get my VMs accessing the internet I could attach them to a public switch (Works perfectly, but will not help to understand where and how traffic lives in real world) or use a dedicated VM as a router (Far more realistic scenario, but require one more VM ). As my preference goes to the second choice, I always have to run/maintain a dedicated VM for that purpose, but no more by now. I have more space available and less management to handle, who don’t want that ?
Benefit 3: Work from the host
One of the major pain Hyper-V has compared to Vmware or Virtualbox is communication with the host! Yes, you can use Powershell or RDP but they both rely on services, work only in one direction and are not what you need if your access needs to be exposed as a drive letter or an UNC path.
With NAT Switch you can access your host from your VM using a simple UNC path like \\MyVMIP\c$ but also on the other side (From the VM to the Host) in the very same fashion \\MyHostIP\c$.
From my daily job perspective, this sweetie allow me to do fantastic things like:
- Editing a remote MDT deployment share on a VM directly from my MDT installation located on the host and vise versa !
- Even cooler ! Deploying Windows on a VM from a deployment share located on the host !!
How To:
I installed MDT on my host, and for the VM part, used the one available on CM01. I also created and filled up a deployment share on both location.
To connect from MDT on the host to a deployment share on a VM:
I cache the credential used to connect to my target VM using this command: cmdkey /add:192.168.10.210 /user:OSDC\Administrator /Pass:P@ssw0rd
where 192.168.10.210 is the IP address of my CM01 VM, and OSDC it my AD domain name. Of course, change them to what is suitable in your environment.
Then I open MDT, right click on the Deployment shares node and click on Open Deployment Share. On the wizard panel I past the path of my remote deployment share using UNC syntax \\192.168.10.210\f$. The Browse button finally helps me to pick the correct folder
Once imported, I can easily edit the deployment share from my VM.
Connecting from MDT on a VM to a deployment share on the host is basically the same process. I just need to start from the CM01 VM, the cached credentials used are the local admin account and password from my host. The destination IP address should be the one of the NAT switch (in my case 192.168.10.1)
Now, let’s say that all is connected for that scenario, what should I do to deploy content from the host to a new VM ?…Not that much…
First, I need to set some sharing permission on the host deployment share.
In this example my deployment share is located on D:\=DS=\HydrationCB\DS. I can share it using the good old net share command:
Net Share DeploymentShareOnHost=D:\=DS=\HydrationCB\DS /Grant:Everyone,Full
then I need to tell MDT the location and credential it should use to remotely connect to the deployment share.
I log on my VM, launch MDT, right click on the Deployment share node, select Properties and then the Rules tab on the panel wizard. I then click on the Edit Bootstrap.ini button and add the following information without forgetting to click on Save when done!
[Settings]
Priority=Default
[Default]
DeployRoot=\\192.168.10.1\DeploymentShareOnHost
UserID=MrDiagg
UserDomain=MyHostPC01
UserPassword=P4ssw0rd
The DeployRoot property is filled with the IP address of my NAT switch plus the alias I defined for my shared folder.
UserID and UserPassword are credential from my host’s local admin account.
UserDomain is the name of my host PC as the machine is not in a domain.
After that I need to create an ISO boot that once loaded in a VM will launch the deployment.
The ISO boot is generated by right clicking on the Deployment share node and then clicking on Update deployment share. When the task is finished the created ISO can be found in your host deployment share on the boot subfolder with the name LiteTouchPE_x64.iso.
The ISO simply need to be added to a new VM where boot to CD is set in bios option.
The Installation is finished, when starting the VM, MDT will start deploying windows with the content taken from your host… super exiting !!!
Benefit 4: PXE boot outside of your VMs lab to physical machines
This one is definitely the coolest, using my NAT switch plus a few more pre requisites, I’m able to deploy directly to physical machines. I’m sure that you’ve already envisioned what you could do with that, but let’s check some of the most common scenarios.
- I’m now truly independent and can start working on customer’s PC even if I’m still waiting for login account or corporate desktop !
- I ‘m not just carrying an Config Manager Lab anymore, it’s now a fully autonomous and mobile deployment appliance.
- I can demo “in the real world” when meeting customers.
- I can test and deploy anything on real hardware right now !
- I can do it either with SCCM or MDT.
How To:
Apart from a PC with a working Hydration kit lab and NAT switch configured correctly (see Benefit 1 for details), you’ll need some hardware:
- A switch or a crossover RJ45 cable.
- At least, a second PC to deploy on.
Note: Before going further, I must tell you that this solution is not 100% perfect and has a small drawback: When switched on, VMs will no longer receive internet traffic! Sure it’s annoying, but doesn’t decrease the value of the solution at all if you ask me.
Before moving on, here is how my connectivity looks like:
The 3 NIC that we care about are:
- Wi-Fi: This is the NIC where I receive internet from my ISP. It could also be an RJ45 NIC
- LAN: This is the NIC connected to my switch and more over, to the PCs I will deploy Windows on.(Yes this is the right moment to connect them!)
- vETHERNET: This is the virtual NAT switch created by Hyper-V
At This point, I have that feeling to be one hop away from the outside: I can ping and reach VMs from the host and the other way around. I can see the VMs Network side by side with the external LAN, so what do I need between the NAT switch and the deployment LAN ? Some kind of bridge to make them speak to each other! …and guess what, that stuff exist in windows and is called… a network bridge!! (sometimes in life, computer science is just… what you expect !)
To Build that Network bridge, I Selected both the NAT-Switch (vEthernet) and the deployment LAN (Lan) by holding down the shift key.
Then I right clicked and selected Bridge Connections
When done, a new virtual NIC called Network bridge has appeared. My two NICs show that they are now bridged.
Other noticeable expected effects:
- Internet does not not work anymore on you VMs (you’ve been warned)
- PCs on the deployment LAN start receiving DHCP lease from the Hydration Lab.
We have nearly finished, I can now rush on any PC attached to the switch and launch a boot from network to begin deployment.
If all is good, this very familiar screen should rapidly appears :
On the WinPE screen, I can verify that I’ve received an IP from the scope defined in my Hydration lab’s DHCP:
For the rest, I’m pretty sure everyone will manage… some further details before you go playing with your new toy:
- I’ve only tested with one external PC, but it should works with several.
- I can still deploy to a VM inside my lab at the same time.
- Deployed Machines are domain joined and work with domain accounts
- Everything you’ve read was demonstrated using a Windows 10 Enterprise 1703 box. Not tested, but it should also works on Pro edition and Server 2016.
- “PXE out” worked without disabling any firewall at any point of the solution. (but your environment may perhaps require to).
- For the Nat switch part, Internet on VMs worked without any DNS forwarder (but your environment may perhaps require one).
- Oh my God, this is soo cool and addictive… here is a picture of my SCCM VM with a remote DART from the “outside” PC side by side with a deployment to another VM!
- Very Important: When your deployment are finished, don’t forget to right click on each bridged card to select option Remove from bridge! This way, the bridge will uninstall and your VMs will recover from internet blackout.
Last word: I’ve never have a clear understanding of the OSI model layers nor a deep network knowledge.I’ll try my best to provide support, but you’ll have to work your part hard before asking for help. I can’t explain in details why all this stuff works, this is truly an accident(No joke)!
Phew… Sota !!!