Lesson Learned

[TracyGarrison]

Last year we upgraded our GIS servers SDE SQL Sever and ArcGIS Server etc.   We kept our old  SDE server up for a couple months during the transition So the new server had a different name.

Here is the lesson learned.  When you shut down the old server everything will seem to be fine until somebody in one of the departments decides they need to look at a MXD from a couple years ago and it had not been updated with the new connections for the new server.

The MXD hangs for ever and will not open at ALL!!!!    I figured it would open but give red exclamation marks showing the broken connections.

But they will not ever load.   Luckily still had the server and switched it on without it being connected to our SAN (no database) but plugged into the network.   The mxd's loaded and we are amble could fix the connections.  I have a couple workstations in my office I use for testing so I renamed the workstation to be the same name as the old server and changed the IP address to be the same as old server and then shut down the old server.  That works and just takes a little bit longer because of the broken connections.   For some reason the problem is not being able to find the server name or IP address..

So, if you are getting ready to replace servers, keep this in mind!!!

[ChrisMathers]

We ran into that December 2013 when we did the same thing, one dying server that hosted both our only DB and AGS Site became three servers with replicated DBs and a two machine AGS site. I wrote a python script that used os.walk to find .mxd and .lyr files then used arcpy.mapping on them to swap them over to the new workspace. Doesnt take long to run across a whole machine but you have to run it on every computer that might have the old files.

[TracyGarrison]

Yes, I too wrote some arcpy to remap the files in my area.  But there is too many users now to go around and have everyone go through the process.   So I will just keep my test workstation named like my old server for a few years. 

I wonder if they will fix this problem.  You would think it would just act like a broken connection and time out and give the red exclamation marks.

Thanks,  Glad to know I am not alone.

[ChrisMathers]

I wonder if an IT department could run this on all GIS users computers as a scheduled task. I think next time we have to replace a server we will give it a setup name and on a weekend do a rename and change the DNS to point to the new one. It'll save on headache.

[AsrujitSengupta]

These two steps should help in these scenarios:

1. Put entry of the old machine name in 'Client's HOST file'

2. Then open map documents to check for the broken links.

1. Add following entry in the client's host file in system32\drivers\etc folder:

'127.0.0.1    old_Arcsde_server_name'

This will point the name-to-IP resolution back to your machine causing the connection attempt to fail immediately instead of timing out for each layer.

2. Then resource the MXD again:

a) Access the map document from ArcCatalog - Right click - Set datasource(s)... - Select All -Replace All

b) Right click on the new connection - Properties - Copy the path that you see in front of Name

c) Put the above path in front of Replace with:

   Replace with: new connection file path

[TracyGarrison]

Yes adding to the host file does work and I used it at first as a test but it requires visiting every ArcGIS workstation and with over 50 installs that is not feasible.

that modification requires administration permissions and our users do not have that kind of permission to make the changes themselves.

So I have a workstation using the old server name in my office (which is not a problem) and is a solution for entities with a lot of ArcGIS users and an enterprise database.

All our users know how to fix broken datasources as long as MXD will load so that is not a problem.