Exchange Solutions

While reviewing the event logs on your Exchange server you could encounter the following error.

Log Name: Application
Source: MSExchange ADAccess
Event ID: 2112
Task Category: Topology

Description:
 Process Microsoft.Exchange.Directory.TopologyService.exe (PID=2700). 
 The Exchange computer dc03.supertekboy.com does not have Audit Security 
 Privilege on the domain controller dc03.supertekboy.com. This domain 
 controller will not be used by Exchange Active Directory Provider.

We ran into this recently at a customer. This was an odd error because the description specified the name of one of our domain controllers as an “Exchange Computer”. That aside, my customer was receiving this error for two of their three domain controllers (dc02 & dc03). The error was also repeated across all their Exchange servers.

To make matters worse if the customer shut down the only domain controller not reported in these errors (dc01) Exchange would become completely unavailable. As the error stated, dc02 and dc03 were definitely not being used by the Exchange Active Directory Provider.

Further analysis of the event logs also revealed informational alert MSExchange ADAccess 2080. In this alert, we could see our three domain controllers with one striking difference.

Log Name: Application
Source: MSExchange ADAccess
Event ID: 2080
Task Category: Topology

Description:
 Exchange Active Directory Provider has discovered the following servers with
 the following characteristics:

 (Server name | Roles | Enabled | Reachability | Synchronized | GC capable |
 PDC |  SACL right  | Critical Data | Netlogon | OS Version)
 In-site:
 dc01.supertekboy.com CDG 1 7 7 1 0  1  1 7 1
 dc02.supertekboy.com CDG 1 7 7 1 0  0  1 7 1
 dc03.supertekboy.com CDG 1 7 7 1 0  0  1 7 1

In the eighth column (highlighted), dc01 was reporting a 1 whereas dc02 and dc03 were reporting a 0. All other column data was identical between the three servers. The words in parenthesis are actually the column headers. They don’t line up very well in event viewer but if we count to the eighth word we see the column is titled “SACL right”. What this means is that the Exchange servers are missing the SACL right on the domain controllers marked with a zero.  Or more specifically, Exchange is missing the right to manage the security and audit logs of those two domain controllers.

When installing an Exchange update you may run into the following error.

Error:
The following error was generated when "$error.Clear(); 
 & $RoleBinPath\ServiceControl.ps1 -Operation:DisableServices -Roles:($RoleRoles.Replace('Role','').Split(',')) -SetupScriptsDirectory:$RoleBinPath;
 & $RoleBinPath\ServiceControl.ps1 Stop $RoleRoles.Replace('Role','').Split(',')
 " was run: "Microsoft.Exchange.Configuration.Tasks.ServiceStopFailureException: 
 Service 'tmlisten' failed to stop due to error:'Cannot stop tmlisten service on computer 
---> System.InvalidOperationException:  Cannot stop tmlisten service on computer 
---> System.ComponentModel.Win32Exception: The requested control is not valid for this service

The tmlisten service is associated with the Trend Micro antivirus product and specifically the Trend Micro Listener service. This service requires a password to stop and can not be disabled via either the services snap-in or command line.

Tip: It’s best practice to temporarily shut down antivirus products during the Exchange install as they have been known to increase install times by several hours. Or, in this case, completely block updates.

The tmlisten workaround

To disable Trend Micro right-click on its icon in the system tray and select Exit Security Agent.

You will be prompted to enter a password to shut down the Trend Micro services. Enter this password and click Ok.

You may need to wait about 60 seconds for the Trend Micro services to stop. Once stopped you can continue your Exchange update past this error.

Have you ever run into this problem? What did you do to fix it? Drop a comment below or come join the conversation on Twitter @SuperTekBoy.

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.