ArcGIS Server 10.5 is installed in Windows Server 2012 R2 (virtual machine). Whenever, I tries to remote login to that machine using Remote Desktop- it takes at least 20 minutes to login. But, if I remotely stop the ArcGIS Server Service or change the Log on as a different user/refresh the service, it log in to Remote Desktop right away. Have anybody seen this behavior?
I am also facing supplementary problems which I don't want to list as this is the critical one to be solved first.
1. Log On as ArcGIS Server service using a domain account (which works fine in our ArcGIS Server 10.3 production environment) has slow login to Remote Server (using Remote Desktop). When remotely changed the Log on as ArcGIS Server service to local account(and refreshed), Remote Desktop immediately logs in to the Remote Server. So, I though it has something to do with domain account.
2. Log On as ArcGIS Server service using a previous Local account again has slow login to Remote Server (using Remote Desktop). When remotely changed the Log on as ArcGIS Server service to local system account or domain account(and refreshed), Remote Desktop immediately logs in to the Remote Server. Now, it's clear that it has nothing to do with domain account or local account or local system account - but with ArcGIS Server 10.5.
You may want to review this tech article: Problem: Remote desktop logins are very slow when running ArcGIS Server with Windows Server 2012 and 2012 R2.
Thank you George. Yes, that was exactly what's happening.
Unfortunately, it looks like a MS issue and there is not anything that we can do at this point.
Now, I have to see whether we can go to WS2016. Is there a way I can move over the config files for ArcGIS Server so that I don't have to republish map services after reinstall? Any thoughts?
I am not sure about the last question. It may be best to open a Technical Support case or create a new question on GeoNet regarding the migrations.
for some discussion. I've been successful with copying some services over, assuming all data connection names and access is the same.
Thanks Rebecca, I'll try it out.
Yes, this is a known issue in Group Policy that Microsoft has addressed in Windows Server 2016.
"Addressed issue to prevent user logon delays when processes that have registered top-level windows fail to respond to BroadcastSystemMessages sent by the Group Policy Preference client-side extensions."