Microsoft Graph vs Azure PowerShell: Key Differences & Capabilities
Microsoft Graph vs Azure PowerShell: Key Differences & Capabilities Introduction I have been asked a number of times by connections and in DMs over the last few weeks about Microsoft Graph and Azure PowerShell – so I figured I would put together a post on this topic – afterall knowledge sharing is knowledge learned. Both Microsoft Graph and Azure PowerShell are powerful tools for managing Microsoft cloud services, but they serve different purposes. Microsoft Graph is the unified REST API that spans across Microsoft 365 services (Azure AD, Teams, Exchange, SharePoint, etc.), while Azure PowerShell refers to the PowerShell modules for managing Azure resources (and previously Azure AD) in a command-line context. Understanding the differences is important for administrators, especially as Microsoft is moving more functionality to Graph (and deprecating some older Azure PowerShell modules). In this post, I will compare their key differences, see how each can be used in practice, and discuss transitioning from Azure PowerShell (AzureAD/MSOL) to Microsoft Graph. Comparison Table: Microsoft Graph vs Azure PowerShell Below is a comparison of key aspects of Microsoft Graph (PowerShell SDK) and Azure PowerShell (specifically the AzureAD PowerShell module for Azure Active Directory tasks, as an example): Practical Scenario & PowerShell Script Examples To illustrate the difference in execution, consider a practical scenario: Creating a new user in Entra ID (Azure AD). Below are two script snippets that achieve the same goal – one using Microsoft Graph PowerShell and one using the AzureAD PowerShell module. Both will create a new user account, but notice the differences in how they authenticate and the cmdlet syntax: Using Microsoft Graph PowerShell: # Connect to Microsoft Graph with the necessary scope (permission) for user management Connect-MgGraph -Scopes “User.ReadWrite.All” # Define a password profile for the new user $passwordProfile = @{ Password = “P@ssw0rd!” } # Create a new user via Microsoft Graph API (through the Graph PowerShell SDK) New-MgUser -DisplayName “John Doe” ` -UserPrincipalName “john.doe@contoso.com” ` -MailNickname “john.doe” ` -AccountEnabled $true ` -PasswordProfile $passwordProfile # The above commands connect to Microsoft Graph and then create a new Azure AD user named John Doe with the specified UPN and password. # Benefit: This uses Microsoft Graph’s up-to-date API, allowing access to the latest Azure AD features and ensuring compatibility with future updates (Graph is the modern approach). Using Azure PowerShell (AzureAD module): # Connect to Azure AD using the AzureAD module Connect-AzureAD # Prepare a password profile object for the new user (AzureAD module requires a specific object type) $newUserPassword = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile $newUserPassword.Password = “P@ssw0rd!” # Create a new user using AzureAD PowerShell module New-AzureADUser -DisplayName “John Doe” ` -UserPrincipalName “john.doe@contoso.com” ` -MailNickname “john.doe” ` -AccountEnabled $true ` -PasswordProfile $newUserPassword # This connects to Azure AD and creates the same user. # Benefit: AzureAD cmdlets are simple and were purpose-built for Azure AD tasks, which made them easy to use for administrators familiar with PowerShell. Explanation In the Graph script, we use Connect-MgGraph with an OAuth scope, reflecting Graph’s need for consent to specific permissions. We then call New-MgUser – a Graph cmdlet – to create the user. In the AzureAD version, we simply do Connect-AzureAD (which uses your account’s credentials) and then New-AzureADUser. One immediate difference is authentication; Graph encourages a scoped OAuth token (more secure and fine-grained), whereas AzureAD module uses your account context directly. Also, Graph’s cmdlet is part of a broader SDK that can manage more than just users, whereas New-AzureADUser is from a module solely focused on Azure AD. # Update Note # Original $newUserPassword in the AzureAD module was: $newUserPassword = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile # Changed to: $newUserPassword = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile # Change Reason: #Microsoft.Open.AzureAD.Model.PasswordProfile was the part of Azure AD for Graph (Azure AD v2), and Azure AD for Graph (Azure AD v2) is deprecated. Migration & Best Practices With Microsoft’s shift toward Graph, many organisations are transitioning from AzureAD/MSOL PowerShell modules to Microsoft Graph PowerShell. In fact, Microsoft Graph PowerShell is the official replacement for the AzureAD and MSOL modules. Here are some key points and best practices for migrating and working across both tools: Plan the Migration: Start by identifying all scripts and processes that use the AzureAD or MSOL modules. These legacy modules are deprecated and may run the risk of stopping entirely after the retirement date (30 March, 2025). List out those scripts – for each, there should be an equivalent approach using Microsoft Graph PowerShell SDK (https://tinyurl.com/4rwp8c4y). Map Out Equivalent Cmdlets: The Graph PowerShell SDK cmdlet names are different from AzureAD module cmdlets. For example, Get-AzureADUser becomes Get-MgUser, New-AzureADGroup becomes New-MgGroup, etc. Microsoft has provided a migration guide (https://tinyurl.com/2s3p3cyh) to help find Graph equivalents. Update your scripts by replacing old commands with the new Graph commands. Keep in mind that parameters might differ slightly, and Graph cmdlets may require specifying properties or filters to get the same data. Modernise Authentication: One of the key differences when migrating is how you handle authentication. The AzureAD module allowed using Azure AD credentials (often with less granular permissions). In Graph, you should use Connect-MgGraph with the appropriate scopes, or set up an app registration for app-only access in automation scenarios. This means possibly updating how your scripts authenticate – e.g., using certificate-based auth for unattended scripts or interactive device login for ad-hoc runs. The benefit is improved security (MSAL and modern auth with token scopes) compared to legacy ADAL-based auth. Ensure your environment is ready for this (you might need to register an Azure AD app and grant it admin-consent for certain Graph scopes). Test Thoroughly: Because the output objects and behaviors can differ, test your updated scripts in a non-production environment. For instance, Graph cmdlets might return different default properties than AzureAD cmdlets did. Verify that the new scripts perform the intended tasks (create the users, update the groups, etc.) and that all required data is being handled. Pay attention to any Graph-specific considerations, like throttling limits or required permission consent – adjust your approach if needed