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:
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…
Great article… I wonder how much SSL and Permissions troubleshooting was put in before “Let’s see what Get-CsPoolUpgradeReadinessState says. ” :D
AHAHAHA AHAHA ahhh.
I’m not going to say how long it took before I clicked on here to realise I had taken one of the frontends down because of the other dcom issues.. yep not saying that at all.