Office 365 Solutions

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 a 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.

 C:\> Set-SendConnector -Identity "Outbound to Office 365" -ProtocolLoggingLevel Verbose

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.

Recently while trying to remove a domain from the federation trust I received the following error.

The URI "supertekboy.com" for domain "supertekboy.com" on application identifier "000000004804735E" couldn't be released. Detailed information: "An unexpected result was received from Windows Live. Detailed information: "1007 AccessDenied: Access Denied.".".

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.

 C:\> Test-FederationTrust -UserIdentity rsong@exchangeservergeek.com

<...edited...>

RunspaceId : e4e42cab-62f4-4d70-be15-69143b273823
Id : TokenRequest
Type : Error
Message : Failed to request delegation token.

Error. Attempted to get delegation token, but token came back as null.

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.