Sep 26 2018
09:15 AM
- last edited on
Jan 14 2022
03:42 PM
by
TechCommunityAP
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,
Ruairidh
Sep 26 2018 10:22 PM
Sep 27 2018 01:19 PM
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.
Sep 27 2018 09:05 PM - edited Sep 27 2018 09:08 PM
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.
Sep 27 2018 11:02 PM
Sep 28 2018 02:26 AM
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.
Sep 28 2018 06:50 AM
Sep 28 2018 07:57 AM
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).
Sep 28 2018 08:44 AM
Sep 30 2018 10:07 PM
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.
Oct 01 2018 12:16 AM
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
Note:
For Office 365 plans you get a free Exchange Server Hybrid Key: http://aka.ms/hybridkey
The Exchange On-Premises is for manage without any configuration and some settings and components need to disable such client access etc.
Eli.
Oct 04 2018 02:24 AM
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.
Oct 04 2018 02:37 AM
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.
Jul 10 2019 02:51 PM - edited Jul 10 2019 02:53 PM
@Deleted @ChrisWebbTech
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?
Thanks!
Jul 10 2019 03:01 PM
Jul 10 2019 04:06 PM
@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?
Jul 10 2019 05:30 PM
Jul 11 2019 03:21 AM
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
Jul 11 2019 03:31 AM
Jul 11 2019 11:13 AM
@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.