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 user.read.all.

Sample Scripts

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


(users Delegate Authentication) 

https://github.com/gscales/Powershell-Scripts/blob/master/Graph101/EnumerateUsersSpAuth.ps1

(Uses Service Principal Authentication)

https://github.com/gscales/Powershell-Scripts/blob/master/Graph101/PeopleModule.ps1

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 https://docs.microsoft.com/en-us/graph/aad-advanced-queries . 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 gscales@datarumble.com

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 gscales@datarumble.com -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 https://github.com/gscales/Graph-Powershell-101-Binder/blob/master/Users/Enumerate%20and%20Search%20for%20users%20in%20Azure.md

ResolveName

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 gscales@doamin.com -filter "proxyAddresses/any(x:x eq 'smtp:info@domain.com')"

Which generates a Request to Graph like
https://graph.microsoft.com/v1.0/users?$top=999&$filter=proxyAddresses/any(x:x%20eq%20'smtp:info@users.com')

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 gscales@datarumble.com -SearchString 'smtp:info@domain.com' -DirectoryOnly

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

Get-AzureUsersFromGraph -MailboxName gscales@datarumble.com -filter "endsWith(mail,'@msgdevelop.com')" -AdvancedQuery

Which generates a Request to Graph like (notice this is an Advanced Query)
https://graph.microsoft.com/v1.0/users?$top=999&$filter=endsWith(mail,'@msgdevelop.com')&$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 gscales@datarumble.com -filter "startswith(displayName,'glen')" -AdvancedQuery

People API

Invoke-SearchPeople -MailboxName gscales@datarumble.com -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 gscales@datarumble.com -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  https://docs.microsoft.com/en-us/graph/api/resources/groups-overview?view=graph-rest-1.0

Popular posts from this blog

Export calendar Items to a CSV file using EWS and Powershell

Somebody asked about this last week and while I have a lot of EWS scripts that do access the Calendar I didn't have a simple example that just exported a list of the Calendar events with relevant information to a CSV file so here it is. I've talked on this one before in this howto  but when you query the calendar folder using EWS you need to use a CalendarView which will expand any recurring appointments in a calendar. There are some limits when you use a calendarview in that you can only return a maximum of 2 years of appointments at a time and paging will limit the max number of items to 1000 per call. So if you have a calendar with a very large number of appointments you need to break your query into small date time blocks. In this example script I'm just grabbing the next 7 days of appointments if you want to query a longer period you need to adjust the following lines (keeping in mind what I just mentioned) #Define Date to Query $StartDate = (Get-Date) $EndDate

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 https://mydom-my.sharepoint.com/personal/gscales_domain_com/Documents/Email%20attachments/filename.txt 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 ' https://mydom-my.sharepoint.com/personal/gscales_domain_com/Documents/Email%20attachments/filena

The MailboxConcurrency limit and using Batching in the Microsoft Graph API

If your getting an error such as Application is over its MailboxConcurrency limit while using the Microsoft Graph API this post may help you understand why. Background   The Mailbox  concurrency limit when your using the Graph API is 4 as per https://docs.microsoft.com/en-us/graph/throttling#outlook-service-limits . This is evaluated for each app ID and mailbox combination so this means you can have different apps running under the same credentials and the poor behavior of one won't cause the other to be throttled. If you compared that to EWS you could have up to 27 concurrent connections but they are shared across all apps on a first come first served basis. Batching Batching in the Graph API is a way of combining multiple requests into a single HTTP request. Batching in the Exchange Mail API's EWS and MAPI has been around for a long time and its common, for email Apps to process large numbers of smaller items for a variety of reasons.  Batching in the Graph is limited to a m
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.