Where has “Desktop Experience Mode” gone from Windows Server 1709?

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.

Release channels and installation options

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:


Maintaining on-premises drive letters for VMs protected by ASR

You have a virtual machine running on-premises and all applications have been installed on the D drive. This machine is protected by Azure Site Recovery and in the event that the machine is failed over to Azure, the drive letters must remain the same.

By default Azure virtual machines are assigned temporary storage and the normal behaviour is for this to assign itself to the drive letter D. Under this scenario the on-premises D drive would then be assigned the next free drive letter of E as the virtual machine powers up in Azure. Obviously this would have massive impact on the applications running on this virtual machine.

For more information on the temporary storage added to Azure virtual machines have a look at this article What is this temporary storage?

It is possible to make sure that drive letters are maintanted when on-premises virtual machine failover to Azure, forcing the temporary storage to append itself at the end. To do this we need to set the SAN policy to “OnlineAll

To view the current SAN policy from the guest system, follow these steps:

1. On the VM (not on the host server), open an elevated Command Prompt window.
2. Type diskpart.
3. Type SAN.


If the drive letter of the guest operating system is not maintained, this command returns either “Offline All” or “Offline Shared.”

To make sure that all disks are brought online and are both readable and writeable, set the SAN policy to OnlineAll. To do this, run the following command at the DISKPART prompt:



NOTE: One thing to keep in mind is that even when this change has been made to the local running virtual machine, you need to make sure that this change has been replicated to ASR as part of the next recovery point, before attempting a failover.

As a final check, it would be worth running a test failover to verify that the drive letters are preserved as required.

For more information about SAN policy, see this Azure Support Team Blog article


Managing VMs stuck in the ‘Starting’ or ‘Stopping’ state in Hyper-V

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$($"}


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.



Shared Nothing Live Migration

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:

  • Configuring constrained delegation against each hosts AD account
  • Configure the local host settings to enable live migration
  • Performing a Shared Nothing Live Migration on a chosen virtual machine

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
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.


Best practices for migrating a datacenter from VMware to Microsoft Hyper-V

A great post from MCS Consultant Giuseppe Di Federico about the tools available when beginning a migration project from VMware to Hyper-V. Some great information about the various tools, when each fits best and some lessons learnt along the way.

The article focuses on the very first step of the transition from VMware to a Microsoft based datacenter: The virtual machine migration.

Best practices for migrating a datacenter from VMware to Microsoft Hyper-V


Microsoft Cloud Solutions Workshop


Listening to the feedback from past attendees and following on from the recent Transforming the Datacentre, Enterprise Mobility and Microsoft Azure Workshops, we are now hosting a new event that aims to cover all of the key areas that we believe are of benefit to the enterprise. This short event is set at a high level and designed to quickly review new technologies available to help improve real world business.

Areas covered during the event include:

Building your private cloud on Windows Server 2012 R2

Today’s applications need a modern platform that enables IT to manage all datacentre resources across multiple clouds, supports apps that scale dynamically, unlocks insights on data anywhere and enables you to securely deliver a personalised experience to any device anywhere. Microsoft’s cloud approach delivers a consistent and comprehensive set of capabilities via Windows Server 2012, System Center 2012, Windows Azure and SQL Server 2012, that will help you take advantage of the cloud on your terms, without fear of lock-in.

Extending your private cloud with Microsoft Azure

What is Azure? In short, it’s Microsoft’s cloud platform: a growing collection of integrated services – compute, storage, data, networking and app – that help you move faster, do more and save money. But that’s just scratching the surface. Join our workshop to find out what else Azure is can do.

Mobilise your workforce with Enterprise Mobility Suite

The Enterprise Mobility Suite is the comprehensive cloud solution to address your consumerisation of IT, BYOD, and SaaS challenges. The suite is the most cost effective way to acquire all of the included cloud services:

  • Microsoft Azure Active Directory Premium
  • Microsoft Intune
  • Microsoft Azure Rights Management

To book a place at one of these events, follow the link available below.


Error (20413) VMM encountered a critical exception and created an exception report

I was recently asked to look at a problem when a Hyper-V cluster would not allow SCVMM to place one of its managed hosts into maintenance mode. Additionally when attempting to live migrate the one remaining VM on the host, this also failed with the error below.

Error (20413)
VMM encountered a critical exception and created an exception report at C:\ProgramData\VMMLogs\SCVMM.c3c48c04-4d3e-4dfa-b3e2-ec11d408f7b5\report.txt.

Recommended Action
See the report for more details and search user forums for well-know failure root causes for self-help.

Scvmm Error 20413

The first thing that was checked was the configuration of the VM but there were no obvious problems at first glance. Scanning through the SCVMM console, I came across an old .ISO file which had become an Orphaned Resource. The old resource was no longer used and from an old SCVMM Library share that had been since removed.


On attempting to delete the object, VMM threw an error ID: 848 and wouldn’t allow the deletion of the object because it had objects apparently dependant on it.


Reviewing the Orphaned Resources dependencies it was interesting to see that the object with dependencies was a checkpoint attached to the VM that wouldn’t migrate of the host that I was having problems with.


On checking the VMs hardware configuration there were no .ISO attached.


But there was a single checkpoint!


On checking the properties of this checkpoint, it differed to the current configuration and had attached the .ISO file that was currently stuck in Orphaned Resources.


To resolve the issue, the checkpoint had to be removed from the VM (which can now be done on a live VM thankfully) then it was possible to remove the orphaned resource. Once this had been done, the VM was free to migrate around the cluster and maintenance mode began to work again as well as manual live migrations.

On reviewing the problem with the client, it was discovered that the .ISO files had been attached to VMs using the “Share file instead of copying it” option.


It appears that whilst in this configuration, a checkpoint of the VM had been made and only after this the .ISO file been detached from the VM and the file share detached from SCVMM. On attempting a live migration or placing the host into maintenance mode, SCVMM was failing to do so because it was unable to enumerate all of the VMs dependency’s.

Interesting little error.


SAN Replication and DR with Azure Site Recovery – Now Generally Available!

Today, Microsoft announced, the General Availability release of Enterprise-Grade Array-Based Replication and Disaster Recovery with ASR and System Center. This offers the ability to leverage replication capabilities of existing Storage Area Network (SAN) Arrays to enable high performance synchronous and asynchronous replication across on-premises Hyper-V Sites. Integrated with System Center Virtual Machine Manager (SCVMM) and Azure Site Recovery, managing the whole DR process.

To read more on this check out this Azure blog announcement Enterprise-Grade Array-Based Replication and Disaster Recovery with ASR and System Center – Now Generally Available!



Helpful Cmdlets

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.


Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

I have recently seen an increase in the interest from clients wishing to invest in DR and Backup to the cloud. Azure Site Recovery Services has many offerings for various scenarios, with additional options appearing all the time. I have discussed Azure Backup Vault in previous posts and no doubt will touch on it again in the future, but today I have chosen to look at DR and Azure Site Recovery.

So what is ASR?

‘Azure Site Recovery helps you to protect important applications by coordinating the replication and recovery of physical or virtual machines. You can replicate to your own datacenter, to a hosting service provider, or even to Azure to avoid the expense and complexity of building and managing your own secondary location.’  Microsoft

Essentially, Microsoft Azure Site Recovery offers the ability to simplify and automate DR between two on-premise site or between on-premise and Azure.

As I write this the options are:


Microsoft are developing ASR rapidly and additional functionality is always appearing, with much to come in Q1 and Q2 of 2015.

For this particular post I will be focusing on the Between an on-premises VMM site and Azure option.


  • An Azure Subscription
  • System Center Virtual Machine Manager 2012 R2
  • Windows Server 2012 R2 Hyper-V – used as VM host
  • Fixed disk .VHD or .VHDX (Generation 1 only VMs)
  • Guest OS Windows Server 2008 or later or Linux: Centos, openSUSE, Ubuntu

More details on requirements and planning are located here:

Setting Up the Azure Site Recovery Vault:

The first step to configuring DR between an on-premises VMM site and Azure is to create a Site Recovery Vault. To do this, open the Azure Portal and select the Recovery Services tab on the left menu.


Next click + NEW  at the bottom of the screen which opens the window required to create a Site Recovery Vault and a Backup Vault. Select Site Recovery Vault, then give the vault a name and select the region where the data should be stored.

A full list of Regions can be found at


After the job has completed, the new Site Recovery Vault appears as Active.


Configuring the Hyper-V and VMM servers:

Now the ASR Vault has been created, the next step is to configure the local Hyper-V and VMM servers. Click on the new ASR Vault to open its Dashboard.


Download the ASR Provider and Registration key. Install the ASR Provider on the VMM server and register against the ASR Vault by using the registration key.

NOTE: If you are running VMM in HA, the first step is to install the ASR provider on the active node, then register the server. Then secondly install the ASR provider on the passive node.


Return back to the Dashboard and then select to Add an Azure Storage Account.


Give the storage account a name (lowercase case and numbers only). Select the location of the storage account and the chosen level of redundancy.

Option Redundancy Comments
Locally Redundant 3 copies replicated within a single datacentre CheapestProtects against hardware failureDoes not protect against loss of facility or region
Zone-Redundant 3 copies replicated between 2 or 3 datacentres in a single region Protects against hardware failureProtect against loss of facilityDoes not protect against loss of region
Geo-Redundant 6 copies replicated 3 times within the primary region and 3 times in a secondary region Maximum durabilityProtects against hardware, facility and regional lossRecommended as default
Read-Access Geo-Redundant Same as Geo-Redundant, additionally grants Read-Access in the secondary region in the event of primary region loss Maximum durability and availabilityMost expensive

Once the storage account has been successfully created, it will appear under the Storage tab of the Azure Portal.


The final step is to download the Azure Recovery Services Agent and install on all hyper-V hosts. When installing the agent, the agent is smart enough to detect if there is a previous version present and attempt to upgrade it.

This is how the Azure Recovery Services Agent looks when its upgrading a previous version.


Now the Azure Recovery Services Agent has been installed on all the Hyper-V servers, this seems a natural point to end this first post. In summary, the on-premises Hyper-V and VMM servers have been configured and registered to the created Azure Site Recovery Vault. Everything is now in place to begin configuring the protection of on-premises clouds and resources.

The next part of this post will include:

  • Configuring cloud protection
  • Managing virtual machine protection
  • Changing the hardware sizing of virtual machines
  • Mapping networks
  • Recovery plans
  • Failover options.

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Two

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three