Microsoft announced the deprecation of the Azure AD PowerShell and Microsoft Online Modules in late 2022.
Microsoft has been working hard to merge these two modules together into a new Module, called Microsoft Graph PowerShell SDK.
This is a wrapper for their Microsoft Graph API – This is a major over hall and improvement over the current module, which has brought the benefits below:
- Access to all Microsoft Graph APIs: Microsoft Graph PowerShell is based on Microsoft Graph API. The Microsoft Graph API includes, in addition to Azure AD, APIs from other Microsoft services like SharePoint, Exchange, and Outlook, all accessed through a single endpoint with a single access token.
- Supports PowerShell 7: Microsoft Graph PowerShell module works with PowerShell 7 and later. It’s also compatible with Windows PowerShell 5.1.
- Cross-platform support: Microsoft Graph PowerShell module works on all platforms including Windows, macOS, and Linux.
- Supports modern authentication: Microsoft Graph PowerShell supports the Microsoft Authentication Library (MSAL) which offers more security. For example, you can use Passwordless sign-in experiences.
- Supports external identities: Users from other Azure AD tenants can authenticate to services in your tenant with Microsoft Graph PowerShell.
- Uses least privilege: Microsoft Graph PowerShell permissions are NOT pre-authorized, and users must perform a one-time request for app permissions depending on their needs.
- Advanced queries: Microsoft Graph PowerShell supports rich, advanced queries via eventual consistency. For example, you can get a near-instant count of all users using advanced queries.
- Open source: Feature teams and the community can create great PowerShell experiences and share them with everyone.
- Receives regular updates: Microsoft Graph PowerShell commands are updated regularly to support the latest Graph API updates.
One of our Cloud Engineers, Mark has been working on getting Atria Migrated to using the newer Modules. We’ve asked him some questions which we hope will help you and your businesses carry out this migration and understand some of the hurdles we’ve faced when carrying this out.
What is the big change in MG Graph compared to the previous Azure AD + Microsoft Online Modules?
Scoping has been added to connection parameters but since Atria uses the Microsoft Secure App Model, this is not used if connecting using token based auth as the application API permissions are followed.
The whole module has a lot of new functionality added and can’t be imported as a whole in PowerShell versions earlier that version 7. So, I opted to import needed sub modules only (e.g., Import-Module -Name Microsoft.Graph.Users).
Below is an excerpt on the official Issue List for the SDK description this issue – https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/1449#issuecomment-1213550597
Returned dataset column headers are also different so I had to re-process data to rename the headers to the same set returned by the older module.
How did you find the new cmdlets in MG Graph compared to AzureAD / Msol?
I found the new cmdlets the same as before except some has changed parameter names and others were added new parameter sets. More functions were added to simplify scripting with a few lines that would be useful in writing more advanced scripts.
This made the migration easy, because there was usually a logical transition using the Cmdlet map provided by Microsoft – Find Azure AD and MSOnline cmdlets in Microsoft Graph PowerShell | Microsoft Learn
For some of the commands they do not have replacements (Such as Confirm-MsolEmailVerifiedDomain) but they have typically been merged with a similar cmdlet (Such as Confirm-MsolDomain).
What kind of issues did you face moving to match the same formatting?
To save time, I casted the objects returned by the migrated scripts to object arrays. This ensures that the variables always contain arrays, even if the result count is just one object, so that object counts are properly calculated in conditional statements. Additionally, some data had to be casted to other data types to match the data type declared in the code from the previous modules. By doing this, I was able to avoid making backend data changes and ultimately save time during the migration process.
An example of this is the domain Verification is no longer a Boolean response, it returns a Microsoft Object type of [Microsoft.Online.Administration.DomainStatus]::Verified instead of “True” or “False” so a condition was created for us to use in future code to know the status.
Are there any major changes in cmdlets between versions?
Only one major change has affected us and our integration, this is specifically around the provisioning of Domains in Azure when using domain federation.
The Boolean property “SupportsMfa” has now changed to “FederatedIdpMfaBehavior” with three option values depending on how you configured ADFS federation.
The Supports MFA configuration option is still present against the domains, but once the command has been run with the federatedIdpMfaBehavior Property specified, this will trigger Azure to ignore the SupportsMFA property once it is set.
A screenshot of the federatedIdpMfaBehavior value is below, and described in this KB:
Anything else you found interesting about the process in migrating the scripts?
In migrating the scripts, I learnt more about how the online modules work. It is always interesting to learn new things you don’t usually do daily. I am glad that I was a part of this project.
If you have any questions or need assistance message us we would be happy to assist contact us.
