With any software package or system, planning for upgrades, maintenance and patching is an important part of the architecture design process. While you may deploy one specific version of a system, as updates are made and security issues are discovered, and as users interact with the system, there will inevitably be a need to apply patches, updates, or upgrades to the system.
Even fully managed SaaS systems like ArcGIS Online have patching and upgrade considerations. While the process of an update to ArcGIS Online may not involve actions by users of the system, properly planning for the announced new functionality, carefully monitoring content and workflows following an upgrade, and submitting issues if they occur are all parts of ensuring a successful upgrade and patching window.
Patching as a term can be applied to almost any software, but in ArcGIS it generally refers to specific software updates that are delivered in between official software releases, or provided for a prior release, to address some gap in functionality, identified software defect or issue. Generally, patches do not introduce any new functionality, and are only considered, built and offered for a period of time after the release of the software, as specified in the Software Product Lifecycle. As an example, see the ArcGIS Enterprise Product Lifecycle.
Patching approaches vary for different categories of ArcGIS products, including ArcGIS Online, ArcGIS Enterprise, and other client apps.
For ArcGIS Online, patches are applied for any issues that are identified in the period directly following the release date for a new software version. After this initial period, no patches are applied until the next regular, planned release of ArcGIS Online. As a SaaS product, no user action is required in relation to patches as they are applied directly and without user visibility, and there is no patching of older releases as there is only one release of ArcGIS Online available to users at a time – the current release.
For ArcGIS Enterprise, patches are provided as downloadable, installable files for Windows and Linux. In Kubernetes, they’re applied directly from the software. Patches can be identified, downloaded, and applied from the Esri Support website, or can be identified and applied directly to the system using the Check for ArcGIS Enterprise Updates tool that is included with ArcGIS Enterprise. More information on this process is available in the ArcGIS Enterprise documentation.
Applying patches to ArcGIS Enterprise components should be carefully planned in relation to the downtime of the target system. Most patches require a restart of the software component that is being patched, which will introduce a short period of downtime as the service or component restarts. For highly-available systems, see how to apply patches and updates to highly available components. Patches can be deployed following an initial software install (if already released) or deployed through automation tools like Chef or Powershell DSC.
In any case, patching should be intentional and specific, in coordination with IT patching procedures for other software components or the operating system. Patching one component often affects others and it is generally preferred to combine patches into one window or period of time to reduce downtime for users. Patching intentionally means carefully considering the order of components to be patched, and ensuring that the patching mechanism, either an automated process or a staff-managed process, follows this design and plan.
Patches can generally be rolled back or uninstalled if any issues are discovered, but are designed to be cumulative, so that multiple patches can be applied to a system as they are released, without a specific, defined order or definition of importance. In some cases, patches refer to specific functionality, in others they may provide general security updates, and as such it is recommended to apply all ArcGIS Enterprise patches as they are released.
Updates for ArcGIS Pro, specifically patches to an already-installed version, which are identified to with a Major.minor.patch numbering approach, are released regularly, but generally only for the latest version of the software, with the exception of certain releases focused on the utility industry or exceptional security patching scenarios. Patches are usually applied directly within the application, which will notify users who are logged in to an ArcGIS Online account of the availability of an update. Updates usually require proper privileges to install software but can otherwise be installed by users as needed and at their discretion.
ArcGIS Pro patches can also be automated and deployed using software automation like Microsoft System Center. Updates to ArcGIS Pro should be carefully planned for large ArcGIS Pro organizational deployments, so that users are able to maintain version consistency across the organization, as this encourages compatibility and assists with technical support processes.
Updates for other client applications beyond ArcGIS Pro are handled differently by application. For example, ArcGIS Experience Builder developer edition is released shortly after each release of Experience Builder for ArcGIS Online, and patches are generally not provided. For ArcGIS mobile applications such as Field Maps or Survey123, patches are deployed directly to the relevant App Store, and users usually receive the update automatically, as mobile operating systems move towards automatically and silently updating applications. For applications configured within ArcGIS Enterprise, patches to the ArcGIS Enterprise software may contain changes to this functionality, but they are not individually patched outside of the Portal for ArcGIS patching process.
Operating system (OS) patching is generally outside if the scope of control or responsibility for a GIS software team, but as enterprise systems increasingly align to IT standards, a clear plan for OS patching is a requirement of a well-architected design. Most enterprise IT organizations will already have a standard patching approach, so the first step is understanding the likely impact to an ArcGIS system, as well as how any impacts can be possibly mitigated.
Operating system patching usually occurs on a regular basis, for example, once a week, once a month, or at another interval. Some patching approaches are disruptive, forcing an update on the operating system through a sudden restart, while others can more gracefully instruct programs and services to shut down, and then restart and apply patches, or even apply patches without a restart to the system. In all cases, it is recommended to allow the system to gracefully shut down before applying updates, as the more disruptive approach can lead to issues with data persistence components within the software, or unexpectedly stop jobs that are underway such as geoprocessing tasks.
Operating system updates can also introduce unexpected issues with software deployed to the system and should be carefully tracked and recorded so that an update can be rolled back if issues are discovered. Esri reviews and deploys operating system patches to understand compatibility as well as potential conflicts or issues and will issue advisory statements for any problematic OS updates or configurations as they are identified.
An upgrade refers specifically to upgrading to a new major or minor release of software, rather than patching an existing release. Upgrades can be seamless, for example in a SaaS system, or somewhat disruptive, when using on-premises software and are usually a carefully planned, managed, and tested process. Upgrades are essential, however, to get users access to the latest technology, features, and offerings, and should be expected on a regular basis for most enterprise systems built with ArcGIS.
Upgrading ArcGIS Enterprise is a well-documented and carefully tested process, as covered in the official documentation. The considerations topic covers important decisions related to upgrades, and should be reviewed as the planning process for an upgrade begins. If your organization is slow to upgrade or prefers to stay on a single version for an extended period of time, be sure to deploy Long Term Support releases of ArcGIS Enterprise.
Upgrades to ArcGIS Enterprise components should always include a backup of the system, either through VM snapshots, the webgisdr tool, or another mechanism, so that the system can be restored if significant issues are discovered.
Upgrades to most specific ArcGIS web applications such as Experience Builder or Instant Apps are largely invisible to the user, either because they are part of the ArcGIS Online or ArcGIS Enterprise system upgrade (and thus applied automatically as part of the larger upgrade) or are upgraded automatically by the operating system (in the case of mobile applications).
ArcGIS Pro deserves particular consideration due to the relationship between ArcGIS Pro, spatial databases that are enabled as enterprise geodatabases, and ArcGIS Enterprise or ArcGIS Online. While most versions of ArcGIS Pro can connect to most versions of ArcGIS Enterprise, and older versions of ArcGIS Pro can be used to publish to ArcGIS Online, several key details include:
Another component that needs to be upgraded along with the desktop and enterprise software are the geodatabase system tables, which are created in a relational database when an enterprise geodatabase is created or enabled. Geodatabase upgrades are documented for each individual database provider and are conducted from ArcGIS Pro or through a Python tool. They are generally quick to complete, but can be disruptive as they require all user and system connections to be dropped or disconnected from the database during the upgrade, so that relevant tables and functions can be changed. Backing up an enterprise geodatabase at the database or schema level is suggested prior to a geodatabase upgrade.
Operating system upgrades deserve particular attention as they are increasingly requested or implemented by IT departments that are moving both clients (users’ laptop or desktop computers) and servers to newer versions of operating systems as older versions fall out of support or are retired. Updates to the operating system of an active, working system are possible, and can be successful, but are considered riskier than deploying new VMs at a desired OS release version, and migrating a deployment to that system.
While users have been successful with in-place operating system upgrades, the primary potential risk is that any issues that arise are likely related specifically to the OS upgrade, and may not be reproducible in a simple deployment, so getting effective help from Esri Technical Support may be more difficult as the problems originate outside the Esri components. Work closely with IT support to understand the implications, backup and restore possibilities related to an operating system upgrade.