Group Writeback is a feature in Azure AD Connect that allows for Office 365 Groups to be written back to your on-premises Active Directory as a universal distribution group. This allows your on-premises users in a hybrid environment to send email to the Office 365 Group.
When configuring group writeback you specify which organizational unit (OU) you want these objects to be written. Each of these Office 365 groups is then represented by a separate universal distribution group that starts with the name of “Group_” followed by a unique identifier.
In the screenshot below I have two Office 365 groups that are being written back to my local AD.
The problem – Access is Denied
When I first tried to get these groups written back to this organizational unit was where I ran into problems. I was following this Microsoft document verbatim. The document specifies to open Active Directory Users and Computers and locate the account that started with “AAD_”. Which I found.
The document later uses this account to run a script. When running the script everything completed as expected. No errors.
When I checked the permissions on the organizational unit I could see that the script had added the AAD_ account with a bunch of permissions. Everything looked good.
However, I quickly started generating errors in Azure AD Connect. When I opened the Synchronization Manager I received the following error on the export of my Office 365 group. “Permission Issue – Access is denied”
The resolution – it was the wrong account
The issue was, I had the wrong account. The article had assumed Azure AD Connect was using an account prefixed with “AAD_”. This was not the case. I had this account but Azure AD Connect was not using it.
If you have ever upgraded from an older version of directory synchronization, or, moved directory synchronization from one server to another, it is entirely possible your Active Directory is littered with old directory synchronization accounts. In my case, I had both an old AAD_ account but I also had an MSOL_ account, which was what AAD Connect was currently using. Once I switched the script to use the MSOL_ account all my errors in Synchronization Manager went away and group writeback began to function.
To determine which account Azure AD Connect is using double click the Azure AD Connect icon.
Click Configure.
Select View current configuration and click Next.
The actual account used by Azure AD Connect will be displayed under Synchronized Directories. Jot this down and use this account for the script. Click Exit.
Have you experienced any problems configuring Group Writeback in Azure AD Connect? Join the conversation on Twitter @SuperTekBoy.
this was really useful
thank you
Added this msol_ user to my Administrators group and did a full sync and it worked without errors. This post is gold.
Thanks Eric
Great article Gareth,
using the MSOL_ account instead of the AAD_ account for the initializeAD cmdlet worked like a charm in my environment:
Initialize-ADSyncGroupWriteBack -ADConnectorAccount “MSOL_” -GroupWriteBackContainerDN “my_group_OU_DN”
Thanks a lot!
Sven
Thank you.
But it doesn’t work without granting “Create all child objects” permission to MSOL_ user
Screenshot: https://i.imgur.com/1vQNytb.png
Yeah Alexey, I saw “Create all child objects” was not granted and wondered why! After seeing your comment I added it on the strength that it worked for you. All ok now.
thanks.