Creating Your Own Personal Hydration Solution – Part 1: Setting Up
|Part 1||Setting Up|
|Part 2||First VM – Windows Router|
|Part 3||Domain Controller|
|Part 4||Configuration Manager Infrastructure|
In this first installment we’ll work on getting the foundation set for building up the lab. We’ll configure the virtual networks, the host networking and get our MDT environment installed and configured. We are going to use a number of tricks that I’ve learned from others.
[This is going to be a long one.]
Note: It would be best to not alter computer names, IP addresses, MacAddresses, task sequence names, etc. until you are comfortable with how all the moving pieces fit together. While using the same conventions that I use is not mandatory, changing names, addresses etc. along the way could lead to problems if you accidentally overlook all the changes that would be needed. If at all possible use the same conventions that I use and then when you are comfortable with all of the interactions throughout the process then start making changes to meet your preferences.
I primarily use Windows Server with the Hyper-V role for my hypervisor but this will work just as well using VMWare Workstation or Client Hyper-V on Windows 8/8.1/10. I could work using the standalone Hyper-V server, it would just take a little extra work, but nothing too difficult.
We are going to create a lab that has 5 network segments. The first will be an external (Hyper-V) or bridged (VMWare) network to provide Internet access to the rest of the segments. This will allow for the various virtual machines to activate their evaluation copies of Windows. The remaining 4 segments will be internal (Hyper-V) or host-only (VMWare) networks. These will be isolated from the rest of your network so running a domain controller and DHCP server does not interfere with services running in your production environment.
Installing MDT and ADK
First things first. If you haven’t already, install the Microsoft Deployment Toolkit (MDT) and the Windows Automated Deployment Kit (ADK) on your host. I am using MDT 2013 Update 2 and ADK 10. The default installation of the MDT is perfect. For the ADK you will only need the Deployment Tools and Windows PE. If you are using the standalone Hyper-V server then install these onto a workstation that will act as your management machine.
Do not create an MDT deployment share yet. We will do that later.
Configuring Virtual Networks
The first part of the heavy lifting will be to configure the virtual network segments in your hypervisor. Again, this is the network topology that we will be creating. You do not need to create all 4 network segments, to be able to do routing you will need to create at least 2 of the network segments. If you wish to create more segments feel free. Once you know how to configure routing for two segments the process is repeatable for any number of segments.
I use 192.168.1#.x IP address ranges for the 4 segments that make up the “working” portion of the lab. You do not have to use the same address scheme and are free to use an addressing scheme that works best for you. The 5th segment is externally facing and rides on the host’s physical network connection.
|Segment Name||IP Address Range||Purpose|
|LAN2||192.168.12.x/24||Remote Office A|
|LAN3||192.168.13.x/24||Remote Office B|
|LAN4||192.168.14.x/24||Remote Office C|
The Main Office is the primary network segment. This segment will hold the domain controller (DC01), the Configuration Manager Primary site server (CM12 or CM16) and one of the Configuration Manager Distribution Points (DP12A or DP16A).
Remote Office A
This segment represents a larger remote office where a Configuration Manager Distribution Point (DP12B or DP16B) would be used. We will use Boundaries in Configuration Manager to restrict clients in this office to using the local Distribution Point and not pull content over the “WAN”.
Remote Office B
This represents a small remote office that relies on services provided by the Main Office over the “WAN” for everything. To PXE boot a machine in this office will require IP Helpers or Relay Agents on the router to process the PXE request.
Remote Office C
This segment is intended to experiment with 3rd party tools such as NomadBranch from 1E or 2Pint’s BranchCache. The servers in the diagram are labelled “NOM12” and “NOM16” for NomadBranch servers but you will be able to name them how you see fit.
All three of the Remote Office segments are optional but they are handy to have for learning.
Hyper-V uses virtual switches to define different network segments. There are 3 types of virtual switches available.
- External – this network rides on the physical network adapter of the host and allows VMs to access your external network
- Internal – this network only allows communication between the VMs on the switch and the host
- Private – this is the most restrictive and only allows for the VMs to communicate with each other and are completely isolated from even the host
If using Hyper-V (any version) we are going to create a single external virtual switch and 4 internal virtual switches. You can either use the Virtual Switch Manager in the Hyper-V console or PowerShell to create the virtual switches.
Virtual Switch Manager (GUI)
Open the Hyper-V console if you haven’t already. On the far right pane you will find the entry point for the Virtual Switch Manager.
Clicking it will open the GUI we will use to add the virtual switches.
First, select External from the switch type list and click “Create Virtual Switch”.
Enter a name for your external switch. (I named mine “LAB – External Virtual Switch”) Next, make sure that the bullet is on “External network” and that your physical network adapter is selected in the drop-down listing.
Finally click “Apply” to save your changes. You may see the following message:
This is completely normal and to be expected. What happens is Hyper-V will create a new network adapter on your host. This process will temporarily drop your network connection. If you are connected to your machine over RDP that connection will drop. This is completely normal and not a problem. Just reconnect your RDP session and you are back.
Now that the business of setting up the external network is finished we just need to set up the internal networks.
Back in the Virtual Switch Manager click the option on the left, “New Virtual Switch”.
This time highlight “Internal” in the window before clicking “Create Virtual Switch”.
Make sure the bullet for Internal network is selected and provide a descriptive name for the switch. Click Apply to save the settings.
Repeat with this process for the remaining internal switches. Feel free to use a naming standard that you prefer. You can name them anything you wish. In my example below I prefaced each with “LAB” so they would stand out should I have other switches on my Hyper-V server and named them with different examples of identifiers. Again, you can name them anything. I would just make sure to somehow be able to identify which switch is for which segment.
You can also create these virtual switches easily using PowerShell instead of the GUI.
First we’ll set up the external switch. To do this we will need to know the name of our host’s network adapter. Remember in the GUI you had to select the network adapter from the drop down list? We need to know what the adapter name is so we can bind the external switch to that adapter in PowerShell.
Using PowerShell’s Get-NetAdapter we’ll find the name of our adapter(s):
On my machine I have an adapter named “LAN1” and one named “Ethernet”. (The “vEthernet…” one is an existing Hyper-V external switch on my server, so ignore it).
Now we’ll use PowerShell to create the external switch for the lab. For this example I’ll name it “DEMO – External”. (Use an Administrative PowerShell prompt.)
New-VMSwitch -Name 'DEMO - External' -NetAdapterName 'Ethernet' -AllowManagementOS $true -Notes 'External switch for virtual lab'
In the above example I used the New-VMSwitch cmdlet to create a switch named “DEMO-External” and bound it to the network adapter named “Ethernet”. The AllowManagmentOS parameter simply means that the adapter will also double as the live connection for the host. The Notes parameter specifies an optional description for the switch.
Once that is complete we’ll create the 4 internal switches. We’ll use the same New-VMSwitch cmdlet to create them:
New-VMSwitch -Name 'DEMO - LAN1 (192.168.11.x)' -SwitchType Internal New-VMSwitch -Name 'DEMO - LAN2 (192.168.12.x)' -SwitchType Internal New-VMSwitch -Name 'DEMO - LAN3 (192.168.13.x)' -SwitchType Internal New-VMSwitch -Name 'DEMO - LAN4 (192.168.14.x)' -SwitchType Internal
When you’re done you will have your virtual switches all set up.
First, open the Virtual Network Editor (you’ll need to UAC up to make changes).
By default VMWare will already have created 3 virtual networks. We are only going to use VMnet0 (the Bridged connection) out of these three. The remaining virtual networks we will create ourselves.
Click on the button “Add Network…” to bring up the Add a Virtual Network dialog. Select a network from the pulldown list. I chose to create virtual networks that match the IP address schemes I’m using.
After adding the new network make sure that “Host-only” is selected and that you change the IP subnet to match the range that will be used in that network.
Repeat this process for the other 3 isolated networks.
Configuring Host Networking
Now that the virtual network environment is complete the next step will be to configure the host networking. I choose to use internal (Hyper-V) or host only (VMWare) networks so that the host can be reached by the VMs on these networks.
You will see that for each network switch you’ve created has a corresponding network adapter on the host.
What we are going to do is to assign an IP address to each of our host’s virtual network adapters on the internal networks. For this example we’ll use .50 (i.e. 192.168.11.50). We will use these IP addresses later when we configure the deployment share so keep track of them.
Doing this will allow the VMs on each of the subnets to access the deployment share that we are going to set up.
Configuring the MDT Deployment Share
The last step in this installment will be to setup the deployment share. We will populate it in other installments as we build out the lab.
From within the MDT console create a basic, simple deployment share. We’re not worried about anything special right now so you can accept the defaults as you step though the wizard. Place the share on the drive of your choice. The drive should have a fair bit of space free.
I placed mine on the root of the C drive and called the folder “_LabHydroShare” with the share name “LabHydroShare”. Feel free to use any names that you prefer.
You can do the same in PowerShell:
New-Item -Path 'C:\_LabHydroShare' -ItemType directory New-SmbShare -Name 'LabHydroShare' -Path 'C:\_LabHydroShare' -FullAccess Administrators Import-Module 'C:\Program Files\Microsoft Deployment Toolkit\bin\MicrosoftDeploymentToolkit.psd1' new-PSDrive -Name 'DS001' -PSProvider 'MDTProvider' -Root 'C:\_LabHydroShare' -Description 'Lab Hydration Share' -NetworkPath '\\HyperVServer\LabHydroShare' -Verbose | add-MDTPersistentDrive -Verbose
We’re going to use a trick in MDT to allow us to select different deployment shares when building the lab virtual machines. We’re going to use a file called “LocationServer.xml” to offer a wizard option to make the selection. This XML file will be added to the boot image so when it boots we will be prompted for the deployment share to connect to.
Later we will automate this so we don’t have to select the deployment share.
First, create a folder in the root of your deployment share called “_WinPE-Xtra-Files”. We’ll use this to add files to our boot image by specifying it as the source for extra files to add to the boot image. MDT will take the contents of this folder and add them to the boot image. We will want to create a couple of folders so our LocationServer.xml file is placed in the proper location in the boot image. Inside of “_WinPE-Xtra-Files” create a folder called “Deploy” and then inside of that create another folder called “Control”. Lastly create a file inside of Control called LocationServer.xml.
Below is a sample of the XML file for my setup.
<?xml version="1.0" encoding="utf-8" ?> <servers> <QueryDefault></QueryDefault> <server> <serverid>1</serverid> <friendlyname> LAN1 (192.168.11.x) </friendlyname> <UNCPath>\\192.168.11.50\LabHydroShare</UNCPath> </server> <server> <serverid>2</serverid> <friendlyname> LAN2 (192.168.12.x) </friendlyname> <UNCPath>\\192.168.12.50\LabHydroShare</UNCPath> </server> <server> <serverid>3</serverid> <friendlyname> LAN3 (192.168.13.x) </friendlyname> <UNCPath>\\192.168.13.50\LabHydroShare</UNCPath> </server> <server> <serverid>4</serverid> <friendlyname> LAN4 (192.168.14.x) </friendlyname> <UNCPath>\\192.168.14.50\LabHydroShare</UNCPath> </server> <server> <serverid>5</serverid> <friendlyname> External (DHCP) </friendlyname> <UNCPath>\\WSVMW7ZH_HV\LabHydroShare</UNCPath> </server> </servers>
Here is how the XML breaks down:
<server> <serverid>1</serverid> <friendlyname> LAN1 (192.168.11.x) </friendlyname> <UNCPath>\\192.168.11.50\LabHydroShare</UNCPath> </server>
Each server (or host’s virtual network adapter in our case) will be defined within a <server> block.
|Defines the beginning and ending of each servers block of XML code|
|Each server entry needs to have a unique number in sequence|
|This is the name that will be displayed in the MDT wizard|
|This is the corresponding UNC that the wizard will attempt to connect|
Now back in the MDT console, right click your deployment share and open the properties.
- Uncheck “x86” under the Platforms Support
We’re only going to be building 64bit operating systems so generating a 32bit boot image is unnecessary
- Click on the Rules tab (we need to clear the default UNC path from the bootstrap.ini)
- Click on “Edit bootstrap.ini”
- When the file opens in Notepad, remove the original UNC path from the [Default] section
- Save and close Notepad
- Click on the WinPE tab and change the platform to x64
- Under the Windows PE Customizations in the center of the screen, point the Extra Directory to Add to the root of your “_WinPE-Xtra-Files”.
(For example in my setup I used C:\ _LabHydroShare\ _WinPE-Xtra-Files)
- Click Apply to save your settings and OK to close the properties.
Last step for this installment (I promise), generate your boot image just to make sure everything so far is working correctly.
I know this was a long one but now we have the foundation set up. From here on out we’ll be building virtual machines.
Posted on December 28, 2015, in Configuration Manager, Hyper-V, MDT 2013, MDT Lab Builder, PowerShell, SCCM, Task Sequences, Training, Virtual Router, Windows Server and tagged evaluation software, Hyper-V, Lab, MDT 2013, PowerShell, SCCM, System Center, Training. Bookmark the permalink. Leave a comment.