Continuous Access Evaluation Revokes Access Immediately

The announcement in message center notification MC884015 (5 Sept 2024) that the Microsoft 365 admin center (Figure 1) will implement continuous access evaluation (CAE) in September 2024 is very welcome. Microsoft implemented CAE for Exchange Online, SharePoint Online, and Teams in January 2022.

Implementing CAE means that the Microsoft 365 admin center can respond to critical events that occur such as user account password changes or if a connection originates from an unexpected IP address. If an administrator account is unfortunate enough to be compromised, CAE will ensure that the credentials used to access the admin center will expire immediately after the password is changed for the account or access is revoked for the account.

Speed is Key

Speed is of the essence when it comes to responding to attacks and making sure that credentials are invalidated and forcing reauthentication as soon as possible is helpful. CAE replaces older methods like waiting for an access token to expire. The problem with waiting for access tokens to age out is that unauthorized access could persist for up to an hour after the compromise occurs.

Of course, it’s even better to stop compromise by making sure that administrator accounts are protected by strong multifactor authentication such as the Microsoft administrator app or passkeys. Even though we’ve known that this is true for years, the percentage of Microsoft 365 accounts protected by multifactor authentication is still disappointing (38% in February 2024). In that context, being able to revoke access to critical administrative tools like the Microsoft 365 admin center is important.

Other Microsoft 365 Administrative Portals

The Microsoft 365 Admin Center is a headline administrative portal and it’s important that Microsoft protects it with CAE. However, this step shouldn’t be seen as bulletproof protection for a tenant because it is not. There’s no news about support for CAE in other important administrative portals like the Purview compliance portal and the Defender portal.

Although it would be good for CAE to be supported in all Microsoft 365 admin centers, the fact remains that this might not be enough to stop an attacker. As noted above, speed is key after an attacker penetrates a tenant. Waiting for a GUI slows down an attacker, who can use automated scripting using PowerShell and Graph API requests to perform actions like the creation of new accounts and permissioned apps. Firing off some scripts to infect a tenant thoroughly is a lot more efficient than using an admin center. This underlines the need to stop attackers getting into a tenant. CAE is a kind of plaster that will heal some of the damage, but it can’t stop attackers wreaking havoc if they manage to compromise an account holding administrative roles.

Continuous Access Evaluation is a Good Thing

Don’t get me wrong. I strongly endorse the implementation of Continuous Access Evaluation across the administrative landscape of Microsoft 365 tenants. Anything that slows or obstructs attackers is a good thing. Everything that complicates the process of compromise is valued.

The sad thing is that 38% figure for accounts protected by multifactor authentication reported above. Taking Microsoft’s reported figure of 400 million paid Office 365 seats, that means only 152 million accounts use multifactor authentication and almost 250 million do not. That’s just too many lucrative targets for the bad guys to go after. We need to do better.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

License Assignments Cease in Entra Admin Center from September 1, 2024

Microsoft hasn’t announced the change formally yet, but a notice posted in the Entra admin center and associated documentation proclaims that from September 1, 2024, administrators won’t be able to assign any form of license to user accounts or groups through the Licenses page of the Entra admin center (Figure 1). In addition, it will no longer be possible to assign or update licenses by editing user account properties in the Entra admin center. Instead, administrators must make license assignments through the Microsoft 365 admin center.

Following the switchover, it will still be possible for administrators to view license assignments in the Entra admin centre. Only license assignments and updates for current assignments are blocked.

According to Microsoft documentation, the change will “streamline the license management process within the Microsoft ecosystem.” A case can certainly be argued that it’s better to centralize license management in one place, even for Entra P1 and P2 premium licenses. Given that Microsoft 365 consumes most licenses, it is logical to focus licensing activity on the Microsoft 365 admin center.

PowerShell Remains Unaffected

The change only affects the GUI in the Entra admin center. Licenses can still be assigned to users and groups via the Microsoft Graph PowerShell SDK or Graph API requests. Any tools written based on the SDK or Graph requests such as the Microsoft 365 Licensing Report remain unaffected.

Microsoft 365 Admin Center Updates

License management has been present in the Microsoft 365 admin center for a while. Group-based license management is a relatively new addition (Figure 2) and supports the same feature set as the Entra admin center.

One nagging doubt that I have about the move is that the Microsoft 365 admin center is invariably slower at dealing with anything to do with licensing than the Entra admin center is. Perhaps folks who work on the Microsoft 365 admin center need some help about efficient license management techniques from their Entra colleagues. Another is that the Microsoft 365 admin center doesn’t support administrative units in the same way as the Entra admin center does (albeit requiring Entra P1 licenses). Hopefully, administrative unit support will appear in the Microsoft 365 admin center soon.

Overall, I don’t think making the Microsoft 365 admin center the fulcrum for license assignments will discomfort anyone except people who write about license assignments. Proving the value of ePublishing, we’ll document this change in the September 2024 update of the Office 365 for IT Pros eBook (2025 edition).

Self-Service Purchases Get a GUI

A change that might have more impact is the one announced in message center notification MC853238 (6 August 2024). For years, tenant administrators have complained about the way Microsoft opened up self-service purchases to users and the need to use the awful MSCommerce PowerShell module to disable the ability for users to buy licenses.

MC853238 says that in mid-September 2024, the Microsoft 365 admin center will have a new Self-service trials and purchases option under Org Settings (Figure 3) to enable or disable self-service license purchases previously only manageable through PowerShell.

Administrators can choose to:

• Allow self-service trials and purchases: Users are allowed to apply for trial licenses and buy self-service licenses.
• Allow trials only. Even after a successful trial, the user cannot purchase a license.
• Do not allow purchases: Users cannot purchase self-service licenses.

It’s surprising that Microsoft has taken so long to introduce the GUI to manage self-service purchases, but at least it’s happening now.

Friday Happiness

These changes are good examples of the kind of updates that flow through Microsoft 365 on an ongoing basis. Neither are earthshattering. They won’t cause processes to stop working unless you really depend on the Entra admin center for license assignments. Even if you do, the switch to the Microsoft 365 admin center is easy. Everyone should ignore some of the breathless hype around these changes and have a nice weekend, which is what I plan to do.

Surprise Announcement Highlights Inconsistencies Across Microsoft 365 Consoles

Microsoft’s 17 August announcement that they are not proceeding with support for dark mode in the Teams admin center (TAC) came as a surprise. Originally announced in message center notification MC567496 (2 Jun 2023), I covered the news briefly on June 6 and pointed out that dark mode for TAC had some problems with custom tenant colors. This didn’t seem like a big issue at the time. It’s the kind of fit-and-finish bug that tends to be taken care of before final release.

I don’t know why Microsoft decided not to deliver dark mode for TAC. Microsoft’s announcement simply says “We have made the decision not to proceed with this feature at this time,” which could mean anything. What’s for sure is that the toggle to enable dark mode has disappeared and won’t come back until Microsoft decides what to do next.

The news about TAC got me thinking about why Microsoft doesn’t have a common platform for Microsoft 365 administrative consoles. Despite efforts to make the consoles look and feel similar, the interfaces have their own foibles.

Authorization and Tokens

Take authorization as an example. The admin consoles use modern authentication, so the consoles need to acquire OAuth 2.0 access tokens and renew the tokens when they expire. Making token renewal a seamless experience for administrators seems to be a very complex technical challenge for the console developers.

The Microsoft 365 admin center manages things best. Behind the scenes, the console takes care of token renewal without a hitch. I seldom experience issues with this console, even after keeping the admin center open for extended periods. The SharePoint Online admin center is also pretty good. Other consoles struggle to deliver an elegant solution to token refresh.

For example, the new-and-improved Exchange admin center flashes errors up when it discovers the need to renew an expired token. Flash is the operative word because an error message appears and disappears in the blink of an eye. However, it’s there and I know it’s there and I worry that something more problematic than a brief pause in token renewal is the root cause. It seems like an issue that is highly solvable.

The Microsoft Purview compliance portal takes a more pedantic stance and insists that administrators should sign in regularly (Figure 1). At least you know where you are and what to do to proceed, and an arguable case exists that the compliance portal gives access to solutions that protect confidential information. But the inconsistency in behavior is obvious and jarring.

Teams Admin Center

And then we come to the Teams admin center. This console is fond of launching and appearing to work as normal before suddenly deciding that it should sign out the connected user (Figure 2). This action forces the user to reauthenticate before they can connect to TAC. And it can force the user to sign in again to other Microsoft 365 apps.

I’ve complained to Microsoft about TAC’s odd connection procedure several times. Each time I’m told things will improve. And to be fair to Microsoft, the issue occurs much less frequently now than it did in the past. Perhaps recent changes to the TAC contained some new code to address the problem. But I don’t trust TAC because I’ve experienced the sign-out issue within the last few weeks. I’m now keeping a watching brief on TAC to see if the issue reappears and if so, whether I can identify specific circumstances that might provoke the sign-out.

Dark Mode Support Across Admin Consoles

With the decision made not to support dark mode for TAC, the situation is that two of the five main Microsoft 365 admin consoles support dark mode while three do not:

• Support dark mode: Microsoft 365 admin center (Figure 3), Exchange Online admin center.
• Do not support dark mode: Teams admin center, Microsoft Purview compliance portal, SharePoint Online admin center.

The inconsistent implementation of dark mode is only an indication of the lack of consistency which still exists across the Microsoft 365 admin consoles. It demonstrates that Microsoft still has work to do to make Microsoft 365 administration a unified space. And when they’re doing that, making access token renewal work the same way across all consoles would be a great thing to do.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant

Release Status Only Present for Some New Notifications

Message center notification MC485549 (14 December, Microsoft 365 roadmap item 108078) brings news of a new launch status Microsoft is adding to notifications to make it clearer to administrators about the actual status of a change heading to their tenant. Until now it’s been difficult for administrators to know exactly when a software change will hit their tenant after release by Microsoft. The difficulty increases when Microsoft misses a predicted availability date, something that often happens regularly (the expanded reaction set for Teams is a notable example).

The new release status shows up as a property of new message center notifications. In Figure 1, we see that some updates have a launched status (update available to all tenant users) while the scheduled date for other updates has not arrived. The third status is “rolling out,” meaning that some users have received the update but not others.

Microsoft plans to unveil the new release status to targeted release tenants starting in mid-December 2022. All targeted release tenants should see notifications with release status by mid-January 2023. General roll-out to standard release tenants is due in mid-April 2023.

Initially, the release status will appear for Teams, Outlook, and Microsoft 365 admin center announcements. Over time, it will spread to all workloads. A release status only appears for updates that correspond to a Microsoft 365 roadmap item. Sometimes updates appear that aren’t on the roadmap. Logically, these messages won’t have a release status.

Continuum of Message Center Notification Improvements

The latest change to message center notifications is part of an ongoing continuum of improvements to customer communications for updates released to Microsoft 365. Recent examples include:

• Introduction of messages to inform tenants when data privacy incidents occur.
• Addition of a relevance tag for message center notifications to advise administrators when a change is especially pertinent to their tenant.
• Flagging how many users are likely to be affected by a change.

The project to improve communications around Microsoft 365 updates is led by Microsoft with considerable customer involvement.

Planner Tasks See the Release Status

The Planner tasks created by the Message Center-Planner synchronization capability include the release status in the Notes section (Figure 2). There’s no easy way to filter tasks with a certain release status in Planner.

I also don’t see any evidence of the release status (or the other recent enhancements like relevance and user count) in the Service Messages API. Perhaps Microsoft hasn’t had the chance to upgrade the API to output all the details now available for message center notifications.

Need for More Predictable Release Dates

The trick for Microsoft will be to make sure that the accuracy of the release status tag is high. At one point, nearly half of all the updates published in message center notifications failed to meet the scheduled dates. Software development is an inexact science when it comes to predicting when the last few bugs that hold up the deployment of a new feature will disappear.

Microsoft has become better at publishing believable and attainable dates in the recent past. Things aren’t perfect yet and are likely to never be. Perhaps a new highlight on release status will make Microsoft do even better when it comes to predicting feature availability. We can but hope!

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Change Reflects Increasing Importance of Web Apps

In a move that will be very popular with users, Microsoft announced a new account switcher for Microsoft 365 web apps in message center notification MC338712 on March 4. This is Microsoft 365 roadmap item 70801 and it’s due to land in tenants starting in early April, with deployment due to finish in late June.

Although Microsoft 365 users do a lot of work using desktop clients like Outlook and Teams, there’s no denying that browser clients have become increasingly important. Anyone who does administrative work with Microsoft 365 is probably signed into a bunch of different administrative portals like the:

• Microsoft 365 admin center.
• Microsoft 365 Defender portal.
• Microsoft 365 compliance center.
• Microsoft 365 security center.
• Azure AD admin center.
• Azure portal.
• Teams admin center.
• SharePoint Online (and OneDrive for Business) admin center.
• Microsoft Intune portal.

At the same time, many Microsoft 365 apps don’t have desktop clients, including SharePoint Online, Planner, Yammer, Bookings, OneDrive for Business, Delve, Stream, Power Automate, Forms, and Lists. Some apps behave perfectly well when installed as a desktop app (which is how I use OneDrive for Business, Planner, Yammer, Lists, and several SharePoint Online sites), but they’re still web pages.

Messy Multiple Browsers

The point is that much of the focus of Microsoft 365 activity is through the browser, so we all end up with multiple open browser apps or a browser cluttered with open tabs. This isn’t so bad until you complicate matters by wanting to sign into different tenants or the Microsoft consumer apps). Until now, switching context requires one of:

• Signing out and signing into the desired tenant.
• Using a second browser (or maybe even a third).
• Using private browser sessions.

When guest support for Teams first appeared, switching to use guest access in another tenant was slow and people worked around the problem by running a separate browser for each tenant they wanted to work in. The technique worked, but it’s an example of the lack of flexibility in credential management and data management in Microsoft 365 browser apps.

New Account Switcher

When the update rolls out, you’ll be able to sign into multiple Microsoft 365 tenants and MSA accounts and switch between the different accounts for Microsoft 365 web apps within the same browser session without having to sign out and in again. A new account manager capability (Figure 1) lists the current signed-in sessions and allows the user to “perform a one-click switch” to a chosen session. After an account switch, the app reloads the page using data from the selected account.

Microsoft says that the switch occurs “while maintaining data integrity and privacy across different account/tenant boundaries.” In other words, you can be signed into OWA in two Microsoft 365 tenants but won’t see data from one tenant appear in the other or vice versa.

If a user opens multiple tabs with different accounts, they’ll be told that they recently switched to the most recently opened account and asked to refresh the page to load data from that account.

Not All Apps Supported

The capability isn’t available for all apps. When released, it applies to:

• OWA.
• SharePoint Online browser client.
• OneDrive for Business.
• OneDrive consumer.
• Microsoft 365 admin center.
• Office.com.
• Office web apps.

Microsoft says more Microsoft 365 web apps will be added later. For now, Planner, Yammer, and Teams are the notable absences. Given the work ongoing to create the next generation of the Teams client, Microsoft might not want to add the capability to the current Teams browser client. We shall see in time.

No Admin Impact

User sign outs from browser sessions continue to work as before, as does the ability to block sign-ins and sign an account out of all sessions from the Microsoft 365 admin center. Azure AD continuous access evaluation (CAE) for critical events, which can force users to reauthenticate when events like password changes occur, is likewise unaffected. The only impact on tenant administrators is the opportunity to give some good news to users!

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Microsoft 365 Notifications User Counts Come from the Graph

Message center notification MC315739 (January 18, roadmap item 83946) brings news of a big change for the information included in notifications. Soon, along with the text describing new features or changes to existing Microsoft 365 features, notifications will include service usage data relevant to the change. Deployment starts for targeted release tenants in mid-January and should be complete worldwide for all tenants by mid-February.

Let’s take the change announced in MC302456 as an example. This notification describes how users can maintain their guest accounts in other tenants from Teams. To help administrators understand how many people will be affected by the change, the service communications API queries the Microsoft Graph reports API to retrieve the monthly active user data for Teams and reports this information in the notification.

Figure 1 shows a mock-up included in MC315739 to illustrate how Microsoft 365 notifications highlight user data. On the left, you see a notification for a change affecting multiple workloads together with the usage data for each workload (Outlook is really Exchange Online, but obviously non-Outlook clients can connect to Exchange Online mailboxes). On the right, you see a notification for Kaizala, which doesn’t store its usage data in the Microsoft Graph, so it’s impossible to display this information.

Editorial comment: The need for Kaizala is possibly now much reduced by the general availability of the Teams Walkie-Talkie feature.

The Problem with Microsoft Graph Usage Data

The Microsoft Graph reports API allows access to usage data about some Microsoft 365 services. Coverage is good for base workloads (SharePoint Online, Exchange Online, Teams, and OneDrive for Business) and not so good elsewhere (Planner, Stream, Forms, Whiteboard, etc.). Nevertheless, the usage data is detailed enough to build a picture of user activity over the last ninety days. If you’d like to know how to use the API with PowerShell, consider running the User Activity Analysis script to see how to make calls against the reports API and the kind of data the API returns. For example, this code creates a query to retrieve Teams activity data for users over the last 30 days. Data returned by the reports API is always a few days behind the actual date.

$TeamsUserReportsURI = "https://graph.microsoft.com/v1.0/reports/getTeamsUserActivityUserDetail(period='D30')"

[array]$TeamsUserData = (Invoke-RestMethod -Uri $TeamsUserReportsURI -Headers $Headers -Method Get -ContentType "application/json") -Replace "...Report Refresh Date", "Report Refresh Date" | ConvertFrom-Csv

The data returned by the API is in an array. Here’s the item in the area for an account:

Report Refresh Date        : 2022-01-16
User Principal Name        : Jane.Smith@office365itpros.org
Last Activity Date         : 2022-01-15
Is Deleted                 : False
Deleted Date               :
Assigned Products          : POWER BI (FREE)+ENTERPRISE MOBILITY + SECURITY E5+BUSINESS APPS (FREE)+MICROSOFT POWER AUTOMATE FREE+MICROSOFT VIVA TOPICS+MICROSOFT DEFENDER FOR CLOUD APPS – APP GOVERNANCE+OFFICE 365 E5 WITHOUT AUDIO CONFERENCING
Team Chat Message Count    : 58
Private Chat Message Count : 14
Call Count                 : 1
Meeting Count              : 5
Has Other Action           : No
Report Period              : 30

The data looks good and is useful. However, some workloads (like Teams) return data for both tenant and guest accounts, so the numbers reported in message center notifications will reflect that data. You might be concerned about how a change will affect guest users, but I hazard a guess that most tenant administrators will focus on the effect on tenant users.

Another issue (acknowledged in MC315739) is the non-specific nature of the report. Usage across all clients and all features is included into one workload figure. For instance, a change affecting Microsoft Lists in SharePoint Online and OneDrive for Business might affect just the five people who create and manage Lists, but the notification will say that the change affects everyone who has used SharePoint Online or OneDrive for Business in the last month. You won’t know either if a change is specific to a client platform, like Android or iOS.

Counting all and sundry who use a workload isn’t such a big problem for new features. It is more important for updated features and becomes even more critical when Microsoft deprecates some functionality. You then want to know precisely who is affected, or at least, how many are affected.

Another aspect of an all-up number is that it doesn’t take account of multi-geo deployments. You’ll know that some people in the organization might need to be informed about a change, but not their location.

Still a Good Change

Even with the caveats listed above, including user data in Microsoft 365 notifications is still a good change. If you see a notification where a low number of users will experience an impact, you can probably spend less time preparing for that change and more on changes affecting large user populations. The availability of data through Graph APIs limit what the developers can do to slice and dice usage data to make it more precise and informative. This will probably happen over time. In the interim, take the user information presented in Microsoft 365 notifications as a starting point to help you understand the likely impact of individual changes on users. Use this data in conjunction with your knowledge of the tenant and how people work within the organization, and the monthly active user data for affected workloads will be helpful. Taken as an exact guide, it won’t be.

I guess I might have to update my script to extract and report information from message center notifications to accommodate this change…

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

From September 1, Pseudonymized by Default

MC275344 (published August 3, updated August 31, Microsoft 365 roadmap item 81959) deals with the topic of anonymization of user information in Microsoft 365 usage reports. Until now, the situation has been that the usage reports show full usage data, including details of user principal names and group names with an option for the tenant to choose pseudonymized information. In this situation, anonymized values like A6968D016DB2256910FD3B85B4B0457B replace user or group identifiable information in the reports. You can still understand the overall context of the report and what it tells you about the usage pattern for a workload like SharePoint or Teams, but you can’t dive down into the detail at user level.

Microsoft says that de-identifying user data will help tenants support local privacy laws. The changeover to use anonymized data by default came into effect on September 1, 2021. Users with access to report data now see values like those shown in Figure 1.

Reverting to Real User Data

If you want to revert to see real user information in usage reports, a global administrator can switch through the Reports section of Org-wide settings by clearing the checkbox shown in Figure 2.

Updating the setting captures an UpdatedCFRPrivacySettings audit record. For instance, here’s an edited version of the audit record captured when I enabled identifiable user information in usage reports.

RecordType   : CoreReportingSettings
CreationDate : 06/09/2021 19:37:55
UserIds      : Tony.Redmond@office365itpros.com
Operations   : UpdatedCFRPrivacySettings
AuditData    : {
                 "ModifiedProperties": [
                   {
                     "Name": "PrivacyEnabled",
                     "OldValue": "True",
                     "NewValue": "False"
                   }
                 ],
                 "Id": "639e2bcc-eba9-4146-8885-333622ffb4b0",
                 "RecordType": "CoreReportingSettings",
                 "CreationTime": "2021-09-06T19:37:55",
                 "Operation": "UpdatedCFRPrivacySettings",
               }

Access to User Information Limited to Certain Roles

In the past, this would have been sufficient to let any account holding an administrative role with access to usage data to see user information. This is not now the case as Microsoft has made a further change to confine the ability to see user information to “administrative and report reader roles.”

In effect, this means that roles like:

• Global administrator.
• Exchange administrator.
• SharePoint administrator.
• Teams administrator.
• User administrator.
• Helpdesk admin.
• Service support admin, and:
• Reports reader.

Can see user information (anonymized or real as selected by the tenant setting), but other administrative roles such as Usage summary reports reader or Global reader, which used to be able to see user information, no longer have access. Users with these roles see only summary graphs (Figure 3).

Governs Programmatic Access Too

The change affects usage reports in the Microsoft 365 admin center and the Teams admin center. It also affects programmatic access to usage data through the Microsoft Graph usage reports API, including SharePoint site detail. This is because the usage reports API is the basis for reporting across Microsoft 365.

As noted when Microsoft originally introduced anonymized user data for reports, if the organization generates its own version of usage reports like my Office 365 User Activity Report, you’ll need to make sure to generate the report using an account with a suitable administrative role. Identifiable user data makes these kinds of reports much more valuable, especially if you use the reports to analyze usage patterns based on departments, locations, and workloads, and if you want the reports to contain this information, the org-wide setting to allow identifiable user data must be enabled when the report runs. Arranging for this to be done if the organization decides to use anonymized user information for reporting could be a challenge!

Good for Privacy

There’s no doubt that this is a good step from the perspective of privacy advocates. However, I wonder if obscuring information about how people use technology at the level of detail available in the Graph (like the number of emails sent and read, or Yammer conversations created) will make it harder for administrators to do their job. I agree with the move to restrict access to detailed information to the more highly privileged administrative roles, but wonder how many organizations will try to use anonymized user information before reverting because good reason exists to access detailed data.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Microsoft 365 Privacy Messages in Case of Data Compromise

Microsoft posts notifications to the message center in the Microsoft 365 admin center to inform tenant administrators about a variety of different updates made to its service. MC272885 posted on Jul 24, 2021, has the title Attachments for messages with Data Privacy Tag, which might leave you scratching your head to understand what Microsoft means. At first glance, the combination of attachments and messages points to email and tag could mean a sensitivity or retention label. But that’s not what it means.

Reading the detail reveals that Microsoft is introducing a new tag for service update messages. Let’s explore what this means.

Tagging Service Messages

When Microsoft publishes a service update message, it applies tags to help tenant administrators understand the importance and potential impact of the change (Figure 1).

The tags shown in the message center include:

• Admin Impact: The change impacts the management of some aspect of the tenant. For example, a new API is available. MC272885 (described here) is deemed a change with administrator impact.
• Feature Update: Microsoft has changed the way a feature works. For example, MC264095 describes how the default setting for guest access in Teams changes from off to on.
• Major Update: The change described is considered major. For example, the retirement of Skype for Business Online on July 31 (MC266078) is obviously a big change in Office 365. Other updates tagged as major are debatable, but you can consider this tag to be a way for Microsoft to highlight important changes. Note: Unlike the other tags, this tag is marked by setting the IsMajorChange property of a message to $True.
• New Feature: A new feature is on its way for an app. For example, MC230680 describes the introduction of reactions in Teams meetings. Microsoft often misses the date for feature introductions and republishes the update, which is what happened on MC230680 on June 30 when they published new dates for availability of the feature in the GCC and DOD clouds.
• Retirement: Microsoft is removing a feature from the service. Skype for Business Online is an example, so is the final removal of Site mailboxes (MC266256). Not many shed tears when site mailboxes shuffled off into the great byte wastebasket.
• User Impact: Many changes impact users in some way. For example, MC271629 advises administrators that Project Moca is moving its spaces to the OWA calendar.
• Updated Message: This tag does not appear in the Microsoft 365 admin center. It’s used to flag service messages which have been updated since the original publication. This is usually due when Microsoft needs to clarify the meaning of the text.

Many updates have multiple tags. For instance, MC264095 has the major update, feature update, and user impact tags.

Analyzing Service Update Tags

Using the Graph API for Service Communications, we can fetch the messages currently available in the Microsoft 365 admin center to see what tags are in use. As you’ll recall, this API spans both incidents (outages) reported in the admin center and service updates. I took the example script I created for service updates and used some of the code to pull all update messages into an array.

$Uri = "https://graph.microsoft.com/beta/admin/serviceAnnouncement/messages"
[array]$Messages = Get-GraphData -AccessToken $Token -Uri $uri

I then used some simple code to analyze the tags placed on each message.

$TagAdmin = 0; $TagUpdate = 0; $TagMajor = 0; $TagNew = 0; $TagRetirement = 0; $TagUser = 0; $TagUpdatedMessage = 0; $TagDataPrivacy = 0
ForEach ($Message in $Messages) {
    ForEach ($Tag in $Message.Tags) {
      Switch ($Tag) 
        {
        "Admin impact"    {$TagAdmin++}
        "Feature update"  {$TagUpdate++}
        "New feature"     {$TagNew++}
        "Retirement"      {$TagRetirement++}
        "User impact"     {$TagUser++}
        "Updated message" {$TagUpdatedMessage++}
        "Data privacy"    {$TagDataPrivacy++}
       } # End Switch
    }  # End Foreach tag
   If ($Message.IsMajorChange -eq $True) {$TagMajor++}
} # End ForEach message 
Write-Host "Admin impact messages:  " $TagAdmin
Write-Host "Feature update messages:" $TagUpdate
Write-Host "Major update messages:  " $TagMajor
Write-Host "New feature messages:   " $TagNew
Write-Host "Retirement messages:    " $TagRetirement
Write-Host "User impact messages:   " $TagUser
Write-Host "Updated messages:       " $TagUpdatedMessage
Write-Host "Data privacy messages:  " $TagDataPrivacy

Admin impact messages:   165
Feature update messages: 65
Major update messages:   76
New feature messages:    119
Retirement messages:     31
User impact messages:    191
Updated messages:        96
Data privacy messages    0

The total count of messages was 266. You can see that:

• The most popular tag is user impact (191) followed by admin impact (165).
• There’s a surprising number of retirement messages (31).
• Many updates are issued (96).

Your mileage might vary because Microsoft issues service updates to tenants based on the feature set licensed by the tenant.

What’s Changing

Microsoft is introducing a new Data Privacy tag to indicate messages which need administrator attention because they potentially impact sensitive data. The change is due to roll out by the end of July.

Microsoft says that messages might also contain one or more downloadable attachments (if multiple, the attachments are in a zip file) to help administrators “gain additional insight into the described scenario.” For instance, an attachment might be a PowerShell script to report data or users affected by a service update.

Only accounts holding the Global administrator and Privacy reader roles can access the downloadable attachments.

It’s hard to be certain about how Microsoft will use the new Data Privacy tag and what kind of service update messages they will tag. I guess we will see when some messages appear with the tag (none are found in the messages in my tenant) and the kind of attachments available for the messages.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Avoiding the Problems Seen with Disabled User Accounts

Last April, I wrote about the problems caused in Teams when disabling a Microsoft 365 user account. In a nutshell, Teams removes disabled accounts from team rosters (the lists controlling team memberships) while leaving the accounts as members of the underlying Microsoft 365 groups. When the account is reenabled (or unblocked), Teams attempts to reverse the process and reintroduce the account into team rosters. That process doesn’t work so well from time to time and is slow, and users lose access to any private channels they belong to. The net effect is confusion and frustration.

Teams works this way by design. The intention is to stop team members seeing blocked accounts whom they can’t collaborate with. For instance, if Jane is leaving the organization and an administrator blocks her account as part of the departing employee process, there’s no point in showing her as a team member.

In any case, I suspect that message center MC264095 (posted June 23) is linked to some moves Microsoft is making to improve the situation, and possibly also to prepare the way for the introduction of shared channels later this year (it wouldn’t be good if blocked users lose their membership of those channels either!).

MC264095 covers a change to the way that the Teams guest access setting works. This is an organization setting in the Microsoft 365 admin center (Figure 1).

Current Behavior

As the name implies, when a tenant turns off guest access in Teams, external people who are guest members in teams in the tenant can no longer access those teams and team owners cannot add any further guest members. Up to now, if a tenant turned guest access off, Teams would remove guests from its team rosters (just like it does for disabled user accounts). The guests remain members of the underlying Microsoft 365 groups and can access resources available to those groups such as the SharePoint Online team site, Planner, and so on.

When you consider how much usage Teams currently gets, disabling guest access could impose a considerable processing load on Office 365 to track down and remove all the guest accounts from all teams in the tenant. Those resources could be better used for more productive purposes.

Sensible Step

The change being introduced in late July will stop Teams removing guest accounts from team rosters. This is a sensible step. It avoids the problems that can occur when a tenant turns guest access back on. In the past, Teams would have to compare its rosters against the membership of the Microsoft 365 groups to find guest members and add those guests to the rosters. As we’ve seen with unblocked user accounts, sometimes this process doesn’t work and overall, it can take a long time. Now, guest access is a simple on-off switch which should be much less disruptive.

Selective Blocks

If you really want to remove guests from Teams, team owners or an administrator would need to check membership and remove the guest accounts. Turning off all guest access for a tenant is a dramatic step to take. A more nuanced approach is to implement an Azure AD B2B collaboration policy and whitelist the domains the organization wants to collaborate with. A PowerShell script can then look for and remove any guest account which doesn’t come from the approved domains.

I don’t hear of many tenants disabling and reenabling guest access to Teams, but I’m sure that it happens. I hope that this change is a forerunner of a future change to the way Teams deals with disabled user accounts.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Teams is the Last Workload to Support Deidentification of Personal Data

On March 16, Microsoft published message center notification MC244599 to announce that the usage data in Teams reports would support the same obfuscation of personally identifiable information (PII) in usage reports as the other workloads do. On April 9, they said that the roll-out of the feature was complete. This is Microsoft roadmap item 70774.

The text in MC244599 and roadmap item 70774 might lead you to think that this is a Teams feature. It’s not. As evident in this December 2020 post, workloads like Exchange Online and SharePoint Online could disguise user-identifiable information like email addresses and display names as well as SharePoint site names in the Microsoft 365 admin center reports. This is a case of Teams catching up. What’s odd about Teams only now obscuring its usage data is that the Microsoft Graph was able to obfuscate the raw Teams usage data then (see the example in the previous post).

Obscuring Personal Data

The setting to control the display of obfuscated user, group, and site data is in the Org-wide Reports section (Figure 1).

After setting the switch, the usage reports for workloads available in the Microsoft 365 admin center contain obfuscated user data (Figure 2).

The setting also covers the usage reports available in the Teams admin center.

The Graph Reports API is to Blame

The setting to control the anonymization of personally identifiable data applies to all reports generated by the Microsoft Graph Reports API, which is the basis for the usage reports in the Microsoft 365 admin center. Deciding to obscure usage data can cause an admin to swap settings to access some information. For instance, the admin center has a report for Microsoft browser usage (Chrome, Brave, and Firefox are studiously ignored). The report is useful to find people who still use the legacy Edge browser, which Microsoft removed from the April 2021 update. But if you look at the report to find the names of people to contact to ask them to switch to a supported browser, you’ll be the deidentified strings like C58FABF670363F68A787078886FCB1A1.

The same issue exists in reports like active users or groups activity, which are examples where the data is all but useless if you don’t know what users are active (and who isn’t) and what groups are in use (and which are not). In all cases, an admin can fix the problem quickly by resetting the switch, but it does show how unintended consequences often flow from an action.

ISV and Your Own Reports as Well

Microsoft hypes the Graph Reports API to ISVs and customers as an easy way to integrate Microsoft 365 usage reporting into existing reporting solutions. This is true, but the downside is that the same switch used to control user anonymization in the Microsoft 365 admin center usage reports affects any other use of the API in a tenant.

For example, we have a PowerShell script to collect information about user activity from a range of Microsoft 365 workloads to present a per-user synopsis of how they interact with the service. The script uses the Reports API to fetch usage data from each workload and combines it together for each user to create the report. If the tenant switches on data obfuscation, the usage report fetched by the script is anonymized and returns data like this:

Report Refresh Date : 2021-04-13
User Principal Name : 47A3F2B66A3C6BF31F1C629D02B43A24
Display Name        : 24589499045E94C4FF5C4A681A467937
Is Deleted          : False
Deleted Date        :
Last Activity Date  : 2021-02-20
Send Count          : 76
Receive Count       : 123
Read Count          : 0
Assigned Products   : MICROSOFT 365 E5 DEVELOPER (WITHOUT WINDOWS AND AUDIO CONFERENCING)
Report Period       : 90

Although the user’s privacy is protected, from an organizational perspective the value of the report is negated.

Understand What Obfuscation Means

It’s easy to understand why Microsoft builds the ability to anonymize user data in reports into the admin center. Several user-assignable roles (like Reports Reader) can access the reports, so it’s good to have a way to protect user privacy, even if it’s only surface-deep. What’s less understandable is the impact the switch has on custom reporting. It just seems a little crude to have a binary switch which control all output.

Poor UI Design, Especially for Large Groups

Vasil Michev, the technical editor of the Office 365 for IT Pros eBook, is quick to spot a problem that we should pay attention to, which is why he highlighted a concern about the Microsoft 365 admin center UI used for group membership maintenance. In a nutshell, George McDonald, the author of the Microsoft Technical Community post, thinks the UI sucks dirty canal water, saying:

“The Members Lists are no longer displayed in a drop-down list, with check boxes preceding each entry, instead now members are clumped together in what can be best described as a single text box, further compounded by the fact that this clump of members is NOT in Alphabetical Order. So if you have anything more than 20 users in the clump, your eyes have to scan every entry carefully to find the required user to remove, then hit an X mark suffix to their name to remove membership. Ridiculous and irritating user experience is putting it politely, make no mistake.

Figure 1 shows the problem. In this case, the group has 57 members and is just about manageable in the format chosen by Microsoft to display group members (as reported below, this UI is now replaced).

With a larger group, the problems in the UI would soon become apparent because:

• The group is sorted in the order in which members are added. In other words, the first member added to the group is at the top and the most recent member is at the bottom. This doesn’t make sense. Alphabetical sorting would be better, including the ability to sort both A-Z and Z-A. It would also be good to be able to filter members based on properties like location in an advanced search.
• The list shows the display names of the members. This is fine and people can be identified if duplicate display names don’t exist. For example, what happens if seven people named John Smith or Jane Ng are members? You can’t assume that organizations will apply suffixes to differentiate group members.
• The initials in circles might look pretty, especially in multiple colors, but they don’t help. In this example, user photos are available for many members, but even if the list included the photo instead of user initials, it probably would not help because the images would be too small.
• You can search for people to add to the group, but you can’t search the existing members to find someone. The membership limit for Teams is now 25,000. Imagine scanning such a list to find and remove a member.
• The default display looks as if all members are selected and that any action, like a removal, will be applied to all.

Microsoft Updates the Group Management UI

As proven in Sod’s law, as soon as something is published about a cloud detail, Microsoft ships an update. In this case, they refreshed the group membership management UI (Figure 2) to address some of the more grievous sins evident in the previous UI. The new approach is clearer and better, but it still suffers from some issues.

• There’s still no ability to sort or filter.
• Limited information is shown about each user. Again, this is fine for a small organization but less good once the number of accounts increases.
• User photos are not shown (if available).

Another example of poor “fit and finish” is when displaying the members of a team-enabled group. Thoughtfully, Microsoft displays an icon to show that a group member is “Teams enabled” (Figure 3). But what does this mean? After all, the members are in a team, so by definition they are Teams-enabled (I guess they could be new members waiting to receive a Teams license through an auto-claim policy). But what then for guest users? These are Teams enabled because they are a member of a team, but they don’t need licenses to access Teams in another tenant. It’s all very confusing.

I also hate the way that the Add members screen insists on loading and displaying mail contacts first. Although it’s possible that an administrator will want to add a mail contact to a group, it’s more likely that they will want to add a tenant account. Some control should be given to allow administrators to choose the order in which mail recipients load when adding new members to a group.

In summary, the Microsoft 365 admin center UI needs a makeover to improve its ability to handle the membership of large groups, provide better search features, and show more information about each member to differentiate individuals.

OWA Group Management is Better

It can be argued that the UI of the Microsoft 365 admin center is intended to help inexperienced administrators and that experienced people will use other tools, like PowerShell (which I would use to remove members from large groups). However, Microsoft uses an inconsistent array of UI designs for group membership management, some of which exhibit characteristics the admin center could adopt. For example, OWA’s UI for managing a group displays fewer members (initially), but more information is available about each member (including their photo), and you can search for members (Figure 4). There’s no filtering or ability to sort, but OWA’s is a better UI.

The Art of the UI

I’m sure Microsoft has heaps of UI experts on staff. Sometimes they get it right, like the recent change to the SharePoint Online sharing control, and sometimes they get it wrong, like the group management UI described above. Perhaps some knowledgeable eyes could look at the different ways to manage group membership surfaced across Microsoft 365 apps with a view to coming up with a common approach that works well for both small and large groups. Wouldn’t that be nice?

Making Teams Client and the Admin Center Produce the Same Type of Teams

Message center notification MC238795 of February 10 says that Microsoft plans “to align experience for creating a team from different Teams interfaces.” This is a complicated way of saying that currently the settings of teams differ depending on where they are created, and Microsoft is making changes to make sure that some important settings are consistent. Specifically, teams created in the Teams client and the Teams admin center (Figure 1) will have the same settings. The change is scheduled for mid-March.

A side effect of the change is that members added to teams created through the Teams admin center will receive “Welcome to Teams” messages rather than “Welcome to Groups.” This might not seem important, but it is because the messages point users to different types of functionality. Teams focuses on chat-based collaboration; Groups focuses on email.

Groups, Teams, and Settings

Every team is underpinned by a Microsoft 365 group. Groups can be used in different ways, but several settings relate to Outlook groups that Teams does not use. The focus is to make team-enabled groups have the same settings.

To explain the problem, let’s look at the relevant properties of a Microsoft 365 group/team created from the Teams desktop or browser client:

Get-UnifiedGroup -Identity "Planning Events" | fl HiddenFromExchangeClientsEnabled, 
HiddenFromAddressListsEnabled, AlwaysSubscribeMembersToCalendarEvents

HiddenFromExchangeClientsEnabled       : True
HiddenFromAddressListsEnabled          : True
AlwaysSubscribeMembersToCalendarEvents : False

The meaning of these settings is as follows:

• HiddenFromExchangeClientsEnabled is True, meaning that the group doesn’t show up in Exchange clients like Outlook and OWA.
• HiddenFromAddressListsEnabled is also True, meaning that the group doesn’t appear in any Exchange Online address list like the GAL and OAB. People can still send email to the group via its SMTP address, but it’s invisible if you go looking in an address list.
• AlwaysSubscribeMembersToCalendarEvents is False, meaning that members of the group do not receive notifications of calendar events. This option is more problematic, because it means that team members don’t receive invitations to channel meetings, even those scheduled with the channel calendar app. Many organizations like to distribution meeting invitations to team members. If you’re in this position and want this to happen for some or all teams, follow the instructions in this article.

By comparison, if we do the same for a Microsoft 365 group/team created from the Teams admin center, we see:

Get-UnifiedGroup -Identity "Teams Writing Group" | fl HiddenFromExchangeClientsEnabled, HiddenFromAddressListsEnabled, AlwaysSubscribeMembersToCalendarEvents

HiddenFromExchangeClientsEnabled       : False
HiddenFromAddressListsEnabled          : False
AlwaysSubscribeMembersToCalendarEvents : True

In other words, unless Microsoft updates the team creation process for the Microsoft 365 admin center, some teams will still be created will inconsistent settings.

Use the Graph!

All of this proves that the Teams developers can make sure that the settings of groups their interfaces create are consistent, but some work is needed to ensure that consistency applies across all of Microsoft 365. Perhaps that’s why MC238795 recommends that organizations use the Teams Graph API to create new teams. The Teams PowerShell module is built on top of the Graph, so let’s see what happens when we run the New-Team cmdlet to create a team-enabled group:

$TeamId = (New-Team -DisplayName "Annual Conference Planners 2021" -MailNickName ConferencePlanners -Description "Team for conference planners" -Visibility Private -Classification Confidential -Owner James.Ryan@office365itpros.com -RetainCreatedGroup:$True)

Get-UnifiedGroup -Identity "ConferencePlanners" | fl HiddenFromExchangeClientsEnabled, HiddenFromAddressListsEnabled, AlwaysSubscribeMembersToCalendarEvents

HiddenFromExchangeClientsEnabled       : True
HiddenFromAddressListsEnabled          : True
AlwaysSubscribeMembersToCalendarEvents : False

Voila! The same result as creating a team using the Teams client and what will happen using the Teams admin center from mid-March.

Learnings

Microsoft’s update imposes consistency across team-enabled groups created using Teams interfaces (admin center, clients, PowerShell, and Graph). However, only new teams will follow the rules as Microsoft will not check and update settings for existing teams. It is easy to do some retrospective processing with a PowerShell script to check the setting of each team-enabled group and update the settings to the desired values (a modified version of the script described in this article will do the job).

Before you go and change anything, take a moment to consider if the settings chosen by Microsoft work well for your organization. Some organizations like to see teams listed in the GAL or to have team members receive calendar updates by email. Teams should work for you rather than the other way round, so make your own mind up.

The Office 365 for IT Pros eBook contains a complete chapter (13) all about working with Microsoft 365 Groups and Teams through PowerShell. It’s the kind of high-value hard-to-find material that’s included in the book. We update content monthly to make sure that it’s accurate, refreshed, and practical. Subscribe today!

Microsoft publishes notifications to the Office 365 message center to inform administrators of upcoming changes that affect their tenant. The idea is that you should get a period of between two to six weeks before new software appears to prepare by taking actions such as informing users about new functionality.

Most of the time the software described in notifications arrives on time, but recently Microsoft has had to publish updates for an increasing number of notifications to inform tenants that new features are delayed. Table 1 details some examples of notifications that have recently been updated. As an application that is delivering many new features to meet customer demand, it shouldn’t come as a surprise that Teams notifications are the most likely to be delayed.

Sometimes Software Needs More Tweaking

You might wonder why Microsoft announces that a new feature is coming and is then forced to adjust dates, sometimes several times. The answer is that this is the nature of software. If an update isn’t ready, it won’t be released to general availability. Tenants don’t want low-quality software and Microsoft doesn’t want the support load generated when users run into problems with new features. For this reason, previews which are scheduled to last a few weeks might extend much longer if the customers participating in the preview uncover problems.

The point is that a notification is only a signal that something new is coming. It’s not a definite commitment that the change will happen on the predicted date. It might, and that’s good, but it might not, and tenant administrators should be prepared to track updates to Office 365 notifications and adjust their plans as necessary. This can be disruptive, especially when a feature slips several times or if some users are waiting for specific functionality.

Tracking Tasks

Speaking of plans, linking Planner to the Office 365 message center is an excellent way of tracking the notifications to make sure that surprises don’t happen. Planner has a reasonable mobile app that allows people to track updates to their assigned tasks, and the same tasks can also be managed through the Tasks app in Teams.

Tracking change inside Office 365 is something that the writers of the Office 365 for IT Pros eBook are pretty good at. Well, we think we are…

Changes Slip Through When You’re Not Watching

Microsoft recently updated the Microsoft 365 admin center with several useful changes to improve the Groups section of the portal. Most of the changes relate to Office 365 Groups (sorry, now Microsoft 365 Groups). It’s entirely possible that these changes have escaped your attention, so let’s cover them briefly.

Restore Deleted Groups

Given the popularity of Microsoft 365 Groups as the membership service for applications like Teams, Yammer, and Planner, it’s inevitable that some mistakes will be made when removing groups or that an important group will be allowed to expire. The ability to restore deleted Microsoft 365 groups was first introduced through PowerShell cmdlets in early 2017. Soon afterwards, the feature appeared in the Exchange admin center.

Now you can restore Microsoft 365 groups in the Microsoft 365 admin center. Go to Groups and open the Deleted groups section. Any groups that have not exceeded their 30-day soft-deleted retention period are listed (Figure 1). Deleted groups of other types, like distribution groups, don’t show up here and can’t be recovered using this method.

To restore a group, select it and either:

• Use the Restore group option in the group header.
• Click the group name to bring up the details pane, which has some basic information about the (display name, description, and email addresses) and click the Restore group button.

Both options perform the same processing to restore the deleted group. After a short delay, the group object is restored in Azure AD and begins the process of notifying the associated workloads to reconnect. It takes a little while for resources like the SharePoint site, a plan, or a team to be reconnected, but eventually everything comes together.

Selecting Licensed Teams Owners

Restoring deleted groups is a relatively big feature. A smaller, but still nice, feature is the way that the Add group wizard checks and displays if assigned groups owners have Teams licenses (Figure 2). Why is this important? Well, if you add someone who isn’t licensed for Teams as a group owner and then team-enable the group, that owner won’t be able to manage the team. And ownerless teams are bad.

The nagging doubt in my mind is that this feature might not work so well in very large tenants when many accounts can be nominated as group owners, but I’m sure this has been tested.

Improvements in Groups Section

The Groups section in the Microsoft 365 admin center has been nicely refreshed. Some of the changes have been around for a while, but I’ll note them here. In Figure 3 we see:

• The ability to edit the name and description of a selected group. This is a shortcut to calling the group details pane where you make the changes.
• Edit email addresses. Those of us who like PowerShell would run Set-UnifiedGroup to do this, but normal people will find it much easier to change the primary SMTP address of a group or add new proxy email addresses here.
• See the set of Teams-enabled groups. The Teams icon tells all.
• Filters to show different kinds of groups. We sometimes forget the humble distribution list, but these objects are managed here too.
• The sync status property tells you where a group is homed. In this case they’re all in the cloud.

Usefully, you can export the filtered set of groups to a CSV file. This kills off many PowerShell scripts written to do the same job (using cmdlets or Graph calls), but there’s nothing wrong with that.

There’s nothing earth shattering in anything that Microsoft has done and it’s likely that the changes help them reduce the number of support calls that flow in to ask how to do these operations. Changes that help both Microsoft and tenants are a good thing and collectively the changes make group management just that bit easier for those who don’t manage these objects very often. Best of all, Restore Deleted Groups is useful for even hard-bitten professionals. I’ll let you decide if you fall into that category.

Changes like those described in this post add value but they can slip by without you noticing. This is why we monitor what’s going on inside Office 365 and update the Office 365 for IT Pros eBook to make sure that our subscribers are always in the know.

Relieves Some of the Boredom Involved in Adding Users

The Office 365 Admin Center and its latest iteration, the preview version of the Microsoft 365 Admin Center (much nicer to use in parts), both offer the option to bulk-create Office 365 accounts. The processing flow is simple:

• Populate a CSV file with account details (a limited number of properties are supported).
• Upload the CSV file to the Admin Center.
• Verify that the CSV file is valid.
• Use the data in the CSV file to create accounts.

The idea is to relieve the tedium of creating multiple accounts, a value that anyone who has had to populate a tenant with account information (for real or to build out a test tenant) can easily recognize. However, there are some issues that need to be taken into account.

Preparing a CSV for Bulk Account Creation

To begin, head to the Active Users section of the Admin Center and select Add multiple users. You now have the choice to download a prototype CSV file to populate with details of the accounts you want to create. If you’ve done this before, you might already have prepared a file for processing – or if you’re very lucky, someone else has done the work manually or by generating the necessary data from another application, like a HR system.

The CSV file is very straightforward. All you really need to populate is the User Name (User Principal Name or UPN), which must be unique. Ideally, the UPN is the same as the email address you want to assign to the new account, and the email address must also be unique. Apart from the UPN, you can leave all the other fields blank except the Country or Region, which Office 365 needs to assign licenses as some features are country-dependent.

As far as I can tell, there’s no limit about the number of accounts you can include in a CSV. However, it’s probably wise to limit the number in a batch to a manageable amount (100 or so). Once you’ve populated the CSV with account information, you can ask Office 365 to verify the information.

Validation is very basic and the errors generated by the process are not very helpful. For instance, it will detect if you include accounts for more than one country and generate an error like:

[{“Row number”:2,”Errors”:[“Invalid domain name used in username. “]},{“Row number”:3,”Errors”:[“Invalid domain name used in username. “]}]

Only engineers would love the formatting of the error report. In any case, don’t expect validation to check that accounts already exist. The real intention of the validation seems to check that the CSV file is in the correct format.

Assigning Office 365 Licenses

Clicking Next brings you to license assignment. Obviously, you can’t assign licenses that you don’t own, but you can create accounts that don’t have the right licenses. One thing that you can’t do is assign different licenses to the accounts you create. You’re limited to the one license for everyone. The limitation on multiple country and license choice within a CSV file is a good reason to divide accounts into batches.

After selecting a license, you can go ahead to the final phase and create the accounts. If all goes well, you’ll have the choice to see the automatically-assigned passwords for the new accounts in email or in a downloadable CSV file. If things don’t go so well, you can download the log file (another CSV) to see errors like

The email address is being used by user (Rory Best) Rory.Best@Office365itpros.com. Please use a different email address.

This error is pretty self-explanatory.

Bare-Bones Office 365 Accounts Generated

Bulk account creation works, but the amount of time the process saves is possibly limited. You must create the CSV file, check that it works, process it, and resolve errors. And then you’ve still got to build out the account to make it fully functional by:

• Adjusting licenses if necessary.
• Adding the new user to distribution lists, Office 365 Groups, and Teams. The new accounts will be added to org-wide teams, if these are available in the tenant.
• Adding manager (reporting) information so that the Office 365 apps can show organizational structures.
• Add a photo for the account.
• Allocate calling plans or numbers if you use Teams or Skype for Business Online to replace a traditional PBX.
• Assign administrative roles.
• Assign extra email proxy addresses (if needed).
• Enable multi-factor authentication.
• Manage mailbox properties, like disabling access to mailboxes via older protocols such as IMAP4 and POP3.

It’s unsurprising that a ton of work remains to transform a bare-bones account to something that is fully usable by the account holder. To be fair to Microsoft, they don’t know how each tenant organizes its affairs, so they have delivered something that works at a basic level for all.

Maybe Roll Your Own Bulk Creation with PowerShell?

Given the situation, a more satisfactory answer for many tenants is to create their own bulk creation process using PowerShell where the script can do all the work to create the Office 365 account, populate all the necessary properties, add the user to appropriate distribution lists, groups, and teams, and so on. Or use what Microsoft provides in the Admin Center and be prepared to fix things up afterwards, perhaps with the assistance of a tool like Hyperfish to find obvious gaps in your tenant directory.

Need help figuring out how to automate Office 365 account creation? The Office 365 for IT Pros eBook has lots of examples of how to use PowerShell to accomplish tasks like account creation, license assignment, joining distribution lists and teams, and so on. You might find your answer in our example scripts!