“Failed while updating destination pool.” error message when moving user from OCS 2007 R2 pool to Lync Server 2010 pool – user is a part of Enterprise Admin and Domain Admin group

This has been a part of the “to blog” list for sometime so I just wanted to make a quick note about the following problem:

You have your new Lync Server 2010 pool set up and would like to move some pilot users over for testing.  Naturally, you’ll probably use your own account which just so happen to have Enterprise or Domain Administrator privileges and when you try to use the GUI to move your account, you get the following error:

Failed while updating destination pool.

I ran into this problem sometime in December 2010 and never really did a whole lot of searching as to why because when I failed to use the GUI to move myself, I simply went ahead and used the cmdlet and it worked:

PS C:\Users\tluk> move-cslegacyuser -identity "sip:tluk@domain.com" -target "

ocspool3.domain.com"

Confirm

Are you sure you want to perform this action?

Performing operation "Move-CsLegacyUser" on Target "CN=Terence Luk,OU=System

Consultants,OU=Some OU,OU=Employees,DC=domain,DC=com".

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help

(default is "Y"):y

PS C:\Users\tluk>

I also noticed that this only happened with accounts that were a part of the Enterprise or Domain administrators group and because I always had problems with these accounts in the OCS 2007 R2 days (ever tried modifying settings of an account that is or used to be a domain administrator before with an account that doesn’t have the same permissions?  It always throws an error), I wasn’t surprised with the error.  Fast forward to January 2011 when I finally got a chance to do a bit of researching and it looks like this is expected behavior when trying to move accounts that are a part of the Enterprise Administrators or Domain Administrators group.  More information can be found at this post here: http://social.technet.microsoft.com/Forums/en/ocsplanningdeployment/thread/df5135b0-ba66-4bde-97e6-e4d89deeabaf.  The following two links provided by an MVP gives a pretty good explanation of why this happens:

1. http://www.unplugthepbx.com/Lists/Posts/Post.aspx?ID=31
2. http://msexchangeteam.com/archive/2009/09/23/452595.aspx

In the meantime, I’ve had success with just using the PowerShell cmdlet to move users that have elevated privileges so if you’re experiencing this problem, just use the cmdlet to move the users.