I started writing about using the Microsoft PowerShell Graph SDK a while ago.

I also released a Pluralsight course on it, which has led to many questions from both.


The lesson learned from this is that migrating away from the standard PowerShell modules for Azure and Microsoft 365 is more complicated than expected.

A simple example of this came from a conversation with a friend Vlad. In the current “AzureAD” and “AzureADPreview” PowerShell modules, you can use “Get-AzureADMSDeletedGroup” to see deleted groups, which is the same as accessing https://admin.microsoft.com/#/deletedgroups within the Microsoft 365 admin center.


If you want to view the same items using the Microsoft PowerShell Graph SDK, you should be able to use “Get-MgGroup“; however, that only returns groups, not deleted. None of the “Microsoft.Graph.Groups” cmdlets let you access this list. Another approach would be to use the “Microsoft.Graph.DirectoryObjects” cmdlets. You can use “Get-MgDirectoryObject -All“; however, you will find that searching is not allowed on this command.

I could use filtering or populate the “-DirectoryObjectId” property to get the groups. Still, I need to know the name of the groups to retrieve first, which defeats the purpose of trying to get a list of the deleted groups.

Luckily this is where you can still use the Microsoft PowerShell Graph SDK but call the Graph API directly. Within the Graph API is an endpoint specifically for retrieving deleted items.


Executing this within Graph Explorer returns JSON for the deleted groups.


To use this within PowerShell, we use the following commands.

$url = "https://graph.microsoft.com/beta/directory/deletedItems/microsoft.graph.group"
$body = @{}
$Params = @{
    Uri = "$url"
    Method = "GET"
    Body = $body
$deletedgroups = Invoke-MgGraphRequest @Params
$deletedgroups | Select-Object -ExpandProperty Value | Select-Object id, displayName

The above is just a simple example of an excellent command within the old “AzureAD” and “AzureADPreview” modules that either do not exist or function similarly. Many commands do not have a “like-for-like” command yet. Much of this is not just a problem with the Microsoft PowerShell Graph SDK; it is more fundamental as some methods don’t exist within the Graph API either. As well as commands not existing, you also get permission issues for specific commands. 

I was recently asked about an “Unauthorized” error when executing “Get-MgComplianceEdiscoveryCase,” even though all permissions were correct. After some discussion, the issue was due to calling this command using an App registration using a certificate with the assigned permissions. The documentation does explain this, not within the PowerShell documentation but in the Graph API endpoint documentation.


The core problem or “woe” I see for all IT professionals is that using the current PowerShell modules is straightforward. In contrast, the migration to the Microsoft Graph module can require extensive learning and investigation to identify the replacement commands. For my journey, I must rely on “Graph Explorer” and the “Graph X-Ray” Microsoft Edge and Chrome add-in or Windows desktop application to understand what is happening and the code to use.

After all that, I want to say a massive THANK YOU to the Microsoft Graph Team and the Microsoft PowerShell Graph SDK Team for their efforts. As with all things new, I understand it takes time to make work the same way or better. Keep up the great work.