On August 2, Microsoft announced “a new guided workflow for deleting Microsoft 365 users.” In fact, it’s really all about removing users from an Office 365 tenant and it’s limited to dealing with just their personal mailbox and OneDrive data. That being said, it’s good to see that Microsoft has put some time to bring more automation to a common task.
One challenge facing the designer of a process to remove an Office 365 user is the breadth of the service. The new workflow, implemented like wizards used elsewhere inside Office 365, tries to do no more than preserve the personal data of the deleted user and allow the administrator to decide what to do with their license. The assumption is that any other data the user is responsible for, such as SharePoint documents, are taken care of elsewhere. No attempt is made, for instance, to highlight situations where the user is the sole owner of an Office 365 Group or Team that someone might need to take over.
When you delete a user, the first screen in the account removal wizard outlines what can be done (Figure 1). An immediate glitch appeared. Although the chosen user has an Office 365 E5 license, which includes an Exchange Online license, Office 365 said that the user didn’t have that license, so it couldn’t have a mailbox. Sometimes you wonder about the quality of testing in the cloud…
Checking with the Get-MailboxStatistics cmdlet revealed that some 6,668 items are in the mailbox. In any case, waiting for a few moments and refreshing the wizard caused Office 365 to reconsider and realize that a mailbox was there all the time.
The workflow can perform the following actions:
The focus of the workflow is to preserve the personal information of the deleted user. Later, after recovering whatever information is available in the user’s mailbox, you could make the mailbox inactive to preserve the remaining information for compliance purposes.
The most complicated part of the workflow are the steps to preserve a deleted user’s mailbox. Unfortunately, another glitch comes into sight when you’re asked to select a user to become the new mailbox owner because Office 365 begins by displaying a list of licensed and unlicensed users, including guest users, instead of showing only fully licensed users.
I’m not quite sure why the list of users is shown because you’re forced to select a valid target user by putting their name into a search box and then selecting them from the results. It seems like a curious way of doing things.
Things get better when the wizard moves on to change the display name of the mailbox, which you might want to do to show its new status. For example, some organizations I know add a “ZZZ-“ prefix to the display name to group the mailboxes belonging to ex-employees at the end of the GAL.
The wizard then turns its attention to creating an auto-reply for the mailbox (Figure 2) to inform correspondents that the mailbox owner has left. Some boilerplate text is inserted by Office 365, but you can overwrite it and insert whatever text makes sense to you. You can also choose to send auto-replies to internal users only, or for new mail coming from both internal and external senders.
Mailboxes need a primary SMTP address to allow email delivery to occur, but many mailboxes have some proxy addresses that Exchange can also use to find and deliver messages. These addresses might be there because they were used in the past when the company had a different name, or used department identifiers in email addresses, or because the recipient wanted to be reachable through a mixture of formal and informal addresses (for example, TonyR and Tony.Redmond). You can remove the extra proxy addresses in the last step of the wizard.
The idea is that if you remove a proxy address, you free that address up for reuse. This might or might not be important to you.
With all the choices made, the wizard is ready to go ahead and delete the user. Office 365 tries to make it clear what’s going to happen by labeling the button Assign access and convert user (Figure 3). I guess you could describe deleting the user as a conversion, but the choice of words isn’t as clear as I would like. A simple Delete account might be better.
There are many ways of removing someone from an organization. The workflow Microsoft proposes is just one way, and it works for simple deletions. When things become a little more turbulent, you might want to do things differently, like making sure that a hold is on the mailbox well before the owner leaves the organization, implementing retention policies to ensure that they can’t delete important documents from SharePoint, and perhaps even forcing Office 365 to sign out the account and block further access on the person’s last day at work. All of this can be scripted with PowerShell.
Automating common processes and procedures is a good thing. It stops people making mistakes and it enforces some element of best practice. I’m sure Microsoft will address the glitches described here and make this workflow even better.
Follow Tony on Twitter @12Knocksinna.
Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.