Remote Assistance and Mandatory Profiles on Windows Server 2012

by · Published · Updated

UPDATE: Microsoft has provided an update for solving this issue. See KB3103699.

Introduction

As you may already know, Microsoft replaced their previous remote control capabilities, a.k.a. shadowing, with Remote Assistance for supporting users. We may have different opinions about Remote Assistance, but it is pushed by Microsoft and therefore we have to deal with that, unless you use a third party remote control solution. The same goes for Citrix XenDesktop 7. They also moved to Remote Assistance for both Citrix XenDesktop 7 (already used in Citrix XenDesktop 5.x) and Citrix XenDesktop 7 App Edition (previously Citrix XenApp).

A couple of weeks ago, I was implementing a proof of concept at a customer using Remote Desktop Services on Windows Server 2012 and Microsoft  User Experience Virtualization (UE-V). I implemented UE-V using a mandatory profile for the RDS users. Something I had to test was remote control using Remote Assistance. During this test I came across this error message, which was presented to the user that I wanted to remotely control.

remote-assistance-1

Research

When looking up this error message on the Internet, I saw it isn’t new, and it is well described. Like the error message suggests, it has something to do with the user type/profile. In this case a mandatory profile type. There is a workaround, in which case you spoof the profile type by adjusting a value in the registry (HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionProfileListState (REG_DWORD)).

remote-assistance-2

In our case, the user has a state value of “5”. When we look at the following list, we can see how this state key value was constructed.

remote-assistance-3
Source: Windows IT Pro

The values “0001” and “0004” are accumulated. When we change the state value to anything other than “1” or “5”, it is possible to remotely control the user using Remote Assistance without any errors.

What can be the issue?

Spoofing the profile state results in the profile (registry part and file system part) not being removed when the user logs off. Now imagine that during the day you have a lot of users logging on and off on a RDS/XenDesktop 7 App Edition server. You may have a lot of garbage and high storage consumption on your server. If you have a good server reboot and cleanup strategy, this may not be a problem for you, as long as you actively monitor disk space on your server. The same goes for Citrix Provisioning Services with a read-only vDisk for your servers and a write-cache disk attached. Profiles that are written to the “C:Users” folder are actually written to that write-cache disk. You really have to think about the amount of disk space you want to allocate for your write-cache disk and you also have to actively monitor disk space on your server.

Like the title of this chapter says, “What can be the issue?”. It doesn’t have to be an issue. But if you’re using Windows Server 2012 with mandatory profiles and you want to use Remote Assistance, then keep in mind that you may run into this issue.

Other options are:

  • Do not use mandatory profiles
  • Do not use Remote Assistance
  • Use a third party remote control solution

What I have tested so far

When you un-spoof the profile state back to the original value, in our case “5”, before you logoff the user, the user profile is correctly removed from the registry and file system. However, this was all tested with an account that has permissions in HKEY_LOCAL_MACHINE. Automatically spoofing the profile state (even though it’s HKEY_LOCAL_MACHINE and the user doesn’t have permissions) is possible using a Group Policy Preference at user logon. But un-spoofing, by changing back the profile state value in HKEY_LOCAL_MACHINE, is something that I haven’t figured out yet.

If someone has a brilliant idea to resolve that last piece of the puzzle, please leave a comment.

Tags:

You may also like...