Share via

Remote Desktop Services – Upgrade guidelines for Windows Server 2012 R2

  • Article

 

1 Supported OS upgrades with RDS role installed

 

       

Upgrades from Windows Server 2012 R2 MP (Milestone Preview) to Windows Server 2012 R2 will not be supported.

This document outlines the supported upgrades and interoperability for RDS features, as per Windows Client and Server guidelines.

1.1  Windows Server 2008 R2 to Windows Server 2012 R2

For RDS, we support upgrade only for the following role services (see table below):

  1. RD Gateway
  2. RD Licensing

For all other roles (RD Session Host, RD Virtualization Host, RemoteFX, RD Web Access, RD Connection Broker) upgrade is blocked (same as for upgrades from  Windows Server 2008 R2 to Windows Server 2012): administrators will need to uninstall the role, upgrade the OS, and then install the role again.

1.2  Windows Server 2012 to Windows Server 2012 R2

Upgrade is supported for all RDS role services (see table below):

  1. RD Gateway
  2. RD Licensing
  3. RD Session Host
  4. RD Virtualization Host (with RemoteFX vGPU)
  5. RD Web Access
  6. RD Connection Broker

 

The following matrix shows the RDS role services that are supported when upgrading from the version listed to Windows Server 2012 R2:

  

 

 RDG

RDL

RDSH

  RDVH

RDWA

RDCB

Windows Server 2008 R2

ü  

ü  

û  

û  

û  

û  

Windows Server 2012

ü  

ü  

ü  

ü  

ü  

ü  

 

2 Deployment upgrade – recommended flow

 

Based on the table above, upgrading in production deployments from Windows Server 2008 R2 to Windows Server 2012 R2 will not work without down time and redeployment.

Upgrading Window Server 2012 to Windows Server 2012 R2 deployments it is possible. The deployment will be down only during the server(s) upgrade. Following the steps below will keep the down time limited to the duration of RD Connection Broker server(s).

We recommend the following flow:
**

  1. RD Connection Broker server**(s) should be the first to be upgraded. If there is active/active (AA) setup in the deployment - all servers should be upgraded in the same time.*** 
    The deployment will not be available during RD Connection Broker server(s) upgrade.***

*** NOTE: It is mandatory to upgrade RD Connection Broker server – we do not support Windows Server 2012 RD Connection Broker server in a mixed deployment with Windows Server 2012 R2 servers.*** *Once the RD Connection Broker server(s) are running Windows Server 2012 R2 the deployment will be functional, even if the rest of the servers in the deployment are still running Windows Server 2012.

*2. RD Session Host server(s) can be upgraded next to avoid down time during upgrade the admin can split the servers to be upgraded in 2 steps detailed below. All will be functional after the upgrade.

**     To upgrade the RD Session Host servers:**

        2.1   Step 1

            2.1.1       Select a number of servers to be upgraded (i.e. half of the RD Session Host servers in the deployment)

            2.1.2       Prevent new connections on the servers to be upgraded (set Allow New connections = false)

            2.1.3       All sessions on the servers should be logged off

            2.1.4       Remove all servers to be upgraded from the collection

        2.1.5       Upgrade the servers to Windows Server 2012 R2

  

    2.2   Step 2

            2.2.1       Prevent new connections on the reaming servers (second half) to be upgraded in the collection (set Allow New connections = false)

            2.2.2       Add back the upgraded servers to the collection

            2.2.3       Repeat Step 2.1.3 – 2.1.5 for the second half of servers to be upgraded.

            2.1.4       Add the upgraded servers back to the collection.

 

NOTE: If the admin decides to upgrade all servers at once, the steps 2.1.1 to 2.1. 4 and 2.1.6 to 2.1.7 will need to be followed.

*** ***

3. RD Virtualization Host server(s) upgrade:

 

3.1 Standalone RDVH servers in the deployment: the servers should be upgraded all at once. Follow   the following steps to upgrade

  • Log off all users
  • Turn off/Save all virtual machines (VMs) on each host
  • Start upgrading the servers to Windows Server 2012 R2
  • Once up – all collections should be available and functional and the users can start connecting.         

3.2 Multi-RDVH server environment to be upgraded where Cluster Shared Volumes (CSV) is used for VM storage:

  • Determine an upgrade strategy where some of the RDVH servers will be upgraded and some will continue to host VMs on Windows Server 2012. 
  • Isolate one or more of the RDVH server(s), targeted for the initial round of upgrading, by migrating all VMs to other ‘not to be upgraded yet’ RDVH server(s) which will remain part of the original 2012 cluster.
    • Open Failover Cluster Manager.
    • Select ‘Roles’
    • Select one or more VMs. Right click to open the context menu.
    • Select ‘Move’ and choose either ‘Live or Quick Migration’ to move the VM(s) to one or more of the RD Virtualization Host Servers that are not part of the initial upgrade. Use ‘Live’ or ‘Quick’ Migration depending on factors such as hardware compatibility or online requirements etc.
  • Evict the RD Virtualization Host Server(s), prepared for upgrading, from the original cluster.
  • Upgrade the isolated RD Virtualization Host server(s).
  • After the targeted RD Virtualization Host Server(s) have been successfully upgraded, create a new cluster and CSV which needs to be on an entirely different SAN volume.           
  • Join all upgraded RD Virtualization Host Server(s) to the new cluster.
  • Create a folder structure in the new CSV which mimics the existing folder structure in the existing CSV. This will include the collection folder(s) and each VM’s top level subfolder(s).
  • From the various VM Collection folders on the original CSV, copy over the ‘IMGS’ folder and contents on to the new collection folder(s) in the same location(s) on the new CSV.
  • On the source RDVH machine, use Cluster Manager to ‘Remove’ the VM’s configuration for ‘high availability’:
    • Launch Cluster Manager.
    • Select the ‘Roles’ node.
    • Right click on the VM objects and select ‘Remove’.
  • On one of the non-upgraded RD Virtualization Host servers, use Hyper-V Manager to ‘Move’ all VMs to one of the upgraded RDVH Servers and new Cluster CSV:           
    • Open Hyper-V Manager.
    • Select one of the non-upgraded RD Virtualization Host servers.
    • Select one of the VMs to be moved, right click on it to open the context menu.
    • Select ‘Move’, the Move Wizard open.
    • Choose ‘Move the virtual machine’ and click ‘Next’.
    • Provide the targeted upgraded RDVH server’s name on the ‘Specify Destination Computer’ page and click ‘Next’.
    • Choose ‘Move the virtual machine’s data to a single location’ and click ‘Next’.
    • Browse to the Destination location.

 

IMPORTAINT*: Insure this path is to an empty folder for the specific VM.*

NOTE*: As mentioned, you will need to pre-create a new destination sub folder prior to this step. The Select Folder dialog will not allow for creation of the appropriate sub folder in this step. Click ‘Next’. Click ‘Finished’.* 

  • Once the VM(s) are relocated, add them as cluster ‘High Availability’ objects.
    • Open ‘Failover Cluster Manager’ on an upgraded RD Virtualization Host Server.
    • Select the ‘Roles’ node and right click to open the context menu. Select ‘Configure Role …’. The ‘High Availability Wizard’ dialog will open. Select ‘Next’ on the Start page of the wizard.
    • On the ‘Select Role’ page, choose ‘Virtual Machine’ from the list of available choices. Click ‘Next’. A list of VMs that are not configured will be shown.
    • Select all the VMs. Click ‘Next’. Click ‘Next’ again on the confirmation page to start the configuration task. The VMs will now be configured for ‘High Availability’.
  • Once all VMs have been relocated, upgrade the remaining RDVH Servers. Use the above steps for balancing VM locations as appropriate.

3.3 Multi-RDVH server environment to be upgraded without using Cluster Shared Volumes (CSV) for VM storage:

  • Determine an upgrade strategy where some of the RD Virtualization Host servers will be upgraded and some will continue to host VMs on Windows Server 2012. 
               
  • Isolate one or more of the RDVH server(s), targeted for the initial round of upgrading, by migrating all VMs to other ‘not to be upgraded yet’ RD Virtualization Host server(s) which will remain part of the original Windows Server 2012 cluster.
               
    • Open Failover Cluster Manager.
    • Select ‘Roles’
    • Select one or more VMs. Right click to open the context menu.
    • Select ‘Move’ and choose either ‘Live or Quick Migration’ to move the VM(s) to one or more of the RDVH Servers that are not part of the initial upgrade. Use ‘Live’ or ‘Quick’ Migration depending on factors such as hardware compatibility or online requirements etc.
  • Evict the RD Virtualization Host Server(s), prepared for upgrading, from the original cluster.
  • Upgrade the isolated RD Virtualization Host server(s).
  • After the targeted RD Virtualization Host Server(s) have been successfully upgraded, create a new Windows Server 2012 R2 cluster node           
  • Join all upgraded RD Virtualization Host Server(s) to the new cluster node
  • Disconnect the SAN from Windows Server 2012 cluster and add it to the new Windows Server 2012 R2 cluster
  • Import all VMs from the SAN on the newly upgraded RDVHs
  • Once the VM(s) are relocated, add them as cluster ‘High Availability’ objects.
    • Open ‘Failover Cluster Manager’ on an upgraded RD Virtualization Host Server.
    • Select the ‘Roles’ node and right click to open the context menu. Select ‘Configure Role …’. The ‘High Availability Wizard’ dialog will open. Select ‘Next’ on the Start page of the wizard.
    • On the ‘Select Role’ page, choose ‘Virtual Machine’ from the list of available choices. Click ‘Next’. A list of VMs that are not configured will be shown.
    • Select all the VMs. Click ‘Next’. Click ‘Next’ again on the confirmation page to start the configuration task. The VMs will now be configured for ‘High Availability’.
  • Once all VMs have been relocated, destroy the Windows Server 2012 cluster and upgrade the remaining RD Virtualization Host Servers.

 

NOTE:

  • Heterogeneous Hyper-V servers in a cluster are not supported.

*** ***

4. RD Web Access server can be upgraded anytime.

NOTE: Windows Server 2012 RDWA will work with Windows Server 2012 R2 deployment.

 

5.  RD License Server can be upgraded anytime.

NOTE: we support Windows Server 2012 RD Licensing in a Windows Server 2012 R2 deployment

*** ***

6. RD Gateway server can be upgraded anytime – will work with all OS versions.

NOTE: we support Windows Server 2012 RD Gateway in a Windows Server 2012 R2 deployment

 

3 VDI deployment – supported guest OSs

 

On Windows Server 2012 R2 RD Virtualization Host servers we support the following guest OSs:

  1. Windows 7 Sp1 Enterprise
  2. Windows 8 Enterprise
  3. Windows 8.1 Enterprise

The table below shows the supported RD Virtualization Hosts operating systems and guest operating system combinations:

  

RDVH OS Version

Guest OS Version

Windows 2012 R2

Windows 7 SP1, Windows 8, Windows 8.1

Windows 2012

Windows 7 SP1, Windows 8, Windows 8.1

** **

NOTE:

  • We do not support heterogeneous collections. All VMs in a collection must be same OS version.
  • We do support having separate homogeneous collections with different guest OS version on the same host.

 

4 VDI deployment – supported guest OS upgrade

 
Administrators will have the following options to upgrade of VM collections:

4.1 Upgrade Managed Shared VM collections

 Administrators will create a gold image with the desired OS version and use it to patch all the VMs in the pool.

We support the following patching scenarios:

  1. Windows 7 SP1 can be patched to Windows 8 or Windows 8.1
  2. Windows 8 can be patched  to Windows 8.1

4.2 Upgrade Unmanaged Shared VM collections

End users cannot upgrade their personal desktops. Administrators should perform the upgrade. The exact steps are still to be determined.