Exchange Online and Azure AD Connect


Hi everyone,


We are planning to implement Azure AD Connect in a Password Hash Synchronization with Seamless Sign On scenario, hosted on Azure B1ms Windows Server 2016 AD DC connect to on-prem AD via S2S VPN.


My company of around 100 users have had O365 for several years and the on-prem and AAD environments are totally separate for now.


One thing that has come up in my research is with Azure AD Connect in place, on-prem AD must be the source of all objects, attributes, and changes - makes sense.  Where there is confusion is Exchange Online attributes.  Several older threads on Tech Community and other forums state you cannot change EXO attributes, in an AAD Connect environment, without on-prem Exchange installed or at least its schema changes.


On review, the only EXO attributes we would change that aren't in the default AD schema are mailbox delegation (SendAs, AccessRights, etc) and email addresses (multiple SMTP addresses).  Other attributes that show in EXO such as Job Title, Address, and Tel Numbers are all available in the default schema via AD Users & Computers, so my presumption is they're not of concern.


Can anyone shed some light on this and confirm how we'd manage things like multiple SMTP addresses without the Exchange scheme in our on-prem AD?  Does this differ depending on where the object is managed (cloud only vs hybrid) or user mailbox vs shared?


Thank you,



30 Replies
If you are going to still manage accounts on-prem, then you must setup a minimal hybrid configuration to still manage the exchange attributes. I seen sometime back that Microsoft was working on a way to completely decommission Exchange on-prem, but AFAIK still today, you still require an exchange server on-prem for management.

I have often read that the on-prem Exchange server is required but we have been using Office 365 for about 3 years and decommissioned our on-prem Exchange server about 2 years ago. 


Apparently there are things we can't do without an on-prem Exchange server but we haven't found them yet. 

Same here, decommisioned on-prem Exchange more than a year ago. So far not missing anything. Although i know this is not a supported setup. But it works and we don't have to manage another on-prem server. SMTP can be set via Attribute Editor in AD card of a user (need to turn on Advanced settings). Send As and Full Access can be set through Office 365 Admin Center or Exchange Online Admin Center. They are not synced back, so it doesn't complain about AD being read-only and the setting stick.


Oh, but as we already had on-prem Exchange, our schema is already modified, so i don't know if ProxyAddress attribute and some other didn't come from that. Maybe orgs using on-prem AD and going to Exchange Online still have to update schema to have needed attributes.

Yeah that is true, since all of Exchange is basically ran via AD. So how do you guys create mailboxes then on new users? Just create the user in AD then add exchange online license and mailbox gets created since the attribute isn't there to prevent it?

Yeap, create a user in AD, add SMTP entry with main email address to ProxyAddresses attribute. Wait or force AD Connect sync, then find the user in Office 365 admin center and apply a license. Mailbox is created in a few minutes usually.


It is different with shared mailboxes though. We create them in Office 365. It shows an error that it can't save changes to AD (we don't have Azure AD Premium and writeback enabled). But mailbox is created and works correctly. There is just no information about it in local AD. Same for rooms. 


Seems sketchy ;). I’d rather just keep a VM around to stay supported hehe. It’s not that much work ;)

Well, it's debatable. I just can't force myself thinking it is normal to have to keep an Exchange server (and keep it up to date) just to administer users. MS should really do something about it (like making a slim tool instead of having to install Exchange). But they won't, as they hope everyone will eventually move fully to the cloud :) I had a number of Exchange related tickets during the year (one dealing with some rogue entry from our local AD which ended up having address, but no mailbox attached somehow) and support never asked how we manage mailboxes. MS partners helping us with migration to Office 365 also didn't warn us strongly about this. It's a common practice as i understood (maybe in small-mid size orgs).

Agree. Makes sense. I need to see if they had any exchange sessions going over if they made progress in this st ignite. Cause I want to say last year was when I sat in on one when they were talking about working on letting us decommission onprem exchange in a supported manner.

I've created shared and resource mailboxes in AD as regular users and gave them Exchange license in Office 365. After the mailbox is created, I converted the mailbox to shared and removed the license. This way I can manage them (i.e. emailaddresses) from on-prem AD. Send As etc. needs to be managed in Office 365 unless you have the Exchange schema.

Hi Ruairidh,


Microsoft recommends that you have an Exchange on Premise to configure mail settings for users, and if you uninstall Exchange on-prem you can't setup Email Address Policies or additional proxy addresses.


So Its much better to leave at least one Hybrid Exchange server on-premises even after all mailboxes have been migrated to Office 365, to allow easily manage mailboxes from a single console. Remember that since the source of authority is the on-premises AD (because AAD Connect), many changes need to be made on-premises. If there is no longer an Exchange server to manage and update mail attributes, you have to turn to 3rd party tools or work with ADSIEDIT.


In your scenario you must to do merge with Office 365 account with an on-premises AD account and to do a soft match between objects and values.


Once you will finish the merging you will be able to configure Seamless SSO



For Office 365 plans you get a free Exchange Server Hybrid Key:

The Exchange On-Premises is for manage without any configuration and some settings and components need to disable such client access etc.



Thank you for the feedback everyone - getting clearer.   We have never used Exchange (migrated from Lotus Notes) and I want to avoid installing unless totally necessary.  I will create a test domain and O365 tenant with Azure AD Connect to confirm a few things, but expect we'll avoid Exchange and just manage additional SMTP addresses using the suggestions in this thread.


One more question if anyone happens to know.  The source anchor for things will now change to be on-prem Active Directory.  Does this include user profile images?   Azure AD Connect documentation states if the on-prem value is currently null (which it is for images), Azure AD values will not be 'wiped'.   But I assume users can still update their avatar using O365?  On further inspection, it appears the avatar value comes from Exchange which, as we have never used, would not even be in our AD attributes?


Thank you again.

We have on-prem SharePoint 2010 which works with local AD users. I can set avatar in there, but it doesn't overlap with O365 avatar, which is indeed set through Exchange.

@Deleted @Chris Webb

Any update on this?  I have a project where the client has no current on Prem Exchange deployed with their on Prem AD, but have a separate Exchange Online deployment that they would like to integrate with their on Prem AD for SSO with their Exchange Online.  Is it still "unsupported" without a local exchange server to manage the mail attributes, even when exchange was never deployed on prem?



It is still unsupported! Although I believe you can get a free version of exchange to get those exchange attributes to AD

@adam deltinger Thanks for the quick reply.  I was thinking that was the case, does the free Exchange Hybrid License include a Windows Server license?  Essentially they are requiring yet another server for me to manage.  I'm just glad that 2019 is intended to be run on Server Core.  

Anyone know or is using their "free" hybrid license on an Exchange 2019 server?



Hey. Just to confirm, you don't need to install Exchange; you only need to extend the AD schema to include its attributes. Do this on your DC and you won't need another server. You are licensed to do this an O365 tenant. You can download Exchange2016-x64.exe from the Microsoft website, extract it, and run, in cmd:


Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareSchema


Yeah, as said, you only need to extend the schema so you can use and sync the correct exchange attributes

@adam deltinger and @Ru 

I should do the extension prior to installing AADC, correct?  Makes the most sense to me anyway, so that when AADC syncs, there is a place to write back the email information from Exchange Online.