Sunday, March 6, 2011

Lync Server 2010 Desktop Share issue with Windows 7 and UAC: “Share control is disabled for elevated applications.”

For those who have come across one of my earlier posts about:

OCS 2007 R2 Desktop Share issue with Windows 7 and UAC

… I finally had some time over this weekend to try testing the same scenario with Microsoft Lync and the results were more or less the same with the only difference being a new warning message is displayed in the Lync client. The following screenshots demonstrates the problem:

A desktop share is initiated:


The shared desktop loads:


Control is given to the person viewing the shared desktop and he proceeds to open the registry editor:


Opening the registry triggers UAC so the person viewing the shared desktop sees the following message:

Sharing is currently paused.


The person sharing their desktop sees the following:


Once the user sharing their desktop proceeds with selecting Yes to UAC, the shared screen loads:


However, the person viewing the shared desktop can no longer move the mouse. The person sharing the desktop can reclaim control:


Then give control again:


While the person viewing the desktop can move the mouse again, they will find that they cannot move or interact with the registry editor. What’s different about Lync Server 2010 and OCS 2007 R2 with this issue is that in Lync, you will see the following warning message in the instant message window of the person sharing their desktop:

Share control is disabled for elevated applications.


Clicking on the text will show the following message:

There are applications running at an elevated privilege on your desktop. A participant in control will not be able to control these applications.


As with OCS 2007 R2, disabling UAC appears to fix this problem but it’s probably not the best solution due to security concerns so I will update this post if I ever figure out if there is a way to get around this without disabling UAC.


DrRez said...

Thank you for this article. I checked with a few folks and am told that the behavior you describe is by design. For security reasons, it could be harmful to allow a participant to remotely control an elevated privileged application. Hope this helps.

Anonymous said...

Hi all. This is utterly stupid. MS has really lost themselves into a state of paranoia, excluding effective use of absolutely required remote control abilities in an enterprise environment. Why are there no options for exceptions?

Terence Luk said...


The only option is to disable UAC. I don't have a strong enough structural understanding to tell you why Microsoft chose to go with this design but I'm sure that there's a good reason why. Have you tried using the service? I believe that desktop share service exhibits the same behavior so it's not only Microsoft that believes the registry should be locked down.

Anonymous said...

but disabling UAC doesn't solve the problem since I'm Working in IT department and in my organization the users doesn't have administrative previleges.
In vista and 7 I disabled UAC in some machines due a application installation trouble.
In future instalattions I tried to install a software directly in pc (without lync) using the oiption Run as administrator... and the result is that the windows doesn't ask for elevated credentials and when tries to write in system areas as Program files folder, system folder and registry says that I dont't have administrator privilegies

Ben said...

I agree that this is silly. If you have an elevated window open, and you are in remote control and you bring that window to the foreground, you lose control immediately. Really dosent make sense, and makes remote control for support purposed useless.

I really think there should be some server setting to allow the 'feature' to be overridden and allow control. Including being able to access the UAC prompt. If you need to support someone, you need to be able to type in a local admin password on their behalf. I think it should also handle elevated windows better, ie. by now allowing you to click on them and then lose remote control!

Anonymous said...

Starting the Lync process (communicator.exe) from a priviledged cmd.exe will allow one to control the remote session, but I agree this is neither a solution nor a good workaround. Maybe we can still find a way to solve this issue without having to disable UAC...

Anonymous said...

Right click on "Microsoft Lync 2010"

Click on "Compatibility" tab

Check "Run this program as an administrator"

Above setting will make sure that user is using lync client in admin mode with out disabling UAC.

You will be able to give control to others with elevated privilege apps running on your desktop.

Anonymous said...

I dont understand why they make Lync not allow UAC prompts show through, if you use Offer remote assistance and have a certain group policy set, the uac prompts show through the remote assistance and i can support the user and enter admin passwords as needed. Unfortunately this only works internally and we need something to support remote people who remote assistance doesnt work for. I was hoping Lync would be that application, but it appears this is not the case.

Unknown said...

I wrote this little app to help with this situation. Just copy it to the desktop of the user you want to support, run it, put in your domain creds at the top and then you can launch anything you want to and it'll use your domain creds. You won't get the UAC popup this way.

P.S. - Google is saying that the 32 bit is a virus, I'm not sure why. You can check the virus total link I posted up there and decide for yourself. I'm trying to see what my options are for getting them to remove that warning.

sc_dem said...

Hi Thad - your download links don't seem to work. Can you re-upload them or post them elsewhere besides google docs? Really curious to try them with Lync shared desktop.

LedStew & CT&D Consulting said...


The link you have posted is not a valid link. Could you please email me your app or make it available else where?