Tuesday, October 19, 2010

OCS 2007 R2 Desktop Share issue with Windows 7 and UAC

Ran into an interesting problem/discovery today while in the office when a colleague of mine was trying to assist someone in Montreal who had an issue. What he noticed was whenever he opened the registry on the user’s desktop, he would lose control of the session. I’ve never encountered this problem before so I tried replicating the problem between us and the following are the details of the findings:

Environment

Terence’s laptop: Windows XP Pro 32-bit

Terence’s Microsoft Office Communicator 2007 R2 version: 3.5.6907.196

image

Colleague’s laptop: Windows 7 64-bit

clip_image002

Colleague’s Microsoft Office Communicator 2007 R2 version: 3.5.6907.196

Problem

1. Colleague initiates a desktop share to share out his desktop to Terence.

2. Colleague gives control to Terence.

3. Terence goes to Start, types in Regedit to open up registry and hit’s the Enter key.

image

4. Terence’s colleague is prompted with the UAC window.

5. Terence see’s the following window:

image

6. Once Terence’s colleague clicks allow for the Windows UAC prompt, Terence can now see the registry window but finds that he is unable to move the mouse even though the indicator at the top reads that he’s still in control.

image

7. Colleague is able to control his own desktop so he proceeds to take back control.

image

8. Colleague then gives control back to Terence.

image

9. Terence is still unable to control the mouse.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

After seeing this first hand, I immediately had a hunch that it had to do with any window that requires UAC intervention so after asking my colleague to close the regedit window, I proceeded to go to Control Panel –> User Accounts –> User Accounts –> Change User Account Control settings to have a look at the UAC settings and what I noticed was that once I got the window opened, I lost control of the cursor again.

image

What I wanted to do next was to lower the UAC level to see what would happen and this was when I inadvertently noticed that I would regain control of the cursor if my colleague deactivates the window (i.e. in this case, clicking on another window rendering the User Account Control Settings inactive). We tried the same for the registry editor window and got the same results so it was interesting to see that the window requires UAC authorization is the only window that is affected.

I proceeded to change the UAC level to the lowest level and tried again to see if the results would change but noticed that I would still lose control as soon as I click on the windows requiring UAC.

image

I’m almost 100% certain that this has something to do with UAC as I tried replicating this on my laptop which was Windows XP and did not have this problem. We don’t have any Vista machines in the office so I wasn’t able to test that operating system.

Since I’m currently working on another CS1000 with OCS 2007 R2 integration, I’m going to test this at the client’s location to see if I get the same results. I’ll write back as soon as I get this tested out.

9 comments:

Tim said...

We have the same issue. We are opening a case with MS. It is due to the UAC. You will see this same type of behavior when running remote assistance.

Terence Luk said...

Thanks Tim. I have yet to post this on our Microsoft Partner forums so I'll do so tonight and see what they come back with. Let me know what you find out from the case if you get the chance. Thanks.

Terence Luk said...

Hi Tim,

Our Microsoft Partner support got back to us and told me that disabling UAC works but the workstation needs to get rebooted. I haven't tried it yet as I just turned off UAC during my testing so I'll write back when I get a chance. Thanks.

karthik said...
This comment has been removed by the author.
karthik said...

hi all. i had the same issue. and i followed above steps and completely disabled UAC to resolve this and it worked fine.
Now my question is will there be any security issue if we disable UAC?

Terence Luk said...

Hi Karthik,

Thanks for confirming that disabling UAC and rebooting does indeed fix the problem. As for security, this will surely affect it as UAC was designed to protect users.

SK said...

Is there any other way to resolve this issue without disabling UAC ?

AtheistX said...

Remote access tools in general have access to the interactive desktop session but not the secure desktop session.
When UAC/Elevation type prompts are presented they are displayed on the "Secure Desktop".
Try tweaking the below.
Group Policy>Computer Configuration>Windows Settings>Security Settings>Local Policies> Security Options
User Account Control: allow UIAccess applications to promt for elevation without using the secure desktop -> Enabled
User Account Control: Switch to the secure desktop when prompting for elevation. -> Disabled

Anonymous said...

Great, thanks AtheistX, worked a treat!