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

Disabling TLS 1.0 may cause Outlook to crash for some of your clients.

I encountered this recently while upgrading a customer from Exchange 2010 to Exchange 2016. The customer had an existing Kemp Load Balancer they had been using for Exchange 2010. We upgraded the Kemp to the latest firmware and created a new Exchange 2016 VIP using the latest templates from Kemp. When we cut over our DNS to the new VIP some of our Outlook clients started to receive the errors below. Other Outlook clients continued to operate without incident.

For some Outlook clients, we would receive errors when creating a brand new profile in Outlook. Errors such as,“Windows Shell Common DLL has stopped working”

Clicking “Close Program” would then be followed by an error reporting that “System resources are critically low”.

While upgrading one my Exchange lab servers I was presented with the error, “The certificate is expired.”

This error occurred while setup was installing the transport service and it was blocking the install from completing. Further investigation of the event logs indicated that the transport certificate had expired (Event ID 12015). This made sense why the setup was failing during that step.

The challenge here was the Exchange Admin Center would no longer load. Luckily, the Exchange Management Shell was still operational. Following are the steps to renew a certificate using the Exchange Management Shell. I have included instructions for renewing both a self-signed and third-party certificate. Once renewed setup will complete. [Read more…] about Error installing Exchange update – The certificate is expired

We ran into this recently at a client. This was an odd error because it indicated we had all the necessary group memberships to perform this task. We had also just used this account to successfully extend the schema moments before.

Fixing ‘User does not have permissions’

We quickly discovered that the Default Domain Controllers Policy (which is a group policy assigned to the domain controllers OU) had been removed. It was uncertain when this may have happened but the absence of this policy was not the issue itself. Moreover, it was a setting that comes predefined by that policy. The error we were receiving was due to the absence of the User Rights Assignment, Manage auditing and security logs. This right is granted to the Exchange Servers and Administrators built-in groups. [Read more…] about Error running /PrepareAD – User does not have permissions but is a member of Enterprise Admins

Recently, while troubleshooting an Exchange environment, I ran across event ID 2142 from the MSExchangeADTopology source. This error can be found in the application logs and indicates that the topology service could not find the minimum required domain controllers needed for Exchange. For the environment, I was troubleshooting this was particularly odd as this site containing Exchange had three functional domain controllers. The environment was also a single AD site. The error in full:

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”

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

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