Build a virtual test lab Part 2: Installing Hyper-V

    As mentioned in the previous part, I am using Hyper-V for my home virtual test lab because I have Windows 10 and the product is already included. If you also have Windows 10 you may notice that though this feature is included, it is nowhere to be found. This is because you have to specifically install it first; the binaries are on the computer but they are not installed by default. The steps are the same on Windows 8 and 8.1 so if you have one of these OSes everything should work as expected.

    Besides installing Hyper-V, I will show you some basic settings to make and how to create a virtual machine.

    Note: Hyper-V is not available on Windows 10 Home edition.    

    Installing Hyper-V

    Optional features on a Windows client can be installed or uninstalled from the Turn Windows feature on or off menu found in Uninstall or change a program.

    First go to Uninstall or change a program from “This PC” (the former My computer). Make sure you are on the Computer tab next to File in the upper left.

Go to Uninstall or change a program
Go to Uninstall or change a program

    Now click on Turn Windows features on or off in the left side menu.

Turn Windows features on or off
Turn Windows features on or off

    Now find Hyper-V and make sure you check all the subfolders like in the image.

Installing Hyper-V
Installing Hyper-V

    After clicking OK you will need to restart the computer in order for the Hyper-V service to be installed. And that’s it for the installation part. You are on your way to having a cool virtual lab for testing.

    To locate the Hyper-V console just open the Start menu or Start screen, go to Windows Administrative Tools and you should see the Hyper-V Manager. I recommend pinning it to Start so you find it easily.

Hyper-V Manager location
Hyper-V Manager location

    Let’s open the console and take a look at a few of it’s settings. I won’t go over everything as some settings are more advanced and not crucial to setting up the lab for home use.

    Exploring Hyper-V settings

    After installing the feature there are some things that you should set up. The general settings are found by right clicking on the computer name from the Manager and selecting Hyper-V Settings.

Open Hyper-V Settings
Open Hyper-V Settings

    The first 2 items in the list let you configure the default paths for virtual machines and hard disks. In my case I made 2 folders on the SSD named VM and HDD and configured them as the defaults. The setting does not mean that you cannot place a particular VM in another place; when creating the machine you are asked if it should be put in another location than the default one.

Set default paths for VMs and HDDs
Set default paths for VMs and HDDs

    We now skip ahed to the Enhanced Session Mode Policy setting. This mode can be used for guest operating systems from Windows 8/Windows Server 2012 and up. It has some very nice features like local devices redirection, copy and paste from host to guest, drag and drop from host to guest, Remote Desktop like features like the nice full screen mode etc. Make sure that this is enabled.

Enable Enhanced Session Mode Policy
Enable Enhanced Session Mode Policy

    If you activated this setting then go to the user part of the configuration menu and enable the Enhanced Session Mode from there also. This configures the usage of the enhanced features on supported VMs without activating them from the Virtual Machine Connection console.

Check Enhanced Session Mode in the user part
Check Enhanced Session Mode in the user part

    These are the basic things to set up after installation. Let’s create a VM so we go through the steps and see what each means.

    Create a virtual machine

    This task is done from the Hyper-V Manager. Right click on the server name, select New > Virtual Machine and the VM creation wizard will start. On the first screen you have the possibility to directly click Finish and make a machine with the default values or click Next and go through every setting to customize it. We will obviously click on Next to see every setting available for creation.

VM creation step 1
VM creation step 1

    The next screen lets you set a name for the VM. This name is just so you know which virtual machine is which in the Hyper-V Manager. The name of the guest operating system can be set to whatever value you want. I like to set the same name to the VM as the name I use in the guest OS.

    Below the name you see the path where the machine will be stored. Since we set our default path there is no need to edit it. If you want to store the VM somwhere else you are free to change this setting here.

Set VM name and storage path
Set VM name and storage path

    The generation is a very important setting because it dictates what operating system you can install and it cannot be changed after creation. Generation 1 VMs are for older operating systems and for Linux as only some Windows OSes are supported in Gen 2. This generation is the old style of VMs in Hyper-V which does not support Enhanced Session Mode, UEFI boot, default PXE boot and other features. It uses BIOS and has legacy hardware support like the floppy disk. Anything older than Windows Server 2008 R2/Windows 7 (including these 2) has to be installed in a Generation 1 virtual machine.

    Generation 2 means that you get Enhanced Session Mode, UEFI, PXE boot from the standard network adapter. no more emulated legacy hardware and security features like Secure Boot. Windows 8/Windows Server 2012 and up should be installed as Gen 2 VMs.

Set VM generation
Set VM generation

    RAM assignement is done on the next screen. The Startup Memory value can mean 2 things:

  • The amount of memory that the machine will have allocated during it’s running state (if the below chackbox is not checked); this means that when starting the VM, that memory value will be shown as used in your host OS.
  • The amount of memory allocated to the machine for startup. After that the value will decrease or increase as needed (if the below checkbox is checked); this is more useful as a VM usually needs more RAM at startup than when it is sitting idle for example. The amount of memory used by the machine at a point in time is the only amount shown as used in the host OS.
Set RAM value and settings
Set RAM value and settings

    The network adapter can be plugged in a virtual switch in order to communicate with other machines on that device. The next screen lets you choose the switch you want. It is possible to leave the NIC unconnected which would be the equivalent to unplugging the network cable from a computer. We will see how to create switches in a later part of this series.

Configure the NIC
Configure the NIC

    Now comes the part to configure the HDD. It’s default location is the one that we set earlier and it’s name is the same as the VM’s name. These of course can be changed if you want. The size can be set to a high value if you think you need a lot of space in the VM. The actual size occupied by the hard disk file (.vhdx) on your host’s storage will expand as data on the virtual disk is added. If you set the size to 100 GB but only have 10 GB on it then it will take only 10 GB from your free space.

     There is the option to use an existing disk if available or no disk at all.

Add virtual HDD
Add virtual HDD

    The next and last thing to set is the installation method for the operating system. You have the option to not install an OS at this time, use an ISO image, use the CD-ROM drive or use a floppy disk image (this is for Generation 1 VMs). To install Windows from an ISO image just select that option and browse for the image file on your hard disk.

Set installation option
Set installation option

    Just click Next and Finish. The virtual machine was created and is visible in the Hyper-V Manager.

 

   In the next part we will go through a VM’s configuration settings.

 

Build a virtual test lab Part 1: Introduction

    Why build a test lab?

    If you are in college, already working or thinking of a career and believe IT is a good way to go, I say you have chosen a very interesting field. IT has many subdomains, each one fasciating in it’s own way: be it networking, system administration, storage administration etc. One big thing they have in common is that in oder for you to really learn the topics, you need to practice them. IT is a very hands on field: you can’t really say you understand how a product works if you only just read about it. The real learning part begins when you take what you read and implement it. This way you may encounter unexpected errors or issues that you did not read about but could happen. Solving the issues and advancing in testing that product is the important part.

    Since the blog is called About windows Server let’s take for example Windows administration. You want to begin in this world and read about installation methods for Windows Server. Usually such chapters have a lot of screenshots, each explained. You will really get the hang of installing servers when you actually install a server and experiment with different scenarios. Since we are talking about just testing different stuff, it is clear that you cannot do this on important equipment that should be left alone like production servers or network switches. The solution is to do the testing in a test lab.

    How do I build my test lab?

    Now that we got that covered, what options do we have for the test lab? The first one is to buy some second hand hardware like desktops, laptops, servers, network equipment, set them up somewhere and start playing. Second hand equipment can be found easily and not very expensive, cables to link everything are also common and if you are lucky you may have a room to set everything up and not annoy everyone in your house. The only poblem is that this sounds like a lot of work just to test some things when you are at the beginning, not to mention it costs some money and you need space.

    Let’s go back to the first sentence. Maybe you are in college, or maybe you are not woking, or maybe you just don’t have a lot of cash waiting around. How to build a test lab without buying all the test hardware? Virtualization to the rescue! Instead of spending money on second hand stuff that takes up space and takes time to set up just buy a powerful desktop PC and virtualize your machines. This is a more versatile way of testing different products and when you are done testing something just delete the virtual machines and create new ones to test something else. An important thing to note is that when getting to more advanced things, you will not be able to just us you vitual lab for everything. Some things require physical machines, for example testing the migration of VMs from a host to another.

    What configuration should I get?

    The subject of: is this configuration enough? is very debatable. Some will tell you that a specific PC is good for VMs the way it is, others will tell you it won’t do and you need something more robust. Keep in mind that the specifications I list in this section are based on how I tested and what I think works best for me. You are free to test creating and running VMs on what configuration you have.

    For my tests I use 2 PCs. One is a Core I5 4460 with 4 cores, 8 GB DDR3 1600 MHz and a 7200RPM Western Digital 500 GB HDD (the OS is on an SSD; the HDD is for the virtual machines and ISO images). After booting Windows I have about 5.5 GB of RAM left which is nough for simple test labs. The CPU is more than capable of running 4-5 VMs. The only drawback is that the HDD is not that fast when having a couple of virtual machines running at the same time. All in all this is OK. I used it and still use it for some tests.

    My other PC is a little more powerful and has the missing ingredient for speed when having a lot of VMs on at the same time: SSD for storing the virtual machine hard disks. The CPU is a Core I7 3770 with 4 cores and Hyper Threading (8 virtual cores), 16 GB DDR3 1600 MHz, a 120 GB SSD for the OS, a 240 GB for virtual machines and a 1 TB HDD for storage. The SSDs are not high end (they are Kingston V300) but running 5 or 6 VMs is a breeze. The amount of free RAM I have after booting Windows is about 12 GB. With regards to the processor, I am pretty sure a Core I5 would have done the job also as RAM and storage are the most utilized resources.

    The main thing I recommend is run your VMs from an SSD if possible. It will make a huge difference.

    What virtualization solution should I use?

    The virtualization product to use depens on some factors. If the PC you want to use for virtualization is also your only or primary computer then you may have Windows or a Linux distribution on it. In this case you have to install a virtualization program on your OS. If running Windows 7 or Linux try VirtualBox (free) or VMWare Workstation. VMWare is much better but it is not free. Both should work fine for a test lab. If running a newer Windows than 7 you could use the 2 solutions but there is a better one freely available in the OS. It is called Hyper-V and it’s Microsoft’s official virtualization product. This is what I will use in my blog posts.

    If you have a PC with the only purpose of running VMs then you can install a hypervisor. This is an OS that has the task of managing the hardware resources between virtual machines. No applications or user interface available. For this method you will need a second PC to manage the hypervisor and the virtual machines. The 2 products you can use for this are VMWare ESXi or Windows Server (Hyper-V server or the full OS).

 

    In the next part we will install Hyper-V on Windows 10 and create a VM.

 

Enable Powershell Remoting with Group Policy

 Powershell Remoting is getting more and more important, at least in the Windows Server space, as seen from Windows Server 2012 and onward. Now the Server Manager is based on PS Remoting so you can manage a big number of servers from only one Server Manager instance. It is also a very good tool for automation, configuration and troubleshooting on the Windows Server side but also on the Windows client side. The only thing to note is that if you want to use it on client operating systems and on Windows Server 2008 R2 you have to enable it.

  Note: This post is applicable for OSes from Windows 7/Windows Server 2008 R2 and up.

 In order for Powershell Remoting to be usable, 3 settings need to be configured:

  1. A listener that has the job to wait for incoming requests
  2. A firewall rule that permits the remoting traffic
  3. The WinRM service which implements the WSMan protocol which Powershell Remoting uses has to be running and it’s startup set to automatic delayed

   For some versions of operating systems some of these settings or all are already configured by default. If you have a complex infrastructure and want remoting on everything (clients and servers) all 3 settings will have to be configured. Let’s see what every OS has by default:

  • Windows Server 2012 and later server OSes have everything already set.
  • Windows Server 2008 R2 has the 3rd setting configured so if targeting this OS, just configure the first 2 settings
  • Windows client OSes from Windows 7 and up do not have any of the 3 settings configured so all 3 have to be set

    So if you only want remoting on servers and have just Windows Server 2012 and up, you are already done: remoting is enabled. In this post I will configure remoting for all scenarios so all 3 settings have to be touched. Now while remoting can be enabled manually, it is not the best thing when you have lots of machines; a good way is to use Group Policy. Below are the steps to do it:

  • If the settings will be placed in a new GPO then configure it; if not, edit an existing one.
Create a new GPO for Powershell Remoting
Create a new GPO for Powershell Remoting
  • Edit the GPO. Navigate to Computer Configuration -> Policies -> Administrative Templates Policy -> Windows Components -> Windows Remote Management (WinRM)
Navigate to WinRM settings
Navigate to WinRM settings
  • Now go to WinRM service and open Allow automatic configuration of listeners. This setting allows you to set the basic configuration settings for a WinRM listener (the listener waits for incoming remoting requests). Set it to Enabled and configura the filters. Filters let you configure the listener to allow connections only on a specific IP, more IPs, a range of IPs or no IPs from the remoting host. There are 2 filters because the listening process can be done on IPv4 and IPv6 and separate configurations can be set. In this case I will be configuring only the IPv4 address so I will put a * in the v4 field (this means: listen on al IPs that the host has). Leave the v6 field blank so remoting will not be permitted on IPv6 interfaces.
Configure WinRM listener for Powershell Remoting
Configure WinRM listener for Powershell Remoting
  • To configure the firewall rule for remoting navigate to: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security -> Windows Firewall with Advanced Security…. -> Inbound Rules
Navigate to the Powershell Remoting firewall rule
Navigate to the Powershell Remoting firewall rule
  • Configure a new predefined rule named Windows Remote Management
Configure new Powershell Remoting firewall rule
Configure new Powershell Remoting firewall rule
  • Uncheck the Windows Remote Management Compatibility setting. This is to listen for remoting on port 80 which is not recommended. Starting with Windows 7 and Windows Server 2008 R2 the default port for Powershell Remoting is 5985.
Disable Powershell Remoting Compatibility Setting
Disable Powershell Remoting Compatibility Setting
  • Allow the connection.
Enable Powershell Remoting firewall rule
Enable Powershell Remoting firewall rule
  • For Windows client OSes we need to also set the WinRM service to start automatically. Navigate to Computer Configuration -> Policies -> Windows Settings -> System Services and configure the Windows Remote Management service to start automatically.
Set the WinRM service to start automatically
Set the WinRM service to start automatically
  • Now link the GPO to an OU or to the domain and you are all set.

    Note: For the client settings, although the service is set to automatic, it will not be started by Group Policy; you either have to start it by other means or just wait for the computer to be restarted.

    One more thing to talk about is who is allowed to connect to servers/computers using Powershell Remoting. There are 2 possible answers to this query:

  • For Windows 7 and Windows Server 2008 R2 only the members of the local Administrators group have access to remoting
  • for anything newer than 7/2008 R2 there is the Administrators group and the Remote Management Users group

    This can be changed but as Group Policy cannot do it, we will not talk about this issue in the current post.

 

Set Powershell Execution Policy with Group Policy

    In an environment with lots of servers, automation is an important topic. In order to automate, you have to run scripts that do certain tasks. For Windows the preffered scripting language to use is of course Powershell. A challenge you will come across if trying to run scripts on Windows 7 or Windows Server 2008 R2 is the Powershell Execution Policy which is set to Restricted for these 2 operating systems.

    In a previous post I wrote a small intro to the execution policy and how to set it manually: Set Powershell Execution Policy. This is fine for a small number of servers but if you have a lot then a more enterprise level solution is required. One of the solutions is to use Group Policy. With it you can ensure that all the selected computers are configured and the configuration cannot be changed by someone locally on one of them because it is controlled centrally by Group Policy.

    The Powershell Execution Policy setting is present in the user part and in the computer part of the GPO. So this means that you have the possibility to set this option for specific users regardless of the machine on which they log on or to set it on specific machines regardless of the user that logs on and runs the script.

   Steps to set the Powershell Execution Policy with Group Policy

    This is an easy task which can be performed in 4 steps. In this example I am configuring a machine level setting.

  • In case you want this setting separate from others then create a new GPO. In my case I named it PS Exec Policy.
GPO for Powershell Execution Policy
GPO for Powershell Execution Policy
  • Now from the Computer Configuration part go to Policies, Administrative Templates, Windows Components, Windows Powershell
Navigating to the Powershell Execution Policy setting
Navigating to the Powershell Execution Policy setting
  • Enable the Turn on script execution setting and select one of the options. I recommend Allow local scripts and remote signed scripts. This is the RemoteSigned execution policy.
Set the Execution Policy value
Set the Execution Policy value
  • Link the GPO where you want it to apply. In my example I linked it to the Domain Controllers container which means that it will apply to any computer object in this container.
Link the GPO
Link the GPO

    And that’s it. Now you can wait for the policy to apply or update the Group Policy manually. You should then see the new setting.

Check Powershell Execution Policy
Check Powershell Execution Policy

    If you decide to set the policy at the user level please remember that it will apply to a specific user after a new logon.

Set Powershell Execution Policy

     About Powershell Execution Policy

    The Powershell Execution Policy is a security mechanism implemented in the Powershell engine that lets administrators have a tighter control on how scripts are run in the infrastructure or if they can be run at all.

    Controlling this settings actually means that the administrator gets to choose if a script has to be digitally signed with a certificate or not in order to be executed. There are 4 settings that you can choose for the executio policy:

  • Restricted – If this setting is active then no script can be run, not even if it’s signed.
  • AllSigned – All scripts that are executed on a host have to be signed.
  • ReoteSigned – Scripts run from a network path (that are not local to the server’s storage or the path is not in the form <Partition letter>:) have to be signed and the ones that reside on the server’s local storage can be executed regardless of their state. Also files can have an alternate stream of data that stores information of where the script came from; if the source is th “internet”, the script will not be executed.
  • Unrestricted – Unsigned scripts can be run from any path. This setting should be avoided as it is a security risk to permit unsigned scripts to be executed from anywhere.

   Configure the Powershell Execution Policy

    The execution policy is configured differently by default for some Windows versions than for others. For Windows Server 2008 R2 and Windows 7 it is set to Restricted. For operating systems newer then these 2 the default value is RemoteSigned.

    To see what setting you have configured just run the following Powershell command:

Get-ExecutionPolicy

    You will get as result the execution policy you use:

Show the Powershell Execution Policy
Show the Powershell Execution Policy

    You are most likely reading this post because you wanted to run a script but got the following error message: “File <your script> cannot be loaded because the execution of scripts is disabled on this system. If the answer is yes then I am happy to tell you the solution is simple: the Set-Execution policy command lets you set another value for the Powershell Execution Policy. For example to set it to RemoteSigned I would run:

 Set-ExecutionPolicy RemoteSigned 

    Accept the changes ad you are ready to run scripts.

Setting Powershell Execution Policy to RemoteSigned
Setting Powershell Execution Policy to RemoteSigned

    In my opinion, RemoteSigned is the best balance you can choose between security and “liberty”. Now running a script that is unsigned and located on the local host will not generate anny execution policy error.

Executing an unsigned local script
Executing an unsigned local script

    Running the same file from the same computer but using an UNC path should not work as can be seen from the below image.

Running a remote unsigned script
Running a remote unsigned script

    The Powershell Execution Policy command can be changed at any time using the Set-ExecutionPolicy command. The only requirement is to run Powershell in an elevated permissions mode. 

Open Command Prompt during Windows installation

    This is a small tip on how to bring up a Command Prompt window while Windows is installing. I have tested this solution on Windows 7, Windows Server 2008 R2, Windows 8.1 and Windows 2012 R2, but it should work on every operating system newer than Windows Vista or Windows Server 2008, including them.

    Using this method you can open a CMD window during the first part of an installation, in WinPE, and also after the restart, until Windows is fully booted up (with some exceptions).

    The keyboard combination that opens the Command Prompt is: SHIFT + F10

    This works for example after booting from CD/DVD/USB up until the computer restarts.

Command Prompt in WinPE
Command Prompt in WinPE

    After that you can use this method during the Installing drivers phase or The setup is preparing your computer for first use phase. This is very cool as you can troubleshoot failing device drivers for example.

Command Prompt during Preparing your computer for first use part
Command Prompt during Preparing your computer for first use part

    Another time during the installation when I found this method useful is near the end when in Windows 7 for example you are asked to specify a user name or when in Windows Server you are asked to choose an Administrator password. For the client OS it is especially useful as you can run Sysprep without creating a user account.

Command Prompt during user account creation
Command Prompt during user account creation