Run your Remote Desktop Server Connection Broker database in Azure SQL (Win Server 2016 TP5)

Windows Server 2016 Technical Preview 5 is out! For Remote Desktop Services, this brings a great new feature to the table! Remote Desktop Services in TP5 allows you to store the RD Connection Broker database in Azure SQL! This is a very interesting scenarios for RDS on Azure IaaS but can also be used for an on premises or hosted scenario.

How to configure this? The process of setting up RDS Deployment (Quick or Standard) via Server Manager or PowerShell in Technical Preview 5 is similar to setting this in up Windows Server 2012(R2).

Now we need to setup an Azure Database. Select New from the Azure Portal and choose SQL Database.

In the New Server window provide a server name, logon and location.

Next, provide a database name, subscription and new (or existing resource group) and select a blank database. For testing purposes in my lab I selected the Basic tier but in future production environments the Tier should be chosen based on the performance needed.

That is basically it! The database will now be created in Azure.

Once it’s finished, the screen below is what you will end up with. Click “Show database connection strings” and copy the ODBC connection string and save it, you’ll need this later on.

From the RDMS console in Server Manager you can select the option “Configure High Availability”, still similar to Windows Server 2012 R2. In this case however, you will be presented with the option to choose a Dedicated database server or a Shared database server. For Azure Databases the option obviously is Shared database server. Note for this to work, similar to HA in Windows Server 2012 R2, you still need the SQL Server Native client to be installed on all RD Connection Broker servers.

Provide the DNS name for the RD Connection Broker, similar to setting up High Availability in Windows Server 2012. Copy the ODBC connection string you saved earlier and enter the password in the string, this is the password you provided while setting up the Azure database.

Double check the information and click next.

The Windows Internal Database is now migrated to the Azure Database

The Server Manager console now reflect the changes and shows “High Availability Mode”.

Obviously other factors now also come into play like performance, what Azure SQL Tier do I need, what connectivity is required etc. These require more in depth testing, and we still have time since this is only Technical preview, but for now it’s a great new feature that adds more options and flexible deployment scenarios of RDS on Azure IaaS or on premises!

Remote Desktop Preview App now supports Azure RemoteApp! (Insiders ring)

The latest update to the Azure RemoteApp Preview App (version 856) in the Microsoft App Store (currently only in the insiders rings) now contains support for Azure RemoteApp! This means you can now start using this client to launch applications hosted in Azure RemoteApp.

What is the experience like?
First download and install the latest Remote Desktop Preview App from the Appstore (note that you currently have to be in the insiders rings to see the update, other rings will follow soon)
https://www.microsoft.com/en-us/store/apps/microsoft-remote-desktop-preview/9nblggh30h88

After launching the App we now have a new option called “Azure RemoteApp, Sign in to a source feed to get apps”.

Simply enter the account you want to use that is assigned to an Azure RemoteApp collection and click Sign In.


The App will start to retrieve the applications that are assigned, which in my case took a few seconds.


And here are the applications that are assigned to my user.


By single clicking, a user session is logged on and the application is launched. Similar to the ClickOnce client, or any RemoteApp environment, the launch of 1st application takes a little longer because at this stage the session is being logged on. Any 2nd or 3rd application we launch leverages the same session and is faster in launch time.


Here I have several applications open. By clicking the three dots in the upper center of the App you can easily switch between active application i.e. if you have minimized an application and want to bring it back up.


Optionally, you can pin RemoteApps by right clicking the App and selecting “Pin To Start”


Currently there is no intuitive way to return to the main screen of the App to launch additional apps. To return to the main screen, first press the button with the 3 dots again, and then click the Back arrow button.


Also, once in the main screen, there currently is no easy way to switch back to an active session, the only method is to launch an additional app from the same source. Ideally you would like to switch concurrent active session easily especially in scenarios where users have multiple feeds from different sources or are in the middle of a migration path from on premises RemoteApp to Azure RemoteApp. Microsoft has confirmed that functionality to provide easy switching of active session is on the roadmap. As with any Azure service or App, it’s all about continuous development, so expect updates to this App regularly too.

Finally, the App collects recently launched RemoteApps and if you right click the tile in the Start Screen, you can quickly launch recently opened RemoteApp and Pin them from the Start Screen as well.

Estimating Azure RemoteApp network bandwidth usage

Microsoft updated some articles for guidance on estimating Azure RemoteApp network bandwidth usage.

”…Azure RemoteApp uses the Remote Desktop Protocol (RDP) to communicate between applications running in the Azure cloud and your users. This article provides some basic guidelines you can use to estimate that network usage and potentially evaluate network bandwidth usage per Azure RemoteApp user.

Estimating bandwidth usage per user is very complex and requires running multiple applications simultaneously in multitasking scenarios where applications might impact each other's performance based on their demand for network bandwidth. Even the type of Remote Desktop client (such as Mac client versus HTML5 client) can lead to different bandwidth results. To help you work through these complications, we'll break the usage scenarios into several of the common categories to replicate real-world scenarios. (Where the real-world scenario is, of course, a mix of categories and differs by user.)

Before we go further - note that we assume RDP provides a good to excellent experience for most usage scenarios on networks with latency below 120 ms and bandwidth over 5 MBs - this is based on RDP's ability to dynamically adjust by using the available network bandwidth and the estimated application bandwidth needs. This article goes beyond those "most usage scenarios" to look at the edge, where scenarios begin to unwind and user experience begins to degrade.

Now check out the following articles for the details, including factors to consider, baseline recommendations, and what we did not include in our estimates…”

Source & more info:

Estimate Azure RemoteApp network bandwidth usage
How do network bandwidth and quality of experience work together?
Testing your network bandwidth usage with some common scenarios
Quick guidelines if you don't have the time or ability to test