fbpx
Active Directory & Office 365 Reporting Tool

How to Find and Export Azure AD Users with PowerShell. Beginning in June 2023, we must use the Get-MgUser cmdlet to retrieve and export Azure AD users. We import the Get-MgUser command in the Microsoft Graph SDK for PowerShell. It enables us to communicate with all Microsoft Services via a single endpoint.

We store all user accounts in our Microsoft 365 tenant in the Azure Active Directory. We then manage them via the admin center or the Azure Portal, but PowerShell is usually more convenient.

In this article, we will show how to use the Get-MgUser cmdlet to find and retrieve user information from Azure AD and export all of our users to CSV, which is found at the end of the article. Also, later on, we discuss how to migrate to Get-MGUser if you are still using the Get-AzureADUser command.

Get-MgUser – How to Find and Export Azure AD Users with PowerShell

Prerequisites

Before we begin, we should install the Microsoft Graph Module in PowerShell. Currently, the Microsoft Graph SDK Module is one of 38 modules. We can install them all but consider only installing the required modules.

Make sure that we install at least Microsoft.Graph.Authentication module when installing individual modules. We can view all available modules with the following command:

				
					Find-Module Microsoft.Graph*
				
			

Only the current user will have the Microsoft Graph module installed. It is also possible to install it for all users, but we’ll need to launch PowerShell with elevated privileges. Enter the following snippet in PowerShell to install the module:

				
					Install-Module Microsoft.Graph -Scope CurrentUser
				
			

It can take a couple of minutes to install all modules before PowerShell completes the installation.

Finding Azure AD Users in PowerShell

We can use the Get-MgUser command to find and extract useful information from the Azure Active Directory. There are a few parameters we can use to find or filter users:

  • UserId – Retrieve a specific user based on their UPN or ObjectID.
  • Filter – Retrieve multiple objects in response to an oDate v3 query.
  • Search – Get a list of all users who match the searchString.
  • Top – Displays the first number of results.

The Get-MgUser cmdlet returns 100 records by default. To get all results, use the -All $true parameter.

So the first step is to connect Microsoft Graph with the correct scope. We will only retrieve user data so that we can use the User.Read.All scope.

				
					Connect-MgGraph -Scopes 'User.Read.All'
				
			

To test if the cmdlet is working, we can get all users from our Azure Active Directory with the following cmdlet:

				
					Get-MgUser -All
				
			

We can use the user’s UserId attribute to get a single user. This attribute can either be the UserPrincipalName of the user or the actual user id:

				
					Get-MgUser -UserId marionm@test.onmicrosoft.com
				
			

If we want to see all properties of the user, then we can add Select-Object * on a new pipeline:

				
					Get-MgUser -UserId marionm@test.onmicrosoft.com | Select-Object *
				
			

We will explain more about the properties later in this article.

Run reports on your Azure AD Users with InfraSOS

Try us out for Free, Access to all features. – 200+ AD Report templates Available. Easily customise your own AD reports.

Using the Get Azure AD Filter Parameter

We can filter the users like we can with the Get-MgUser cmdlet. The tricky thing about the oData v3 query is that Azure only supports some field operators. So, for example, we can search for all users with the “IT Engineer” job title.

				
					Get-MgUser -Filter "jobtitle eq 'IT Engineer'"
				
			

This command will get all users whose job title equals “IT Engineer”. But we would expect we could also use the -ne (not equal) operator to get all users who are not IT Engineers.

				
					Get-MgUser -Filter "jobtitle ne 'IT Engineer'"
				
			

However, that operator isn’t supported. To filter users, we can only use the following operators: eq, and, or, and startsWith.

Get Azure AD User Filter Examples

The filter parameter in the Get-MgUser cmdlet is a powerful feature that allows us to filter and retrieve specific Azure AD users based on a wide range of criteria. Using this parameter, we quickly and easily retrieve a subset of users that match your specific search criteria, allowing you to perform targeted actions such as password reset or group membership changes.

So, here are a couple of examples of how to use the filter parameter on the Get-MgUser cmdlet:

  • Filter using the full name: Remember that we can’t use the wildcard or -like operators in this case.
				
					Get-MgUser -Filter "DisplayName eq 'Marion Mendoza'"
				
			
  • Filter on the last name
				
					Get-MgUser -Filter "Surname eq 'Mendoza'"
				
			
  • Search on the initial part of the name
				
					Get-MgUser -Filter "startswith(DisplayName,'M')"
				
			
  • Get Enabled Azure AD accounts
				
					Get-MgUser -Filter "accountEnabled eq true" -All
				
			
  • Using multiple conditions
				
					Get-MgUser -Filter "department eq 'IT' and jobtitle eq 'IT Engineer'"
				
			

Note that we have added the -All parameter on some commands. By default, the Get-MgUser command only returns the first 100 results. We get all of the returned results by adding the -All parameter to the snippet.

Finding Azure AD Users Using Search

In addition to the filter parameter, we can find users using the -Search parameter. The parameter requires a searched property and a value. We must also set the -consistencylevel to the eventual value.

The -Search parameter has the advantage of allowing us to search on any filter. So, for example, if we want to search on a specific part of the name, we can type:

				
					Get-MgUser -Search 'DisplayName:van' -ConsistencyLevel eventual
				
			

Also, note that we must wrap the search query in single quotes. We can use the search parameter on almost all fields that the Get-MgUser command returns.

Combining Search and Filter in Get MgUser

We can also combine -Filter and -Search parameters in a single command. These parameters enable us to search only among promoted accounts using a name or job title, for example:

				
					Get-MgUser -Filter 'accountEnabled eq true' -Search 'DisplayName:mar' -ConsistencyLevel eventual
				
			

Selecting Properties to Return

We’ve noticed that the Get-MgUser cmdlet returns only a few properties by default. The majority of fields are either empty or have the value Microsoft.Graph.PowerShell.Models followed by an entity name. So, how do we get this information?

We can use two parameters to get the information we need -Property and -ExpandProperty.

The -Property parameter is equivalent to the selection we can pipe behind the cmdlet. The only difference is that with select, Microsoft Graph returns and filters out all data in PowerShell.

				
					Get-MgUser -UserId marionm@test.onmicrosoft.com | Select DisplayName,BusinessPhones,Mail,JobTitle
				
			

When we use the property parameter, Microsoft Graph only returns the data. Especially when working with many records, this will be faster than selecting.

				
					Get-MgUser -UserId marionm@test.onmicrosoft.com -Property DisplayName,BusinessPhones,Mail,JobTitle | Format-List
				
			

Expanding Microsoft Graph PowerShell Models

When we looked at a user’s properties, we noticed that some of them had the value Microsoft.Graph.PowerShell.Models followed by a resource name. These models (or resources) represent resource-type relationships.

These relationships allow us to view the resource’s related data efficiently. For example, if we take the user, we want to know who the user’s manager is.

To accomplish this, we must expand the properties and select the appropriate manager object parameter:

				
					Get-MgUser -UserId marionm@test.onmicrosoft.com -ExpandProperty manager | Select @{Name = 'Manager'; Expression = {$_.Manager.AdditionalProperties.displayName}}
				
			

The difficulty with those relationships is locating the appropriate field and permissions. We connect to Microsoft Graph, for example, using only the User.Read.All scope. For example, if we want to view a user’s working hours in the mailbox settings, we must first find and add the appropriate scope to our session.

We like to use the Rest API documentation to find the correct permission. For example, if we expand a resource, it will show the resource’s relationships. We can then click on the type, which will take us to the related resource where we can find the required permissions.

So we’ll need to add the MailboxSettings.Read permissions to the mailbox settings:

				
					Connect-MgGraph -Scopes "User.Read.All", "MailboxSettings.Read"
				
			

And then, we can select the nested values and properties:

				
					Get-MgUser -UserId marionm@sample.com -Property MailboxSettings | Select @{Name = 'days'; Expression = {$_.MailboxSettings.WorkingHours.DaysofWeek}}
				
			

Export All Azure AD Users

Despite being in Azure, we can use the same command to export users in a report using the Export-CSV command. To get all the users of our Azure tenant, we only need to remove the value for the Get-MgUser command.

				
					Get-MgUser -Property DisplayName,BusinessPhones,Mail,JobTitle | 
Export-CSV -Path $path -NoTypeInformation
				
			

Replace the $path variable to the actual destination path of your choosing.

Migrating to Microsoft Graph

Windows scheduled the Azure AD module’s and MS Online’s deprecation on June 2023. As a result, we will need to switch over to the Microsoft Graph SDK for PowerShell.

Scripts written in Azure AD PowerShell won’t automatically work with Microsoft Graph PowerShell. This migration happened because Microsoft designed the new cmdlet names to be easy to learn. Instead of using AzureAD or AzureADMS in cmdlet names, use Mg. For example, the cmdlet Get-AzureADUser is equivalent to Get-MgUser.

However, migration is more than becoming familiar with the new cmdlet names. In addition, there are renamed modules, parameters, and other essential changes.

Update Current Scripts

The equivalent of the Get-AzureADUser cmdlet is Get-MgUser. This cmdlet has additional parameters that let us do more with its output. For example, the -ConsistencyLevel parameter allows us to do Count, Filter, and Search.

				
					Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -ConsistencyLevel eventual -Count userCount -Filter "startsWith(DisplayName, 'a')" -Top 1
				
			

We can read more about the official Microsoft documentation changes by clicking on this link.

Limitations

Some limitations currently exist in Microsoft Graph PowerShell, either by design or due to some future functionality.

  • There has yet to be an equivalent of -SearchString for Get-AzureADUser and Get-AzureADGroup commands. Use -Filter instead. For example, Get-MgUser -Filter “DisplayName eq ‘Marion M'” returns the user whose display name is equal to the specified string.
  • We need to use hash tables to pass nested parameters.
  • Use the Microsoft Graph PowerShell -ConsistencyLevel parameter. To learn more about the -ConsistencyLevel parameter, see Advanced query parameters.

Thank you for reading How to Find and Export Azure AD Users with PowerShell. We shall conclude this article blog. 

Get-MgUser – Find and Export Azure AD Users with PowerShell Conclusion

In conclusion, the Get-MgUser is a powerful PowerShell cmdlet that we can use to find and export Azure AD users. Using these cmdlets, we can quickly and easily retrieve a wide range of information about our Azure AD users, including their names, emails, and group memberships. These commands can be handy for organizations with large numbers of users or for performing bulk operations such as user management or reporting.

By understanding how to use these cmdlets, we can leverage the full power of Azure AD and make our organization more efficient and productive.

InfraSOS-AD-Tools

Try InfraSOS for FREE

Invite your team and explore InfraSOS features for free

Marion Mendoza

Marion Mendoza

Windows Server and VMware SME. Powershell Guru. Currently working with Fortune 500 companies responsible for participating in 3rd level systems support across the enterprise. Acting as a Windows Server engineer and VMware Specialist.

Leave a comment

Your email address will not be published. Required fields are marked *