Latest Contributions by ChristopherPawlyszyn

Did you compare your original installation directory/location to the new deployment? If the arcgisportal/db directory changed, then that may be a reason the restore fails on the database portion. Check out this doc for the required settings for duplicate deployments: Disaster recovery and replication | ArcGIS Enterprise ... View more

If the Windows OS is reporting virtual memory exhaustion, that's usually a pretty reasonable diagnosis and is hopefully trivial to remedy. An important thing to keep in mind is that in the latest Windows Server operating systems (2016 and 2019), the page file growth is limited to the size of the volume it is on divided by eight. This means that for a 60GB C: volume, the default system-managed settings would restrict growth of the page file to 7.5GB. With that in mind, you may want to work with your IT team to either define a static value for the page file (old-school recommendations range between 1.5-3x the amount of physical [or virtual] RAM on the machine), or move the page file to a volume with a larger size to allow for additional expansion of the virtual memory. How to determine the appropriate page file size for 64-bit versions of Windows - Windows Client Management | Microsoft Docs https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size#system-managed-page-files ... View more

My suspicion is that OpenStack operates in a similar fashion, so would issue the shutdown command to the VM upon termination and not initiate the failover process. As I alluded to earlier in the thread, I do believe your tile cache data store is behaving as-expected at this point and the failover conditions haven't been met. One way to initiate the failover may be to remove/detach/disable the network interface from the VM in OpenStack prior to terminating it, but I'm not sure the level of effort to accomplish that on your hypervisor interface. I went ahead and logged an enhancement request internally for adding that functionality, so that the development team is aware of the topic going forward. I agree that this would be a helpful step towards allowing testing of failover between the machines in a high availability tile cache configuration. Another location where you can log the request is within the ArcGIS Enterprise Ideas board, since members of the product team review those ideas and determine relative interest. ArcGIS Enterprise Ideas - Esri Community https://community.esri.com/t5/arcgis-enterprise-ideas/idb-p/arcgis-enterprise-ideas If you open a support case, the owning analyst should be able to attach the case to the existing enhancement. Feel free to reach out directly if you have any trouble with that process. ... View more

Not sure what cloud platform you were testing in, but I was able to reproduce the same results in AWS. It looks like the termination of the instance falls under the graceful shutdown conditions since an ACPI shutdown event is triggered. Terminate your instance - Amazon Elastic Compute Cloud https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#what-happens-terminate ... View more

Apologies, I wasn't clear in that statement. The events that initiate a failover with the tile cache data store match the events for the relational data store. While there is an option to failover on a graceful shutdown for the relational data store, the equivalent for the tile cache data store is not available. A graceful shutdown in this circumstance would include stopping the ArcGIS Data Store service, shutting down the machine, or restarting the machine. The manually-initiated failover of the tile cache data store would have to occur by abruptly disconnecting the network connection on the machine that is currently the primary node, or by running the 'makePrimary' operation on the standby machine in the Server Admin endpoint while the primary is still accessible. Since you have additional components on the same machine, this is less simple to simulate as you would also cause a failover of Portal's roles if the primary nodes are the same for those two components. ArcGIS Server should run at half capacity without issue, just a reduction in the overall instances available to service requests.   This excerpt was what I was referring to for the similarities between the relational and tile cache data stores during failover events:   The following is a list of situations for which the standby machine becomes the primary for your relational data store. Note that the following three situations involve hardware or software failures. The primary data store stops working. ArcGIS Data Store attempts to restart the data store on the primary machine. If it cannot restart, the data store fails over to the standby. The primary's web app stops running and attempts to restart the web app on the primary machine. In the rare case that this does not work, the data store fails over to the standby machine. The primary machine is unavailable. This can happen if the computer crashes, is unplugged, or loses network connectivity. ArcGIS Data Store makes five attempts to connect to the primary machine. If a connection is not possible after five attempts, the data store fails over to the standby machine. From https://enterprise.arcgis.com/en/portal/latest/administer/linux/add-standby-machine.htm#ESRI_SECTION1_39B889D99635448CB901792F0DF80EE3 ... View more

There is an enhancement request that has been logged for this ability with the ArcGIS Enterprise core components (ArcGIS Server, ArcGIS Data Store, Portal for ArcGIS), but the functionality from a web-tier perspective is already available depending on the configuration of the web server running the ArcGIS Web Adaptor or whatever load balancer/reverse proxy is fronting the client-side communication to the internal components. My configured HTTPS binding for port 443 (using IIS 10.x) shows in my browser's network traffic capture as using HTTP/2 for communication with ArcGIS Enterprise resources when accessed via the web adaptor. ... View more

I've found in practice that the Tile Cache Data Store behaves the same as the rules outlined for the Relational failover (if the failover_on_primary_stop property is not enabled). With that being the case, this should apply to the failover process: "The only human-initiated situations that cause a failover are if the primary data store machine is deliberately taken offline, or the ArcGIS Server site administrator runs the makePrimary REST command on the standby machine." From: https://enterprise.arcgis.com/en/portal/latest/administer/linux/add-standby-machine.htm#:~:text=Failover%20scenarios%20for%20relational%20data%20stores&text=The%20primary%20data%20store%20stops,app%20on%20the%20primary%20machine. Prior to shutting-down the primary machine, you should be able to promote the standby to primary via the Admin API, then you can patch/restart the previously-primary machine without interruption of your hosted scene layers. If that is not working as described, then we'd need to take a closer look at your particular configuration to get a better idea of what part of the process is breaking-down. ... View more

I just attempted a deployment without configuring the CNAME record to point to the <subdomain>.<region>.cloudapp.azure.com endpoint and it failed on the ArcGIS Server deployment process. Having the CNAME available beforehand is therefore a necessary step and not doing so will prevent a successful deployment. Due to the way Azure Front Door routes traffic, and the requirements of Portal to only support a single DNS, I think the Cloud Builder application is not going to be compatible with your intended use case. With that being said, you may be able to break the federation of the deployed site and update the URLs to use the correct Front Door URL while still maintaining a trusted endpoint on the Application Gateway, but the header rules on the Application Gateway would have to be reconfigured accordingly as well. Modifications of that level would prevent the site from being managed/upgraded by the Cloud Builder application in the future, so it seems like a catch 22. Thinking out loud, is there a method by which the Front Door configuration can resolve DNS differently than via public DNS? If that is the case, the Front Door service could resolve to the Application Gateway while clients would resolve to the Front Door service for the same target host and the same SSL certificate could be used for both. ... View more

Have you tried exporting the artifacts prior to hitting the final button to start the deployment? I'd be curious if the AGBaseproperties.json existed within those exported files. Nothing in your summary immediately jumps-out as causing an issue, so I'm thinking we may need to look further in the Azure logs. If you login to the Azure portal in a browser, then select Monitor and Activity Logs, you should see a failed deployment with a drop-down arrow. Selecting the event that failed and looking at the JSON output should give you the clearest indication of anything Azure-size that the Cloud Builder application may not be aware of. I can drum-up a screenshot if it would be helpful as well. ... View more

Are you using the service in SystemD to start/stop ArcGIS Server or manually calling the start/stop scripts? There is a definition for 'LimitNOFILE' in the arcgisserver.service file that may be taking priority over the value defined in /etc/security/limits.conf, so either commenting-out that line in the arcgisserver.service file or increasing that value may change the behavior. I haven't had a chance to test it directly yet today. ... View more

Image Server is a licensed role for ArcGIS Server, so the only designation you should have to make in that regard is using a license file that includes the Image Server authorization code as well as the core GIS Server license. ... View more