Monday, October 25, 2010

Accessing Pooled and Personal VMs From RD Web Access Logs You On With Windows Credentials Instead Of Prompting

This is a specific circumstance, but I ran into it, so I bet more people have too.

If you:
Enable and apply the following GPO to your to your pooled or personal VMs:

Computer Configuration \ Policies \ Administrative Templates \ Security \ Credentials Delegation\ Allow Delegating Default Credentials (enable the setting and add this entry: TERMSRV/*.yourdomainname.suffix)


From Windows XP SP3 or Windows 7 clients, when you access RD Web Access, pick Private mode and then access a pooled or personal VM via their icon on the RemoteApps page, you are not prompted for credentials—the session automatically logs you in using the credentials with which you logged onto the client machine. If you pick public mode, then you will be prompted for credentials.

Its due to the GPO setting. Remove the GPO and you will be prompted for creds in either public or private mode.

Wednesday, October 6, 2010

RDP Settings for RDC 7

RDP Settings are stored in the RDP file used to launch the connection. When you launch, the settings are passed to the endpoint. The following table shows the RDP settings available in in RDC 7 to connect to Windows 7 and Windows Server 2008 R2 endpoints. 

Not all RDP settings will be specified in all RDP files.All RDP settings follow the this format: name of setting:datatype:value. 

The name of setting is in the Setting column; the datatype is either i (for integer) or s (for string).The value is the string or integer representing the desired behavior. Most RDP settings are integers; the ones that are strings are the ones that can’t have a default (e.g., the setting to define the command-line settings for an RDP file). 

If an RDP setting conflicts with a setting configured through Group Policy or RD Configuration, the settings in the RDP file settings always have lowest precedence.

Administrative session
Creates an administrative session. This is equivalent to starting the session with /admin.
Allow font smoothing
Enables font smoothing, which improves the appearance of TrueType fonts.
Alternate full address
Specifies an alternate name or IP address of the remote computer that you want to connect to by using Remote Desktop Connection (RDC). This setting will override the full address.
The DNS name of the farm or server (e.g., or the IPv4 or IPv6 address.
Alternate shell
Indicates the application to start for RemoteApp programs
Name of the application executable
Determines whether audio capture is enabled. Corresponds to the Remote audio area on the Local Resources tab under Options in RDC. Available settings are 1 (enable capture) and 0 (disable capture).
Determines how sounds on a remote computer are handled when you are connected to the remote computer by using Remote Desktop Connection (RDC).
Corresponds to the settings in the Remote audio area on the Local Resources tab under Options in RDC. There are three settings: 0 (play sounds on local computer), 1 (play sounds on remote computer) and 2 (do not play).
Determines the quality of the audio played in the remote session. Possible settings are 0 (adjust audio quality based on bandwidth), 1 (always use medium quality) and 2 (always use uncompressed quality). This setting only has any effect if audio redirection is enabled.
Authentication level
Determines what should happen when server authentication fails. Corresponds to the selection in the If server authentication fails drop-down list on the Advanced tab under Options in RDC. There are four valid options: 0 (Connect and don’t warn me), 1 (Do not connect), 2 (Warn me), and 3 (server authentication is not required).
Autoreconnection enabled
Determines whether the client computer will automatically try to reconnect to the remote computer if the connection drops; Corresponds to the Reconnect if the connection is dropped check box on the Experience tab under Options in RDC. There are 2 valid option: 0 (do not attempt reconnect) and 1 (attempt reconnect).
Autoreconnect max retries
Determines the maximum number of times the client computer will try to reconnect to the remote computer if the connection drops
Determines whether bitmaps are cached on the local computer. There are two valid options: 0 (do not cache) and 1 (cache).
Determines whether the connection should use bulk compression. There are two valid options: 0 (do not compress) and 1 (compress).
Determines the resolution height (in pixels) on the remote computer. Corresponds to the selection in the Display configuration slider on the Display tab under Options in RDC.
Determines the resolution height (in pixels) on the remote computer. Corresponds to the selection in the Display configuration slider on the Display tab under Options in RDC.
Specifies the devices to redirect to the remote session. Corresponds to the selections for Other supported Plug and Play (PnP) devices under More on the Local Resources tab under Options in RDC. There are four valid options:  nothing (which redirects nothing), *, which redirects all devices, Dynamic Devices, whch redirects all devices added during the session, and the HW ID of the device, which will redirect only that device.
Disable ctrl+alt+del
This may sound like a security setting, but it determines whether the CTRL+ALT+DELETE security attention sequence is required to enter credentials after you are connected to the remote computer. Valid options include 0 (it’s not required) and 1 (it is required).
Determines whether Easy Print is enabled when connecting to the remote computer. Valid options include 0 (enable Easy Print) and 1 (disable Easy Print).
Determines whether clipboard redirection is enabled when connecting to the remote computer. Valid options include 0 (enable clipboard) and 1 (disable clipboard).
Determines whether the connection bar appears when you are in full screen mode when you connect to a remote computer. Corresponds to the Display the connection bar when I use the full screen check box on the Display tab under Options in RDC. Valid options include 0 (do not display the bar) and 1 (display the bar).
Sspecifies the name of the domain for the user account that will be used to log on to the remote computer. This value and the username value appear in the RDC GUI on the General tab.
Determines whether RDC will use CredSSP for authentication if it’s available, Valid options include 0 (don’t use CredSSP, even if available) and 1 (use CredSSP if possible).
Full address
Specifies the name of the farm or server the RDP file points to. This value can be overridden by the value of alternate full address.
The DNS name of the farm or server (e.g., or the IPv4 or IPv6 address.
Specifies the credentials that should be used to validate the connection. Values may be 0 (ask for password, uses NTLM), 1 (use smart card), or 4 (allow user to choose).
Specifies the name of the RD Gateway.
DNS name of the RD Gateway
Determines the RD Gateway authentication method a user can use, whether the defaults are specified by the administrator (0) or user-specified (1).
Specifies if and how RD Gateway is used. Valid options include 0 (Do not use RD Gateway), 1 (Always use the RD Gateway, even for local connections), 2 (Use the RD Gateway if a direct connection cannot be made to the terminal server), 3 (Use the default RD Gateway settings), and 4 (Do not use RD Gateway). 0 and 4 have the same effect; the only difference is in the user interface (UI), wherein the option to bypass RD Gateway is selected or cleared.
Determines how Windows key combinations are applied when you are connected to a remote computer. Corresponds to the selection in the Keyboard drop-down list on the Local Resources tab under Options in RDC. Valid options include 0 (apply them to local computer), 1 (apply them to remote computer), and 2 (apply them to the remote computer only when the remote session is in full-screen mode).
Load balance info
Specifies the provider name, endpoint type, and an endpoint. This setting is how a RD Connection Broker knows which type of resource plugin (VM or session)  to activate.
Negotiate security layer
Determines whether the level of security is negotiated or not. If it is, then the connection begins with SSL; if I is, then the connection begins with an x.224 connection request. Valid options include 0 (use SSL) and 1 (negotiate).
Determines whether or not the connection bar should be pinned to the top of the remote session. Valid options include 0 (do not pin) and 1 (pin).
Prompt for credentials on client
Determines whether the connection will prompt for credentials when connecting to a server that does not support server authentication. Corresponds to the Always Ask for Credentials option in the RDP file. Valid options include 0 (do not prompt) and 1 (ask for credentials).
Enables Remote Clipboard, which is required for copying and pasting text between local and remote settings. Valid options include 0 (do not redirect) and 1 (redirect)
Redirect COM ports to the remote session. Valid options include 0 (do not redirect) and 1 (redirect)
Specifies whether drives are redirected.
Redirects printers to the remote session. determines whether printers configured on the client computer will be redirected and available in the remote session when you connect to a remote computer. Corresponds to the selection in the Printers check box on the Local Resources tab under Options in RDC. Valid options include 0 (do not redirect) and 1 (redirect)
Redirects Point of Sale Devices. Valid options include 0 (do nor redirect) and 1 (redirect).
Enables smart cards to use smart cards for single  sign-on. Valid options include 0 (do not redirect) and 1 (redirect).
Command-line parameters for a RemoteApp (e.g, opening a file when launching the RemoteApp).
No default; provide the parameters.
Specifies that the RDP file will display a RemoteApp.
Specifies the name of the TS RemoteApp as displayed in TS Web Access or at connection time. Use this if changing the name from the default.
New name of the RemoteApp program, if you’re changing it from the default.
Specifies the alias of the RemoteApp; don’t change it or you may prevent the RemoteApp from working with RD Web Access.
Screen mode ID
Determines whether the remote session window appears full screen when you connect to the remote computer.  Valid options include 1 (display in a window ) and 2 (display full screen).
Server port
Specifies the server port the
connection request will be sent to. Use this setting if you have changed the default port on the server.
Session bpp
Specifies the color depth to use (in bits). Valid options include15 (high color, 16 (high color) , 24 (true color) and 32 (highest quality).
Smart sizing
Determines whether the client computer should scale the content on the remote computer to fit the window size of the client computer. Valid options include 0 (don’t scale the client window) and 1 (scale the client window).
Span monitors
Enables monitor spanning. When using RDC 7, the Use multimon setting is recommended.
Specifies the name of the user account that will be used to log on to the remote computer.
This value appears in the User name box on the General tab under Options in RDC
Use multimon
Detetmines whether the session should use true multimon to connect to the endpoint. Valid options include 0 (do not use) and 1 (use)
Determines whether RDC will use RDP efficient multimedia streaming for video playback (in other words, send it to the client for rendering in Windows Media Player or render it on the server). Valid options include 0 (do not use) and 1 (use if available).
Defines the position of an RDP window on the client computer.
6 integers to define its x axis,y axis, front and back position (also known as its z order), and the window height and width.
Workspace id
Defines the RemoteApp and Desktop ID associated with the RDP file that contains this setting. Applies only when launched from RemoteApp and Desktop Connections.
RemoteApp and Desktop ID.

Thursday, September 30, 2010

How RD Web Access Public and Private Mode Affects Logging Onto Pooled And Personal VMs:

If I log onto a machine, but then log onto RD Web Access with different credentials, I get different behavior when access pooled or personal VMs when in public or private mode.

In RD WEB access, logged into from either  Windows 7 or Windows XP SP3:
  • If I choose "This is a private computer" then when I try to launch a Pooled or Personal VM, it uses the credentials I logged onto the MACHINE with, not the website. It does not give me an opportunity to change this.
  •  If I choose "This is a public computer" then when I try to launch a Pooled or Personal VM, it prompts me for credentials.  
Also, this is not the case if I use Win2k8R2 as a client. Win28kR2 prompts me for credentials no matter if I choose public or private mode when logging onto RD Web Access.

(RemoteApps in all of these cases are set to use WebSSO and so they use the credentials I logged onto the website with. This is expected behavior.)

Thursday, August 26, 2010

COPY TO Button Not Available in Windows Server 2008 R2

I had someone ask me today why the Copy To button no longer worked in Windows Server 2008 R2. He was trying to use it to make a customized mandatory profile for use with Remote Desktop Services, but the button was greyed out.

Just so happned I was reviewing Ch5 in our upcoming Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit. Chapter 5 is our profiles chapter so the timing was perfect to post this answer:

Short story is, Copy To on a user profile has never actually been supported. For many reasons. Because of this, In 2008 R2 Microsoft did away with the functionality.

Copying a user profile over another could lead to problems if the copied profile had been used at all, because the profile being copied would be “tattooed” with inappropriate settings and naming, such as the following:

• A list of that user’s frequently run programs.

• The user’s documents folders will be incorrectly called Administrator’s Documents.

• The user may have access to Administrative Tools (this is incorrect for regular users).

• Windows 7 libraries will be broken.

Now the only profile you can copy is the default profile, which is not tatooed.

If you must make a customized mandatory profile, then you have to overwrite the default profile with another profile by running sysprep with an answer file that tells it to overwrite the default profile with the profile of the user that is logged in that runs sysprep. This is described here:

Here are the steps:

1. Log on as an administrator and customize the profile as needed. This is the profile that will be copied over the default user profile.

2. Create an Unattend.xml file and add a line of code to it to tell it to copy the profile of the user logged on over the default profile when the system reboots. The line you add is

The unattend file should look like this for 64 bit:

3. Save this Unattend.xml file to : C:/Windows/System32/Sysprep.

4. Once you have the Unattend.xml file in place, open a command prompt and type the following command:

sysprep.exe /oobe /reboot /generalize /unattend:unattend.xml

This will copy the user profile over the default user profile, with which you can then use the Copy To button.

But be warned, sysprepping a production machine will do things like:

• The sysprep command resets the computer SID as well as eliminating system-specific data like the computer name and the domain affiliation.

• It can also remove unique hardware drivers and can reset the Windows activation key.

If you are using VMs, then one workaround is to take a snapshot of the VM before sysprepping. After you are done running sysprep, rebooting, and copying the default profile to another location, apply the snapshot and the VM will be rolled back to its prior state.

People are circumventing this and posting their workarounds, such as using windows enabler to turn on the Copy To button and doing things the old way, but again this is unsupported.

You can also stand up a 2008 VM and then get a profile using the win2k8 server. Again, not supported.

Really the best way to do this is to NOT customize the mandatory profile but use the default profile as it is, and layer in your changes via GPO and GPP and scripting. That way you never have to deal with a customized mandatory profile.

More reading for you:

Sunday, August 22, 2010

An authentication error has occurred. The specified target is unknown or unreachable. NLA Error, XP SP3

This is really annoying and it took me a little while to find the fix, so I am blogging about this in hopes that others waste less time!

I have a 2008 R2 RD Session Host server farm. IT is set to accept only connections from NLA clients.
Connecting from any Win7 machine works great.

Then I tried to connect via a client running XP SP3, running RDC 6.1 (supports NLA) with CredSSP enabled.

I got the following error: An authentication error has occurred. The specified target is unknown or unreachable.

If I turn off requiring NLA on the farm servers, I can connect.
Next, I added RDC 7.0 and tried again. I get the same error. 
I tried from more XP clients, with the same setup and I get some that get in and some that give the error.  VERY CONFUSING.

Turns out,  there is a hotfix out there that fixes this:
I added:, and rebooted.   
Now it works.

What I find interesting is that the hotfix does not specifically lay out this exact error result.ARGH.If it had I would have found it SO much faster.

Note: WebSSO will still not work unless you have RDC 7.0 on your XP client - RDC 7.0 is a requirement for WebSSO.  

Tuesday, August 17, 2010

Minimum Certificate Requirements for Typical RDS implementation

I see this question a lot on the Microsoft RDS forum:  What certificates do I need to purchase in order to sucessfully implement a typical RDS environment with farms, and RD Web Access and RD Gateway?

Personally, I like to use separate certs for all needs so that the names on the certs all say what these services represent. 

This is my optimal setup:
  • 1 cert per farm name (farm1.ash.local, farm2.ash.local, etc)
  • 1 cert for rd gateway (
  • 1 signing cert (
  • 1 web cert (SAN cert if no hairpin turn in the firewall) (rdweb.ash.local and
And really, certs are like 30 bucks each these days. So it’s not a huge expense.  Still for small businesses, it might still be an expense they wish to forgo. 

So, to set up RD Web Access, RD Connection Broker, RD Session Host server farms and RD Gateway with the least amount of certs: 

Get one cert for each farm name. (reason: you can't use SAN certs for server auth):
  • farm_1.domain.local
  • farm_2.domain.local
  • farm_n.domain.local
Install the pertaining cert to each appropriate farm member (make sure private key is included on each cert on each server). 

The cert you SIGN your remoteapps with needs to be the SAME on EACH farm member in ALL farms (so websso works across farms). 

Get a SAN with to cover all RDWEB names and RD Gateway names and RemoteApp signing:   
  •  rdweb.domain.local (if you use an internal URL),,, 

Install it to RDWEB, RD Gateway and on ALL farm servers in every farm.  Also install it on RD Connection Broker server.  

Configure it as a signing cert in RemoteApp Manager on ALL farm members and also in RD Connection Broker.  (Note, that this cert is only for signing on the farm already have a farm cert for server auth)

Configure it as the RD Gateway server cert in RD Gateway Properties.   

Reboot all servers and test.
This works for me. :)

Other cert info:

Tuesday, July 20, 2010

How to test RDS farm scenarios with self signed certificates

I have seen a lot of folks out there getting frustrated when fully testing out a RD Session host server farm scenario because they keep getting annoying yallow warning messages when they attempt to connect to the farm.

If you try to connect to a farm, for example, farm1.ash.local, you get a big yellow warning like this:

The warning is telling you the truth: the requested farm name is not the name on the certificate. This is because RD Config is set to use the default certificate to identify itself. That cert is self-generated, and therefore contains the server name, not the farm name:

You can of course buy an SSL certificate whose common name is the name of your farm, put it in place on all your farm servers, and then this message will go away. However, there are many people out there that don't want to invest in an SSL certificate when you are just in your testing phase.  So how to make this work....

You can create self signed cerrtificates on a RD Session Host server, but the name on that certficate is the name of the server, not the name of the farm.

If you try to create a self-signed certificate using RD Gateway, it will let you. However, the certificate is not importable to other machines because the private key is not exportable.

My solution is to download the IIS 6 Resource Kit and use a tool called SelfSSL.exe. Using this tool, you can create a self signed certficate, whose private key is exportable, and whose common name can be anything you like.

For example, to create a self signed certficate for the RDS farm called farm1.ash.local, you would run this command (make sure to start your command console with elevated priviledges!):

C:\Program Files (x86)\IIS Resources\SelfSSL>selfssl /N:cn=farm1.ash.local /K:2048
Microsoft (R) SelfSSL Version 1.0
Copyright (C) 2003 Microsoft Corporation. All rights reserved.

Do you want to replace the SSL settings for site 1 (Y/N)?y
The self signed certificate was successfully assigned to site 1.

Then when you look in the computer certificates store, you will find the certificate under the personal store:

Note: You can run SelfSSL on a Windows 7 machine :)

The private key is exportable, as shown by the little key located in the upper left hand corner of the certificate icon. This means you can move it to another server.

Next you need to export the certificate so you can import it to all of your RD Session Host servers in the farm:
  1. Right click on the certificate and choose All Tasks --> Export....
  2. As you run through the Export Certificate Wizard, make sure to choose to export the private key.
  3. Enter a password for the file for security, and save the resulting .PFX file.

Now you need to import the self signed certificate to your RD Session Host server farm members.  On each member:
  1. open the computer certificates MMC, right click on the Personal store/Certificates folder, and choose: All tasks --> Import...
  2. This starts the Import Certificate Wizard.
  3. browse to the PFX file you created earlier.
  4. Make sure the file extension dropdown box is set to All Files, and then choose your file and click Open.
  5. Enter the password
  6. install the certficate to the personal store (it is chosen by default)
  7. Click Finish.
Now you have a self signed certificate that contains the farm name on all of your farm members, so you can test farm access now without getting a message that the machine you specified in RDC was not the name of the responding server.

Now, you also have to install the self signed cert into the Trusted Root Certification Authorities / Certificates folder in the Computer Certificate Store, on every computer you will connect to the farm with. If you don't you will get this error:

In a real life situation, you would purchase an SSL certificate from a public CA that is part of the Microsoft Root Certificate Program ( so the CA certificate used to sign the SSL certificate would automatically be downloaded to the computer Trusted Root folder via Windows Updates.

But in a test situation, you have to do this part for yourself, since your self signed certificate is not part of this program.