Blog Post

Microsoft Entra Blog
6 MIN READ

Introducing the Microsoft Entra PowerShell module

SteveMutungi's avatar
SteveMutungi
Icon for Microsoft rankMicrosoft
Jun 27, 2024

We’re thrilled to announce the public preview of the Microsoft Entra PowerShell module, a new high-quality and scenario-focused PowerShell module designed to streamline management and automation for the Microsoft Entra product family. In 2021, we announced that all our future PowerShell investments would be in the Microsoft Graph PowerShell SDK. Today, we’re launching the next major step on this journey. The Microsoft Entra PowerShell module (Microsoft.Graph.Entra) is a part of our ongoing commitment and increased investment in Microsoft Graph PowerShell SDK to improve your experience and empower automation with Microsoft Entra.

 

We’re grateful for the substantial feedback we’ve heard from Microsoft Entra customers about our PowerShell experiences, and we’re excited to hear your thoughts after evaluating this preview module. We plan to build on our investment in the Microsoft Entra PowerShell module going forward and expand its coverage of resources and scenarios. 

 

What is Microsoft Entra PowerShell?

 

The Microsoft Entra PowerShell module is a command-line tool that allows administrators to manage and automate Microsoft Entra resources programmatically. This includes efficiently managing users, groups, applications, service principals, policies, and more. The module builds upon and is part of the Microsoft Graph PowerShell SDK. It’s fully interoperable with all cmdlets in the Microsoft Graph PowerShell SDK, enabling you to perform complex operations with simple, well-documented commands. The module also offers a backward compatibility option with the deprecated AzureAD module to accelerate migration. Microsoft Entra PowerShell supports PowerShell version 5.1 and version 7+. We recommend using PowerShell version 7 or higher with the Microsoft Entra PowerShell module on all platforms, including Windows, Linux, and macOS.

 

Benefits of Microsoft Entra PowerShell

 

  • Focus on usability and quality: Microsoft Entra PowerShell offers human-readable parameters, deliberate parameter set specification, inline documentation, and core PowerShell fundamentals like pipelining.
  • Backward compatibility with AzureAD module: Microsoft Entra PowerShell accelerates migration from the recently announced AzureAD module deprecation.
  • Flexible and granular authorization: Consistent with Microsoft Graph PowerShell SDK, Microsoft Entra PowerShell enables administrative consent for the permissions you want to grant to the application and supports specifying your own application identity for maximum granularity in app permission assignment. You can also use certificate, Service Principal, or Managed Identity authentication patterns.
  • Open source: The Microsoft Entra PowerShell module is open source, allowing contributions from the community to create great PowerShell experiences and share them with everyone. Open source promotes collaboration and facilitates the development of innovative business solutions. You can view Microsoft's customizations and adapt them to meet your needs.

 

Next steps

 

Installation: Install Microsoft Entra PowerShell, which uses the “/v1.0” API version to manage Microsoft Graph resources, from the PowerShell Gallery by running this command:

 

Install-Module Microsoft.Graph.Entra -AllowPrerelease -Repository PSGallery -Force

 

Or install the Beta module, which manages Microsoft Graph resources using the "/beta" API version, by running this command:

 

Install-Module Microsoft.Graph.Entra.Beta -AllowPrerelease -Repository PSGallery -Force

 

Authentication: Use the Connect-Entra command to sign in to Microsoft Entra ID with delegated access (interactive) or application-only access (noninteractive).

 

Connect-Entra -TenantId 'your-tenant-id' -Scopes 'User.Read.All'

 

To see more examples for using your own registered application, Service Principal, Managed Identity, and other authentication methods, see the Connect-Entra command documentation.

 

Find all available commands: You can list all available commands in the Microsoft Entra PowerShell module by using the command:

 

Get-Command -Module Microsoft.Graph.Entra

 

Get Help: The Get-Help command shows detailed information about specific commands, such as syntax, parameters, cmdlet description, and usage examples. For example, to learn more about the Get-EntraUser command, run:

 

Get-Help Get-EntraUser -Full

 

Migrating from AzureAD PowerShell module: You can run your existing AzureAD PowerShell scripts with minimal modifications using Microsoft Entra PowerShell by using the Enable-EntraAzureADAlias command. For example:

 

Import-Module -Name Microsoft.Graph.Entra

Connect-Entra #Replaces Connect-AzureAD for auth

Enable-EntraAzureADAlias #enable aliasing 

Get-AzureADUser -Top 1

 

Frequently Asked Questions (FAQs)

 

What is the difference between the Microsoft Graph PowerShell SDK and Microsoft Entra PowerShell modules?

 

Microsoft Entra PowerShell is a part of our increased investment in Microsoft Graph PowerShell SDK. It brings high-quality and scenario-optimized Entra resource management to the Microsoft Graph PowerShell SDK. Still, it keeps all the benefits of Microsoft Graph PowerShell SDK for authorization, connection management, error handling, and (low-level) API coverage. As Microsoft Entra PowerShell builds on the Microsoft Graph PowerShell SDK, it is completely interoperable.

 

Is the Microsoft Entra PowerShell module compatible with Microsoft Graph PowerShell?

 

Yes. You don't need to switch if you’ve already used the Microsoft Graph PowerShell module. Both modules work well together, and whether you use Entra module cmdlets or Microsoft Graph PowerShell SDK cmdlets for Entra resources is a matter of preference.

 

I need to migrate from the deprecated AzureAD or MSOnline modules. Should I wait for Microsoft Entra PowerShell?

 

No. One of our goals with Microsoft Entra PowerShell is to help you migrate from Azure AD PowerShell more quickly by setting Enable-EntraAzureADAlias. Microsoft Entra PowerShell supports simplified migration for scripts that were using AzureAD PowerShell, with over 98% compatibility. However, the legacy AzureAD and MSOnline PowerShell modules are deprecated and will be retired (stop working) after March 30, 2025. We recommend that you act now to begin migrating your MSOnline and AzureAD PowerShell scripts. 

 

Both modules use the latest Microsoft Graph APIs. For test environments and non-production systems, you can migrate to Microsoft Entra PowerShell. We recommend migrating to this module for production systems only after it reaches general availability. If you migrate scripts to Microsoft Graph PowerShell SDK now, there is no need to update them again with Microsoft Entra PowerShell, as it enhances and will not replace Microsoft Graph PowerShell SDK.

 

Should I update Microsoft Graph PowerShell scripts to Microsoft Entra PowerShell?

 

This is not necessary but a matter of preference. Microsoft Entra PowerShell is part of the Microsoft Graph PowerShell solution, and the two modules are interoperable. You can install both modules side-by-side.

 

Will Microsoft Entra PowerShell add support for more resources in the future?

 

Yes, it is a long-term investment. We will continue to expand support for more resources and scenarios over time. Expect new cmdlets for Privileged Identity Management (PIM), Entitlement Management, Tenant Configuration settings, Per-User multifactor authentication (MFA), and more. We'll also enhance existing cmdlets with additional parameters, detailed help, and intuitive names. Check out GitHub repo for ongoing updates.

 

Will Microsoft Entra PowerShell use a pre-consented app like AzureAD or MSOnline modules?

 

No. Microsoft Entra PowerShell permissions aren't preauthorized, and users must request the specific app permissions needed. This granularity ensures that the application has only the necessary permissions, providing granular control over resource management. For maximum flexibility and granularity in application permissions, we recommend using your own application identity with Entra PowerShell. By creating different applications for different uses of PowerShell in your tenant, you can have exacting control over application permissions granted for specific scenarios. To use your own application identity with Microsoft Entra PowerShell, you can use the Connect-Entra cmdlet:

 

Connect-Entra -ClientId 'YOUR_APP_ID' -TenantId 'YOUR_TENANT_ID' 

 

I am new to Microsoft Entra PowerShell; where do I start?

 

Explore our public documentation to learn how to install the Microsoft Entra PowerShell module, authenticate, discover which cmdlet to use for a particular scenario, read how-to guides, and more. Our best practice guide will help you start on a secure foundation.

 

How can I provide feedback?

 

You can provide feedback by visiting our GitHub repository issues section. Create a new issue with your feedback, suggestions, or any problems you've encountered. Our team actively monitors and responds to feedback to improve the module. 

 

How can I contribute?

 

We welcome contributions from the community, whether it's through submitting bug reports, suggesting new features, or contributing scenario and example improvements. To get started, visit the GitHub repository, check out our contribution guidelines, and create a pull request with your changes.

 

Learn more about Microsoft Entra PowerShell module

 

Explore our public documentation, to learn how to install the Microsoft Entra PowerShell module, the authentication methods available, which cmdlet to use for a particular scenario, how-to guides, and more.

 

Try It Today

 

Try out the new version and let us know what you think on GitHub! Your insights are invaluable as we continue to improve and enhance the module to better meet your needs.

 

Thank you!

 

We want to thank all the community members who helped us improve this release by reporting issues on GitHub during the private preview! Please keep them coming!

 

Steve Mutungi

Product Manager, Microsoft Entra PowerShell

 

 

Read more on this topic

 

Learn more about Microsoft Entra 

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

Updated Jun 28, 2024
Version 5.0
Announcements and Product News
  • DevOpsMaverick's avatar
    DevOpsMaverick
    Brass Contributor
    Jun 27, 2024

    Should the Beta module not be called Microsoft.Graph.Beta.Entra to align with the other Microsoft Graph PowerShell SDK Beta modules?

  • ians-uleth's avatar
    ians-uleth
    Iron Contributor
    Jun 27, 2024

    Well, something had to change given how well the transition to the Graph SDK was going. So I am glad to see some real improvements, though this is... unexpected, and confusing.

     

    I would guess that one thing most administrators will be looking to see resolved is SDK-API finger pointing scenarios to come to an end. As in, the SDK not properly supporting a feature from the API, the SDK team pointing the finger at the API team, while the API team points the finger back at the SDK team, in an infinite loop while the SDK feature remains broken for months (or longer!) This doesn't seem to have the potential to address that, as it relies on the same imperfect API translation layer?

     

    Will Microsoft Entra PowerShell use a pre-consented app like AzureAD or MSOnline modules?

    No. Microsoft Entra PowerShell permissions aren't preauthorized, and users must request the specific app permissions needed. This granularity ensures that the application has only the necessary permissions, providing granular control over resource management.

    I don't really buy this argument, not when you had the opportunity to do something better in this module. You developed a module with the understanding that the developer-focused modules were not meeting needs, and I would argue this was not tackled simply due to time or resources, and you fail to own up to that (further emphasized by the fact that you still require the API's parameter of TenantId.) Many administrators will simply connect with scope Organization.ReadWrite.All, and we all know it, so the granular permissions argument, in my mind, holds little water given the intention and target audience of this specific module. This is just lazy.

     

    Also, cmdlets such as Get-EntraUser still use parameters with names like ObjectId, versus something more "human-readable" as you said would be the case like UserPrincipalName.

     

    My final thought is why continue pushing this API translation layer so hard, when other Microsoft 365 teams continue not to go down this road? If it has proven to be this problematic, why write a new module that still incorporates most of what has failed? For example, the Teams and Exchange Online teams have PowerShell modules that do not rely on such a translation layer, and those modules work well, and are well received.

     

    I mean, I get that you can't please everybody, but this is your solution? You should have just invested this time into improving the existing Graph SDK modules and their documentation, instead of just confusing everybody even more.

  • merillms's avatar
    merillms
    Icon for Microsoft rankMicrosoft
    Jun 28, 2024

    ians-uleth 

     

    I would guess that one thing most administrators will be looking to see resolved is SDK-API finger pointing scenarios to come to an end.

    We understand the frustration here and have worked with the Entra service owners to resolve issues when alerted. Please raise any issues you come across on Entra PowerShell in GitHub and we will work with service owners to have the issues fixed.

     

    Will Microsoft Entra PowerShell use a pre-consented app like AzureAD or MSOnline modules? No

    I don't really buy this argument....This is just lazy.

    This is intentional. Pre-consented Graph permissions for Azure AD and MSOL have allowed threat actors and offensive tool builders to leverage this powerful service principle to gain API access to tenants. While we do understand admins can consent to privileged permissions, our goal is to provide a solution that is secure-by-design and secure-by-default. This will ensure the millions of tenants that don't use PowerShell, to be protected and gives the flexibility for admins to restrict the permission of the Graph client to specific users and permission scopes. In our updated docs we provide guidance on following a least privilege model.

     

    On a side note, the Organization.ReadWrite.All is not a very privileged scope, maybe you were referring to Directory.ReadWrite.All? Even in this case it is limited to core directory permission and does not by default grant access to privileged operations such as updating conditional access policies.

     

    ...why continue pushing this API translation layer...

    While the initial release of Entra PowerShell does rely on a translation layer, we don't plan on extending its use to new cmdlets.

     

    ...invested this time into improving the existing Graph SDK modules and their documentation...

    Graph PowerShell SDK has a much wider use case and covers all of Microsoft 365, as such it aims to stay as close as possible to the Graph REST API. It also follows a very rapid release cycle based on auto generated content. 

     

    The Entra and Graph PowerShell teams work together and have been working on improving the quality of Graph PowerShell docs. This can be seen in the improvements that have been made to the docs in the last few months including least privilege permission scopes, rich examples and cloud specific support. A good example is https://learn.microsoft.com/en-us/graph/api/user-get?view=graph-rest-1.0&tabs=http

     

     

  • TonyRedmond's avatar
    TonyRedmond
    MVP
    Jul 01, 2024

    My view:

     

    Practical Graph: Microsoft Launches Entra PowerShell Module

     

    On June 27, 2024, Microsoft launched the preview of the Entra PowerShell module. Built on top of the Microsoft Graph PowerShell SDK, the new module helps organizations that still have PowerShell scripts based on the now-deprecated AzureAD and AzureADPreview modules. If you're in that situation, the Entra module might help. But overall, I recommend using the Microsoft Graph PowerShell SDK instead.

     

    https://practical365.com/entra-powershell-module/

  • JamesC95's avatar
    JamesC95
    Brass Contributor
    Jul 23, 2024

    I think a lot of confusion has been generated with making this look like a separate thing to the Graph modules

     

    Please get rid of the Connect-Entra cmdlets, and just instruct users to use the Connect-MgGraph as they already do with the other Microsft.Graph modules. Duplicating functionality in this way clearly causes confusion

     

  • aidahl's avatar
    aidahl
    Copper Contributor
    Jun 27, 2024

    What’s the benefit of using this module instead of the current in Microsoft Graph Users/Groups/Applications 2.x.x modules, and does this support anything new those do not?

  • cblackuk1's avatar
    cblackuk1
    MVP
    Jun 28, 2024

    Really nice to see a new module to "replace" AzureAD ones 🙂

    Thanks for sharing 🙂

     

    Happy Azure Stacking!!!

  • JamesC95's avatar
    JamesC95
    Brass Contributor
    Jun 28, 2024

    This is interesting and a more 'admin friendly' module for tasks would be welcome considering the existing Graph module is barely a wrapper over the API

     

    However disappointing that even in V1.0 some obvious things aren't possible

    e.g. Get-EntraUser -UserPrincipalName [email]

    or being able to easily query readable properties

    e.g. Get-EntraUserMembership -UserPrincipalName [email] | Where-Object { $_.DisplayName -eq "My Group"}

     

    It would be nice to see this as a layer to making admin tasks a little more friendly. Its definitely not there at the moment

  • ians-uleth's avatar
    ians-uleth
    Iron Contributor
    Jun 28, 2024

    Thank you merillms, I appreciate the clarification you provided, especially regarding not necessarily relying upon the API translation layer (that alone will be huge.) I am excited to see how this module shapes up and where it takes us.

     

    I suppose you can answer my follow-up question and JamesC95's together - existing cmdlets that are currently implemented using the API translation layer, such as Get-EntraUser and Get-EntraUserMembership seem to be highly reflective of the API at the moment, obviously. Does the Entra module's current implementation allow for more user-friendly things such as what JamesC95 is saying in the short-term with just some quick over-the-top customization by the development team, or would these things be a longer-term goal for the development team in uncoupling these cmdlets from the API translation layer?