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.
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
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.
On October 23rd, Microsoft announced – a little out of the blue – they were going to introduce self-service purchase options for users on November 19th. The details of this change were put forward in a post in the message center, article MC193609 to be exact. In short, this option would introduce the following changes for commercial tenants:
Allow end users to purchase Power Platform related subscriptions using their own payment method, e.g. Power Apps, Automate (formerly Flow) or PowerBI Pro.
These subscriptions could be made in their employee’s tenant, with the exception of government, non-profit and education.
It would not end with Power Platform subscriptions.
To make purchases, end users would be able to open a restricted view of the Microsoft 365 Admin Center.
While a handful individuals cheered ‘Power to the end user’, the vast majority of organizations were very unhappy with this development to say the least. This adoption booster would not only be opposing Microsoft’s own ‘Cloud on your terms’ and ‘Your tenant, your data’ principles they have been telling customers for years, it could also severely impact enterprise security and governance policies (or absence thereof), let alone lead to discussions when people expense their PowerBI Pro purchase. And I’m not even talking about the absence of admin controls.
So, swiftly after the massive backlash on social media, UserVoice as well as other channels, the announcement was altered, and a FAQ was published, which you can read here. The change itself was postponed until January 14th, 2020, and organizations would be handed controls to turn self-service purchases off before roll out.
Rather quietly, details on how to disable self-service purchase have been added to the FAQ. To read on how to accomplish this, continue reading my original blog post over at ENow by clicking here.
EighTwOne (821) 