Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community

AAD PowerShell Commands not working (get-msol ...)

Bronze Contributor

Could some please point out the error I'm doing?

I'm trying to create classifications


Neither Get-MsolAllSettingTemplate or Get-MsolAllSettings are recognized names for commandlets.


I have installed:

  • Microsoft Azure Active Directory Module for Windows PowerShell v.
  • Microsoft Azure PowerShell - September 2016 v3.0.0
  • Microsoft online Services Sign-in Assistant  v.7.250.4556.0
17 Replies
best response confirmed by VI_Migration (Silver Contributor)
These cmdlets are not supported in the Azure Active Directory Module for Windows PowerShell GA (v. which you have installed. Instead you can install V1.1.130.0 public preview and use it. See release notes from below link for more details.

I just ran some tests and experienced the same thing as you. I did some research and found the following info at


This is the general availability release of the V1 version ("MSOnline") of Azure Active Directory PowerShell cmdlets. The following cmdlets have been added:

  • Get-MsolCompanyAllowedDataLocation
  • Set-MsolCompanyMultiNationalEnabled
  • Set-MsolCompanyAllowedDataLocation

The following cmdlets are not available in this release but are available in the latest public preview release of Azure Active Directory PowerShell V1

  • Get-AllSettings, Get-Setting, New-Setting, Remove-Setting, Set-Setting
  • Get-AllSettingTemplate, Get-SettingTemplate 


you were faster than me :)

Thanks, I'll give it a try. But could someone explain the versioning numbers to me please :p

Why is GA version number higher than the Public Preview? I just assumed that the GA version has caught up to public preview and the page hasn't been updated.

v1.1.166.0 GA

v1.1.130.0 Preview


EDIT1: just tried to install the preview version over the GA version and as assumed the setup says a newer version is already installed :)

Guess I'll have to use some other machine to install the public preview version.


EDIT2: commands are working in the public preview version. Though I'm able to follow the instructions for creating classification labels, but thats a topic for a different thread :)




We have one build system that build both a preview version and a GA version in the same run. Since this module is going to be deprecated in favor of the newer AzureAD V2 PowerShell module we do not add any new functionality to it and usually only release it when previously released cmdlets in a preview version are moved into GA status.

Hi @SanthoshB1 - I've been trying to evaluate the ability to limit the creation of Groups as discussed in this thread, however, it now appears that all links to the version of the Azure AD module (v1.1.130.0) have been removed from the associated and linked to pages.  Therefore I am at a loss to know how to proceed as the no other versions of the module appear to have the cmdlets and the necessary module is unavailable.  Has the overall approach changed?  I would have thought that the introduction of Microsoft Teams will have re-ignited the question of governance with regards to the proliferation of Office 365 Groups.


Can anyone provide any guidance here, please?

These cmdlets were in preview and have moved to the newer AzureAd V2 module

Hi @SimonChalfont @Ivan Unger @Dean_Gross @SanthoshB1,


The Settings cmdlets that were previously published in a preview release of the MSOL module are no longer available there. As we are deprecating the MSOL module, no more preview releases are made available and no new functionality will be added to that module.


The Settings cmdlets ycan now be found in the newer Azure AD PowerShell V2 Preview module, which can be installed from here:

More information about how to use the new cmdlets for Settings can be found here:

More information about the Azure AD PowerShell V2 module can be found here:


Please reach out to me if you have any questions or concerns.


-Rob (

@Rob de Jong Is there anything available that describes how the movement of the old cmdlets to the new modules, i.e., a cross-reference map of some kind?


Also, it can be quite challenging to understand what cmdlets are available in Preview vs GA. There is something about the docs for the modules that makes this unclear and complicated for many of us. I get confused because the version number scheme does not give any clues about the modules status, i.e., and were Preview, but and were GA. The way that the Release notes present the changes, makes it very difficult to figure out what has happened when we are trying to work out how to update an older example.


It would be helpful if there was something that explained how we should work when we have both modules installed (or even if this is a recommended approach.


The list of cmdlets on is not very readable which keeps it from being very helpful

Hi Dean, thanks for your response and feedback.

I'm currently working on a cross reference document between V1 and V2 cmdlets, I hope to get this out soon. I'm also working on an article that better explains the migration plan from V1 to V2 and what sort of timelines we're thinking about for the deprecation of V1.


The question about Preview vs GA, version numbers and which cmdlets are where came up several times now so I'm adding some additional content to the documentation there as well. But here's the short version:

We release our PowerShell in modules on the PowerShell Gallery. A module consists of a set of DLLs, one for each API endpoint we call. Which cmdlet goes where is determined by a configuration file for each of the modules - so a release consists of a subset of all the DLLs that came out of the build, and all of these DLLs have the same version number, e.e. 

We have a build system that creates a daily build for 3 V2 module releases: a private build, a public preview build and a general availability build.

The idea here is that if we have something brand new that someone either internally or externally needs to try out we can get them the private build. THis build will always contain the latest and greatest of everything we have, but may not be completely tested and documented.
All cmdlets that have been approved for release always go into the public preview build, and this build is usually published on the PowerShell gallery as soon as there are changes. So when you're looking for a certain cmdlet and want to be sure you have the latest version, this will always be on, which will redirect you to the latest version. Note that preview cmdlets can still change and these changes may potentially break any scripts or preocesses in which they are used, so we recommend not using them in a production environment.
The General Availability release needs to pass certain gates first: fully tested,fully documented, all; API's it uses must be GA too, only using public API's etc. As soon as a cmdlet passes these gates in can be promoted into the GA release. GA also means "fully supported by Microsoft". The GA release is always a subset of the Public Preview release.

So this is why the version numbers are independent of the release types. We could potentially release a preview and a GA version at the same time and they would have the same version numbers - but the module names would be different - AzureAD vs AzureADPreview.

What I can do to help clarify which cmdlet is in which release is add, to the preview release notes, a list of all cmdlets that are in preview and not in the GA version. Would that help?

Any other suggestions to help create more clarity?





What is most maddening is that even when we see which versions have the PS cmdlet's we need, it redirects to the latest release to download which may not have them. Higher version number, but oddly enough drops previous version cmdlets in the same version branch. Really? Took me a while to figure that out and then how to get an older preview release to use the cmdlet's I needed to control O365 Group Creation. Nevermind that many blog posts on this topic, most importantly those created by Microsoft, refer to a specific v1 preview version of MSOL module cmdlets that is not available for download anywhere right now. The adding and dropping of these critical cmdlets is maddening to anyone simply trying to follow some instructions. I'd appreciate if MS paid a little closer attention to older versions that have cmdlets that were not brought forward. Leave those as available. Don't take them down/redirect please.

While we wait for the official documentation to be updated, I can recommend this blog post to which I was referred on a separate thread:


Hope it helps.


Hi Christopher, thanks for your feedback.

Please note: the MSOL preview cmdlets for Settings have not stopped working and can be used just as before. However, since we have deprecated these cmdlets and replaced them with newer cmdlets in the V2 module we no longer publish the module in in which they were exposed.

To answer your question about releases and versions:
There are two releases for Azure AD PowerShell that our team publishes: the preview release and the GA release. As I mentioned in my previous comment, the GA release is a subset of the preview release.

These two releases have separate download links: for the preview release, and for the GA release.

Both these links will redirect to the latest version. If you scroll down the download page you will see all older versions and can go to their respective module pages. There are currently 18 older versions of the preview module available for installation.

To install the preview version, you would use Install-module AzureADPreview, to install the GA version use Install-Module AzureAD. The Install-module cmdlet always installs the latest version of a module. If you require a previous version you can install this by specifying the -required version parameter, as in:

Install-module AzureADPreview -RequiredVersion


The reason we publish preview versions of the module is that we know that for new capabilities, customers often like to get their hands on them as quickly as possible to investigate the new functionality. We encourage this as it often provides valuable feedback that allows us to improve and fine tune our cmdlets based on this feedback. Note that these improvements could potentially introduce breaking changes, so we mention in all of our documentation that preview cmdlets should not be used in a production environment.

A breaking change was introduced for the MSOL Setting cmdlets when we moved those to the Azure AD PowerShell V2 module. The full capability of the cmdlets is available in V2 and has not changed.
I'm sorry if this change has caused confusion.

We are working with teams within Microsoft and with 3rd parties that have pubished references to the MSOL Settings cmdlets to get these updated to reflect this change.

Thanks again for your feedback.


for me the most confusing part was that a lower build number preview had commandlets that a higher version build GA version did not have.
V2 helps in this regard, with the -preview prefix for commands. I believe those were not available in v1, right?
For me it wasn't clear that those were not preview versions in v1, but in reality a completely different release channel. What didn't help either was, that the preview channel didn't include commandlets from previous versions.  

When (and/or where) will the cross reference between MSOL (v1) and Azure AD (v2) come?


I am currently working on "translation" a v1 script to be v2-compliant, and is specifically missing the v2 version of the "Get-MOSLCompanyInformation"-cmdlet.

Hi - we're currently working on that plan, I expect it to get published in the coming weeks. 

Just in case you didn't find the information to cull GROUP creation in Office 365.

Import-Module MSOnline
get-module MSOnlineService
Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -GroupCreationEnabled $false


1 best response

Accepted Solutions
best response confirmed by VI_Migration (Silver Contributor)
These cmdlets are not supported in the Azure Active Directory Module for Windows PowerShell GA (v. which you have installed. Instead you can install V1.1.130.0 public preview and use it. See release notes from below link for more details.

View solution in original post