If you run Office 365 and use Directory sync to push Active Directory objects to Microsoft Online then you’ll likely know that if you want to make a change to a mailbox, contact or distribution group, then it needs to be done on that object within AD.
This is great, and Directory Sync is a brilliant idea but it seems to have a slight pitfall; It assumes that you’ve previously had Exchange deployed… Dirsync wants to sync Exchange AD Attributes
As an Example; You may have run into an instance where you’ve wanted apply settings such as delivery options or mail tips to a distribution group; Searching through Active directory yields no results for the correct attribute so the the setting has to be changed online/via powershell? Wrong:
Error: The action ‘Set-DistributionGroup’, ‘RequireSenderAuthenticationEnabled’, can’t be performed on the object ‘RESDEVManagers’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
Now, in order to set this attribute manually I could set the MsExchRequireAuthToSendTo to ‘true’ from the attribute editor in Active Directory Users and Computers (or ADSI)… But I don’t have Exchange, I never had exchange and therefore I don’t have that attribute in my AD schema.
This Microsoft KB article (http://support.microsoft.com/kb/2256198) explains what AD attributes are referenced and written to/from AD and a quick look in the FIM Metaverse designer confirms this:
- You could manually create the attributes from ADSI edit and set them to the correct Type as per FIM’s Metaverse designer – Messy and could cause issues
- Run the Exchange 2010 Installation and extend your AD schema to include all MsExch* attributes so you can set them from ADUC/Powershell/Some other management tool
We’ll opt for the 2nd option (its easier and automated) – Let’s get started:
- Download the Exchange 2010 Trial media from here. Run the executable and extract the files to a temp location.
- Ensure your account is a member of Enterprise Admins and Schema Admins in Active directory. Change Directory to your extracted Installation media and run the following: Setup /PrepareSchema
Wait for the tool to complete. - Open up Active Directory Users and Computers and enable View > Advanced features (If you haven’t already).
- Locate an object from the AD tree and click the Attribute Editor Tab and Scroll down to MSExch- ; Your AD Schema has been extended successfully and you now have a bit more control over objects in Office 365.
Hopefully everything’s there and the process went smoothly
You can go ahead and edit MsExchServerHintTranslations for Mailtips and MSExchRequireAuthtoSendTo for Distribution group send as permissions (as two examples)
-Patrick
Great post thanks. Are there any “gotchas” we need to be worried about with extending the AD Schema like this with regards to Office 365 functionality? Does doing this cause any side effects that we need to be aware of, or is it simply as easy as adding more attributes to modify?
Hi Ted,
Glad you found the post somewhat useful.
There is not really any Real side-effects to adding in the extra Exchange AD attributes other than the ability to more easily manage Exchange Online objects… Basically, if DirSync cannot sync the objects they would have null values on Office365; You can do the same if you wish.
One thing I should have pointed out in the above post is that you are indeed making a change to your Active Directory schema, You must always follow best practice recommended by Microsoft when doing so.
-Patrick
Hey Patrick, I came across a similar situation in a client I was working on several weeks back. However you dont seem to mention what the consequences of applying the schema extensions to the local AD and what happens when null attribute values are pushed up to the Azure AD through Dirsync. Should we be concerned about null msexch attribute values overwriting values in the Azure AD?
From my research and experience MS advise that attribute values should be exported from the Azure AD, then reimported into the on premise AD prior to synchronization, which is massively messy!
Hi Andy,
Null Values – I understand where you are coming from.
I have done this in a production environment and had no ramifications by doing so.
Are you saying that when the attributes are added to the Local Active directory the values will be null and that when DirSync runs it will push the null values to the cloud? I would like the exchange attributes but I am also concerned that when I do the exchange schema update it will mess with the users that are already being synced with the cloud. Would I have to populate those null values in our local AD?
Hi Joe,
This is a list of attributes synced by Azure AD Sync – Pretty much anything starting with msExch is what would be added by a schema update.
If your Azure AD is already synced with on-prem AD then you’ll likely not be able to edit any of these settings through the front-end (see the error in the post above instructing the admin to configure setting in AD instead); in theory they should not be set and should not cause any issues when you add them to your existing schema.
Patrick,
I don’t have a problem with the Exchange attributes being present in our schema, they’re already in place from when we migrated from On-premise Exchange 2010 to Office 365. My problem is that I don’t necessarily want my Help Desk to be going in and having to edit AD attributes for relatively simple things like setting up forwarding, adding an alias address, etc… So, is there any way to use the Exchange 2010 console to manage those attributes, without an actual Exchange server being in place? I can connect a 2010 EMC to Office 365 and manage objects that live only in 365 just fine, but since the Dirsync source is still AD, my Help Desk wouldn’t actually be able to manage any AD Exchange attributes like that.
Hi Matt,
Sorry for the late reply…
I’m fairly sure you cannot use the EMC console unless you have a hybrid co-existence configured, however I may be wrong. But then again, because you are using Directory sync – you would want the Attributed to be changed within your on-premises Active Directory.
What about using A.D’s build in Delegation feature to allow Support staff to only edit specific attributes?
-Patrick
Pingback: Set-CsMeetingRoom unable to set Line URI when leveraging CCE for PSTN |