➖ ➕ Remove PSNotification, replace AzureAd with Microsoft.Graph

[FH-Inway]

Since we replaced the Azure.Storage with the Az.Storage dependency (see #361 ), I took a look at the other PowerShell module dependencies:

d365fo.tools/d365fo.tools/d365fo.tools.psd1

Lines 30 to 37 in f5f9069

	RequiredModules = @(
	@{ ModuleName = 'PSFramework'; ModuleVersion = '1.0.12' }
	, @{ ModuleName = 'Az.Storage'; ModuleVersion = '1.11.0' }
	, @{ ModuleName = 'AzureAd'; ModuleVersion = '2.0.1.16' }
	, @{ ModuleName = 'PSNotification'; ModuleVersion = '0.5.3' }
	, @{ ModuleName = 'PSOAuthHelper'; ModuleVersion = '0.3.0' }
	, @{ ModuleName = 'ImportExcel'; ModuleVersion = '7.1.0' }
	)

• PSNotification is (no longer?) used by the module and can be removed
• AzureAd is deprecated and could potentially be replaced with Microsoft.Graph modules

This issue is mainly about the AzureAd replacement. For now, I think there is no urgency behind the replacement, but eventually, it should be done. The issue was created to kick things off and act as a central point to coordinate efforts.

Deprecation

Azure AD PowerShell is planned for deprecation. The Migration FAQ sums up the deprecation timeline. Important: Azure AD Graph Retirement and Powershell Module Deprecation seems to be the latest information on the deprecation. To sum up: It seems to be a typical Microsoft deprecation where they stop supporting the AzureAd module and API behind it, but it will still work.

Why

So why would/should we replace AzureAd? Unlike with Azure.Storage, there is (currently) no functional reason to replacing it.
Upgrade from Azure AD PowerShell has a nice list of reasons (most of them would apply to Azure.Storage as well). The cross-platform support would also open up the option to use Github codespaces/devcontainers for developing/testing/teaching/presenting the d365fo.tools.

Impact

The AzureAd module is currently used in one cmdlet, Import-D365AadUser.

The following table generated by PSAzureMigrationAdvisor lists the AzureAD commands used by Import-D365AadUser and their Microsoft Graph equivalent. The listed Microsoft Graph commands would require the modules Microsoft.Graph.Users and Microsoft.Graph.Groups (note that both modules are dependent on Microsoft.Graph.Authentication).

Path	Line	Before	After
import-d365aaduser.ps1	185	Connect-AzureAD	Connect-MgGraph
import-d365aaduser.ps1	189	Connect-AzureAD	Connect-MgGraph
import-d365aaduser.ps1	205	Get-AzureADGroup	Get-MgGroup
import-d365aaduser.ps1	210	Get-AzureADGroup	Get-MgGroup
import-d365aaduser.ps1	214	Get-AzureADGroup	Get-MgGroup
import-d365aaduser.ps1	236	Get-AzureADGroupMember	Get-MgGroupMember
import-d365aaduser.ps1	240	Get-AzureADUser	Get-MgUser
import-d365aaduser.ps1	245	Get-AzureADUser	Get-MgUser
import-d365aaduser.ps1	263	Get-AzureADUser	Get-MgUser

[Splaxi]

PSNotification will be removed going forward...

[Splaxi]

PSNotification is gone!

Next up is the AzureAd

[FH-Inway]

I've been looking a bit further into Microsoft.Graph and, well, it's complicated 🥲

Basically, there are actions you can do with AzureAd such as retrieving user information from Active Directory (now Entry ID) without any further permissions. With Microsoft.Graph, your admin needs to grant you those permissions first before you can do those actions.

As far as I understand microsoftgraph/msgraph-sdk-powershell#1409, this seems to be some red tape that is not really necessary, because the access is also controlled by the roles a user has. But Microsoft says they had to do it and couldn't get a version without those permissions approved and that people need to be educated 🙃

The linked issue mentions an option to grant all permissions for the Microsoft.Graph PowerShell module as a one time setup. I think that we should research that option and document it well. In any case, switching to Microsoft.Graph will likely mean a breaking change until people can get their permissions.

[FH-Inway]

Seems Microsoft is moving to Microsoft Graph as well and encounters the same issues: https://www.yammer.com/dynamicsaxfeedbackprograms/threads/2535916690333696

Their recommendation to use an app registration could be one option for us as well: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/secure-developer-vm#external-integrations

For cloud hosted environments, we may even be able to piggy back on that and use the same certificate. For other environments (local VHD, Azure DevOps pipeline, ...), using the app registration secret instead of the certificate may be more straightforward.