Remove requirement for onprem Exchange when using DirSync
as per : http://tinyurl.com/kqgjvqx
Currently for a small business who want password sync, but make the move to 365. they have to keep Exchange running on premise simply to be able to edit user attributes related to Exchange. - an active directory DLL, standalone app or simply support in the 365 portal would solve this for so many customers.
We’re reviewing the best architectural solution here and will updated when we know more.
Do you have an update on when this will work?
Exchange is not actually required, only the Schema changes. It *might* be possible to use the Kerio Connect AD Extension to prep your AD Schema without actually having a running Kerio Connect mail server but consider that "theoretical" ;-)
We're working on a solution and will update you when we know more.
Rob de Jong (Azure AD IAM) commented
Update - we're still working on this, we expect to be able to update with a timeline in the next 3 months
Hayden Greaves commented
@Don: sure it is possible to maintain via extended schema attributes, but how many people want to remember exactly which attributes need to be altered (eg. proxyaddress for a simple alias addition, including remembering the syntax and caps vs lowercase SMTP) and then use ADUC in advanced mode, or ADSI edit for simple changes? And the question was specifically for SMB, so how many SMB teams are populated with experts that can be trusted not to break things when modifying AD object attributes? Finally, these standard BAU changes are usually a Lvl 1/2 support function - good luck training those staff with attribute-level changes as opposed to a UX-friendly GUI. Ok, you can script that I hear you say - but you can script anything, the question is why hasn't Microsoft just made simple and common BAU operations available without having to maintain an on-prem hybrid server for a management GUI? BTW, that isn't a whine, it's a pretty reasonable question.
For all whiners - stop whine and simply extend your schema! Exchange is not a requirement for Azure AD connect!!!! DO YOUR FREAKING HOMEWORK, after all, you're calling yourselves IT
Graham Ford commented
It seems like this is even more important for the SMB given that the Essentials on Server 2019 won't have password synchronization. That was the only other supported option. Even for large orgs this would make much more sense than having to maintain an exchange server.
Ryan Morash commented
No news on this front was made at Ignite (I asked during the Hybrid session)
Travis Short commented
The complexity of maintaining an onsite Exchange organization for a small business is getting out of hand.
The only feature we want is password sync, yet I am required to continue maintaining a healthy Exchange environment to achieve this (if I want to have a "supported" environment). PLEASE Microsoft, give us SOMETHING to hold on to hope with! Anything!
Ryan Morash commented
Can we expect something to be announced at Ignite?
Jake Edwards commented
The on-prem Exchange server should be decommissionable. The AAD/Msol directory should become source of truth (with editable properties in o365).
Douglas Plumley commented
@Rob de Jong, just being able to source the AD user from on-premises AD via Azure AD Connect and then being able to mail enable/disable directly in EXO would be an amazing start.
So many organizations/institutions are managing complex PS scripts that have to take into account the syncing of AD --> Azure AD, Azure AD --> EXO, EXO --> Azure AD, etc.
Just being able to master mail attributes in EXO would be huge.
Rob de Jong (Azure AD IAM) commented
Hi - we're currently reviewing the best possible architectural solution for this, there are many dependencies on the attributes that are part of the Exchange schema extension for AD - but we do have a goal to get rid of these dependencies, hopefully in the coming months, for most of the scenarios.
The need to manage exchange Online Properties in AD even if you never used Exchange Server be-fore is seriously ridiculous. Just give us the ability to change the Sync direction for those attributes or enable us to write users back to active directory from azure ad
Microsoft could easily build an O365 management tool which does the local AD exchange schema update and add the functionality to ADCU (as a tab as it existed before) to manage On-Prem exchange attributes and add exchange PowerShell functionality.
Especially SMB customers which less mailboxes do not want to install and keep an exchange server to achieve a supported environment even it is via the free exchange license Microsoft offers.
An alternativ would be, not setting the Exchange Attributs to read in O365 so configuration could be done on the O365 site.
Or as stated in other comments write back of the sync tools would also an option.
I wonder why Microsoft is not listening to their customers needs.
I am not willing to migrate to Office 365 as long as there is no clean solution for this problem.
Any updates or progress? It would be nice to use the Hybrid exchange for rich mailbox moves to O365 and then remove post migration but maintain DirSync/AADConnect. This is a big thing in the SMB space.
for small business customer isnt a possibel way to let eh exchange instance for management purposes only. MS please get us a solution. Thx.
What we need is to use AD as a identity provider and Exchange online manages the mailboxes. If you run as we do with on prem AD with AAD Connect and adfs you just don't want to manage exchange attributes on-premise, no matter what. We need the option migrate and then cut the attributes synchronization for email. And when we add users we sync the account, and later adds email functionality in Office 365.
Chris K Ellsworth commented
FYI you can mange those items through the Attribute Editor within ADUC
I would echo these comments also, would very much prefer a method to keep AD Connect Sync in place WITHOUT the requirement for Exchange.
I just finished a Hybrid "Express Migration", and am using the only supported way of managing the cloud accounts using Server Essentials Role locally. However this is not as good as a proper AD Connect Sync option.