Re: What's the best practice for CM Disaster recovery
Untested, but here are some ideas:
Use BARS on the CallManager and DiRT on the Unity server to back up directly to shares on the CallManager and Unity servers at the DR site, every night. The CallManager and Unity servers at the DR site should be installed with the same versions of software at the main site, but left totally unconfigured other than that.
When you need to invoke your DR plan, it's as simple as running the restore process on those servers, using the backup files that are already stored on each server from your automatic scheduled backups. This only takes a few minutes per server. This takes care of Unity completely, but the CallManager would need more work.
The CallManager will get configured with the MAC addresses of the old phones which are presumably still at the host site, but unless you already know where everyone's going to sit at the DR site, you are probably going to have to have a process anyway where you manually change the MAC address on phone profiles to match phones you have at the DR site. Alternately, you could install Extended Services and TAPS, and relax the TAPS security option while you're getting your DR site set up so you can register the new phones on top of your "already configured" phone profiles in CallManager. Another alternative is to go ahead and fully configure new phone profiles for the DR-site phone MAC addresses in your production CallManager, such that they share all their lines with the user's "real" phone. The DR-site phone profile will normally sit there unregistered, but when you restore at the DR site, the DR phone will register and the "real" phone will sit unregistered.
If you don't have the same gateway hardware, you'll have to configure CallManager for that new gateway after the restore. Again you could pre-configure that gateway in your production CallManager, and with creative use of route lists and so forth, you could get calls to automatically use that gateway after restore and deal with any local calling-area changes.
Any DR site recovery procedure is going to be complicated. I don't know if you're just trying to operate the DR site, or if you intend to operate your other remote sites off this DR site CallManager. There are more things you have to do, this is just an overview of one possible method. You might experiment with it and see if it meets your needs. It would benefit you to order your DR site servers with RAID and with an extra RAID drive to sit on the side, so you always have a "clean" just-installed image you can revert to after restores and experimentation.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...