Exploring the Azure RemoteApp User Experience

The Microsoft RDS team released a new blog post on the User Experience of Azure RemoteApp. In several recorded demo’s they show the Local-like Productivity, Multi-platform support and performance!

 

Source & more info: http://blogs.msdn.com/b/rds/archive/2015/02/02/exploring-the-azure-remoteapp-user-experience.aspx?wa=wsignin1.0

KB: Window is blank when you run a RemoteApp program that is located on a Windows 8 or Windows Server 2012-based server

Microsoft released a new KB (2982431) yesterday in regards to possible issues with Remote Apps that run child windows that call the RedrawWindow function. In those cases the child window could become blank. Microsoft has provided a hotfix for Windows Server 2012 and Windows 8.

More info & download: http://support.microsoft.com/kb/2982431/en-us?sd=rss&spid=16526

Microsoft Azure RemoteApp: feature set

The table below shows the feature set of Microsoft Azure RemoteApp as presented in the Tech Ed NA 2014 session “Azure RemoteApp Deep Dive”.

Source:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/PCIT-B342#fbid=

Microsoft Azure RemoteApp preview announced!

Today, Microsoft Azure RemoteApp was announced in the Keynote at Tech Ed NA 2014 in Houston! It is now available as preview in Microsoft Azure, and of course I have already signed up for it!

Microsoft Azure RemoteApp is based on Remote Desktop Session Host (RDSH) running Windows Server 2012 R2 and (for now) allows you to publish and run the full Office 2013 suite based on Remote Apps running seamlessly on your Windows, Mac OS X, iOS, or Android end point devices! Future plans are to support a Bing Your Own Application scenario where you can “upload” your application to Azure and make them available as Remote Apps. It’s a subscription based model, currently free in preview. The price per user per month has not been announced yet.

I have been able to run some really quick tests, after your request to use the preview has been completed, a RDSH server incl. a complete Office Suite (incl. Visio & Project) are ready!

To allow an end-user to work with the Remote Apps a separate client needs to be installed. After that the end-user is presented with his set of Azure Remote Apps

You can expect more technical details on this feature once I’ve done some test-driving!

“…Azure RemoteApp helps employees stay productive anywhere, and on a variety of devices - Windows, Mac OS X, iOS, or Android. Your company’s applications run on Windows Server in the Azure cloud, where they’re easier to scale and update. Users can access their applications remotely from their Internet-connected laptop, tablet, or phone. While appearing to run on the users' local device, the applications are centralized on Azure’s protected, reliable platform.

Azure RemoteApp combines Windows application experiences with the powerful capabilities of Remote Desktop Services on Microsoft Azure – the cloud for modern business…”

More info:

https://www.remoteapp.windowsazure.com/
http://azure.microsoft.com/en-us/services/RemoteApp/

KB: Shortcut menu items flicker as you move the mouse pointer over them in a RemoteApp in Windows 8 or Windows Server 2012

A new KB article (2925336) was released by Microsoft in regards to an issue with shortcut menu’s inside a Remote App published on Windows Server 2012 or Windows 8.

”…On a computer that's running Windows 8 or Windows Server 2012, you publish a RemoteApp application. However, when you use the RemoteApp application, you discover that shortcut menu items flicker as you move the mouse pointer over them…”

Source & download: http://support.microsoft.com/kb/2925336/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 !

RDS Enhancements - Enhanced VDI in Windows Server 2012 R2

Windows Server 2012 R2 has just been announced at Tech Ed NA 2013! With Windows Server 2012 R2 new features and improvements around RDS are also announced to further enhance VDI !

I’m not allowed to show detailed information yet, but here is a quick wrap up based on what’s just been posted on blogs.microsoft.com

“'…RDS Enhancements - Enhanced VDI in Server 2012 R2 which delivers improvements in Management, Value, and User Experience. Session Shadowing allows Admins to view and remotely control active user sessions in an RDSH server. Disk dedupe and storage tiering allow for lower cost storage options. User experience for RemoteApps, network connectivity and multiple display support has been improved. Administrators can now easily support users with session desktops to provide helpdesk style support. Administrators now have even more flexible storage options to support a VDI environment without expensive SAN investments. End users will find RemoteApp behavior is more like local apps, and the experience in low-bandwidth is better, with faster reconnects and improved compression, and support for multiple monitors…”

Source: http://blogs.windows.com/windows/b/springboard/archive/2013/06/03/what-s-new-for-the-enterprise-in-windows-8-1.aspx

Expect more detailed information on these features soon on this blog including screenshots!

Windows Server 2012 RemoteApp and Desktop Connections: Default Connections and File Type Associations

A new blog post by Travis Howe, a developer on the Remote Desktop Virtualization team on default connections and file type associations in Remote Desktop Services on Windows Server 2012.

A summary:

“…Default connections

When we added the RemoteApp and Desktop Connections feature in Windows Server 2008 R2 and Windows 7, many administrators wanted to be able to push connections to their users by using Group Policy. To help enable this, we supported a “silent install” API that allowed a user to be signed up for a connection without any prompts. Administrators had to push something like this script on Script Center to their users by using Group Policy.

In Windows Server 2012 and Windows 8, we improved this scenario. We have added a new Group Policy container under “Remote Desktop Services” called “RemoteApp and Desktop Connections,” and within that container have defined a new policy setting called “Specify default connection URL.” Enabling this policy setting causes users to be subscribed to RemoteApp and Desktop Connection at the specified URL. RemoteApp and Desktop Connections that have been installed by using this policy setting have a special name: default connections…”

“…File type associations support: what does it mean?

So what do I mean when I say that default connections are able to install file type associations? When an administrator is publishing RemoteApp programs, they can also choose to publish file types that should be associated with that program. Then, when the RemoteApp program is installed as part of a default connection, we associate the RemoteApp program with those file types on the client machine.

The next time the user tries to open a file of that type, the standard Windows 8 file type association behavior will be used to determine which of the registered programs should be used to open the file. Often, the user will be given a choice. For example, if Microsoft Paint has been published as a RemoteApp program with the .bmp file type association, the user is presented with the following options…”

For the complete blog post and source:

http://blogs.msdn.com/b/rds/archive/2013/05/21/windows-server-2012-remoteapp-and-desktop-connections-default-connections-and-file-type-associations.aspx

Adding custom RDP properties in Windows Server 2012 RDS/VDI environments

If you’re familiar with Remote Desktop Services in Windows Server 2008(R2) you’re probably familiar with the Remote App manager. This MMC snap-in was available on servers running the RD Session Host role and could be used to publish Remote Apps. As you might know by now, with Windows Server 2012 many of the MMC snap-ins have been deprecated and configuration of those features is now performed centrally using the Remote Desktop Management Service (RDMS) as part of the new Server Manager console. For more details on that also see RDMS on Windows Server 2012: The Where, the Why and the How..

Part of this Remote App manager in Windows Server 2008 R2 was the ability to set Deployment Settings, for example the Custom RDP Settings. Custom RDP settings can be used to further customize the users session, for example by settings specific redirection options or enabling Smart Sizing.

With Windows Server 2008(R2) setting these Custom RDP settings could be modified by using the GUI.

With Windows Server 2012 there is no option to set this in the RDMS Server Manager GUI. In order to add custom RDP properties we need to use the RemoteDesktop PowerShell module

The command to do this is Set-RDSessionCollectionConfiguration

For example, if we want to remove the connectionbar we could run the following command:

Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection "displayconnectionbar:i:0"

These settings are are stored in the registry of the RD Connection Broker(s) that are part of the Session Collections deployment.

Do note that if we wanted to add an additional custom RDP property we would have to specify all the custom RDP properties in one command. For example if we would add an additional custom RDP property to map the local C: drive and run

Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection "drivestoredirect:s:C:"

That would overwrite the previously added custom RDP property.

We obviously have to add all the custom RDP properties at once. To make this work we need to add a linefeed character (which is: `n) between the options otherwise it won’t be applied properly. The command would look like this:

Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection "drivestoredirect:s:C: `n displayconnectionbar:i:0"

This will result in a published desktop with the following properties

As you might know the RD Connection Broker settings (as well as other RDMS settings) are stored in a database. Without running in RD Connection Broker High Availability (HA) mode, this is a SQL Express database running on the RD Connection Broker itself, and when running in HA mode, the database is moved to a central SQL Server instance.

Since the SQL database is the central place to store configuration we would expect the Custom RDP property to also be stored in this database. I’ve done some searching inside the RDMS database, and it appears that the Custom RDP property that we set using PowerShell is not stored there. Inside the table called PoolProperty, there is a CustomRDPSettings but that only contains the setting that is there by default, not our added properties.

There also is a value called CustomRdpSettings inside the table RdpFileInfo, but that table does not seem to hold any records at all.

So as it now seems the properties are only stored inside the registry of the RD Connection Broker.

Now consider the following scenario; we define the Custom RDP properties as shown above and after that add an additional RD Connection Broker. Would our added properties make it to the additional RD Connection Brokers registry?
I have tried this in my lab and it seems that this settings does not make it to the newly added RD Connection Broker!

First RD Connection Broker server	Added RD Connection Broker server

The solution here is to run the PowerShell command again so that the configuration on the 2 RD Connection Broker is in sync again.

This raises another question, what if we would add a additional Custom RDP Property in a environment that is already in HA mode, but with 1 of the RD Connection Broker servers not being available? We can simulate this by disconnecting the network adapter of the 2nd RD Connection Broker and then try to run the PowerShell command again.

The command now raises an error “Unable to set Custom RDP Properties for collection Quick Session Collection because one or more RD Connection broker servers are unreachable or misconfigured”. Which is good! Because this way the RD Connection Broker configuration stays consistent.

Other properties configured in the RDMS GUI can be configured while a RD Connection broker in your HA farm is offline. For example we would be able to publish a Remote App. When the 2nd RD Connection Broker comes online again it’s triggered to sync the configuration, which can also be forced by restarting the “Remote Desktop management” service. The fact that you cannot change the Custom RDP Properties with a RD Connection Broker being offline seems to proof that this setting is not stored in the RDMS database but only in the registry.

Distribution of Remote Apps and desktops in Windows Server 2012

My new article “Distribution of Remote Apps and desktops in Windows Server 2012” just got published on VirtualizationAdmin.com

 “…With the Release To Manufacturing (RTM) version of Windows Server 2012 being available (September 4th) many people have been test-driving Windows Server 2012, or will do so in the near future. Windows Server 2012 has been improved in many different areas, Remote Desktop Services being one of them. In this article, we’ll take a look at a common action while using Remote Desktop Services in Windows Server 2012, which is the distribution of Remote Apps and Desktops. In this article, we’ll discuss what has changed, what the consequences of those changes are compared to Windows Server 2008 R2, what’s possible with Windows Server 2012, and what’s not…”

View the complete article:
http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/distribution-of-remote-apps-and-desktops-in-windows-server-2012.html

Remote Desktop Web Access single sign-on now easier to enable in Windows Server 2012

The Microsoft RDS team posts a new blog that explain the way to setup Single Sign On (SSO) with Windows Server 2012. The setup has been made a lot easier compared to what you had to configure with Windows Server 2008 R2.

“…Hi, I’m Sergey, one of the developers on the team that produces Remote Desktop Services. In Windows Server 2008 R2, we introduced Web Single Sign-On (web SSO), which reduced the number of times a user was asked for credentials when accessing RemoteApp programs published through Remote Desktop Web Access (RD Web Access). Enabling this was complex and difficult for users. In this post, I'll explain how easy it is to set this up in Windows Server 2012. It basically works "out of the box…”

Source:http://blogs.msdn.com/b/rds/archive/2012/06/25/remote-desktop-web-access-single-sign-on-now-easier-to-enable-in-windows-server-2012.aspx

The Remote Desktop Web Access website does not show any published RemoteApp programs

Revision 2.0 of KB 2705427 was just released. I don’t recall ever seeing the 1.0 version of this KB, but it’s an interesting one.

Article ID: 2705427 - Last Review: June 13, 2012 - Revision: 2.0
The Remote Desktop Web Access website does not show any published RemoteApp programs if a RemoteApp source is offline in Windows Server 2008 R2.

“…Consider the following scenario:

• You configure a Remote Desktop Web Access (RD Web Access) server on a computer that is running Windows Server 2008 R2.
• You install the Remote Desktop Session Host role service on some servers that are running Windows Server 2008 R2, and then you publish some RemoteApp applications on these servers.
• You configure these Remote Desktop Session Host servers as the RemoteApp source of the RD Web Access server.
• You shut down one of the Remote Desktop Session Host servers.

In this scenario, you notice that the list of the RemoteApp applications in the RD Web Access website is returned as blank.

This issue occurs because of a design flaw in the RD Web component. The RD Web component stops enumerating applications as soon as the component encounters a session host that is unavailable…”

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

New Article: Remote Apps and the Metro RDP client

My new article titled “Remote Apps and the Metro RDP client" on virtualizationadmin.com just got published. The article is about the integration of RemoteApps running on Windows Server 2012 (8 Beta) launched from a Windows 8 client.

“…Introduction

Remote applications that run seamlessly on a client desktop have been around for some time now. With Windows Server 8 Beta, Microsoft has put in a good effort to make the RemoteApps on the Windows 8 desktop interact and integrate better than before. In this article, we will look at the integration of RemoteApps running on Windows Server 8 Beta launched from a Windows 8 client...”

Read the complete article here:
http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/remote-apps-and-the-metro-rdp-client.html

RemoteApp session is disconnected when the RDP encryption level is set to Low and RDP compression is disabled in Windows Server 2008 R2

Today a new KB article and hotfix have been released for RDS on Windows Server 2008 R2. In a specific scenario a RemoteApp session could disconnected and additionally, the following error message is raised: "Because of a protocol error this session will be disconnected. Please try connecting to the remote computer again"

Article ID: 2699817 - Last Review: May 9, 2012 - Revision: 1.0
RemoteApp session is disconnected when the RDP encryption level is set to Low and RDP compression is disabled in Windows Server 2008 R2

"...Consider the following scenario:

• You install the Remote Desktop Session Host role service on a computer that is running Windows Server 2008 R2.
• You configure the Remote Desktop Protocol (RDP) encryption level to Low, and then you disable RDP compression.
• You publish a RemoteApp program on the computer.
• You connect to the RemoteApp program from a client computer.

In this scenario, the RemoteApp session is disconnected intermittently. Additionally, you receive the following error message:

Because of a protocol error this session will be disconnected. Please try connecting to the remote computer again.

 

This issue occurs because an incomplete window instruction is sent to the client computer..."

 

Source and download: http://support.microsoft.com/kb/2699817/en-us?sd=rss&spid=14134

New update to the RDS wiki: The Case of the Invisible RemoteApps

Amongst some others, I've have been working on some of the articles in the New RDS Wiki on TechNet. Recently a new article came out by Pankaj Pande related on (non)visibility of RemoteApp programs in RD WebAccess.

"...In our previous blog entry on Remote Desktop Services resources for IT Pros, we mentioned that we'd added a new wiki for Remote Desktop Services in WS08 R2.This wiki has been growing quickly, thanks to the efforts of some of our community. Most recently, we've released a new article on the TechNet Wiki entitled The case of invisible RemoteApp programs (a.k.a. No RemoteApp programs listed on RD Web Access site). This article discusses one of the error messages that you may get while trying to add one or more RemoteApp sources by using the Configuration tab on the RD Web Access page. It includes an analysis and troubleshooting tips using RD Web Access Tracing. The article also covers the permissions related to WMI and DCOM that you can check when you get these error messages. If you have your own tips, we encourage you to add them to our wiki and link them to the appropriate landing page..."source:
http://blogs.msdn.com/b/rds/archive/2011/12/07/new-update-to-the-rds-wiki-the-case-of-the-invisible-remoteapps.aspx

The taskbar may not show the application name correctly when using a Terminal Server RemoteApp

A new KB article was released by Microsoft yesterday related to the display of an incorrect name in the taskbar when using a Remote App. The workaround that Microsoft offers however seems a bit disappointing :-). But I’m sure they’ll fix this issue in a upcoming hotfix.

Article ID: 2642873 - Last Review: November 17, 2011 - Revision: 1.0

The taskbar may not show the application name correctly when using a Terminal Server RemoteApp

source: http://support.microsoft.com/kb/2642873/en-us?sd=rss&spid=14134

Take RDS management to a higher level with Windows Server 8

In a previous blog post, I discussed the Scenario Based Deployment of RDS in Windows Server 8, and more recently, discussed the new features of RD WebAccess in Windows Server 8. In this blog post, we’ll take a deeper look into what the new Server Manager has to offer when it comes to managing RDS Roles in Windows Server 8. I must say, I was quite surprised, in a positive way!

Let’s walk through the scenario. In a previous blog post I showed the steps to perform a Scenario Based Deployment of RDS using the standard scenario and spreading the different RDS roles over separate servers. This time we’ll do it differently and choose the Quick Scenario which deploys the RDS Roles (RDSH, RDWA and RDCB) on a single machine in order to create a RDS environment very quickly that you could i.e. use as a demo environment.

We start by launching the Add Roles and features wizard and choose Next.

We then select the Scenario Based Installation and choose next. 

As mentioned earlier we’ll go for the Quick Deployment in order to create a single server that contains all the roles that the RDS scenario is able to deploy. 

In this case, we want to publish applications and desktops on a RDS server, so we choose session virtualization deployment.

The next step is to select the server on which we want to deploy the roles. We’re reminded that the deployment will restart the server if necessary. Just a quick note: what I didn’t show you is that I pre-installed the RDSH role on this machine (using the Add Roles wizard) as this is a requirement for this type of Scenario Based Deployment where you run the wizard on the machine itself.

The deployment was successful! If you read my earlier blog post on Scenario Based Deployment, you’ll see a difference here. In that previous deployment, I got an error at the end of the wizard saying configuration failed: SetAllowTSConnections failed. I had configured a GPO that sets the SetAllowTSConnections to allow. In that post I assumed that the GPO caused the error at the end of this wizard and apparently, I was right. As a pre-installation action I removed the GPO setting, and set the SetAllowTSConnections back to default, and now no errors occur at the end of the installation.

Now let’s go back to the new server manager, we’ll notice some great new options and management features there! We now have a graphical overview of the RDS environment showing us that we have a RDWA, RDCB and RDSH role.

We can even add or remove roles from within this interface! I.e. adding a new RDSH server is done my right-clicking on the RD Session Host icon and choosing Add RDSH server.

We can also add the role RD Gateway which is not part of the Scenario Based Deployment itself.

When we drill down one-step, notice that we now have something new there that is called Collections, and underneath the first collection called QuickSessionCollection which the Scenario Based Deployment wizard created for us. (click the image to expand)

  

When we look into that QuickSessionCollection we see; the properties of the RDSH servers (groups, resources), the RemoteApp Programs, the host servers and the active connections on this SessionCollection. Normally you’d had to gather this information in different places, it’s now nicely gathered and consolidated in the Server Manager, which is a big improvement!

From this console we can i.e. choose Edit Properties.

This brings us to the properties page of the collection where we can set security groups, timeout settings, redirection settings etc. Before, you would edit or view these properties on the RDP-tcp properties screen.

We can also manage our Remote Apps from this console! As you can see, I added two RemoteApps (calculator and wordpad).

When we choose the properties of a RemoteApp, we can edit the settings that we previously had to do in the RemoteApp Manager. Again, all from within the Server Manager!

Notice that we can now enter a folder name! If you read my previous blog post you’ll remember that inside the new Remote App .aspx files I noticed that there was new code regarding to folder management of your Remote Apps. I promised to further take a look at that later, so here it is! We enter the folder name “Accessories” here, refresh the RD WebAccess page, and Voila!

This is definitely a big improvement of RD WebAccess. I’ve seen people asking for this feature in TechNet Forums and blog posts quite a lot.

Conclusion so far:Microsoft has done great work with the new Server Manager. It definitely makes managing your RDS environment a whole lot better. I really like the fact the all RDS roles, settings and even Remote Apps can now be managed through a consolidated interface in the Server Manager.

I will drill down in the Server Manager some more and start using it some more by adding additional RDSH servers and more RemoteApps to get a good feeling on how it will perform and what working with the new Server Manager will be like. But so far, it looks very promising!