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)
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
Same move attempt via Lync Shell:
Ok, so now what?
The following errors in the Lync Event log on the Front end with the active backup service were also observed:
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
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:
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….