Migrating to new cluster & new hardware/vm

[sharon1shaw]

We currently have a couple of EOL Cisco UCS C210 M2 chassis, running CUCM 10.5.1 (on ESX( 5.1.0) and have purchased 2 x Cisco UCS C240 M4SX which we want to run CUCM 11.0  (on ESX( 5.5.0)

The company is carrying out a departmental re-org, in which the Cisco UC side will be built on new domain, new MS AD integration etc. So I just wanted some advice.  We were thinking of either a) upgrading the old pub/subs to 11.00 and moving them to new UCS, but then still have the new AD/Domain config to think about, or b) (preferred) build new pub/subs on new vm onto new UCS's.  This is so that we can do a cleanup of old configs, integrate with new domain and AD etc.

So my question is, has anyone done anything similar and could Cisco Prime be used for any of the above? Or does anyone have a better suggestion on how we can accomplish our tasks? We would like to think about the least impacting solution for users. We currently only have around 950 phones and users registered to our cluster.

thanks in advance! 

[Jaime Valencia · Accepted solution]

Either option is acceptable, changing the domain is not that big of a deal, do bear in mind that it will cause certs to be re-generated.

If you wish to clean up your config, the other option is the way to go.

Probably the least dis-ruptive way would be to do a fresh install on your new server, work with that on the lab, and then do a cutover. Remember that you'll need to enable the prepare cluster for rollback parameter to avoid ITL problems if you do that.

[sharon1shaw]

Thanks for the comments Jaime. I think we are definitely looking to go option b). Can we use Cisco Prime Collaboration Provisioning to migrate from old vm's to new 11.0 vm's?

[Deepak Rawat]

Yes you can definitely use PCD for this purpose.

Regards

Deepak

[heathrw]

I did a 8.6 to 10.6 migration using PCD and new IP addressing. Ran it a a lot of problems with PCD, hopefully you won't migrating from a later version of UCM. Here were some of my key take aways.

• Build a dedicated PLM server, get your licensing migrated and ready to go
• Only migrate the Publisher, build the new subscribers from scratch, its way more faster and I think a cleaner way
• Disable extension mobility services when PCD is extracting information from existing cluster
• Ensure the phone firmware on the old and new clusters match, speeds up phone cut overs
• As per Jamie stated that to Rollback to pre 8.0 parameter is set on the old cluster (only needs to be done for moving phones to new cluster not for data extraction), reboot the phones several times, and do random phone checks to ensure the ITL certs have cleared. keep in mind the EM wont work with this enabled.
• Find any other phones that were once registered to the UCM sitting in cupboards, store rooms, etc connect them also, so the ITL certs clear.
• Have all your voice gateway configs ready, add your new dial-peers put them in shutdown then swap them out. If you have MGCP and use DNS for the new cluster routers will need DNS servers or static DNS entries for the CUCM servers

I did have to raise a TAC case to get this working, TAC found some odd stuff in the DB which some SQL commands to clean up a few records.

[sharon1shaw]

Thanks for sharing the information heathrw, much appreciated.

[shaneblackwell]

Hi Sharon,

We have gone through something similar at my work, going from version 8.6 to version 10.5 from old to new tin built in parallel on new IP / host names.

A few things to think about / be aware of when changing hardware (which was our route as well)

• An obvious one is if the servers are being built in parallel from scratch ensure theres no conflicts with IP and hostnames - this however will be slightly tricker if you plan to restore the DB then make the changes for house keeping afterwards as the new servers will need to be off the main network until the IP and host servers are changed
• when upgrading to a newer version of CUCM the firmware on all the phones need to be upgraded, some model phones need a mid-step version to get it to the latest
• IP phones will need the CTL clearing out manually unless you migrate the certificates on the new CUCM from the previous version - this was a solution we used and thankfully worked as we didn't fancy clearing files and resetting over 700 phones manually
• You'll need to know all the security passwords to be able to restore the database / backups on the new version, a key one that tripped us up was the security password for the informix database which meant we had to rebuild the IM&P from scratch - if you are doing this completely from scratch then it wont be an issue but you will need to keep those passwords going forward
• When changing the TFTP (option 150) address (along with any other new records for the new domain) on the DHCP server you'll need to ensure all devices are reset to get the new settings, those remote users or people with manual settings will be a pain and will cause some calls into the support team - so its important your support team know what to do to update the settings.  We had a number of issues with Jabber users and had to ensure the DNS SRV record was updated and the previous server was set at a lower preference whilst migrating (in case of a rollback

Thats about all I can think of for now, I wish you all the best.

[sharon1shaw]

Hi Shane, many thanks for all the information above. It has been very helpful in regarding to planning out the migration/upgrade. The last upgrade for me was a 7.0 to 8.5, but this project has a bit more to it, so it was good to have some checks and balances based on your experience. We aren't looking at restoring from backup, but would like to migrate using PCD. It looks pretty straightforward, so be interesting to see what happens when we test in the lab. Thanks again for all the info. Cheers Sharon

[jeremiah88]

Good suggestions all.  I would say/add however, that if you are going to rebuild the systems anyways, I would not worry about PCD.  PCD has been one of those tools that I still find buggy and when I am doing what amounts to a new setup, I would go a different way.  

In your situation in addition to some of the already great suggestions from Shane and Jaime, I'd add that this is a great opportunity to update your dial-plan to take advantage of 11.X design.  With the new "Named Local Route Groups" that can be applied at the Device Pool level, and with many other enhancements you can now deploy simple line-based class of service and no longer have to worry as much about the Line/Device approach, which results in a simpler dial-plan and better scalability.  So, Not using PCD, I would build a new CUCM cluster and start from scratch by deploying a great dial plan, then using BAT to import the phones with the updated parameters to support for global +E164.  Basically your dial plan should be such that you globalize on ingress and localize on egress and use the newer "transformation patterns" concept to keep the user experience visually, pretty much the same, although functionally, way better.  

By deploying a great dial-plan design it makes everything easier down the road like Click to Call from applications and Jabber and SIP URI dialing and later dialing using MRA and Expressways and CMR and on and on...  Using the mid-market or Enterprise Cisco Validated Design Guides for guidance is always a great resource: http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/collbcvd.pdf

For AD/LDAP, you should design your synchronization agreements around your ultimate provisioning goals.  For example, if you have Site A and Site B, you would configure 2 different agreements complete with site templates for self-provisioning, and a mask applied so that when the +E164 formatted telephone field parameter in AD is filled, and the UC system syncs with AD, the user and line is auto-created and you can have users self-provision their phones.  Basically, you give them any phone, they plug it in, and can be presented with step by steps instructions to enter their AD creds, and voila the phone/User/Line is automagically created in CUCM.  It's called Self-Provisioning and it makes deploying phones very seamless and easy.  You can do this without Prime Collaboration Provisioning server, or you can always run that as well.

For Unity Connection use the COBRAS Import/Export tool to transfer the data between the systems.

[sharon1shaw]

Thanks Jeremiah, some great information and tips. Currently doing an audit on our system and it's opening up a 'can of worms'. A review and overhaul of our Dial Plan seems to also be one of the tasks that will be added to our migration/deployment list. Thanks again.