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
Labels:

Popular posts from this blog

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 Gr...
Read more

Exporting and Uploading Mailbox Items using Exchange Web Services using the new ExportItems and UploadItems operations in Exchange 2010 SP1

Two new EWS Operations ExportItems and UploadItems where introduced in Exchange 2010 SP1 that allowed you to do a number of useful things that where previously not possible using Exchange Web Services. Any object that Exchange stores is basically a collection of properties for example a message object is a collection of Message properties, Recipient properties and Attachment properties with a few meta properties that describe the underlying storage thrown in. Normally when using EWS you can access these properties in a number of a ways eg one example is using the strongly type objects such as emailmessage that presents the underlying properties in an intuitive way that's easy to use. Another way is using Extended Properties to access the underlying properties directly. However previously in EWS there was no method to access every property of a message hence there is no way to export or import an item and maintain full fidelity of every property on that item (you could export the...
Read more

Sending a Message in Exchange Online via REST from an Arduino MKR1000

This is part 2 of my MKR1000 article, in this previous post  I looked at sending a Message via EWS using Basic Authentication.  In this Post I'll look at using the new Outlook REST API  which requires using OAuth authentication to get an Access Token. The prerequisites for this sketch are the same as in the other post with the addition of the ArduinoJson library  https://github.com/bblanchon/ArduinoJson  which is used to parse the Authentication Results to extract the Access Token. Also the SSL certificates for the login.windows.net  and outlook.office365.com need to be uploaded to the devices using the wifi101 Firmware updater. To use Token Authentication you need to register an Application in Azure https://msdn.microsoft.com/en-us/office/office365/howto/add-common-consent-manually  with the Mail.Send permission. The application should be a Native Client app that use the Out of Band Callback urn:ietf:wg:oauth:2.0:oob. You ...
Read more
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.