Exchange Solutions

While upgrading one of 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. The 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. If you have multiple Exchange servers in your lab it is also possible to do this task remotely against the problem server.

While preparing Active Directory for Exchange you may run into the following error.

 F:\> Setup /PrepareAD /IAcceptExchangeServerLicenseTerms

Microsoft Exchange Server 2016 Cumulative Update 6 Unattended Setup
Copying files...
File copy complete. Setup will now collect additional information needed for installation.

Preforming Microsoft Exchange Server Prerequisite Check

   Prerequisite Analysis

Setup will prepare the organization for Exchange Server 2016 by using 'Setup /PrepareAD'.

Active Directory must be prepared with 'Setup /PrepareAD'. However, the current user account doesn't have the permissions required even though it's a member of the 'Enterprise Admins' group. Check whether this is a valid user account.

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.

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:

Process Microsoft.Exchange.Directory.TopologyService.exe (PID=2700) Forest domain.com. Topology discovery failed, error details: No Minimal Required Number of Suitable Directory Servers Found in Forest domain.com Site Default-First-Site-Name and connected Sites.

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:

1. The user doesn't have any access to a private mailbox or public folder messaging data.

2. There are no private mailboxes or public folders on the server.

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