All I know is Revit didn't make it a local - it "just" got opened (and saved) like one.

I imagine you're going to want some kind of script to reach in and do this repathing automatically - that would be nice. I presently have had our IT guy working with the API to develop a script for RS backups - so I will ask he look at something like this as well, but I'm afraid it won't be ready too help you now.

We have done this occasionally in the past when upgrading to new servers. Believe it or not, we just named the new server the same name as the old one, placed it in the same domain with the same ip address, copied the files over, (including linked files) took the old server offline, and fired up the new server. We crossed our fingers, and------ it worked!

If you can name the server exactly the same, this works. If not, you would likely need to open each "central" file using the "Detach from Central" option and simply save over the old file. Make certain everyone has sync'd and closed all their local copies - then make new local copies from the "new" central file and you are off and running. We had to do this once and it worked fine once everyone knew what the deal was.

This is exactly the reason for DFS. Revit sees a DFS share path that never changes, while server room infrastructure like servers, storage arrays and the like can change as needed. Actually very slick when combined with network places and user customized network favorites.

And it is worth noting the technical difference between a central and a local is simply one of location. When you create a central file, revit logs the location in the file. A "local" file is simply that file in a different location. Revit opens the file, reads the central location, compares it to the current file location, and treats it appropriately. So, renaming a server, or a folder, will "Make all the central files local files with lost centrals" in a sense. So will simply moving the central file. Nothing changes in the file itself, just how Revit makes use of the file changes.

Gordon

Jason-

If you cant name the servers the exact same thing, you are basically stuck doing it the way you are thinking: One at a time. HOWEVER, that handy batch file that can run on all of your content to upgrade RFA's? You can use it for RVT's as well. Certainly it would break on files that ran in to unexpected dialogues (specify worksets, Manage Links, Coordination Review), but you could add in the journal text to ignore some of the warnings, and then hope for the best. If it fails on 1 out of 5, youre still ahead of the game.

Were about to start down the same road, since we are (intentionally) restructuring servers and they will not end up named the same thing (again, intentionally).

Repathing is one thing, as much pain as it is.
But all of the Links have to be repathed INSIDE every project as well. And, you can't Reload From unless the file already exists. So you HAVE to have both servers up parallel for at least the transition period.

I filed a Support Request about this a while ago, and the only "answer" was to point me to a couple of AUGI posts.

You can 'reload from' as long as the NEW server has the links on it. Its not quite as bad either, since once you 'reload from' the first file, the other links in the same file remember the directory you just use, so its as quick as reload from > enter.

Still not an ideal workflow (and you cant really ghetto journal script that since all the link names are different.... Youd probably have to use the real API to do it automatically, if its even possible), but it works when you have to.