Azure | Hyper-V | SCVMM | RDS | DPM Technical Blog – Michael Coutanche
On Wednesday 12th December, I will be co-hosting alongside James Boother (Coeo) and Microsoft for our final webinar of the year ‘Beyond SQL Server 2008’
The webinar will take you through the ins and outs of unsupported platforms and how to modernise following the end of Server 2008 and SQL Server 2008 support.
Register here: https://hubs.ly/H0fMnBp0
The RDP client is one of the most heavily utilised tools in a system administrator’s toolkit. There are alternatives, for example, console access, PowerShell, iLO or in the case of a physical machine the locally connected keyboard and monitor. This is fine for on-premise machines but for machines running in the cloud, most of the alternative methods are not an option and RDP becomes a critical method of connectivity.
Over the past months I have seen an increase in the number of customers that have adjusted the guest Windows OS firewall, inadvertently locking themselves out and making it impossible to manage their Azure virtual machines.
The following article outlines one of the methods I have successfully used when restoring access. This method makes use of the Azure virtual machine Custom Script Extension and a snippet of PowerShell.
1. The first step is to open your preferred PowerShell editor and paste in the following code.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy
\DomainProfile' -name "EnableFirewall" -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\
PublicProfile' -name "EnableFirewall" -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\
Standardprofile' -name "EnableFirewall" -Value 0
These commands update local registry values which in turn disables the three firewall profiles on the next machine reboot.
A copy of the file can be downloaded from my GitHub disablefw.ps1.
2. Save the file as <filename>.ps1
3. Now login to the Azure portal and browse to the virtual machine that is having connectivity problems.
4. From the blade of the virtual machine, select Extensions
5. Click the +Add button and select Custom Script Extension from the popup menu.
6. Click on the folder icon to browse to where the <filename>.ps1 file has been stored and after selecting the file, click Open to upload it.
7. The virtual machine extension can now be installed by clicking OK.
NOTE: Additional Arguments are optional and for this task should be left blank.
8. Once the extension is installed, the Azure portal will report that provisioning has been successful.
9. It’s now time to restart the virtual machine before retrying an RDP connection.
This has proven to be very useful to me on a number of occasions, hopefully it will be of assistance to others.
As always, if any mistakes are spotted, feel free to leave me a comment.
First of all don’t panic, Windows Server Desktop Experience Mode has not gone for good!
Although for sometime now core has been seen as the preferred version of Windows Server for the enterprise. From experience, most customers will still end up installing the full GUI version.
So why remove it from the latest Windows Server release 1709?
Windows Server, version 1709 is the first release in the new Semi-Annual Channel for Microsoft. The Semi-Annual Channel release is aimed at customers such as those that have a rapid development path or perhaps those acting as hosting companies who wish to keep up with the latest Hyper-V investments. Microsoft plans for Windows Server products in the Semi-Annual Channel to be released twice a year, with each release in this channel being supported for 18 months from the initial release. Microsoft have stated that, most of the features introduced in the Semi-Annual Channel will be rolled up into the next Long-term Servicing Channel release of Windows Server. However, the actual editions, functionality, and supporting content might vary from release to release depending on customer feedback.
Windows Server as we know it with the full Desktop Experience Mode will become the Long Term Service Channel of Windows Server 2016. If you want to stay in this channel, you should continue to install Windows Server 2016, which can be installed in Server Core mode or Server with Desktop Experience Mode.
These changes will call for a more informed discussion during project initiation phases. Choosing the correct OS will be based not only on the need for the latest and greatest features, but also an acceptable upgrade cycle for the business, whether the customer is comfortable supporting Windows Server Core and if the the technology being deployed as part of the proposed solution is supported. For example, Remote Desktop Service (RDS) would not take advantage of the new Semi-Annual Channel where as Hyper-V would.
Both releases will be supported with security updates and non-security updates but feature updates to the LTSC would happen less frequency purely due to its release cycle.
| Installation option | Semi-Annual Channel (Windows Server) | Long-term Servicing Channel (Windows Server 2016) |
|---|---|---|
| Nano Server | Yes | No |
| Server Core | Yes | Yes |
| Server with Desktop | No | Yes |
For much more on this subject, checkout this Microsoft blog:
https://docs.microsoft.com/en-us/windows-server/get-started/semi-annual-channel-overview
It’s sometimes necessary to manually change the network location configuration of a Windows 2012 R2 Servers network connection. There are two common approaches to this, either by Local Group Policy or PowerShell. In this post I will be stepping through how to implement either method.
Windows classifies networks connections into one of three profiles, each profile configures the server with different firewall settings.
By default new network connections are configured with the public profile, however, if ADDS (Active Directory Domain Services) are found on the network, the profile automatically changes to domain.
Changing the Network Location by Local Group Policy
1. Run gpedit.msc to open the Local Group Policy Editor
2. Navigate to Computer Configuration / Windows Settings / Security Settings / Network List Manager Policies and double click the appropriate Network Name
3. From the popup window select the Network Location tab, then select the correct location type
4. Click OK and close the Local Group Policy Editor
5. Finally checking back in the Network and Sharing Center, the network profile should now display the options chosen in the previous steps.
Changing the Network Location by PowerShell
As with most things on Server 2012 it is possible to use PowerShell to change the network category. We first need to list the network connections and make note of the InterfaceIndex associated with the network connection we are looking to reconfigure.
1. Open an elevated PowerShell prompt and run the following CmdLet
Get-NetConnectionProfile
2. Make note of the InterfaceIndex for the network connection that requires its location changing. We can then use the following command to change the connections network location type
Set-NetConnectionProfile -InterfaceIndex <ID> -NetworkCategory <Category>
For Example:
Set-NetConnectionProfile -InterfaceIndex 12 -NetworkCategory Private
3. To confirm changes have been made, rerun the Get-NetConnectionProfile CmdLet and review the NetworkCategory reflects the change.
With many of the recent events slowly drawing to a close, I thought it worth making note of some of the ones I will be involved with during the second half of the year.
Transform the Datacentre Workshop with Microsoft
Transform the Datacentre Workshop with Microsoft
Azure Round Table Workshop
The Azure round table events have been very successful and we have had lots of positive feedback. For this reason new dates and locations have been added to the current schedule. This workshop is high level and starts with an overview of the Azure platform and then concentrates around some of the key areas that we believe offer the most value to customers. Numbers dependant, we are usually able to adjust the contents depending on attendees areas of interest.
NEW Azure Webinar
For anyone who is unable to attend the round table events, a new Azure webinar is being offered which can be better tailored towards your enterprise requirements.
To find out more on these events and others checkout Latest News and Events
Every now and then, Hyper-V virtual machines for various reasons decide that they don’t want to start or stop correctly and get stuck in the ‘Starting’ or ‘Stopping’ state.
This is a bit of a pain and the last thing we want to do as an administrator is have to migrate all the other virtual machines to reboot the Hyper-V host. Especially if the host is managing large numbers of running machines or is not part of a cluster and migrating the other running machines may take sometime or impact their running in any way.
One way its possible to kill off that stuck virtual machine is to open Task Manger and end the task responsible for that machine. Unfortunately its not quite that simple because the Virtual Machine Worker Process which is responsible for running the virtual machine appears numerous times, once for each running guest machine!
So how do we differentiate between them?
1. First we need to open Task Manger and view the process tab
2. Then right click on the column titles and add in the Command Line column
3. Expand the Command Line column to view the full command, including the machine GUIDs at the end of each line
4. Browse to the location where the virtual machines are stored and open the folder of the virtual machine which is currently hung. From here we can find the machine configuration file and make note of the GUID for that machine
5. Now we know which GUID relates to the virtual machine that we are looking to stop. Jump back to Task Manger, right click on the correct process and End Process
NOTE: this process should only be used as a last resort as it could cause corruption of the virtual machine!
Another way to locate the GUID of the machines running on the server is to use PowerShell to output the machine names and associated GUID
Get-VM | Select Name, Id
There are various way to work out which virtual machine is which Virtual Machine Worker Process in Task Manager.
In Task Manger, it is also possible to add the Process ID column as well as the Command Line and then work out which process is attached to which VM.
I don’t confess to be the best at putting together PowerShell commands but the line below pulls a list of virtual machine names and GUIDs then compares that to a list of GUIDs in the Command Line of the processes running and returns virtual machine names with the associated Process ID.
Get-WmiObject Win32_Process -Filter "Name like '%vmwp%'" | %{$vm=get-vm -id $_.CommandLine.split(" ")[1];"$($_.processID)`t$($vm.name)"}
Once we have the list of machine names and Process IDs we can then return to Task Manger and end the correct process.
Another alternative to Task Manger would be to Sysinternals Process Explorer which can be downloaded and used instead.
UPDATE: AD Connect is now on Public Preview 2 and in “Pilot Mode” 20/03/2015
There are currently various tools to allow administrators to integrate their on-premises AD environments with Azure depending on organisational requirements. Microsoft recently released another tool which is currently in public preview that could potentially take the place of them all!
Azure AD Connect is a simple, integrated tool for connecting your existing Windows Server Active Directory with Azure Active Directory. Azure AD Connect has the ability to connect your on-premises AD to Azure AD with as few as 4 clicks, but also the ability to allow a much more customised configuration if required.
Microsoft boast “Now you can get started using Azure AD in under an hour, no new hardware required!”
NOTE: The preview available at the writing of this post, does NOT support production deployments in this release. It is suggested that the next release will support production deployments. Azure AD Connect also allows an administrator to configure a Exchange Hybrid deployment, password change write-back, AD FS and Web Application Proxy.
Prerequisites:
The first step to the process is to download the AD Connect tool to the machine from which the Sync will be run. The link for the AD Connect tool can be found in the prerequisites above.
Using a Domain Administrator account, run the AD Connect tool. On the first window, check the box to agree to the licensing terms, then click Continue.
The next windows lists the prerequisites that require installing, so just click Install if your happy for the tool to begin downloading and installing these prerequisites.
The next window is where the tool requires the details of an Azure AD account. The Azure AD Account must be of a Global Administrator role. The credentials are used for the configuration process and the account and password are not stored or used once the wizard has been run.
The following window gives you the option to use the Express settings or Customize your configuration. For the purpose of this post I have chosen to use the Customize option, but will not be configuring all the options this makes available.
If selecting the Customize option, the next window gives you the ability to choose the sign-in experience.
After choosing the sign-in experience, the next window is used to enter the connection information for your on premises directories or forests.
Once the directory details have been input, click Add Directory to add the directory to the Azure AD Connect tool. Then click Next.
The next window gives the ability to choose one of the two current optional features. Either Exchange hybrid deployment or Password write-back.
The next window gives the options available to choose from to select how users should be identified in your on premise directories.
Configure the preferred Source Anchor and User Principle Name attributes in the next window.
The next screen is the Review Options window. Check the Start the synchronization as soon as the initial configuration completes if this is what you require. Then click Install.
Once the install is complete the wizard will display the Configuration Complete screen below. At this point the basic install and integration between your on premises and Azure AD is complete.
Testing the on premises integration with Azure AD
To test the integration and sync is working, create a new on premises AD account using Active Directory Users and Computers and check that the user is synchronised and appears in Azure AD.
Once the user account has been created you need to wait for a sync to happen. If you wish to perform a manual/forced sync, you can use the “DirectorySyncClientCmd.exe” application.
Once the synchronisation has completed, either naturally or forced, the test user should appear in Azure AD.
For another quick check, browse to the Directory Integration tab of the Azure AD settings and you will see that Directory Sync is now enabled and when the Last Sync was run.
Obviously there is a lot more to be able to configure and tweak as required but hopefully this post will give you a quick insight into Azure AD Connect and the power and simplicity its beginning to offer.
Since Hyper-V 2008 administrators wishing to migrate VMs from one Hyper-V host to another have been able to achieve this with either a “Quick Migration” or “Live Migration“. Since the introduction of the “Shared Nothing Live Migration” in Windows Server 2012, it has even been possible to migrate a running VM from one host to another with nothing more in common than a basic network connection.
The process involved in migrating a VM is a fairly simple, however to get the environment ready is a little more tricky. This post will step through the configuration required and the process involved in migrating a virtual machine using the “Shared Nothing Live Migration” technology built into Hyper-V on Windows Server 2012 R2.
The process can be broken down into three sections:
Configure Constrained Delegation:
1. Firstly log into SBHost1 using an account with Domain Admin rights, then open up Active Directory Users and Computers.
2. Locate the AD accounts of the source and target Hyper-V hosts.
3. Right click on the first Hyper-V hosts and select Properties.
4. On the Properties window, select the Delegation tab.
5. On the Delegation tab, select the Trust this computer for delegation to specified services only and Use Kerberos only options and click the Add button.
6. In the Add Servers windows, click on Users or Computers.
7. In the Enter the object names to select window, enter the name of the host you wish to delegate rights to and then click Check Names before clicking OK.
8. In the Add Service window, select the cifs and Microsoft Virtual System Migration Services service types, and then click OK.
9. Back on the Properties windows of SBHost1, check that the service types have been added as appropriate and then click OK.
10. To complete the constrained delegation configuration, repeat the process for the second host. In this example SBHost2.
Configure Host Settings for Live Migrations:
1. Open Hyper-V Manager on SBHost1 and add SBHost2 to Hyper-V manager. This is not essential but it will make the next step a little easier as we can complete all configuration from the one console.
2. Right click SBHost1 and select Hyper-V Settings from the menu.
3. In the Hyper-V Setting window for SBHost1, select Live Migration in the left menu window. In the right window, firstly select Enable incoming live migrations, then select Use these IP addresses for live migration. Finally click the Add button and entering the IP range of the network allowed for Live migrations. In this example 172.16.0.0/16.
4. Click Apply
5. Below the Live Migrations page of the Hyper-V settings menu, expand the Advanced Features page. Select Use Kerberos as the authentication protocol and Compression as the performance option. Click Apply then OK to close the Hyper-V settings window and confirm the settings.
Performing a Shared Nothing Live Migration:
1. From one of the Hyper-V hosts open Hyper-V Manager, right click on the virtual machine you wish to migrate and select Move.
2. On the first page of the Move Wizard, click Next.
3. The next page requires you to chose the type of move you wish to perform. For a Shared Nothing Live Migration select Move the virtual machine and then click Next.
4. Enter the name of the target host in the Name field, and then click Next.
5. Next select how you wish to manage the virtual machines items, such as virtual disk and configuration file. Select Move the virtual machine’s data by selecting where to move the items and then click Next.
6. To move the virtual machine to the target server whilst keeping the same file structure it had on the source server, select Move the virtual machine’s data automatically and then click Next.
7. Review the Summary, then click Finish.
8. Having clicked Finish, the move begins and a process bar is displayed by the Move Wizard.
During the migration, Hyper-V Manager displays the state of the migration by showing the percentage completed. One way to check that the virtual machine remains online during the migration is to connect and monitor it through the console. Another option is to run a ping -t against the virtual machine to confirm there is no drop in connectivity during the migration.
The Shared Nothing Live Migration was a great addition to Hyper-V and well worth playing with if you haven’t already.
Over the past few years when deploying Hyper-V, SCVMM or Windows Clustering, I have found myself searching around for little snippets of PowerShell or Cmdlets to make basic configuration changes to the environments. I know there are some fantastic scripts out there that will step you from the beginning to end of full builds, but on many occasions, these short one or two liners have been of great help.
If all goes to plan, I will add additional posts to the series with similar content.
Changing the metrics of a cluster network
(Get-ClusterNetwork “CSV Network”).Metric=900
Revert the network back to autometric
( Get-ClusterNetwork “Cluster Network 1” ).AutoMetric = $true
The network metric is used by windows to determine which network should be sued for CSV communications when cluster shared volumes are installed. The lowest metric network would be chosen for this purpose with the second lowest being designated for live migration. (It is possible to also select a live migration network from within the GUI)
Check ODX Status (return value 0 = ODX enabled, return value 1 = ODX disabled)
Get-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name “FilterSupportedFeaturesMode”
Disable ODX
Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name “FilterSupportedFeaturesMode” -Value 1
ODX is a feature that allows Windows to move or copy data from one device to another or one location on a device to another location on the same device without transferring the data through the windows device. Essentially offloading the workload to the device and speeding up the transfer.
Disable TRIM
fsutil behavior set disabledeletenotify 1
Re-Enable TRIM
fsutil behavior set disabledeletenotify 0
SCVMM 2012 R2 displays duplicate VMs
Get-VM “DuplicateVM” | Where Cloud -eq $Null | Remove-VM -force
This command will remove the VM from the SCVMM DB, yet leave the VM on the Hyper-V host/Cluster. Once removed from SCVMM, refresh the cluster to reregister the VM in SCVMM.
Discover WWN info from a Hyper-V host using PowerShell
Open up a powershell with administrator privileges, then run: Get-InitiatorPort
Fibre Output:
iSCSI Output:
Disable all disconnected Adapters on a Hyper-V host
Get-NetAdapter -Physical | Where-Object {$_.Status -eq “Disconnected”} | ` Disable-NetAdapter }
How to add host management credentials to Hyper-V Hosts in SCVMM that are greyed out via the console
Open PowerShell and Import the SCVMM Module, or open SCVMM PowerShell from the top ribbon in the SCVMM console.
$YourCluster = Get-SCVMHostCluster -Name YOUR-CLUSTER-NAME
$YourRunAs = Get-SCRunAsAccount -Name “YOURRUNASACCOUNT”
Set-SCVmHostCluster -VMHostCluster $YourCluster -VMHostManagementCredential $YourRunAs
Replace YOURRUNASACCOUNT with VMM Run as account and YOUR-CLUSTER-NAME with name of cluster. It can take a minute to run, but afterwards your hosts in the cluster will be managed with the new Run As account. You can right click on any host and go to properties > Host Access to verify.
I have recently been involved in designing and deploying a Hyper-V and SCVMM environment for Landmarc Support Services. They have since spoken at Microsoft Future Decoded, based around the road map used in building a private cloud within the MOD.
https://www.youtube.com/watch?v=eME3e6eW47Y&feature=youtu.be