Exchange Online and Remote Domains



This article talks about the importance to configure Remote Domain both on Exchange on premise and Exchange Online to control the format and type of email messages exchange between hosted mailbox users and on premise mailbox users.

This post is available on my new blog:

Hybrid Email Moderation Part 1



This article is all about talking about the email moderation when people have mailboxes on premise and on Office 365. In certain cases, the approval process do not work well if we have mixed of approval and senders between on premise and Office 365.

How Email Moderation Works

  1. A mail user sends an email to a moderated group.
  2. The categorizer at hub transport server intercepts the email, marks for moderation and then re-routes it to the arbitration mailbox.
  3. The store driver component stores the message in the arbitration mailbox and sends an approval request to the moderator.
  4. The moderator takes an action.
  5. The store driver marks the moderator’s decision on the original message stored in the arbitration mailbox.
  6. The Information Assistant reads the approval status on the message stored in the arbitration mailbox, and then process the message depending on the moderator’s decision.
    1. If the moderator has approved the message, the Information Assistant resubmits the message to the submission queue, and the message is delivered to the recipient(s).
    2. If the moderator has rejected the message, the Information Assistant deletes the message from the arbitration mailbox and notifies the sender that the message was rejected.

So What are the Arbitration Mailboxes?

Those are system mailboxes that get created by default in any Exchange organization. They have a well known names that is similar in any Exchange organization.

You can view them by typing Get-Mailbox -Arbitration 

Arbitration Mailboxes on Exchange On Premise

The one that we are interesting in here is the first one (Microsoft Exchange Approval Assistant). This is the system mailbox that handles moderation.

IT Admin can create as many arbitration mailboxes for moderation to load balance the approval process, but we choose to stick with this one default one.

Notice that on our on premise Exchange implementation, we know we have only one arbitration mailbox for moderation and we know its address by typing Get-Mailbox – Arbitration.

In Exchange Online, the property -Arbitration does not exist in the Get-Mailbox command. This is because it is hosted environment and Microsoft seems to have lots of those arbitration mailboxes and they are  hidden from us. We just know that some arbitration mailbox in the cloud will handle the approval process, we just know which one and we cannot query it.

IMPORTANT NOTE: We only know and this is so important, that the Exchange Online arbitration mailbox has email address that ends with and NOT Strange enough as we all know that is identity domain, while is a mail routing domain.

The One Million Dollars Question: Which Arbitration Mailbox will be used?

So we have people in Office 365 and their mailboxes are in Exchange Online, and we have people on premise with mailboxes in our on premise Exchange Environment, so which arbitration mailbox will kick in when sending to a moderated group? The Exchange Online one or the one we know about in our Exchange on premise system?

Why this is important is coming soon, but it is so important to understand which arbitration mailbox will be invoked.

There are two types of moderated groups on our on premise Exchange system:

  • Dynamic groups that are moderated.
  • Non-Dynamic groups that are moderated.

Why this is important? Well, because the way AD Sync works.

Dynamic groups created on premise are not synchronized to Azure AD. Azure AD does not recognized our dynamic groups. This means that all our dynamic groups are not available in the address book of Office 365 mailbox users.

Well, we kind of trick Office 365 mailbox users by creating contacts on Azure AD that has the same name of each dynamic group that we have on premise so that they can see ALL GSO for example in their address book.

So why this is important from our subject perspective. Well, the only thing that we want to make sure we understand is that when Office 365 hosted mailbox user is sending email to an on premise dynamic group, there is no way for Exchange Online to know that this group is moderated because AD Sync does not sync dynamic groups to Azure AD, instead it will route it to our Exchange on premise servers to deal with it. Now our Exchange on premise knows that this is a moderated group, and it will put that email to the on premise arbitration mailbox. Sound good?!

While if a an Office 365 hosted mailbox user is sending email to an on premise non-dynamic group, Exchange Online query Azure AD, and since this group is synced, Exchange Online at this moment knows and realize this is a moderated group, because the group and all of its properties including moderation information is synced and available in Azure AD. So Exchange Online will try to behave in a smart way and start taking responsibility. It will not dare to forward the email to Exchange on premise, as it feels that it should stand to the challenge. It knows it is moderated group, so it will try to save the day. It will shout (Hey Exchange Online, give me an available arbitration mailbox, I have work to be done), and it will through the email to one of the many available arbitration mailboxes in Exchange Online, that we do not know their names or specific email address. We only dare to know that the email address of those cloud arbitration mailboxes ends with (yes not

Be aware

Before anything start working, there are couple of prerequisites to be accomplished before making moderation works between on premise and Exchange Online.

  • On the outbound connector to Office 365, we shall add in the address space for that connector. That is we need to educate our Exchange on premise that anything going to should be routed to Exchange Online.  This is necessary for the approval messages from on premise moderators to reach the Exchange Online arbitration mailbox (that has email address ends with

  • In order for the button called Approve and Reject to work correctly in hybrid moderation, we need to configure remote domains and configure them in both on premise and Exchange Online. This would be mentioned in part 2 of this article.

How things works?

Well, we have 8 possibility to take care of when evaluating how hybrid moderation works.

  1. On Premise sending to On Premise Dynamic Group and the approval is On Premise. [We know it will work]
  2. On Premise sending to On Premise Dynamic Group and the approval is On Cloud.
  3. On Cloud sending to On Premise Dynamic Group and the approval is On Premise.
  4. On Cloud sending to On Premise Dynamic Group and the approval is On Cloud.
  5. On Premise sending to On Premise Non-Dynamic Group and the approval is On Premise.[We know it will work]
  6. On Premise sending to On Premise Non-Dynamic Group and the approval is On Cloud.
  7. On Cloud sending to On Premise Non-Dynamic Group and the approval is On Premise.
  8. On Cloud sending to On Premise Non-Dynamic Group and the approval is On Cloud.

We will go through those cases and try to see which arbitration mailbox will be invoked and what to expect. The rule is [THE FIRST EXCHANGE SERVER WHO KNOWS ABOUT MODERATION, WILL USE HIS ARBITRATION MAILBOX]

Case 2: On Premise sending to On Premise Dynamic Group and the approval is On Cloud.

Since the sender [Let us say Alice] is on premise, and the on premise Exchange knows about the fact that the dynamic group is moderated, it will use the on premise arbitration mailbox. So the email will be forwarded to the on premise arbitration mailbox.

The arbitration mailbox will send email to the moderator [say his name is Bob and his mailbox is in Office 365]. Bob will receive email from [] saying hey please approve this email.

Bob when he approves the email, he is like sending email to that arbitration mailbox, so it is Bob’s mailbox sending email to All sounds good. Arbitration mailbox will release the email, letting the on premise Exchange transport engine to deliver the email to that group.

Case 3: On Cloud sending to On Premise Dynamic Group and the approval is On Premise.

Now this is interesting. Alice is Office 365 user and trying to send email to dynamic group on premise that is moderated. Since Exchange Online do not know anything about Dynamic Groups created on premise because they are not synced to Azure AD, it just forward the email as is to on premise Exchange.

On premise Exchange will send the email to the on premise arbitration mailbox, approval will be sent to the on premise moderator from the on premise arbitration mailbox and everything works fine here. The on premise moderator will approve the email, so he will be replying to the on premise arbitration mailbox, and then the transport engine will release the message.

Case 4: On Cloud sending to On Premise Dynamic Group and the approval is On Cloud.

This is similar to the previous case. the on premises arbitration mailbox will be used as the Exchange Online system does not know that the group is moderated as it is not synced to Azure AD. Of course now the on premise arbitration mailbox will send approval email to the cloud moderator. The cloud moderator will see the email coming from the on premise moderation mailbox, he will reply back by approving or rejecting, and all will work just fine.

Case 6: On Premise sending to On Premise Non-Dynamic Group and the approval is On Cloud.

Alice is on premise user, trying to send email to a non-dynamic group on premise, so the on premise Exchange will pickup the message, and since it is aware that the group is moderated, it will send the message to the on premise arbitration mailbox. Nothing interesting here and everything will work just fine.

Case 7: On Cloud sending to On Premise Non-Dynamic Group and the approval is On Premise.


So now Alice is Office 365 user trying to send email to on premise non-dynamic moderated group. Since Alice is in Office 365, Exchange Online is the first point of contact here, and it knows, yes it knows, that that on premise group is moderated. Why? because it is synced to Azure AD, in contrast to the dynamic groups which are not synced.

So here we go!. Exchange Online will send the email to the Exchange Online arbitration mailbox. Remember the rule: [THE FIRST EXCHANGE SERVER WHO KNOWS ABOUT MODERATION, WILL USE HIS ARBITRATION MAILBOX].

We only know that the Exchange Online arbitration mailbox has an email address that ends with

Now the arbitration mailbox in Office 365 will send email to Bob the moderator whose mailbox is located on the on premise Exchange system.

The email looks like this:



To: BOB@contoso.COM

Please approve or reject this message from Alice to this group.


Bob is a good dude, we will click APPROVE. and let us pause for a second here. Bob by pressing APPROVE, he is like sending email that looks like this:


From: BOB@contoso.COM


Please approve or reject this message from Alice to this group.


Guess who will be sending this gameness? Of course Exchange on premise, and since there is a connector between us and Exchange Online with as a destination SMTP address space, out hybrid servers will forward the message to Exchange Online.

Guess who is protecting Exchange Online? Yes it is Exchange Online Protection EOP. This EOP system has a wall of defense called Accepted Domains and Directory Based Edge Blocking. Also the domain is defined as Authoritative domain in Exchange Online.

So what all that means? Well, in Exchange Online, Accepted Domains are the SMTP domains that EOP receives email to. When a domain is configured as Authoritative Accepted Domain, EOP applies a firewall defense called Dictionary Based Edge Blocking, that does the following:

  • If I receive an email coming to an authoritative domain, the recipient in that email should be well defined as a recipient in the Azure AD [Exchange Online Address Book].
  • Else, drop the email.

So what is the point here? This is to protect from dictionary attack, where someone tries to open a dictionary and tries every possible first and last name, and tries to send storm of possible smtp addresses for a domain. If this dictionary based edge blocking is not in place, then EOP would send all those attempts to the internal Exchange system to deal with, and filter wrong address from right ones, which consume the resources of the internal email system.

To return back and talk about our case, now the email is coming from on premise Exchange from and going to some Guid address that ends with via the outbound connector to Office 365. Now EOP will check the domain and it will see it configured as Authoritative domain, and will apply the Dictionary Based Edge Blocking knowledge. So it will look at the Azure AD and will ask Azure AD ” Hey Azure AD, do you have a recipient with email address”. Azure AD will say “hell, no”, and EOP will block that message. Interesting right? This took us long time to figure it out.

Case 8: On Cloud sending to On Premise Non-Dynamic Group and the approval is On Cloud.

This is straight forward, so the Exchange Online arbitration will pickup the message, and communicate with the cloud moderator, and all will work just fine. No traffic will reach the on premise Exchange environment until the final group delivery in case the group contains on premise recipients.

Why don’t turn Dictionary Based Edge Blocking off for

We can do that by going to Exchange Online> Accepted Domains, and then we can make the as Internal Relay domain and not Authoritative. This will turn off the Dictionary Based Edge Blocking. Going back to case 7 above, when EOP receives a message going to, it will not bother asking Azure AD anything, and will just deliver the message to Exchange Online. Exchange Online knows this address, as it is one of many arbitration mailboxes in Office 365, and everything will work just fine.

Wake Up !! This should never ever been done. the domain should always be authoritative domain or other stuff will stop working.

The first thing that will not work the moment you switch that domain to Internal Relay is the Hosted Voice Mail. Hosted Voice Mail REQUIRES that the domain to be Authoritative. There is no clear reason why this is required, but it took us long troubleshooting time to figure this out and fix the hosted voice mail system.

Note: Hosted Voice Mail means that we have people with Office 365 mailboxes and using the on premise Skype for Business telephony, and we need the Skype for Business on premise to deliver voice mail for Office 365 through Skype federation with Exchange Online. This requires the domain to be configured as Authoritative domain in Exchange Online Admin Console.

Other Solution, creating contacts

So the other option that some Microsoft support engineer proposed an then we figured out it would not make sense is to create a contact in our Exchange Online system, mail enabled contact with an email address is the smtp address of the Exchange Online arbitration mailbox.

Now going back to case 7 above, when Bob sends email to and since that domain is authoritative and the Dictionary Based Edge Blocking logic will kick, EOP will try to match that recipient address with any recipient defined in Azure AD, and it will found that mail enabled contact that we just made, and it will deliver the mail to Exchange Online that knows how to deal with it.

This will work will except that there are many arbitration mailboxes in Exchange Online and we do not know how to query them. The best guess is to try to simulate the Case 7 over and over and for each new arbitration mailbox Online that we detect, we shall create a mail enabled contact in Exchange Online to trick EOP. This does not work well in the long run.

What to do?

The best thing to do is to try to scope the problem. We know we have 7 out of 8 cases working just fine, and we have only on case not working fine. Only when the moderator is on premise we have an issue.

We also do not have any issues with on premise dynamic groups, only non-dynamic groups with on premise moderator is where we need to look at.

One solution could be migrate the mailbox of all on premise moderators for non dynamic groups. This can play well, but needs some time which we cannot have now.

The other solution is this. Remember why we do not have problem with on premise dynamic groups even though they have on premise moderators? Well, because Exchange Online do not know about them, because they are not synced to Azure AD in the first place, which in place triggers the email to go to the on premise arbitration mailbox, which works just fine.

The proposed solution is to query our directory for all non-dynamic on premise moderated groups, that have on premise moderators, and put them in an OU that is not synced to Azure AD, and then create Exchange contacts for them on Exchange Online. This will solve the whole issue for now until all moderators are in Office 365.

The only bad thing about this is that Office 365 users will not be able to expand those groups because they appear as contacts, and will not see the mail tip that the group is moderated (which we can mimic by using mail tips). This will work well I believe for the time being.

Now, when Office 365 users trying to send to one of those groups, they will open address book, and see a group called The fact is this is a mail enabled contact, so Exchange Online will not know it is moderated, and will just send it to Exchange on premise, which will send it to the on premise arbitration mailbox and everything will work just fine.

Hosted Voice Mail in Office 365 Part 2



This article will talk about a real call flow scenario when leaving voice mail to hosted mailbox user via Skype for Business on Premise.

Let us imagine that Bob has his mailbox migrated to Office 365, and he is enabled for UM there. Now let us suppose that Alice tried to call Bob on his extension and Bob did not answer. How can Alice leave voice mail to Bob in this case?

Hosted Voice Mail Call Flow

  • Note: Any mention of Skype server here means the On-Premise Skype for Business Front End Servers. Any mention of Exchange Online means Office 365.
  • Bob has Skype for Business extension using on premise implementation of Skype for Business and is enabled for enterprise voice EV. He should be enabled for EV or else, nothing will work.
  •  Bob’s mailbox is located in Office 365 and he is enabled for UM in Exchange Online.
  • Alice (we do not care who is Alice, it could be someone calling from land line, it could be on premise or in Office 365, or it could be calling from her mobile) is calling Bob Skype extension.
  • Bob did not answer the call, so the on premise Skype server will look for voice mail possibility.
  • Skype server will try to see if Bob has [HostedVoiceMail] set to true [Get-CSUser].
  • If this value is set to $false, which is the default value, then Skype server will start looking if Bob is enabled for on premise UM solution. We will not cover this possibility here as this was discussed in different article.
  • If this value is set to true, then Skype server immediately knows that Bob has cloud voice mail capabilities and the hosted voice mail call routing logic will be triggered.
  • Skype server now knows it should route to Office 365 UM solution, but it needs some routing information on how to route the call and to what address. This information is available in [HostedVoiceMailPolicy] configuration, which is defined by the Skype Admin. There could be many Hosted Voice Mail Policies, so Skype needs to know which Hosted Voice Mail Policy Bob is enabled on.
  • So Skype server will issue a Get-CSUser -identity | Select HostedVoiceMailPolicy. If this value is empty, then Bob is enabled on the default Global HostedVoiceMailPolicy which is created by default in every organization. Usually this is the case.

  • Now the Skype server knows two things so far:
    • Bob has hosted Voice Mail in the cloud
    • Bob Voice Mail UM Server address is located in a HostedVoiceMailPolicy called Global.
  • Skype server will then read the Global HostedVoiceMailPolicy by running Get-CSHostedVoiceMailPolicy

  • Skype server knows now that is the Exchange Online UM server that we need to route the call to in order to play the voice mail greeting message for Bob.
  • Skype Front End Servers will then generates a new Invite and sends the call to the Edge server.
  • Skype Front End Server’s role is done at this point.
  • Now Skype Edge receives the call.
  • Edge server checks the CSHostingProvider to see if a Hosting Provider has been created for “” to find out if it should send the call out to O365 [by running Get-CSHostingProvider]

  • Edge found a hosted provider for, hence edge creates an INVITE and sends it out to
  • Once Edge sends the INVITE it reaches the Microsoft access edge proxies which relay this to the Exchange online UM servers in O365.
  • The exchange Online UM server verifies the tenant, checks Dial Plan, Then Checks the “Callee” Info from the Invite and validates if the “Callee” user has been enabled for Voice Mail in O365 and if he is then it accepts the Voice Mail.

Hosted OVA Subscriber Access Numbers and Auto-Attendants Call Flow

  • Let us assume we have a dial plan in Exchange Online called [CloudDialPlan] and Bob whos mailbox is located in Office 365, is enabled for UM on that same dial plan.
  • Let us also assume that the Office 365 Admin had configured OVA for that dial plan by assigning a subscriber number in the dial plan say +9626551333.
  • Also the IT Admin already created RTC contact in on premise Active directory with SIP address and with +9626551333 as telephone number. Also, a HostedVoiceMailPolicy is applied on that contact explicitly by using user scoped HostedVoiceMailPolicy and not the global one.
  • Now Alice is called that subscriber number +9626551333, and Skype knows this number belongs to an RTC contact. So it maps that number to a SIP URI (, and this is one of the benefits of creating that contact, to map a number to SIP URI, since Exchange UM Dial Plans only deals with SIP URI.
  • Skype will try to ring that SIP URI without luck, so it will search for voice mail possibility, and since there is no HostedVoiceMail attribute on that contact, it will check if the contact is linked to a HostedVoiceMailPolicy.
  • Now, since the contact is linked to a policy, the Skype will send SIP invite to the Edge, the Edge will send SIP Invite to Office 365, and Office 365 will realize that number is mapped to a subscriber access number on a dial plan and will play the OVA greeting.

Hosted Voice Mail in Office 365 Part 1



This article talks about how hosted voice mail works in hybrid environment. Hosted voice mail means voice mail in the cloud (Office 365) because the user’s mailbox is there. Hybrid means the user is using on premise Skype for Business.

The challenge now that the someone calls a hosted mailbox user (user with mailbox in Office 365) using the on premise Skype for Business infrastructure, and voice mail is to be invoked, how the on premise Skype for Business servers will route the call to Exchange Online (Office 365) and allow the caller to record a voice mail message that is stored on the hosted mailbox (in Office 365).

On premise Exchange UM servers cannot serve users who are hosted in Office 365. Office 365 mailbox users should use Exchange Online UM features and should be enabled for UM there.

Exchange Online UM Issues to solve

When we say hosted user, this means his mailbox is in Office 365. So hosted users cannot use Exchange UM on premise. If they are to use Exchange UM capabilities, then they should be enrolled in Exchange Online UM features.

Saying that, on hybrid model where we have users hosted in Office 365 and others on premise, it is a challenge to have Skype route voice mail messages sometimes to Exchange UM on premise and once to Exchange UM Online. There should be a flag in the user AD object that specifies weather Skype will route the voice mail traffic to on premise Exchange UM or to Exchange UM Online. This attribute is called [HostedVoiceMail].

So now, when Alice is calling Bob whose mailbox is hosted online, and Bob is not answering, Skype on premise will evaluate for voice mail possibilities. It will do that by inspecting the user’s HostedVoiceMail flag. If it is true, then Skype knows that the user is provisioned for voice mail in Office 365. If it is false, then Skype will start evaluate if the user is provisioned for on premise UM solution by trying to see if he is UM enabled and what UM dial plan he is member of.

So we have figured out how Skype can route to voice mail in the cloud and to voice mail on premise systems. Next is how will Skype initiate traffic to Exchange Online UM Services? There should be a way for Skype to know the server name for Exchange Online UM. This is where HostedVoiceMailPolicy comes to play. It tells Skype servers the DNS name to route the traffic to deliver voice mails in Office 365.

Finally, Skye front end servers do not manage SIP connections outside the corporate network, so there should be a way for the Skype front end servers to ask Skype Edge servers to open SIP traffic to Exchange Online  UM. A Hosting provider is Required in order for the Edge Server to forward Voice Mail calls to O365.

Condition to make hosted voice mail work

  1. User should have [HostedVoiceMail]equals to true usingSet-CSUser.
  2. The user should be enabled for Enterprise Voice on premise.
  3. User should havebeen assigned[HostedVoiceMailPolicy] using Set-CSUser. If this value is empty, then the global HostedVoiceMailPolicy will apply.
  4. Hosting provider Should be defined in Skype in order for Edge to route traffic to Office 365 using New-CsHostingProvider
  5. Configure EDGE for federation and DNS Server routing using Set-CsAccessEdgeConfiguration.
  6. Make sure is marked as Authoritative domain in Exchange Online Admin interface and not internal relay or nothing will work.
  7. Create at least one UM dial plan in Exchange Online.
  8. Enable the user for Exchange Online UM and assign him to UM dial plan.
  9. Connect Office 365 UMmailboxpolicy with On Premise Exchange UMmailboxpolicy. This will enable us to move already on premise Exchange UM enabled users to O365 without first disabling their UM settings, and also preserving the user’s PIN  settings.

Step 1

First thing to do is to give a tip to Skype for Business servers that this user has a voice mail in the cloud, so that Skype for Business will not waste time and try to allocate on premise UM servers to handle the voice mail traffic.

This is done by setting HostedVoiceMail attribute for the user:

Set-csuser –identity “ammarh” –hostedvoicemail $true

This will also light the voice mail icon on Skype client.

Note: You may run into an error when running this command [Set-CsUser : HostedVoiceMail property contains a value that is not recognized by Skype for Business Server.]

This will happen to users that are created after we installed the Skype for Business Server. The command will actually succeed, so if you run Get-CsUser you will find that the -HostedVoiceMail is now $true

The reason why this is happening is mentioned here.

Step 2

Hosted Voice Mail is ONLY supported for users who are Enabled for Enterprise Voice. In order to ensure all Voice Mail features for Users work accurately you need to ensure they are enabled for EV on Premise.

Step 3

Now that the Skype for Business knows that Ammarh has hosted voice mail, the next thing to do is to know how to reach that voice mail. The way to do that is via using Hosted Voice Mail Policy. This is nothing but a routing information to tell Skype how to each cloud voice mail system.

Hosted Voice Mail Policies can be Created at Global level, Site level, and at user level. The good news is that in every organization, there is an existing Global Hosted Voice Mail Policy created in advance for us. By default, each SIP user is already assigned to the Global Hosted Voice Mail Policy. If we type Get-CSUser and we inspect the HostedVoiceMailPolicy, we will find that it is empty. This means that the user is using the default global hosted voice mail policy.

There can be only on Global hosted voice mail policy, and in our case, we will just configure it instead of creating user based policy and having to apply it individually to users.

To configure the default global HostedVoiceMailPolicy:

Set-CshostedVoiceMailPolicy -Identity Global -Description “Global Hosted VM Policy for All Users” -Destination -Organization

Note that:

  • Destination should always be, as this is Office 365 UM service.
  • Organization should be and not

Claude is using cloud hosted voice mail, and he is using the default global hosted voice mail policy because the value is empty

Step 4

We need to help Skype EDGE route traffic to Office 365. To do that, we need to configure a hosted provider.

When running Get-CSHostingProvider, we found that there is already hosting provider for both Exchange Online and Lync Online, so what we did is we configure it to match the following:

It is worth noticing that the previous value for the Exchange Hosting Provider (Verification Level) was AlwaysVerifiable, but we change it to UseSourceVerification according to Microsoft documentation.

The Proxy FQDN Field should always be pointing to for every customer. The Enabled and EnabledSharedAddressSpace parameters should always be set to TRUE for every customer.

Reference article is here.

Step 5

Now it is time to configure the Skype Edge servers to support connecting to Exchange Online.

Type: Get-CsAccessEdgeConfiguration

Then run:

Set-CsAccessEdgeConfiguration -AllowFederatedUsers $true -EnablePartnerDiscovery $true -UseDnsSrvRouting

Edge Configuration to support hosted voice mail.

Step 6

Make sure is marked as Authoritative domain in Exchange Online. It took us coupe of days trying everything just to find out that it was set to InternalRelay. By default, is configured as authoritative domain. We changed it to Internal Relay because we opened a case with Microsoft regarding Email moderation problem between people in O365 and on premise. The escalation engineer started to talk about arbitration mailboxes and advise us to convert that domain to InternalRelay.

Once we changed the domain back to Authoritative domain, everything start working. The devil is in the details indeed !

Step 7

Now it is time to create a dial plan in Office 365. This is easy step, and we decided to create UM dial plans on O365 that matches the name of UM dial plans on premises.

Now, it is not a requirement to have same names between UM dial plans in Office 365 and on premise, but doing that has one and only one advantage that I will discuss here.

As we are in the case of migrating user from Exchange On Premise to Exchange Online and since the user is already enabled for UM On Premise, then to Enable him for UM in O365 you have two options.

Option 1: You can disable UM for the User on the ON Premise Exchange server and then Move his mailbox to O365 and then Enable him again For UM on the O365 Portal following the same instructions as described above.

Option 2: If you Do not wish to Disable and Re-enable the user for UM and would instead like him to stay UM Enabled while you are moving the users Mailbox then to do this you have to create the same Dial plan and Mailbox policies as you use on the ON Premise Exchange UM set up in O365 and then you can move the User with his UM settings to O365, this way his UM extension and Pin will remain the same.

The procedure for this is described very well here 

So How to create the dial plan?

I have a script that can do this:

New-UMDialplan -Name “LOC801” `
-URIType SipName `
-NumberOfDigitsInExtension 4 `
-CountryOrRegionCode 1 `
  -AccessTelephoneNumbers “+88118801”

sleep 10

Set-UMDialPlan -Identity  “LOC801” `
-DialByNamePrimary FirstLast `
-DialByNameSecondary LastFirst `
-PilotIdentifierList  “+88118801”

 Get-UMMailboxPolicy -UMDialPlan “LOC801”  | Set-UMMailboxPolicy -PINLifetime Unlimited

Step 8

From Exchange Online, you can enable the user for Exchange UM.

Step 9

Now, if a user is on premise mailbox user with Exchange UM enabled. If we want to move his mailbox to Office 365, we need to disable his UM settings, move him to Office 365, and then enable him again in Exchange Online UM.

This does not be the case if we do an extra step. For this to work correctly, you need to “map” the UMMailboxPolicy objects in the source forest to the UMMailboxPolicy objects in the target forest

We can avoid that if we have the same name for the UMMailboxPolicy in both source and target environment. Else, we need to do the mapping by running the following command in Exchange Online:

Set-UMMailboxPolicy -identity “Policy B” -SourceForestPolicyNames “Policy A”

Where Policy B is the UMMailboxPolicy in Exchange Online, and Policy A is the UMMailboxPolicy on Exchange on Premise.

Reference Article is here.

Outlook Voice Access and Subscriber Access

In order to have Outlook Voice Access capabilities for hosted users (in Office 365) we need to assign a subscriber number in each Exchange UM Dial Plan in Office 365. Each Exchange Dial Plan should have unique subscriber access number.

Saying that, we need a contact (a.k.a RTC Contact) to be created on premise to map to each subscriber number we create in Office 365. To do that, two steps need to be done:

  1. Create contact object on premise using New-CsExUmContact
  2. Assign hosted voice mail policy to that contact.

If you read previous related article about how Exchange and Lync integrates, you know that those contacts are using to map an extension to SIP URI, and to enable Skype to discover where to route the traffic going to the subscriber number.

Suppose we have a dial plan in Exchange Online with Subscriber number +9626551333. Now we need to create on our on premise system a contact using this command: from Skype on premise Shell:

New-CSExumContact -displaynumber +9626551333 –sipaddress -registrarpool -ou “OU=RTC Special Accounts,OU=Lync Accounts,OU=Service Accounts,OU=Network Management,DC=contoso,dc=com”

Going to AD, we can see that object getting created.

You can see the display name is an ugly GUID number but this is fine.

Now, remember when we talked about hosted voice mail policy, and we decided not to create one because we will be using the built in already created default global policy? Well I am not sure if this default policy will apply to this newly created object, so what I did, is to create a user based hosted voice mail policy and apply it to that contact by running:

New-CsHostedVoicemailPolicy -identity Office365UM -Destination -Description “Office 365 Voicemail” -Organization “”

and then assign it to the created contact:

Grant-cshostedvoicemailpolicy –identity “CN={9522170e-9140-462e-b0f5-5efde255d355},OU=RTC Special Accounts,OU=Lync Accounts,OU=Service Accounts,OU=Network Management,DC=contoso,DC=com” –policyname Office365UM


So all looks good, but to change the name of the contact instead of this ugly GUID, I have created the following script to do that:

$DisplayNumber = “+88118801”

$Sipaddress = “”

$Pool = “”

$Description = “O365 EXO Subscriber Access Number [OVA] for 801”

$UMContact = New-CSExumContact  -Description $Description `
-DisplayNumber $DisplayNumber `
-SipAddress $SipAddress `
-RegistrarPool  $Pool `

Start-Sleep 20

Set-ADObject -Identity $($UMContact.Identity.DistinguishedName) `
-DisplayName “Outlook Voice Access $code”

Rename-ADObject -Identity $UMContact.Identity.DistinguishedName `
-NewName “Outlook Voice Access $code”

Start-Sleep 20

Grant-CsHostedVoicemailPolicy -Identity “Outlook Voice Access $code” `
-PolicyName Office365UM

Auto Attendant

This is now an easy one to configure. It is the same as Outlook Voice Access subscriber number, but now when creating the contact object using New-CSExumContact , we will use the [-AutoAttendant $true]

Reference article for this command is here.



This article shows the call flow between Exchange and Skype for Business when someone is leaving a voice mail or trying to access OVA or auto-attendant.

Voice Mail Call Flow

So Alice just called Bob on his Skype extension, and let us say that Skype decided to route the call to Exchange UM for any reason, like Bob not answering.

  • Skype will then send SIP INVITE to the UMCallRouter.exe hosted on the CAS. Skype will always use Secure SIP (5061), but since Exchange UM can receive SIP invites from third party PBX systems, those systems may send unsecure SIP over TCP 5060. Exchange does not care if it is SIP or secure SIP as its service will listen on both ports if the startup mode for Exchange UM services is Dual Mode.
  • UMCallRouter.exe will then send SIP REDIRECT, saying “hey I got your call, but I am not the one you should be talking to that machine over there”.
  • Skype will then initiate another SIP INVITE to the UMService.exe on the mailbox role.
  • The UM worker process will send SIP 302 Moved temporarily.
  • Skype server will send SIP traffic to the UM worker process, and then the media traffic start to flow. This is Exchange answering the phone and do some greeting and get the audio message.

UM call answering flow

Alice calls Bob, and the call reach Skype, and Skype will ring all Bob end points. If Bob did not answer the call, then Skype will try to see if it can provide an option for voice mail or missed call notification.

First thing Skype will do is to see if the user is configured for hosted voice mail option by running Get-CSUser and then inspect the hostedvoicemail property and see if it is true or false. We will not discuss hosted voice mail case (that is voice mail in Office 365), so we will assume the value is false.

Since the user is not enabled for hosted voice mail, the next step is to see if he is enabled for on premise UM solution. If the user is enabled for Exchange UM, then the next challenge is how the Skype server will know which UM server it should contact?. It will answer that by querying AD and looking for the dial plan for the user. Once identified, it will then go to AD and tries to read from the AD configuration partition the UM dial plan properties. Skype server will need special permissions to read those attributes and this should be assigned by the IT administrator by running a script in Exchange called ExUCUtil.ps1.

Now assuming that the Skype server has permission to reach from AD the UM dial plan object, and since each dial plan is attached to UM servers, then the Skype server has now lists of Exchange UM servers that are servicing that dial plan, and hence it knows where to send the SIP Invite and hope for an answer. The UM component that the Skype talks to exists in the CAS server [Exchange 2013 and above]

CAS will generate a redirect, and the call will reach the mailbox server. The mailbox server sees SIP traffic, it inspects the Diversion header info, and it sees Bob extension in the form of extension or SIP URI.

So the mailbox server needs to map that extension or SIP URI to a mailbox or identity, and it do that using Exchange UM Proxy Addresses (EUM Proxies). This is just one more address that exist in the email address attribute in the user object in AD. EUM addresses start with EUM and then extension that can be SIP URI or actual extension like 1222 then @ then name of dial plan

So the mailbox server will query AD for that EUM address (which is indexed property so that searching for it will be very fast), and then will know who owns that EUM address, it is BOB.

The next step is that that mailbox server needs to know where Bob’s mailbox is hosted (that is, what is the mailbox server hosted Bob’s mailbox). Why this is needed? Well, because the greeting that Bob had recorded exists in his mailbox, so the first mailbox server will query AD for EUM proxy and will figure out the which mailbox server hosting his mailbox.

There are three types of greetings and they are stored on the user’s mailbox:

  • Fully recorded by Bob
  • Bob only record how his name is pronounced, and then Exchange UM will say (Hey, you have reach the mailbox of The Thing You Recorded)
  • The Exchange UM text to speech engine will try to pronounce your name and play fully automated greeting.

The mailbox server will then connect using MAPI to Bob’s mailbox and will get the greeting and will return through RTP to Skype or PBX to the caller.

The caller then will need to make a decision, will it hang up or leave a message.

If Alice leaves a message, her message will go through Skype back to the Exchange server, that will record it using the configured codec, optionally convert it to text (voice mail preview), and ends up delivering through the transport mechanism to Bob’s Delete repeated word

This is SMTP traffic going from the mailbox server through the transport pipeline to Bob’s mailbox. Because It is SMTP, then all the transport rules can be applied here and this is a powerful thing. They go through the dumpster, the safety net, and it can be protected via IRM. You can also configure retention policies on voice mail messages.

Now if Alice does not leave a message, a missed call notification will be generated by the mailbox server who was playing the greeting, and it will go via the same transport pipeline.

Diversion header

Usually the PBX system knows why a call is going to voice mail system, perhaps the party did not answer or busy. Exchange has no way to know that, because it is PBX independent, and it does not use any specific PBX vendor API to know why this call comes to it (why a voice mail request is made to Exchange).

So what exchange gets instead is a SIP header (Diversion header) that indicates where the call is really coming from (extension) along with wit the extension that is supposed to go to.

Let us say that the pilot extension in the PBX is 7000, and Bob’s extension is 9000 and Alice’s number is 2565551212, so the diversion header will say that the call is FROM 2565551212, and it was originally to extension 9000, but it is coming from extension 7000, so Exchange will then try to map the 7000 extension to EUM proxy in AD.

Two notes here:

  • Diversion header is not used when connecting to hosted voice mail in Office 365 as Microsoft has new architecture of knowing the extension information when connecting to O365.
  • the pilot extension is not used in Exchange UM and is always left blank.

In case of auto attendant, there is no need for the mailbox to search for EUM, because it knows this is the target, and it will start playing the auto attendant media.

What is ExchUCUtil.ps1?

It is a PowerShell script located in any installation of Exchange, you run it without any parameters and it will do some magic.

The person running this tool needs to have permissions on both the Skype environment and the Exchange environment.

When you should run the tool? When you have new Skype servers deployed as those are candidate to be defined as UM IP gateways.

What this tool do? Well, remember that Skype servers need to identify which dial plan the user in, and then what UM servers servicing that dial plan, so that they know where to route the call next? To do that, Skype servers need access to the UM dial plan objects located in the AD configuration partition. Well, running the script will give Skype servers access to read UM dial plan information in AD.

What else, well the script will also create a UM IP Gateway for each Skype server it fins, so that you can use it when you configure your dial plans.

Outlook Voice Access Call Routing

OVA is a greeting that Exchange plays and gives users ability to reach their email and do many actions. OVA configuration is just deciding on the OVA number that people will dial. This number is called OVA Access Number or Subscriber Access number.

This number is configured in one place which is inside the UM dial plan configuration. One OVA number cannot serve two different dial plans, so you need different numbers for different dial plans.

When someone calls that subscriber access number or OVA number, the user will be one of two:

  1. Authenticated user: OVA answers the call, and asks the user to authenticate by providing extension and PIN. the extension is just the four digit number like (1222) and not (801 1222). Since there is one OVA number per dial plan, there is no way for OVA to be confused between two users having same extension number but located in different UM dial plans.
  2. Unauthenticated user: If the user did not authenticate, he can only do directory search.

So what is the big deal here? Well, I will give you a confusing case, and walk you through the way Microsoft decided to implement a resolution.

Imagine you have a UM dial plan say LOC801 that is serving Jordan office. Now you decided you want to give people OVA access, so you allocate a DID number say +96265515333 and you want anyone in GSO dialing that DID to end up in the Exchange OVA greeting, so that they can put their PIN and have access to their email.

So you opened the UM dial plan configuration, then you configured the Outlook Voice Access number there. This means that when Exchange UM receive a call directed to that number, it knows it should play the OVA greeting.

So, you configured your PBX to direct calls to +9626551333 to the Skype servers, but the problem is that how can you instruct Skype to route that call to Exchange UM?

Problem 1: well, Skype servers need to see a user or contact in AD that has that number configured on it, or else it will try to route it through mediation to the external PBX system and try to dial it out.

Problem 2: moreover, the UM dial plan is configured as SIP URI dial plan, so the Skype server should route calls to Exchange UM via SIP URI and not via a number (+9626551333)

To solve the first problem, Microsoft decided that we should create a user in that is configured with +962551333 as phone number, bust since user objects are heavy objects and needs passwords, then they decided that it makes sense to create AD contact object with +9626551333 as its phone number.

To solve the second problem, we need to give that contact a SIP URI so that Skype can send that SIP URI when it sends a SIP invite to Exchange UM. Remember that Exchange UM only accepts SIP URI for the destination extension.

To make the life easier to IT Admins, Microsoft provided two ways to create such contact:

New-CsExUmContact -SipAddress -RegistrarPool -OU “OU=ExUmContacts,DC=contoso,DC=com” -DisplayNumber +9626551333

Actually running this command is note enough in case of on premise UM integration. As we need to make Skype know what dial plan this contact belongs to so it can route the call to Exchange UM.

This can be done by doing another Set-ADObject and setting the OtherIpPhone property for the contact and inject the UM dial plan information there.

To know exactly how to do such PowerShell commands manually, download this script.

This utility will do it all. It will create contact object in AD, it will assign SIP address and access number (+96265515333) and it will inject the UM dial plan information in the OtherIpPhone attribute

So now, suppose we used the PowerShell command above, imagine someone from outside is calling +9626551333, this DID is configured to be routed to Skype. Skype will try to locate a SIP enabled object (user or contact) that has such extension or phone number by querying the (msRTCSIP-Line) attribute, and it founds a contact that we created using the PowerShell script (sometime the PowerShell command will create the contact with ugly display name that looks like a GUID but this does not matter, just make sure to put a good description on it).

Now, the Skype server will say ok let ring that contact on its sip address endpoints, and of course no one will answer, so guess what, the same logic we talked about will happen. Skype will say let me try to see if it can leave voice mail or missed call notification, so it will look if that contact has hostedvoicemail policy on it, and if it does not, it will try to see if that contact belongs to UM dial plan by inspecting the (OtherIpPhone) attribute, and then will try to read the UM dial plan information from AD, from there it will lookup the UM servers serving that dial plan from the dial plan AD object properties, and then it will send SIP INVITE to that UM server containing the phone number and the SIP URI for that contact. UM server will then maps that extension +9626551333 to the dial plan OVA access number, and it will know to play the OVA greeting.

You can see that the contact object serves two things:

  1. Maps an extension to SIP URI that can be routed to the Exchange SIP URI Dial Plans.
  2. provide UM dial plan assignment to the subscriber number so that Skype can route the call.

Note: Auto-attendant works the same way, but the New-CsExUmContact PowerShell command has a switch called [-AutoAttendant <$true | $false>].

Exchange UM Architecture Part 1 of 2



This article is about exploring what are the main components of Exchange Unified Messaging platform (UM) and how call routing and voice mail features really work behind the scenes.

 Exchange UM Components

  1. UM Dial Plans
  2. UM Messaging Policies
  3. UM IP Gateways / UM Hunt Groups
  4. UM Auto Attendants

 What is Exchange Dial Plan?

Dial plans is the main and most important component in Exchange UM infrastructure. It has any usages, so will try to list them here.

UM dial plans acts from one side like telephony dial plans. They are used in Unified Messaging to make sure that user telephone extensions are unique. You cannot have two similar extensions in the same dial plan, but you can if they are in different dial plans.

UM dial plans controls the length of user extension, in our case the extension length is four digits. Going back to the previous point, my extension can be 1222, and another one say in Dubai could have the same extension, if he is located in different dial plan. This is why we are designing UM dial plans to match Skype/Lync dial plans. So we have a UM dial plan called LOC801 for GSO and a Skype dial plan called LOC801 for GSO. We also have UM dial plan called LOC803 for DXB, and Skype dial plan called LOC803 for DXB. If we did not do that, and we have just one UM dial plan for the whole network, then my extension number (1222) cannot be assigned to anyone else in the whole network.

So why 4 digits and not 7 digits like 801 1222? If we make it 7 digits then we can put the whole company in one big fat dial plan and no way we would have collisions in extension because we are adding the 80X prefix to indicate the region. There are two reasons for that:

  • If the UM dial plan number of digits is = X, then Exchange will try to take the last X digits from the user’s phone number and will assume that this is his extension. For example, my phone attribute is +96265515111 x 1222, So Exchange UM will try to take the last X digits and put it as my extension, unless we manually assign the extension number for the user during his UM provisioning. Saying that, it makes sense to make the number of digits as 4 and not 7, since the last 7 digits of my phone number does not read 801 1222.
  • Second part, if we put all people in the same dial plan, then we loose customizations needed for each office, like default language for greeting, dialing habits, and more. So suppose we have one big dial plan and the default language is English, now imagine in France office someone is leaving voice message in French and Exchange UM tries to generate voice mail preview (speech to text). Assuming that the dial plan default language is English, trying to handle French voice mail to English words would be really interesting.

So UM dial plans defines number of extensions, and provides the ability for two people to have same extensions if they are in different dial plans.

Dial plans are unit of applying policy, so we can say, prevent people to make outgoing calls to people outside this dial plan. You know, one feature of Exchange UM is giving users the ability to dial out, like for example, play my voice message on my phone.

Moreover, dial plans are mainly used for routing calls, because UM servers are linked to dial plans. Suppose the case where Skype servers wants to leave a voice mail for user John Smith, Skype will try to located the dial plan for John, and see which UM servers are serving that dial plan, and then open SIP Invite to one of those UM servers serving that dial plan. Without dial plans, there is no way Skype would know how to route calls.

This article is now hosted on my new blog platform here:

Exchange UM architecture and Exchange UM dial plan

Explore Exchange UM



This article is to introduce what Exchange Unified Messaging is really about, and go through quick listing of the features it can provide.


What is Exchange UM?

Exchange UM (Unified Messaging) is a big IVR Application*. It has:

  • Speech Recognition system, so you can ask it “read my email” and it will do that. This is same as Siri in IPhones. This feature is called Outlook Voice Access or OVA.
  • Text to Speech TTS: It converts your voice messages to text and deliver it to your inbox using a feature called Voice Mail Preview.

* “Interactive voice response (IVR) is a technology that allows a computer to interact with humans through the use of voice and DTMF tones input via keypad”.

What does Exchange UM provide?

  1. Voice Mail solution
  2. Outlook Voice Access or OVA: Users can call their inbox to access voicemail, email, calendar and contacts (all read to the user with text-to-speech).
  3. Play on Phone: Allows users to play their voicemails on a phone, rather than through their computer speakers.
  4. Outbound Calls.
  5. Auto Attendant: Has a set of default prompts but can also have company-specific prompts (can be voice or DTMF)
  6. Missed call notifications: delivered in your inbox.
  7. Voice Mail Preview: Uses speech-to-text to take a voicemail and put a text preview in your inbox (uses best guess for words it does not understand).
  8. Message Waiting Indicator.
  9. Others.

What is Outlook Voice Access or OVA?

Outlook Voice Access users can use Outlook Voice Access when they access the voice mail system from an external or internal telephone.

  • Access voice mail.
  • Listen to, forward, or reply to email messages.
  • Listen to calendar information.
  • Access or dial contacts who are stored in the organization’s directory.
  • Accept or cancel meeting requests.
  • Set a voice message to let callers know the called party is away.
  • Set user security preferences and personal options.
  • Search for users in the directory of the organization.

This article is now hosted on my new blog platform here:

Introducing Exchange UM

Exchange 2016 Hybrid : TLS negotiation failed with error UnknownCredenta


I was adding couple of Exchange 2016 servers with CU2 to the Hybrid configuration wizard to send and receive emails to Exchange Online. On Exchange Online Admin center, I configured the receive connector to Office 365 o verify the subject name on the certificate for TLS authentication.

The problem is that emails are not being sent to Office 365 via the send connector. After enabling the protocol logging on my Exchange 2016 hybrid servers [Get-SendConnector “outbound to Office 365” |Set-SendConnector -ProtocolLoggingLevel verbose] , and opening the smtpsend log file, I can see many TLS failures:

016-07-19T12:13:14.863Z,Outbound to Office 365,08D3AFC581A92DD3,3,,,>,EHLO,
2016-07-19T12:13:14.910Z,Outbound to Office 365,08D3AFC581A92DD4,2,,,<,”220 Microsoft ESMTP MAIL Service ready at Tue, 19 Jul 2016 12:13:14 +0000″,
2016-07-19T12:13:14.910Z,Outbound to Office 365,08D3AFC581A92DD4,3,,,>,EHLO,
2016-07-19T12:13:15.004Z,Outbound to Office 365,08D3AFC581A92DD3,4,,,<,250 Hello [] SIZE 157286400 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS 8BITMIME BINARYMIME CHUNKING,
2016-07-19T12:13:15.004Z,Outbound to Office 365,08D3AFC581A92DD3,5,,,>,STARTTLS,
2016-07-19T12:13:15.051Z,Outbound to Office 365,08D3AFC581A92DD4,4,,,<,250 Hello [] SIZE 157286400 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS 8BITMIME BINARYMIME CHUNKING,
2016-07-19T12:13:15.051Z,Outbound to Office 365,08D3AFC581A92DD4,5,,,>,STARTTLS,
2016-07-19T12:13:15.145Z,Outbound to Office 365,08D3AFC581A92DD3,6,,,<,220 2.0.0 SMTP server ready,
2016-07-19T12:13:15.145Z,Outbound to Office 365,08D3AFC581A92DD3,7,,,*,” CN=*, OU=IT, O=contoso International (L.L.C), L=Dubai, S=Dubai, C=AE CN=thawte SHA256 SSL CA, O=””thawte, Inc.””, C=US 0D92CFF6070B73AD5722EC8B4DA3389B AAA3D3DADA6891A2CCB3134D0B2D7764F1351BC4 *”,Sending certificate Certificate subject Certificate issuer name Certificate serial number Certificate thumbprint Certificate subject alternate names
2016-07-19T12:13:15.145Z,Outbound to Office 365,08D3AFC581A92DD3,8,,,*,,TLS negotiation failed with error UnknownCredentials

I am sure the certificate is fine as the other hybrid servers are using the same certificate and they are able to send emails to Office 365. Also on the event viewer, I am seeing the following error:

TLS Error Office 365 Exchange Hybrid


So finally, I tried something and it worked. I opened the certificate store, and I was checking the permissions on my certificate private key, the certificate I am using for the TLS connection.

TLS Error Office 365 Exchange Hybrid2

I can see the following permissions on the private key:

TLS Error Office 365 Exchange Hybrid3


So I added the Network Service and I gave it READ access. After that everything worked just fine. Try to give EVERYONE Read access if things are not working yet.

Hope this will help someone, leave a note if it did 🙂

Office 365 and Group Moderation Tips

In the process of testing out Office 365 and Exchange hybrid configuration, an interesting thing happened that I want to share with you.

I have an on-premise Exchange 2010 implementation and couple of users are hosted at Office 365. All hybrid configurations are set and connectors are configured to route emails between the two spaces.

Everything is working fine, and mailboxes hosted on Office 365 are working just fine. Things started to get interesting when people start to send emails to moderated distribution groups.

When someone sends email to a moderated groups, and the moderator is hosted on Office 365, the buttons for Approve and Reject are not showing at his email client.

It turned out that a setting called TNEF (Transport Neutral Encapsulation Format) is causing this to happen. We need to make sure TNEF format is enabled when sending emails out to Office 365 tenant.

The TNEF setting is configurable per remote domain (Get-RemoteDomain) and (Set-RemoteDomain).

By default, there is a default RemoteDomain configured in your Exchange environment called (Default). If you hit (Get-RemoteDomain), you will see all settings that controls the behavior of email communications and format when sending emails to external parties. One of the settings is TNEFEnabled.

Now that we have Office 365 hybrid setup, the HCW creates for us a remote domain in the on-premise organization to allow TNEF (

That is great. So all what we need to do is to configure that remote domain (Set-RemoteDomain -TNEFEnabled ….) and all is done, right?

There is a small thing left to say. When Office 365 sends emails regarding moderated groups, the messages come from a system mailbox in the tenant with email address SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} So we need to add a new remote domain called

So let us start typing some PowerShell commands:

New-RemoteDomain -Name “Hybrid Domain –” -DomainName

Now we have two remote domains:


We have then to configure both remote domains to allow TNEF format. I also recommend configuring many other settings on the way.

Set-RemoteDomain -Name “Hybrid*” -IsInternal $true -TargetDeliveryDomain $true -AllowedOOFType InternalLegacy -MeetingForwardNotificationEnabled $true -TrustedMailOutboundEnabled $true -TrustedMailInboundEnabled $true -UseSimpleDisplayName $true -TNEFEnabled $true

That’s great. Now we have configured both remote domains to enable TNEF format. I have also noticed that when on premise mailboxes try to communicate with the Office 365 system mailbox for moderation actions (Approve,Reject), they are receiving authentication errors. To fix that, add the to the address space of the Office 365 connector:

Set-SendConnector “Outbound to Office 365″ -AddressSpaces @{Add=””}

Finally, it makes sense to instruct the Office 365 tenant to treat the on premise Exchange organization the same way. Suppose my on premise domain domain is, then connect to your office 365 Exchange PowerShell, and type:

New-RemoteDomain -Name “Hybrid Domain –” -DomainName

Set-RemoteDomain -Name “Hybrid*” -IsInternal $true -TargetDeliveryDomain $true -AllowedOOFType InternalLegacy -MeetingForwardNotificationEnabled $true -TrustedMailOutboundEnabled $true -TrustedMailInboundEnabled $true -UseSimpleDisplayName $true -TNEFEnabled $true.

Reference Link 

Azure Sync Case – Conflict between UPN and SMTP address

I was working heavily on AD Sync Tool with all its versions including the AAD Connect tool. And I came across an issue that will cause you trouble soon. So in this blog post I will share my experience with you.


My environment was consisting of one AD domain with Exchange 2010 on premise and a single sign on experience. The AD domain and SMTP domain is the same (

I have a manager called John Smith:

  • UPN :
  • SMTP address :

This manager came to me asking me to add a secondary SMTP address for him Since that SMTP address is available, I agreed.

Azure AAD Sync UPN vs SMTP 12121

Life goes on. John is a big manager and he used his nice clean new SMTP in all his communications. He printed the new email address to his business cards.

So far, we have all our mailboxes are on premise and we do not have any Office 365 implementation.

The Problem

After 10 years, the corporate decided to start using Azure services and they decided to start with AD Sync next month.

Meanwhile, a new employee is hired with name John William. The IT department assigned him the following:

  • UPN :
  • SamAccountName : Contoso\John
  • SMTP Address :

Everything is fine so far and there is no single conflict.

Azure AAD Sync UPN vs SMTP 1212122

Now when we started to Sync users to Azure AAD, John Smith user is no longer synchronizing to Azure AD and the AD sync tool is giving an error for that user.

“Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services:[ProxyAddresses smtp:].Correct or remove the duplicate values in your local directory.”

After opening a case with Microsoft, we reviewed our AD Sync configuration and after opening the AAD Connect sync tool, we confirmed that we are using ObjectGUID as the anchor attribute and not email address.

Microsoft confirms that when an on premise mail enabled user is synched to Azure AD, he is assigned a secondary SMTP in the form of his UPN. So in this case, when John William is being synched to Azure AD, Azure will try to stamp him with a secondary SMTP in the form of which causes a conflict with John Smith user.

So although there is no conflict on premise, Azure introduces this type of conflict and throwing sync error.  Microsoft answered us : “THIS IS BY DESIGN DEAL WITH IT”

How big this problem is

Now, we contacted John Smith and asked him to give away his lovely SMTP address. What do you think his reaction is ? He is using that email address since years and he cannot give it away. Further more, if he agreed to give it away, and if Azure assigned it to John William user, then people sending emails to will be sending to John William and this is by itself a security and privacy issue.

So we went to John William and ask him to change his UPN and SamAccountName. This solves the problem for a while, until a new employee come again with the name John Robert, and the IT found that Contoso\John is not used in the enterprise and so they assigned it to John Robert.

Now suddenly the Sync Tool will throw a sync error and the same loop happens over and over.

Imagine you have many users who used to have clean SMTP addresses and you have to go through them one by one and do this 🙂

Compare your on Premise AD users and Azure users – One by One !

If you are synchronizing your on premise Active Directory with Azure Active Directory, then you know for sure that maintaining a healthy synchronization is not an easy thing to do.

I want to give you my experience in synchronizing a single domain AD to Azure AD, using ObjectGuid as anchor attribute.

The Challenge

I am using Azure AD Connect to synchronize AD objects to Azure AD. The Azure AD Connect tool is nice, and it gives you the health of the synchronization process and a nice error messages if there is a problem synchronizing one of your on premise AD objects. I used the AD connect tool for a month, and everything was fine. No errors and everything looks clean.

I then noticed that couple of users are having problem with Office 365 and i discovered that they have never synched to Azure AD in the first place. I did Get-MSOLUser on them and no results are returned. I had to go to Azure AD Connect and force Full AD Import to sort out this issue.

I become so worried about this, and I started to compare the number of AD users and Azure AD users to at least ensure matching numbers. Count AD users and Azure AD users and compare them is not enough, as there is no guarantee that the same objects represent these numbers.

I then came with an idea. I wanted to take each AD user, collect his ObjectGuid, and then compute his ImmutableID, go to Azure AD, and search for that ImmutableID, and finally linked the AD user with his Azure AD copy. We will do that for all AD users. Finally, we can identify AD users that does not have Azure copies, and Azure AD users that are not mapped to AD users.

This will guarantee that each one of your AD users are mapped to Azure AD users. Along this journey, the script will generate couple of information:

  • AD users not in Azure
  • Azure users not in AD
  • Azure users with Synch Errors
  • Filtered AD users from Synchronization
  • Total number of AD users
  • Total number of Azure users
  • Last AD Sync time

Compare you on Premise AD users and Azure users 11

Conditions to use the script

  1. This script assumes you are using ObjectGuid as anchor attribute
  2. If you have multiple domains, forests or you are doing filters to scope AD users by OU or attribute, then you must write your script block to populate the $ADusers_Raw variable, by searching inside the script for (Raw data collection from AD) region. You can find examples there to do that. By default the script will do Get-ADuser to retrieve all users.

Compare you on Premise AD users and Azure users 2

Script Visuals

The script provides many visuals to help you see what is going on:

  • The script code is divided into regions that you can expand separately for better script browsing.
  • Progress bars will appear during running the script to give you a feel and sense of what is going on during the run time of the script.
  • Summary information is displayed on the PowerShell console window with summary statistics.
  • Results are written at the end of the script in two locations:
    • The PowerShell console window.
    • Couple of files that are generated on the script running directory.


The script connects to Active Directory and gets a list of users (Get-ADUser) , and then connects to Azure Active Directory AAD and gets all azure users (Get-MSOLUser). A comparison then is performed by mapping each AD user with his Azure user, and identify un-synchronized AD users that do not have a mapped/synched Azure copy.

This script assumes that ObjectGUID is used as the anchor attribute to link/map AD user and Azure AAD user. If you are using any other attribute, then this script is not for your case.

The script needs to get the list of AD users that you are synchronizing to Azure AD. Microsoft Sync tool gives you the ability to filter by OU or by attribute. Another tricky part of the script is when you are synchronizing multiple domains or perhaps multiple forests. For all those different cases, it is your job to populate the variable called ($ADusers_Raw) located under (Raw data collection from AD) region in this script.
By default, the script will do Get-ADUser to populate this variable. In your case, you may need to write your own script block to collect all AD user objects that you are synching to azure.

Script Parameters

.PARAMETER ScriptFilesPath
Path to store the script output files. For example C:\ , or ‘.\’ to represent the current directory.

As the script needs to connect to Azure, an internet connectivity is required. Use this option if you have an internet proxy that prompts for credentials.

.PARAMETER CreateGlobalObject
The switch when used, the script will generate an extra csv file that contains a unified view of each user with properties from the on premise AD and Azure AD.


.\Compare-CorpAzureIDs.ps1 -ScriptFilesPath .\

.\Compare-CorpAzureIDs.ps1 -ScriptFilesPath .\ -Proxy:$true

.\Compare-CorpAzureIDs.ps1 -ScriptFilesPath .\ -CreateGlobalObject

Download the script

You can download the script from here.

Office 365 – This may indicate invalid parameters in your hybrid configuration settings.

I came across a case in which an organization wants to implement Office 365 Hybrid Exchange, and they have a tenant with the following licenses (subscriptions): (EOP,EOA,DLP).

They initiated the Exchange Hybrid wizard and the wizard reported the following error:

INFO : Session=Tenant Cmdlet=Set-OnPremisesOrganization -HybridDomains {} -InboundConnector 'Inbound from 866c6111-4067-46e1-bb8b-df0637594a40' -OutboundConnector 'Outbound to 866c6111-4067-46e1-bb8b-df0637594a40' -OrganizationRelationship 'O365 to On-premises - 866c6111-4067-46e1-bb8b-df0637594a40' -OrganizationName 'contoso' -Identity '866c6f7c-4067-46e1-bb8b-df0637594a40' START
INFO : Session=Tenant Cmdlet=Set-OnPremisesOrganization FINISH Time=781.2552ms
ERROR : Subtask Configure execution failed: Configure Mail Flow
Execution of the Set-OnPremisesOrganization cmdlet has thrown an exception. This may indicate invalid parameters in your hybrid configuration settings.
A parameter cannot be found that matches parameter name 'HybridDomains'.
at System.Management.Automation.PowerShell.CoreInvokeRemoteHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
at Microsoft.Exchange.Management.Hybrid.RemotePowershellSession.RunCommand(String cmdlet, SessionParameters parameters, Boolean ignoreNotFoundErrors)


We have verified that the user running the Hybrid wizard is Global Administrator on the tenant, and the strange thing is that the error specified that the Set–OnPremisesOrganization command does not have a parameter called HypridDomains. If you check TechNet, you can see this is not true. So how come?


After spending could of days with Microsoft support,  it seems that we have to add at least one E3 Office 365 licenses to the tenant in order for the PowerShell commands to work properly.