Skip to main content

Migrating Exchange Web Services (EWS) Directory and Recipient resolution code to the Microsoft Graph

 One of the more complex things to migrate in EWS when migrating to the Graph API is any directory access code that uses one of the following EWS operations

  • FindPeople
  • ResolveName
  • ExpandGroup (ExpandDL)
or if your using OnPrem you maybe using System.DirectoryServices to do direct LDAP requests of Active Directory.

With the Microsoft Graph API these Directory based mail operations don't exist, because you have full access to the underlying AzureAD, so in theory everything should be achievable without these type of operations. For the most part this is correct where is starts to get a little grayer is around this like Address Lists and Exchange recipient types mostly because the Graph doesn't expose the following underlying Active Directory properties

  • msExchRecipientDisplayType
  • msExchRecipientTypeDetails
  • msExchRemoteRecipientType
so this can be a limitation if your migrating from LDAP code and some FindPeople implementations if your searching based on AddressList.

Microsoft Graph Users Endpoint and the People API

The two main endpoints you will use when migrating your directory based code is the Users endpoint which allows you to enumerate and query the underlying users in Azure AD.  The People API allows you to query both the Users, Mailbox Contacts, Directory and other related contacts information (and a little bit more). The third endpoint you might use is Contacts if you just want to search the contacts of the local mailbox but I'm not going to cover this in this post also the Groups Endpoint should be used for group operations (expanddl)

Permission and uses 

For the People API there are two permissions that are usable but if you need to be able to search all users in your organization (regardless of their relevance to the underlying user) you need to make sure that you have the People.Read.All permission that requires Admin Consent. For the Users Endpoint depending on the level of detail you need user.readbasic.all is an option but you may find you need

Sample Scripts

For this post I've created a number of sample scripts for the user endpoint i have 

(users Delegate Authentication)

(Uses Service Principal Authentication)

Users API Advanced Queries

The Microsoft Graph API recently introduced an Advanced query engine that allows you to make more complex queries of Azure AD . To use this advanced query the Request string needs to modified and a additional header 

ConsistencyLevel: eventual

needs to be added to the Graph request, this is supported in the sample script for using the -AdvancedQuery switch

People API Search Scope

As well as the permission scope in the People API the scope it will search can be affected by an additional header called 

"X-PeopleQuery-QuerySources: Mailbox,Directory”

By default the People API will only search the Mailbox so it's important to use this header when you want to search the Directory or even limit your search to the Directory (and don't search the mailbox). In the sample script using the -DirectoryOnly switch will limit the search to the directory only. One thing to note if you don't have the People.Read.All permission and you use a Directory only search scope it will only return those contacts relevant to the user rather then rather then any user in the directory.

Enumerating or browsing users (Find People)

Address books are a pretty standard feature of any email client, in EWS you may have used the FindPeople operation to search or browse the users from an Addressbook. The good thing about findpeople is that it gave you the ability to use Exchange Address Lists. The Graph doesn't have that direct ability so if your trying to browse using Address lists using one of the Graph endpoints to try and mimic the GAL you need to try to reproduce that filter in your code (which you may not be able to do).  When you enumerate objects in the Graph API you page those objects in pages of  up to 999 objects at a time. An example of a straight page of all the users in the underlying directory is

Get-AzureUsersFromGraph -MailboxName

Using the People API you can search across all Exchange Address Lists (rather then browse within a particular address lists like FindPeople could). Because this is a search rather then an enumeration like the Users endpoint you can use a workaround such as search for "smtp:" as the search string to return all users (this was a workaround for EWS as well it was limited to 100 users in EWS I haven't tested if there is the same limit in the Graph and its not documented, the differences is the Microsoft Graph results are paged where resolveName wasn't, paging is also a little weird in the People API and the documentation is lacking at the moment and doesn't explain how it works (or it has bugs at the moment) (eg Directory queries look like there is a limitation to 150 where Mailbox queries aren't limited ) If anybody can give clarity around this let me know and I'll correct this.

Invoke-SearchPeople -MailboxName -SearchString 'smtp:' -DirectoryOnly

I've added a Graph 101 Binder page for enumerating users in the directory which has more example for the users interface


In EWS the ResolveName operation has a number of different uses in the conventional sense it would be used to do ANR (ambiguous name resolution) when someone is sending email. In an Application it maybe used to do any of the following 

Get the contact information for a user that you only have the SMTP Address for

If the target users are located in AzureAD you could use the Users Endpoint in Azure to search for the user based on one of their proxyaddress so it could be a Primary or secondary address of the object. eg

Get-AzureUsersFromGraph -MailboxName -filter "proxyAddresses/any(x:x eq '')"

Which generates a Request to Graph like$top=999&$filter=proxyAddresses/any(x:x%20eq%20'')

If the Contact your trying to locate is in the Mailbox or if its in either the Mailbox or the Directory then you can use the People API to search both scopes. Note this is a Search so you may need to filter the results more then you would in the Users example with is doing an exact match

Invoke-SearchPeople -MailboxName -SearchString '' -DirectoryOnly

Find All users from a particular domain (eg all guest users from domain)

Get-AzureUsersFromGraph -MailboxName -filter "endsWith(mail,'')" -AdvancedQuery

Which generates a Request to Graph like (notice this is an Advanced Query)$top=999&$filter=endsWith(mail,'')&$Count=true

Search based on part of a DisplayName 

For the closest ResolveName behavior use the People API however the Users Endpoint in Graph can also be used here are some examples

Users Endpoint

 Get-AzureUsersFromGraph -MailboxName -filter "startswith(displayName,'glen')" -AdvancedQuery

People API

Invoke-SearchPeople -MailboxName -SearchString 'glen' -DirectoryOnly

Resolving a Legacy ExchangeDN or EX Address

This is something I've used a lot especially when your migrating email or in other instances where all you have is the LegacyDN or Exchange Native Address of the User. You can resolve these addresses using the People API and a DirectoryOnly query eg

Invoke-SearchPeople -MailboxName -SearchString '/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=a7d0ec70c15e4132a8a2cfb840c75a66-gscales' -DirectoryOnly

Expand Group

I haven't actually included this in any of my samples as there is a Groups Endpoint in the Microsoft Graph that you should use for this which is documented well at

Popular posts from this blog

How to test SMTP using Opportunistic TLS with Powershell and grab the public certificate a SMTP server is using

Most email services these day employ Opportunistic TLS when trying to send Messages which means that wherever possible the Messages will be encrypted rather then the plain text legacy of SMTP.  This method was defined in RFC 3207 "SMTP Service Extension for Secure SMTP over Transport Layer Security" and  there's a quite a good explanation of Opportunistic TLS on Wikipedia .  This is used for both Server to Server (eg MTA to MTA) and Client to server (Eg a Message client like Outlook which acts as a MSA) the later being generally Authenticated. Basically it allows you to have a normal plain text SMTP conversation that is then upgraded to TLS using the STARTTLS verb. Not all servers will support this verb so if its not supported then a message is just sent as Plain text. TLS relies on PKI certificates and the administrative issue s that come around certificate management like expired certificates which is why I wrote th

A walk-though using the Graph API Mailbox reports in Powershell

Quite recently the Reporting side of the Graph API has moved in GA from beta, there are quite a number of reports that can be run across various Office365 surfaces but in this post I'm going to focus on the Mailbox related ones. Accessing Office365 Reports using Powershell is nothing new and has been available in the previous reporting endpoint however from the end of January many of these cmdlets are now being depreciated in favour of the Graph API . Prerequisites  In comparison to using the Remote PowerShell cmdlets where only the correct Office365 Admin permissions where needed, to use the new Graph API reports endpoint you need to use OAuth for authentication so this requires an Application Registration  that is then given the correct oAuth Grants to use the Reports EndPoin

Downloading a shared file from Onedrive for business using Powershell

I thought I'd quickly share this script I came up with to download a file that was shared using One Drive for Business (which is SharePoint under the covers) with Powershell. The following script takes a OneDrive for business URL which would look like This script is pretty simple it uses the SharePoint CSOM (Client side object Model) which it loads in the first line. It uses the URI object to separate the host and relative URL which the CSOM requires and also the SharePointOnlineCredentials object to handle the Office365 SharePoint online authentication. The following script is a function that take the OneDrive URL, Credentials for Office365 and path you want to download the file to and downloads the file. eg to run the script you would use something like ./spdownload.ps1 '
All sample scripts and source code is provided by for illustrative purposes only. All examples are untested in different environments and therefore, I cannot guarantee or imply reliability, serviceability, or function of these programs.

All code contained herein is provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.