Taking a look at the new HTML5 connector in Dell/Wyse vWorkspace 8.5

Dell/Wyse has released the latest version of their vWorkspace product this week, which is version 8.5! I have been upgrading a first environment this week, which went smooth.

For an overview of all that’s new in 8.5, see: http://documents.software.dell.com/vWorkspace/8.5/Whats%20New/

In this blog post I’ll focus on a specific new feature, the HTML5 connector. The HTML5 connector allows users to connect to applications or desktops without having to install a vWorkspace connector. HTML5 can be enabled or disabled for Windows, Mac, iOS, Android, Linux and Chrome OS.

Obviously the experience of running a RemoteApp or Desktop on a (installed) connectors or RDP client is much better than HTML5. In most use cases HTML5 will therefor not be the primary way of connecting. However, it does allows users to connect to applications or desktops without having to install a connector or client. Which makes a great way of providing a secondary or backup way of connecting in situations were users are not allowed to install or configure a client locally or just want to check a document real quick on a device they’ve never used before and don’t want to download, install and configure a connector or client first. Or, in case of using one of the few devices for which a vWorkspace connector is not available (like e.g. Windows RT).

HTML5 can be enabled an configured within the vWorkspace management console on a per client type level.

After doing so, you log on to vWorkspace Web Access (which is also improved to support scales to the size and orientation of the endpoint device).

You select a Remote App

And after logon we are now running multiple RemoteApps inside our browser, bases on HTML5, without installing any client.

Do note that in most scenario’s you will see NLA enabled in an environment. By default however, NLA is disabled for the vWorkspace HTML5 connector. To enable HTML5, edit the following file C:\inetpub\wwwroot\web\Freezer\Web.Config

And set EnableNLA to the value true.

Azure RemoteApp (ARA) now supporting Office 365 ProPlus!

The Microsoft RDV Team released a new bog post about support for Office 365 in Azure RemoteApp (ARA). This means that you can now publish Office 365 ProPlus applications as a RemoteApp to your end-users!

As a results, you can now choose from three different Microsoft Images to create Azure RemoteApp cloud collections which are available out of the box in Azure!

Below is a description of the images currently available today!

Windows Server 2012 R2 (a.k.a. "the vanilla image")

• This image is based on Microsoft Windows Server 2012 R2 Datacenter operating system and has the following roles and features installed to meet the requirements of Azure RemoteApp template images:
  • .NET Framework 4.5, 3.5.1, 3.5
  • Desktop Experience
  • Ink and Handwriting Services
  • Media Foundation
  • Remote Desktop Session Host
  • Windows PowerShell 4.0
  • Windows PowerShell ISE
  • WoW64 Support
• This image also has the following applications installed:
  • Adobe Flash Player
  • Microsoft Silverlight
  • Microsoft System Center 2012 Endpoint Protection
  • Microsoft Windows Media Player

Microsoft Office 365 ProPlus (Office 365 Enterprise E3 or E4 subscription required)

• Office 365 is the most requested application and therefore we have provided you with a pre-created "custom" image for you to work with.
• This image is an extension of the vanilla image and has the following components of Microsoft Office 365 ProPlus installed in addition to the components described in the Windows Server 2012 R2 image:
  • Access
  • Excel
  • Lync
  • OneNote
  • OneDrive for Business
  • Outlook
  • PowerPoint
  • Project
  • Visio
  • Word
  • Microsoft Office Proofing Tools
• Full functionality of Office 365 ProPlus apps is available only for users who have Office 365 Enterprise E3 or E4 subscriptions. Please contact your Microsoft account representative for more details on Office licensing.

Microsoft Office 2013 ProPlus (trial only)

• During the preview, we thought that it would be good idea to provide a pre-created "custom" image for you to test the service with.
• This image is an extension of the vanilla image and has the following components of Microsoft Office 2013 ProPlus installed in addition to the components described in the Windows Server 2012 R2 image:
  • Access
  • Excel
  • Lync
  • OneNote
  • OneDrive for Business
  • Outlook
  • PowerPoint
  • Project
  • Visio
  • Word
  • Microsoft Office Proofing Tools
• Our legal team wanted us to emphasize: This image does not include Microsoft Office license and hence cannot be used for production. Office 2013 ProPlus is for preview only and if you want to use Office apps in Azure RemoteApp for production, please use Office 365 ProPlus image. For more details on Office licensing, please contact your Microsoft account representative.

Source and more info: http://blogs.msdn.com/b/rds/archive/2014/12/02/azure-remoteapp-now-supporting-office-365-proplus.aspx

KB: RemoteApp program pop-up window is hidden in Windows

Microsoft released a new Kb article today (2964832) in regards to incorrect opening of Remote Apps on clients running Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, or Windows Server 2008 R2.

“…Assume that you publish some RemoteApp programs on a remote desktop server. When you open a RemoteApp program from a client computer, the pop-up window of the RemoteApp program opens on top of other program windows, and then the window is hidden immediately behind the other windows…”

“…To resolve this issue, install the hotfix that is described in this article…”

Source & download: http://support.microsoft.com/kb/2964832

KB: Error when you try to change the properties of a published RemoteApp in Windows Server 2012

A new KB article (2862077) was released yesterday in regards to changing the properties of a Remote app inside the RDMS if this Remote App is installed on a non-system drive of the RD Session Host.

“…Consider the following scenario:

• You deploy Remote Desktop Service on a Windows Server 2012-based computer.
• A Remote Desktop Connection Broker is installed in the environment. The computer is joined in a session-based collection.
• You install an application on a non-system drive of the computer.
• You publish this application as a RemoteApp.
• You try to use Remote Desktop Management Server (RDMS) UI to change and save the properties of the RemoteApp.

In this scenario, the operation fails, and you receive the following message:

Cannot bind argument to parameter 'VirtualPath' because it is an empty string

This issue occurs because the script that RDMS UI calls receives an empty parameter unexpectedly…”

“…To work around this issue, use the Set-RDRemoteApp cmdlet to change the properties of the RemoteApp…”

Source & download: http://support.microsoft.com/kb/2862077/en-us?sd=rss

What's New in Windows Server 2012 R2 Virtual Desktop Infrastructure and Remote Desktop Services (more details!)

Yesterday, Adam Carter (Technical Product Manager) did a session on What's New in Windows Server 2012 Virtual Desktop Infrastructure and Remote Desktop Services on Tech Ed 2013 North America and announced the some of the new features in R2 in more detail! So I’m now able to talk some more on those details. Here is a wrap up of some of the announcements on R2!

Let’s start with the big feedback item Microsoft got after the release of Windows Server 2012 and that is bring shadowing (Remote Control) back! Back in September 2012 I wrote a review on RDS in Windows Server 2012 for blogs.msdn.com called Managing RDS/VDI with Windows Server 2012 where I mentioned that I was very surprised and not too happy about the fact that Shadowing was a deprecated feature. And I was not the only one. I’ve seen many questions on TechNet Forum, replies to blog posts and many e-mail’s from people asking where shadowing was moved to. It is a widely used feature and it’s good that Microsoft listened to the feedback and reintroduced (and even improved!) shadowing in Windows Server 2012 R2.

A session can be shadowed using the Server Manager GUI

And you’ll be asked to view or interact with the session.

The user will be prompted to accept (if configured that way)

And also, it’s now fully supported to Shadow RemoteApps!! Which was previously not supported.

On the left you see a Remote App ran by the user, on the right you see the Remote Control Interface as seen by the admin.

Actually Shadowing / Remote Control  is now build into mstsc.exe so you don’t need the GUI to start the shadowing, for example using the command mstsc /v:<servername> /shadow 6 /control

Dynamically add / Remove monitors
Upon changing resolution or adding monitors you used to have to disconnect and reconnect to use the new resolution, that’s now dynamically. No more logoff, logon! This also works for tablet or surfaces when you rotate the device the session will pick up on that.

Improved RemoteApp behavior.
There have been many improvements in the way RemoteApp behave. Before when dragging a Window of a Remote App you just get the the windows outline

And, when you look at the taskbar preview you just see a genuine Excel Icon.

With Windows Server 2012 R2, when you drag a RemoteApp, it’s not just the border and a full preview of the application is available!

Quick Reconnect
The Remote App and Desktop Connections (RADC) can be used to sign up for corporate applications and desktops and publish them in the users local start screen or start menu. Part of this feature was the ability to disconnect all Remote Apps and later reconnect them. It used to take a long time to perform the full reconnect, they improved the time it takes the reconnection process to finish in R2 and it now does so under 5 seconds! Also, network loss detection has been improved to allow for a more intuitive reconnect phase.

Codec improvements
The continuing improvements in the codecs that are being used, less bandwidth, better performance.

There are some other new features not shown / announced yet, so I’m not allowed to show you that, but stay tuned to find out soon!

Source: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WCA-B350#fbid=YavD-8dO8_f

KB2798286: RemoteApp disconnects from a client running Windows 7 or Windows Server 2008 R2

A new KB article (KB2798286) was released today related to Remote Apps being disconnected with a protocol error when the Remote App supports Remote Applications Integrated Locally (RAIL). It seems like a similar update as KB2696020 http://support.microsoft.com/kb/2696020/en-us?sd=rss&spid=14134. Only this time the fix is also applicable for Windows 7.

“…Consider the following scenario:

• You install the Remote Desktop Session Host role service on a computer that is running Windows Server 2008 R2.
• You publish a RemoteApp application that supports the Remote Applications Integrated Locally (RAIL) feature on the computer.
• You use the Remote Desktop Web Access (RD Web Access) service on a client computer that is running Windows 7 or Windows Server 2008 R2 to access the RemoteApp application.
• You open the RemoteApp application and perform several operations.

In this scenario, the Remote Desktop session disconnects. Additionally, you receive an error message that resembles the following:

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

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

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

Setting the default RemoteApp connection URL on your clients using GPO

Before Windows Server 8 beta (soon to be Windows Server 2012) there was an option in the control panel of the user called Remote App and Desktop Connections. Using this Control Panel option the user was able to set the URL needed to build the connection to the RD WebAccess to be able to have the RemoteApps available. Remember that in this Feature highlight blog post I wrote that Window Server 8 beta added a new option so that users would also be able to enter their corporate e-mail address in stead of the connection URL, which is of course much more user friendly.

Windows Server 8 Beta also comes with a new GPO setting to set the default connection URL so that the user would not have to configure anything at all!

The setting is inside a new container called “RemoteApp and Desktop Connections”

And is called “Specify default connection URL”

If you enable this setting you are able to set the default connection URL. The details of the setting are shown below.

Setting: Specify default connection URL
Supported on: At least Windows 8 Consumer Preview
Comment: This policy setting specifies the default connection URL for RemoteApp and Desktop Connections. The default connection URL is a specific connection that can only be configured by using Group Policy. In addition to the capabilities that are common to all connections, the default connection URL allows document file types to be associated with RemoteApp programs.

The default connection URL must be configured in the form of http://contoso.com/rdweb/Feed/webfeed.aspx.

If you enable this policy setting, the specified URL is configured as the default connection URL for the user and replaces any existing connection URL. The user cannot change the default connection URL. The user's default logon credentials are used when setting up the default connection URL.

If you disable or do not configure this policy setting, the user has no default connection URL.

Note: RemoteApp programs that are installed through RemoteApp and Desktop Connections from an untrusted server can compromise the security of a user's account.

RemoteApp improvements in Windows Server 8

There have been numerous improvements regarding the way end-users experience RemoteApps in Windows Server 8. In this blog post, I’ll discuss some of the improvements that might at first seem very small but will definitely help end users to adopt Remote Apps even more.

With Windows 7, new features were introduced, such as grouping of applications, pinning, tabbed windows, overlay icons etc. However, RemoteApps didn’t allow full compatibility with these newly introduced features. Windows Server 8 (Beta) crosses the bridge and has the capability to allow compatibility with these features!

Users can now also pin RemoteApp applications to the client taskbar just like they were locally installed applications.

Users can now easily spot the difference between RemoteApps and workspaces by a unique icon. This identifier is in the form of an icon overlay in the form of the Remote Desktop logo.

Users can now see a change in the status of an application as icon overlays is now also supported for Remote Apps.

And users can now also see the difference between multiple instances of an application by being able to see tabs in the RemoteApp preview.

It's good to see that these features made it to the Windows Server 8 (Beta) release, it definitely makes Remote Apps more user-friendly!

"Input Capture Window" shows on local desktop when you start Windows Remote Assistance as a RemoteApp

A new ("FAST PUBLISH") KB article was released by Microsoft today regarding running Windows Remote Assistance (msra.exe) as a RemoteApp hosted on a Windows Server 2008 R2. The article states that using applications like Windows Remote Assistance as RemoteApp is not a supported scenario in Windows Server 2008 R2.

Article ID: 2674002 - Last Review: February 15, 2012 - Revision: 1.0
"Input Capture Window" shows on local desktop when you start Windows Remote Assistance as a RemoteApp

"...When you start Windows Remote Assistance (msra.exe) as a RemoteApp hosted on a Windows Server 2008 R2, you may see an extra window showing up on the Taskbar with the title "Input Capture Window" on your workstation. Also the desktop is not redrawn correctly.

Using applications like Windows Remote Assistance as RemoteApp is not a supported scenario in Windows Server 2008 R2..."
Source: http://support.microsoft.com/kb/2674002/en-us?sd=rss&spid=14134

Some windows of a Remote Desktop Services (Terminal Services) RemoteApp application might not be displayed correctly in Windows Server 2008 R2

A new KB article was released yesterday regarding issues some Windows of RemoteApp Applications. This issue occurs because the remote desktop connection does not display the window correctly if The window ownership hierarchy is more than two levels deep or if the windows are remoted in reverse order.

Article ID: 2614136 - Last Review: December 14, 2011 - Revision: 1.0

Some windows of a Remote Desktop Services (Terminal Services) RemoteApp application might not be displayed correctly in Windows 7 or in Windows Server 2008 R2

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

Consider the following scenario:

• You install the Remote Desktop Services role on a computer that is running Windows Server 2008 R2.
• You configure a Remote Desktop Services RemoteApp application on the computer. This RemoteApp application supports the Remote Applications Integrated Locally (RAIL) feature.
• You connect to the RemoteApp application from a client computer that is running Windows 7 or Windows Server 2008 R2.

In this scenario, some windows of the RemoteApp application are not displayed correctly. You find large blank or dirty areas at the expected locations of the pop-up windows. The frequency of this behavior varies.

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

Remote Desktop Web Access in Windows Server 8

In an earlier blog post I showed and discussed the Scenario Based Deployment of Remote Desktop Services. (see here: Scenario Based Deployment). Remote Desktop WebAccess (RDWA) is part of this deployment. In this blog post I will discuss the changes to this role a bit further and show you what RDWA looks like in Windows Server 8 (at least inside the developers preview).

When you install the Remote Desktop WebAccess (RD WebAccess) role, either via de Scenario Based Deployment or manually using the Server Manager, the RD WebAccess page becomes available under https://hostname/rdweb (no difference there, compared to Windows Server 2008 (R2). When we browse this URL, the login screen actually looks pretty much the same.



We can see that the RD WebAccess page in the Developers Preview still needs some work done, as it still states “Windows Server 2008 R2” in the lower-left corner. :-)

When we logon, we are presented with the screen below. Again, not very different compared to Windows Server 2008 R2. A difference that we do see however is “Current folder: /” Is that what we think (and hope) it is? It seems that in upcoming releases, we will actually be able to put RD WebAccess RemoteApps Programs inside (sub)folders! That’s great! I have seen lots of requests and questions on about this on TechNet forum!



When we look at the source of default.aspx quickly, it seems my thoughts a confirmed! We already see declarations of strings containing errors and messages of a folder hierarchy structure.

const string L_BadFolderErrorTitle_Text = "Folder does not exist. Redirecting...";
const string L_BadFolderErrorBody_Text = "You have attempted to load a folder that does not exist. In a moment, you will be redirected to the top-level folder.";

Also, note that we’re missing a tab here called “Configuration”. Am I perhaps not logged on as an Administrator? Yes, I am. So why is it not showing? It simply isn’t there yet. When we look at the content of the folder that RD WebAccess uses (that is still C:\Windows\Web\RDWeb\Pages) we see the following content:



Which is different compared to Windows Server 2008 R2 as we can see below.



We’re missing config.aspx. This configuration is moves to the Server Manager. I'll talk about that more in an upcoming blog post!

There is another new file in the en-US folder called RDWAstrings.xml. When we open this up we’re presented with, as the name suggests, strings that we can modify. A snippet of the code is shown below.

<string id="ControlUpgradeVistaBody_2">.<br/><br/></string>
<string id="SearchingForApps">Searching for available RemoteApp programs... </string>
<string id="CurrentFolder">Current folder: </string>
<string id="ParentFolder">Up</string>

So yes, we can already change the name of the root-folder using the CurrentFolder string :-)



In my next blog post I will discuss the new functionality that has moved from the "Configuration" tab in the RD WebAccess page to the Server Manager. Stay tuned!

Configuring a RemoteApp on Windows 7

As you might know, RemoteApp programs can be configured on Windows Server 2008 (R2). When end-users access these RemoteApp programs they, from the end-users perspective, appear to be running locally.

Configuring these RemoteApp programs on a Windows 7 machine is less frequently seen. It can be done relativly simple however. Benny Trisch explains the procedure is one of his blogposts here:

http://blog.drtritsch.com/?p=176

Credits to Dr. Trisch for the simple guide!

The first step is to activate RemoteApp on Windows 7 by setting the Registry key HKLM \SOFTWARE \Microsoft \Windows NT \CurrentVersion \Terminal Server \TSAppAllowList: fDisabledAllowList to the value 1.

The next step is to create a key for each RemoteApp program: HKLM \SOFTWARE \Microsoft \Windows NT \CurrentVersion \Terminal Server \TSAppAllowList \Applications \<Appname>. Add a string named “Name” and the value “Appname”. Add a string named “Path” and the value “C:\Windows\System32\Appname.exe”.

The last step is to create an RDP file on the client side. The RDP file must include the following entries:

• full address:s:<VM-Adresse>
• disableremoteappcapscheck:i:1
• alternate shell:s:rdpinit.exe
• shell working directory:s:
• remoteapplicationprogram:s:||<Appname>
• gatewayhostname:s:
• remoteapplicationname:s:Appname.exe
• remoteapplicationcmdline:s:

Two new hotfixes regarding RDS 2008 (R2) KB2522762 and KB2538047

Microsoft has released two new hotfixes yesterday and today regarding Remote Desktop Services in Win Server 2008 R2. Details see below.

Article ID: 2522762 - Last Review: June 16, 2011 - Revision: 1.0
RemoteApp application does not work correctly from RD Web Access in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2522762/en-us?sd=rss&spid=14134

Article ID: 2538047 - Last Review: June 15, 2011 - Revision: 1.0
Audio capture redirection feature does not work after a second remote desktop connection is created in Windows Server 2008 R2
http://support.microsoft.com/kb/2538047/en-us?sd=rss&spid=14134

RD WebAccess and the "unknown publisher story"

Anyone who had worked with RD WebAccess will have seen the following error one time or another:

The question: can we configure RD WebAccess to sign the .RDP that is used so that this warning does not pop-up on our end-users computers?

The answer: The answer is, as with all IT-questions, it depends!

And here’s why: There are two ways to have users access your RD Session Host farm from RD WebAccess. The first one is by making use of RemoteApp. RemoteApp is the technique on the RD Session Host that is used to deliver seamless applications to your end-users that “blend in” with the users locally installed applications. You can use RD WebAccess to publish these RemoteApps via a webpage. In the example below I have published Calculator and WordPad to be available via RD Web Access.

 In the RemoteApp configuration on the RD Session Host we can actually configure the SSL certificate that is used to sign the “.rdp file” that is used to run the RemoteApp.

 That’s great! Now we have a publisher available and a user can check that he trusts the publisher. (Or we can use a GPO that automatically trusts all RDP connections that were signed using a specific SSL certificate, by making use of the hash of the SSL certificate).

 Now comes the catch, the second method is making use of the option Remote Desktop tab in RD Web Access. This way you can publish a full desktop instead of a RemoteApp.

Can we sign the .RDP that is used for this connection as well to get rid of the publisher warning?
No, we can’t.

The reason for this is that is that there’s a difference in how the .RDP file is built when using Remote App RD Web Access and when using Remote Desktop via RD Web Access.

When you connect to a RemoteApp, a .RDP file is created on the RD Session Host based on the settings that we configured in the Remote App Manager. Remember that we specified a SSL certificate there. So the .RDP file will be signed here before its being channeled to the client from where it is executed.

When you connect to a Remote Desktop, the .RDP file is actually created on the client itself based on parameters that it gets from the RD Web Access (which reside in the web.config and aspx pages) plus the settings that might have been done in the Remote Desktop page by the user. The client does not sign the .RDP file, and thus, you still get the warning about the unknown publisher!