Table of Contents
New Version of the MSCommerce PowerShell Module Released
Microsoft’s drive to liberate the great downtrodden masses of Microsoft 365 users from the baleful oversight of tenant administrators continues and there are now 25 different licenses available for self-purchase. That’s all very well if you buy into the theory that it’s good for people to buy their own licenses for products like Python on Excel or Viva Learning. It’s less welcome in organizations that like to exert control over licenses to keep monthly charges within reasonable boundaries.
It’s a while since I looked at self-purchase licenses. The last time I checked was after Microsoft added Teams Premium licenses to the self-service roster. This time round, my interest was sparked by the release of V2.0 of the MSCommerce PowerShell module and its rapid replacement by a V2.2 release on April 1. That version was subsequently unlisted by Microsoft and is currently unavailable, despite the publication of message center notification MC767477 (3 April) saying that V2.2 contains vital security updates and should be used. According to MC767477, all prior versions of the module will cease to work on April 17, 2024. Let’s hope that Microsoft gets V2.2 back online before then.
Still Not an Interesting Module
In any case, when an update increases the major version number, you always hope that the developers have done something exciting to warrant the appearance of a new version. Regretfully, the MsCommerce PowerShell module is still not very interesting and it seems like the developers increased the major version number out of boredom rather than for any other good reason. The module requires Windows PowerShell (version 5) and doesn’t support PowerShell 7.*. The module cmdlets behave in their own way, but at least the module seems to be stable, which is not something that has always been the case in the past (and might have been the reason why the V2.0 module was replaced so quickly).
In any case, I used the Get-MSCommerceProductPolicies cmdlet to find out how many products are now available for self-purchase. The number is now 25. Proving that I haven’t been keeping an eye on things, 12 products were enabled for self-purchase in my tenant.
Turning Off Self-Purchase for Enabled Licenses
Disabling self-purchase for all eligible licenses is quickly done by finding the set of enabled products and updating their enabled status to False. After connecting to the Commerce endpoint with the Connect-MsCommerce cmdlet, (your account needs to hold either the global or billing administrator role), running this PowerShell command did the trick:
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Where-Object {$_.PolicyValue -match 'Enabled'} | ForEach {Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductId -Enabled $False}
To check the status, run this command:
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Sort-Object ProductName | Format-Table ProductName, PolicyValue ProductName PolicyValue ----------- ----------- Dynamics 365 Marketing Disabled Dynamics 365 Marketing Additional Application Disabled Dynamics 365 Marketing Additional Non-Prod Application Disabled Dynamics 365 Marketing Attach Disabled Microsoft 365 F3 Disabled Microsoft ClipChamp Disabled Microsoft Purview Discovery Disabled Power Apps per user Disabled Power Automate per user Disabled Power Automate Per User with Attended RPA Plan Disabled Power Automate RPA Disabled Power BI Premium per user Disabled Power BI Pro Disabled Project Plan 1 Disabled Project Plan 3 Disabled Python On Excel Disabled Teams Exploratory Disabled Teams Premium Disabled Visio Plan 1 Disabled Visio Plan 2 Disabled Viva Goals Disabled Viva Learning Disabled Windows 365 Business Disabled Windows 365 Business with Windows Hybrid Benefit Disabled Windows 365 Enterprise Disabled
Although it’s easy to disable all the self-service product licenses, it’s a pain to have to check periodically for newly enabled products and disable them. One potential solution seemed to be to create a runbook for Azure Automation to execute on a scheduled basis. Regretfully, it seems that the MsCommerce PowerShell module can’t cope with Azure Automation. At least, I can find no information about getting the module to work in a runbook apart from this GitHub thread lamenting the lack of support. As commented within the thread, it would be nice if MsCommerce supported a Graph API. Perhaps Microsoft doesn’t want to make it too easy for tenants to disable self-service purchases?
Back to a Manual Check
Until the module behaves like a mature PowerShell component, I have a monthly reminder to check the enabled state for self-service purchases in my tenant. Oh well, it could be worse. At least I know that a manual check will always work.
Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.
Hello Tony, not sure if you have seen this: https://github.com/microsoft/MSCloudLoginAssistant/issues/46
but with that help I was able to create a runbook to do a daily check on it. (using a service account with proper rights)
Yes, I looked at that code and played with it a little. I am sure that I did something silly as I couldn’t get it to work.
My point is that all Microsoft modules should work predictably. The MsCommerce module never has.