#LyncDevQ: Lync Shared Desktop and Admin Control with UAC
Sometimes people send me questions via email or Twitter about Lync Development. Rather than reply, which benefits one person, I write them up here, so that others can benefit too. You can see all the questions in the LyncDevQ category. Do you have a question?
Q: We want to use Lync for help desk operations since we take care of multiple sites. Is there anyway for us to use our admin abilities through a Lync shared desktop? For example I figured out how to get the UAC prompt for an admin password to show up by editing the Group Policy but am still unable to type in the username and password through a shared desktop. Is there any way to make that accessible for us through Lync??
The super-short answer is No – you can’t control the Username / Password prompt, and you can’t control the Yes/No UAC prompt unless you modify the local computer and disable it. However, from searching around you probably already know that – so I want to outline why it’s the case.
At its heart, Lync is a communication tool, not a IT support tool. There’s no denying that it’s really useful for doing IT support – but that’s just one use-case. IT support is really the only application in which this feature would make any sense.
Because it’s an edge case, it would have to be a configurable option. Organisations would need to be able to turn it on/off for specific users, and only give that control ability to certain users. Some organisations would not want it enabled for federated users, some (with outsourced support teams) would. By itself this increases the development, testing and documentation requirements needed to bring this to market.
It’s technically non-trivial. UAC was designed to prevent rouge applications from gaining administrative control. Any solution that bypasses that has to be 100% sure it’s not opening a vulnerability in UAC. Doing this in a communication application that’s usable by federated contacts outside the organisation makes this even more important.
There are better tools to do this. Coming back to my first point – it’s a lot of code to put into a communication tool (and then support). I know it’s better at getting through firewalls and holding connections than some of the alternatives – but that doesn’t make it the right choice.
So, what can you do?
Two things, I think.
Use all the technologies. There will be a way of achieving what you want to do without using Lync. Group Policy, Remote Registry, Remote Desktop, Remote Assistance – not to mention the 3rd party support tools such as Spiceworks and a thousand others. Just because you can’t get a desktop session to a machine doesn’t mean you can’t control it.
Lync is still an excellent choice when you’re talking with your users about something they’re having problems with. In fact – in some ways it’s better than being there, because it forces you to step into their shoes and their security settings. If there’s something they can’t do regularly without you typing in a password – well, that’s a process problem.
Hope that helps.
-tom
Written by Tom Morgan
Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.
Well, there is a simple solution to bypass this.
1- create a scheduled task to run at logon
2- task should run the Lync with System account
3- The user can type in their username/password to login as usual and if they share their screen you can run any app in admin mode and it will not freeze
The downside is that user need to type his/her username everytime they sign in to their computer