Ever seen the movie Happy Gillmore? (if not you should) Think:

You son of a ***** ball! (Lync user account) Why don’t you just go home?! (Pool) That’s your HOME! (Pool) Are you too good for your home? (Pool) 

Setup:

2 Lync 2013 Enterprise Pools in an ‘Associated backup pool’ relationship.

3 Front Ends/Pool

Pool uses SQL Clustering (booo)

File Shares on DFS

The issue at hand is that while moving a user from the Lync pool in the primary datacenter to the Lync pool in the secondary datacenter, the DFS sharing service on the DFS server hosting the secondary data centers Lync pool was shut down. Thank you very much security team compliance scans (HULK SMASH! – you’re fired!). At any rate, the user seemed to move successfully, but when an attempt was made to move the user back to the primary datacenter Lync pool, we received some of the following:

User account move attempt via Lync Control Panel

NewImage

 

Same move attempt via Lync Shell:

NewImage

 

Ok, so now what?

The following errors in the Lync Event log on the Front end with the active backup service were also observed:

EventID 4073:

NewImage

NewImage

Uhhh ok, so now what? Looked at several things and even with some additional testing it was decided to call PSS. We were provided with a utility that I certainly had never heard of, wait for it, the ‘Pool Conflict Corrector tool’.

The Poolconflictcorrector tool will look for conflicts on a user object that even though it physically resides on one pool, could believe it exists in both pools, hence the error/issue.

Some preliminary steps (read: CYA just in case something goes wrong) should be to:

1. Export-CsUserdata for the primary and backup pools.

2. Backup the RTCXDS database for both pools as well.

You should be provided with instructions from PSS on running the PoolConflictCorrector tool but the basic syntax is:

PoolConflictCorrector -pool1fqdn -pool2fqdn -logfile

Example:

poolconflictcorrector -pool1.contoso.com -pool2fqdn pool2.contoso.com -logfile c:\repair.log

If any conflicts are detected they should be listed and you can decide if you want to continue, no changes will actually be made should you choose not to continue.

An example of the output:

NewImage

There is a Lync Resource Kit utility, VerifyUserDataReplication.exe that should be run to verify any conflicts still exist, and verify that the 4073 errors do not persist.

Additionally, if you are running  this in an environment with a split SQL permissions model (read: evil SQL admins won’t give you lowly Lync guys full SQL rights – sigh :)), or the overall SQL permissions are not correct on the RTCXDS database or have been modified you may run into an issue where the tool errors out with a permissions error on RTCXDS.

Please understand the risks on using a tool of this nature and follow all guidance from PSS as applicable. Please comment on any questions or experiences if you find yourself in the same situation.

Hope this helps….