close
182-07_1-300×162

Informing Tenants About Feature Updates

I recently wrote about the transition of the Office 365 Service Communications API to become a Microsoft Graph API and how to use the API to fetch details of service incidents. As I pointed out then, the API includes the ability to retrieve information about the service update messages Microsoft posts to inform tenants about the delivery or retirement of features. These messages show up in the message center in the Microsoft 365 admin center (Figure 1) and are a great source of information about future change.

Service update messages in the Microsoft 365 admin center
Figure 1: Service update messages in the Microsoft 365 admin center

Microsoft has done a lot of work over the last few years to improve communication with tenants. They’ve:

  • Built an integration between the Message Center and Planner to synchronize updates to Planner. Tenants can then use the tasks created in Planner to assign responsibility for managing the introduction of new features or phasing out of old features. We recommend that all tenants consider using this integration to help manage change.
  • Added extra information to the messages to highlight the affected services (like Exchange Online, SharePoint Online, and Teams).
  • Introduced better filtering capability in the Message Center.

Even so, challenges still exist in dealing with the volume of updates Microsoft introduces annually. It’s not just reading about the changes as they appear to understand how a new feature will affect users and the business, or how to manage something like the retirement Skype for Business Online on July 31, 2021. Not everyone has the time or opportunity to keep tabs on new posts in the message center, and when they do, it can be challenging to understand some of the text created by Microsoft development groups to describe what they’re doing (intelligent people aren’t necessarily great writers). Another problem is tracking the frequent slippage in dates when Microsoft predicts features will be available. While Teams is notable for the high percentage of missed dates, no workload hits all its commitments.

Custom Message Processing

Good as the Message Center is, it’s always good when you can do things your own way, and that’s why the Office 365 Service Communications API is valuable. My last article covers the basics of connecting to the API and fetching data. Here we focus on the Messages API and how to extract and manipulate service update messages with PowerShell.

I like to think of practical examples to illustrate how something works. In this case, my example is a report of the service update messages flagged for tenants to act by a certain date. For instance, Teams ceased support for IE11 after November 30, 2020. That date is long gone now but a message to remind administrators of the fact remains. You could argue that this is an example of something Microsoft should clean up; equally, you could say that it’s a prompt for tenants to move off IE11 to Edge, which is why Microsoft might have left the message in place. In any case, it’s a message with an act-by date. Looking at the message center as I write, of the 256 messages, 31 have act-by dates.

I discovered this fact by running a simple Graph query using a registered app with consent to use the ServiceMessage.Read.All permission:

This code sets a date range to check service update messages against (I chose 180 days in the future) and sets up a query to find messages with an action required date less than the date. The code then runs the query and extracts the message data from the information the API returns. An individual message looks like:

So far, so good. We have some data, and the nice thing about having some data to play with is that we can decide how to slice and dice the information to make it more digestible for the target audience.

Let’s assume that we need to convince managers of the need to do some up-front preparatory work before Microsoft delivers new software to the tenant. Asking managers to go to the Microsoft 365 admin center isn’t feasible. In my experience, busy managers are more likely to review information if given a spreadsheet or report.

The next task is therefore to create code to loop through the message data retrieved from the Graph and generate suitable outputs. Apart from removing all the HTML formatting instructions from the descriptive text for a message, there’s no great challenge in this code. To make things interesting, I computed the time remaining between the current time and the action by date and flagged overdue items. You can download the complete script from GitHub. Figure 2 shows the HTML version of the report. The script also generates a CSV file.

Service update message data reported in HTML file
Figure 2: Service update message data reported in HTML file

Generating a Word Document

Given the flexibility of PowerShell, you could even create Word documents using message data in an approved form. Here’s some code to generate a Word document containing details of a message center notification.

Figure 3 shows an example of a Word document generated using the code.

A Word document generated by PowerShell using service message data
Figure 3: A Word document generated by PowerShell using service message data

Access Drives Innovation

The nice thing about having access to data is that innovative people will do interesting things with the data. Being able to process Microsoft 365 service update messages to extract whatever value you see in the information is goodness. The only question is how best to make use of the opportunity…

Source Practical 365

Chioma Ugochukwu

The author Chioma Ugochukwu

Leave a Response