Real world Azure AD Connect: multi forest user and resource + user forest implementation

Originally posted on Lucian’s blog at Follow Lucian on Twitter @LucianFrango.


Disclaimer: During October I spent a few weeks working on this blog posts solution at a customer and had to do the responsible thing and pull the pin on further time as I had hit a glass ceiling. I reached what I thought was possible with Azure AD Connect. In comes Nigel Jones (Identity Consultant @ Kloud) who, through a bit of persuasion from Darren (@darrenjrobinson), took it upon himself to smash through that glass ceiling of Azure AD Connect and figured this solution out. Full credit and a big high five!



  • Azure AD Connect multi-forest design
  • Using AADC to sync user/account + resource shared forest with another user/account only forest
  • Why it won’t work out of the box
  • How to get around the issue and leverage precedence to make it work
  • Visio’s on how it all works for easy digestion


In true Memento style, after the quick disclaimer above, let me take you back for a quick background of the solution and then (possibly) blow your mind with what we have ended up with.

Back to the future

A while back in the world of directory synchronisation with Azure AD, to have a user and resource forest solution synchronised required the use of Microsoft Forefront Identity Manager (FIM), now Microsoft Identity Manager (MIM). From memory, you needed the former of those products (FIM) whenever you had a multi-forest synchronisation environment with Azure AD.

Just like Marty McFly, Azure AD synchronisation went from relative obscurity to the mainstream. In doing so, there have been many advancements and improvements that negate the need to ever deploy FIM or MIM for ever the more complex environment.

When Azure AD Connect, then Azure AD Sync, introduced the ability to synchronise multiple forests in a user + resource model, it opened the door for a lot of organisations to streamline the federated identity design for Azure and Office 365.


In the beginning…

The following outlines a common real world scenario for numerous enterprise organisations. In this environment we have an existing Active Directory forest which includes an Exchange organisation, SharePoint, Skype for Business and many more common services and infrastructure. The business grows and with the wealth and equity purchases another business to diversity or expand. With that comes integration and the sharing of resources.

We have two companies: Contoso and Fabrikam. A two-way trust is set up between the ADDS forests and users can start to collaboration and share resources.

In order to use Exchange, which is the most common example, we need to start to treat Contoso as a resource forest for Fabrikam.

Over at the Contoso forest, IT creates disabled user objects and linked mailboxes Fabrikam users. When where in on-premises world, this works fine. I won’t go into too much more detail, but, I’m sure that you, mr or mrs reader, understand the particulars.

In summary, Contoso is a user and resource forest for itself, and a resource forest for Fabrikam. Fabrikam is simply a user forest with no deployment of Exchange, SharePoint etc.

How does a resource forest topology work with Azure AD Connect?

For the better part of two years now, since AADConnect was AADSync, Microsoft added in support for multi-forest connectivity. Last year, Jason Atherton (awesome Office 365 consultant @ Kloud) wrote a great blog post summarising this compatibility and usage.

In AADConnect, a user/account and resource forest topology is supported. The supported topology assumes that a customer has that simple, no-nonsense architecture. There’s no room for any shared funny business…

AADConnect is able to select the two forests common identities and merge them before synchronising to Azure AD. This process uses the attributes associated with the user objects: objectSID in the user/account forest and the msExchMasterAccountSID in the resource forest, to join the user account and the resource account.

There is also the option for customers to have multiple user forests and a single resource forest. I’ve personally not tried this with more than two forests, so I’m not confident enough to say how additional user/account forests would work out as well. However, please try it out and be sure to let me know via comments below, via Twitter or email me your results!

Quick note: you can also merge two objects by sAmAccountName and sAmAccountName attribute match, or specifying any ADDS attribute to match between the forests.



If you’d like to read up on this a little more, here are two articles reference in detail the above mentioned topologies:

Why won’t this work in the example shown?

Generally speaking, the first forest to sync in AADConnect, in a multi-forest implementation, is the user/account forest, which likely is the primary/main forest in an organisation. Lets assume this is the Contoso forest. This will be the first connector to sync in AADConnect. This will have the lowest precedence as well, as with AADConnect, the lower the precedence designated number, the higher the priority.

When the additional user/account forest(s) is added, or the resource forest, these connectors run after the initial Contoso connector due to the default precedence set. From an external perspective, this doesn’t seem like much of a bit deal. AADConnect merges two matching or mirrored user objects by way of the (commonly used) objectSID and msExchMasterAccountSID and away we go. In theory, precedence shouldn’t really matter.

Give me more detail

The issue is that precedence does in deed matter when we go back to our Contoso and Fabrikam example. The reason that this does not work is indeed precedence. Here’s what happens:


  • #1 – Contoso is sync’ed to AADC first as it was the first forest connected to AADC
    • Adding in Fabrikam first over Contoso doesn’t work either
  • #2 – The Fabrikam forest is joined with a second forest connector
  • AADC is configured with user identities exist across multiple directories
  • objectSID and msExchMasterAccountSID is selected to merge identities
  • When the objects are merged, sAmAccountName is taken Contoso forest – #1
    • This happens for Contoso forest users AND Fabrikam forest users
  • When the objects are merged, mail or primarySMTPaddress is taken Contoso forest – #1
    • This happens for Contoso forest users AND Farikam forest users
  • Should the two objects not have a completely identical set of attributes, the attributes that are set are pulled
    • In this case, most of the user object details come from Fabrikam – #2
    • Attributes like the users firstname, lastname, employee ID, branch / office

The result is this standard setup is having Fabrikam users with their resource accounts in Contoso sync’ed, but, have their UPN set with the prefix from the Contoso forest. An example would be a UPN of rather than the desired When this happens, there is no SSO as Windows Integrated Authentication in the Fabrikam forest does not recognise the Contoso forest UNP prefix of

Yes, even with ADDS forest trusts configured correctly and UPN routing etc all working correctly, authentication just does not work. AADC uses the incorrect attributes and sync’s those to Azure AD.

Is there any other way around this?

I’ve touched on and referenced precedence a number of times in this blog post so far. The solution is indeed precedence. The issue that I had experienced was a lack of understanding of precedence in AADConnect. Sure it works on a connector rule level precedence which is set by AADConnect during the configuration process as forests are connected to.

Playing around with precedence was not something I want to do as I didn’t have enough Microsoft Identity Manager or Forefront Identity Manager background to really be certain of the outcome of the joining/merging process of user and resource account objects. I know that FIM/MIM has the option of attribute level precedence, which is what we really wanted here, so my thinking as that we needed FIM/MIM to do the job. Wrong!

In comes Nigel…

Nigel dissected the requirements over the course of a week. He reviewed the configuration in an existing FIM 2010 R2 deployment and found the requirements needed of AADConnect. Having got AADConnect setup, all that was required was tweaking a couple of the inbound rules and moving higher up the precedence order.

Below is the AADConnect Sync Rules editor output from the final configuration of AADConnect:


The solution centres around the main precedence rule, rule #1 for Fabrikam (red arrows pointing and yellow highlight) to be above the highest (and default) Contoso rule (originally #1). When this happened, AADConnect was able to pull the correct sAmAccountName and mail attributes from Fabrikam and keep all the other attributes associated with Exchange mailboxes from Contoso. Happy days!

Final words

Tinkering around with AADConnect shows just how powerful the “cut down FIM/MIM” application is. While AADConnect lacks the in-depth configuration and customisation that you find in FIM/MIM, it packs a lot in a small package! #Impressed



Completing an Exchange Online Hybrid individual MoveRequest for a mailbox in a migration batch

I can’t remember for certain, however, I would say since at least Exchange Server 2010 Hybrid, there was always the ability to complete a MoveRequest from on-premises to Exchange Online manually (via PowerShell) for a mailbox that was a within a migration batch. It’s really important for all customers to have this feature and something I have used on every enterprise migration to Exchange Online.

What are we trying to achive here?

With enterprise customers and the potential for thousands of mailboxes to move from on-premises to Exchange Online, business analyst’s get their “kind in a candy store” on and sift through data to come up with relationships between mailboxes so these mailboxes can be grouped together in migration batches for synchronised cutovers.

This is the tried and true method to ensure that not only business units, departments or teams cutover around the same timeframe, but, any specialised mailbox and shared mailbox relationships cutover. This then keeps business processes working nicely and with minimal disruption to users.

Sidebar – As of March 2016, it is now possible to have permissions to shared mailboxes cross organisations from cloud to on-premises, in hybrid deployments with Exchange Server 2013 or 2016 on-premises. Cloud mailboxes can access on-premises shared mailboxes which can streamline migrations where no all shared mailboxes need to be cutover with their full access users.


How can we achieve this?

In the past and from what I had been doing for, what I feel is, the last 4 years, required one or two PowerShell cmdlets. The main reference that I’ve recently gone to is Paul Cunningham’s ExchangeServerPro blog post that conveniently is also the main Google search result. The two lines of PowerShell are as follows:

Step 1 – Change the Suspend When Ready to Complete switch to $false or turn it off

Get-MoveRequest | Set-MoveRequest -SuspendWhenReadyToComplete:$false

Step 2 – Resume the move request to complete the cutover of the mailbox

Get-MoveRequest | Resume-MoveRequest

Often I don’t even do step 1 mentioned above. I just resumed the move request. It all worked and go me the result I was after. This was across various migration projects with both Exchange Server 2010 and Exchange Server 2013 on-premises.

Things changed recently!?!? I’ve been working with a customer on their transition to Exchange Online for the last month and we’re now up to moving a pilot set of mailboxes to the cloud. Things were going great, as expected, nothing out of the ordinary. That is, until I wanted to cutover one initial mailbox in our first migration batch.

Why didn’t this work?

It’s been a few months, three quarters of a year, since I’ve done an Office 365 Exchange Online mail migration. I did the trusted Google and found Paul’s blog post. Had that “oh yeah, thats it” moment and remembered the PowerShell cmdlet’s. Our pilot user was cutover! Wrong..

The mailbox went from a status of “synced” to “incrementalsync” and back to “synced” with no success. I ran through the PowerShell again. No buono. Here’s a screen grab of what I was seeing.

SERIOUS FACE > Some names and identifying details have been changed to protect the privacy of individuals

And yes, that is my PowerShell colour theme. I have to get my “1337 h4x0r” going and make it green and stuff.

I see where this is going. There’s a work around. So Lucian, hurry up and tell me!

Yes, dear reader, you would be right. After a bit of back and forth with Microsoft, there is indeed a solution. It still involves two PowerShell cmdlet’s, but, there is two additional properties. One of those properties is actually hidden: -preventCompletion. The other property is a date and time value normally represented like: “28/11/2016 12:00:00 PM”.

Lets cut to the chase; here’s the two cmdlets”

Get-MoveRequest -Identity | Set-MoveRequest -SuspendWhenReadyToComplete:$false -preventCompletion:$false -CompleteAfter 5
Get-MoveRequest -Identity | Resume-MoveRequest

After running that, the mailbox, along with another four to be sure it worked, had all successfully cutover to Exchange Online. My -CompleteAfter value of “5” was meant to be 5 minutes. I would say that could be set with the correct date and time format and have the current date and time + 5minutes added to do it correctly. For me, it worked with the above PowerShell.

Final words

I know it’s been sometime since I moved mailboxes from on-premises to the cloud, however, it’s like riding a bike: you never forget. In this case, I knew the option was there to do it. I pestered Office 365 support for two days. I hope the awesome people there don’t hate me for it. Although, in the long run, it’s good that I did as figuring this out and using this method of manual mailbox cutover for sync’ed migration batches is crucial to any transition to the cloud.



Complex Mail Routing in Exchange Online Staged Migration Scenario

Notes From the Field:

I was recently asked to assist an ongoing project with understanding some complex mail routing and identity scenario’s which had been identified during planning for an upcoming mail migration from an external system into Exchange Online.

New User accounts were created in Active Directory for the external staff who are about to be migrated. If we were to assign the target state, production email attributes now, and create the exchange online mailboxes, we would have a problem nearing migration.

When the new domain is verified in Office365 & Exchange Online, new mail from staff already in Exchange Online would start delivering to the newly created mailboxes for the staff soon to be onboarded.

Not doing this, will delay the project which is something we didn’t want either.

I have proposed the following in order to create a scenario whereby cutover to Exchange Online for the new domain is quick, as well as not causing user downtime during the co-existence period. We are creating some “co-existence” state attributes on the on-premises AD user objects that will allow mail flow to continue in all scenarios up until cutover. (I will come back to this later).


We have configured the AD user objects in the following way

  1. UserPrincipalName – username@localdomainname.local
  2. mail –
  3. targetaddress –

We have configured the remote mailbox objects in the following way

  1. mail –
  2. targetaddress –

We have configured the on-premises Exchange Accepted domain in the following way

  1. Accepted Domain – External Relay

We have configured the Exchange Online Accepted domain in the following way

  1. Accepted Domain – Internal Relay

How does this all work?

Glad you asked! As I eluded to earlier, the main problem here is with staff who already have mailboxes in Exchange Online. By configuring the objects in this way, we achieve several things:

  1. We can verify the new domains successfully in Office365 without impacting existing or new users. By setting the UPN & mail attributes to, Office365 & Exchange Online do not (yet) reference the newly onboarded domain to these mailboxes.
  2. By configuring the accepted domains in this way, we are doing the following:
    1. When an email is sent from Exchange Online to an email address at the new domain, Exchange Online will route the message via the hybrid connector to the Exchange on-premises environment. (the new mailbox has an email address
    2. When the on-premises environment receives the email, Exchange will look at both the remote mailbox object & the accepted domain configuration.
      1. The target address on the mail is configured
      2. The accepted domain is configured as external relay
      3. Because of this, the on-premises exchange environment will forward the message externally.

Why is this good?

Again, for a few reasons!

We are now able to pre-stage content from the existing external email environment to Exchange Online by using a target address of The project is no longer at risk of being delayed ! 🙂

At the night of cutover for MX records to Exchange Online (Or in this case, a 3rd party email hygiene provider),  We are able to use the same powershell code that we used in the beginning to configure the new user objects to modify the user accounts for production use. (We are using a different csv import file to achieve this).

Target State Objects

We have configured the AD user objects in the following way

  1. UserPrincipalName –
  2. mail –
  3. targetaddress –

We have configured the remote mailbox objects in the following way

  1. mail
    1. (primary)
  2. targetaddress –

We have configured the on-premises Exchange Accepted domain in the following way

  1. Accepted Domain – Authoritive

We have configured the Exchange Online Accepted domain in the following way

  1. Accepted Domain – Internal Relay

NOTE: AAD Connect sync is now run and a manual validation completed to confirm user accounts in both on-premises AD & Exchange, as well as Azure AD & Exchange Online to confirm that the user updates have been successful.

We can now update DNS MX records to our 3rd party email hygiene provider (or this could be Exchange Online Protection if you don’t have one).

A final synchronisation of mail from the original email system is completed once new mail is being delivered to Exchange Online.

Understanding Outlook Auto-Mapping

Auto-mapping is an Exchange & Exchange Online feature, which automatically opens mailboxes with Full Access permissions in a delegate’s Outlook client. The setting is configurable by an Administrator when Full Access permissions are assigned for a user. Once enabled, the periodic Autodiscover requests from the Outlook client will determine which mailboxes should be mapped for a user. Any auto-mapped mailboxes with be opened by the Outlook client in a persistent state and cannot be closed by the user. If users want to remove the auto-mapped mailbox from their Outlook client, Administrative intervention is required to remove the Full Access permission, or clear the auto-mapping flag.

There are two scenarios where you may want to use this configuration:

  • You would like mailboxes to automatically open & persist in Outlook, for users who are assigned full access permissions
  • When users require access an Online Archive associated with the delegating mailbox – the Online Archive isn’t available if you add the mailbox via the “Open these additional mailboxes” console in a mailbox profile. Note that the Online Archive is also available via “Open Another Users Mailbox in Outlook Web App and in some cases, when the delegating mailbox is added as an additional mailbox in the Outlook profile (this has proven to be unreliable depending on identity & permission assignment.)

The auto-mapping feature may be undesirable for users who have access to a large number of mailboxes (taking up valuable Outlook screen real estate), or for users who want to control which mailboxes are open in their Outlook client.

If we take a look at the Autodiscover response for my Office 365 mailbox, we can see the AlternativeMailbox options that advertise a Shared Mailbox (including its Online Archive) for which I have Full Access permissions & auto-mapping enabled.

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="">
<Response xmlns="">
<DisplayName>! Shared Mailbox</DisplayName>
<DisplayName>In-Place Archive - ! Shared Mailbox</DisplayName>

Auto-Mapping Principles

  • By default, auto-mapping is enabled whenever Full Access permissions are granted to the mailbox via Add-MailboxPermission. It must be explicitly set to false if you want it disabled for a user i.e -Automapping:$false
  • At this time, it is not possible to view the state of the auto-mapping setting for a mailbox (whether it has been enabled/disabled)
  • If you are using Mail-Enabled Security Groups to grant Full Access permissions, auto-mapping will not work for the group members. The auto-mapping feature must be assigned by granting Full Access to individual user objects

Managing the Setting

It is enabled per-user, for new or existing Full Access delegates:

Add-MailboxPermission -AccessRights FullAccess -User -Automapping:$true

You can disable auto-mapping for a single user, by removing the user’s Full Access permission and then reinstating the permission with the -automapping:$false parameter defined:

Remove-MailboxPermission -AccessRights FullAccess -User
Add-MailboxPermission -AccessRights FullAccess -User -Automapping:$false

In Exchange Online, auto-mapping can be removed for all existing Full Access delegates on a mailbox by running the command:

Remove-MailboxPermission -ClearAutoMapping


That’s it, simple! Hopefully this helps to explain the nuances of Outlook auto-mapping.

Configuring Intune Service to Service Connector for Exchange Online with a Service Account

If you are considering the use of Intune Conditional Access with Exchange Online it is generally recommended that you configure the Intune Service to Service Connector.  While it is not mandatory, it does provide your Intune Administrators the ability to report on the effectiveness of the Conditional Access Policies on your mobile ActiveSync clients within your Exchange Online environment.  In addition, if you wanted to enforce the use of the Outlook iOS/Android app using Exchange ActiveSync policies, as per my previous blog post here, setting up the connector would allow you to configure the ActiveSync access rules straight from the Intune Admin Portal.

The steps to configure the connector are already covered in the newly reskinned Enterprise Mobility Documentation, with the specific steps located here – but the purpose of today’s blog is to clarify how you would do this “properly” in a Production environment using a Service Account, as the specifics of this are glossed over in the documentation.

If you note the article, you will see a comment that “Microsoft Intune uses the email address of the currently logged in user to set up the connection”.  That means if you executed the steps using your administrative account (which is what most people will end up doing if they weren’t paying attention), Intune will actually configure the connector to use your account from then onwards to perform its regular syncs (every 2 hours for a quick sync, and daily for a full sync).  This is not exactly great, as now this functionality is tied to a specific user, of which that account could be expired, disabled or terminated based on the employment status of that person.   Ideally, you want to be using a Service Account for this purpose.

In order to do this you are going to need the following:

  • A cloud identity to act as the Service Account
  • An Intune License assigned to the Service Account
  • An Exchange Online license assigned to the Service Account

You may question why the licenses are required, but unfortunately that’s just the limitations imposed by Microsoft.  All Intune Administrators (regardless of whether they are Tenant or Service Administrators) must have an Intune license.  Furthermore, the Service to Service Connector requires that the account have a valid email address (and thus a mailbox), necessitating the need for an Exchange Online license.

Step 1 – Grant the Service Account Intune Admin Access

  1. Log into your Intune Management Portal with an admin account that already has Tenant or Service Administrator privileges
  2. Under Admin -> Administrator Management -> Service Administrators add your service account (e.g.
    Note:  You won’t be able to do this unless the account has an Intune License assigned to it

Step 2 – Grant the Service Account Exchange Admin Access

  1. Log into the Exchange Online Admin Portal with an admin account that has Organization Management privileges
  2. Under Permissions -> Admin Roles create a new role
  3. Provide a relevant Name and Description
  4. Leave the Write Scope as Default
  5. For the Roles ensure that you include:
    • Organization Client Access
    • Recipient Policies
  6. For Members add the service account

Step 3 – Set up the Intune Service to Service Connector

  1. Log into your Intune Management Portal with the Service Account
  2. Under Admin -> Microsoft Exchange -> Set up Exchange Connection select the Set up Service to Service Connector button at the bottom
    Note:  If the service account doesn’t have an email address (i.e. Exchange Online License with a mailbox), you will get an error indicating so.  Also, if the service account doesn’t have an Intune license assigned, it will throw up an ‘unexpected error’.IntuneS2S-SetUp
  3. Click OK when prompted.  Use this opportunity to verify that the correct account is being used (i.e. you haven’t forgotten to sign out with your original admin account)IntuneS2S-Account
  4. It will take about 10-15 mins for it to verify the account and configure the connection, but once it is successful, you will see a status update with a green tick like below:IntuneS2S-Success

Optional Step – Hide Mailbox of Service Account

Since we’ve had to give the service account an exchange mailbox (which it doesn’t use), it’s probably a good idea to hide it from the GAL so users don’t get confused.

  1. Log into the Exchange Online Admin Portal
  2. Under Recipients -> {Search for user} -> Edit -> General and select Hide from Address lists

And there you have it, a much more secure and cleaner way to configure your Intune Service to Service connector for Exchange Online!

Enforcing Outlook App in Exchange Online and Intune Conditional Access

[UPDATE 23/11/16] Microsoft have announced a new method of doing what I describe in this blog post.  Matt Shadbolt from the Intune Engineering team has a nice blog post that describe how to use this new process, based on Intune MAM policies.  The below information is still useful though if you want to do more specific restrictions (e.g. iOS vs Android native clients).

What is Intune Conditional Access?

Intune Conditional Access is a pretty neat feature that allows administrators to enforce compliance policies to devices prior to allowing them access to sync their mail with Exchange Online.   The requirements and process required to implement his feature is quite well documented within Microsoft’s TechNet library:  Manage email access with Microsoft Intune

In short, what is happening is Microsoft Intune becomes an additional ‘gate’ that’s sits in front of Exchange Online (or Exchange On-Prem via a connector) that requires devices to provide information on its state (e.g. is it registered, managed or compliant) before being allowed through as part of the authentication process.   In its current state, this conditional access feature, for Exchange Online, can supports ‘controlling’ access for clients on mobile devices (i.e. ActiveSync), while for PCs (i.e. Outlook Desktop) and browser based access (i.e. OWA) this is currently in preview.

How Intune Conditional Access works with Mobile Devices with ActiveSync

For mobile devices, ActiveSync is the primary protocol that is used to communicate with Exchange Online and sync the mail to the devices, however it must be noted that there are some variations to how the ActiveSync protocol is implemented.  Most users are familiar with what we call the ‘Native mail client’ on iOS and Android devices and more recently now the Outlook for iOS/Android App.  While both of these utilise ActiveSync, the defining feature of the Outlook App is that it also supports Modern Authentication which is important for the purposes of this blog.   Pretty much all other mail clients utilise ActiveSync with ‘Basic’ authentication which, in simple terms means that they only know to send the username/password to Exchange Online and expect to be let through.  They certainly don’t understand the concept of ‘device compliance’ tokens and other features like Multi-Factor Authentication.

To work around this, Intune Conditional Access takes over and leverages the ActiveSync policies feature of Exchange Online to quarantine these “legacy” ActiveSync clients after they have configured their mail profile and injects a fake email into their inbox indicating that they’ve detected the device as being unmanaged and hence does not meet compliance policies to satisfy the conditional access requirements.  This email then directs the user to enrol and uplift their device to meet the compliancy policy (e.g. PIN locked, not jail broken etc.) before they are allowed to sync.


The key take-away from this is that Intune Conditional Access is tightly integrated with the ‘Active Sync Policies’ feature of Exchange Online

For applications that support Modern Authentication however (i.e. Outlook app), the process is a bit more elegant in that the device compliance (and subsequent enrolment processes) are all performed as part of the authentication / sign in procedure.  This is also the same process where MFA prompts can also be initiated.

ModernAuthAppEnrol         MFA

How to enforce the Outlook App when Intune Conditional Access is used

With that bit of backstory covered off, we can now proceed to explain how you would go about configuring the enforcement of the use of the Outlook App with Intune Conditional Access.  There are numerous reasons why you might want to enforce the use of the Outlook App, but some of the key reasons we often see are:

  • ActiveSync mail clients do not support ‘Selective Wipe’ if the email profile is not managed by Intune.  Intune can only manage iOS native mail app profiles.  This leaves Android and third party apps open to data leakage if an employee departs the company with a BYOD device for example (and thus a full wipe is not allowed)
  • ActiveSync mail clients using ‘basic authentication’ cannot support Multi Factor Authentication and thus must use the less secure ‘app passwords’ approach
  • Only the Outlook App, to date, supports Mobile Application Management (MAM) Intune policies, which is a feature that provides Data Loss Protection functionality by keeping company data within ‘managed’ apps

Within Intune, the below image shows what the standard conditional access policy configuration would look like:


The section highlighted in green is what triggers all ‘Modern Auth’ applications to abide by Intune’s Conditional Access rules.  This includes Outlook for desktop and the Outlook for iOS/Android app.  The section highlighted in red is what controls Intune Conditional Access for all the ‘legacy’ ActiveSync mail clients (i.e. your native mail clients and third party apps).  In order to enforce the use of the Outlook app, we actually have to disable Intune Conditional Access for Exchange ActiveSync apps that use basic authentication.

This may seem weird, but the reason we are doing this is because in order to control what specific ActiveSync clients are allowed to connect to Exchange Online we have to use the Exchange Active Sync Policies feature.  Specifically, we have to configure the Access Rules to block all device families and only allow the Outlook App device family, like below:


As noted earlier, when Intune Conditional Access is in play, it actually leverages and takes ownership of this feature, and thus any rules you have configured through that are ignored if the user falls within management under Intune and that conditional access policy is enabled.  So, in effect what we are doing is this:

  1. Enable Intune Conditional Access, but only for ‘Modern Authentication’ Apps.  Do not perform the conditional access checks for ‘legacy’ ActiveSync clients
  2. Configure Exchange Online to block all ActiveSync device clients except the Outlook app

The net effect of doing this is as follows:

  • ‘Legacy’ ActiveSync clients will successfully authenticate but their mail synching is blocked by the access rules configured within Exchange Online
  • Outlook App clients, even though they are still using ActiveSync, still abide by Intune Conditional Access policies because they are using Modern Auth and can successfully connect to Exchange Online after they meet compliance

The next challenge of course is then convincing all your users to stop using their Native Mail Client (or their preferred third party app) and use the Outlook app instead, but that’s a post for another day 🙂

Use MailTips to help avoid those embarrassing email slips

If you’re like me you probably have a lot of email addresses that auto-complete in Outlook because you spend a lot of your professional life in email.

As some point I bet you’ve also emailed Alan Smith at an external supplier rather than Alan Smyth in accounts because Outlook auto-complete did its thing and you didn’t notice. That is, until that split second after you clicked ‘Send’ or when Alan Smith replied with an email along the lines of “Errrr, don’t think this was meant for me”.

While Exchange Server (on-premises or Online in Office 365) provides us with many features designed to stop leakage of important business information there is a very simple way (without using DLP) that we can help users avoid the above scenario.

Our old friend MailTips.

MailTips have been around since Exchange and Outlook 2010, but some of these items are switched off by default. One of these disabled items is the “External Recipients” MailTip.

You can enable the MailTip display using the below PowerShell (you’ll need to be an Exchange Admin for this to work).

Import-Module MSOnline

$cred = Get-Credential

$exoSession = New-PSSession -ConfigurationName Microsoft.Exchange `
-ConnectionUri "" `
-Credential $cred -Authentication "Basic" -AllowRedirection

Import-PSSession $exoSession

Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true

Once we’ve made this change users will begin to see warnings in their Outlook clients (both desktop and web) that look similar to the below and will hopefully be alerted if they are sending a mail to the wrong person.

Outlook on the web - External Recipient Warning

Outlook - External Recipient Warning

Happy Days! 🙂

Delegate Mailbox Access using Groups in Exchange Online

A common misconception about granting mailbox access rights in Exchange Online is that you can only add access to the individual and not a group. You may have opened the Exchange Administrator Center (EAC), found the mailbox you wanted and looked at the delegated access tab. Only to be provided with a list of eligible user identity’s, but none of your on-premises security groups that have been created. Fear not, the on-premises groups just need a little remediation to the correct flavour to be seen in the picker and then applied.
The key settings of a group to assign mailbox access in Exchange Online are:
  1. Universal Security
  2. Mail Enabled
Things in your environment may have gotten this way over time as legacy on-premises Exchange Server versions weren’t as picky with your selection and would allow the permission to be granted to any kind of group you threw at it. Moving to Exchange Online has more sophisticated taste that needs to be catered for due to its Evergreen state with all the latest Exchange trends.
If you migrate on-premises mailboxes with these slightly incorrect permissions to Exchange Online they will be lost forever. So if you remedy the existing on-premises mailboxes before initiating a remote move request to Exchange Online, no further action will be required at completion.

The Process

Update the group to universal:
Get-Group $Name | Set-Group -Universal
Mail enable the group:
Enable-DistributionGroup -identity $Name
Finally, not compulsory but if you want the group to be hidden from your Exchange Address Book:
Get-DistributionGroup -identity $Name | Set-DistributionGroup -HiddenFromAddressListsEnabled:$True
Force a synchronisation of your group modifications with Azure Active Directory and you should find that the group will be available in the Office 365 Exhange Administrator Center. On the Azure AD Connect Server:
CD C:\Program Files\Microsoft Azure AD Sync\Bin\
.\DirectorySyncClientCmd.exe delta
So my final note that I would like to re-iterate is that if you tidy this stuff up before migrating to Office 365 you will have a lot less problems when the mailbox becomes active in Office 365. A mailbox that has been migrated with a faulty group type will have permissions assigned on the object, but will not resolve to an object and therefore only show SID information. Firstly the permissions fail, but secondly, it makes it very difficult to find out what the group was previously to add post migration. (see first permissions below)

 Hot Tip

Fix the issue with your groups before you start the synchronisation of the mailbox to Exchange Online and the permissions will be stamped correctly during the initial phases of the move request and once finalised, will work as expected.

Using powershell to add users to an Exchange Online in-place hold

Originally blogged on Lucian’s blog at Follow Lucian on Twitter @LucianFrango.

A month ago I wrote a quick post (available here) on removing users from large in-place hold polices in Exchange Online. At the time I wasn’t that familiar with the process and documentation online was limited. After sharing is caring that process I had a deeper look into the in-place hold policies for a client I’m consultant at. There was some cleanup that was required and this post explains that process as well as a streamlined way via powershell to add users to an in-place hold policy.

The problem

Over the course of any large-scale migration to Exchange Online, managed services and project resource teams coordinate to successfully migrate users and apply policies and post migration tasks. In-place hold policies and governance around storing email data for compliance and legal purposes is key for certain organisations. The larger the organisation though, the more tricky the task. The GUI or web console just isn’t enough to cater for thousands of users. Insert powershell!- it is your friend.

The solution

Overall the process to add users to an in-place hold isn’t that much different from the process of removing users from a policy. Like the previous post (available here), I’ll keep the process short and sweet to outline the steps required:

Read More

Using PowerShell to remove users from an Exchange Online in-place hold policy

Originally posted on Lucian’s blog at Follow Lucian on Twitter @lucianfrango.

In-place hold, legal hold, compliance hold, journaling and/or select “D”: all of the above, when it’s simplified down to its simplest form is storing emails for X amount of time in case there’s a problem and these need to be reviewed. What’s great about Office 365 Exchange Online is that there is the ability to store those emails in the cloud for 2,555 days (or roughly speaking 7 years).

Let’s fast forward to having in-place hold enabled for an Exchange Online tenant. In my reference case I have roughly 10,500 users in the tenant and numerous in-place hold policies, with the largest containing 7,500 or so users. I’ve run into a small problem with this Hybrid based environment whereby I need to move a mailbox that is covered by an in-place hold policy (let’s call it “Lucians Mailbox Search Policy”) back to on-premises for a couple of reasons.

The following blog post outlines how to remove users from an in-place hold via PowerShell as the Office 365 / Exchange Online Control Panel may not let you do that when you have thousands of users in a single hold policy.
Read More