SuperTekBoy

Hybrid mail flow: TLS negotiation failed with error NoCredentials

February 28, 2017 By Gareth Gudger 3 Comments

39 Shares

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.

 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. [Read more…] about Hybrid mail flow: TLS negotiation failed with error NoCredentials

An error occurred while testing the Mail Store (Mailbox logon returned ecLoginFailure -2147221231)

February 27, 2017 By Gareth Gudger Leave a Comment

24 Shares

Ran into a strange issue recently when a client upgraded from Exchange 2010 to Exchange 2016. The client had already decommissioned Exchange 2010 so coexistence was not a factor. Their configuration was a single-server running Exchange 2016. All mailboxes were located on a single database.

Outlook clients would work fine internally. Externally Outlook would never connect. The status bar would simply report ‘Trying to connect’. Outlook on the Web and all ActiveSync clients were working fine. In addition, the Autodiscover test on the Microsoft Remote Connectivity website was passing.

In contrast the Outlook Connectivity test from the same site was failing. The following error was reported.

Testing the MAPI Mail Store endpoint on the Exchange server.
  An error occurred while testing the Mail Store.

Additional Details

Elapsed Time: 919 ms.

Test Steps

Attempting to log on to the Mailbox.
  An error occurred while logging on to the Mailbox.

Additional Details

Mailbox logon returned ecLoginFailure -2147221231. Possible causes are:

 	The user doesn't have any access to a private mailbox or public folder messaging data.
 	There are no private mailboxes or public folders on the server.
 	The server is exiting or is about to exit.


StatusCode: -2147221231

The possible causes identified by the error were equally vague. We confirmed these user credentials were working fine with Outlook on the Web and internally for the user. In addition, this was the only server hosting all the mailboxes and we could access them just fine with Outlook internally. As part of our troubleshooting we disabled MAPI over HTTP in favor of the older RPC over HTTP connection method. Unfortunately, this provided the exact same result.

Fixing logon returned ecLoginFailure -2147221231

The remedy for us was to move all users to a new database. We tested this first by creating a new database and moving a single user over. When that user passed the Outlook connectivity test (and Outlook also connected externally) we moved all other users and system mailboxes to this database.

It is uncertain what was wrong with the original database. It was barely a week old and was the default database installed by Exchange. In any case the fix was quite simple and it was easier to move the users than to continue troubleshooting for a root cause.

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

Unexpected result from Windows Live. 1007 Access Denied – Federation Trust

February 11, 2017 By Gareth Gudger Leave a Comment

25 Shares

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 come join the conversation on Twitter @SuperTekBoy.

The delegation token is NULL – Hybrid Free/Busy

February 11, 2017 By Gareth Gudger Leave a Comment

30 Shares

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.

2016: What an epic year!

January 2, 2017 By Gareth Gudger 2 Comments

18 Shares

As we begin 2017 I wanted to thank everyone for making this blog a resounding success. Your comments, your shares and your feedback mean a lot to me and I want to thank you for your continued support.

Blog Success

As we wrap up the third year at SuperTekBoy I wanted to share some numbers with you.

In 2015, SuperTekBoy welcomed 320,000 visitors who viewed 450,000 pages.
In 2016, SuperTekBoy welcomed 377,000 visitors who viewed 521,000 pages.

That’s around 18% growth. Thank you!

With your continued support–your shares, your likes, your follows–I am sure we can continue this upward trend.

Never could I have imagined 3 years ago that this site would grow to the extent it has. Thank you!

Without you, there is no need for me. So, as always, I desire your feedback. Good or bad. Plus, let me know if there is an article you’d like me to write.

Exchange December 2016 Updates

January 2, 2017 By Gareth Gudger Leave a Comment

49 Shares

It was a big month for Exchange updates. Not only did we get Cumulative Update 15 for Exchange 2013, but we also got Cumulative Update 4 for Exchange 2016.

As always, test these updates in a lab first! I recommend checking out this 7-part guide on configuring Exchange in your lab. It doesn’t take much to get one going.

The updates are as follows:

Exchange Server 2016 Cumulative Update 4 | KB3177106 | UM Language Pack

Exchange Server 2013 Cumulative Update 15 | KB3197044 | UM Language Pack

Exchange Server 2010 SP3 Update Rollup 16 | KB3184730

Exchange Server 2007 SP3 Update Rollup 22 | KB3184712

A quick word on Exchange 2007

It’s time to update. Exchange 2007 will go end of life on April 11th 2017. That’s a little over 4 months. If you are counting the days from this blog post that is exactly 100 days before Microsoft drops all support for Exchange 2007. On April 12th you will receive no more patches and no more telephone support.

If the lack of security updates from Microsoft isn’t convincing enough, check this article for a list of cool things Exchange 2013 can do. (P.S. Like the fact Exchange 2013 uses less IOPS per mailbox than 2007…say what?)

Windows Server 2016 was breaking Exchange 2016

Cumulative Update 3 for Exchange 2016 officially added support for deployment on Windows Server 2016. Unfortunately, it was quickly realized that a bug existed that would crash the IIS Application Pools after a reboot of a freshly installed DAG member. The Server Team’s official response can be found here.

If you attempt to run Microsoft Exchange 2016 CU3 on Windows Server 2016, you will experience errors in the IIS host process W3WP.exe. There is no workaround at this time. You should postpone deployment of Exchange 2016 CU3 on Windows Server 2016 until a supported fix is available.Windows Server Team

This issue has since been resolved in an update provided by the Windows Server team. The update can be downloaded here (KB3206632).

It is worth noting that Exchange 2016 CU4 will not install on Windows Server 2016 unless this update is present. [Read more…] about Exchange December 2016 Updates

Change the notification email for directory synchronization failures

January 1, 2017 By Gareth Gudger 1 Comment

45 Shares

In this article we explore how to change the email address that receives the Office 365 directory synchronization failure notifications. We will explore how to do this with PowerShell.

Let’s get started!

Getting connected

First, you will need to have access to the Windows Azure Active Directory Module for Windows PowerShell. An article detailing how to install this module and all prerequisites can be found here.

You should have an icon on your desktop named Windows Azure Active Directory Module for Windows PowerShell. Right click on this icon and select Run As Administrator from the context menu.

At the PowerShell prompt enter the following command and hit enter.

 C:\> Set-ExecutionPolicy –ExecutionPolicy RemoteSigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the
about_Execution_Policies help topic at http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"):

Press Y for yes and hit Enter. [Read more…] about Change the notification email for directory synchronization failures

Unable to connect to the Synchronization Service

January 1, 2017 By Gareth Gudger Leave a Comment

32 Shares

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 logon session does not have your updated group membership. Once you do this launch the Synchronization Service Manager again to see if you have access.

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

Main navigation