At some point you’ll have performed enough upgrades or migrations to have encountered a DCOM error while trying to move users from one pool to another. It’s generally well-documented: Anthony, Michael, Paul, Michael or others might have shown you the light. It’s usually a permissions thing. You don’t have enough of them.

I was a little surprised when I encountered “it” this week, and burnt a little more time than I’d like to admit in search of the cause – but in my defence, I ended up on a tangent down a rabbit-hole chasing red herrings in search of a wild goose.

Annoyingly, my occurrence didn’t fit the more common mould. This one didn’t blame my Front-End, the load balancer or report a cryptic error code I could just Google:

PS C:\Users\gsheridan> get-csuser bpitt | move-csuser -Target "sfbpoolxxxx.contoso.com"  -Verbose
VERBOSE: CN=Brad Pitt,OU=Apparently Now Single,OU=Hollywood,DC=contoso,DC=local
Confirm
Move-CsUser
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
move-csuser : Distributed Component Object Model (DCOM) operation SetMoveResourceData failed. For details, see inner exception.
At line:1 char:21
+ get-csuser bpitt | move-csuser -Target "sfbpoolxxxx.contoso.com"  -Verbose
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (CN=Brad Pitt,...ntoso,DC=local:OCSADUser) [Move-CsUser], MoveUserException
    + FullyQualifiedErrorId : MoveError,Microsoft.Rtc.Management.AD.Cmdlets.MoveOcsUserCmdlet

Results from this operation can be found at "C:\Users\gsheridan\AppData\Local\Temp\MoveResults-5934ffd2-29ed-4171-8929-0f35c0efe81c.csv".
PS C:\Users\gsheridan>

Unfortunately the CSV didn’t tell me anything more than what was on-screen.

My new 3 server Enterprise Edition pool was running fine. My account – the only one on it – was running totally fine & manifesting no problems at all, so clearly the issue must have been something amiss with the old pool not wanting to give up its users.

Permissions were checked and re-checked.

Maybe it was their OU, because as a contactor I’m relegated to the poor-house elsewhere in AD, unlike these “real” users. Nope.

I asked another (pre-existing) customer admin to try the move commandlet. It failed.

After bashing my head against a wall for a while, it occurred to me to take a closer look at my new pool, and from here it was all downhill.

Let’s see what Get-CsPoolUpgradeReadinessState says. Was the pool in a “Ready” state for an upgrade? Eek: NO!

Busy? The “User State is being re-built on some Front-Ends”?

What does Get-CsFabricPoolState have to say about that? Oh.

I don’t know how that happened!! Let’s have a quick word with FE3:

Phew!

Needless to say, I was now able to easily move my users from this point.

Hopefully this helps someone for whom the DCOM issue isn’t permissions…

– G.