Performance testing RDS (Session-Based Desktop deployment) on Azure

If you’ve read my previous blog post you’ll know that Session-Based Desktop Deployment is now supported on Azure and can be licensed using SPLA. Details: Running VDI Session-Based Desktops on Azure now supported for SPLA

Now that this architecture is supported I thought it would be a good time to share some performance tests on Windows Azure I did earlier, to get an idea on how many concurrent sessions Azure is able to host on a single Remote Desktop Session Host (RDSH) server.

For this performance test I used the following Windows Azure VM’s (all Windows Server 2012).

A VDI Session-Based Scenario-Based Deployment has been enrolled, and the servers are running the roles as shown below. Although technically for this test, a role-based deployment of just the RD Session Host role would have been enough because the other RDS roles are not touched within this particular load test.

To perform the load testing and benchmarking I used Login VSI. Login VSI is an industry standard benchmarking tool for measuring the performance and scalability of Virtual Desktop Infrastructures. These tests were performed before the release of 4.0 For more info also see: http://www.loginvsi.com.

Login VSI is capable of generating different types of workloads and calculates what they call a VSIMax, which is basically the maximum capacity of the RD Session Host server expressed in the amount of sessions.

The following table shows the specifications of the different Windows Azure virtual machine sizes I used for the purpose of this test.

Azure VM Size	CPU	Memory
Extra Large	8 cores	14 Gb
A7	8 cores	56 Gb

I left out the VM’s with less available resources because I figured these two VM types would be most interesting since they can probably host the most number of sessions.

The following table shows the different VSI workloads (in number of sessions launched and type of workload) as well as the different Windows Azure virtual machine sizes I used for the purpose of this test. For more information on the workload types visit http://www.loginvsi.com./documentation/v3/performing-tests/workloads.

Number	Azure VM	Workload	# Sessions launched
1	Extra Large	Medium	30
2	Extra Large	Medium	40
3	Extra Large	Light	45
4	Extra Large	Light	50
5	A7	Medium	40
6	A7	Light	55

In all tests, user profiles have been pre-created for the test users and prior to each new test a reboot of the RD Session Host server has been performed to ensure everything is cleaned up properly. Also, all tests were performed several times to ensure more accuracy. Microsoft Performance monitor was also running during the tests to capture the performance counters on the RD Session Host server as shown below.

Performance counter	color
Processor - % Processor time _total	Green
Memory – Available Mbytes	Blue
Terminal Services – Active Sessions	Red
Logical Disk – Disk Reads / Sec	Purple
Logical Disk – Disk Writes / Sec	Yellow

Test number 1

Azure VM	Workload	# Sessions launched
Extra Large	Medium	30

In this scenario the VSIMax is not reached.

Test number 2

Azure VM	Workload	# Sessions launched
Extra Large	Medium	40

The Extra Large Azure VM reaches its VSIMax limit at 36 concurrent sessions.

Test number 3

Azure VM	Workload	# Sessions launched
Extra Large	Light	45

In this scenario the VSIMax is not reached.

Test number 4

Azure VM	Workload	# Sessions launched
Extra Large	Light	50

The Extra Large Azure VM reaches its VSIMax limit at 46 concurrent sessions.

Test number 5

Azure VM	Workload	# Sessions launched
A7	Medium	40

The A7 Azure VM reaches its VSIMax limit at 36 concurrent sessions.

Test number 6

Azure VM	Workload	# Sessions launched
A7	Light	55

The A7 Azure VM reaches its VSIMax limit at 49 concurrent sessions.

Summary

As a summary, here are the results of the highest VSIMax value I got calculated per Azure VM type.

Azure VM	Workload	VSIMax
Extra Large	Light	46
Extra Large	Medium	36
A7	Light	49
A7	Medium	36

So according to the test results, these are the VSI workloads a RD Session Host (running Server 2012) is able to handle on Windows Azure. Note that these results are of course based on a Full Desktop being published. Publishing just Remote Apps obviously consume fewer resources. Also, in these tests I’ve used Office 2013 and, as you might have heard, Office 2013 causes additional resources to be used compared to previous versions of office. And I’ve used a plain Windows Server 2012 image for the RD Session Host role without any optimizations. Also note that the number of concurrent sessions (VSIMax) is a simulation, the actual performance will always vary depending on your specific applications and users. But since LoginVSi is an industry standard these workloads can be compared to other environments.

It’s interesting to see that when workloads run towards the VSIMax, available CPU is the biggest part of the bottleneck. Because CPU is the biggest part of the bottleneck, the difference in VSIMax on an Extra Large VM and A7 Azure VM (both 8 Cores) are practically the same. Since Light workloads consume less CPU and there is a difference in available memory between the Extra Large Azure and A7 Azure VM, there is a (little) difference in the VSIMax there. Therefore, environments with Light workloads could take advantage of the biggest Azure VM, the A7.

For more information on pricing and detailed specifications on Azure VM’s see:
http://www.windowsazure.com/en-us/pricing/details/virtual-machines/

New Remote Desktop App for Windows 8.1 in the Microsoft Store!

For Windows 8.1, which is currently available in preview, a new Remote Desktop App is available in the App Store. The version has some significant improvements compared to the one available for Windows 8 and Windows Server 2012.

When we use the Remote Desktop App to signup a connection to a workplace to retrieve published Remote Apps and Desktops we did not have the ability to remove this sign up or manually update the sign up to retrieve the most up to date Remote Apps and Desktops assigned to our account. In order to do this you had to switch back to the Classic Control panel and perform those actions in the RADC Control Panel applet (Remote App & Desktop Connections). This functionality has been added to the Remote Desktop App available in the Windows Store for Windows 8.1 !

After doing a sign up we can swipe from the right and select “Manage RemoteApp and Desktops”. This option was previously called “Access RenoteApp and Desktops”.

Windows 8.1	Windows 8

When we choose this option we get an overview of all the Work Resources we have performed a signup for. The name Work Resources is the default name of a RDS deployment in 2012, which can be changed

When we click the a Work Resources item we’re presented with the screen below. This contains an overview of the details of the connection with the Connection URL and the amount of Remote Apps and Desktops.

Here we can easily hit “Update” to retrieve the latest set of Remote Apps and Desktops assigned to us. And we have the ability to remove this sign up by choosing “Remove”.

The functionality itself is not new of course as it has always been available in the classic RADC, however it’s good to see that this functionality is now also available in Desktop Desktop App!

Second improvement is accessing the on screen keyboard and touch pointer from within a Full Desktop Session using the Connect option inside the Remote Desktop App.

When we’re running the Full Desktop Session we can now easily swipe from the bottom and instantly select the on screen keyboard as well toggle the touch pointer on and off.

Memory leak occurs in the Dwm.exe process on a Remote Desktop computer that is running Windows 8 or Windows Server 2012

A new KB article (2852483) was released yesterday regarding a memory leak running RDS on Windows Server 2012 (or Windows 8).

“…Consider the following scenario:

• You use Remote Desktop Connection to connect to a remote computer that is running Windows 8 or Windows Server 2012.
• You disconnect from the Remote Desktop session.
• You reconnect to the Remote Desktop session, and you specify a different display resolution for the session. For example, you change the display setting in Remote Desktop Connection before you reconnect to the session, or you reconnect to the session from another computer that has a different screen size.

In this scenario, a memory leak occurs in the Desktop Windows Manager (Dwm.exe) process on the remote computer.
Then, assume that you disconnect from the Remote Desktop session and then reconnect to the session many times, and you specify a new display resolution for the session every time. In this scenario, the remote computer may freeze, crash, or experience a decrease in performance…”

“…To resolve this issue, install update rollup 2855336 on the remote computer. For more information about how to obtain this update rollup package, click the following article number to view the article in the Microsoft Knowledge Base: 2855336…”

Source: http://support.microsoft.com/kb/2852483/en-us?sd=rss&spid=16526

Running VDI Session-Based Desktops on Azure now supported for SPLA

If you have been following my blog you might have read this blog post I wrote back in September 2012 about a test drive I performed running a VDI Session-Based Desktop deployment on Windows Azure. Read it here: Running a Windows Server 2012 Remote Desktop Services environment on Azure.

Back then running Remote Desktop Services roles on Windows Azure was not officially supported (yet). Microsoft has recently changed their support statement on this, and therefore running a Session-Based Desktop Deployment on Windows Azure is now officially supported by Microsoft but can however only be licensed using SPLA. The PUR of July 2013 has been updated with the following statement;

Remote Desktop Services. Remote Desktop Services (RDS) Subscriber Access Licenses (SALs) purchased through the Microsoft Service Provider Licensing Agreement (SPLA) may be used to deliver graphical user interface functionality on Windows Azure virtual machines. RDS Client Access Licenses (CALs) purchased through other Volume Licensing programs including the Enterprise Agreement may not be used with Windows Azure virtual machines. Virtual Desktop Infrastructure functionality may not be used on Windows Azure virtual machines.

Link to the PUR:  http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentTypeId=1

KB: Adding Remote Desktop Services role may fail when Firewall Service is stopped in Windows Server 2012 (2802436)

KB article (2802436) related to installing RDS on Windows Server 2012 where the Firewall service is not running.

“…On a computer that is running Windows Server 2012, when you try to install the Remote Desktop Services Role, using the "Add Roles and Features" Wizard, the installation may fail. Additionally, during the installation process you may receive one of the following error messages:

Unable to open remote connections on the RD Connection Broker server
The post installation configuration did not complete.

Note: After a reboot the RDS Server may work. If it does not, the following powershell commands will complete the failed action:
    $tss = Get-WmiObject -namespace root\cimv2\terminalservices -class Win32_TerminalServiceSetting
    $tss.SetAllowTSConnections(1,0)

During the post installation configuration, the wizard attempts to enable necessary firewall exceptions for the RDS Role. When the firewall service is stopped, this operation fails and is reported with the above error

It is not recommended to run without a Firewall. If you have certain requirements to do so, enable the Firewall Service at least during installation of this Role…”

Source: http://support.microsoft.com/kb/2802436/en-us?sd=rss&spid=16526

Closer look at Remote App and Full Desktop experience improvements in Windows Server 2012 R2 and Windows 8.1

At Tech Ed 2013 US, Microsoft releases more info on the improvements on Remote Apps and Full Desktops in Windows Server 2012 R2. I highlighted the improvements in my What's New in Windows Server 2012 R2 Virtual Desktop Infrastructure and Remote Desktop Services (more details!) blog post. Now that the R2 release is officially in preview, let’s take a closer look at the improvements in experience compared to Windows Server 2012.

As a background, Remote Apps are published application on a RD Session Host (or VM) and interact seamlessly with the local desktop. With the upcoming R2 release Microsoft improved the way Remote Apps behave (from a client’s perspective) in order to create an experience that’s now even closer to locally installed applications than before.

One of the improvements is related to Remote App window’s. In order to be able to show those differences, I configured my lab with a RD Session Host running 2012 and a RD Session Host running 2012 R2 in separate Session Collections, as part of the  same deployment. In both Session Collection I published the same Remote App, WordPad. That results in the following Web Access view.

When we open both Remote Apps two separate sessions are logged on, one for each Session Collection, and we’re presented with two Remote Apps.

Better experience dragging, minimizing and maximizing a Remote App

We notice the first improvement immediately when moving the Remote Apps on our Desktop. When we drag the Remote App running on Windows Server 2012, we’ll notice a thick black border and while dragging we the window the actual window is not shown, only a border representing the window we’re dragging.

Doing the same action on Windows Server 2012 R2 results in a much better experience (although this is complicated to capture in a screens shot). Dragging a Remote App running on R2 is much much closer to the experience of dragging a local application. Black borders don’t occur, and while dragging the contents of the application are also shown.

Live taskbar preview of a Remote App

Another improvement becomes visible when hovering over task bar. With Server 2012 R2 we’re able to show a live preview of the Remote App, were server 2012 only shows a icon. The screenshot below shows this difference.

Automatically adapting to rotation

The experience for Remote Apps on Tablets and hybrids has also been improved. If we run a Remote App on a Windows 8 tablet and hybrid and rotate the tablet from landscape to portrait that would result in a disconnect and reconnect of the Remote App.

The Remote App running in landscape on a Windows 8 tablet

When turning the tablet to portrait, the Remote App disconnects and reconnect. And although the reconnect is automatic, it’s annoying, especially when running multiple Remote Apps.

The Remote App running in landscape on a Windows 8.1 tablet

When turning the tablet to portrait, the Remote App instantly rotates and no disconnect and reconnect exists.

This improvement makes the Remote App experience on tablets and hybrids much better.The improvement relies on the Remote Desktop Client (RDC) version 8.1 and thus at this point requires Windows 8.1 or Windows Server 2012 R2 (as the client). Although we can expect a RDC 8.1 update to be released for Windows 8. This means that this improvement is also in place when connecting to a Windows Server 2012 using a RDC 8.1

Automatically adapting to screen resolution change

For Full Desktops, a improvement has been made related to automatically adapting to the local screen resolution. With Windows Server 2012 and RDP 8.0, if you had a full desktop session running in full screen mode, and you would change the local screen resolution, and then come back to the RDS session and maximize that, it would still maximize to the previous resolution. With RDP 8.1, the screen resolution of the remote session automatically adapts to the resolution of the local session. In this example I opened 2 full desktop sessions, 1 session to a RD Session Host server running Server 2012 and 1 to a RD Session Host server running 2012 R2, both part of the same deployment (two separate Session Collections). II then minimized both sessions and changed the local screen resolution to be smaller. Upon maximizing both Full Desktop sessions again this is what Windows Server 2012 looks like (scroll bars all over the place)

This is what Windows Server 2012 R2 looks like. It automatically adapted to the local resolution!

Note that to use this new feature both the Remote Desktop Client (RDC) version 8.1 is also needed.

This concludes this blog post on Remote App and Full Desktop experience improvements in Windows Server 2012 R2 and Windows 8.1. The improvements introduced result in a Remote App experience that is much closer to the experience of running local applications. I’m looking forward to the General Availability of R2 and 8.1 !

Detailed walkthrough on Remote Control (Shadowing), reintroduced in Windows Server 2012 R2

As you probably know the ability to Remote Control a user in RDS (shadowing) was removed from Windows Server 2012. I briefly talked about that in a Customer Review I wrote for blogs.msdn.com. In the R2 upgrade of Windows Server 2012, Remote Control has been reintroduced! I briefly discussed this in the blog post What's New in Windows Server 2012 R2 Virtual Desktop Infrastructure and Remote Desktop Services (more details!)

Now that the preview bits for Windows Server 2012 R2 have been released during Tech Ed Europe in Madrid, I’m able to show Remote Control (shadowing) in Windows Server 2012 R2 in greater detail.

With Windows Server 2012, there are 2 options to perform the Remote Control of a user session. Using the Server Manager GUI or using a the Command Line.

Remote Control using Server Manager GUI

Open the Server Manager Console and select Remote Desktop Services. You now have two options to find the user you want to Remote Control. Click on “Collections” and the look at the Connections section. This view contains all active or idle sessions within every Session Collection as part of the deployment.

Or, if you know the Session Collection under which the user is active, in stead of clicking on “Collections”, click on the collection in question and then look at the Connections section.

To Remote Control a user, right click the user and choose Shadow

You will then be prompted asking if you would like to view or control the session and if the users needs to be prompted, which can also be enforced using GPO.

The user in question will receive an authorization request as shown below.

While waiting for the users response the administrator is represented with the dialog below.

If the user clicks No or does not respond within 30 seconds the administrator that launched the Remote Control will be presented with a “The operator or administrator has refused the request”.

The 30 seconds is also configurable suing the GPO:

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections\Set Rules for Remote Control of Remote Desktop user Session

If he chooses to accept, the Remote Control will start and the administrator will be presented with the remotely controlled session easily recognizable by looking at the name of the window as shown below.

Remote Control using the Command line

The second method to Remote Control is by using the command line. In order to be able to perform the command line Shadow the client machine must be running at least Remote Desktop Client 8.1 (which at this point is only available for Windows 8.1 (preview) or Windows Server 2012 R2 (preview), but will be become available for Windows 8 and Windows Server 2012 in the future.

The reason for this requirement is that the shadowing option has become part of the mstsc.exe executable itself.

To be more precise, the shadowing is now a command line parameter of mstsc.exe which can be confirmed by running mstsc.exe /help, which will result in the screenshot below.

The syntax to shadow a session is as follows:

mstsc /v:<ServerName> /shadow:<SessionID>

We obviously first need to find out the ID of the session we want to Remote Control. The Session ID can be found by running the PowerShell command “”Get-RDUserSession” (make sure you first import the module RemoteDesktop) and is retrieved in the UnifiedSessionId column.

And while inside the PowerShell console it’s probably most convenient to do the mstsc command from within there is as well.

The authorization process is the same compared to launching the Shadow option from the GUI, however, by default the command line will start the Remote Control in “View” mode. If you want to be able to interact with the session the parameter /control also needs to be specified. If you want to bypass the authorization prompt, use the /noConsentPrompt option.

In the introduction I also mentioned that shadowing has not only been reintroduced in R2 but also improved. We’re now also able to Shadow a Remote App, which was previously not supported. And also it now supported to shadow a client session running multiple monitors.

Shadowing a Remote App

As an example we launch Paint as a Remote App

If you perform a Remote Control on this user Session (and after running through the same authorization process) you are represented with the screen below. Because the user we’re shadowing does not have a desktop we see a black screen presenting the users desktop.

As you might know, if a user runs more than 1 Remote Apps, additionally launched Remote Apps all run in the same user session (and thus same Session ID). Therefor, if a user would run multiple Remote Apps, they will all be visible for the administrator who is shadowing, as shown below.

Do note that if the end user minimizes the Remote App, it will become invisible for the administrator doing to Remote Control. So if all Remote Apps are minimized the administrator will end of with a black screen.

Also, note that since the black screen represents the user local desktop, I the administrator chose the Control option and would move to the lower left part of the black screen that triggers the local start menu. In the screenshot below the administrator moved the cursor to the area marked by the red square on the left. That causes the File Explorer on the local user’s client (on the right) to show a preview pane.

The administrator obviously cannot interact with the local desktop by performing left or right clicks, but the experience above is something to be aware of.

The black screen does not occur when shadowing a full desktop that the end user minimizes. The admin will still be able to interact with a minimized full desktop session.

Permissions

In order to be able to perform Shadowing you need permissions. If no permissions are in place it will result in the error below.

Being local administrator on the destination server obviously works. However, to allow non-administrators permissions to shadow you can use the following command which is also applicable for Windows Server 2008 R2 (Credits for this command go to fellow RDS MVP TP who posted this on TechNet Forum.

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName="RDP-Tcp") CALL AddAccount "domain\group",2

Than concludes this blog post on the reintroduction or Remote Control (shadowing) in Windows Server 2012 R2.

Happy shadowing !!