Community

Upgrade of ArcGIS Server 10.9.1 to 11.2 fails

1588
10
Jump to solution
02-11-2024 05:58 PM
Brian_Wilson
by
Occasional Contributor III
‎02-11-2024 05:58 PM

Suggestion solicited on how to actually make a Server upgrade work 10.9.1 to 11.2

Another failed Esri upgrade. This happens each time I do an upgrade. It's something new each time, keeps me on my toes. I have to work past all the bugs in the installers. Usually several. Usually I can refer to my notes for some of them, because they were not fixed in the intervening years. (Why would Esri fix old bugs when they are busy adding new ones??)

The upgrade of Portal and Portal Web Adaptor worked with only one major bug; "the username is longer than 20 characters". But I worked around that.

I then moved on with Server and it ran fine, finished, and launched the web browser. I can't go further than that because it fails to connect on port 6443. It's supposed to connect at https://localhost:6443/arcgis/manager/

I tried various and sundry URL's including localhost and hostname and various browsers including Firefox, Edge and Chrome. I tried connecting over the network from my desktop. (All behind a firewall and there are no reachability problems)

I checked logs and Event Viewer and I see no errors. The regular logs show nothing -- log messages show up in C:\Program Files\ArcGIS\Server\usr\logs\ instead of C:\arcgisserver\logs\ and I think that's what happens until the upgrade completes?  Here is a boring sample

<Msg time="2024-02-11T16:56:33,616" type="INFO" code="7720" source="Server" process="1224" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">The cloud regions configuration file was deleted from this server machine. If you have other server machines in the site, please make sure that the file has been deleted from them as well.</Msg>
<Msg time="2024-02-11T16:56:49,987" type="INFO" code="9011" source="Rest" process="4420" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">Application initialized.</Msg>
<Msg time="2024-02-11T16:56:49,987" type="INFO" code="9011" source="Rest" process="4420" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">Application initialized.</Msg>
<Msg time="2024-02-11T16:56:50,592" type="INFO" code="30204" source="Admin" process="4420" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">Webhook log: Webhooks app context initializing..</Msg>
<Msg time="2024-02-11T16:56:50,594" type="INFO" code="30204" source="Admin" process="4420" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">Webhook log: Webhook processors initialization in progress...</Msg>
<Msg time="2024-02-11T16:56:50,594" type="INFO" code="30204" source="Admin" process="4420" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">Webhook log: Starting webhook processors....</Msg>
<Msg time="2024-02-11T16:56:52,333" type="INFO" code="7702" source="Server" process="1224" thread="1" methodName="" machine="CC-GISSERVER.CLATSOP.CO.CLATSOP.OR.US" user="" elapsed="" requestID="">Web server started successfully.</Msg>

I found a suggestion regarding forcing the upgrade by going to https://cc-gisserver.clatsop.co.clatsop.or.us:6443/arcgis/admin/ but this is impossible because there is nothing running on port 6443

That article also mentioned the C:\arcgisserver\config-store\version.json -- it still says 10.9.1 which is depressing.

I tried running "repair" and rebooting. I've rebooted many times. I've tried running under a local account and under the AD network account.

I found a file from 2022 called version.rlock next to the version.json file and deleted it and then ran the installer again. The repair option wont run again.

I am thinking the actual upgrade does not happen until the URL is invoked?

I peeked at the Tomcat logs which as always show "potential memory leak" messages but nothing jumps out.

I will now tell my admin that he needs to roll back to the snapshots he made this morning, so that we can function normally rolling back to 10.9.1, having basically wasted another day. A Sunday. Insert more colorful language here.

 

10 Replies
Brian_Wilson
by
Occasional Contributor III
‎02-26-2024 11:42 AM

I had my fabulous IT guy clone the Server VM so I could hack away on it. I was able to get a version of 11.2 installed there, from scratch. It worked fine, but, no data.

Then I went ahead and did the full upgrade this past weekend. Hit the same problem, nothing on port 6443. Knowing it's a Tomcat app, I searched the Tomcat conf files and found that some text was different between the upgraded and installed-from-scratch versions in server.xml

Using 'netstat' in a Powershell I could see there was just no service running on port 6443. The service on 6080 simply redirects to 6443 at which time a browser just returns an error.

ESRI version from upgrade (fails)

<Connector SSLEnabled="true" URIEncoding="ISO-8859-1" clientAuth="false"
 connectionTimeout="60000" connectionUploadTimeout="1000000"
 disableUploadTimeout="false" maxHttpHeaderSize="65535" maxPostSize="10485760"
 maxThreads="150" port="6443"
 protocol="org.apache.coyote.http11.Http11Nio2Protocol" relaxedQueryChars=""
 scheme="https" secure="true" server=" " sslProtocol="TLS"
 useServerCipherSuitesOrder="true"/>

My current version from fresh install

<Connector SSLEnabled="true" URIEncoding="ISO-8859-1"
 ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384,
 TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
 TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
 TLS_RSA_WITH_AES_128_CBC_SHA" clientAuth="false" connectionTimeout="60000"
 connectionUploadTimeout="10000000" disableUploadTimeout="false"
 keyAlias="SelfSignedCertificate"
 keystoreFile="C:\Program Files\ArcGIS\Server\framework\etc\certificates\arcgis.keystore"
 keystorePass="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
 maxHttpHeaderSize="65535" maxPostSize="10485760" maxThreads="150" port="6443"
 protocol="org.apache.coyote.http11.Http11Nio2Protocol" relaxedQueryChars=""
 scheme="https" secure="true" server=" "
 sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" sslProtocol="TLS"
 useServerCipherSuitesOrder="true"/>

I saw references to a keystore file in the working version, so I confirmed the file existed. I edited the server.xml file to replace the lines above and restarted the service and it worked. I was then able to complete the upgrade with only the usual hiccups and flaws.

Once it completed I checked services and maps and all and everything seems to be working so far. It's been quiet today. Huge anticlimax. The only discernible difference so far is the version number.