Forum Discussion
AAD PowerShell Commands not working (get-msol ...)
- These cmdlets are not supported in the Azure Active Directory Module for Windows PowerShell GA (v.1.1.166.0) 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.
http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185
http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185
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?
Rob de JongMicrosoft
Hi SimonChalfont Ivan54 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: https://www.powershellgallery.com/packages/AzureADPreview
More information about how to use the new cmdlets for Settings can be found here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-settings-cmdlets
More information about the Azure AD PowerShell V2 module can be found here: https://docs.microsoft.com/en-us/powershell/azuread/
Please reach out to me if you have any questions or concerns.
-Rob (Rodejo@Microsoft.com)
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., 2.0.0.52 and 2.0.0.76 were Preview, but 2.0.0.55 and 2.0.0.71 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 https://www.powershellgallery.com/packages/AzureAD/2.0.0.71 is not very readable which keeps it from being very helpful
- Rob de Jong
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. 2.0.0.89
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 https://www.powershellgallery.com/packages/azureadpreview, 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?
Thanks,Rob
