What you want to avoid is Unity servicing mailboxes across the link. For example, if you have site a and site b, the Unity server is site b should not service any mailboxes homed on an exchange server in site a. As long as you adhere to that you should be fine. Check out http://www.cisco.com/cgi-bin/bugtool/onebug.pl?bugid=CSCea68581 for more information.
All of the networking data is replicated through the directory and cached locally to SQL so link speed really isn't an issue for Digital Networking.
Can you explain what you are trying to do with failover here? It is not supported for failover partners to be separated via a WAN link...
Thanks for your reply. The first paragraph clarifies a whole lot of issues. Well, site B is the disaster recovery (DR) site to site A. Thus the idea has always been to replicate services to the DR site from site A and Unity is to be no exception.
However, exchange is not clustered in this scenario over the WAN which in effect makes failover for Unity even more unthinkable.
So, going by segregating the site mailboxes what happens when site A completely dies? What are the options given all backups are available?
I should start by saying that failover was not designed for disaster recovery purposes. It was designed to handle a Unity application failover and nothing more. Since it was designed with that intention only, it was assumed that the Unity servers would be connected to the same 100mbps switch. Low bandwidth situations and WAN links were never considered.
So, if site A died the Unity in site B will run in UMR mode until site A is back online. What you need to be concerned with is what happens if CallManager in site A fails or the Unity server in site A fails. That could get tricky.
Your best bet is to have a Unity server already built (no failover) in the DR location and to do regular backups with DiRT and store them at the DR location as well. If site A goes down for an extended period you can restore from DiRT and contact Cisco to have them move your license to the new MAC address.
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...
[toc:faq]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 discusse...