Migrate to new ISE Server

[DAVID]

Forgive me if this seems a bit unorthodox but I am forced to migrate to a new ISE server while still maintaining the production ISE. Explanation is too long for this post.  Anyway, what I am wanting to do is simply take those devices and policies that have no user impact such as our printers that are being profiled and have those devices now to be profiled by a new ISE server.  Once I have all the printers profiled by the new ISE server I can then continue with the other low impact devices and then I finally move those policies that deal with users. 

Is this even possible? To control which ISE server a device is profiled on?  I have discovered that I am seeing some vmware machines being profiled that I did not expect to. Essentially, I want to be able to see that my own workstation and IP phone show up as profiled devices on the new ISE server.  The port that my workstation is connected on is configured as open access to allow the device access to the network without any restrictions as we are just monitoring the devices first.  Once all the devices are  profiled on new server then we can worry about posturing and remediation.

[kvenkata1]

Since this is a production network migration, please reach out to TAC. They will be able to guide you.

- Krish

[DAVID]

I did but the engineer seemed to interpret my situation as that I was trying to authenticate to the printer or that I wanted the printer to authenticate to the network. Neither of these are correct. Does my question even make sense with what I am trying to accomplish? All I am trying to do is to profile printers to a different ISe server

[paul]

Is your old ISE environment completely messed up and you are trying to get a fresh start?  If not then why don't you restore your old ISE environment to the new ISE servers, clean up what you want and then start pointing devices at the new ISE environment?  If something goes wrong you can just point the devices back at the old environment.

If you want the new ISE environment to start profiling without restoring the old environment to it, just load in the network devices and enable ISE with SNMP polling it will start learning the devices attached to your switches and start to profile them.  You won't get device sensor data and you won't get DHCP data unless you add the new ISE PSNs to your DHCP forwarding list (if you are using that for the old deployment).

[DAVID]

The production ISE servers are fine but mgmt is scared to take the chance of something going wrong with the upgrade process from 2.0 to 2.4 and the database conversion process so I am forced to go another route. I have already got some devices being profiled by the new ISE server. What I am after is being able to control those devices that are being profiled in one ISE server to be migrated to the new ISE server to be profiled such as the printers. I am trying to basically migrate the least user impacting since printers are only being profiled and not under any posturing. The catch is on the 6800 I have the snmp strings for both the current ISE server and new ISE server i hopes that I can be able to control based on the SNMP string and device profile which ISE server the device is profiled on. I am not at this time configuring any devices in the new ISE server for radius authentication as that will come after I know that all the devices like printers, iphones, cameras, workstations, etc are now being profiled. Then I can run a script on the branch routers and switches and simply point them to the new ISE servers IP address. Then finally change the radius auth for the WLANs and then change the ASA to point to the new ISE servers for user auth for vpn access.

[paul · Accepted solution]

What you are trying to do is a standard upgrade practice that I have done many times. Forget the migrating printers and such, just build a parallel 2.4 deployment, restore you 2.0 data to it, validate everything looks good, point some test devices at it to test the rule set, rehome your licenses and then cut over your production devices. It is a pretty fool proof method for doing the upgrade.

[DAVID]

My problem with that is our current ISE deployment has morphed from three different admins. Each tasked with trying some new feature that the company never ended using. 90% of ISE is used for radius authentication so there are a lot of conditions, results and policies that aren't even used. So while our current ise is doing the job mgmt has decided to just start all over again. Personally I reluctantly agree as the current ise policies are a bit granular.

[paul]

This is also quite common. Over the years ISE installs tend to get bloated or the tribal knowledge about why certain things were done certain ways is lost.



You can still do the restore method and then work on cleaning up the policy sets.



Personally, I would do a complete fresh rebuild, but not sure how familiar you are with ISE. If you are very familiar with ISE you can rebuild any deployment from scratch pretty quickly. You can export/import profiles, NDGs, network devices, static endpoint assignments, etc. from the old deployment to the new deployment. When you export from the old deployment you can make manipulations to the CSVs to update any naming conventions if you want before importing them into the new deployment.



If you are not absolutely solid on how to do the manual rebuild then the restore is the way to go. That way you know you aren't going to miss anything. Then your efforts are focused solely on clean-up.

[Damien Miller]

One other nice benifit of doing a policy clean up following the upgrade to 2.4 is that you will have hit counters on the policy sets. Quickly shows you what's heavily used vs light, and not at all.

[Steven Williams]

I am doing this now, but the issue is I need to keep the same DNS name and IP for the two new ISE nodes I am building. Its not very feasible to reconfigure 100's of devices and other authentication pointers to new IP addresses and new DNS names. How can I achieve this?

[paul]

I have migrated 1000s of NADs to new ISE IPs/DNS names. That is my normal upgrade process when doing major version jumps. Building a parallel environment with new IPs/DNS names is the safest way to do the migration and allows you the easiest failback scenario.

[Steven Williams]

Ya I think you are correct in that method. otherwise could potentially lead to me being locked out of devices, and authentication failures for users. Wait till all things are migrated over and then turn the old ones off.

[Steven Williams]

I attempted to restore the new ISE node and it restored it with the IP address of the current production node. Do we not include the restore of the OS when we do the restore?

[paul · Accepted solution]

You should be just restoring the configuration backup that you took from the GUI. I have done many restores from that backup and never had it change the IP on the system I am restoring to.

[MaheshPandey60919]

Hi Paul,

Need your help to know if we are building a new infra in VM and do a backup restore from existing Infra i.e. on ISE 2.2.

IP's and hostnames are changing for all the nodes in new infra. Once new infra is build and all the existing services will be migrated, current setup will be decommissioned.