Need someone to tell me the best way to proceed....we have a unity server that is currently 4.0(2), VM only, running as also the exchange/domain controller. We want to move to failover using unity but the first step is to seperate exchange/unity. We must be able to create a new (or same if needed) domain / unity installation WITHOUT taking down the existing server. Any suggestion about backup/reformat the existing server is not acceptable (at this time - it will be done, just not now) The idea is that our cut-over to the new setup should be seamless to the end users, we want to preserve the existing unity configuration, greetings, call handlers, user messages (if possible). What is the best way to do this? Will DIRT handle this? I'm assuming that the new DC and new unity server will have to be on a different network since they would have the same names (dc/mailstore/computer etc) and that would create conflicts. Is there anyone that has a better suggestion? Will DIRT create the user accounts in the new DC during a restore? Should everything (computer names/dc/mailstore/accounts) be exactly the same? What about SID issues (I don't think so, but the question was raised by someone)? Also, moving just unity off the existing server is NOT an option either - again, that server must stay online. We have two other servers to use for this.
you will first have to build the new exchange server/AD environment. then you will perform an Exchange upgrade in essense, to the newly built exchange box.
new exchange box should be in same AD domain.
cannot decommision the existing partner exchange server until you have completed the exchange upgrade to the new box. (there are 3 specific sections to complete before you can decommision, as outlined in link below)
after this is done, then you can build the failover unity.
I disagree. That won't work. In the same tech note link that was provided in the section titled "Adding Failover to the Cisco Unity System When Exchange Is Already on a Separate Server" is this statement:
"If Cisco Unity and Exchange are currently on the same server and the server is a DC/GC, you must reinstall all software Because the Cisco Unity server cannot be a DC/GC in a failover configuration, and because demoting a Cisco Unity server to a member server is not supported."
Your assuming that your moving the GC/DC along with exchange - if not, failover won't work, Unity can't be a DC with failover.
This is exactly my situation as I stated before. The existing unity server in question is the DC/GC with exchange and Unity 4.0(2).
I get the part about a new exchange/AD environment. So, my next question is: Is DIRT affected if I change the COMPUTER name of the GC/DC server? The domain/exchange mailstore name would be the same.
Example, I have a server named "VMSERVER1" that has AD/Exchange/Unity on it. I use DIRT to backup the system to seperate Unity.
I rebuild the AD/Exchange to new server and rebuild Unity to a different server. I would like to keep the name "VMSERVER1" for the Unity server and create a new server name for the GC/DC - can I do this?
I just went through the same process last Saturday and all went smoothly, the migration was seamless to users with no issues.
I have a similar setup as yours going from a single Unity server with Exchange 2k on box to three servers (with Exchange 2k off box plus Unity primary and Unity secondary).
I was able to separate Unity from Exchange and keep Exchange on the existing server as the message store.
There are lot of steps involve but you can pre-install Unity on the new box it will not conflict with your production Unity box and make sure you thoroughly understand all procedures before you pull the trigger.
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...