Microsoft 365 for IT Pros (2027 Edition)

Posted on July 1, 2026 by Michel de Rooij

It is that time of year again. The new edition of Microsoft 365 for IT Pros is out, and this one brings the biggest structural change we have made in years. What used to be one large book with a single companion volume has now grown into a bundle of four focused books. Splitting the content allows us to go deeper while keeping the main book maintainable. Together, they deliver more than 1,700 pages of practical guidance for people who run Microsoft 365 every day.

A bit of history

The series goes back to May 2015, when it started life as Office 365 for Exchange Professionals. Over time, the platform expanded, the audience broadened, and the book evolved with it. This year also marks the move from Office 365 for IT Pros to Microsoft 365 for IT Pros. The name changed, but the focus did not. We still cover the services and workloads administrators, architects, and technologists rely on.

I joined the writing team in 2024. What stood out to me from day one is that this is not a traditional technical book. Most books age the moment they are published. This one does not. We update it every month and keep tracking the constant stream of changes across Microsoft 365. That evergreen model, combined with real-world experience, is what makes this book stand out. It is written for people who manage Microsoft 365 daily and need the most up-to-date content.

What you get

The bundle now consists of four books, each focusing on a specific area:

Microsoft 365 for IT Pros is the core book. It covers the Microsoft 365 ecosystem from an administrative perspective, including identity, Exchange Online, SharePoint Online, Teams, OneDrive, and overall tenant management. This edition adds a dedicated AI and Agents chapter covering architecture, licensing, deployment, governance, monitoring, and cost control for Copilot and related technologies.
Automating Microsoft 365 with PowerShell is the PowerShell / automation book. It focuses on automating Microsoft 365 with PowerShell and Microsoft Graph, providing practical examples you can apply in real-world environments.
Microsoft Purview for IT Pros is a new standalone book. It covers compliance and data governance, including data lifecycle management, eDiscovery, data loss prevention, information protection, and communication compliance.
Power Platform for IT Pros is the 2nd new standalone book. It focuses on the administration and governance of the Power Platform, including environments, Dataverse, solutions, application lifecycle management, and platform security through policies and controls. It also covers scenarios for Power Apps, Power Automate, AI Builder, and Copilot Studio.

Splitting the content into separate books allows for more depth and focus, while making the core book easier to consume and maintain. And for those who need it, each companion book is available separately, offering the same monthly updates for that book throughout the subscription.

Who this is for

Tenant administrators, consultants, architects, engineers, and technical leads will get the most value from this edition. If your job involves Exchange Online, Entra ID, SharePoint Online, Teams, OneDrive, Purview, Power Platform, Copilot, PowerShell, or Microsoft Graph, this set has been designed for you.

Availability

We use Gumroad.com to publish and distribute the books. All books are available in EPUB and PDF formats and can be converted for use on Kindle devices.

You can get the books here:

Microsoft 365 for IT Pros (2027 edition) (which includes the other 3 companion books)
Automating Microsoft 365 with PowerShell (2027 edition)
Microsoft Purview for IT Pros (2027 Edition)
Power Platform for IT Pros (2027 edition)

Challenges of PowerShell Scripting with Microsoft 365

Posted on October 16, 2023 by Michel de Rooij

If you are looking for a way to automate and simplify your Microsoft 365 administration tasks, PowerShell is a great option. However, PowerShell scripting is not without its challenges. Not proactively maintaining code can quickly become an issue because of the changes made to dependencies such as modules, as well as the cmdlets you use.

In an article I wrote for Practical 365, related to the presentation of the same name held at the The Experts Conference 2023 in Atlanta this year, I discuss some of the challenges administrators might encounter with PowerShell scripts. Also, I provide some guidance and point out a few tools that can assist with rewriting or refactoring code, i.e., updating code while keeping its external functionality.

Click here to read the full article on Practical 365.

Change Teams Guest Profile Picture

Posted on April 11, 2021 by Michel de Rooij

In tenants with lots of Guests, the massive display of user initials – the default profile picture – isn’t very pleasing to the eye. Now while regular user can change their profile picture, Guest users cannot. Therefor, a long standing and popular request on UserVoice has been the ability to change profile pictures for Guest users. End of 2020, this request was updated, indicating a change was planned to incorporate the ability to change this profile picture. No signs on the roadmap yet, so what options – if any – does one currently have?

Last week, Teams MVP Yannick Reekmans posted a blog containing instructions on how to change your profile picture for tenants in which you are a Guest. It requires quite some steps and fiddling to accomplish this. One might also wonder, isn’t this possible “the programmatic way”? Well, yes, and here are the steps:

First, open up PowerShell, install the AzureAD PowerShell module it is not yet installed using Install-Module AzureAD, and connect to Azure Active Directory, specifying the tenant where you are a guest:

Connect-AzureAD -TenantDomain contoso.onmicrosoft.com

When the authentication challenge pops up, specify the credentials of the Guest account and approve the Multi-Factor Authentication challenge when required.

Next, use Set-AzureADUserThumbnailPhoto to set the profile picture for your Guest account, specifying your User Principal Name as ObjectId, as well as the picture you want to use, e.g.

Set-AzureADUserThumbnailPhoto -ObjectId 'michel_fabrikam.com#EXT#contoso.onmicrosoft.com' -FilePath 'c:\pic.jpg'

Regarding the User Principal Name, you can use Yannick’s method of determining your Guest’s ID. You can also try to guesstimate it by taking the e-mail address of your original account, replacing ‘@’ with ‘_’, adding a trailing #EXT# followed by ‘@’ and the default domain of the hosting tenant. The picture can be JPEG or PNG format, size 100kb at most, and square dimensions work best.

To verify the image has been set successfully, use Get-AzureADUserThumbnailPhoto -ObjectId <ID>. Then, have some patience for the change to propagate throughout the directories and caching mechanisms. To verify your update was successful and your picture looks properly, you can close the Teams client, clear the locally cached Teams data by removing everything under %AppData%\Microsoft\Teams (Windows), and start Teams again.

To easily spot tenants where you are a guest user and not a regular user, you might want to alter your standard issue profile picture a bit. For example, I have added a text label ‘Guest’ to mine. It doesn’t look as good as the high resolution photos that you can store in Exchange Online, but it certainly looks less boring than a set of intilials.

Note that all of the above is not an officially supported way to manage this picture. So, until there is one, these steps might help you out.

Module Updates: What’s New?

Posted on September 18, 2020 by Michel de Rooij

After updating your PowerShell modules which support managing parts of the Microsoft 365, some of us are curious about what changes are introduced with the updated module. In the world of continuous change, it is hard to keep track of these changes. New cmdlets or parameters get added to support new features, and some get removed as they become obsolete. So, how to discover what those changes are after updating to the latest module?

Time to blog on a small script I created for this purpose a long time ago, Compare-Cmdlets.ps1. This script has two operating modes:

Export currently available cmdlets and parameters for supported modules.
Compare two exports of cmdlets & parameters and report the differences.

Currently, the following command sets are supported:

Module	Test Cmdlet	Export File
AzureAD	Get-AzureADUser	AzureAD-<version>.xml
ExchangeOnline	Get-Mailbox	ExchangeOnline-<version>.xml
ExchangeOnlineManagement	Get-ExoMailbox	ExchangeOnlineManagent-<version>.xml
MicrosoftOnline	Get-MsolUser	MSOnline-<version>.xml
Teams	Get-Team	MicrosoftTeams-<version>.xml

Command sets are exported per module, where a module is assumed to be present by a simple check for cmdlet availability (specified in column Test Cmdlet). That is, if Get-Mailbox is available, the ExchangeOnline module is assumed to be available. It does not distinguish between the Exchange PowerShell module or ‘classic’ Remote PowerShell session, nor will it take into account the repository origin of the module, nor if the Get-AzureADUser is coming from the AzureAD or AzureADPreview module.

That said, here’s how this is works. Load up PowerShell and have your modules installed and ready. Some modules like ExchangeOnlineManagement require connecting to the service first to import the cmdlet functions, so for ExchangeOnlineManagement run Connect-ExchangeOnline first. Same applies to the newer Teams modules, where the Skype Connector functions are only available after running New-CsOnlineSession.

Then run Compare-Cmdlets to export the cmdlets and parameters for those modules. The commands will by default be exported to an XML in a subfolder named ‘data’. The name of the file is mentioned in the table above. If you want to use a different folder to store the XML files, use DataFolder parameter.

Note that with Exchange, the cmdlets available to you depend on which role you have been assigned in Exchange’s Role-Based Access Control model. For example, if you haven’t explicitly assigned Mailbox-ImportRequest to your account, you will not see it in the exports. Therefor, when exporting module changes, it is required using an account with the same roles assigned to have proper exports. But when needed, you can also use it to report on command set differences between two Exchange Online accounts.

After updating some of the modules, or downloading one of the command set reference XMLs I stored with the script on GitHub, you can use Compare-Cmdlets to compare different versions of module exports. For example, to compare the cmdlets of Microsoft Teams module 1.1.4 with those after updating to 1.1.5, use

.\Compare-Cmdlets.ps1 -ReferenceCmds data\MicrosoftTeams-1.1.4.xml -DifferenceCmds data\MicrosoftTeams-1.1.5.xml

From the output, we see for example that:

The cmdlet Get-TeamChannel has a new GroupId parameter.
The cmdlet New-CsGroupPolicyAssignment parameter PolicyType has been removed.
The cmdlet Add-TeamChannelUser is new.

Note that common parameters (e.g. Verbose and ErrorAction) and optional common parameters (e.g. WhatIf) are left out of the equation. Also, parameters are not compared in depth and only presence is checked. If for example a parameter changes type (e.g. string to multivalue), Compare-Cmdlets does not pick that up.

As-is, the script is made to run on demand from an interactive PowerShell session. Ideally, this would run scheduled and serverless from within the service, reporting changes by e-mail.

The script Compare-Cmdlets.ps1 can be downloaded from GitHub here. If you find this useful, would like to comment or have suggestions, use the comments below or leave them on GitHub.

Comparing Sets of Cmdlets

Posted on March 12, 2018 by Michel de Rooij

powershell With the speed of development in Office 365, it is sometimes hard to track which changes have been made to your tenant. Of course, there is the roadmap and message board which you can use to keep up to date, but those are in general high level descriptions. Sometimes you may want to see what are the changes at the cmdlet level in your tenant, between tenants, or Azure Active Directory module. And there is also the occasional gem in the form of a yet undocumented cmdlet or parameter which could hint at upcoming features.

For this purpose I have created a simple script which has two purposes:

Export information on the current cmdlets available through Exchange Online or Azure Active Directory.
Compare two sets of exported information, and display changes in a readable way.

The script is in PowerShell (of course), and is called Compare-Cmdlets.ps1. To export information, you need to be already connected to either Exchange Online or Azure Active Directory (or both).

To export cmdlet information, use:

[code].\Compare-Cmdlets.ps1 –Export[/code]

For Exchange Online and Azure Active Directory, separate export files are created. The files are prefixed with a timestamp and postfixed with the Exchange Online build or Azure Active Directory module version, e.g. 201803121814-ExchangeOnline-15.20.548.21.xml or 201803121815-AzureAD-2.0.0.137.xml.

After a few days/week, or when connected to another tenant or using a new Azure Active Directory PowerShell module, run the export again. You will now have 2 sets of Exchange Online or Azure Active Directory cmdlets, which you can compare using the following sample syntax:

[code]Compare-Cmdlets.ps1 -ReferenceCmds .\201801222108-ExchangeOnline-15.20.428.21.xml -DifferenceCmds .\201803120926-ExchangeOnline-15.20.548.21.xml[/code]

A progress bar is shown as comparison might take a minute. When the script has finished checking the two sets, you will see output indicating changes in cmdlets, parameters or switches, e.g.