I recently performed a Cisco Prime Infrastructure migration from 2.1.2 to 2.2 so here’s my 2 cents on why you may need it and what issues I encountered.
For some it’s a habit to upgrade to the latest and greatest. Historically the stability and performance of CPI have also been questionable so upgrading whenever possible was the only way to get through the plethora of bugs. I had gone with this up until 2.1.2 but could go no further without the big effort to go over to a fresh VM install.
I wanted to take advantage of the individual FlexConnect Group VLAN Mappings feature made available in code 126.96.36.199 and although CPI 2.1.2 supports code 8.0.x there is no support for the new features that come with the code. The ability to configure individual VLAN mappings via AP Templates was key for a particular project so that was the decision maker. I found this info under the very useful compatibility matrix that is always within easy reach on my favourites menu.
As usual, Rasika’s instructions came in very useful but I ended up having to change a few things which will be outlined below.
The CPI 2.2 Quick Start Guide includes notes on hardware required and upgrade path etc so sort out which patch or ova file you’ll need and then, if it isn’t you, talk to your server guys about available resources. Once the OVA has been deployed that’s the easy part over and you’re ready to configure.
Change in plans
After previous experiences with data migrations and new installs failing I really wasn’t overly comfortable with the approach of backup -> decommission -> restore and hope the data will restored with no issues. So that meant a side-by-side install which is fine but requires available server resources being allocated to the 2nd server whilst the 1st server is still chewing up its own. Thankfully I had enough available for a temporary side-by-side. In my opinion if you have dedicated time for this work then 2-3 days is all that is required to perform the work and be happy that the old server can be decommissioned but that is subjective!
Our server guys didn’t believe I needed the resources listed and under-specced the new VM. I didn’t notice this until the application restore stage where it failed due to a difference in spec. That lost me quite a few hours so make sure the specs are, at minimum, the same as your original server’s.
With a side-by-side install I had to name the VM differently although I suspect it doesn’t matter as you tell Prime what the server is called during the setup stage and I ended up calling it ‘cpi2’. Regardless, this meant my base license wouldn’t work/recognise the new server and would require re-hosting via the Cisco License Portal. You’ll need to have your support contract linked for this and in the end, after attempting every combination under the sun from the instructions, I had to get TAC to do it for me. Sigh!
Data migration was a big fail. After performing a full application and database backup/restore – which took quite a few hours – Prime restarted with zero data / settings in place. Although a bit off-putting it wasn’t too hard to manually export and import the data myself and provided an opportunity to trim some unnecessary devices. The devices were easy – export and import the whole DB in one go and then watch it
Incorrect Imported Map Sizes
This was noticed by a stroke of luck otherwise there could have been some interesting consequences. Like all sensible people we use the metric system which is easy (now) to change from the default of feet in CPI. What I didn’t realise is regardless of what measurement you have selected, the maps will export in feet and if you then import into a new version of CPI which uses meters it will use that same number and blow out your maps to 3 times the size. From what I can tell this cannot be rectified without re-creating each map which was a horrific task to contemplate when you have 200+ maps. To export large numbers of maps I recommend exporting in groups of 50 or so as there is a lot of data and CPI sometimes doesn’t like exporting that much. Additionally, make sure all your devices have been imported and are active before importing the maps otherwise they won’t appear on there.
I can’t find the helpful post from the Cisco Wireless Forum but it saved me a lot of work should I have decommissioned my old server without checking the maps.
Prepare well – check the compatibility matrix, plan what hardware you’ll need and make sure it’s to the right spec. Thoroughly check your device counts match up from old to new and make sure those damn maps are accurate. Good luck!