Remote Control a RDS session in a mixed Remote App and Full Desktop environment

With RemoteApp becoming more and more a common scenario in environments where a Full Remote Desktop is also offered that raises the question, what about Remote controlling a user’s session?

For the people that didn’t already know, Remote Control (often called shadowing) is most commonly used to deliver support to end users. It gives the ability to view, and even interact, with the users Remote Desktop Session.

Before you try to shadow a session keep in mind that you can shadow a session only from another RDP session (because you are intercepting the graphics output of the shadowed session). So you can’t do this from the console. You can only shadow sessions connecting to a full desktop. “Ah”, you say “So if I’m trying to remote control a RemoteApp Session I’ll get an error or a warning?” That’s the funny part, you won’t!

There is nothing in the user interface that prevents you from Remote Controlling a RemoteApp session, and you won’t see any warnings. But, shadowing a RemoteApp session simply isn’t supported, and doesn’t work as you might want to. Here’s why; it requires communication between the server and the client to position the window in the right way and that communication simply doesn’t exist. If the user shadowing the session moves the application’s window it might disappear or become unresponsive to the end-user.

So how to tell the difference between a Full Desktop and a RemoteApp session? The Remote Desktop Services Manager doesn’t tell you the difference that easy. The key to this is the fact that full desktop sessions use Explorer.exe  and Userinit.exe and RemoteApp sessions use Rpdshell.exe and Rdpinit.exe, respectively.

Of course you can ask the end-user to describe the session to you in order to figure out whether it’s a RemoteApp or not but, with all due respect, most end-users will not see or even know the difference.

So here’s two ways to quickly check it out remotely:

1. Open the Remote Desktop Services Manager, select the farm or the RDSH server in question and hit the processes tab. Look for the user that you want to remote control and check whether his or her session has a process rdpshell.exe running, if that’s the case then don’t even try to Remote Control.

2. Fire up a command prompt on the RDSH server and enter:

query process Freek.Willem /SERVER:RDSH01

You can get a result like:

USERNAME SESSIONNAME ID PID IMAGE
freek.willem rdp-tcp#1 2 2276 taskeng.exe
freek.willem rdp-tcp#1 2 3433 rdpclip.exe
freek.willem rdp-tcp#1 2 2937 dwm.exe
freek.willem rdp-tcp#1 2 3637 explorer.exe
freek.willem rdp-tcp#1 2 2712 winword.exe
freek.willem rdp-tcp#1 2 2637 powerpnt.exe
freek.willem rdp-tcp#1 2 3112 excel.exe

No rdpshell.exe here, so note down the Session ID (in this case 2) and start shadowing directly using by entering:

shadow /SERVER:RDSH01 2

That’s all! Happy shadowing!

Some extra info:

How to Connect to and Shadow the Console Session with Windows Server 2003 Terminal Services
http://support.microsoft.com/kb/278845

How to Shadow a Terminal Server Session Without Prompt for Approval
http://support.microsoft.com/kb/292190

Configure Remote Control settings:
http://technet.microsoft.com/en-us/library/cc781839(WS.10).aspx

Administering Remote Assistance

http://technet.microsoft.com/en-us/library/bb456978.aspx

 

Locking down your 2008 R2 RDS Farm

When it comes to setting up a RDS environment in general (whether it being RemoteApps or a full blown desktop) locking down your RDS farm must always be on your priority list. Reading this you must be thinking; okay, point me to the “Locking down RDS Guide” and we’re done. Well, it isn’t that easy I’m afraid. The way you lock down your RDS environment highly depends on the customer wishes, the applications used and the way you want to scale security against user-experience.  

As Brian Madden (Microsoft MVP on RDS) wrote;

“...Do users really need to be able to execute programs from their home drives, temporary Internet files, or the Outlook attachment cache folder? Of course not!”

And I couldn’t agree with him more. Locking down you RDS is all about denying users from everywhere they don’t need permissions. This can be done in multiple ways, directly editing NTFS permissions, using Software restriction policies or AppLocker. The last one is new to Windows Server 2008 R2. Whatever method you choose highly depends on your environment.

We can all agree that directly editing NTFS permission for this purpose is just a lot of work and very inflexible. Software Restriction Policies (SRP’s) which have been around for quite some time can further help you in this. I won’t go into much detail here, you can find all the info you need on setting this up here: http://technet.microsoft.com/en-us/library/bb457006.aspx. Basically, a SRP consists of a security level and one or more additional rules. The security levels describe the methods and are available here:

Along with Windows Server 2008 R2 (and Windows 7) came AppLocker, and this is where it gets interesting. AppLocker has similarities with SRP’s but it is in fact a completely new feature. So what are the advantages? Besides the advantages like AppLocker rules can survive version upgrades and location path changes because they can be based on digital signatures, AppLocker rules are wizard-driven, so they’re easy to set up, AppLocker has Windows PowerShell support via AppLocker cmdlets I really like the following new feature:

Computer Configuration | Policies | Windows Settings | Security Options | Software Restriction Policies | Security Levels

Then you make exceptions to these using the additional rules that are available here:

User (or computer) Configuration | Policies | Windows Settings | Security Settings | Software Restriction Policies

This is a very powerful feature. It can be used to help you determine what the real affect is of the rules that you build. Everyone who has worked with SRP’s or any other form of locking down has been in the situation where you think you build the SRP correctly but somehow are not 100% sure about the real outcome. In environments where you don’t have an OTAP available that reflects the production environment you are forced to trial and error. Furthermore, when it comes to designing and building a new environment audit-mode really comes in handy as well. You can have test users operate on the new environment locked down with AppLocker, have them do whatever need and check the log later to see whether you have made your polices to tight and you get a good glance on what applications are used. For a guide on how to configure this see; http://technet.microsoft.com/pt-pt/library/dd723693(WS.10).aspx

When AppLocker rule collections are configured to user Audit Only mode, actions that the rules would have affected (both allowed or denied) will be logged in the Event log of the machine in question. To give an example; if a user tries to access the application Freek-Willem.exe on a RDSH server where AppLocker has a rule that denies this (in audit mode), the following will be found in the eventlog:

Event Id 8003: %SYSTEM32%\Freek-Willem.EXE was allowed to run but would have been prevented from running if the AppLocker policy were enforced.

To make it complete this is the list of events that you can expect:

Also, only using RemoteApp and no full desktop is not the same as locking down! This has to do with the way RemoteApp works. Although when a user gets presented a RemoteApp it might seem that it’s just an application, it’s still a session that has the same access to the environment that an application on a full desktop would have.

Nice quote from the RDS 2008 R2 Resource toolkit regarding locking down a RDS environment: J

“…We’re Star Wars enthusiasts. As Yoda might say, Ctrl+Alt+End leads to the Task Manager. The Task Manager leads to Run. Run leads to suffering.…”

With that all in mind, keep locking down in your priority list, and configure it to the needs of the environment in question. Keep in mind though that this post doesn’t describe everything you must do, just some locking down you can do. A full lock down involves more than just AppLocker.

To conclude, here’s some extra info:

ü  What’s new: 

http://technet.microsoft.com/en-us/library/dd378941(WS.10).aspx

ü  Technical Documentation:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=025cf2e8-b0ab-4419-b5bb-86ab2d5eca83&displaylang=en

ü  AppLocker FAQ:

http://technet.microsoft.com/en-us/library/ee619725(WS.10).aspx

ü  AppLocker Walk-through demo (5 min. video)

http://technet.microsoft.com/en-us/windows/dd320283.aspx

DFSS, fair-sharing your RDS 2008 R2 environment!

Remote Desktop Services (formally known as Terminal Services) has always been about sharing resources. A single Remote Desktop Server (farm) that all your users can connect to and run their applications on. Sharing resources means less hardware. That does sound great doesn’t it? But what if some users consume so much CPU that it starts to affects other users? You could start isolating these “heavy” users on their own machine or farm, but you lose a lot of flexibility.

In a RDS environment based on Windows Server 2008 you could fairly divide the CPU usage by making use of Windows Server Resource Manager (WSRM). This technique divides CPU-time by watching processes that run on the Remote Desktop Servers and is able to lower the priority of a process when it starts to make heavy CPU usage. So far so good! The only downside is that WSRM is reactive. Meaning that it takes a small amount of time before the priority-change actually kicks in. Although most of the time it’s not more than a few seconds, those few seconds delay could become very annoying to other users when i.e. typing an e-mail.

WSRM also isn’t enabled out of the box. You have to install and configure to let it do its magic. And when you did you could end up with a process used by WSRM that eats away even more of your valuable CPU time J. This bug was fixed by Microsoft though. If you experience this in a RDS 2008 environment see the following kb article: http://support.microsoft.com/kb/970067. (This is fixed in R2).

In Windows Server 2008 R2 Microsoft introduces Dynamic Fair Share Scheduling (DFSS). A kernel based feature that control CPU allocation. It makes sure that each session is not consuming more than its fair share of CPU time. A proactive solution! And, it’s turned on by default! If you want you can disable it here: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SessionManager\DFSS\EnableDFSS

So when you want your sessions to share the CPU equally, you’re ready to go without any extra configuration!

For more advanced scenario’s you can create different groups of users that you want to give different amount of CPU resources. DFSS is unable to do this; this is where the newly built-in policy called “Weighted_Remote_Sessions” comes in. Using this policy you can define a Premium, Standard and Basic group. As you might have guessed, the Premium group will get more resources than the Standard group and the Standard Group will get more resources than the Basic group. To configure this open the WSRM console, right click the “Weighted_Remote_Sessions” policy and choose properties. Here you can start adding the different AD users or groups (preferably).

When you’re done, configure the policy as the managing policy and you’re done! Little side-note: Setting the “Weighted_Remote_Sessions” policy as the managing policy requires a reboot if this wasn’t already selected as the managing policy.

For more info on WSRM on Windows Server 2008 R2 see here: http://technet.microsoft.com/en-us/library/cc754150.aspx

Happy fair-sharing!

RD Connection broker and it’s polling intervals

In a Remote Desktop Services environment where you make use of RD Connection Broker, this blogpost about its polling intervals might come in handy.

To keep track of the status of RD Session Hosts Servers, the RD Connection Broker keeps track of whether the connections that it redirects to the RD Session Host servers in the farm go through successfully. If such a redirection fails, then there might be a problem with the RD Ses­sion Host server (or i.e. the network). Therefore, 1 minute after the initial redirection request, the RD Connection Broker starts pinging the RD Session Host server that didn’t respond. If the RD Session Host server does not respond to a specified number of pings (by default 3, with a interval of 10 seconds) then the RD Connection Broker will remove that RD Session Host server from the database.

In the meantime, users that are trying to connect could end up not being able to. That raises the question, how long could it potentially take before the record of the RD Session Host in RD Connection broker database gets updated? You could end-up having to wait about two to three minutes from the time the RD Connection Broker attempted to redirect a connection to the unavailable RD Session Host before the RD Connection Broker will stop trying to redirect to that server. You will have the same issue when removing the RD Session host from the TS Session Directory Computers group because that won’t directly delete it from the RD Connection Broker database.

There is a way to speed up the process of bringing the database up to date by changing the intervals RD Connection Broker uses and here’s how:

Open the registry of the machine that holds the RD Connection Broker Role and open the following path:

HKLM/SYSTEM/CurrentControlSet/Services/Tssdis /Parameters

And there you’ll see the parameters to control the intervals and you will be able to change them!

And to re-add the RD Session Host server to the RD Connection Broker database, re-add the RD Session Host Server to the Session Broker Computers Group.