I’m not using Roaming Profiles, what am I missing?

This question, or something related to it, comes by from time to time. I also see these kinds of questions asked in TechNet forum a lot. So what are you really missing when you’re not using roaming profiles?

Before we get to the bottom of this, let’s get the terminology straight first. Roaming profiles is part of Microsoft’s User State Virtualization (USV). USV is the separation of user settings and data from an end user's personal computer or Remote Desktop Session Host (RDSH).

The term user settings refers to the different kinds of customizations that a user can perform on a Windows operating system. Examples of these user settings are customization to the taskbar, the background but also customization in applications like Microsoft Office. To have these user settings roamed with the user upon logoff, logon and when logging on to a different computer (or RDSH) you can implement roaming profiles.

The term user data refers to the files and folders that a user can maintain on their computer(s). Usually this data is inside well-known folders like My Documents, My Music etc. To have this user data available after logoff, logon and when logging on to a different computer (or RDSH) you can implement folder redirection.

As a side note, when implementing roaming profiles it’s recommended to also implement folder redirection. Why? If you don’t, the user data will be part of the roaming profile and will be copied over from the central profile storage to the client! Not something you would want to happen of course.

The last part of USV is offline files, which I’ll not be discussing further in this blog.  For more information on offline folders see the related links at the end of this blog post.

So let’s focus on the roaming profile. A roaming profile is a collection of folders together with the registry hive HKey Current User (HKCU). As you might know the setting inside HKCU are stored in the NTuser.dat file in the users profile folder and cannot be redirected using folder redirection.

Ok. Now that we got the terminology in order lets back to the original question in this blog. Without Roaming profiles, what settings could you be missing?

Here are some examples of user settings that cannot be centralized without implementing Roaming User Profiles. (note that this list is an example and not exhaustive, there could be more settings)

Setting	Example of a change
Themes	Change the current theme used to customize the desktop background, window colors, sounds and screen saver for
Sounds	Change the sounds that should be planed when various system events occur.
Desktop background	Select a folder containing pictures to be displayed as a slide show on the user's desktop.
Screen saver	Select a screen saver and configure the timeout interval.
Desktop icons	Choose whether icons such as Computer, Network and Recycle Bin should be displayed on the user's desktop.
Mouse pointer	Enable or disable mouse pointer features such as pointer trails and pointer shadow.
Display settings	Change the displayed text size from 100% to 125% to make it easier for the user to read what is displayed on the screen.
Taskbar settings	Configure the taskbar properties to auto-hide the taskbar.
Start menu	Configure the Start menu to not store and display recently opened programs.
Accessibility	Configure Magnifier to invert the colors of the magnified area of the screen.
Regional Options	Change the currency symbol and the long date format.
Keyboard settings	Change the repeat delay and repeat rate when a key is pressed.
Action Center	Turn different types of notification messages on or off in the Action Center
Problem Reporting	Specify whether Windows should check for solutions to problems that are found on the computer
Folder Options	Configure Windows Explorer to open each folder in a separate window, to show hidden files, to use partial matches when searching indexed locations, and other settings configured by selecting Folder Options from the Tools menu.
Windows Explorer	Configure Windows Explorer to display items within a folder using Extra Large Icons.
Libraries	Configure the Documents library to arrange documents by Author. Create a new Library that includes a shared folder on a network file server. (Note: Libraries of this type can also be roamed by enabling Folder Redirection for the AppData(roaming) folder.)
Internet Options	Change the home page, disable tabbed browsing, change the security level for the Intranet Zone, and make other changes using the Internet Options Control Panel.
Windows Media Player	Configure how often Windows Media Player checks for updates, specify privacy settings, configure Media Library settings, and make other changes to Windows Media Player by selecting Options from the Tools menu.
Printers	Add a printer connection to a network printer published in Active Directory.
Network connections	Set up a Virtual Private Networking (VPN) connection to a VPN server on a remote network.
Mapped drives	Map a drive letter to a shared folder on a network file server.
Command prompt	Change the buffer size in the command prompt properties.

Some examples of Microsoft Office settings that cannot be centralized without implementing Roaming User Profiles.

Instelling	Voorbeeld wijziging
Ribbon	Minimize the ribbon.
Quick Access Toolbar	Position the Quick Access Toolbar above or below the Ribbon.
Word Options	Enable Live Preview, show formatting marks for Tab characters, specify the language for a custom dictionary, ignore UPPERCASE words when spell-checking, personalize your copy of Office with your username and initials, specify autosave settings, or configure other Office personalization settings by configuring Word Options, PowerPoint Options, or another Office application's Options dialog.

And an example 3^rd party application (Adobe Acrobat Reader). These settings that cannot be centralized without implementing Roaming User Profiles.

Instelling	Voorbeeld wijziging
Toolbars	Display or hide the Edit toolbar.
Preferences	Specify the default page layout and zoom level, configure how often open documents should be saved to a temporary file, change the underline color for spell checking, and configure other settings by selecting Preferences from the Edit menu.

These examples are taken from this Microsoft document: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fd01ed7a-c603-4f7c-8a60-8e4872b58bdf

This document also describes thoroughly all the things you need to consider before choosing the User State Virtualization that suits your environment best. The question “Which USV combination is best?” can, as all IT question, be answered with “it depends”. It depends on end-user requirements and IT requirements. So, if in doubt about what USV options to choose, this document provides an excellent guide.

One last option I would like to discuss. New to Window 7 and Windows Server 2008 R2 is the option called “Background upload of a roaming user profile's registry file while the user is logged on”. This is a GPO setting that can actually be used to upload settings inside the HKCU without a logoff. This can be very useful because without this setting the HKCU is only uploaded to the central storage at logoff. A  scenario where this policy provides benefits is when an organization has users who work remotely from their laptops. Users who hibernate their laptop off can still have their user settings uploaded to the profile server. Another possible benefit with this is that the settings inside the HKCU can be roamed when logging into other machines or devices without having to logoff on the device where the settings were changed!  The policy can be found here:

Additional information:
http://technet.microsoft.com/en-us/windows/ff629664
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=fd01ed7a-c603-4f7c-8a60-8e4872b58bdf
http://technet.microsoft.com/en-us/library/ff877478.aspx
http://go.microsoft.com/fwlink/?LinkId=200543

Optimize my experience for a LAN network when connecting to the computer or application.

If you have upgraded your Windows Server 2008 R2 RD WebAccess server to Service Pack 1 (SP1) and open up the RD WebAccess page after that, you’ll notice a very small change on the RemoteApp Programs page. Suddenly there now is an option called “Optimize my experience for a LAN network when connecting to the computer or application”.

So what does that option do? A quick search on Bing only shows one result. A search with some other search engine (that starts with a G) doesn’t show more either.

So why is this option suddenly there and what does it do?

During the installation of SP1, the web.config file inside c:\windows\web\rdweb\pages is also being updated. The following lines have been added:

<add key="ShowOptimizeExperience" value="true" />
<add key="OptimizeExperienceState" value="true" />

You can use ShowOptimizeExperience to either show the option in RD WebAccess or not and you can use OptimizeExperienceState to force it being on or off.

So what is it used for? RemoteFX!

As RemoteFX is optimized for LAN connections, users must request a LAN connection to actually experience RemoteFX. That’s what the option is there for. It’s basically the same as custom RDP setting “connection type:i:6”.

Force the use of RD WebAccess (block direct mstsc.exe connections)

Consider the following scenario:
You have one or more RD Session Host servers running on which you installed and configured applications and settings. You want to publish this full desktop using a full desktop to your end-users using RD WebAccess and via RD WebAccess only.

When you publish the full desktop via RD WebAccess (whether it’s via a RD Gateway or not). Users will be able to directly contact the RD Session Host (or via RD Gateway) using their local Remote Desktop Client (mstsc.exe). Why? Because RD WebAccess does nothing more than provide you with the rdp-settings to use after you have authenticated. When you start a full desktop session via RD WebAccess mstsc.exe is launched under the hood. Therefore, when you have knowledge of the name of the RDS farm (and the FQDN of the RD Gateway) you will be able to bypass the RD Webaccess and just launch mstsc.exe

Remember that there is difference between in the way the .rdp is built when launching a RemoteApp or a full desktop. (see here: http://microsoftplatform.blogspot.com/2011/05/rd-webaccess-and-unknown-publisher.html )

Microsoft states this scenario as “expected behavior”. And, there right about that of course. Access is possible because of the way RD WebAccess works. (RD WebAccess is not some form of proxy). In some scenario’s the ability to access the environment could in fact be thought of as a form of workaround when the RD WebAccess temporarily unavailable.

There are multiple scenarios however, in which being able to connect directly is not the desired functionality.

For example, when you have made heavy customizations on your RD WebAccess page and want to inform users with news of updates on the availability of your environment using this page you would want to have your users to actually go through the RD WebAccess page to take note of those updates.

Another scenario is where you have setup a form of Two Factor Authentication (2FA) on your RD WebAccess page and want your users to always use this 2FA. By having them access the environment without accessing the RD WebAccess they can actually bypass the 2FA.

A solution for this scenario can be achieved by making use of ISA (or TMG). My colleague explains the way we successfully set this up thoroughly in a blog post here: http://www.forefrontblog.nl/2011/05/06/publishing-rds-web-rsa-and-preventing-direct-logon/

You can find a detailed configuration in the blog post above but basically what you do is you create two rules in ISA that use the same HTTP listener. The first rule will have the destination of the RD WebAccess server; the second rule will have the destination of the RD Gateway server. By doing so (based on cookie authentication) you will only be able to access the RD Gateway (and thus the RDS farm) by making first authenticating on the RD Webaccess rule (on which you could configure your 2FA as well). This will force users to always use RD WebAccess.

Small note:

A change in a .aspx file that RD Webaccess uses is also necessary, for RD WebAccess based on Windows Server 2008 R2 the change should  be:

RDPstr += "pre-authentication server address: s: https://<RDWebAccess FQDN>/rdweb\n";
RDPstr += "require pre-authentication:i:1\n";
RDPstr += "";

And note that the cookie is authorized for 10 minutes by default. This value can be changed in ISA, but during testing make sure that you delete your browsers cookies before testing the inability of directly connecting using mstce.exe

Hotfix KB2522743: Calendar control in RemoteApp

Microsoft released a new hotfix today regarding using a calender control in a RemoteApp. In this scenario, the calendar control opens for a split second and then closes automatically. Therefore, you cannot use the calendar control.

Article ID: 2522743 - Last Review: May 6, 2011 - Revision: 2.0
You cannot use a calendar control in a RemoteApp application when you use the RDC 7.0 client to connect to the RemoteApp application from a computer that is running Windows 7 or Windows Server 2008 R2http://support.microsoft.com/kb/2522743/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!

Shadowing error: The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.

In addition to an earlier blogpost about troubleshooting shadowing (remote controlling) sessions; http://microsoftplatform.blogspot.com/2011/04/troubleshooting-remote-control-session.html

Microsoft released KB2533983 yesterday. This is about shadowing remote session in which Aero is enabled. This is not supported and could raise the following error:

The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.

How do you know Aero is enabled for a user? The existence of the Dwm.exe process in the user session indicates that Aero is enabled for that session.

In addition the following events are raised:

Log Name: System
Source: TermDD
Date: 4/5/2011 1:14:24 PM
Event ID: 50
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computername.domain.com
Description:
The RDP protocol component WD detected an error in the protocol stream and has disconnected the client.
Log Name: System
Source: TermDD
Date: 4/5/2011 1:14:24 PM
Event ID: 56
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: computername.domain.com
Description:
The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP: fe80:0000:0000:0000:e499:f014:83ea:8221.

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

RD Gateway using NPS and NAP (Network Access Protection)

As you might know the Remote Desktop Gateway (RDGW), which is one of the components of Remote Desktop Services, uses two kinds of policies. Connection Authorization Policies (CAP’s) hold the configuration of who can access resources behind the RDGW. The Resource Authorization Policies (RAP’s) consist of the information of what resources (i.e. servers of farms) can be accessed by users that have an entry in the CAP.In a standard configuration a RDGW uses a local store for its CAP which is based on Network Protection System (NPS) and the configuration of the CAP is done by using the RDGW Manager.

In this scenario I wanted to test a Remote Desktop Gateway (RDGW) using a central server running NPS. Why would I want to do this? Most obviously because this way I could create a second RDGW server that would use the same central NPS server for its CAP’s with which I would be able to create a form of High Availability (HA) for my RDGW. But besides this reason, using a central server running NPS I am able to make use of Network Access Protection. With a combination of RDGW and NAP I would be able to set restrictions on the workstations before letting them be able to connect. In other words I can set rules that clients have to be compliant with before I let them through my RDGW. Why is this interesting? When using managed clients (i.e. clients that are members of your domain) you can, of course, create all kinds of policies to enable firewall, virus scanning etc. But what about those non-managed clients? The term bring your own device (BYOD) is becoming more and more popular. A good evolution because why would you still want to manage client machines if all they access is some kind of cloud service (in the broadest sense of the word, a RemoteApp that runs behind your RDGW)? Using RDGW and NAP together you can define a compliance policy so that you can enforce that only clients that are compliant may connect. These compliance policies can include i.e.

·         The Windows firewall must be enabled

·         Ant-virus application must be running

·         Anti-virus must be up to date

·         Anti-spyware must be running

·         Windows updates must be enabled

·         Windows updates must be up to date

How does this work? Without going into detail, the client reports a statement of health (SoH) to the RDGW. Based on this SoH the RDGW checks the CAP’s that are stored on NPS server. If the client is compliant it will let it through, if not an error is raised to the client that it is not compliant including the actual reason why.

So let’s take a look at the scenario in this lab. I have set up the following machines:

-          Windows Server 2008 R2 with RD Gateway role

-          Windows Server 2008 R2 with RD Session Host role

-          Windows 7 client machine

-          And of course a Domain Controller (also Windows Server 2008 R2)

Our goal: Set an environment in which the Windows 7 client can only connect to the RDSH via the RDGW when the Windows Firewall is running on the Windows 7 client. And, on top of that, perform an auto-remediation on the client by automatically enabling the Windows Firewall if it’s not running and inform the client that he’s now compliant. Sounds like a lot of work, but it will turn out to be surprisingly easy!

We are assuming that the RDSH server already has the RDSession Host role and that a group is created and configured to be allowed to connect to the RDSH server using RDP. (Preferable using a GPO).

We also assume that the RDGateway server already had the RD Gateway role installed without any CAP’s or RAP’s defined during the setup and that we selected local NPS storage during the setup.

After issuing a SSL certificate for our RD Gateway server to our local CA and selecting it on the SSL certificate tab on the properties of the RDGateway, we’re ready to configure the NPS and RDGW.

We start by creating a new RAP in the RD Gateway Manager.

Remember to only create the RAP, not the CAP. We enter the name “RDS RAP”, enter the security group that holds the user we want to allow to connect and use the RDSH server as the Network Resource to be allowed to connect to.

On the RDGW properties in the RDGW manager on the RD CAP Store tab we make sure that “Request clients to send a statement of health” is checked. Remember that we do this to have the clients send their SoH to the RDGW.

We now open up the Network Policy Server (can be found in the admin tools section of the start menu of the RDGW server). You can of course, have the NPS server running on a different machine, but for the sake of the demo we have it running locally on the RD Gateway server.

Right click the RADIUS Server Groups and click new.

Enter a name and add the central NPS server by clicking Add and use the FQDN of the NPS server. Enter a shared secret, and note it down.

Now right-click the Connection Request Policies and choose new

Enter a name and choose Remote Desktop Gateway as the type
Add the NAS Port Type and select Virtual (VPN).

Click next and select “Forward request to the following remote RADIUS server groups for authentication” and make sure that the group you created earlier is selected.

Open the properties of the Default Configuration in the settings of the Windows Security Health Validator

For this demo we’re only going to check the Windows Firewall, so make sure that this is the only one that is selected here

Now move all the way to the top, select NPS(local) and click Configure NAP

On the first screen select RD Gateway and leave the default name
Next add the RD Gateway server by using its FQDN, and enter the same shared secret as used earlier.
Leave the default redirection settings and timeout settings in place
Now add the user group that you used earlier (the one that you want to allow to connect)
Make sure the Windows Security Health Validator is select and hit next and finish

We now have the basic configuration running. We have created three network policies:

 And two health policies:

Let’s make sure that auto-remediation is turned on. Remember we run this auto-remediation when a client is not compliant, so the setting is in the properties of the NAP RD Gateway Noncompliant on the settings tab:

That’s it for the configuration on the server side. To have a fully operational client with NAP auto-remediation capabilities we need to configure the client. We can quickly do this by running Tsgqecclientconfig.cmd which can be downloaded here:

http://www.microsoft.com/downloads/en/details.aspx?familyid=cb986639-20e5-4f16-8e48-be68d23dc888&displaylang=en

Ok, we’re done! Let’s do some testing!

We open up our Windows 7 machine and make sure all Windows Firewalls are disabled on it:

We create a .rdp file that has the correct RDSH server as the destination and the correct RD Gateway server configured and hit connect.

The first error we get is:

Which is good, because we are in fact not compliant with the policy!

Now comes the good part, a balloon of the NAP client pops up, when we click it we get the following dialog:

Which again tells us that we’re not compliant, but on top of that it also tells us why, The Windows Firewall is not running. AND: it’s attempting to fix this as mean of remediation!

We hit close. The NAP dialog gets updates as shown below:

We try to connect again: no errors and we’re allowed to connect!
Why? Because the auto-remediation did it’s work and automatically enabled our Windows Firewall again and made our client compliant again:

And these are just the basics! The combination of the RD Gateway and NPS(with NAP) generates lots of possible scenarios and is very flexible! Especially the fact that you can also create your own System Health Validator (SHV) or make combinations! And I haven’t even talked about Remediation servers that you can add to your environment as well.

For now, these are the basics, hope it was useful! I might do a new blog on this and take this NAP configuration a little further by extending it with a custom SHV and doing some NAP troubleshooting as well!

Additional info:
http://technet.microsoft.com/en-us/network/bb545879
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8e47649e-962c-42f8-9e6f-21c5ccdcf490&displaylang=en
http://technet.microsoft.com/en-us/library/dd560672(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc742822.aspx