The contents within this document are for rebuilding a CUCM 9.X server if an existing CUCM is corrupt or has problems related to the CAR database.
As a UC engineer for the last few years and being a tech from 05-11 I have come across many things that an engineer should know when presented with problems. Last night I had to completely rebuild a CUCM from scratch and push the backup file. Normally, a from scratch install is easy but setting it up to be rebuilt based on the previous configuration requires a bit more finesse.
The very first thing that you need to do is reconnaissance. Since you are rebuilding a publisher or subscriber there is some key information that needs to be present.
- IP Address of the CUCM
- Subnet Mask
- Default Gateway
- NTP Server (The EXACT same one you were using)
The above need to match what you originally were using on the corrupted or busted CUCM. I found this out the hard way when I had input another NTP server temporarily since I was just going to restore the node using the .tar file created. A few other things also need to be in order that are asked for at the install.
- Organization
- Unit
- Location
- State
- Country
These items can be found in the certificate of the CUCM and assuming you have a subscriber, you could check that certificate as well if you really wanted to. Just be sure to change the host name and other information accordingly. Next, the version needs to be the exact same as the version that is currently experiencing issues. You cannot restore a CUCM on a different release than what was backed up.
The rebuild should be done using the provided OVF template from Cisco as this makes life much easier when rebuilding since the settings are already per-configured and you eliminate human error. Additionally, I highly recommend leaving the original CUCM VM that was corrupt/faulty available until you have fully established your new restore has synchronized and has a fully replicated database. Ensure that the old CUCM VM is shutdown and is not set to auto-start within vSphere. In fact, while you are at it, make sure the new VM is set to auto-start.
One thing to note is that you should stop auto-replication on the subscriber if you are restoring the publisher just to prevent any possible issues. Always backup your CUCM without CDR/CAR unless for some reason you really need that information. This will help prevent copying the problem I personally had to the new rebuild.
Once the rebuild is complete, verify that the database is stable and ensure replication is starting. You may need to go back to the subscriber if you stopped it earlier to ensure it is correctly copying across. You should see a replication status of "2" if everything went well. I always go in and check a few items such as phones, route patterns, and device pools just for comfort. Once this is complete, you should have a fully functional cluster again.
***Note: To ensure accuracy of this document, if anyone spots errors please let me know so that I can correct them. This was the first time I had to restore a publisher that had the CAR DB failing. I've done plenty of installs in the past but never a restore of the publisher itself.
