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.

RD Connection Broker HA and the RDP properties on the client.

In some earlier posts I discussed the new High Availability (HA) feature of the RD Connection Broker (RDCB) in Windows Server 2012 (formally known as Windows Server 8).

1. RDS in WIN8 Feature highlight no. 1 Better High Availability of the RD Connection Broker
2. How to configure High Availability for RD Connection Broker on Windows 8
3. RD Connection Broker HA – SQL Permissions

In the blog post regarding the configuration of HA (no. 2 in de above list) I ended the blog with the comment that we would now be able to connect to the environment by using MSTSC and entering the DNS farm name as the destination host to connect to. Having read that you’re probably wondering how this works. Because we’re launching an RDP connection using MSTSC with the destination set to the DNS farm name that points to the brokers. Would that not result in launching an RDP session to the RDCB server and not to the RDSH server(s) behind it? Yes it would!

If, after completing the step in blog post no. 2, I would launch MSTSC and enter the DNS farm name as the destination host (as shown below):

That would result in the error below. Why? Because we’re actually launching an RDP session to one of the RDCB servers, and of course that’s denied for our end user.

What we need to do is configure some properties in an .RDP file so that it has knowledge of the fact that we’re trying to connect through a HA Connection Broker.

These are the properties that need to be added:

full address:s:FARM.LAB.LOCAL
workspace id:s:FARM.LAB.LOCAL
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Wortell_sLab_Ses
alternate full address:s:FARM.LAB.LOCAL

If we try that as our end user, the connection bar would still show the RDCB DNS farm name, but we’re now logged in on the RDSH server.

This also get’s automatically configured for your RemoteApps. RemoteApps integrated on the client are stored inside RDP files in the following location:

C:\Users\<username>\AppData\Roaming\Microsoft\Workspaces\<Workspace-ID>\Resource

Editing such a .RDP file in notepad would (amongst some other properties that I left out here) results in:

full address:s:FARM.LAB.LOCAL
alternate shell:s:||calc
remoteapplicationprogram:s:||calc
gatewayhostname:s:rdgw.lab.local
remoteapplicationname:s:Calculator
remoteapplicationcmdline:s:
workspace id:s:FARM.LAB.LOCAL
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Wortell_sLab_Ses
alternate full address:s:FARM.LAB.LOCAL

RD WebAccess also automatically points to the RD Connection Broker farm

So that’s how to configure your .RDP files if you want to connect through a HA RD Connection Broker!

Good luck testing this. If you have any questions, let me know!

Windows Server 8 Settings Spreadsheet

The Group Policy Team created a new Blog Post today about the availability Windows Server 8 GPO settings spreadsheet! The sheet contains settings for Windows Server “8” Beta, Windows 8 Consumer Preview and all earlier versions of Windows.

“…The latest Group Policy settings reference spreadsheet that covers the available administrative template settings and security settings for Windows Server “8” Beta, Windows 8 Consumer Preview and all earlier versions of Windows is now available in the download center here:

http://download.microsoft.com/download/8/F/B/8FBD2E85-8852-45EC-8465-92756EBD9365/WindowsServer8BetaandWindows8ConsumerPreviewGroupPolicySettings.xlsx

To see the description of what is contained in this latest version before downloading, go here:http://www.microsoft.com/download/en/details.aspx?id=25250…”

Source: http://blogs.technet.com/b/grouppolicy/archive/2012/04/16/windows-server-8-settings-spreadsheet.aspx

RD Connection Broker HA – SQL Permissions

I've received some questions via e-mail on one of my previous posts on how set up High Availability on the Connection Broker in Windows Server 8 (Beta)

http://microsoftplatform.blogspot.com/2012/04/how-to-configure-high-availability-for.html

The questions were related to preparing the correct (SQL) permissions to be able to enable High Availability using the Server Manager wizard. In this blog post I’ll dive a little deeper in the SQL permissions part. But before we get started, since we’re dealing with beta product and since there is no official Microsoft documentation on this exact configuration yet, this blog post contains my personal thoughts on what I think the configuration should be.

The prerequisite that refers to the SQL permissions is explained by the setup as: “A Microsoft SQL Server with write permissions granted to all RD Connection Broker servers that will be part of the deployment.” But what exactly does that mean?

When you would not prepare any SQL permissions except opening port 1433 for your RD Connection Broker, you will receive the following error in the wizard:

“The database specified in the database connection string is not available from the RD Connection Broker server <servername>…”



Assuming that, 1. you did install the SQL Native Client on the RD Connection Broker and 2. traffic on port 1433 to the SQL Server is possible, you will see a log entry generated on the SQL Server that looks something like this:



The wizard to configure HA is trying to connect to the SQL Server using the computer account of broker.

So, basically what we need to do is create a group in Active Directory, and place all RD Connection Broker computer objects in there.



Then we add this group as a SQL Login in SQL Server manager.



If we then try the wizard again, it will try start to configure HA. However, without any further preparations, the following error will be raised



The wizard is unable to create a database.Why? Because we didn’t assign the AD group any roles or permissions. We open up SQL Server manager again, open the group and specify the role dbcreator.



When try the wizard again, it will succeed.



The database is created and exists in the folder we specified.



Note that when we add a second (or any new) RD Connection Broker to the HA setup, that new server also needs permissions to the database. If those permissions are not in place you will receive the following error in the wizard:



And the SQL Server log will raise the following events:



We open up SQL Server Manager again, open up the properties of the group we created select server mappings, select our database and we (although datareader and datawriter will probably also be enough) give our group owner permissions on our database.



This will allow us to successfully add new RD Connection Brokers to out HA environment, as long as they are a member of the created group.

Bottom-line:

• create a new AD group that contains your RDCB servers participating in the HA
  
• Give that group dbcreator permissions to be able to create the database during the wizard
  
• Give that group owner permissions (or at least dbwriter and dbreader) on the newly create database to ensure all RDCB servers are able to contact the database.

A final FYI to be aware of, if you created a database before starting the RDCB HA wizard the wizard will delete this database and create a new one during the setup.

RD Gateway in Windows Server 8 supports UDP

Remote Desktop Services in Windows Server 8 (Beta) supports the UDP protocol. The UDP transport protocol provides a better experience for users that connect to a RDS session on a server running Windows Server 8. TCP as well as UDP protocols can now be used for the RDP session.

The Remote Desktop Gateway (RD Gateway) in Windows Server 8 extends this UDP functionality by supporting it in the gateway. If the client or endpoint does not support UDP, RD Gateway will automaticially switch back and thus the selection process of the best possible transport protocol is completely transparent to the end-user as long as the it has been enabled in the RD Gateway and the client and RDP endpoint support a UDP connection. The client has to be equipped with Remote Desktop Client 8 to support UDP.

To configure the RD Gateway to use UDP when possible, open the RD Gateway manager and then select the "Transport Settings" tab. Here you have the option to enable UDP support. Of course, the UDP settings can also be configured using GPO's. E.g. there is a setting "Turn off UDP On Client" to configure it on the the client and setting "Connections - Turn Off UDP On Server" to force it to turn of on the RDSH server.

Expired passwords in RD WebAccess on Windows Server 8 revisited.

In one of my previous blog posts (http://microsoftplatform.blogspot.com/2012/03/rds-in-win8-feature-highlight-no_12.html )I showed that Windows Server 8 (Beta) now also has a functionality to have a user reset his password using RD WebAccess.

In that blog post, I wrote that I was wondering whether the final release of Windows Server 8 would contain a link to that password reset page on the logon page itself to guide the user to the password reset page. I’ve done some editing, and it seems that it’s extremely easy to add this functionality yourself. This the line of text I added containing a link:

However, the real intention of this new password reset functionality seems to be the ability to have a user change his expired password. See the screenshot below. Notice that a notification text is added saying that the password has expired with a link to the password reset page! Great feature!

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!