Desktops and Applications
Virtualizing and migrating desktops and applications to Azure comes into play when your users run applications that don’t work well across a WAN, like QuickBooks. Most client/server applications with a desktop-installed client component are designed for LAN environments where the server and data are located close to the client app running on desktops.
Separating such desktop apps from their data sources by placing the data in the cloud can create an unacceptable end-user experience and poor performance. Desktop virtualization technologies such as Remote Desktop Services (RDS) and Windows Virtual Desktop (WVD) are designed to overcome such end-user experience challenges by allowing the client application to run in the same physical location as the data on the server, sending only screenshots down to the end-user.
Another common scenario for migrating desktops and applications to Azure are in environments with high requirements for privacy and data regulation. Virtualizing the end-user desktop environment creates a network perimeter that is easily defendable against data loss and cyber security threats. Centralizing the data and servers in the cloud,and moving a users’ desktop environment allows IT administrators to control what’s allowed to enter, and - more importantly - exit the network perimeter. By using RDS/WVD technology, data never leaves Azure: only transient screenshots. This way a lost laptop won’t contain any company data, since the only way the user could interact with the system was through a virtual desktop session.
Migrating desktops and applications to Azure is unfortunately not simple, and requires a good understanding of the existing desktop environment. It will also require the ability to properly spec and deploy a cloud environment that provides the right functionality, the best possible end-user performance, and a cost-effective price point.
Now we’ll look at two popular technologies from Microsoft: RDS and WVD.
Remote Desktop Services (RDS)
RDS is a mature and well-known desktop virtualization technology introduced 20 years ago with Windows Server 4.0 Terminal Edition. The current version allows MSPs and IT administrators to fully oversee the control and connection plane of the RDS environment, by installing the various RDS roles (e.g. connection broker, gateway, web access, etc.) on a set of manageable VMs.
The typical RDS deployment uses a Windows Server operating system to run multi-session VMs, where multiple users have a virtual desktop session on the same machine that shares that VM’s resources. The desktop experience looks and feels like Windows 10 with Server 2016, but is missing some Windows 10 functionality.
Windows Virtual Desktop (WVD)
WVD is a brand new, Azure-only set of technologies introduced by Microsoft in 2019 that allows MSPs and IT administrators to use the true Windows 10 Enterprise operating system in either single or multi-session mode. With WVD, there is no longer a need for MSPs to install and manage control plane roles, since these are hosted and managed by Microsoft as a managed service. WVD is also fully integrated with Azure AD and supports Multifactor Authentication (MFA) and Conditional Access (CA) technologies from Azure AD. Microsoft anticipates most, if not all, virtual desktop deployment in the future will use the WVD model and run in Azure.
For a deeper look at the differences between RDS and WVD, check out the following articles:
Published Desktop vs. RemoteApp
Desktops and applications can be deployed in two ways. A published desktop is a way of delivering a full virtual desktop with all applications installed on it. Think of it as the equivalent of a physical desktop with Office, Windows Explorer, internet browsers, a Start menu, and every other desktop component delivered in a window that can be maximized to take over the entire screen, or resized to take up just a portion.
A RemoteApp is a way to publish a single application, like Word, to a remote user. When a user opens this application, it opens in its own window and appears to run just like a native application. It is visible on the task bar and can be moved around the screen or from one monitor to another.
Which One is the Right Choice?
Under the hood, both RemoteApps and published desktops operate on top of a desktop virtualization technology like RDS or WVD. With published desktops, the user has the Explorer.exe shell with all its functionality, while with RemoteApps, the shell of the remote session is set specifically to the application that’s being published. Once the application is closed, the user session is terminated, and the account is logged in.
RemoteApps are a common way to publish a single (or small number) of individual applications to users who are otherwise working on their local device. For instance, if users use SaaS applications primarily but there is one legacy, rarely-used application that must be virtualized, it should be published as a RemoteApp. There’s no need to give a user access to a complete virtual desktop to run a single application.
On the other hand, if a user operates multiple virtualized applications, publishing the entire desktop improves the end-user experience since there is only one session to log into, and all applications are pre-installed on that published desktop. Also, if an organization encourages virtual desktop use for all corporate IT use and discourages the use of local devices for storage of sensitive company information, a published desktop is the way to go. Both RDS and WVD support published desktop and RemoteApp deployment scenarios, and it is very easy to switch from one to the other.
There aren’t too many options when it comes to virtualizing and migrating desktop applications to Azure. It is not recommended to take an existing desktop image and try to make it work in the cloud as part of an RDS or WVD deployment. The best practice is to create a brand-new desktop image VM (either Server 2016 with RDS or Windows 10 Enterprise with WVD) and install all applications.
When creating virtual desktops, it is important to consider everything that these desktops will interact with.
These considerations include:
- Access to local files
- Speakers, microphones and webcams
- Hardware license keys and other USB devices
The recommended method for virtual desktop printing is via the network. A site-to-site VPN tunnel should be established between the Azure IT environment and the local network where the network printer is located. Printer objects are defined on a print server VM, and then mapped to individual virtual desktop sessions--or defined on the virtual desktop VM itself. These printer objects use TCP/IP network ports and point at the IP of the printer device on the local network across the VPN. Static IP assignment is recommended. Users print from the virtual desktop session via a print server, or directly to the physical printer over the network. This can be done regardless of where the end-user is physically located. For example, a user working from home can print to their network printer in the office, since the network connected via site-to-site VPN is always available.
If it is not possible to use network printing, printer redirection can be used. It is not as reliable as network printing but is supported under most virtual desktop scenarios. Microsoft RDP and WVD come with built-in printer redirection functionality from the client apps running on local PC or Mac devices. There are also many third-party printer redirection providers like ThinPrint that optimize the printer redirection experience. When using printer redirection, local printers available on a user’s specific device become visible inside of the virtual desktop session and can be selected from any application’s print dialog box. With such a setup, it is only possible to print to a locally attached printer (via USB for example) while the virtual desktop session is connected. As soon as the session is disconnected, the printer is no longer available.
Finally, if no printer redirection or network printing is possible, a user can print-to-PDF from their virtual desktop, transfer the file to their local computer or mobile device, and print it from there. This is not an elegant solution, and not one that most users will be happy with in the long-term, but is available as a workaround when needed.
As with printing, the recommended connectivity method is via the network, rather than USB. Network-attached scanners can be pointed to scan to email or scan to a file folder on a server. This scanning method bypasses the user’s desktop altogether and scans directly to a location - like email or file share - that the user can access. This means that scanning can be accomplished whether the virtual desktop session is open or not.
Many users have personal, USB-attached scanners at their desks. In order to work, the virtual desktop deployment must support scanner redirection or USB redirection. The native scanner and USB redirection functionality in RDS is not as robust and reliable as some of the available third-party solutions, such as RemoteScan and Fabulatech. Many deployment scenarios in healthcare and check scanning use these third-party products with great success and reliability.
A popular workaround for remote scanning is to scan with the USB scanner locally into a folder that’s accessible via the virtual desktop session. For example, there may be a file server share that can be accessed via the local user’s desktop where the scanner is attached and the virtual desktop where the scanned document is needed. The user would scan locally into this shared folder and then pull up the scanned file from the virtual desktop session.
Access to Local Files
There are a few options for users to access local files from within their virtual desktop session. Whether this functionality is enabled depends on the security policy of the organization. Some organizations restrict users’ ability to copy files to and from local devices into the corporate virtual desktop environment.
RDW and WVD clients allow for local drive redirection from the physical device the user is using and makes those drives visible within the virtual desktop session. They come up under This Computer within Windows Explorer and work just like any other network or local drive. Users can drag and drop files, copy and paste, and so on. The transfer happens over the network, and transfer speed is largely determined by the throughput of the line connecting the user’s physical device to their virtual desktop in Azure.
Another popular, and often better-performing, file access method is via the use of common shared locations or OneDrive. Users can map a network drive from both their local device and virtual desktop session to a common folder on the network, and use that folder as a transfer mechanism between the two systems.
OneDrive is another excellent way to make files available on multiple devices. If the OneDrive client is installed and configured on both the local and virtual desktop, any files copied to the OneDrive folder will be available in both places. This is usually the fastest method of data transfer, since OneDrive uses network connectivity efficiently, and is capable of multi-threaded file transfer.
Speakers, Microphones and Webcams
Multimedia I/O devices can be redirected and used in virtual desktop sessions. However, the performance will be worse compared to their local versions, since large amounts of data have to traverse an oftentimes slow WAN connection. Audio output (speakers) typically works very well in a virtual desktop session. Audio input (microphone), on the other hand, is hit-or-miss and will depend heavily on the quality of the internet connection. It is usually not recommended to use VoIP or audio recording inside of virtual desktop sessions.
Webcams accentuate the connectivity challenge, given the amount of data that is transferred with encoded video and audio. Webcam redirection experience in virtual desktops sessions is usually poor, and is not recommended.
Hardware License Keys and Other USB Devices
Some applications rely on a hardware key connected via USB to operate. This presents a unique challenge in a virtual desktop environment where multiple end-user, physical devices can be used to access the same remote virtual desktop session. However, this can be easily remedied with a Network USB Device Server like a Silex DS-510. Multiple USB devices can be plugged into this Network USB Device Server, and the server plugs into any network port on the local network with site-to-site VPN connectivity. A driver and a small application are installed inside of the virtual desktop session, which discovers the Network USB Device Server via the VPN tunnel, presenting any of the attached USB devices to the virtual desktop as though they were locally attached.
This connectivity method is not only useful in supporting applications protected with USB keys, but it can also be used for unique scanning, audio, and video USB redirection. What makes Network USB Device Scanners efficient is their encoding of USB traffic before it is sent via the network. The raw USB traffic is compressed - or encoded - at the source, and then decompressed - decoded - at the destination virtual desktop session. This allows many USB devices to work, even across WAN connectivity.
With over 1,000 Azure cloud deployments and migrations over the past 10 years, Nerdio has seen it all; pure cloud and hybrid cloud, files and email tools, LOB applications, directory, and virtual desktops of all flavors. A cloud migration is by no means trivial - but can be very successful with proper preparation.
Our Partner Solutions team helps hundreds of MSPs onboard thousands of their customers to Microsoft Azure with the help of Nerdio’s Azure automation platform – Nerdio for Azure. It is the definitive solution for MSPs working on building a successful and profitable cloud practice in Microsoft Azure.
Make sure you stay up-to-date on all things Microsoft Azure: subscribe to our newsletter to receive new and timely content from the Nerdio Academy!
Get the latest insider updates from Nerdio