Office 365 Solutions

While attempting to configure an Outlook client with an Exchange mailbox I ran into an issue where the account creation would not complete. Instead, Outlook would stop on “Search for server settings” and prompt me for a username and password. The credentials of my Exchange account did not work and kicked back the login prompt.

When I attempted to test Autodiscover using testconnectivity.microsoft.com I ran into an even stranger error. Autodiscover appeared to work. But I received the error “No account settings were returned from the Autodiscover response”.

Examining the Autodiscover response I noticed that the test successfully completed against the root of supertekboy.com. This was odd as supertekboy.com is redirected to the website www.supertekboy.com where no Autodiscover responses should be happening.

However, when attempting to plug the Autodiscover URL into a web browser I found that something was responding to Autodiscover requests. It was responding with an error of “Autodiscovery must be provided a valid email address”.

This isn’t an Exchange or Office 365 autodiscover response. Instead, this was my web hosting provider responding to my Autodiscover request. Specifically, cPanel. cPanel has its own implementation of autodiscover, which allows Outlook and other email clients to automatically configure themselves for a cPanel mailbox. Unfortunately, this conflicts with autodiscover locating an Exchange or Office 365 mailbox.

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”