I have a client who migrated from one Unity 5.0 server to another. Both are VMO with on-box Exchange 2003, however they share the same AD. We used DiRT for the migration, and everything "appeared" to be successful for the first full day after the migration. All external and internal callers could leave VM messages, and the subscribers could retrieve them. However, the second day after the migration, the users could only retrieve VMs from internal callers. We eventually found out the mailstore attribute in AD still contained the old server message store I thought DiRT would change this attribute during restore? I'm trying to confirm this but the documentation I can find only says it changes the Unity attributes with no specific mention of the mail store.
We ended up migrating the Exchange mailboxes from the old server to the new.
So, my first thought is to ask what the build/validation process of the new Unity 5x server was. Did you happen to get the system up and running (including mailstore integration) and then test on some test accounts from the Unity subscriber OU's BEFORE running the DiRT restore? I ask because, according to DiRT, you can restore a Unity backup on a system configured with a different back end connection so long as it’s Exchange based. Specifically, you can backup a system running with Exchange 5.5 on box and restore the backup information onto a clean install of the same version of Unity that’s connected to Exchange 2000/2003/2007 server off box. Any combination of 55/2K/2003/2007 and on/off box should work fine. However, DiRT has no way to know if the new mail store is actually online and working or not. If there are issues there, there can be problems with the DiRT restore.
Can you give me a little more background on the actual build/restore process?
The new Unity 5.0 was built and fully tested prior to the migration. Mailstore integration as well as integration with CUCM was completed, and we created a couple test accounts in the Unity subscriber OU. Test VM's, MWI, etc was all good.
A day after the migration when the issue came to light I found out the client upgraded one of their AD servers from 2003 to 2008. They said any backups used for the AD upgrade were taken after the Unity migration.
Here's a timeline of the events:
- DiRT backup of old Unity (cvm1) and restore on new Unity box (cvm2)
- Configured CUCM VM pilot / hunt group to point to cvm2
- Shut down Unity on cvm1
- Tested successfully from outside and inside calls
Thursday all day
- no issue reported. All external and internal VM's were working. Subscribers were able to retrieve VM's from outside and inside callers
- Received call that external VM's were getting "lost". Callers hear the greeting and were prompted to leave a VM, but subscribers couldn't retrieve them. Internal VM's were fine, only VM's from external callers were effected
- Client shut down old cvm1 server. Now subscribers can't retreive any messages, internal or external.
- Discovered AD mailstore attribute for subscribers still showed "cvm1". Opened TAC case and eventually migrated the mailstores from cvm1 to cvm2
From what I gather, either the AD server upgrade somehow reverted this attribute back to cvm1, or the DiRT utility never changed it.
Hmm, I'd be suspicious of the timeline but that's going down a path you'd probably rather or possibly should avoid. It's going to be hard to prove anything one way or the other when it comes to what was/was not in the AD backup. I don't get into a lot of DiRT backup/restores. Personally, I prefer COBRAS these days but you went about things in what would appear to be the right order. The documentation for DiRT pretty clearly states you can move between mailstores and the utility wil take care of remapping things for you.
I guess the question would be: how much do you want to pursue this?
Also, for operational purposes - what ES are you running? I assume you are running an ES of Unity that support AD 2008? If not, that could cause an issue as well.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...