Migration question - old and new Unity in the same Exchange 5.5 environment
Customer is upgrading their Unity from an AV version 2.43. That box is old enough that all new s/w and h/w will be brought in. They have asked about phasing the old box out over time and my question stems from this: In an Exchange 5.5 environment, can they shrink/grow an old Unity to a new one over time with both the old and new Unity pointing to the same message store/hidden attributes for users? Any process recommendations to follow here if so (if delete a user from the old system before bringing up their new box, how to deal with hidden attributes already present, etc.) Or, do they need to cut the old box off and bring up the new one to enable a functional system? Other pieces I'm missing?
Re: Migration question - old and new Unity in the same Exchange
A Unity 4.0 (or 3.1 for that matter) can live in the same Exchange 5.5 environment as a 2.4 box (there is no 2.4.3 did you mean 2.3.4? We went from 2.4.0 to 2.4.5 to 2.4.6 ).
While the 2.x system writes a bunch more data to the directory than 3.x/4.x systems do, they do both agree on the tags that means a subscriber is currently owned by another Unity box and will respect that. So if you deleted a user out of the 2.x system you could then import them into the 3.x/4.x system no problem.
This is a very awkward migration strategy, however, in that you will lose all the users greetings, voice name, mailbox settings and all that further, and more problematic, the users on the 2.x system wont be able to easily message to users on the 3.x/4.x box and vice versa 2.3 didnt have networking at all.
If it were me, Id install a clean 3.x/4.x system into the environment and do a fullDBExport of the 2.x system and import it all in one shot this is going to be _much_ cleaner and easier for everyone involve than doing a slow bleed migration across systems.
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...