ISE 2.7 to 3.2 Migration Questions

[Chris Terry]

I plan on doing the backup and restore method of upgrading to ISE 3.2 from ISE 2.7. My current deployment is 6 VMs, 2 PANs and 4 PSNs.

Questions:
- For the upgrade I know it's required to switch to smart licensing and I'm currently using the traditional licensing. Would I just have the current licenses converted to smart licenses? Would that be done in the background, or would it impact the current deployment?
- In the guide it's required to update the Guest OS to RHEL 8. Would I be able to update the VMs prior to the upgrade maintenance window, or is the Guest OS version updated after the upgrade to 3.2? Would ISE 2.7 be able to run on RHEL 8 until the upgrade window?

[Arne Bier · Accepted solution]

Hello,

You won't need to upgrade the RHEL version since you will deploy a fresh ISE 3.2 VM upon which you restore the config backup from an ISE 2.7 PAN.  When you restore an "older version" config onto a newer version ISE, then ISE triggers the upgrade.

You can keep your existing PSN nodes running while you build the new ISE 3.2 deployment. Typically, in say a 2 node deployment you de-register the Secondary node, shut it down cleanly and then use its IP details to deploy the fresh ISE 3.2 node. Then restore config backup. Then make that new node Primary. Now you have two deployments. 2.7 and 3.2 - they are independent. But since the config was restored onto the new 3.2 node, the config of both nodes is the same.  You must of course ensure that the certs and AD joins etc. are done on the new node. The WLC/Switches etc. will not notice any difference. But you will have to monitor Live Logs in two places at once

Smart Licensing is not automatic. You have contact Cisco to have the traditional licenses converted to Smart.

[Chris Terry]

When you mention a fresh ISE VM is that a brand new VM? I always thought the method involved taking the secondary PAN out of the deployment and reimaging it to 3.2. 

[ajc]

Hi Arne,

I am facing that scenario, going from 2.7 to 3.2. I have a complete parallel deployment to play with (including IP's). So far I created a new VM running ISE 3.2 patch 4 (ESXi 7.0 / RHEL8)   so based on your coment I could directly restore my 2.7 ISE PATCH 7 config backup into this VM that initially would run 3 personas (and later on individual roles as more nodes will be added), Is that right?.

I have also a backup of the ISE 2.7 trusted CA, Primary PAN cert, etc that will be used on the 3.2 deployment for initial testing. I have no limitations regarding IP, deploying a parallel ISE 3.2 deployment and later change the Radius entries for WLC's, Meraki Dashboard, etc.

Do I have to install the latest 2.7 patch and created the backup, I mean patch 10 or my current patch 7 is ok? Based on the following link looks like patch I would need patch 10. That would not be an issue because I can install a 2.7 VM patch 7, restore the backup config and then install patch 10. From there, I would create another 2.7 config backup that would be restored in my 3.2 patch 4 VM.

https://community.cisco.com/t5/security-knowledge-base/ise-version-upgrade-matrix/ta-p/3653501

[Chris Terry · Accepted solution]

Hi Ajc,

You can directly restore your ISE 2.7 config to the ISE 3.2 VMs. ISE 2.7, ISE 3.0, and ISE 3.1 is listed as versions that can be directly upgraded to ISE 3.2.

It's recommended that you are on the latest patch of ISE 2.7 per the upgrade guide. I would also recommend using the URT (Upgrade Readiness Tool) bundle to validate the current configuration and point out any potential issues when upgrading.

I upgraded from ISE 2.7 to ISE 3.2 using the back and restore method. I, personally, used new VMs with different IPs. My PSN nodes are load balanced behind F5 VIPs. I have a 6 node deployment. Using different IPs allowed me to bring up the deployment and fully validate everything before I cutover. That involved adding the new certs, joining AD, etc. All I had to do was change the pool members to the new PSNs in the F5 pools for the VIPs.

[ajc]

Got it so I assume that you restored into a 3.2 patch 4 ISE VM the config backup of ISE 2.7 patch 10, am i right? btw there are multiple security vulnerabilities on 3.2 addressed by at least 3.2 p3 see picture

[ajc]

I am working in a parallel deployment, created a new ISE 2.7 p7 VM, restore my existing 2.7p7 config backup into this new VM. On my new VM, installed 2.7 p10 (last patch), created another new 3.2 p4 VM and tried to restore the 2.7 p10 config backup and it failed.

Now I am moving into the 2.7 p10 new VM direct upgrade to 3.2 version (RHEL config changes would be required after the upgrade) since that the initial one failed.

[Chris Terry]

Did you try running the URT (Upgrade Readiness Tool) on your current VMs running 2.7? It will check everything to make sure you can upgrade.

[ajc]

I did it but keep in mind that I am restoring an ISE 2.7 p10 config backup into the 3.2 p4 VM that based on the notes of this post should work but it did not for my case.

ISENODE/admin# application install ise-urtbundle-3.2.0.542a-1.0.0.SPA.x86_64.tar.gz ?
<WORD> Name of the configured remote repository (Max Size - 255)

ISENODE/admin# application install ise-urtbundle-3.2.0.542a-1.0.0.SPA.x86_64.tar.gz REPO
Save the current ADE-OS running configuration? (yes/no) [yes] ? yes
Generating configuration...
Saved the ADE-OS running configuration to startup successfully

Getting bundle to local machine...
Unbundling Application Package...
Verifying Application Signature...
Initiating Application Install...

###########################################
# Installing Upgrade Readiness Tool (URT) #
###########################################

Checking ISE version compatibility
- Successful

Checking ISE persona
- Successful

Along with Administration, other services (MNT,PROFILER,SESSION) are enabled on this node. Installing and running URT might consume additional resources.
Do you want to proceed with installing and running URT now (y/n):y

Checking if URT is recent(<45 days old)
- Note: URT is 226 days old and its version is 1.0.0. There might be a recent URT bundle on CCO, please verify on CCO
Do you want to proceed with this version which is 226 days old (y/n):y
Proceeding with this version of URT itself

Installing URT bundle
- Successful

########################################
# Running Upgrade Readiness Tool (URT) #
########################################
This tool will perform following tasks:
1. Clone config database
2. Copy upgrade files
3. Data upgrade on cloned database
4. Time estimate for upgrade

Clone config database
=====================
[####################--------------------] 50% Exporting data from ISE database tdsbise31
Not executed the acl_config
ISENODE
Not executed the acl_config
GET_HOST_NAME is working fine
[########################################] 100% Successful

Copy upgrade files
==================
- N/A

Data upgrade on cloned database
===============================
Modifying upgrade scripts to run on cloned database
- Successful

Running schema upgrade on cloned database
- Running db sanity to check and fix if any index corruption
- Auto Upgrading Schema for UPS Model
Do you want to proceed with installing and running URT now (y/n):y

Checking if URT is recent(<45 days old)
- Note: URT is 226 days old and its version is 1.0.0. There might be a recent URT bundle on CCO, please verify on CCO
Do you want to proceed with this version which is 226 days old (y/n):y
Proceeding with this version of URT itself

Installing URT bundle
- Successful

########################################
# Running Upgrade Readiness Tool (URT) #
########################################
This tool will perform following tasks:
1. Clone config database
2. Copy upgrade files
3. Data upgrade on cloned database
4. Time estimate for upgrade

Clone config database
=====================
[####################--------------------] 50% Exporting data from ISE database ISENODE
Not executed the acl_config
ISENODE
Not executed the acl_config
GET_HOST_NAME is working fine
[########################################] 100% Successful

Copy upgrade files
==================
- N/A

Data upgrade on cloned database
===============================
Modifying upgrade scripts to run on cloned database
- Successful

Running schema upgrade on cloned database
- Running db sanity to check and fix if any index corruption
- Auto Upgrading Schema for UPS Model
- Upgrading Schema completed for UPS Model
- Successful

Running sanity after schema upgrade on cloned database
- Successful

Running data upgrade on cloned database
- Data upgrade step 1/68, NSFUpgradeService(2.8.0.127)... Done in 16 seconds.
- Data upgrade step 2/68, NetworkAccessUpgrade(3.0.0.10)... Done in 0 seconds.
- Data upgrade step 3/68, UPSUpgradeHandler(3.0.0.10)... Done in 2 seconds.
- Data upgrade step 4/68, GMTConfigRegistration(3.0.0.221)... Done in 0 seconds.
- Data upgrade step 5/68, UPSUpgradeHandler(3.0.0.227)... Done in 0 seconds.
- Data upgrade step 6/68, ERSDictionaryRegistration(3.0.0.240)... Done in 0 seconds.
- Data upgrade step 7/68, CertDictAttribAddition(3.0.0.240)... Done in 0 seconds.
- Data upgrade step 8/68, UPSUpgradeHandler(3.0.0.250)... Done in 8 seconds.
- Data upgrade step 9/68, EPScriptOSConfigRegistration(3.0.0.307)... Done in 0 seconds.
- Data upgrade step 10/68, AuthzUpgradeService(3.0.0.320)... Done in 0 seconds.
- Data upgrade step 11/68, RegisterPostureTypes(3.0.0.325)... Done in 0 seconds.
- Data upgrade step 12/68, ESAgentlessPostureScriptRegistration(3.0.0.352)... Done in 0 seconds.
- Data upgrade step 13/68, GuestAccessUpgradeService(3.0.0.355)... Done in 8 seconds.
- Data upgrade step 14/68, UpnDictionaryCreation(3.0.0.368)... Done in 0 seconds.
- Data upgrade step 15/68, UpnProfileCreation(3.0.0.368)... Done in 0 seconds.
- Data upgrade step 16/68, SessionServiceAgentlessRegistration(3.0.0.375)... Done in 0 seconds.
- Data upgrade step 17/68, PostureSettingsAgentlessRegistration(3.0.0.382)... Done in 0 seconds.
- Data upgrade step 18/68, SxpConnectionUpgrade(3.0.0.382)... Done in 0 seconds.
- Data upgrade step 19/68, RestIDStoreSettingsRegistration(3.0.0.385)... Done in 0 seconds.
- Data upgrade step 20/68, AnyNadProfIdRegistration(3.0.0.388)... Done in 0 seconds.
- Data upgrade step 21/68, AuthProfileUpgradeService(3.0.0.389)... Done in 0 seconds.
- Data upgrade step 22/68, AccessSecretEncryptionUpgrade(3.0.0.436)... Done in 0 seconds.
- Data upgrade step 23/68, ProvisioningRegistration(3.0.0.441)... Done in 7 seconds.
- Data upgrade step 24/68, UPSUpgradeHandler(3.0.0.442)... Done in 2 seconds.
- Data upgrade step 25/68, RuleResultsSGTUpgradeService(3.0.0.450)... Done in 0 seconds.
- Data upgrade step 26/68, SGTToTableMapper(3.0.0.450)... Done in 0 seconds.
- Data upgrade step 27/68, OpenApiRegistration(3.1.0.120)... Done in 1 seconds.
- Data upgrade step 28/68, CertMgmtUpgradeService(3.1.0.152)... Done in 2 seconds.
- Data upgrade step 29/68, RegisterPostureTypes(3.1.0.160)... Done in 32 seconds.
- Data upgrade step 30/68, NetworkAccessUpgrade(3.1.0.231)... Done in 0 seconds.
- Data upgrade step 31/68, EADictionaryCreation(3.1.0.238)... Done in 0 seconds.
- Data upgrade step 32/68, RegisterPostureTypes(3.1.0.247)... Done in 0 seconds.
- Data upgrade step 33/68, SGTUPSParityFixer(3.1.0.249)... Done in 0 seconds.
- Data upgrade step 34/68, SgVnVlanUpgradeService(3.1.0.250)... Done in 0 seconds.
- Data upgrade step 35/68, SgaclUpgradeService(3.1.0.250)... Done in 2 seconds.
- Data upgrade step 36/68, AuthProfileUpgradeService(3.1.0.262)... Done in 3 seconds.
- Data upgrade step 37/68, GuestAccessUpgradeService(3.1.0.273)... Done in 1 seconds.
- Data upgrade step 38/68, DictionaryUpgradeRegistration(3.1.0.293)... Done in 59 seconds.
- Data upgrade step 39/68, RegisterPostureTypes(3.1.0.333)... Done in 0 seconds.
- Data upgrade step 40/68, NetworkAccessUpgrade(3.1.0.334)... Done in 0 seconds.
- Data upgrade step 41/68, ProfilerUpgradeService(3.1.0.337)... Done in 0 seconds.
- Data upgrade step 42/68, PostureSettings8905PortRegistration(3.1.0.374)... Done in 0 seconds.
- Data upgrade step 43/68, CertMgmtUpgradeService(3.1.0.379)... Done in 1 seconds.
- Data upgrade step 44/68, UPSUpgradeHandler(3.1.0.398)... Done in 2 seconds.
- Data upgrade step 45/68, GuestAccessUpgradeService(3.1.0.431)... Done in 1 seconds.
- Data upgrade step 46/68, NSFIdentityProviderConfigUpgradeService(3.1.0.449)... Done in 0 seconds.
- Data upgrade step 47/68, GuestAccessUpgradeService(3.1.0.451)... Done in 1 seconds.
- Data upgrade step 48/68, TelemetryUpgrade(3.1.0.477)... Done in 0 seconds.
- Data upgrade step 49/68, CertMgmtUpgradeService(3.1.0.490)... Done in 0 seconds.
- Data upgrade step 50/68, RegisterPostureTypes(3.1.0.491)... .....Done in 346 seconds.
- Data upgrade step 51/68, ProvisioningRegistrationNew(3.2.0.0)... Done in 0 seconds.
- Data upgrade step 52/68, NetworkAccessUpgrade(3.2.0.100)... Done in 2 seconds.
- Data upgrade step 53/68, PassiveIdAttributeRegistration(3.2.0.225)... Done in 0 seconds.
- Data upgrade step 54/68, RegisterPostureTypes(3.2.0.250)... Done in 0 seconds.
- Data upgrade step 55/68, FiveGUpgradeService(3.2.0.256)... Done in 5 seconds.
- Data upgrade step 56/68, EADictionaryCreation(3.2.0.300)... Done in 0 seconds.
- Data upgrade step 57/68, CdaRegistration(3.2.0.302)... Done in 0 seconds.
- Data upgrade step 58/68, GeneralMdmSettingsRegistration(3.2.0.308)... Done in 0 seconds.
- Data upgrade step 59/68, TelemetryUpgrade(3.2.0.311)... Done in 0 seconds.
- Data upgrade step 60/68, NSFUpgradeService(3.2.0.312)... Done in 15 seconds.
- Data upgrade step 61/68, GuestAccessUpgradeService(3.2.0.339)... Done in 0 seconds.
- Data upgrade step 62/68, RestIDStoreRegistration(3.2.0.464)... Done in 0 seconds.
- Data upgrade step 63/68, UPSUpgradeHandler(3.2.0.468)... Done in 2 seconds.
- Data upgrade step 64/68, NSFUpgradeService(3.2.0.542)... Done in 0 seconds.
- Data upgrade step 65/68, ProfilerUpgradeService(3.2.0.542)... Done in 0 seconds.
- Data upgrade step 66/68, GuestAccessUpgradeService(3.2.0.542)... Done in 8 seconds.
- Data upgrade step 67/68, UPSUpgradeHandler(3.2.0.542)... Done in 0 seconds.
- Data upgrade step 68/68, ESUpgradeService(3.2.0.542)... Done in 0 seconds.
- Successful

Running data upgrade for node specific data on cloned database
- Successful

Time estimate for upgrade
=========================
(Estimates are calculated based on size of config and mnt data only. Network latency between PAN and other nodes is not considered in calculating estimates)
Estimated time for each node (in mins):
ISENODE(STANDALONE):81

Final cleanup before exiting...

Application successfully installed
ISENODE/admin#

[Chris Terry]

My upgrade path involved restoring my config from my 2.7 p10 to new VMs on 3.2 p4. I actually just did that same exact thing for my test environment a couple of days ago. It should work just fine according to all documentation. You may try installing just 3.2 on the new VMs, restoring the config, and then patching to patch 4.

Was there an error given as to why the config restore failed on your new VMs?

[ajc]

First thing I noticed is that initial ISE 2.7 p7 configuration backup was 850 MB. Once I installed p10 on that version, the new configuration backup I created was only 350 MB. (500 MB missed). Then, from the 3.2 p4 VM I ran the config backup restore via CLI and one of the steps related to "transferring from repository" failed. I rebuilt the whole thing and starting from scratch, let's see what the ISE 2.7p10 config backup size gives me this time. I will keep you posted. 

UPDATE: my new ISE 2.7 p10 configuration backup process was completed and this time I have the right file size of 850+ MB. Before it was under 400 MB, I have no idea why that happened. Proceeding now with the direct restore of this config backup into my 3.2 p4 VM.

UPDATE2: Next the reason provided by ISE 3.2 p4 because the initial restore config backup failed (it was not a wrong encryption key).

UPDATE #3: Restoring my ISE 2.7 p10 directly into ISE 3.2 p4 VM worked,see next. I will check now enduser authentication.

ISENODE/admin#show restore status
%% Configuration restore status
%% ----------------------------
% backup name: ise2-7p10-bck-CFG10-231117-1427.tar.gpg
% repository: REPO
% start date: Fri Nov 17 15:07:41 EST 2023
% scheduled: no
% triggered from: Admin web UI
% host: ISENODE.domain
% status: restore ise2-7p10-bck-CFG10-231117-1427.tar.gpg from repository REPO: success

%% Operation restore status
%% ------------------------
% No data found. Try 'show restore history' or ISE operation audit report
ISENODE/admin#

[Chris Terry]

It sounds like it was successful this time? Did you have to do anything different for the restore to work?

[ajc]

Final UPDATE: Another bug

As expected there is an issue with the ISE 2.7 p10 config backup restore into 3.2 p4. I finally found the reason because FTP does not work after restoring my 2.7 p10 config backup into ISE 3.2 p4. THE FTP REPOSITORY configuration is messed up and it does not work anymore via GUI for ISE 3.2 p4.

The config backup restore process only puts back the localdisk repository and anything else is missed in the CLI show running output even though all the original 2.7 FTP repositories are still displayed via GUI. Removing those GUI FTP repositories and adding them back via does not solve the issue.

Creating new FTP repositories via GUI does not work. I repeated the FTP config backup process via CLI after adding another repository (that would not be added to the GUI list as per following output) and it worked.

ISENODE/admin(config-repository-testing1)#url ftp: //172.22.80.143/
% Warning: Repositories configured from CLI cannot be used from the ISE web
UI and are not replicated to other ISE nodes. If this repository is not
created in the ISE web UI, it will be deleted when ISE services restart.
ISENODE/admin(config-repository-testing1)#user testing password ?
Description: Configure repository password for access
Possible completions:
hash Specifies an ENCRYPTED (hashed) password will follow
plain Specifies an UNENCRYPTED plain text password will follow
ISENODE/admin(config-repository-testing1)#user testing password plain testing ?
Possible completions:
<cr>
ISENODE/admin(config-repository-testing1)#user testing password plain testing
ISENODE/admin(config-repository-testing1)#end
ISENODE/admin#show run
interface GigabitEthernet 0
ip address 10.10.10.12 255.255.255.0
ipv6 enable
ipv6 address autoconfig
!
!
repository localdisk
url disk: /
!
repository meraki (THIS REPOSITORY WAS ADDED VIA GUI AND THE FTP CONFIG BACKUP PROCESS FAILED)
url ftp: //10.10.10.143/
user meraki password hash **********
!
repository testing1 (THIS REPOSITORY WAS ADDED VIA CLI AS INDICATED AT THE BEGINNING OF THIS OUTPUT - WORKED)
url ftp: //10.10.10.143/
user testing password hash **********
!
ISENODE/admin#show repository testing1
6 [3706637]:[info] transfer: cars_xfer.c[329] [system]: ftp dir of repository testing1 requested
7 [3706637]:[debug] transfer: cars_xfer_util.c[2315] [system]: ftp get dir for repos testing1
7 [3706637]:[debug] transfer: cars_xfer_util.c[2328] [system]: initializing curl
7 [3706637]:[debug] transfer: cars_xfer_util.c[2340] [system]: full url is ftp://172.22.80.143/
7 [3706637]:[debug] transfer: cars_xfer_util.c[2214] [system]: initializing curl
7 [3706637]:[debug] transfer: cars_xfer_util.c[2228] [system]: full url is ftp://172.22.80.143/Defaultselfsignedservercerti.pem
7 [3706637]:[debug] transfer: cars_xfer_util.c[2248] [system]: res: 78
7 [3706637]:[debug] transfer: cars_xfer_util.c[2214] [system]: initializing curl
7 [3706637]:[debug] transfer: cars_xfer_util.c[2228] [system]: full url is ftp://172.22.80.143/Defaultselfsignedservercerti.pvk
7 [3706637]:[debug] transfer: cars_xfer_util.c[2248] [system]: res: 78
7 [3706637]:[debug] transfer: cars_xfer_util.c[2214] [system]: initializing curl
7 [3706637]:[debug] transfer: cars_xfer_util.c[2228] [system]: full url is ftp://172.22.80.143/Defaultselfsignedservercerti.zip
7 [3706637]:[debug] transfer: cars_xfer_util.c[2248] [system]: res: 78
Defaultselfsignedservercerti.pem
Defaultselfsignedservercerti.pvk
Defaultselfsignedservercerti.zip
7 [3706637]:[debug] transfer: cars_xfer.c[378] [system]: freed file list
ISENODE/admin#
ISENODE/admin#
ISENODE/admin#backup test10 repository testing1 ise-config encryption-key plain ABCD123admin
Warning: Do not use CTRL+C or close this terminal window until the backup is completed.
% Internal CA Store is not included in this backup. It is recommended to export it using "application configure ise" CLI command
% Creating backup with timestamped filename: test10-CFG10-231123-1300.tar.gpg
% backup in progress: Starting Backup...10% completed
% backup in progress: Validating ISE Node Role...15% completed
% backup in progress: Backing up ISE Configuration Data...20% completed
% backup in progress: Backing up ISE Indexing Engine Data...45% completed
% backup in progress: Backing up ISE Logs...50% completed
% backup in progress: Completing ISE Backup Staging...55% completed
% backup in progress: Backing up ADEOS configuration...55% completed
% backup in progress: Moving Backup file to the repository...75% completed
% backup in progress: Completing Backup...100% completed
ISENODE/admin#
ISENODE/admin#show repository testing1
Defaultselfsignedservercerti.pem
Defaultselfsignedservercerti.pvk
Defaultselfsignedservercerti.zip
test10-CFG10-231123-1300.tar.gpg (BACKUP SUCCESSFULLY TRANSFERRED TO THE FTP REMOTE REPOSITORY)
ISENODE/admin#

QUITE INTERESTING THAT MY CLI FTP CONFIG BACKUP RESULT IS DISPLAYED ON THE GUI EVEN THOUGH THAT REPOSITORY DOES NOT EXIST VIA GUI.

[ajc]

Hi Chris,

I had to rebuild the whole thing my ISE 2.7 p7 VM and ISE 3.2 p4 VM. Once that was completed, I restored my config backup from production into the ISE 2.7 p7 test VM, installed patch 10 then I ran a test for all SSID's. Once that SSID's test was completed, I created the configuration backup from my test ISE 2.7 p10 VM and restore it into the ISE 3.2 p4 test VM. Again, all the SSID's were tested on ISE 3.2p4 with no issues. BUT!!! my repository using FTP (not SFTP) does not work anymore on the "restored config backup" ISE 3.2p4.

Curiously, the same FTP repository that is configured on ISE 2.7 p10 works fine from there. What is the reason because the  ISE 3.2 p4 FTP repository does not work after the config backup was restored??? I have no idea.

I built another 3.2 p4 VM and I was able to create a config backup using the same FTP repository that works on ISE 2.7 p10 test VM.

Something interesting I noticed was that ONCE the configuration backup was restored into my ISE 3.2 p4 VM, the GUI presents all the repositories previously configured on ISE 2.7 P10 BUT when I checked for the same information via CLI, NOTHING except the "localdisk" repository is displayed. I suspect there is a BUG when you restore ISE 2.7 p10 into ISE 3.2 p4 where REPOSITORY configuration is NOT replicated properly into CLI config.

[Arne Bier]

The "upgrade" method chosen by many in the field, is to restore a config backup onto a new ISE VM.

The most common approach is to re-use the IP Addressing of the old ISE nodes, onto the new ISE nodes. This is especially the case with 2 node deployments, where PAN/MNT/Services run on those two nodes. Plus, you might have a lot of switches, Wireless Controllers, and firewall rules that all contain these two IPs.  Therefore, re-using the IP addressing of the existing ISE nodes has operational advantages.

So, let's say you have a two-node setup, and you want to run ISE 3.2 then you deploy a new ISE 3.2 VM (using the OVA or ISO). When the VM has installed and is sitting at the 'setup' login prompt, then you must de-register your old Secondary node - this separates it from the Primary - Primary is now alone. You can then shut down the Secondary VM. Now run the setup on the new VM and enter all the details relating to the Secondary node.  Let the build complete. Add a repo, restore the config backup. Install certs, join AD, etc and make the node Primary. Apply latest patch. 

For the remaining old ISE node, shut it down and power off the VM. Then build a new VM using the Primary's IP details - install same patch as used on the other node. Install certs. Then register this node to the new Primary.  Join AD. Finally, if you have a specific preference about which node is the Primary, you may need to promote the Secondary to become your new Primary. This will however restart processes on both nodes. One of the "issues" of having a two node deployment is that this PAN promotion impacts Services.