Some more disconnects with managing users and groups in the Microsoft 365 Admin Center

For a while now, I have been stumbling into some puzzling experiences in the Microsoft 365 admin center, and I decided it’s about time to get this off my chest. In this article, we will go over few such examples that have caused me to scratch (or bang) my head.

Let’s start with the Delete user wizard. While generally I find it useful, as it helps less experienced users to perform some additional tasks with ease, and without having to use other tools, in some cases it can actually do more harm than good. Take licensing for example. While generally not a requirement for deleting a user, in some cases it might be appropriate to “free up” the license. By recommending this without taking into consideration all the various factors that weigh in on such decision however, Microsoft is promoting some bad practices.

First, let’s set things straight. Soft-deleted users in Office 365 do not actually “consume” licenses, as illustrated below, and hard-deleted ones even less so.

C:\> Get-MsolAccountSku

AccountSkuId                        ActiveUnits WarningUnits ConsumedUnits
------------                        ----------- ------------ -------------
michev:SMB_APPS                     25          0            5

C:\> Get-MsolUser | ? {$_.Licenses.AccountSkuId -eq "michev:SMB_APPS"}

UserPrincipalName DisplayName isLicensed
----------------- ----------- ---------- Gosho True Pesho True Vasil Michev True MU2 True HuKu True

C:\> Remove-MsolUser -UserPrincipalName

Continue with this operation?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):

C:\> Get-MsolUser | ? {$_.Licenses.AccountSkuId -eq "michev:SMB_APPS"}

UserPrincipalName DisplayName isLicensed
----------------- ----------- ---------- Gosho True Pesho True Vasil Michev True HuKu True

C:\> Get-MsolAccountSku | ? {$_.AccountSkuId -eq "michev:SMB_APPS"}

AccountSkuId ActiveUnits WarningUnits ConsumedUnits
------------ ----------- ------------ -------------
michev:SMB_APPS 25 0 4

C:\> Restore-MsolUser -UserPrincipalName

UserPrincipalName DisplayName isLicensed
----------------- ----------- ---------- MU2 True

C:\> Get-MsolAccountSku | ? {$_.AccountSkuId -eq "michev:SMB_APPS"}

AccountSkuId ActiveUnits WarningUnits ConsumedUnits
------------ ----------- ------------ -------------
michev:SMB_APPS 25 0 5

C:\> Get-MsolUser | ? {$_.Licenses.AccountSkuId -eq "michev:SMB_APPS"}

UserPrincipalName DisplayName isLicensed
----------------- ----------- ---------- Gosho True Pesho True Vasil Michev True MU2 True HuKu True

You can also see that the License information is actually preserved on the soft-deleted user, which can be useful in scenarios where you do want to recover it (more on this later). On the other hand, because the license information is still stamped, recovering the user might result in an error in case you run out of licenses. The real trouble here though lies in what happens with the mailbox after removing a license, and equally important scenario is when there are holds involved. Although I haven’t been able to prove this conclusively just yet, I have a strong suspicion that the Delete user wizard is in fault for the numerous cases I’ve seen where the inactive mailboxes process is used incorrectly.

The wizard does perform some checks around holds actually, as evident in the case where you want to “give another user access” or in other words, convert the mailbox to shared one. Lots to discuss on this particular flow, but for the purposes of this article it is sufficient to mention that the check for holds only seems to apply to the “convert to shared” step, as illustrated below. What exactly is the problem with that is not clear, as shared mailboxes certainly can be put on hold.

Note that this check only seems to cover the good old LitigationHoldEnabled method, and not any of the other methods, including In-place Holds or Retention-based ones, be they targeted or org-wide. The wizard will happily let you remove a license for a mailbox put on any hold type, including the lit hold scenario shown above, which in turn results in putting the mailbox in an erroneous state, as a mailbox with active hold cannot be disabled. Moreover, it puts you in a license agreement violation. Which is exactly what I mean by “doing more harm than good”.

The helpfulness of the Microsoft 365 Admin Center doesn’t stop with deleting a user, it will also baffle you whenever you decide to restore a soft-deleted user too. Every time you try to do so, you will be forced to reset the password for the user, for reasons unknown. Pressing the Restore user button will bring forth another helpful “panel”, giving you some information about the process. Whoever came up with the text presented obviously didn’t make his mind about licensing though:

Before you restore ‎‎ you need to make sure you have a product license available. Restoring ‎‎ will restore all associated data, assign product licenses, and give access to all services they could access before they were deleted.

Nowhere in the process you are actually prompted to assign a license, and neither is one assigned automatically (remember that the licenses are removed when you use the Delete user wizard). So you will need to complete this as additional operation once the user has been restored. Plugging in this as a step in the recovery process would have been nice and would help clarify the above message.

That’s not what annoys me though, it’s the fact that you are forced to reset the password for the user. There’s no way going around it, if you want to use the M365 AC for this task that is. None of the other admin endpoints will ask you, let alone force you, to reset the password. And there is absolutely no explanation (or any reason I can think of) as to why this is needed.

Oh, and the best part? The same process will trigger when you try to restore a Guest user. Yes, the type of user who is external to your organization and whose credentials are managed in their home tenant. Go figure!

Next, we switch gears to the Group management experience. Tony Redmond just published a nice article on how the “remove member” experience sucks. Incidentally, this coincided with the release of an updated experience, which is of course not free of issues either, but it does offer some improvements over the previous iteration. At the very least the  flashy, “unicorn barfed a rainbow” arrangement is gone. Still, the behavior continues to differ across the various endpoints, and it goes beyond the UI bits.

As an example, one can use the M365 AC to remove a member of a “modern” Microsoft 365 Group, while leaving him as owner. On the other hand, if you try to perform the same operation via PowerShell, you will run into the good old “Only Members who are not owners can be removed from group. Please remove ‘xxx’ as owners before removing them as members.” error. In all fairness, the Azure AD blade and the Graph API itself also allow for this operation to complete, so we probably shouldn’t blame it on the M365 AC. The fact remains however that huge disconnects remain between the different experiences within the Microsoft 365 suite.

In effect, we’ve now described few examples of functionalities that differ in behavior across the various Office 365 management endpoints. While it does make sense to bring some sort of wizard-type interface to assist smaller and inexperienced customers will common admin tasks, forcing the same behavior in a “one size fits all” manner is not the right approach. Bigger and more complex organizations will likely use their own tools to manage groups and users, but whenever they do use the M365 Admin Center, they should be getting an experience that is consistent with other endpoints and methods. More importantly, the experience must take into considerations all the complexities, and not force them down the same predefined path, which in some cases can result in creating a bigger mess.

As our final example of annoyances, we can briefly cover yet another issue with the Audit log. While testing the recently introduced auto-claim policies, I noticed that no corresponding events are being recorded. Further investigation showed that the group-based licensing functionality also exhibited similar behavior. In addition, direct license assignment events, while present in the audit log, did not include the information about what changes were actually made to the license (as in which SKU or individual service was added/removed). After making some fuzz about it, audit log entries started appearing as expected, at least when new licensing assignments are concerned. This matter will be subject or a more detailed article later this week…

UPDATE 09/04/2021: Well, it didn’t took long for the next disappointment to hit. Apparently the Microsoft 365 Admin Center now only allows you to manage the Mail (Exchange-related) settings for *licensed* mailboxes. In other words for every shared/resource mailbox you will get the following:

Serves me well for actually trying to use the M365 AC…

This entry was posted in Azure AD, Microsoft 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.