-->

• Azure Rds Farm Deployment
• Azure Rds Cals
• Azure Rds Pricing
• Azure Rds Vm
• Azure Rds Cal

Windows Virtual Desktop is a comprehensive desktop and application virtualization service running in the cloud. It's the only virtual desktop infrastructure (VDI) that delivers simplified management, Windows 10 Enterprise multi-session optimizations for Microsoft 365 Apps for enterprise, and support for Remote Desktop Services (RDS) environments. Deploy and scale Windows desktops and applications on Azure in minutes, and get built-in security and compliance features.

• Remote Desktop Services (RDS) Farm - Virtual Desktop Solution (VDI) Deploy a Remote Desktop Services (RDS) 2019 farm with a new Active Directory 2019 Domain. Fully automated IaaS deployment. The perfect solution to setup a basic RDS IaaS farm in Azure as a Windows virtual desktop infrastructure service solution (VDI,VDS).
• Creating a Highly Available Windows 2012 R2 RD Gateway Environment with Azure Multi-Factor Authentication.

If this was for your employees, you would use RDS User CAL with Software Assurance (SA) for each unique person that will connect to your RDS environment in Azure/AWS. You cannot use RDS Device CAL for this case either.

Azure Rds Farm Deployment

Note

This article focuses on using Windows Virtual Desktop in Azure to move an on-premises RDS environment to Azure.

Business drivers

Working closely with business partners, the Contoso IT team will define the business drivers for a VDI migration to Azure. These drivers might include:

• Current environment end-of-life: A datacenter is out of capacity when it reaches the end of a lease or is closing down. Migrating to the cloud provides virtually unlimited capacity. Current software might also be reaching its end of life where it has become necessary to upgrade the software running Contoso's current VDI solution.
• Multi-session Windows 10 VDI: Provide Contoso users with the only multi-session Windows 10 desktop virtualized in the cloud that's highly scalable, up to date, and available on any device.
• Optimize for Microsoft 365 Apps for enterprise: Deliver the best Microsoft 365 Apps for enterprise experience, with multi-session virtual desktop scenarios providing the most productive virtualized experience for Contoso's users.
• Deploy and scale in minutes: Quickly virtualize and deploy modern and legacy desktop applications to the cloud in minutes with unified management in the Azure portal.
• Secure and productive on Azure and Microsoft 365: Deploy a complete, intelligent solution that enhances creativity and collaboration for everyone. Shift to Microsoft 365 and get Office 365, Windows 10, and Enterprise Mobility + Security.

RDS on-premises to Windows Virtual Desktop in the cloud goals

With the business drivers in mind, Contoso has pinned down goals for this migration:

• Modernize the virtual desktop environment for the cloud.
• Take advantage of existing Microsoft 365 licenses.
• Improve security of corporate data when users work remotely.
• Optimize the new environment for cost and growth.

These goals support the decision to use Windows Virtual Desktop and validate it as the best migration method for Contoso.

Benefits of running Windows Virtual Desktop in Azure

Using Windows Virtual Desktop in Azure, Contoso can now seamlessly run, manage, and scale its VDI solution quickly and easily. The company also can provide an optimized multi-session Windows 10 environment to its users.

Contoso will capitalize on existing Microsoft 365 licenses while using the scale, performance, security, and innovation of Azure.

Additional benefits might include:

• Access to Windows Virtual Desktop from anywhere.
• Optimized Microsoft 365 Apps for enterprise environment.
• Windows Virtual Desktop for dev/test environments.

Solutions design

After pinning down goals and requirements, Contoso designs and reviews a deployment solution and identifies the migration process.

Current architecture

RDS is deployed to an on-premises datacenter. Microsoft 365 is licensed and in use by the organization.

Proposed architecture

• Sync Active Directory or Azure Active Directory Domain Services.

• Deploy Windows Virtual Desktop to Azure.

• Migrate on-premises RDS servers to Azure.

• Convert user profile disks (UPDs) to FSLogix profile containers.

  Figure 1: Proposed architecture.

Solution review

Contoso evaluates the proposed design by putting together a list of pros and cons.

Migration process

Contoso will move VMs to Windows Virtual Desktop in Azure by using the Lakeside assessment tool and Azure Migrate. Contoso will need to:

• Run the assessment tool against its on-premises RDS infrastructure to establish the scale of the Windows Virtual Desktop deployment in Azure.

• Migrate to Windows Virtual Desktop via either Windows 10 Enterprise multi-session or persistent virtual machines.

• Optimize the Windows Virtual Desktop multi-session by scaling up and down as needed to manage costs.

• Virtualize applications and assign users as needed to continue to secure and manage the Windows Virtual Desktop environment.

  Figure 2: The migration process.

Scenario steps

1. Assess the current RDS environment.
2. Create the VDI and new images in Azure and migrate and persist VMs to Azure.
3. Convert UPDs to FSLogix profile containers.
4. Replicate any persistent VMs to Azure.

Step 1: Assess the current on-premises environment

Azure Rds Cals

Contoso will provision the Windows Virtual Desktop service in the East US 2 Azure region. With Windows Virtual Desktop, Contoso can provision virtual machines, host pools, and create application groups. Windows Virtual Desktop also configures an availability set for all the servers in the Windows Virtual Desktop solution. Windows Virtual Desktop allows Contoso to create a high-available VDI environment and to scale up and down quickly as needed.

Note

Contoso reviewed two scenarios during the assessment: multi-session (shared) instances of RDS and persistent (or user-dedicated) virtual machines.

1. Make sure that domain services, either Active Directory or Azure Active Directory Domain Services, are synchronized with Azure Active Directory (Azure AD). Ensure the domain service is accessible from the Azure subscription and virtual network to be connected where Windows Virtual Desktop will be deployed.

   Note

   Learn more about Azure AD Connect for synchronizing Active Directory on-premises with Azure AD.

   Note

   Learn about provisioning Azure Active Directory Domain Services and synchronizing Azure AD to it.

2. Create a new Azure Migrate project.

   Figure 3: Creating a new Azure Migrate project.

3. Select the option to assess and migrate servers, select VDI, and add a tool.

   Figure 4: Target Azure Migrate goals.

4. Set the subscription, resource group, project name, and geography for the migrate job data.

   Figure 5: Adding job data to the migration.

   Important

   This location isn't where the new Windows Virtual Desktop environment will be deployed. Only the data related to the Azure Migrate project will be stored here.

5. Select Lakeside: SysTrack as the assessment tool.

6. Select Azure Migrate: Server Migration as the migration tool.

7. Add the tools to the migration project.

   Figure 6: Adding tools to the migration.

8. Start the assessment of the current environment by selecting Register with Azure Migrate in the Lakeside tool.

   Figure 7: Assessing the current environment.

9. Contoso connects Azure Migrate and Lakeside, and accepts any requested permissions.

   Figure 8: Connecting Azure to Lakeside.

10. Contoso continues with the Lakeside tool to create a new tenant and start assessing the current on-premises RDS environment. From the dashboard, Contoso can access the deployment guide, download the assessment client to deploy to the current environment, and review the data collected from these agents.

    Figure 9: The Lakeside dashboard.

11. After an adequate amount of data is captured, Contoso reviews the assessment data to determine the best migration path. This assessment data includes the raw assessment data from the desktops data and the data broken into different user personas. This information includes the:

• Number of users in each persona.

• Applications in use by users.

• Resource consumption by user.

• Resource utilization averages by user persona.

• VDI server performance data.

• Concurrent user reports.

• Top software packages in use.

  Figure 10: Lakeside dashboard reports.

The data is analyzed by Contoso to determine the most cost-effective use of both pooled Windows Virtual Desktop resources and personal Windows Virtual Desktop resources.

Note

Contoso will also need to migrate application servers to Azure to get the company closer to the Windows Virtual Desktop environment and reduce network latency for its users.

Step 2: Create the Windows Virtual Desktop environment for pooled desktops

Using the Azure portal, Contoso will create a Windows Virtual Desktop environment to use for pooled resources. Later, it will go through the migration steps to attach personal desktops to the same environment.

1. Contoso selects the correct subscription, and creates a new Windows Virtual Desktop host pool.

   Figure 11: A new Windows Virtual Desktop host pool.

2. Specify the subscription, resource group, and region. Then select the name for the host pool, desktop type, and default desktop users. Desktop type is set to Pooled because Contoso is starting with a new shared environment for some of its users. Default desktop users can be left blank. Move on to configure the virtual machines.

   Figure 12: Prerequisites for configuring virtual machines.

   • Contoso configures the VM and chooses a custom size by selecting Change size or using the default.
   • Windows Virtual Desktop is chosen as the VM name prefix for these pooled desktops.
   • Because Contoso is creating the pooled servers to use the new Windows 10 Enterprise multi-session functionality for the virtual machine settings, leave the image source set to Gallery. This option enables Contoso to select the Windows 10 Enterprise multi-session image for the VMs.
   • Based on the personas of the users from the Lakeside assessment, Contoso sets the total users to 150.
   • Other settings include the disk type, an Active Directory domain join UPN field, an admin password, an optional OU path to which machines are added, the virtual network, and a subnet for adding servers.

   Figure 13: Configuring virtual machines.

   Note

   Contoso can't create a new virtual network at this step. Before reaching this step, Contoso should have already created a virtual network that has access to Active Directory.

   Note

   Contoso can't use a user account that requires multi-factor authentication in this step. If Contoso plans to use multi-factor authentication for its users, it will need to create a service principal for this purpose.

3. Contoso performs one more validation of the Windows Virtual Desktop settings, and creates the new environment of pooled Windows Virtual Desktop virtual machines.

   Figure 14: Reviewing and creating virtual machines.

Step 3: Convert the UPDs to FSLogix profile containers

Because Windows Virtual Desktop doesn't support user profile disks (UPDs), Contoso needs to convert all the UPDs to FSLogix via the FSLogixMigration PowerShell module.

After Contoso imports the FSLogixMigration module, it runs the following PowerShell cmdlets to migrate from UPDs to FSLogix.

Important

The PowerShell modules for Hyper-V, Active Directory, and Pester are prerequisites to running the cmdlets to convert UPDs to FSLogix.

A UDP conversion:

A roaming profile conversion:

At this point, the migration has enabled using pooled resources with Windows 10 Enterprise multi-session. Contoso can begin to deploy the necessary applications to the users who will use Windows 10 Enterprise multi-session.

But now Contoso must migrate the persistent virtual machines to Azure.

Step 4: Replicate and persist VMs to Windows Virtual Desktop

The next step in the migration process for Contoso is to migrate its persistent virtual machines to Windows Virtual Desktop. To do this, Contoso goes back to the Azure Migrate: Server Migration job it created at the beginning of the process.

1. Contoso starts by selecting Discover in the Azure Migrate: Server Migration tools.

   Figure 15: Discovering a server migration.

2. Contoso converts an appliance in its environment that's going to manage the replication of the machines to Windows Virtual Desktop. Ensure that the target region is set to East US 2, where the Windows Virtual Desktop environment was created.

   Figure 16: Converting an appliance.

3. The replication provider is downloaded, installed, and registered to the Azure Migrate project to start the replication to Azure.

   Figure 17: Prerequisites for replicating to Azure.

4. The replication of the hosts into Azure Blob Storage is now started. Contoso can continue to let the replication occur until it's ready to test the VMs and then migrate them into production.

   • As machines start running in Azure, Contoso makes sure to install the Windows Virtual Desktop VM agent on each machine.
   • As a part of the installation, enter the registration token for the Windows Virtual Desktop environment to associate the server with the correct environment.

5. The registration token can be obtained by using the following commands:

   Note

   Contoso can also automate this process by using msiexec commands and passing in the registration token as a variable.

6. As the last step before the final migration, Contoso selects the Users item in the Azure Windows Virtual Desktop settings to map the servers to their respective users and groups.

   Figure 18: The last step prior to the final migration.

After host pools are assigned to users, Contoso finalizes the migration of those machines and continues to gradually migrate the rest of the on-premises VDI hosts to Azure.

Review the deployment

With the virtual desktops and application servers now running in Azure, Contoso now needs to fully operationalize and secure the deployment.

Security

The Contoso security team reviews the Azure VMs to determine any security issues. To control access, the team reviews the network security groups (NSGs) for the VMs. NSGs are used to ensure that only traffic allowed to the application can reach it. The team also considers securing the data on the disk by using Azure Disk Encryption and Azure Key Vault.

For more information, see Security best practices for IaaS workloads in Azure.

Business continuity and disaster recovery

For business continuity and disaster recovery (BCDR), Contoso backs up the data on the VMs by using Azure Backup to keep data safe. For more information, see An overview of Azure VM backup.

Licensing and cost optimization

• Microsoft 365 licenses are used for the desktop deployments.
• Contoso will enable Azure Cost Management + Billing to help monitor and manage the Azure resources.
• Contoso has existing licensing for its VMs and will take advantage of the Azure Hybrid Benefit for application servers. Contoso will convert the existing Azure VMs to take advantage of this pricing.

Azure Rds Pricing

Conclusion

In this article, Contoso moved its RDS deployment to Windows Virtual Desktop hosted in Azure.

You can use Azure AD Domain Services (Azure AD DS) in your Remote Desktop Services deployment in the place of Windows Server Active Directory. Azure AD DS lets you use your existing Azure AD identities in with classic Windows workloads.

With Azure AD DS you can:

• Create an Azure environment with a local domain for born-in-the-cloud organizations.
• Create an isolated Azure environment with the same identities used for your on-premises and online environment, without needing to create a site-to-site VPN or ExpressRoute.

When you finish integrating Azure AD DS into your Remote Desktop deployment, your architecture will look something like this:

To see how this architecture compares with other RDS deployment scenarios, check out Remote Desktop Services architectures.

To get a better understanding of Azure AD DS, check out the Azure AD DS overview and How to decide if Azure AD DS is right for your use-case.

Use the following information to deploy Azure AD DS with RDS.

Prerequisites

Before you can bring your identities from Azure AD to use in an RDS deployment, configure Azure AD to save the hashed passwords for your users' identities. Born-in-the-cloud organizations don't need to make any additional changes in their directory; however, on-premises organizations need to allow password hashes to be synchronized and stored in Azure AD, which may not be permissible to some organizations. Users will have to reset their passwords after making this configuration change.

Azure Rds Vm

Deploy Azure AD DS and RDS

Use the following steps to deploy Azure AD DS and RDS.

Azure Rds Cal

1. Enable Azure AD DS. Note that the linked article does the following:

   • Walk through creating the appropriate Azure AD groups for domain administration.
   • Highlight when you might have to force users to change their password so their accounts can work with Azure AD DS.

2. Set up RDS. You can either use an Azure template or deploy RDS manually.

   • Use the Existing AD template. Make sure to customize the following:

     • Settings

       • Resource group: Use the resource group where you want to create the RDS resources.

         Note

         Right now this has to be the same resource group where the Azure resource manager virtual network exists.

       • Dns Label Prefix: Enter the URL that you want users to use to access RD Web.

       • Ad Domain Name: Enter the full name of your Azure AD instance, for example, 'contoso.onmicrosoft.com' or 'contoso.com'.

       • Ad Vnet Name and Ad Subnet Name: Enter the same values that you used when you created the Azure resource manager virtual network. This is the subnet to which the RDS resources will connect.

       • Admin Username and Admin Password: Enter the credentials for an admin user that's a member of the AAD DC Administrators group in Azure AD.

     • Template

       • Remove all properties of dnsServers: after selecting Edit template from the Azure quickstart template page, search for 'dnsServers' and remove the property.

         For example, before removing the dnsServers property:

         And here's the same file after removing the property:

   • Deploy RDS manually.