Exchange Solutions

I recently ran into an issue where the Microsoft Exchange FrontEnd Transport service refused to stay started. As a result, no external mail was being delivered to the Exchange server.

From the Services app, I could start the service, but it would stop within a couple of seconds.

When reviewing the Application logs in the Event Viewer I ran into a few separate errors with a source of MSExchangeFrontEndTransport. The first error was merely a symptom of a broken Front End Transport and not the root cause. We ignored this one and moved on.

Inbound direct trust authentication failed for certificate %1. The source IP address of the server that tried to authenticate to Microsoft Exchange is [%2]. Make sure EdgeSync is running properly.

The second error gave us the clue we needed. This error indicated something else was already listening to port 25.

The address is already in use. Binding: 0.0.0.0:25.

When installing an Exchange update you may run into the error; Service: MSExchangeHM failed to stop.

[ERROR] The following error was generated when "$error.Clear(); 
& $RoleBinPath\ServiceControl.ps1 -Operation:DisableServices -Roles
($RoleRoles.Replace('Role','').Split(',')) -SetupScriptsDirectory:$RoleBinPath;
& $RoleBinPath\ServiceControl.ps1 -Operation:Stop -Roles:
($RoleRoles.Replace('Role','').Split(',')) -IsDatacenter:([bool]$RoleIsDatacenter)" was run:
"Microsoft.Exchange.Configuration.Tasks.ServiceStopFailureException: 
 Service 'MSExchangeHM' failed to stop due to error:'Cannot stop MSExchangeHM service on computer '.'.'. 
---> System.InvalidOperationException:  Cannot stop MSExchangeHM service on computer  '.'. 
---> System.ComponentModel.Win32Exception:  The service has not been started   
    --- End of inner exception stack trace ---
    at System.ServiceProcess.ServiceController.Stop()

The MSExchangeHM service is part of the Managed Availability feature in Exchange. Managed Availability performs monitoring and self-healing to ensure Exchange stays up and running. This is a service you want to ensure stays running during normal operation, but in this particular scenario, we need to terminate the service so our cumulative update can complete.

The following servers in the Windows Failover Cluster are not in Active Directory: <server name>. This is usually the result of an incomplete membership change (add or remove) of the database availability group.

I ran into this error recently while trying to remove two Exchange 2010 members from a database availability group (DAG).

The error stated that a member of the DAG, a server named EXC3, did not exist in Active Directory. This was odd because queries to the Exchange 2010 management tools only returned two Exchange servers–EXC1 and EXC2.

We further confirmed that there was no computer account for EXC3 in Active Directory Users and Computers. We did, however, see remanents of EXC3 in ADSI Edit.

Talking with our customer we discovered that there had been a third Exchange server, named EXC3, that had crashed and was never recovered.

Fix–The following servers in the Windows Failover Cluster are not in Active Directory

To verify the status of all nodes in your database availability group, open PowerShell and import the Windows Failover Clustering cmdlets with Import-Module.

 C:\> Import-Module FailoverClusters

Next, run the Get-ClusterNode cmdlet. This will retrieve the status of all our nodes.

 C:\> Get-ClusterNode

Name                                                  State
----                                                  -----
EXC1                                                     Up
EXC2                                                     Up
EXC3                                                   Down 

In the example above, we can see EXC1 and EXC2 are operational, whereas EXC3 is offline.

Because EXC3 no longer exists (and the fact we plan to collapse the entire DAG anyway) we can forcibly evict the failed node. To do this issue the following command.

 C:\> Get-ClusterNode -Name "EXC3" | Remove-ClusterNode

Remove-ClusterNode
Are you sure you want to evict node EXC3
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

You will be prompted to confirm. Press enter to accept the default action of “Yes”.

If we repeat the first Get-ClusterNode command we will only have the two operation cluster nodes remaining.

 C:\> Get-ClusterNode

Name                                                  State
----                                                  -----
EXC1                                                     Up
EXC2                                                     Up

With no more failed nodes we can remove the two operational nodes using either the Exchange 2010 management console or PowerShell.

Have you run into this error while add or remove members to a DAG? What did you do to fix it? Drop a comment below or join the conversation on Twitter

While applying a cumulative update I ran across the following error.

Warning:
An unexpected error has occurred and a Watson dump is being generated: Could not find a part of the path 'C:\Windows\Temp\ExchangeSetup\bin\EnterpriseServiceEndpointsConfig.xml'.

The Exchange setup log essentially repeated this same error, without any additional clues. The C:\Windows\Temp\ExchangeSetup\ folder is a staging area used by setup to unpack temporary files. These files are copied to this temporary location during the ‘Initializing Setup’ and ‘Copying Files’ steps.

When navigating to this folder it became apparent that not only was the file in question missing but the entire parent folder too.

When performing a cumulative update on Exchange 2013 I ran into an issue where the finalization step was hanging as 45%.

When I checked the Exchange Setup logs I saw the following repeated over and over.

Service  'MSExchangePOP3BE' failed to reach status 'Running'  on this server after waiting for '25000' milliseconds.
[WARNING] Service checkpoint has not progressed. Previous checkpoint='0'- Current checkpoint='0'.
Previous service status query time is '7/5/2018 1:35:37 AM'.
Current service status query time is '7/5/2018 1:36:02 AM'.
Will wait '25000' milliseconds for the service 'MSExchangePOP3BE' to reach status 'Running'.

In this instance, the Exchange setup was unable to start the POP3 backend service. Attempting to start the service manually through the Services MMC also failed. Upon checking the System Event Log the following error was reported.

The address is already in use. Binding: 0.0.0.0:9955.

This error indicates something else was already listening on port 9955, which was preventing the POP3 backend service from starting (and setup from completing).

While upgrading an Exchange 2013 server to the latest cumulative update, I ran into the following error while setup was configuring prerequisites.

Service 'WMSVC' failed to reach status 'Running' on this server.

When attempting to start the service manually via the Services MMC, it refused to start, resulting in the following error.

Windows could not start the Web Management Service on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code -217483640.

When reviewing the System Event Log an equally cryptic error was displayed.

The Web Management Service service terminated with the following service-specific error: Unspecified error

When migrating mailboxes between Exchange versions using the Exchange Admin Center you may receive the error:

Nullable object must have a value.

This error will appear when you navigate to the Recipient > Migration tab and click View Details on a migration batch. In the screenshot below we are examining a migration batch named “Test Migration to Exchange 2016” which contains two users. We are attempting to move these two users from Exchange 2013 to Exchange 2016.

From this screenshot, you will notice the Status column reports both users as successfully migrated. However, the Data Migrated and Migration Rate attributes in the right-hand pane are missing values. For an executed migration batch these attributes should contain metrics.

When upgrading to Exchange 2016 you may receive the errors, “There was a problem loading your options” & “Exchange Server doesn’t support the requested version”.

Both of these errors are centered around the add-ins feature.

What are add-ins?

First introduced in Exchange 2013, add-ins are apps that you can globally distribute to all your Outlook clients, whether they be the full Outlook client, Outlook Web App, or, Outlook for iOS and Android.

Add-ins include features such as Bing Maps, which will identify an address in an email and automatically load a web-part displaying a map. Or, simply the ability to identify action items within an email.

Exchange ships with a few add-ins out of the box. Additional add-ins can be downloaded through the Microsoft store or uploaded via a custom XML file.

The real beauty of an add-in is that you can centrally manage it via the Exchange Admin Center. Much easier than deploying Outlook add-ins with traditional endpoint management software. Plus it ensures everyone is always using the latest version of an app.

There was a problem loading your options (“add-ins”)

While in coexistence with an older version of Exchange your users may receive the error “There was a problem loading your options”. They receive this error when trying to manage their add-ins via Outlook Web App. This error prevents users from seeing or managing their add-ins.