Solution: Importing license failed during Portal upgrade

[BrianOevermann]

Yesterday I performed an upgrade of our ArcGIS Enterprise from v.10.6.1 to v.10.7.1. During the Portal upgrade I had an issue with importing our license file. After a lack of immediate success using Tech Support (they were stumped and it was later in the day so the overall brain trust had left), I tried one last thing and achieved success. I have supplied this info to Tech Support for their database but am putting it out on Geonet to hopefully save someone some stress if they see the same issue. [For the record, Tech Support had me cancel my license file and re-provision a license file, operating on the idea that the license file was possibly corrupt. That would be a good 'next step' if the solution below doesn't work for you.]

Attached is the error message I received when attempting to import my license file.

For the upgrade I referred to the Upgrade your ArcGIS Enterprise Portal help document for version 10.7.1. The relevant section of the document is under the heading “Perform an upgrade of your portal deployment.”

Step 7 says “Click Finish to close the installation wizard. The portal website opens in a browser window.”

Step 8 then has you clear your browser’s cache (including cookies).

Step 9 has you import your license file, which threw the error for me.

Faced with a delay in Tech Support being able to follow up to troubleshoot I was looking at rolling back our VM to prior to our upgrade so my users could get back to work. I decided to try an idea that popped into my head at the last minute.

I hypothesized that maybe clearing the cache after the page loaded caused something to break, so I copied the URL, cleared the browser cache yet again, and closed the browser. I restarted the browser and loaded the URL and the license file imported successfully.

It is possible that I could have simply reloaded the page and it would have corrected things.

Hopefully this helps someone into the future.

[RyanUthoff]

Clearing the browser cache is always a good idea. I always have to clear my browser cache when upgrading the web adaptors. A lot of end users of web maps also have to clear out their browser cache after the upgrade. Some users reported just a blank white page. But once they cleared their browser cache, everything worked fine.

[BrianOevermann]

I agree, Ryan. The takeaway here in my mind is that Step 8 seems to clear out whatever is loaded in step 7 and it takes a reload of the page to 'fix' it. It's interesting that the Server upgrade document says to clear your browser cache before you even start the upgrade. I'm unsure if the Portal upgrade document simply needs to have the cache clearing step listed earlier or if this only happens to certain people.

[BrianOevermann]

As I mentioned in my original post, I followed up with my Tech Support rep and provided my solution to my issue. After thanking me for my detailed email, my troubleshooting, and mentioning that he was making a note of this solution he responded with:

"I would like to mention that we do not recommend to re-load the page or clear the browser cache while upgrading ArcGIS Enterprise. Otherwise this can be a workaround as a part of troubleshooting."

Huh... and to be honest, arghhh! If that is the recommendation, then why is it STEP 8 in your upgrade document? I mean, the instruction to clear the browser cache (including cookies) isn't buried in another step. Esri explicitly made that task its own step in the process.

So, I guess you need to decide on your own if you perform step 8 or not as Esri seems conflicted in what we should do.

[JonathanQuinn]

I know that if you leave the Data Store registration page open for a while and then attempt to configure the Data Store, it returns a similar if not identical error, ("failed to load status 0"). After reloading the page, it registers successfully. My assumption is that it is related to a cookie or something expiring. While the documentation is correct in that there could be information cached that causes problems, if clearing the cache in the browser session, we should also indicate that the browser should be restarted. I'd circle back with the support analyst and ask them to give it a try, see if they see the same problem you did.

[BrianOevermann]

Jonathan Quinn‌, it is honestly water under the bridge for me now. This was my first upgrade with Portal involved so I anticipated only about a 3-4 hour Enterprise upgrade. How wrong I was! It was about 4 hours just for the Portal upgrade alone. With that short anticipated time window I chose to take Enterprise offline during the day in order to have my IT colleagues close at hand should something go awry.

I was happy to find the solution on my own since I was facing the decision point of either inconveniencing my users for another whole day or rolling our VM back to pre-upgrade and re-scheduling the upgrade to another day/time. It ended up being a 15 hour day for me, though that included work hours that were before the start of the upgrade process.

I've pretty much given the support analyst the scenario and steps taken so they should be able to set up their own test environment and do whatever testing they deem necessary. At the very least I am hoping that he documented my solution in the database so that it gives staff another possible thing to try if others have the same issue.

The upgrade document for Server has you clearing your browser cache before you even start the upgrade. I don't know if that is viable with the Portal upgrade. Logic tells me that step was placed where it is for specific reasons.

[JasonHansel1]

I know this is an old thread but can still happen. I wanted to share what has worked for me.

One thing to check in the logs (\framework\runtime\ds\usr\logs) as @JonathanQuinn mentioned is lock notifications that indicate .nodes or any other lock file is write protected. What looks like happens, is if the index fails to upgrade, these lock files get left behind and don't get cleaned up, which prevent the index from upgrading after a failed attempt. If you Stop Portal, remove these lock files in the target index directory, then re-start Portal, the indexes should be able to backup to the 'portal-upgrade' folder and propagate to the 'index' folder.