ISE Upgrade Planning and Migration
ISE Upgrade Planning and Migration
Introduction
Upgrading Cisco Identity Services Engine (ISE) is one of the most critical operations you will perform in a production network. Unlike a simple software update, an ISE upgrade fundamentally involves building a new deployment cluster running the target version and migrating your configuration and data into it. A poorly planned upgrade can result in authentication outages, lost configuration, or extended downtime that impacts every user and device on your network.
This lesson walks you through the complete upgrade planning and execution process. You will learn the available upgrade methods, how to prepare your environment with a thorough pre-upgrade checklist, how to estimate and reduce upgrade duration, and the recommended five-step sequence for upgrading a distributed ISE deployment. By the end of this lesson, you will have a clear, repeatable framework for planning and executing ISE upgrades with confidence.
Key Concepts
Before diving into the upgrade process, you need to understand the ISE node personas and the three upgrade methods available.
ISE Node Personas
Every ISE deployment consists of nodes assigned specific personas that define their role in the cluster:
| Abbreviation | Full Name | Role |
|---|---|---|
| PPAN | Primary Policy Administration Node | Holds the primary configuration database |
| SPAN | Secondary Policy Administration Node | Configuration replica; promotes to primary during upgrade |
| PMNT | Primary Monitoring Node | Stores operational data (logs, reports) |
| SMNT | Secondary Monitoring Node | Monitoring replica |
| PSN | Policy Service Node | Handles authentication and authorization requests |
Understanding these personas is essential because the upgrade sequence is built around them. Upgrading an ISE cluster consists of creating a new cluster in the target version, and each node transitions through a specific order to minimize service disruption.
Upgrade Methods
ISE provides three distinct upgrade methods, each suited to different deployment sizes and requirements:
| Method | Description | Best For |
|---|---|---|
| Backup and Restore (Reinstall) | Reinstall all nodes to the new version using the installation ISO. Configuration backup is restored on the SPAN. Data is replicated between nodes. Only option available for cloud instances. | Large deployments to optimize upgrade duration (fastest method) |
| Split Upgrade | Step-by-step upgrade allowing you to upgrade more nodes simultaneously in iterations. Available starting from 3.2P3 and 3.3. Includes pre-checks. | Small and medium deployments; distributed deployments across multiple regions |
| Full Upgrade | Two-step upgrade process: first the PPAN, then all other nodes. No persona change required. Added in 2.6P10, 2.7P4, and 3.0P3. | Faster approach but downtime is required |
The Split Upgrade method offers better visibility and control over the upgrade process. It is often preferred when advanced knowledge of the ISE upgrade process is available and is commonly used as a fallback if a GUI-based upgrade fails. The Backup and Restore method is the fastest overall and is the only option for cloud-based ISE instances.
How It Works
The Upgrade Sequence in a Distributed Deployment
The recommended upgrade sequence for a distributed ISE deployment follows five steps. Think of this as the flight plan you must follow precisely to land safely.
Step 1 -- Upgrade the SPAN. The Secondary PAN is upgraded first. Once upgraded, it becomes the new PPAN of the new cluster running the target version.
Step 2 -- Upgrade the PMNT. The Primary Monitoring Node is upgraded next. It retains its PMNT persona in the new cluster (no persona change is required for this node).
Step 3 -- Upgrade the PSNs. Policy Service Nodes are upgraded next. You can take as many iterations as needed to avoid impacting authentication services. For example, if you have six PSNs, you might upgrade them in groups of two to maintain service availability throughout the process.
Step 4 -- Upgrade the SMNT. The Secondary Monitoring Node is upgraded and joins the new cluster as the SMNT.
Step 5 -- Upgrade the original PPAN. The original Primary PAN is the last node upgraded. It becomes the SPAN in the new cluster.
Key Point: MNT nodes and PSN nodes can be upgraded at the same time, which helps reduce overall upgrade duration.
Tip: For faster parallel ISE reinstallation on multiple VMs, use the ISO image instead of the OVA. Ensure the ISO is located close to the server to minimize installation delays, particularly when using a mounted ISO over CIMC KVM. Localized ISE Installation is available starting from 3.1P9, 3.2P5, 3.3P3, and 3.4.
Estimating Upgrade Duration
Planning your maintenance window requires realistic time estimates. The following table provides approximate durations for each operation during an upgrade:
| Operation | Estimated Duration |
|---|---|
| Reimaging ISE | 60--70 minutes |
| Restoring a configuration backup (PPAN) | 40--60 minutes |
| Registering a node into the cluster | 20--30 minutes |
| Upgrading a node | 70--120 minutes |
| Upgrading operational data (MNT) | 5 minutes per GB of operational data |
| Patching | 20--30 minutes |
| Persona change | 15 minutes |
Note: These are estimates and actual timings are subject to your specific environment. Improving the upgrade duration can be achieved by cleaning endpoints, users, and logs before starting the upgrade.
Configuration Example
Pre-Upgrade Repository Validation
Before starting any upgrade, you must set up and validate your upgrade repositories. Repositories should be accessible and located as close as possible to the ISE nodes.
Validate repositories through the CLI on all nodes:
show running-config | include repository
This command displays all configured repositories. To verify that a specific repository is reachable and contains the expected files:
show repository {repository_name}
Using the Local Disk as a Repository
You can use the local disk to store the URT file, upgrade bundle, or ISO installation file. Copy files to the local disk using the CLI:
copy {source_url} disk:/
To list files on the local disk and check free space:
dir disk:/
Note: Since ISE 3.1, you can manage local disk files directly from the GUI under Administration > System > Maintenance.
Running the Upgrade Readiness Tool (URT)
The Upgrade Readiness Tool (URT) verifies that the configuration database is compatible with the new version and provides an estimated upgrade duration per node. Run the URT on the SPAN:
application install {URT_filename} {repository_name}
The URT is optional for the Split Upgrade and Full Upgrade methods, but it is highly recommended as it catches compatibility issues before you commit to the upgrade.
Purging Operational Data to Reduce Upgrade Duration
Large volumes of monitoring data significantly increase upgrade time, especially on MNT nodes where operational data is upgraded at a rate of approximately 5 minutes per GB. You can purge operational data using the CLI:
application configure ise
When prompted with the menu, select option 3 to purge Monitoring and Troubleshooting operational data:
[3] Purge M&T Operational Data
# 3
Enter days to be retained: 1
This command purges all operational data older than the number of days you specify. You can also use the Purge Data Now option in the ISE GUI to accomplish the same task.
Warning: Operational data logs are not synchronized between MNT nodes in case of a persona change. If you need historical data, export it before purging.
Real-World Application
The Pre-Upgrade Checklist
In production environments, successful ISE upgrades come down to preparation. Here is the complete checklist you should follow before every upgrade:
Planning tasks:
- Choose the target version carefully, considering feature requirements and known defects
- Validate the upgrade path -- determine whether a direct upgrade or a two-step upgrade is required
- Install the latest patch on your current version before upgrading (and install the latest patch on the target version after upgrading)
- Choose your upgrade method (Backup and Restore, Split Upgrade, or Full Upgrade)
- Set up and validate your repositories on all nodes
Backup tasks:
- Back up your configuration (this is mandatory)
- Optionally back up operational data; if not required, export and purge it
- Export network devices and endpoints as CSV files
- Export certificates and private keys
- Export internal CA certificates from the CLI
Documentation tasks:
- Record Active Directory credentials, MDM credentials, and other integration credentials
- Document the profiler configuration for each PSN
Cleanup tasks:
- Delete expired certificates
- Purge operational data, inactive endpoints, and guest accounts
Final preparation:
- Perform Health Checks (available since 2.6P8 and later)
- Disable PAN Failover
- Disable scheduled backups
- Run the URT on the SPAN
Testing Before Going Live
Before committing your production environment to the upgrade, consider building a test environment. You can reimage an unused PSN to the target version, install the latest available patch, restore your configuration backup on this test node, and then perform authentication tests covering all your use cases. This validation step can save you from discovering issues in production.
Design Considerations
- Cloud deployments must use the Backup and Restore method -- this is the only supported option for cloud instances.
- Multi-region deployments benefit from the Split Upgrade method because it provides granular control over which nodes are upgraded and when, allowing you to maintain service in each region while upgrading others.
- Small maintenance windows may favor the Full Upgrade method for its simplicity, but be aware that it requires downtime.
- Reducing upgrade time is primarily achieved by purging operational data, cleaning inactive endpoints, and removing expired guest accounts before the upgrade begins.
Summary
- ISE upgrades create a new cluster in the target version rather than updating nodes in place. The recommended five-step sequence starts with the SPAN and ends with the original PPAN.
- Three upgrade methods are available: Backup and Restore (fastest, required for cloud), Split Upgrade (best control and visibility), and Full Upgrade (simplest but requires downtime).
- Preparation is everything. Follow the complete pre-upgrade checklist: validate repositories, run the URT, back up configurations and certificates, document credentials, and clean up operational data.
- Purging MNT operational data before upgrading dramatically reduces upgrade duration since operational data upgrades at roughly 5 minutes per GB.
- Test before you commit. Restore your configuration on a test node running the target version and validate your authentication use cases before upgrading production.
With this lesson, you have completed the ISE Advanced Operations course. Continue your studies by practicing upgrade scenarios in a lab environment and reviewing the ISE Health Check features available in your current deployment to build operational confidence before your next production upgrade.