Migrate to a new Server

[LindseyStone]

I'm currently running ArcGIS Server, Portal, and Web Adapter v. 10.3.1 on a Windows Server 2008 and was wanting to upgrade to v. 10.6.  I asked IT to duplicate my server (ran on vmWare) for a fail over backup in case something goes wrong with the upgrade.  Instead IT created a brand new server with Windows Server 2012 R2 and told me to use that one going forward.  I asked if we could upgrade the Server 2008 to 2012 instead of starting completely over and they gave me a bunch of reasons/excuses that they couldn't.  So I need advice on how to get my ArcGIS Server & Portal over to the new Server 2012 without having to republished all my services in Server and re-set up all maps in Portal.  

Can I install 10.3.1 on the new Server 2012 and backup all my Server and Portal settings from my 2008 server and restore it on the 2012 server?  I'm finding a lot of documentation on v 10.6 with this but not much for v 10.3.1.  I have tons of Services running in server and I really don't want to open each mxd and re-publish each service.  On top of that I have several maps running in Portal.  Some are web apps made and customized thru portal and some are web maps being used in Web App Builder Developer.  Just the thought of having to do redo these from scratch is daunting.   I'm fine manually copying over my data and mxd's and I'm wanting the file structure exactly the same, I just need to get all the customized items onto this new server.  I figured once I get 10.3.1 installed and correctly setup on the 2012 Server than I can just upgrade that up to ArcGIS 10.6.

Thanks for any help!

[JonathanQuinn]

Are you open to running an in-place upgrade to at least 10.4 on the machine? If so, you can upgrade to 10.4, create a backup using the WebGIS DR tool, spin up your new machine, use the etc\hosts file to "trick" the machine into making sure the hostnames and URLs match, and then restore the backup to the site. Somewhat convoluted, but it should work.

You can also look into joining machines, described in this blog. Install the software on the new machine, join to your existing site on the older hardware, and remove the old machines.

[LindseyStone]

Thanks for the info Jonathon.  So when you say trick it with the host file, am I adding the current machine name and IP into the host file.

Also,  the blog seems real interesting but it is fairly new do you think it would work on my older 10.3.1 version.

[JonathanQuinn]

If you can't or aren't interested in upgrading to 10.4, then you don't have to worry about the hosts file trick as that's specific to using the DR tool for this migration.

Multi-machine Server sites, HA data stores and HA portals are supported at 10.3.1, so the blog should work for that version as well.

[Anonymous User]

So depending on how complex your site is, I have several re-deployment scripts I have for that precise scenario that, after installing AGS (and Portal from how it sounds), setting up the Web Adaptors, and federating, will:

1. Create necessary folders in AGS;

2. Define all necessary AGS directories;

3. Register necessary data stores;

4. Republish all content programmatically into their appropriate folders;

5. Share services appropriately;

6. Report any issues / complications

If you change the DNS record for your new server to match the alias of the old machine right before the setup (done after hours on a Friday to give you time just in case) and execute the scripts your site will be populated with all the necessary services. You then can use the script provided by esri for moving content between portals found here. 

Let me know if you're using a single-machine deployment, how many services you're working with and if your environment is federated, http | http & https | https only and if the two machines can currently ping one-another.

[LindseyStone]

I believe my set up is fairly simple.  I have one server running both ArcGIS Server and Portal on a SMB 2008 server.  I have a second server that is running Windows 10 that has my cache in  a shared folder.  In the Directories of the Server Manger I have the Cache Directory pointing to this shared folder on the Windows 10 machine.  The rest of the directories are all pointing to local folders.  No data stores only registered folders all sitting on the local machine.

As for services I have around 45 services in Server.  In Portal I have 30  items that include Web Maps, Web Mapping Applications, Applications, Map Image Layer, and geoprocessioning Service.

My Server is NOT federated, runs http & https and the current machine and the new machine can ping each other.

[Anonymous User]

Radical, so that makes some portions of the script not ideal so we'll have to 'brute force' some elements, but that shouldn't take too long. 

The first step is to gather all of your .mxds that were used to create your services and put them in a single folder so the publishing script can iterate over them and publish all of them at once (sequentially, but you click 'run' and it takes care of it). 

The best way to ensure you're getting the proper .mxds is to go to your AGS' system\input folder. The default location is on at C:\arcgisserver\directories\arcgissystem\arcgisinput. Within that folder, you'll see a bunch of folders. These folders correspond to your AGS folders used for organizing content and the service folders for items published to your site root.

Notice that some folders end in the prefix .MapServer. Each folder that ends with .MapServer corresponds to a Map Service you published. An example would be: C:\arcgisserver\directories\arcgissystem\arcgisinput\MainMap\CATS.MapServer.

Within this folder there's an extracted folder and within that folder there's a v101 folder (C:\\arcgisserver\directories\arcgissystem\arcgisinput\MainMap\CATS.MapServer\extracted\v101). There you'll find the MXD that was used for publishing. 

Copy the MXD into a new local folder (I created one on my desktop called 'AllMXDs' (C:\Users\MyUserName\Desktop\AllMXDs). Do this for all your map services.

Once you've completed that, give me a holler! Then we'll publish all the services and take care of the next step of replicating content.

[JonathanQuinn]

You shouldn't need to move the .mxd files out of the arcgisinput folder. You can recursively loop through the input folder using the os.walk function to find all MXDs. The benefit of this approach is that you can also determine if the service was previously in a folder or not based on the directory structure. You can also update the new service with the configuration of the old service based on the .json file in the same directory:

https://community.esri.com/servlet/JiveServlet/downloadBody/10220-102-2-16225/Loop_Through_InputFold... 

For a non-federated Server, this should work fine. However, you'll need to be careful using this approach with any federated server or even using Python outside of the Python API and this sample to clone items and groups. The problem is that if you were to move a serviec to a new machine by re-publishing, it'll get a new item ID. Similarly, if you create a new group or item, it'll get a new group ID and item ID. Web apps reference web maps using the item IDs so that link is broken if you recreate the webmap yourself. The sample script from the Python API doesn't clone services, so you'll need to republish them. I don't think clients reference services by the item ID, but sharing settings won't be preserved if you republish services yourself, and you'll have duplicate items in the Portal for the same item, which requires cleanup. The easiest approach, in my opinion, is the DR tool if you're at 10.4 or on or using the join site operations.