ArcGIS Enterprise 11.3 vs 11.1 Portal Web Adaptor Install Order

[DavidColey]

Hello - In prepping for the Enterprise 11.3 Portal upgrade this weekend, I just now noticed that the step for the Web Adaptor Uninstall - Re-Install has been moved from Step 3 in the upgrade documentation for 11.1:

https://enterprise.arcgis.com/en/portal/11.1/install/windows/upgrade-portal-for-arcgis.htm

3. Sign in to the machine hosting the ArcGIS Web Adaptor you're using with your portal, and uninstall ArcGIS Web Adaptor. For full instructions, see the uninstallation topic for IIS or Java (Windows). Be sure to note the name of the Web Adaptor before you uninstall it.

to Step 9 in the latest upgrade documentation for 11.3:

https://enterprise.arcgis.com/en/portal/latest/install/windows/upgrade-portal-for-arcgis.htm

9. Sign in to the machine hosting the ArcGIS Web Adaptor you're using with your portal, and uninstall ArcGIS Web Adaptor. For full instructions, see the uninstallation topic for IIS or Java (Windows). Be sure to note the name of the Web Adaptor before you uninstall it.

So in other words, we are now supposed to leave the 11.2 web adaptor version in place on my web server until AFTER we run the Portal upgrade and post-upgrade steps?

I've done this so many times since 10.6 and we have always removed the web adaptor BEFORE running the Portal Setup.exe.  Can anyone comment?

@MarceloMarques 

@A_Wyn_Jones 

@JakeSkinner 

@ScottTansley 

Thanks - 

David

Sarasota County GIS

[DavidColey]

Yes I totally agree @RyanUthoff .  My understanding since 10.6 is that we uninstall the WAs before running the setup upgrade exes so that calls to Portal (and then Server) through the web adaptor urls can't get to the machines during their upgrades.

So yes I don't understand the change, and there is no documentation on the reason.  It's just 'changed'.

I recall seeing your post at my upgrade from 11.0 to 11.1 but because I had completed the upgrade by uninstalling WA first,  (11.1 Step 3) I had no comment to make.

Yes, I do see now that this doc for 11.0:

https://support.esri.com/en-us/knowledge-base/upgrade-arcgis-enterprise-000029452

from the knowledge base reads to uninstall the WA after the portal post-upgrade has completed so no one knows what is 'correct'.  

BUT, now since both the 11.2 and 11.3 steps and the knowledge base doc say to do the WA uninstall - install after post upgrade(s), this is what I am going to do.

@dhochhal 

[DavidColey]

Ok so I completed 11.3 upgrade this Saturday.  We have a completely distributed deployment, with all of the components - Web Adaptors, Portal, Hosting Site, Relational Datastore, Tile Cache Datastore and a Federated Server Site that supports our Image Server and SDE feature access services on separate servers.

For the first time, I was able to convince our EIT security to allow the capability to suspend active virus scanning during the upgrades.  So for Portal, Server and Datastore what used to take 3 -4 hours per server, with various hanging points during both upgrade and post-upgrade, now took 15 - 30 minutes.

So for our entire enterprise, the update would take up to 18 hours.  I had the entire deploy upgraded, cleaned and tested, in 5 hours.

I can't express how thrilled I was.  Simply by suspending active virus scanning during the upgrade and post-upgrades.

I did run into one hiccup that relates to this thread.  While adopting the updated uninstall - reinstall order for web adaptor, the reinstalls went just fine for both Portals' WA and the Hosting Site WA. 

But for the Federated Site WA, the reinstall failed with a window installer message:

'Can't complete install because a folder with the same name already exists in the ....\innetpub\wwwroot...  directory.  Remove the folder or rename the install'.   Having never seen this before, I wasn't quite sure what to do. 

So I made sure that the 11.2 web adaptor was no longer registered with the 11.3 Federated Site and then I went into the wwwroot folder and physically delete the windows directory.  Then I ran the install again and it did complete.  It then took a few minutes for the IIS to recognize?  I guess?  my 'agsfed' WA name and it spun up via localhost and I was then able to configure.

Everything is up and clean so far, but am now thinking, that for my Federated Site, I may go back to removing the WA prior to running the Server upgrade exe . . .  but otherwise not real sure if there was a better way to handle this.

@MarceloMarques 

@Scott_Tansley 

[Scott_Tansley]

Hey, very very occasionally I get that WA issue on install. It appears random, and I put it down to bad luck.  As you suggested, I just clean it out of the Server/Portal Admin API, then hard delete it from IIS and the disk.  I've never had an issue with installing after those actions.  If it's working now, I see no reason to change it.  

Also agreed that AV makes a massive difference.  Well done on your upgrade.  🙂

[DavidColey]

Great thanks for the reply Scott, I just didn't know if there was a more elegant way to handle.

If occurs again in the future, I'll remove in order of Porta/Server>unregister (if still present )>remove from IIS>remove any remaining files from windows directory>install new.

Yes suspending AV was truly remarkable.  I've been asking my EIT security group to allow this for 10 - 12 years now, they finally relented . . . 

[JoëlHempenius3]

#TLDR; deinstalling the WA first prevents other systems from messing around with the ArcGIS Server. 

I would still use the old way of upgrading. I'm currently working for a large utility upgrading a four tier DTAP from 11.1 to 11.3 and ArcGIS Server was giving me headache.

I'm using ArcGIS Powershell DSC for installation and upgrade and it will upgrade the portal or server first before doing anything on the webadaptors. 

Right now I did upgrade DTA and everytime Powershell DSC would fail on the ArcGIS Server post-upgrade.  After the error ArcGIS Server service was stopped and no error message pointing to what happened. I could go to https://server:6443/arcgis/admin/upgrade and start the upgrade again, if I remember correctly it would reporrt after I clicked POST that it completed four steps, but it would never complete the next step. 

When this happened I reverted the snapshot and did a manual install, and after configuring the license execute the post-upgrade from MS Edge. The first time this worked and the server upgrade was completed. The second time I reverted the snapshot, did a manual install and I executed the command line post upgrade. This would result after some time in a connection reset error and at this stage the ArcGIS Server wouldn't work anymore, much like the state I would get from Powershell DSC. At this point I reverted the snapshot again, and reinstalled manually using MS Edge for the post-upgrade. 

For both servers, the WA was still installed and working.

The third server, I upgraded manually, configured the license, but then I had to do some other things first and so it took some time before I returned to finish the post-upgrade in the browser. When I returned, I couldn't navigate to the localhost:6443 url and the webpage wouldn't open. ArcGIS Server was stopped as a Windows Service and after starting it and navigating to localhost:6443/arcgis/admin/upgrade and starting the upgrade I immediately saw that it completed the first four steps! But how? Not sure how, but the webadapter was still there, fully functioning and ArcGIS Server at this stage would send 302 redirects to the upgrade endpoint. And if some system would follow the 302, do a POST there it could start the upgrade from there. Now this is just my theory, I've no evidence to prove it. But it's a fact that other clients can communicate with the server using the webadaptor at a stage where the upgrade has not completed yet.

So, revert snapshot, uninstall webadaptor, upgrade arcgis server, configure license, run browser post upgrade and everything completes without error message

If* I'm moving forward with production, I'm definitely going to deinstall the webadaptors first before any Powershell DSC or manual install is going to happen. 

*My services in a shared SOC are crashing every minute and I don't know why, most of them where published using the 2.9 runtime and I'm currently republishing them using the 3.3 runtime. It's about 500 services and everything has been automated using GIT and devops pipelines, so I just have to wait it out before I can see whether it makes the shared soc processes stable or not. 

*For unknown reasons, my NEW homepage setup on portal gets reset to a default homepage. I have to rebuild the whole thing, but it's just a matter of copying all configuration back from production. Still makes me doubt whether there are some other unseen isues as well