04-23-2020 06:34 AM
04-23-2020 06:34 AM
I have a question regarding managing O365 attributes that does not exist in an on-prem AD when using AD-Sync. Surely there must be tons of companies with a Microsoft AD that has never had their own Exchange installation but migrated to O365 and are using plans that include mailboxes. I cannot find any prerequisites from Microsoft that you must or should, expand the company AD scheme with the Exchange attributes to be able to manage the mailboxes and all their attributes after the sync has been established.
As a common example, a user changes their name due to marriage. I need to update attributes like MailNickName and proxyAddresses and such to match their new name in O365.
If I would try to edit attributes directly through O365 for a user in an AD-Synced tenant, it would give the following error:
The operation on mailbox "Firstname Lastname" failed because it's out of the current user's write scope. The action 'Set-Mailbox', 'EmailAddresses', can't be performed on the object 'Firstname Lastname' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
So, I know why this is, but I cannot find a good answer as how IT managers goes about their daily work editing these kinds of things with ease. Some blogs and threads here, taking a single change as an example, says that the "supported method" is to expand the AD with the Exchange attributes and synk up the changes. But, this way I can only apply or edit some attributes in O365, I cannot erase them easily. Lets say I need to add one and erase another of 6 e-mail alias for a mailbox. I can add one through ADUC and set proxyaddresses = smtp:Firstname.firstname.lastname@example.org and that will be added to the mailbox on the next sync but it will not take away any old ones. So, how would I delete one?
If we have an “non personal” e-mail alias that needs to be transferred from one mailbox to another, how would I easily do that through ADUC?
What is the best practice to alter Exchange attributes on a O365 accounts when synked with an on-prem AD that has never had an Exchange installation? Should I brake the synk each time and edit all the changes directly in O365 and then re-apply the synk? I work with hundreds of smaller companies that now plan to take their step up to O365. Surely the answer cannot be to expand all these companies AD schemes with Exchange attributes and alter attributes on a daily basis for thousands of users through ADUC?
Hopes for a good answer,
Best regards, Karljohan
04-23-2020 07:33 AM - edited 04-23-2020 07:38 AMSolution
Hi, when you synchronise your on-premises AD to Azure AD with AADC, it is Microsoft recommended/supported practice to install an Exchange 2016 management server and configure hybrid co-existence. If you have O365 Enterprise licensing, then you will qualify for a free Exchange 2016 hybrid licence key. This is conditional on no mailboxes being present on the server. This is the best way to manage attributes such as secondary email addresses in a hybrid identities methodology.
However, it is also possible (but not really recommended) to manage on-premises attributes without the Exchange Management server by using either ADSI edit (to be used with great caution), or by enabling Advanced Features in AD Users and computers, which will enable the attribute editor tab in the user properties. These methods will allow you to add and remove smtp addresses by modifying the proxy addresses filter setting.
I highly recommend the first option, as it is free to setup if you have O365 E1 or E3 licences and offers far more control of those attributes which must be managed on-prremises. You just need to spin up a server to install Exchange 2016 on (which may require a schema update), and then you can run the Hybrid Configuration Wizard.
04-23-2020 09:42 AM
Just to add to the above, at minimum you should extend the on-premises AD schema with the Exchange attributes. Regardless on whether you plan to keep an Exchange box for management purposes or not.