SuperTekBoy

This week was a big week for Exchange. Microsoft released its second cumulative update for Exchange 2019 as well as cumulative updates for Exchange 2016 and 2013.

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 2019 Cumulative Update 2 (VLSC)| KB4488401

Exchange 2016 Cumulative Update 13 | KB4488406 | UM Language Pack

Exchange 2013 Cumulative Update 23 | KB4489622 | UM Language Pack

Exchange 2010 SP3 Rollup 27 | KB4491413

The final countdown – 208 days left for Exchange 2010

Here is a quick reminder that extended support for Exchange 2010 is coming to an end. After January 14th, 2020, no further technical support or updates will be available. This includes security, bug and time zone updates.

Unfortunately, there is no direct path to Exchange 2019 from 2010. If you do plan to stay on-prem you will need to migrate to either 2013 or 2016 (I’d recommend 2016 as 2013 is now in extended support). From there you can migrate to 2019. Alternatively, you can migrate to Office 365.

For more information about the Exchange 2010 life-cycle check out the Exchange Team blog.

So, what’s new in these Cumulative Updates?

In the last set of cumulative updates, Microsoft reduced the number of permissions Exchange had in Active Directory. In an ongoing effort to further tighten the security posture of Exchange, Microsoft has further reduced Exchange’s permissions in Active Directory.

This includes two notable changes. The first is that Exchange can no longer assign service principal names (SPN). Second, a deny attribute has been added to the DNS Admins group. The Exchange Team determined neither of these rights was necessary for the operation of Exchange.

In the previous Exchange 2019 cumulative update, you could disable legacy protocols on a per-user basis. In cumulative update 2, you can now globally disable legacy authentication at the organization level.

This series of updates also introduces support for .NET Framework 4.8. While optional now, 4.8 will be mandatory as part of the December 2019 updates.

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 removing members to a DAG? What did you do to fix it? Drop a comment below or join the conversation on Twitter