[cisco-voip] Migrate Subscriber Data issue in Unity

[James Buchanan]

Hello again,

 

I think we may have found it.

 

The Unity server was pointing to an invalid DC and GC. We did not know
this because generally the customer did not change the backend AD user
for VM-only users when changing the VM box. So, AD changes were really
infrequent-until yesterday. 

 

We fixed the GC/DC issue using the reconnect tool. However, we did not
force it to do a full sync. It would have done one on its own, but we
did not give it enough time to complete one. So, when we rebooted, the
changes were lost (unless of course it had already given up, in which
case they were lost anyway). 

 

So, the rule of thumb would be to look in the log for Migrate Subscriber
Data and make sure you have no errors. We saw an error -2143027020 (or
something like that) repeat a lot during the process that resulted in
the failure. This appears to be the error that got the ball rolling. 

 

Thanks,

 

James

 

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of James Buchanan
Sent: Thursday, April 15, 2010 8:42 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Migrate Subscriber Data issue in Unity

 

Hello,

 

At a customer, they ran Migrate Subscriber Data to migrate 110 Unity
4.0(5) users from VM only to Unified Messaging. The process showed as
having run successfully. However, after exiting the tool and allowing
the Directory Synchronization to finish, messages still were not
delivering to the correct places consistently. We eventually decided to
reboot the server in case there was a MAPI cache issue due to the change
of the Information Store for the user accounts as well.

 

Upon doing the reboot, 75 of these 110 accounts were deleted from Unity.
The stream files, user, all of it. The AD user still existed as well as
the messages in Exchange (though they had not migrated). Basically, MSD
lied about doing the migration properly. 

 

Unity is 4.0(5), no ESes that I'm aware of. 

 

Has anyone seen this behavior before?

 

Thanks,

 

James

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100416/1338ac10/attachment.html>