I have an existing Unity server, VM only with Exchange 2k local as Message Store, in an AD network, hosting 3 remote CCM's for voice-mail. I will be swapping out the hardware completely to a new server (an MCS 7837), and I want to ensure that the migration occurs with minimal downtime or hiccups. After much thought I decided to use the client's backup program (UltraBac ... I know, it's not on the list, but it works well with SQL) to do a full, system-state backup of the old server. In the meantime, I would apply the WinOS to the new server, give him an IP address and hook em up, but NOT bring him into the domain or install any software. Once I had a few successful backups, I would do a complete restore of Unity/Exchange on the new system, reboot after unplugging the old system from the network, then apply the dongle, double-check licensing, and then test.
The old server will stay available for a hot restore if there are lasting problems with the new one. This way, we will only lose maybe a few saved voice-mails, but nothing more.
What are the holes, if any, in this idea? What has anyone else done in this scenario? and what would you suggest? My goals for the client are typical:
- mimimize down-time
- limit off-hours work, reducing the charge on my eventual bill
First, I'm assuming Unity with Exchange on the same server here is just acting as the message store... these are AD records used by the corporate directory that are mail enable on to provide voice mail services, right? In other words you don't also have desktop client issues to deal with here, this is a VM only config...
Will you be instaling the box with the same server name as the old one?
this can work but can be tricky, the Exchange restore can be dicey in this situation in particular. It can be done this way, though.
You can take a somewhat different approach I think that might work out a little smoother and have less down time.
Install a new Unity server on your new platform with it's own server name and attatch it to the network - the whole shootin' match. Both Unity servers would then be up and in the diretory at the same time - not a problem. When you're ready to do the move, do a DiRT backup including messages of the old box and then remove it from the network. Do the DiRT restore on the new box and it'll automatically hook up to the accounts in the corporate AD directory and rebuild the messages on the local Exchange box. While messages are being restored, Unity is brought back up so your total downtime here is minimal.
Once Unity is up and running again and while the message restore is under way you can cut the lines over on the switch and you're live.
You might want to check out the DiRT documentation and training videos available out on AnswerMonkey.net here:
I'll be posting updated versions of both the Backup and Restore portions of DiRT here in the next few days once QA is done regression testing it - you might want to hang tight till Thursday or so when I get the updated versions posted for this.
what about the dongle? also, should I concern myself with the Exchange install? that is the part that is bugging me, that Exchange will be brought into the AD, just like the server itself ... will DiRT handle that as well?
I have the new server with the OS on it now, same name as the old Unity server (Unity2 ... clever, huh?) ... no Unity or Exchange installed yet ... you suggest doing a full install after renaming the server (call it Unity3) of both Unity and Exchange2000? what will the effect be on AD in the domain? I can perform these tasks and let things sit until Thurs no prob, then DL the new DiRT and deploy accordingly ... please respond with alacrity, s'il vous plait ... and thanx!
You can move the dongle and the Unity server you moved it from will still continue to operate OK for a while, no worries there.
You need to install Exchange - you have to have the new Unity server up and running before you do the DiRT restore. Check out the DiRT home page link I sent you. There's good documentation there and a few training videos that should give you all the details you need for how this works...
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...