We are in the process of migrating to ArcGIS Server 10.5 and stuck with a strange issue:
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.
Also, here is a list of things which I did and miserably failed:
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.
Solved! Go to Solution.
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.
re: moving services, you may want to check GitHub - eea/discomap.ServiceTransferTool: Transfer tool
for some discussion. I've been successful with copying some services over, assuming all data connection names and access is the same.
Microsoft has addressed this issue:
"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."