*Important:
The PowerShell cmdlets named in the article aren’t available yet. We’ll update this article when we publish the cmdlets.
The Fall 2019 release of Windows Virtual Desktop provided PowerShell cmdlets and REST APIs to create a service environment. It also created service objects. When we talk about "objects" in the service environment, we mean objects Windows Virtual Desktop creates, such as tenants, host pools, application groups, and session hosts.
The one drawback of the Fall 2019 version of Windows Virtual Desktop is that it isn't automatically Azure integrated. This means that objects you create with the Fall 2019 release aren't automatically managed by the Azure portal, as they aren't connected to your Azure subscription.
The Spring 2020 update marks a shift in the Windows Virtual Desktop service towards full Azure integration. This means that any objects created with the Spring 2020 update are automatically managed by the Azure portal. In the future, all service objects will be integrated with the Azure service and the customer's Azure account.
This article will explain why you should migrate to the latest update of Windows Virtual Desktop, and how to do it.
Why migrate?
Major updates can be inconvenient, especially ones you have to do manually, so let’s see why migration couldn’t be done automatically:
- Existing service objects made with the Fall 2019 release don't have any representation in Azure. Their scope doesn't extend beyond the Windows Virtual Desktop service.
- When the Spring 2020 update became a first-party Azure service, the service's application ID changed. New Azure objects with Windows Virtual Desktop can’t be created, unless authenticated with the new application ID.
Let’s go through why migration to the Spring 2020 update is important. With the Spring 2020 update, you can:
- Manage Windows Virtual Desktop through the Azure Portal.
- Assign Azure Active Directory (AD) user groups to application groups.
- Use the improved Log Analytics feature to troubleshoot your deployment.
Our team is committed to making the migration process as quick and easy as possible, so we’ve made sure your users can stay on their Windows Virtual Desktop sessions during the migration process.
Prepare for migration
Before you start the migration, make sure you have the following things:
- An Azure subscription where you’ll create new Azure service objects
- You need to be assigned the Contributor role to create Azure objects on your subscription, and the User Access Administrator role to assign users to application groups.
- You need at least RDS Contributor permissions on an RDS tenant or the specific host pools you’re migrating.
- The latest version of the PowerShell module for the Fall 2019 release.
Important:
Migration currently only creates service objects in the US geography. You can't migrate the objects to a different geography with the tools currently available. When the service supports creating objects in other geographies, follow the process in “Migrate to a new geography.”
Migrate using service-provided cmdlets
Migration will be done using the PowerShell cmdlets.
- Run Start-RdsHostPoolMigration.
- Input the following information:
- Specify whether you're migrating all host pools within a tenant or just a single host pool.
- Specify a user assignment mode for the existing user assignments:
Copy mode copies all user assignments from Fall 2019 app groups to Spring 2020 app groups, leaving the existing user assignments as-is. Users will be able to see feeds for both versions on their clients. Move mode copies all user assignments from Fall 2019 app groups to Spring 2020 app groups, then deletes the existing user assignments on Fall 2019 release app groups. Users will only be able to see the feed from the Spring 2020 app groups on their clients. None mode doesn't change the user assignments. You have the option to assign users or user groups to app groups with the tools provided by the Spring 2020 update, such as the Azure portal, PowerShell cmdlets or API.
Note: You can choose to output the topology mapping between the two sets of resources, without performing the actual migration.
Once you've entered the information, wait about 15 minutes for the service objects to be created in the subscription and resource groups you specified. If you copied or moved user assignments, that will take some extra time for the assignments to complete.
Once authentication is done, you should have the following:
- Azure service objects for the tenant or host pool you specified.
- Based on your input, users might have also been published to the newly created app groups.
- Virtual machines will be available in both existing and new host pools to avoid user downtime during the migration process. This lets users connect to the same user session.
- Next, make sure you have all RBAC permissions and diagnostic setup for the new Azure service objects. Once initial user connections are validated, you can choose to also publish the app group to more users or user groups.
- Finally, run Complete-RdsHostPoolMigration to finish migration for the tenant or host pool you're moving into the Spring 2020 update. This will delete all service objects created by the Fall 2019 release. You'll be left with just the new Azure objects and users will only be able to see the feed for the newly created app groups on their clients.
Note:
If you aren't ready to finalize the migration and want to wait until a later date to migrate your Fall 2019 service objects, run Revert-RdsHostPoolMigration and your newly created service objects will be deleted. Users will only see the feed for the Fall 2019 version in their clients. If you chose Move in step 1, you won’t be able to revert the user assignment, which means you’ll have to republish the app groups to users.
If you don't want to get rid of your Fall 2019 service objects, you can run Set-RdsHostPoolHidden instead. This will hide the Fall 2019 user feed and the Fall 2019 service objects instead of deleting them. This gives you the option of reverting later if you choose to but operate as if you have completed the migration.
Migrate to a new geography
- The current migration process only migrates service objects to US geography. If your organization needs to store metadata in a different geography (when the service allows objects to be created in the geography of your choice), here's how to migrate manually: Create the whole environment using the Azure portal by following the instructions in Create a host pool with the Azure portal.
- If you want to repurpose the virtual machines you currently use, you can manually register them to the newly created host pool by following the instructions in Register the virtual machines to the Windows Virtual Desktop host pool.
- Create new RemoteApp app groups.
- Publish users or user groups to the new desktop and RemoteApp app groups.
To avoid or minimize downtime, register existing session hosts in small increments to the ARM-integrated host pool for the Spring 2020 update and slowly migrate users over to the new ARM-integrated app groups.
Continued support for Fall 2019 release
We'll continue supporting and maintaining the environment and tools for the Fall 2019 release for now. However, new features will only be added to the Spring 2020 update. To keep up with the latest Azure features in Windows Virtual Desktop, we recommend you migrate to the Spring 2020 update as soon as possible. If you have any feature suggestions, submit your idea along with your scenario on our UserVoice forum at https:///aka.ms/wvdfbk.
