We've heard from customers that having a great PowerShell experience is critical in helping manage your identity needs at scale from automating tasks through scripts to managing users in bulk. Today we wanted to share the investments we're making with PowerShell that will help you save time with administrative tasks. These will be focused on, but not limited to, high-use scenarios such as user, group, and application management and role-based access controls (RBAC).
If you're using the Azure AD PowerShell or MSOnline PowerShell modules to manage Azure AD, we encourage you to try the Microsoft Graph PowerShell SDK. The Microsoft Graph PowerShell SDK is where all our current and future investments are being made.
Derrick Kimani, a program manager in the Identity Division drives our PowerShell initiatives, and his guest blog below will take you through our current and future investments in PowerShell. As always, please share your feedback in the comments below.
Alex Simons (Twitter: @Alex_A_Simons)
Corporate Vice President Program Management
Microsoft Identity Division
Hi everyone –
I'm excited to share our investments in PowerShell that make it easier to manage your identity needs and critical tasks. Today, thousands of customers use PowerShell for a wide range of tasks from monitoring and tracking data changes to managing cloud applications at scale.
Last year, we announced end of support plans for Azure Active Directory (Azure AD) Graph API in favor of Microsoft Graph. Microsoft Graph offers a single endpoint to access Microsoft 365 data. The Microsoft Graph includes all the previous Azure AD APIs and APIs from several other Microsoft services like Teams, Exchange, Intune, and more. Since the announcement last year, we've added more Azure AD APIs in Microsoft Graph such as: Advanced Query Support, Device Management, and Cloud communication.
The Microsoft Graph PowerShell SDK acts as an API wrapper for the Microsoft Graph API, exposing the entire API set for use in PowerShell. Over the coming months, we will provide usability enhancements, documentation, examples, and additional improvements to the Microsoft Graph PowerShell SDK, where we will create compound commands that map more closely to the specific tasks and scenarios admins would like to automate.
As Alex stated above, the Microsoft Graph PowerShell SDK is where all our current and future investments are being made and is the best choice for future-proofing your scripts. With broad Microsoft 365 support, full cross-platform support, and an up-to-date release cycle with the Microsoft Graph API, the Microsoft Graph PowerShell SDK will become our recommended module for administering Azure AD. It is open source and available cross-platform on PowerShell 7 and above.
Our plan with PowerShell moving forward is as follows:
- As new Identity APIs are added to Microsoft Graph, they will continue to be made available through the Microsoft Graph PowerShell SDK.
- We will provide usability enhancements, documentation, examples, and additional improvements to the Microsoft Graph PowerShell SDK on an ongoing basis.
- Our Identity-related investments in the Microsoft Graph PowerShell SDK will be focused on, but not limited to, high-use scenarios such as user, group, and application management and role-based access controls (RBAC).
Our eventual goal is that every Azure AD feature has an API in Microsoft Graph so you can administer Azure AD through the Microsoft Graph API or Microsoft Graph PowerShell SDK. If you're using other PowerShell modules to manage Azure AD, such as the Azure AD PowerShell or MSOL, we encourage you to start using Microsoft Graph PowerShell SDK.
While many customers use the Azure AD PowerShell to manage users, groups, applications, and service principals, we have stopped investing in new features for this module, and it will not be updated to work with PowerShell 7.
To get started using the Microsoft Graph PowerShell SDK, review our updated documentation and check out the GitHub wiki to find information on Microsoft Graph-based modules. We will continue to enhance samples and documentation in the coming months. The Microsoft Graph PowerShell SDK is open-source and we encourage the PowerShell scripting community to contribute to improving our identity modules. Anyone in the identity community is welcome to deliver improvements through the same open-source contribution process used by the API engineering teams.
Azure PowerShell Module & CLI
In the longer term, we're also exploring how to align the Microsoft Graph PowerShell SDK with the Azure PowerShell Module and CLI to deliver a consistent and unified terminal experience.
The Azure PowerShell modules are a set of cmdlets for managing Azure resources directly from the PowerShell command line, which can include tasks such as provisioning virtual machines, databases, and networks. While we recommend that you use the Microsoft Graph PowerShell SDK for your Azure AD needs, the Azure PowerShell Module does support a small set of cmdlets to help manage identity features such as AzADUser, AzADGroup and AzADApplication. These modules are supported on Windows PowerShell 5.1 and PowerShell 7.x and above.
We'd love to hear your feedback or suggestions on how we can improve Azure AD management within Microsoft Graph PowerShell SDK. If you have feedback or suggestions for any new modules, be sure to comment below.
Microsoft Identity Division
Learn more about Microsoft identity:
Thank you for taking the time to publish and clarify the current roadmap.
Specifically in regards to users of the AzureAD module (clarify if I am wrong):
- Their stated roadmap is to migrate to the Microsoft Graph SDK, there will not be an equivalent “AzureAD” module that will be rewritten to use MS Graph SDK
- Some commandlets in Az are expected to be the “friendly” cmdlets, however today as far as I can tell these still use the legacy AzureAD Graph API, will these be updated to use MS Graph SDK? These will also be very limited compared to what is currently offered in the AzureAD module.
- There will be no other development of “friendly” cmdlets, the Graph SDK will primarily be the autogenerated cmdlets, with guidance coming in the form of documentation and examples.
My concern is that the Graph SDK has been stated to be just that, a software SDK for powershell developers to develop against the graph SDK. This leaves “normal” administrators in a difficult position. Is Microsoft expecting that the “Az” small friendly command set is all that will be invested in making the SDK available to bridge the gap for these administrators?
If so, then is Microsoft expecting there to be community led efforts to build modules that translate the SDK direct calls into more “friendly” commands normally associated with the AzureAD module? If so then that may be a major problem, as a standard AzureAD administrator-level user will look at the new graph SDK commands, consider them extremely difficult to use or unintuitive, and stay on the AzureAD module or bail entirely to use a different solution.
@JGrote #3 is incorrect. The Identity engineering team is committed to continuing to invest in improving the “friendliness” of cmdlets available for managing AzureAD through the MS Graph SDK module. We want to ensure the community can participate and contribute in this effort, but that doesn't preclude our continued ownership for the end user experience.
I share your concern that if we don't do a good job here of making the MS Graph SDK module an experience at least as good as the AzureAD module (and hopefully better), we're doing a disservice to our customers. I don't think we get to great overnight, but I believe we have a sustainable framework in place for continuous improvement.
@RicLewisIdentity Thank you for the response!
Since the MS Graph SDK modules are generally autogenerated with AutoRest, will there be a roadmap or vision for this plan? For instance, will these be enhancing the autorest commands with a bunch of extra “calculated parameters” that do friendlier things, or will it be a new “overlay” set of commands that use the “raw” commands on the backend? Will these be bundled into separate modules (e.g. Microsoft.Graph.AzureADFriendlyCommands) to deliniate their “bespoke” crafting so people know what's been “made with love” vs what's a raw SDK API autogeneration?
A follow-up blog post on what to at least tacitly expect here would be welcome, so the community can provide feedback. Again thank you for all the hard work that the identity team performs, the graph Powershell SDK has been very useful to provide a solid type system against which to perform graph tasks.
Thank you very much for provide this information about the roadmap.
Do you think as a consequence of moving to Graph API, we will have the option to restrict powershell access?
I am trying to convert my MSOL and AZUREAD scripts to Microsoft.Graph and most cannot be replaced as the functionality doesn't exist. For example, is there a way to get a user's password expiry date from Microsoft.Graph ?
> For instance, will these be enhancing the autorest commands with a bunch of extra “calculated parameters” that do friendlier things, or will it be a new “overlay” set of commands that use the “raw” commands on the backend?
@JGrote we're still developing the practices for how to structure this, but if you're interested in seeing and contributing to the work-in-progress, take a look at one example, the Azure AD entitlement management cmdlets we're working on, in the folder https://github.com/microsoftgraph/msgraph-sdk-powershell/tree/dev/src/Identity.Governance/Identity.G… These for entitlement management will be included into a future version of the Microsoft.Graph.Identity.Governance module, and I expect that customizations to other feature's cmdlets would ship in the same module as the auto-generated cmdlets. These enhancements to the auto-generated cmdlets includes both
For example, there is also now an ask to have a cmdlet to show the available access packages and who the approvers are which could then exported to CSV.
@Mark Wahl Thank you Mark for the detail. May I suggest that, if at least the “bespoke” modules are not going to be done, that the documentation at least have an index of “non-direct-REST” commands, since the sheer list of commands will be overwhelming for a new user and they'll probably want to zone in on the “friendly” commands at first.
Thanks again for all your hard work.