none
MSRA from Windows 10 to Windows 10 administrative windows mouse doesn't work

    Question

  • In a domain environment when connecting from a Windows 10 computer to another Windows 10 computer using remote assistance I will launch a window administratively like computer management using an admin account and two odd issues come up:

    1) Right shift doesn't work when typing in credential fields so caps lock must be used for uppercase letters (Left shift key does work).

    2) The mouse doesn't recognize clicks within the administratively launched window. You can click outside of the window but you can only navigate the administratively launched application using the keyboard.

    I've tried running msra both as an admin account and regular domain account with the same result.


    Wednesday, December 23, 2015 6:38 PM

All replies

  • Open start and search for Feedback and open Feedback App and report these issues.
    Friday, December 25, 2015 3:33 PM
  • Thank you I've just done this. Hopefully there will be a fix soon. Is anyone else able to reproduce? I'm able to consistently.
    Friday, December 25, 2015 4:09 PM
  • Hi,

    I am supposing you mean remote assistance in Windows 10, we’d like to test for you but there are too many variables. Where did you launch a window administratively? On invited one or the one who provide assistance? Do you mean open a windows administratively on invited machine in remote session?

    I didn’t find similar issue as you mentioned in my test. I invited a remote assistance from a Windows 10 (10240 let’s say pc1), a local machine (10240 pc2) will provide help in this session, when remote assistance is connecting, then I start mstsc.exe on PC2, I can use Shift to switch uppercase letters (ENG US input method) and enter credentials for another remote connection. And I opened MMC.exe (MMC.exe on PC2) as administrator, but after clicking “Yes” locally, the window opened properly and everything works.

    Also I opened it in remote session (mmc.exe on PC1), but also it worked perfectly.

    If you mean this issue occurs on different build of Windows or it is different case, please provide me more details and we’d love to test for you again.

    From an online searching, few similar case could be found on other forums, but they are old ones about RDP session (not remote assitance) and no definite fixes but appears on different case.

    Perform a clean boot see if the issues still persists.

    Change the RDP client settings as follows:

    1. Click Options in the Remote Desktop Connection User Interface.

    2. Select the Local Resources tab.

    3. Under Keyboard > Apply Windows key combinations, select on the local computer.

    Regards,

    D. Wu 


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, December 28, 2015 2:21 AM
    Moderator
  • I will answer inline:

    I am supposing you mean remote assistance in Windows 10, we’d like to test for you but there are too many variables. Where did you launch a window administratively? On invited one or the one who provide assistance? Do you mean open a windows administratively on invited machine in remote session?

    I launch a window administratively on the remote side. To reproduce the issue I do the following:

    From my pc I run msra /offerra computername. On the remote side I click start, type regedit, right click regedit and click Run as administrator. Once prompted for credentials I type administrative credentials and regedit launches administratively. Within the Regedit window mouse clicks are not recognized whereas keyboard actions are recognized so you have to tab and arrow key everything to navigate. You can't even drag the window to move it or resize.

    I didn’t find similar issue as you mentioned in my test. I invited a remote assistance from a Windows 10 (10240 let’s say pc1), a local machine (10240 pc2) will provide help in this session, when remote assistance is connecting, then I start mstsc.exe on PC2, I can use Shift to switch uppercase letters (ENG US input method) and enter credentials for another remote connection. And I opened MMC.exe (MMC.exe on PC2) as administrator, but after clicking “Yes” locally, the window opened properly and everything works.

    I've been testing with Windows 10 1511. My answer above reproduces the issue on every Windows 10 machine I've connected to using msra /offerra computername. No matter what application I right click and run as administrator I am unable to use my mouse within the administratively launched application. Clean boot is being used and Remote Desktop Connection doesn't display the issue only Microsoft Remote Assistance (msra /offerra). 

    Thank you for your help! Please let me know what additional information I can provide.


    Monday, December 28, 2015 4:20 PM
  • I am experiencing the same issue.  There is also another user at spiceworks experiencing the same issue:  https://community.spiceworks.com/topic/1350337-windows-remote-assistance-uac-prompts-and-windows-10

    In group policy we have these settings:

    Allow UIAccess applications to prompt for elevation without using the secure desktop = Enabled

    User Account Control: Switch to the secure desktop when prompting for elevation = Disabled

    This worked great for assisting Windows 7 end users with remote assistance.  Now if I assist a Windows 10 end user, I can take control and interact with everything, but once I do anything elevated (run as administrator), I am unable to interact with any of those newly launched applications using a mouse.  I can move the mouse back to non elevated applications, but in the elevated application, mouse clicks don't register.  The strange thing is the keyboard is fully functional.  Also, the end user who I am assisting, can fully interact with the same window using the mouse or keyboard. 

    This leaves remote assistance (msra) a broken tool.

    Friday, January 8, 2016 3:25 PM
  • Glad to hear it's not an isolated event. Does this mean we will have to wait for a fix from Microsoft? Is there anything else we can do other than wait for a fix?
    Monday, January 25, 2016 3:07 PM
  • I just built two clean Windows 10 Build 1511 PC's.  I put them in an isolated workgroup so no group policies would apply.  I turned off the firewall and edited the local group policy to allow remote assistance to work and added the appropriate accounts.  I still experience the same issue with the mouse not working in an elevated window.  This rules out anything in our domain.  The only time I can get the mouse to work is when both PC's are logged on as administrators.  Obviously this won't happen in a production environment.  Not sure where else to go from here.   
    Tuesday, January 26, 2016 3:59 PM
  • I just built two clean Windows 10 Build 1511 PC's.  I put them in an isolated workgroup so no group policies would apply.  I turned off the firewall and edited the local group policy to allow remote assistance to work and added the appropriate accounts.  I still experience the same issue with the mouse not working in an elevated window.  This rules out anything in our domain.  The only time I can get the mouse to work is when both PC's are logged on as administrators.  Obviously this won't happen in a production environment.  Not sure where else to go from here.   
    You're awesome that's excellent troubleshooting and rules out a lot. Not sure what else can be done. Seems like it's going to have to be resolved by an update of some kind. Is there any way to ensure this is known so a fix is on the way? Something tells me the feedback app isn't the best way to expedite a fix.
    Tuesday, January 26, 2016 4:18 PM
  • It looks like we are in the same boat. Seems weird that there is hardly any talk on this. Are we the only ones that use remote assistance?  I think the feedback app just sends information to a black hole and I couldn't imagine anything useful coming out of it.  At this point I'm honestly not sure what to do.  Perhaps Deason Wu or one of the other moderators can help?  I think we summed up the problem with specific details through the post so it should be easy enough for anyone to reproduce.
    Tuesday, January 26, 2016 9:41 PM
  • It looks like we are in the same boat. Seems weird that there is hardly any talk on this. Are we the only ones that use remote assistance?  I think the feedback app just sends information to a black hole and I couldn't imagine anything useful coming out of it.  At this point I'm honestly not sure what to do.  Perhaps Deason Wu or one of the other moderators can help?  I think we summed up the problem with specific details through the post so it should be easy enough for anyone to reproduce.
    Ditto. I thought technet would be the place to go if anywhere. There can't be these few using remote assistance for Windows 10 machines. Hopefully a moderator is able to assist.
    Thursday, January 28, 2016 4:49 PM
  • I'm having this trouble too - elevated control does not work with mouse control
    Wednesday, February 3, 2016 8:05 PM
  • Same issue here, 2500 endpoints, planning on upgrading but this bug would make for a poor experience for our HD. We try to stick to the tools provided insteadof buying more tools and agents to layer ontop of the OS.

    Please someone fix this sooner than later.

    Wednesday, February 3, 2016 8:53 PM
  • On one hand, I'm glad it's not just me. On the other... sheesh, what a mess.

    I am having the same issue - mouse doesn't work in an elevated window and caps are tricky.

    Wednesday, February 3, 2016 10:44 PM
  • On one hand, I'm glad it's not just me. On the other... sheesh, what a mess.

    I am having the same issue - mouse doesn't work in an elevated window and caps are tricky.

    We've got all of the same issues.   The caps issue seems to be something strange along the lines of the right shift won't work but the left one does.  I never had this issue because I always use my left shift.  A colleague kept calling me over saying he couldn't authenticate successfully to an elevation prompt over the course of several days on different Win 10 machines.  It would say his username or password was incorrect.  I'd type in my credentials and it worked fine (Well, with the aforementioned cursor issue still in play).  Eventually he figured out that he was using right shift and I always used left.
    • Edited by JeffZ6 Thursday, February 4, 2016 2:02 AM
    Thursday, February 4, 2016 1:34 AM
  • It looks like we are in the same boat. Seems weird that there is hardly any talk on this. Are we the only ones that use remote assistance?  I think the feedback app just sends information to a black hole and I couldn't imagine anything useful coming out of it.  At this point I'm honestly not sure what to do.  Perhaps Deason Wu or one of the other moderators can help?  I think we summed up the problem with specific details through the post so it should be easy enough for anyone to reproduce.

    Probably because very few use MSRA/Windows Remote Assistance and even fewer use it with UAC left on (With the appropriate GPO/Registry changes to make it usable via MSRA).  Everyone I've ever talked to in the IT field in real life didn't even know this existed.  It's great if you're not having to traverse NAT to get to your users though.  Much faster and less failure prone to grab their machine name or IP address from inventory and offer them assistance vs. having to have the user click on things and give you numbers or type in numbers that you give them for most fancier remote assistance systems.  The LogMeIns, GoToAssist, etc. all traverse NAT better though so tend to be better for supporting road warriors and what not.

    Thursday, February 4, 2016 1:42 AM
  • I agree that other tools are better for road warriors since the end user only needs Internet connectivity.  Internally, however, MSRA is so easy to use and worked great up until now. I don't need to have the end user open a browser or install any plugins, etc.  Not to mention that it's built in so there's no additional cost involved.  I simply send them an invite and it pops up on their screen and they accept.  Nothing more to be done.  I really hope Microsoft fixes it soon.
    Thursday, February 4, 2016 2:57 PM
  • Still no word on this... Anyone can message Gabe on twitter and point him to this thread?
    Tuesday, February 9, 2016 3:48 PM
  • Still no word on this... Anyone can message Gabe on twitter and point him to this thread?
    Who's Gabe? I don't think so but if he's able to get this moving I'll sign up for twitter to point him over here. Everyone's "yeah me too" comments are great. Hope to get a solution for this soon.
    Tuesday, February 9, 2016 4:02 PM
  • All the mentioned problem can be reproducable. It does not seem like a security issue but window focusing problem. Right shift does not work at all. Mouse click in elevated windows does not work in the cases of 90%. However if you avoid clicking anywhere after that the elevated window appeared you will be able to switch to "Yes" button using keyboard. Please confirm if the mentioned workaround is applicable.

    Wednesday, February 10, 2016 11:56 AM
  • All the mentioned problem can be reproducable. It does not seem like a security issue but window focusing problem. Right shift does not work at all. Mouse click in elevated windows does not work in the cases of 90%. However if you avoid clicking anywhere after that the elevated window appeared you will be able to switch to "Yes" button using keyboard. Please confirm if the mentioned workaround is applicable.


    Keyboard entry and navigation works fine, its mouse clicks that don't... annoying to say the least.
    Thursday, February 18, 2016 12:26 AM
  • Still no word on this... Anyone can message Gabe on twitter and point him to this thread?

    Who's Gabe? I don't think so but if he's able to get this moving I'll sign up for twitter to point him over here. Everyone's "yeah me too" comments are great. Hope to get a solution for this soon.

    Gabe Aul... Hes the guy that leads the insider program....

    https://twitter.com/GabeAul

    Thursday, February 18, 2016 12:27 AM
  • Sent him one. Not sure what the chances are he's going to respond to a tweet to check out a technet, but if it leads to a fix I'm all for it. Are there any official channels for things like this?
    Friday, February 19, 2016 4:46 PM
  • I assume still no fix for this.  We just started deploying Windows 10 and I am running into this issue as well.  A little more info that we are seeing:

    I <g class="gr_ gr_8 gr-alert gr_spell undefined ContextualSpelling" data-gr-id="8" id="8">logon</g> as a domain admin (User A)to a computer, then open an MSRA session to that computer from User B.  User B then attempts to open something as admin and gets a different prompt because User A is Domain admin.  User B cannot click with the mouse on that dialog box, but can still use <g class="gr_ gr_178 gr-alert gr_gramm undefined Grammar only-ins doubleReplace replaceWithoutSep" data-gr-id="178" id="178">keyboard</g> to say Yes.  Once that is done I can use the mouse again inside the admin opened window.  So a slight difference in the way the elevated prompt appears based on user rights seems to affect it as well.

    We also use SCCM and if I use the remote connection from SCCM then I can do everything as I normally would expect, no mouse issues at all.  I remember that Windows 7 had the issue where the elevated prompt for username/password  caused the screen to go black, wonder if this is related?

    Wednesday, March 9, 2016 5:53 PM
  • Is there any other means to get the word out on this or somehow expedite a resolution?

    Glad to hear there's others with the issue. It's not very unique circumstances to reproduce the issue. Wondering if there's not more because not many have Win10 deployed using Remote Assist for support. Thank you all for your input!

    Monday, March 21, 2016 1:36 PM
  • Has anyone opened an incident with Microsoft regarding this issue?  If not I'll throw down the $499 since this is almost certainly a bug and I ultimately won't have to pay.
    Monday, March 28, 2016 7:37 PM
  • No I don't believe anyone has. Please let me know how it goes! And thank you for your help on this! I agree it is an easily reproduced bug.
    Monday, March 28, 2016 7:41 PM
  • I went ahead and threw down the $499 of my organization's money and opened a case (116032813889034) with a verbose description of the problem and included a link to this thread.  We shall see where it goes.

    FWIW I've reproduced this on a VM with no third party software installed and no domain membership or GPO settings in play.  Just a fresh copy O' Windows 10 Build 10586.164 with the latest updates installed.  Even if I check the box on the end user machine upon excepting the request to share control which allows the assister to respond to UAC prompts the elevation prompts cannot be interacted with via the mouse cursor, only the keyboard.
    Monday, March 28, 2016 9:40 PM
  • I went ahead and threw down the $499 of my organization's money and opened a case (116032813889034) with a verbose description of the problem and included a link to this thread.  We shall see where it goes.

    FWIW I've reproduced this on a VM with no third party software installed and no domain membership or GPO settings in play.  Just a fresh copy O' Windows 10 Build 10586.164 with the latest updates installed.  Even if I check the box on the end user machine upon excepting the request to share control which allows the assister to respond to UAC prompts the elevation prompts cannot be interacted with via the mouse cursor, only the keyboard.

    Glad to hear it! With everyone's input we've got a good amount of test environments all with the same issue.

    Thanks again.

    Monday, March 28, 2016 9:42 PM
  • Jeff, Thank you for doing that. 

    I have been using Unsolicited Remote Assistance for years without issue as well. One thing that I have noticed with Windows 10 is I have to turn off UAC to be able to use remote assistance. Which you may all know that this requires a REGEDIT in Windows 10 to completely shut off UAC. Now I run into the problem of not being able to use Windows Apps with UAC off. This wouldn't be so bad if UAC could easily be toggled on/off without a reboot but.... 

    Hopefully Microsoft works these bugs out soon as my company of 4000+ is beginning to look into alternatives. 

    Tuesday, March 29, 2016 11:40 AM
  • Thank you JeffZ6.  Keep us updated.
    Thursday, March 31, 2016 4:59 PM
  • Any progress with MS Jeff? I think we're all looking forward to some/any progress on this one.

    Thanks again!!

    Monday, April 11, 2016 8:50 PM
  • I've also logged this as an advisory with Microsoft, 116041313956618. Will update when I hear back from them.
    Wednesday, April 13, 2016 1:05 PM
  • No apparent progress from my end yet but I've done 3 LogMeIn sessions with the engineer and sent them steps recorder recordings of both test VMs with the problem demonstrated.
    Wednesday, April 13, 2016 1:08 PM
  • Same issue here, this is very annoying

    Cheers

    Wednesday, April 13, 2016 3:51 PM
  • We also have the same issue and also logged a call with MS. The response was that this is a known issue and they are working on a fix for it. Unfortunately there's no ETA on when the fix will be available. 

    Niels

    Monday, April 18, 2016 2:14 PM
  • We also have the same issue and also logged a call with MS. The response was that this is a known issue and they are working on a fix for it. Unfortunately there's no ETA on when the fix will be available. 

    Niels

    Niels,

    Thank you for your input and following up with MS. Glad to hear a fix is at least in the works and it's not isolated. Please keep us updated on any new developments!

    Monday, April 18, 2016 2:23 PM
  • We have the same issue when offering assistance from Windows 7 -> Windows 10. Doesn't matter if you run MSRA as local admin. Right shift key doesn't work in the remote assistance window. Also you can't click on any windows opened via UAC, but the user you are helping can click. My keyboard does seem to work in windows opened via UAC, but have to ask user to click on things for me.
    Tuesday, April 19, 2016 8:39 PM
  • latest I have is that it will hopefully fixed in the Windows 10 (Anniversary Update).
    Thursday, April 21, 2016 1:28 PM
  • latest I have is that it will hopefully fixed in the Windows 10 (Anniversary Update).

    That was what the MS tech said? I was hoping that too...and that they'd have a little more substantial response than that haha. Did they leave it at that or are they continuing to investigate?

    Thanks again!

    Thursday, April 21, 2016 3:20 PM
  • yes, that's what the MS tech told me.  They were already aware of this bug, and have a few open calls for it by the sounds of it.  they are continuing to investigate.  I've offered to test any hot-fixes when they have them.  
    Monday, April 25, 2016 11:43 AM
  • Hello Guy's

    just i case MS bothers reading this thread:

    Same Problem here, blocking our Windows 10 Rollout.

    regards

    Stefan

    Friday, April 29, 2016 11:29 AM
  • Just discovered this problem today and found this thread, I have the same exact issues as you. Keyboard works fine, I can tab around any windows opened via UAC but no mouse click. We just rolled out our first Windows 10 machines which happen to be Surface Pros and this is killing me. Hoping this thread comes up with a solution, I'll keep testing this week and see what I can find.
    Tuesday, May 17, 2016 7:51 PM
  • Yes!  For me, I see this for example when doing something with another user in "User accounts" The user I am helping is signed in and he/she is an Administrator. My user has ticked the checkbox to allow me to respond UAC prompts.  So if I then attempt to delete a past user, for example, it requires permission and I can neither click into the box to type a password into the box nor click a different credential. I have to have someone standing by wasting their time in case I need them to click something ???? Not good.

    I did not try keyboard combinations (tab and arrows?) to get into the password field. I was unaware that keyboard may work until reading this thread.

    Wednesday, May 18, 2016 7:04 PM
  • Keyboard works fine, I can tab around any windows opened via UAC but no mouse click.

    That is summary description of how Mouse Without Borders is letting me use my mouse and keyboard on another machine.  I was assuming that that is the way it was designed.  Otherwise I hope you are right.   <eg>

    However, MWB provides alternate buttons and keyboard (in a Touch UI) so I can work around most quirks such as this with them.  One example would be that sometimes the real keyboard's Shift works for selecting text and sometimes it doesn't.  In those problem cases I need to use Show Keyboard (button), click a Shift, then move the pointer and then use the Left Click button in the UI.  But in some cases I need to start the remote machine's OSK and do keyboard shortcuts in the remote machine that way.



    Robert Aldwinckle
    ---

    Thursday, May 19, 2016 1:15 PM
  • Goodness, I am just running into this this morning to much dismay. I have used Remote Assistance for years throughout different organizations as the primary remote support tool. Our current organization has the Remote Assistance GPO enabled for a while now and has begun our upgrade to Windows 10 recently.. Good to know that this is still a heavily relied upon tool/service based on the number of responses in this thread. 

    I certainly hope there is a fix for this soon. 

    Friday, June 3, 2016 6:58 PM
  • We are having the exact same problem, having to use the keyboard for UAC prompts.
    Friday, June 10, 2016 10:30 AM
  • I just got a call and was told that there should be a patch released in about two weeks and my $499 will be refunded.
    Tuesday, June 14, 2016 4:40 PM
  • That is awesome to hear! Thank you again for submitting the bug. Technicians everywhere will be thankful to JeffZ6.
    Tuesday, June 14, 2016 8:36 PM
  • Just logged in to say "Me too"

    And thanks Jeff.

    Tuesday, June 21, 2016 8:40 AM
  • Another "me too" on the problems, and also a "thank you" Jeff for reporting the bug to MS and for keeping this thread updated on the status!
    Thursday, June 23, 2016 3:28 PM
  • I've got word that there's a patch that should fix the issue. https://support.microsoft.com/en-us/kb/3164028 should fix the issues. I'll be testing it the coming days but if someone has some news before my findings, please let us know.

    Niels

    • Proposed as answer by Nielsjuh Tuesday, July 5, 2016 11:52 AM
    • Unproposed as answer by darkknight2k3 Wednesday, July 6, 2016 5:04 PM
    Wednesday, June 29, 2016 10:48 AM
  • Hi Niels,

    Thanks for the update. Looking at the description of kb3164028 doesn't seem to describe a resolution to the issue described in this thread. Or does it when describing the threat of elevation of privileges?

    It looks like the patched linked in the KB article are also delivered in Windows Update. Since the article is from 6/14/16,  we should have received the update already, but I do not see it in my installed updates.

    Thursday, June 30, 2016 3:25 AM
  • Our first tests are successful, although I haven't tested it myself but my colleagues assure me it's fixed.

    Niels

    Tuesday, July 5, 2016 11:52 AM
  • Hi Niels,

    Could you please provide us the link for the update because we don't find the KB3164028 ? We only find the KB3163018 (included in KB3164028) that does not solve the problem.

    Thanks in advance

    Jérôme

    Wednesday, July 6, 2016 2:58 PM
  • Hi,

    we have the same issue here and the patch did not help at all.

    I've installed KB3163018 and KB3170410. I also can't find KB3164028.

    Best regards,

    Bernd

    Friday, July 8, 2016 12:44 PM
  • You can't find KB3164028 as a stand-alone package for Windows 10.
    It's integrated in the June 2016 Cumulative Update (KB3163018).

    If you install the CU, KB3164028 is installed.

    Gerald

    Friday, July 8, 2016 2:57 PM
  • I found none of the recently mentioned hot fixes had any effect on this issue.  I'm working on nailing it down but it seems one of the updates released yesterday may have resolved the issue.  I was remote assisting a Win 10 user and not even thinking about it as everything was working as expected with elevated applications.  When I noticed that I had been clicking around in UAC prompts and elevated applications without issue I had to go back and make sure I wasn't crazy and it was indeed Win 10.

    *Edited to remove some theories that were disproven

    It looks like KB3172985 is the winner.  It replaces MSRA.exe along with 17,200 other system files.

    I'm still messing with KB3172985 some though.  It seems to install fine on build 10240 and resolve this issue but it claims to not be applicable for build 10586.

    It's worth noting that the working machines don't seem to have KB3163018, KB3164028 or KB3170410 installed.


    • Edited by JeffZ6 Wednesday, July 13, 2016 9:32 PM *Edited to remove some theories that were disproven
    Wednesday, July 13, 2016 8:38 PM
  • JeffZ6, thanks for testing.  I am not having any luck on version 1511, build 10586.494.  I confirmed that all the latest updates are successfully installed including KB3172985 and KB3173428 from July 12.  I still have no mouse control when I get a UAC prompt and have to tab over to yes.  After that the mouse doesn't work in the elevated app.  My msra.exe doesn't appear to be updated as it shows a version number of 10.0.10586.0 from 10/30/2015 3:19 AM.

    Testing example: I remoted from a fully patched Windows 10 to another fully patched Windows 10 PC and went to Windows Firewall and clicked on Advanced settings.  I then entered in the admin credentials in the UAC prompt but could not click on Yes.  I had to tab twice with the keyboard and then was able to use the spacebar to click yes.  After that, I couldn't use the mouse in the firewall screen at all.  I did the same test from a fully patched Windows 7 PC to a fully patched Windows 10 PC with the same negative results.  I checked a few other apps and the same holds true for any elevated app it seems.

    I really hope this gets fixed with the Anniversary Update.

    Thursday, July 14, 2016 5:11 PM
  • We're seeing the same symptoms at my company as well.  The Right shift key does work in UAC Prompts and mouse clicks are not working either.
    Thursday, July 14, 2016 5:17 PM
  • I'll add myself as a me too

    Richard P

    Sunday, August 7, 2016 11:59 PM
  • Hello Guy's,

    it seems the anniversary Update resolved the issue.

    Can Anyone confirm?

    regards

    Stefan

    Monday, August 8, 2016 7:02 AM
  • +1 to this. 

    I've been having this issue for months now and would like to know if that update fixed the issue.

    Tuesday, August 9, 2016 5:32 PM
  • I've installed the "anniversary update" (1607) on a few computers and I can confirm that it does resolve this issue.  In fact, it changes the appearance of UAC prompts completely. Unfortunately it won't be available via WSUS for a few more days.
    Tuesday, August 9, 2016 5:37 PM
  • Solved !!!

    "Edit Dcom"

    Open DCOM = dcomcnfg

    Service COM - My Computer -  CONFIG DCOM - Search RASERVER

    Open Propreties and Security.

    Set permition "administratores or Ad group" TAB. 

    Try Again..

    Att,


    Luiz Henrique Lima Campos
    Microsoft MVP,MCT,MCC,MCDST,MCSA,MCSA+M,MCTS e MCITP
    Moderador no Microsoft Community e TechNet Forums e Membro do TechNet Wiki Community Council
    Visite o meu blog: http://luizhenriquelima.wordpress.com
    Me siga no twitter: @luizlima
    **Ajude a melhorar o sistema de busca do fórum.Marque a(s) resposta(s) que foram úteis**

    Monday, August 15, 2016 6:30 PM
  • Solved !!!

    "Edit Dcom"

    Open DCOM = dcomcnfg

    Service COM - My Computer -  CONFIG DCOM - Search RASERVER

    Open Propreties and Security.

    Set permition "administratores or Ad group" TAB. 

    Try Again..

    Att,


    Luiz Henrique Lima Campos
    Microsoft MVP,MCT,MCC,MCDST,MCSA,MCSA+M,MCTS e MCITP
    Moderador no Microsoft Community e TechNet Forums e Membro do TechNet Wiki Community Council
    Visite o meu blog: http://luizhenriquelima.wordpress.com
    Me siga no twitter: @luizlima
    **Ajude a melhorar o sistema de busca do fórum.Marque a(s) resposta(s) que foram úteis**

    Monday, August 15, 2016 6:31 PM
  • Solved !!!

    "Edit Dcom"

    Open DCOM = dcomcnfg

    Service COM - My Computer -  CONFIG DCOM - Search RASERVER

    Open Propreties and Security.

    Set permition "administratores or Ad group" TAB. 

    Try Again..

    Att,


    Luiz Henrique Lima Campos
    Microsoft MVP,MCT,MCC,MCDST,MCSA,MCSA+M,MCTS e MCITP
    Moderador no Microsoft Community e TechNet Forums e Membro do TechNet Wiki Community Council
    Visite o meu blog: http://luizhenriquelima.wordpress.com
    Me siga no twitter: @luizlima
    **Ajude a melhorar o sistema de busca do fórum.Marque a(s) resposta(s) que foram úteis**

    Monday, August 15, 2016 6:32 PM
  • Hi Luiz, Is that on the 'admin' machine or the end user machine?

    Also, is it possible to roll that setting out as a GPO?


    Richard P

    Monday, August 15, 2016 9:54 PM
  • this is for the end user machine.

    Yes its possible for GPO in register.

    Import register for you local machine for AD.

    1° set you ad group in you machine.

    2° import the register for you local machine for you AD, create de UPDATE Register in AD.

    exemple:


    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{F8FD03A6-DDD9-4C1B-84EE-58159476A0D7}]
    @="RAServer"
    "PreferredServerBitness"=dword:00000003
    "RunAs"="Interactive User"
    "AccessPermission"=hex:01,00,04,80,78,00,00,00,88,00,00,00,00,00,00,00,14,00,\
      00,00,02,00,64,00,03,00,00,00,00,00,14,00,03,00,00,00,01,01,00,00,00,00,00,\
      05,0a,00,00,00,00,00,24,00,07,00,00,00,01,05,00,00,00,00,00,05,15,00,00,00,\
      73,02,10,5d,ae,21,ff,04,d8,7e,a7,47,00,02,00,00,00,00,24,00,07,00,00,00,01,\
      05,00,00,00,00,00,05,15,00,00,00,73,02,10,5d,ae,21,ff,04,d8,7e,a7,47,a5,54,\
      00,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,01,02,00,00,00,00,00,\
      05,20,00,00,00,20,02,00,00
    "LaunchPermission"=hex:01,00,04,80,78,00,00,00,94,00,00,00,00,00,00,00,14,00,\
      00,00,02,00,64,00,03,00,00,00,00,00,24,00,1f,00,00,00,01,05,00,00,00,00,00,\
      05,15,00,00,00,73,02,10,5d,ae,21,ff,04,d8,7e,a7,47,a5,54,00,00,00,00,24,00,\
      1f,00,00,00,01,05,00,00,00,00,00,05,15,00,00,00,73,02,10,5d,ae,21,ff,04,d8,\
      7e,a7,47,00,02,00,00,00,00,14,00,0b,00,00,00,01,01,00,00,00,00,00,05,04,00,\
      00,00,01,05,00,00,00,00,00,05,15,00,00,00,28,45,a6,d3,e7,12,d7,46,df,28,60,\
      89,e9,03,00,00,01,05,00,00,00,00,00,05,15,00,00,00,28,45,a6,d3,e7,12,d7,46,\
      df,28,60,89,e9,03,00,00



    Luiz Henrique Lima Campos
    Microsoft MVP,MCT,MCC,MCDST,MCSA,MCSA+M,MCTS e MCITP
    Moderador no Microsoft Community e TechNet Forums e Membro do TechNet Wiki Community Council
    Visite o meu blog: http://luizhenriquelima.wordpress.com
    Me siga no twitter: @luizlima
    **Ajude a melhorar o sistema de busca do fórum.Marque a(s) resposta(s) que foram úteis**


    Tuesday, August 16, 2016 12:44 AM
  • Hi everybody,

    The problem is solved if you try "Remote Assistance" to Win 10 Anniversary from Win 10 Anniversary but not to Win 10 Anniversary from Win 7 Pro : you don't have the second window to accept the control by someone else. Can someone make a test and onfirm the problem ?

    Thanks in advance.

    Jérôme.

    Thursday, September 1, 2016 2:27 PM
  • I finally got around to test the anniversary update (v1607) and here are my findings. In every case both the person offering help and the end user receiving help were logged on as non administrators.  I only tested with Enterprise versions.  No changes to DCOM or registry settings or any other modifications were used.

    v1607 to v1607: Works as it should.

    v1511 to v1607: Works as it should.

    v1607 to v1511: Same issue. No mouse control over any UAC prompts or windows.

    Win 8.1 to v1607: Works as it should.

    v1607 to Win 8.1: Has the box to allow the requestor to respond to UAC prompts which requires admin rights by the end user. I think this was always an issue and was just a bad design in 8.1. Not going to worry about it.

    Win 7 to v1607: Same problem as previous post by Jeje21. Can view the screen but when asking to take control, the second window to allow control never appears.

    v1607 to Win 7: Works as it should.

    No other versions tested. Sounds like if you are going to be deploying windows 10, make sure it's v1607 and make sure all your admins/help desk have access to a v1607 PC.

    Thanks.

    Wednesday, September 21, 2016 3:20 PM
  • v1607 to Win 8.1

    If this can be represented by W10 replying to an invitation by W8.1 RT I can confirm the original symptom description still with 14393.187.  I can see the client's screen on W10 but neither mouse nor keyboard can interact with that window.  This is rather useless because I was hoping to be able to replace MouseWithoutBorders with MSRA and then leave my keyboard and mouse permanently attached to W10 instead of the cumbersome way I have now of connecting W10 with MWB to give it not much more than typing and cursor movement and emulating anything else one way or another.

    I haven't tried looking at Luiz suggestion about using dcomcnfg yet.



    Robert Aldwinckle
    ---


    Thursday, September 22, 2016 5:49 PM
  • I'm experiencing the same issues here. We are testing out Windows 10 for enterprise deployment at the moment and yesterday I got told that remote assistance isn't working the way it used to work anymore.

    Upon requesting a remote assistance session via "msra /offerra <pcname>" the screen is shared successfully but a "request control" does not trigger a prompt asking the user to allow or deny. The button appears pressed but no prompt is displayed.

    I've tried several configurations, using Enterprise editions of Windows 7 and Windows 10, all patched to the latest patchlevel of their respective branches.

    - Windows 7 -> Windows 7: works
    - Windows 7 -> Windows 10 1511: works
    - Windows 10 1511 -> Windows 7: works
    - Windows 10 1607 -> Windows 7: works
    - Windows 10 1511 -> Windows 10 1511: works
    - Windows 10 1511 -> Windows 10 1607: works
    - Windows 10 1607 -> Windows 10 1511: works
    - Windows 7 -> Windows 10 1607: doesn't work

    Since the full Windows 10 deployment will take us a couple of years we'll be using Windows 7 machines for quite a while longer. It would be kinda bad if we couldn't offer remote assistance from Windows 7 machines to Windows 10 machines...

    The Windows firewall, and thus issues with port 139 and 3389, I've already ruled out.

    I'll be testing the dcomcnfg suggestion next.


    Update 1: I've tried the dcomcnfg suggestion and gave both the local administrators and the local remote assistance providers groups full access to everything on the RAServer entry. The problem still exists
    • Edited by Jens Ge Tuesday, September 27, 2016 9:24 AM
    Tuesday, September 27, 2016 9:05 AM
  • I opened a case with Microsoft about the "Windows 7 -> Windows 10 1607" Remote Assistance issue.

    Apparently it is a known problem and they are working on a solution, which might come in the form of a patch this month already. They are just waiting on some more feedback about their fix, it seems.

    Wednesday, October 5, 2016 8:00 AM
  • Issue still exists with 14393.321.
    Tuesday, October 18, 2016 11:01 AM
  • any news about this issue?

    Issue still exists with 14393.351.

    Wednesday, October 26, 2016 9:43 AM
  • Yeah, issue still exists in 14393.351 and no feedback from Microsoft whatsoever on the call I opened.

    However, I can confirm that it does work on the insider build 14955.1000

    Edit: Just had a call with a Microsoft Support Engineer and apparently the Windows 10 Product Group hasn't yet decided whether there will be a backport of the fix they have developed for the Redstone2 Update. So whether this will ever work in the Anniversary Edition or not has not yet been decided and it is very well possible that there won't be a fix before April 2017 when the Redstone2 Update comes out.

    The support engineer will keep me updated if there is any progress. Let's hope for the best.

    Edit2: I just filed a Business Impact report with Microsoft telling them that the bug is blocking the Windows 10 rollout in our company.
    • Edited by Jens Ge Thursday, November 3, 2016 9:45 AM
    Thursday, November 3, 2016 8:11 AM
  • I just got informed that the fix for 1607 got approved and is planned to be shipped with the december updates.

    So if everything goes as planned we should be able to provide remote assistance from a windows 7 machine to a windows 10 1607 machine soon.

    Monday, November 14, 2016 10:29 AM
  • good news!!

    Tuesday, November 15, 2016 3:30 PM
  • Any news ?
    Monday, December 5, 2016 8:37 AM
  • December patchday is the 13th. So you'll have to wait at least another week.
    Monday, December 5, 2016 9:13 AM
  • Just updated my Windows 10 test machine to 14393.576 and tried connecting to it from my Windows 7 machine using "msra /offerra <pcname>" .. but when asking to take control of keyboard and mouse Windows 10 still wouldn't display a prompt asking the user for permission.

    So either this bug is still not fixed, despite what Microsoft promised, or ... the Windows 7 machine actually needs the updates installed? Will test that next.

    Edit: OK, the Microsoft engineer informed me that on the 13.12. patchday only security fixes were released. Bug fixes and feature updates are scheduled for 20.12.
    • Edited by Jens Ge Thursday, December 15, 2016 1:38 PM
    Thursday, December 15, 2016 12:43 PM
  • Hello,

    Try to update with all Windows 10 (1607) updates today, but the problem still occurs.

    Has somebody any news ?

    Thanks

    Thursday, December 22, 2016 10:36 AM
  • Yeah, the engineer informed me that the patch was moved to 04.01.
    Tuesday, December 27, 2016 7:21 AM
  • Hi,

    The problem still occurs. I think Microsoft leads us up the garden path.

    Thanks.

    Thursday, January 5, 2017 1:18 PM
  • Hello,

    Try to update with all Windows 10 (1607) updates today, but the problem still occurs.

    Has somebody any news ?

    Thanks

    Just tried with release preview of  1607  build 14393.594. going from windows 7 to release preview build. 

    after a long pause(2.5 minutes) . offerra connected and remote control take over worked!. 

    I do not have control over the network so I cannot say what the issue was with the long pause. but it did work. 

    I had to use the IP address instead of the computer name if that helps anyone out. 

    • Proposed as answer by Kukujin Thursday, January 12, 2017 5:15 AM
    Saturday, January 7, 2017 1:16 AM
  • Update from the MS engineer:

    Apparently there was some miscommunication between the departments and the fix was released on 04.01. to Insiders. For regular users the fix is now scheduled for the January patchday on 10.01.

    Monday, January 9, 2017 8:01 AM
  • fix was released on 04.01. to Insiders.

    I thought you were giving us an April Fool's joke.


    Robert Aldwinckle
    ---

    Monday, January 9, 2017 2:15 PM
  • I can confirm that with the 14393.683 update released on 10.01.2017 Windows 10 is now asking for confirmation when a remote assistance session initiated from a Windows 7 system is asking to share the controls of mouse and keyboard.
    Wednesday, January 11, 2017 12:53 PM
  • Yesss, wonderfull, it works now.

    Thanks for the information.

    Thursday, January 12, 2017 7:54 AM
  • Hi Jens Ge,

    We are testing Win10 1607 enterprise. Its patched but MSRA from  Windows 7 -> Windows 10 1607: doesn't work.

    Does it work in your environment?

    Thanks,

    KV00

    Wednesday, September 6, 2017 2:41 AM