Office 365 Solutions

When I first started using Outlook for Android it was running great. I use it to check three different email accounts–two accounts in Office 365 and one Outlook.com.

However, as the months went by the app seemed to get slower and slower, with more frequent blank screens. These blank screens would appear most often when I would try to pull up my folder list (pictured below)

Although it would happen at other times as well. Such as trying to open an email (pictured below).

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. [Read more…] about No account settings were returned from the Autodiscover response

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 a 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 Synchronization Manager I received the following error on the export of my Office 365 group. “Permission Issue – Access is denied”

If you created a new calendar in Outlook on the Web you may notice the option to delete it might be missing. I see this question come up quite a lot so figured it was time to address it with a blog post.

The issue occurs when a user creates a calendar in Outlook on the Web. Often the calendar is created in error because the user was trying to add a shared calendar instead. When the user right-clicks the calendar they will see no option to delete.

We have an example of this in the screenshot below. The user has created a calendar titled, “My New Calendar”. However, when they right-click there is no option to delete.

Ran into a strange problem recently where an Exchange 2016 server could not send mail to Office 365 via hybrid mail flow. What made this situation particularly strange is that other Exchange servers in the environment had no problem sending messages over the hybrid connection. On the problem server, messages would get stuck in the queue and eventually time out.

The queues were filled with retries such as these.

451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or deliver failed to all alternate hosts.

This message tells us that the server was unable to connect to Office 365. Unfortunately, it does not give us much detail beyond that. For that level of detail, we need to enable logging on the SMTP send connector used to send mail to Office 365.

Turn up logging on the SMTP Send Connector

To enable logging on an send connector log into the Exchange Admin Center (EAC) and select the Mail Flow tab and Send Connectors sub tab. Double click the send connector named Outbound to Office 365 and select Verbose under the General tab. Click Save.

To perform this same action through the Exchange Management Shell (EMS) type the following command.

Note: Protocol logging can take some time before it starts creating log files. You can jump-start this process by restarting the Microsoft Exchange Transport service. Keep in mind this will disrupt mail flow on that server while the service restarts. The default location for SMTP send logs in Exchange 2016 is %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend.

While we waited for logging to generate some entries we also confirmed that we could successfully make a connection from the problem server to Office 365. For this task, we confirmed that we could telnet over port 25 to Office 365 and send an email message. This confirmed two things. First that this server was not being blocked on outbound port 25. Second that this server could resolve and reach Office 365 servers. [Read more…] about Hybrid mail flow: TLS negotiation failed with error NoCredentials

Despite the almost cryptic error, this one is actually quite simple to fix. In this particular case, the time in my domain was 5 minutes behind the rest of the world. Or more importantly, 5 minutes offset from the Microsoft Federation Gateway. As soon as I brought my time forward I was able to immediately release the shared domain from the federation trust.

Error 1007 can occur while making other configuration changes to the federation trust. It is not just linked to releasing a domain. So if you see this error while performing any task with the federation trust, check the time on your Exchange boxes.

Have you run into this error? What was your solution? Drop a comment below or join the conversation on Twitter @SuperTekBoy.

Ran into a strange issue recently where on-premises users could not see the free/busy information for test users I had migrated to Exchange Online. Exchange Online, on the other hand, had no problem seeing the free/busy of the on-premises users. I had just run the hybrid configuration wizard and it completed without incident. The environment had not been previously enabled for the Microsoft Federation Gateway so I let the wizard take care of that step as well.

When we tested the trust with the federation gateway we received the following error on Step 5 of 6: Requesting delegation token.

The token coming back as null seemed to be the key here. Unfortunately, the web seemed to lack any real way to fix the existing trust. We resolved to delete and recreate the trust with the federation gateway.

Recreating the Federation Trust

Warning: Before we get started with the process you will need access to external DNS zone. Recreating the trust voids the current TXT record that was used for domain validation.

To delete the federation trust navigate to the Organization > Sharing tabs in the Exchange Admin Center. Under the section titled Federation Trust click the Remove button. Click Yes to confirm.

If you run into the following error after installing Azure AD Connect then the fix might be quite simple. There are certainly a number of in-depth articles out there concerning the synchronization service but this might be one quick step to try first.

Unable to connect to the Synchronization Service.
Some possible reasons are:
1) The service is not started.
2) Your account is not a member of the required security group.
See the Synchronization Service documentation for details.

If you have just installed Azure AD Connect and attempt to launch the Synchronization Service Manager, you may receive the error above. It is likely that the second bullet point regarding membership to a required security group is somewhat true.

Chances are your account has this membership but not the associated token. The fix is possibly quite simple: Log off and log on again.

It’s possible your current login session does not have your updated group membership. Once you do this launch the Synchronization Service Manager again to see if you have access.

If that does not work, then make sure your account is a member of the ADSyncAdmins group in Active Directory. You will then need to log off and on again.

Have you run into this problem? What was your fix? Drop a comment below or join the conversation on Twitter @SuperTekBoy.