Exchange, Office365

Office 365 Directory Synchronization without Exchange server Part II

23 Comments

The question in my previous blog post was “Can we decommission our Exchange servers after moving to Office 365?” and the blunt answer was “No, you cannot decommission your last Exchange server on-premises”.

In this previous blog post I showed you what happens if you synchronize a user to Azure Active Directory from your on-premises Active Directory, and how to create a Mailbox in Exchange Online with a proper primary Email address. At the same time, it was only possible to set only one Email address, and there’s no possibility to add multiple Email addresses, nor is it possible to change any other Exchange related setting.

In this blog post I’ll discuss how to extend Active Directory with Exchange attributes to unleash more functionality and management options in Exchange Online. Please note that the solution in this blog works fine, but it is not recommended and not supported by Microsoft.

Add additional email address

As we’ve seen in the previous blog post it is not possible to change the Email address of a user in Office 365 (using EAC) when Azure AD Connect is installed. This is because the source of authority is the on-premises Active Directory.

How do we add additional Email addresses to a user? Typically, Exchange takes care of this, and the (additional) Email addresses are stored in a attribute called proxyAddresses. This is a multi-valued attribute and can contain multiple entries, i.e. Email addresses.

In our example a green-field Active Directory is used, an Active Directory that isn’t even prepared for any Exchange version. This a situation that can occur when a customer has moved from another messaging platform like Groupwise or Notes, but does have Exchange installed. As a result, the Exchange attributes are not available in the on-premises Active Directory.

To add the Exchange attributes you have to prepare the on-premises Active Directory schema for Exchange using the Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms command from the Exchange installation media:

image

After running this command the Active Directory Schema has been extended, and when checking a user account with ADSI Edit you can see the Exchange related attributes. In the following screenshot you can see the proxyAddresses attribute of a user after running the command mentioned above.

image

The new attributes need to be made available in Azure Active Directory as well. To do this you have to run the Azure AD Connect tool again and select the Refresh Directory Schema option as shown in the following three screenshots:

clip_image002

clip_image004

clip_image006

Now we can add additional Email addresses to this user.

To do this we have to edit the user’s proxyAddresses property according to the following guidelines:

  • The primary Email address format: SMTP:username@domain.com (Uppercase SMTP)
  • Additional Email addresses format: smtp:more@domain.com (lowercase smtp)

So, in the the following screenshot additional email addresses are added using ADSI Edit for the user that was created in the previous blog post:

image

And when the information is replicated to Azure Active Directory you can check the user properties in the Microsoft Online Portal:

image

You can change more options. For example, to hide a user from the Address List in Exchange Online, you have to set the msExchHideFromAddressLists property from False to True as shown in the following screenshot:

image

Please note that for the “Hide From Address Lists” option will be activated in Exchange Online only when the user’s alias attribute is set!

The following questions arise:

  • Is this useful? Maybe.
  • Does it work? Sometimes (in my experience)
  • Is this supported? Absolutely not!
  • Would I recommend this? No, I’m afraid not.

Summary

In this blogpost I showed you how to extend the on-premises Active Directory with the Exchange attributes, something that might be useful when you’ve migrated from Notes or GroupWise to Exchange Online. This way the Exchange attributes become available on-pemises which can be used for management purposes. But if you’ve moved from Exchange on-premises to Exchange Online and removed the last Exchange server in your organization, you’re basically in the same situation.

Unfortunately, Exchange Online management can only be achieved using ADSI Edit or Active Directory and Computers by directly editing the Exchange attributes, something that can be complex and that’s not supported by Microsoft. It is basically an undocumented feature, and when Microsoft changes the way Azure AD Connect works there’s the possibility your manual configuration will start to fail. I always recommend against it.

The best solution is to add an Exchange server on-premises for management purposes. In some cases, you can get the Exchange license for free, and there’s not much configuration needed on the Exchange server. This is part of my next blog.

23 thoughts on “Office 365 Directory Synchronization without Exchange server Part II”

  2. I know it’s not recommended to remove the last Exchange (see https://blogs.technet.microsoft.com/exchange/2012/12/05/decommissioning-your-exchange-2010-servers-in-a-hybrid-deployment/ for more info). However, many of our customers start fresh with an empty AD, use AD Connect and use Office 365. It’s hard for us to argue they need to install Exchange to be fully supported. They’re still technical so they can use ADSIEdit/ADUC to edit the attributes directly. However, we had a case where a new customer after a few months got their primary e-mail address changed from their domain to @xyz.onmicrosoft.com. After support with Microsoft, they gave us the information that the attribute mail and also proxyAddresses with SMTP: must be set – even though you only have one e-mail address and domain to be fully supported. We had only set the userPrincipalName to the e-mail address. Any comment and something you know anything about?

    Like

    Reply

    1. Let me see if I get this correctly…. your customer’s email address was like user@xyz.com, and this was working correctly. After some time, the email address had to be changed to user@xyz.onmicrosoft.com, i.e. the default tenant domain name.
      Did you have the proxyAddresses attributes available, or in other words, did you extend the AD Schema with the Exchange attributes?
      Txs, Jaap

      Like

      Reply

      1. Correct, they reverted back to @xyz.onmicrosoft.com for reason unknown. It was when I opened up a supportcase they told me we have to set not just the userPrincipalName but also mail and proxyAddresses (even though they only have one primary email address). Brand new AD on Windows 2012 R2 from start. No Exchange whatsoever. But the proxyAddresses attribute is available without Exchange, at least in my lab forest I just checked.

        Like

      2. Hi,
        Sorry for my late reply, been working with a customer (on Azure AD Connect ;-).
        I have been testing. Created a user account user@contoso.com, UPN is also user@contoso.com, primary address is user@contoso.com (i.e. proxyAddresses is SMTP:user@contoso.com). All provisioned via Active Directory Users and Computers. I can change this primary SMTP address to SMTP:user@contoso.onmicrosoft.com (in the proxyAddresses attribute) and this works fine (as expected). The proxyAddresses attribute is your primary point of contact when it comes to setting (multiple) Email addresses.

        Like

  3. Yes – that is also what I assume. But in this particular case, the users were created with just user@contoso.com as UPN and therfore got user@contoso.com as primary e-mail address in O365. But proxyAddresses field was EMPTY. This worked for months. Then suddenly the primary e-mail address in O365 to user@xyz.onmicrosoft.com even though no on-premise changes had been made. I contacted Microsoft and they said that you HAVE to set proxyAddresses and mail attribute to be supported. Did that and all was fixed. So lesson learned – make sure you set proxyAddresses and mail attribute and not just UPN. I guess this is one of the reason why Microsoft says that you really should have an Exchange server on-premise because otherwise things like this can occur 🙂

    Like

    Reply

    1. Ah…. now I see what you mean. It is strange that the email address changed unexpectedly, but I’m hearing rumors that Microsoft is changing behavior actively, so I wouldn’t be surprised something had changed here. You can work with the proxyAddresses property, and this will work well, but it is still not supported. As you say, the best solution is add an Exchange server on-premises. See my part III blog post about this: https://jaapwesselius.com/2016/06/15/office-365-directory-synchronization-without-exchange-server-part-iii/

      Like

      Reply

    2. That is an interesting problem. MS’s own article discusses how proxy addresses are created/populated in AAD (https://support.microsoft.com/en-us/help/3190357/how-the-proxyaddresses-attribute-is-populated-in-azure-ad) and it’s clear that if the proxyAddresses field is empty in the source directory there is a calculation that is performed to populate it in AAD. I presume this is done for the purpose of not having to rely on admins setting the proxyAddresses field in ADUC.

      Like

      Reply

  4. Just an FYI, and unless I missed something in this article, the AD schema does not need to be extended with Exchange for the proxyAddresses attribute to be available. It is not an Exchange attribute and is a default attribute in AD.

    Like

    Reply

  5. hello
    we had exchange before our migration to exchange online, we removed it.
    so the attributs as dlMemSubmitPermsor authorig exist on our local AD.
    If I modify the attribut for an existing group (created when we had exchange and already synchronized to online) it is fine but if I create a new group I can’t modify their attributs , the issue is :”there is no edit registered to handle this attribute type”.
    do you think if I update the schema it will fix my issue?
    thanks or have you an other idea?
    benedicte

    Like

    Reply

    1. I don’t think updating the schema will fix your issue here. What’s most likely this issue is that you’ve created a distribution group in Active Directory, but that this group is not mail-enabled for Exchange. Since you have removed Exchange there are no Exchange mangement tools left so you have to use ADSI Edit or something to edit the distribution group directly to make it appear as mail-enabld. I haven’t seen this before so there is a certain guess component in my reply 🙂

      Like

      Reply

      1. thanks for your reply. the issue is I can’t edit attribut via ADSI Edit, (see my error in my last post) but for example for this :msExchRequireAuthToSendTo i can…
        thanks
        benedicte

        Like

  6. Hi, im going to install AD Connect after cutover migration and decommission of my exchange 2007

    This means i already have cloud users in my office 365 tenant. What attribute i have to modify, if I want to match the users? I don’t wanna have duplicates in my office 365 tenant.

    In our environment the UPN doesn’t match our smtp efault address:

    UPN: hans.muster@contoso.com

    SMPT: muster@contoso.com

    Is There a problem?

    For the primary SMTP – address which attribute i need to modify? i read the comments, but i got a little confused (E-mail or proxy-address)?

    Thanks

    Like

    Reply

    1. Hi,

      why do you want to implement Azure AD Connect, right after doing a cutover migration and decommissioning your Exchange 2007 server? I think you took the wrong approach, and should have implemented Azure AD Connect directly from day one. But that’s too late I’m afraid.
      It will match based on UPN, so the UPN (logon name) in Office 365 should match the UPN in on-premises Active Directory. If they do match you won’t see any duplicates.
      As for the SMTP address. This is stored in the ProxyAddress property, like SMTP:hans.munster@contoso.com. Additional addresses are stored like smtp:munster@contoso.com, the difference is in the capitals. If you don’t have any Exchange on-premises and create a new user in ADUC you can use the mail entry in ADUC, but that’s only one value.

      Like

      Reply

      1. thanks for your reply. When a cutover migration is performed, directory synchronization can’t be used before or during the migration. Thats why im going to install AD Connect after the migration.

        Like

Leave a comment