N
NB1986
Good afternoon. The organization I work for has a Windows domain with about 2,000 workstations and a similar number of employees. Most desktops run Windows 10 Pro Version 1909, Build 18363.657. The machines access the Internet through an automatic proxy configuration address (.pac file).
Years ago, we implemented a solution to facilitate IT support, using Microsoft Remote Assistance (msra.exe), which works as follows:
1) A GPO creates a shortcut on the desktop of each user's profile when he logs in;
2) This shortcut executes the following command:
C:\Windows\System32\msra.exe /saveasfile "\server\path\%USERNAME%.msrcIncident" "genericpassword"
3) When people need help, the IT professional asks them to double-click this shortcut. This creates an msrcincident file in the server folder, named with the user's login. The IT professional goes to the folder, double-clicks the file, types the password and controls the computer after the employee authorizes.
This worked well for quite a while. After the support guy opened the msrcIncident and typed the password, the employee immediately received the dialog boxes asking if he wanted to share the screen and the control of his computer, and soon afterwards the professional could already operate the machine. Quick and easy. But after we migrated from Windows 7/8 to 10, the following happened (and still happens): after the IT professional opens msrcIncident and types the password, it takes exactly 45 seconds for the dialog boxes to appear on the employee's computer, which obviously creates an irritating and embarrassing situation for workers and a significant amount of lost time for the support team.
Searching the Internet, I understood that those 45 seconds are a timeout, which occurs because msra.exe is unable to verify some certificates on the Internet. A user in the same situation posted the problem and a solution he reached at the link below, but I honestly don't know how to implement what he did, more specifically, find out which certificates and lists that msra.exe looks for and download them to a local server:
Solved: Remote Assistance (msra.exe) will need 45 seconds to connect from Win10 1809 or 1803 | Experts Exchange
Finally, I did the following test: I took two computers and reproduced the problem I am describing in this topic. Meanwhile, a colleague watched the proxy server to see whether the machines tried to access the internet. Then, the following appeared:
1) On the machine giving support (10.26.10.34):
10.26.10.34 TCP_TUNNEL/200 4046 CONNECT settings-win.data.microsoft.com:443 - HIER_DIRECT/40.74.108.123
2) On the machine receiving support (10.26.10.112):
1602002859.246 123838 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002861.004 125454 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002862.440 122370 10.26.10.112 TCP_TUNNEL/200 7249 CONNECT c-ring.msedge.net:443 - HIER_DIRECT/13.107.4.254 - 1602002862.527 126700 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002863.040 127209 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002865.571 128542 10.26.10.112 TCP_TUNNEL/200 9978 CONNECT fp.msedge.net:443 - HIER_DIRECT/204.79.197.222 - 1602002867.622 128012 10.26.10.112 TCP_TUNNEL/200 7425 CONNECT s-ring.msedge.net:443 - HIER_DIRECT/13.107.3.254 - 1602002868.349 132939 10.26.10.112 TCP_TUNNEL/200 6196 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002921.080 180846 10.26.10.112 TCP_TUNNEL/200 9913 CONNECT fp-vp-nocache.azureedge.net:443 - HIER_DIRECT/192.16.48.200 -
Sorry for the long post. Thank you very much for your attention and help.
Continue reading...
Years ago, we implemented a solution to facilitate IT support, using Microsoft Remote Assistance (msra.exe), which works as follows:
1) A GPO creates a shortcut on the desktop of each user's profile when he logs in;
2) This shortcut executes the following command:
C:\Windows\System32\msra.exe /saveasfile "\server\path\%USERNAME%.msrcIncident" "genericpassword"
3) When people need help, the IT professional asks them to double-click this shortcut. This creates an msrcincident file in the server folder, named with the user's login. The IT professional goes to the folder, double-clicks the file, types the password and controls the computer after the employee authorizes.
This worked well for quite a while. After the support guy opened the msrcIncident and typed the password, the employee immediately received the dialog boxes asking if he wanted to share the screen and the control of his computer, and soon afterwards the professional could already operate the machine. Quick and easy. But after we migrated from Windows 7/8 to 10, the following happened (and still happens): after the IT professional opens msrcIncident and types the password, it takes exactly 45 seconds for the dialog boxes to appear on the employee's computer, which obviously creates an irritating and embarrassing situation for workers and a significant amount of lost time for the support team.
Searching the Internet, I understood that those 45 seconds are a timeout, which occurs because msra.exe is unable to verify some certificates on the Internet. A user in the same situation posted the problem and a solution he reached at the link below, but I honestly don't know how to implement what he did, more specifically, find out which certificates and lists that msra.exe looks for and download them to a local server:
Solved: Remote Assistance (msra.exe) will need 45 seconds to connect from Win10 1809 or 1803 | Experts Exchange
Finally, I did the following test: I took two computers and reproduced the problem I am describing in this topic. Meanwhile, a colleague watched the proxy server to see whether the machines tried to access the internet. Then, the following appeared:
1) On the machine giving support (10.26.10.34):
10.26.10.34 TCP_TUNNEL/200 4046 CONNECT settings-win.data.microsoft.com:443 - HIER_DIRECT/40.74.108.123
2) On the machine receiving support (10.26.10.112):
1602002859.246 123838 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002861.004 125454 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002862.440 122370 10.26.10.112 TCP_TUNNEL/200 7249 CONNECT c-ring.msedge.net:443 - HIER_DIRECT/13.107.4.254 - 1602002862.527 126700 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002863.040 127209 10.26.10.112 TCP_TUNNEL/200 7812 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002865.571 128542 10.26.10.112 TCP_TUNNEL/200 9978 CONNECT fp.msedge.net:443 - HIER_DIRECT/204.79.197.222 - 1602002867.622 128012 10.26.10.112 TCP_TUNNEL/200 7425 CONNECT s-ring.msedge.net:443 - HIER_DIRECT/13.107.3.254 - 1602002868.349 132939 10.26.10.112 TCP_TUNNEL/200 6196 CONNECT www.bing.com:443 - HIER_DIRECT/204.79.197.200 - 1602002921.080 180846 10.26.10.112 TCP_TUNNEL/200 9913 CONNECT fp-vp-nocache.azureedge.net:443 - HIER_DIRECT/192.16.48.200 -
Sorry for the long post. Thank you very much for your attention and help.
Continue reading...