More MCOValidationErrors and chasing squirrels in ADSIEdit

The experienced around here know an article is going to be good when I mention ADSI edit. But for those that don’t know, ADSI edit is one of the more dangerous Active Directory tools allowing Administrators to edit things directly, even if they have no idea what that means.

I hear a lot about how Linux is so powerful because it doesn’t hold your hand and lets you do whatever you want. Windows has stuff like that too… it’s just intentionally hidden from “Google-Fu” admins, and ADSIEdit is one such tool.

Anyway, First off, a bit of background. A customer of mine had a series of 4 common area phones created as just plain users. When we attempted to migrate these users, the Move-CsUser cmdlet would throw an Object not found error.

The root cause of the issue was that when they were initially created, they had [email protected] UPN’s, now this wouldn’t fly in Office365. So, As part of their sync into Azure AD, they changed the user UPN to the contoso.onmicrosoft.com domain. Thus, effectively, we now have two different accounts linked by an Immutable ID. AD knows there the same thing. Teams knows they are the same thing, even throwing a SIP address conflict error in the MCOValidationError field, But Skype4B had no idea about this “other account”, causing an Object Not Found error when I attempted to move them.

The Fix…

Now had I thought about this in advance, I could have changed the UPN for the four user accounts to the right vanity domain and tried migrating them again after an AADSync. Teams would have been happy it could make an actual SIP address, and Skype would be satisfied with finding the user, but being a Common Area Phone. I figured it was just easier to blow it away and start again.

Squirrel one: Can’t I just disable the on-prem skype4b user and enable Teams?

The plan was to disable their on-prem accounts and enable their cloud ones. Simple enough, I thought.

As a reminder, as per the documentation, Disable-CsUser “deletes all the attribute information related to Skype for Business Server” and then clears any data from the Skype4B database.
Many admins, including myself, would take that statement to indicate any AD attribute beginning with “msRTC*” would be cleared.

So ideally, Disable-CsUser should remove the user attributes, AADsync should sync this change to Azure AD and then AzureAD should re-provision the user, right?

Wrong. Even after completely removing the Teams service plan, and licences from the users, waiting for replication and trying again. The account was still no good. This time with a new error.

Squirrel Two: Lets just clear the Deployment locator record and re-enable Teams?

Let’s read further in the Disable-CsUser documentation. We can see that the cmdlet only clears server attributes from AD. Sure enough, if we run a Get-CsAdUser for the affected account, we still have AD attributes but no mention of the msRTCSIP-DeploymentLocator attribute. Piping the output of this to Get-Member or Get-CsUser doesn’t show anything useful either.

Thus, in ADSIEdit, we trust.

As usual, I’m not going to cover using ADSIEdit here, there are plenty of guides out there from AD MVP’s that I highly recommend as I couldn’t do the tool justice. And again, doing the wrong thing in here, will have your Identity admin breathing down your neck whilst they are in DSRM mode restoring AD from a backup! It is VERY easy to blow away core AD services if you arent paying attention, (Domains, Forests, Exchange configs, you name it, its all stored here!)

Anyway, now the doom and gloom has been dealt with. We start off by grabbing the DN of the affected user using Get-CsUser, then locating the offending account object in ADSI using its DN, and checking out the object’s attributes.

Sure enough, the msRTCSIP-DeploymentLocator attribute is still set to SRV: This means the Skype4B infrastructure “knows” about this user and will attempt to use the DNS SRV records to locate where it’s homed, based on its DNS suffix.

So, let’s try clearing the attribute and waiting for AADSync. (Remember, edit the attribute, then click clear. Don’t just empty the field and click OK)

A quick check after AADSync shows that Azure hasn’t magically added the attribute back in, so we can proceed.

But, even after removing the Teams licence and reapplying it to the same user. We still have the same error message, drat.

Squirrel three: Clean up and fixing the core issue

So, Teams is still aware of something, and we need to finish clearing it out.

The simplest way to do that, now that all the msRTCSIP attributes are missing, is to remove any Licences or Service Plans granting Teams and Calling to the user. And then, as usual with Office365, the trick is to WAIT. (30 mins should be enough)

Watching the account via PowerShell, the interpreted user type changed to “HybridOnpremUserNotLicensedForServiceNeedsProvisioningToAD” and then eventually “AADConnectEnabledOnlineUserNotLicensedForService”, indicating that Teams had finished de-provisioning the user.

Finally, I could update the user’s sign-in address to be the customer’s vanity domain instead of “contoso.onmicrosoft.com” and re-licence the user to re-create their Teams account.

Now, we just keep an eye on Users > Active Users > Teams Setup Status aaaaand…

Is this method perfect? probably not. The simpler fix would have been to fix the UPN in the first place and then migrate the user. There is a good chance that the On-Prem instance of Skype4B won’t know about this user, but as this was the tail end of a migration. I’m not terribly concerned. I could. I suspect re-inject the msRTCSIP attributes manually so Skype is aware of the cloud account. But again, just not a risk worth taking.

Till next time…