This one took weeks from me to figure out, and a little help from our friends at Microsoft. After upgrading a customer's SBA fron 2013 to SfB (and following the correct process):
- Move users to Front-End
- Remove SBA from topology
- Add SBA back into topology with the same name but under the SfB node
- Re-install SBA software using 2015 image
- Move users back to SBA
Number five is where the issue happened; the users would not move back with a DCOM error:
Interestingly enough, the error in the event log is even more confusing, talking about RoutingGroup already assigned to a different pool (EventID:32209):
Since this is a weird error, the fix will have to be even more weird; this fix is from MS internal documentation :-) (DISCLAIMER: I take no responsibility for doing this on your own environment)
You will need to run the below command to find the users that have a conflicting routing group ID with the one in the Error message:
(Get-CsPool FE01.contoso.com).Computers | `
% {Sqlcmd.exe -E -S $_\rtclocal -d rtc -Q `
"select UserAtHost,* from dbo.RoutingGroupAssignment as rga `
inner join dbo.ServiceCluster as sc on (sc.ServiceClusterId = rga.ServiceClusterId) `
inner join dbo.ServiceAssignment as sa on (sa.ServiceTagId = sc.ServiceTagId) `
inner join dbo.Pool as p on (p.PoolId = sa.UscClusterId) `
inner join dbo.ResourceDirectory as ResD on (ResD.RoutingGroupId = rga.RoutingGroupId) `
inner join Resource as Res on (Res.ResourceId = ResD.ResourceId) `
where rga.RoutingGroupName = '<BAD ROUTING GROUP ID>'" -W -s "," -o $_-dumpuserinRG.csv}
The output file will have several users for that routing group ID that are considered "defective"; you will need to run the next command from the RTC database on ALL FE servers in the pool:
use rtc
go
exec [RtcDeleteResource] 'user@domain.com'
go
Rinse and Repeat ... for all Routing Group IDs that show up in the error message.
Now the move user works !!!
