Just can't get enough of IT

Problem

The use of Exchange Edge Transport Servers requires the synchronization of user and configuration data from internal Exchange Servers to the Edge Transport Servers. The synchronization utilizes secure LDAP (EdgeSync) to transmit the data securely and is based on an Edge Subscription.

When you create a new Edge Subscription on your internal Exchange Servers by importing the Edge Subscription XML-file, establishing the EdgeSync-connection might fail.

You will find the following error in the application event log of the internal Exchange Server:

Log Name:      Application
Source:        MSExchange EdgeSync
Event ID:      1035
Task Category: Synchronization
Level:         Error
Keywords:      Classic
Description:
EdgeSync failed to synchronize because it only supports Cryptographic API certificates. 
The local Hub Transport server's default certificate with thumbprint XYZ isn't a 
CAPI certificate. To set a CAPI certificate as the default certificate, use the 
Enable-ExchangeCertificate cmdlet with the Services parameter using the value of SMTP.

Reason

The private key of the current Exchange Transport default certificate of the internal Exchange servers uses a CNG private key. EdgeSync requires a CAPI1 based private key.

• CNG = Cryptography Next Generation
• CAPI1 = Cryptographic API (already deprecated)

This problem occurs primarily when using an Enterprise Certificate Authority using certificate templates with individual template settings. 

How do you determine, if the type of the default transport certificate is a CNG or CAPI1 certificate?

• Log on to the internal Exchange Server where you imported the Edge Subscription file and start a new Exchange Management Shell session
• Query the Transport Service to identify the default certificate thumbprint

Get-TransportService | ft Name,InternalTransportCertificateThumbprint

• Open an administrative command prompt
• Export the certificates information from the certificate store to a text file

certutil -v -store my > cert.txt

• Open the text file using an editor tool of your choice
• Search for the certificate thumbprint identified in step 2
  This thumbprint is the SHA1 certificate hash
• Scroll down to the provider section to find the following two attributes
  • ProviderType
  • KeySpec

If both attribute are of the value 0, the certificate if a CNG certificate.

The section might look like this:

Unique container name: XYZ
    Provider = Microsoft Software Key Storage Provider
    ProviderType = 0
  Flags = 20 (32)
    CRYPT_MACHINE_KEYSET -- 20 (32)
    KeySpec = 0 -- XCN_AT_NONE

Solution

Use OpenSSL to convert the CNG certificate to a CAPI1 certificate.

Using OpenSSL requires the download of the Windows release of OpenSSL. I recommend to not install the software on the Exchange Server but a separate Windows server or your administrative desktop system. Additionally, you need the certificate with its private key as a PFX-file.

Use the following steps to convert the CNG certificate to a CAPI1 certificate.

• Download and install OpenSSL
• Open the OpenSSL Command Prompt
• Navigate to the folder containing the PFX-file
• Convert the PFX-file to a PEM-file
  The tool will query to enter the PFX password

openssl pkcs12 -in CERT.pfx -out cert.pem -nodes

• Convert the PEM-file to a new PFX-file
  The tool will query you to set a PFX password

openssl pkcs12 -export -in cert.pem -out NEWCERT.pfx

The new PFX-file is now a CAPI1 certificate. The new certificate has the same thumbprint. Now you must replace the current certificate used by Exchange Server with the new certificate. 

Replacing the certificate requires a downtime of each Exchange Server requiring the certificate replacement. This is due to the requirement to remove the CNG certificate first, following the import of the CAPI1 certificate. Afterward, you need to enable the required Exchange services.

• Log on to the internal Exchange Server where you imported the Edge Subscription file and start a new Exchange Management Shell session
• Query local Exchange Server certificates and identify the thumbprint of the default Exchange Server self-signed certificate 
  The certificate common name (CN) equals the server name

Get-ExchangeCertificate -Server SERVERNAME

• Change the Exchange Transport default certificate to the self-signed certificate before deleting the CNG certificate

# It is mandatory to answer the query for replacing the default certificate with YES
Enable-ExchangeCertificate -Thumbprint THUMBPRINT -Services SMTP

# Restart the transport service
Restart-Service MSExchangeTransport

• Remove the CNG certificate
  • Use either the certificate store MMC, Exchange Management Shell, or Exchange Admin Center
• Import the CAPI1 certificate
  • Use either the certificate store MMC, Exchange Management Shell, or Exchange Admin Center
• Enable the imported certificate and replace the default transport certificate

# It is mandatory to answer the query for replacing the default certificate with YES
Enable-ExchangeCertificate -Thumbprint NEWCERTTHUMBPRINT -Services SMTP

# Restart the transport service
Restart-Service MSExchangeTransport

• Repeat the certificate replace for each Exchange Server in the same Active Directory site

Now, that you updated the local Exchange Servers there is one more step that needs to be checked on the Edge Transport Servers.

Edge Transport Servers are not domain-joined and therefore do not receive any GPO-based configuration. Each required configuration must be performed locally. To ensure that the default transport certificate of the internal Exchange servers can be used for cryptographic operations we must ensure that the certificate chain of that certificate is present in the certificate store of Edge Transport servers.

Take a look at the certificate chain of the converted CAPI1 certificate and import the Root-CA and Subordinate-CA certificates into the Edge Transport servers local certificate store. You must ensure that the certificates are placed into appropriate stores:

• Root-CA certificate goes into Trusted Root Certification Authorities \ Certificates
• Subordinate-CA certificate goes into Intermediate Certification Authorities \ Certificates

Next, you create a new Edge Subscription on your Edge Transport server and create a new subscription for the Active Directory site on the internal Exchange Server. The internal Exchange Servers are now able to establish an EdgeSync connection and encrypting the data transferred to the Edge Transport servers.

Note

When you receive the TLS certificate as PFX/PKCS12 file, you import the certificate and the private key. The import process itself defines the priavte key Crypto Provider. Using the following command line you ensure that the import process suses the legacy crypto provider.

certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx my MYCERTpfx

Links

• Exchange Edge Transport Server Role
• Edge Subscriptions
• Cryptography API: Next Generation
• Cryptographic Service Providers
• OpenSSL for Windows

Enjoy Exchange Server and Edge Transport!

Are you located in Germany, Austria, or Switzerland? Join the Exchange User Group DACH to collaborate with other Exchange enthusiasts.
Follow us on Twitter @exusg, join on Meetup, or visit our website. 

Problem

You are not able to list public folders in a co-existence scenario with Exchange Server 2007 and Exchange Server 2010/2013 using the Exchange 2007 EMS or EMC.

When you try to execute Get-PublicFolder you receive the following error:

Get-PublicFolder " There is no existing PublicFolder that matches the following Identity: '\'. Please make sure that you specified the correct PublicFolder Identity and that you have the necessary permissions to view PublicFolder.

This might happen after you have removed the first Exchange 2007 mailbox server, but not the last Exchange 2007 mailbox server.

Exchange Server 2007 uses the Exchange System Attendant to access the public folder store and fails if the System Attendant discovery in Active Directory does not provide a proper configuration.

KB 2621350 describes the discovery process:

1. Exchange Server 2007 selects a mailbox database.
2. Exchange Server 2007 obtains the LegacyExchangeDN attribute of the selected mailbox database. For example, Exchange Server 2007 obtains the following LegacyExchangeDN attribute value:
   /o=First Organization/ou=Exchange Administrative Group (group_name)/cn=Configuration/cn=Servers/cn=E14HUBCAS/cn=Microsoft Private MDB
3. Exchange Server 2007 removes the "CN=Mailbox Database" part of the address. The address then resembles the following:
   /o=First Organization/ou=Exchange Administrative Group (group_name)/cn=Configuration/cn=Servers/cn=E14HUBCAS
4. Exchange Server 2007 adds "CN=Microsoft System Attendant" to the LegacyExchangeDN value. After the value is appended, the LegacyExchangeDN attribute value resembles the following:
   /o=First Organization/ou=Exchange Administrative Group (group_name)/cn=Configuration/cn=Servers/cn=E14HUBCAS/CN=Microsoft System Attendant
5. Exchange Server 2007 tries to log on to the public store by using the value in step 4.
6. The store then tries to locate the System Attendant object.

There two annoying things about these steps

1. Step 1:  Exchange Server 2007 selects a mailbox database
   
   There is no description available on how the database is being selected. But the co-existence scenario results in a mailbox database being selected that might be located on Exchange Server 2010 or Exchange Server 2013. Even though there still are Exchange Server 2007 mailbox database available. You still require to have a mailbox database hosted on an Exchange 2007 public folder server, due to the legacy public folder requirements with Exchange Server 2013.
    
2. Steps 2-4: The LegacyExchangeDN example shows an E14HUBCAS name as a placeholder. In a situation where you have deployed dedicated mailbox servers, this should read E14MBX.
    

Solution

The magic System Attendant mailbox has been removed from Exchange 2010. But the System Attendent configuration node does still exist in the Active Directory Configuration Partition for compatibility reasons. The configured attributes of the System Attendant entry vary depending on the version of the installed Exchange Server.

In regards to the public folder issue, we need to focus on the following:

• Exchange Server 2010 System Attendant
  • homeMDB: <not set>
  • homeMTA: <not set>
• Exchange Server 2013 System Attendant
  • homeMDB: <not set>
  • homeMTA: CN=Microsoft MTA,CN=E15MBX,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]

To fix the public folder access issue for Exchange Server 2007, set the homeMDB and homeMTA attributes. Set the Exchange System Attendant attributes to appropriate values for your Exchange servers.

Exchange Server 2013

1. Open ADSIEdit and connect to the Configuration context
2. Open Databases node
   CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
3. Open the Properties of an Exchange 2013 database
4. View the distinguishedName property and copy the value to clipboard
   Example: CN=E15MBXDB01,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
5. Close the Properties window and open the Servers node
   CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
6. Expand the first Exchange 2013 server and open the Properties of the Microsoft System Attendant node
   Ensure that the view is not filtered to Show only attributes that have values
7. Edit the homeMDB attribute and paste the distinguished name of the mailbox database copied in step 4
8. Apply the changes and close the properties window

Repeat steps 4 to 8 for each Exchange 2013 server in your environment.

Exchange Server 2010

1. Open ADSIEdit and connect to the Configuration context
2. Open Databases node
   CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
3. Open the Properties of an Exchange 2010 database
4. View the distinguishedName property and copy the value to the clipboard
   Example: CN=E14MBXDB01,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
5. Close the Properties window and open the Servers node
   CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
6. Expand the first Exchange 2010 server and open the Properties of the Microsoft System Attendant node
   Ensure that the view is not filtered to Show only attributes that have values
7. Edit the homeMDB attribute and paste the distinguished name of the mailbox database copied in step 4
8. Apply the changes and close the properties window
9. Open the Properties windows of the Microsoft MTA of the same Exchange
10. View the distinguishedName property and copy the value to the clipboard
    Example: CN=Microsoft MTA,CN=E14MBXSRV01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=[ORG],CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=[DOMAIN],DC=[TLD]
11. Open the properties of the Microsoft System Attendant node for a second modification
    Ensure that the view is not filtered to Show only attributes that have values
12. Edit the homeMTA attribute and paste the distinguished name of the mailbox database copied in step 10
13. Apply the changes and close the properties window

Repeat steps 4 to 13 for each Exchange 2010 server in your environment.

Wait for Active Directory replication and retry to access the public folders using Get-PublicFolder in an Exchange Server 2007 Management Shell.

It might be required to restart the Exchange 2007 Information Store and System Attendant service of the Exchange 2007 server in question

Use an administrative PowerShell

Restart-Service MSExchangeIS 
Restart-Service MSExchangeSA 

I haven’t noticed any issues in production environments so far. If you encounter any issues in your environment, feel free to leave a comment.

Links

• You cannot view a list of public folders in an Exchange organization that has Exchange Server 2007 and Exchange Server 2010 mailbox databases,
• On-Premises Legacy Public Folder Coexistence for Exchange 2013 Cumulative Update 7 and Beyond,
• Breaking Change : The System Attendant mailbox has been removed from Exchange 2010
• Exchange 2007 and 2013 environment – Public Folders on 2007 “Get-PublicFolder” cmdlet fails

Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?

Contact me at thomas@mcsmemail.de
Follow at https://twitter.com/stensitzki

The JET Blue Story

The Exchange Server product used the Extensible Storage Engine (ESE, aka JET Blue) to store data for decades. The story of the JET Blue (in contrast to JET Red which is used for Access database) can be read here (https://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine). In the acient days of data storage the ESE database was the best choice for storing mostly unstructured data with many dynamic properties.

The Messaging API (MAPI) had been developed in the 1990s to provide programmers with a set of unified interface for easier message exchange. The MAPI documentation at TechNet has been replaced by the current Outlook 2013 MAPI Reference. In todays world it is not easy to find reliable ressource about the original MAPI implementation. The only printed resource is Inside Mapi (Microsoft Programming Series) , ISBN 978-1572313125 , which has been published in 1996.

At Ignite 2015 Ross Smith VI joked about moving the Exchange storage engine to SQL. Back in the day with Exchange 2013 in production and Exchange 2016 coming, this was true. But Ross laid the tracks for the evolution of Exchange.

But it seems that the Exchange Product Team realized that in today's world with heavily standardized communication and less dynamic requirements than in the 1990s the days of JET blue are over. At the same time SQL Server evolved to mature database solution, capable of handling big data. The question was, if it can store SharePoint data, why not Exchange data. After twenty years of Exchange Server using the good ole ESE engine it was time to move on.

The SQL scripts that are used by Exchange to configure SQL are loacted in $exbin\SQL

Example

CREATE TABLE [dbo].[MAPI_PROPERTIES](
	[MAPI_PROPERTTY_ID] [int] IDENTITY(1,1) NOT NULL,
	[MAPI_PROPERTY_NAME] [nchar](127) NOT NULL,
	[IsWellKnownProperty] [bit] NOT NULL,
	[MAPI_TYPE_ID] [int] NOT NULL,
 CONSTRAINT [PK_MAPI_PROPERTIES] PRIMARY KEY CLUSTERED 
(
	[MAPI_PROPERTTY_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[MAPI_PROPERTIES]  WITH CHECK ADD  CONSTRAINT [FK_MAPI_PROPERTIES_MAPI_TYPES] FOREIGN KEY([MAPI_TYPE_ID])
REFERENCES [dbo].[MAPI_TYPES] ([MAPI_TYPE_ID])
GO

ALTER TABLE [dbo].[MAPI_PROPERTIES] CHECK CONSTRAINT [FK_MAPI_PROPERTIES_MAPI_TYPES]
GO

Exchange Server goes SQL

The current Exchange 2016 CU2 Preview supports an undocumented registry key to activate SQL Server support for Exchange. Personally I do not know, if this was supposed to be officially included in a public realease. So maybe the SQL support was made available by error and is already removed from the most current build again.

The famous SqueakyLobster registry key in has been used in Exchange 5.5 to troubleshoot performance issues. The new "Lobster" key is used to activate hidden code in Exchange Server product. The name of the key is LobsterMapiDB.

This key activates support for Exchange modern storage. Without this key you won't be able to move mailboxes from ESE legacy storage to SQL modern storage.

It is assumed that a SQL Server 2014 instance is available. A SQL Server 2014 Express edition is sufficient for testing purposes.

Note:
Any changes to configurations or the registry should be validated in a test environment first. Never try this in production right away.

The high level steps required to activate SQL support for Exchange 2016 are:

• Create a configuration file to provide the SQL connection string
• Create a SQL server login for the Exchange Trusted Subsystem security group
• Add a registry key to the local Exchange Server registry
• Restart Information Store Service (MSExchangeIS)
• Execute PowerShell script to migrate mailboxes to SQL

The detailed steps are:

• Create a new config file named Microsoft.Exchange.Data.SQL.exe.config in $exinstall/bin

		<?xml version="1.0" encoding="utf-8" ?>
		<!-- Exchange SQL Configuration - preliminary support -->
		<!-- %MAILBOXDATABASENAME% will be replaced by Exchange -->
		<!-- More information https://goo.gl/QiTtDo -->
		<configuration>
			<sectionGroup name="SqlMapiProviderGroup" type="Microsoft.Exchange.Data.SQL.SqlMapiProviderGroup, Microsoft.Exchange.Data.Common, Version=15.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
				<section name="SqlMapiProviderSection" type="Microsoft.Exchange.Data.SQL.SqlMapiProviderGroup, Microsoft.Exchange.Data.Common, Version=15.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
		    </sectionGroup>
			<runtime>
				<gcServer enabled="True" />
				<generatePublisherEvidence="False" />
			</runtime>
			<appSettings>
				<add key="MigrateMailboxesAutomatically" value="false" /> <!-- Not yet supported -->
				<add key="AllowJETBlueCoexistence" value="true" /> <!-- Allows for SQL/ESE Coexistence in DAG -->
				<add key="PerDatabaseMaxSize" value="1GB" />
				<add key="VerboseLoggingEnabled" value="False" />
		
			</appSettings>
			<SqlMapiProviderSection>
				<SqlMapiProvider>
					<add name="LobsterMapiDB"
					providerName="System.Data.SqlClient"
					connectionString="Data Source=SERVERNAME\INSTANCE;Initial Catalog=%MAILBOXDATABASENAME%;Integrated Security=True;MultipleActiveResultSets=True" />
				</SqlMapiProvider>
			</SqlMapiProviderSection>
		</configuration>

• Create a SQL login for Exchange Trusted Subsystem

CREATE LOGIN [DOMAIN\Exchange Trusted Subsystem] FROM WINDOWS

• Create a new DWORD named LobsterMapiDB in
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15
  and set the data value to 1
  
  
• Restart Exchange Information Store
  
  Restart-Service MSExchangeIS
   
• Use Move-MailboxToModernStorage.ps1 script to move selected mailboxes to modern storage

More can be found here:

• Migration scripts and config files are available at Github, https://github.com/Apoc70/LobsterMapiDB

Links

• From crush to product documentation: The story of Squeaky Lobster, http://blogs.technet.com/b/exchange/archive/2006/06/15/3394229.aspx
• Setting "Squeaky Lobster" performance counter settings, https://support.microsoft.com/en-us/kb/556030
• Extensible Storage Engine, https://en.wikipedia.org/wiki/Extensible_Storage_Engine
• Outlook 2013 MAPI Reference, https://msdn.microsoft.com/en-us/library/cc765775.aspx
• SQL Server 2014, https://www.microsoft.com/en/server-cloud/products/sql-server/
• Final information: https://goo.gl/QiTtDo

Enjoy Exchange for the next 20 years...

Exchange Server 2016 introduced the PowerShell cmdlet Get-MailboxServerRedundancy. This cmdlet helps you plan and prepare for Exchange Server maintenance by querying the current maintenance readiness of the database availability group (DAG). 

Interestingly, there is no PowerShell help available for this vital cmdlet. Microsoft Docs or Exchange Management Shell's Get-Help provide any valuable information.

When querying a DAG about the server redundancy status, the cmdlet's default output provides you with the essential information.

The default output contains information about:

• Identity
  Name of the DAG member server
   
• IsServerFoundInAD
  Indicates if the corresponding server computer object exists Active Directory
   
• IsInMaintenance
  Indicates if the server is currently in maintenance mode
   
• RepairUrgency
  Indicates an aggregated state of the mailbox database and search index repair modes 
   
• SafeForMaintenance
  Indicates if you can safely activate the maintenance mode for this server
   
• HealthInfoLastUpdateTime
  Timestamp when the server's health state was last updated
   

Example - Prior Maintenance

This example shows the Get-MailboxServerRedundancy output of a six server DAG, before activating maintenance mode for server LOCEXS06.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 09:10:11
LOCEXS02        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS03        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS06        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS05        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS04        True          False       Prohibited    False              17.02.2020 09:10:11

As Exchange Administrator, you are most interested in the information displayed in columns RepairUrgency and SafeForMaintenance.

As you can see in this screenshot, no server is in maintenance mode. Servers S01 and S04 have a RepairUrgency state of Prohibited, and a SafeForMaintenance state of False. The latter tells us that we cannot activate maintenance mode for servers safely without risking mailbox database redundancy. 

What is the reason for this? Let's have a look.

Server Information

You can use the same cmdlet to query detailed information for each member server of the DAG. The default output for a single server does not provide any additional information on the server status. 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 09:11:11

Because we cannot activate maintenance mode for server LOCEXS01 safely, we are interested in identifying which redundancy state is responsible.

You can find this information by displaying the detailed server information.

Detailed Server Information

Use the Format-List, or short FL, cmdlet to display the Get-MailboxServerRedundancy cmdlet output as a formatted list.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 | FL

RunspaceId                                  : 70d82f8d-e6ca-4bfc-863f-11300a9784ff
Identity                                    : LOCEXS01
IsServerFoundInAD                           : True
IsInMaintenance                             : False
RepairUrgency                               : Prohibited
SafeForMaintenance                          : False
ServerContactedFqdn                         : LOCEXS04.VARUNAGROUP.DE
HealthInfoCreateTime                        : 15.06.2018 15:16:19
HealthInfoLastUpdateTime                    : 17.02.2020 09:11:11
ServerFoundInAD                             : CurrentState: Active; LastActiveTransition: 15.06.2018 15:22:16;
                                              LastInactiveTransition:
InMaintenance                               : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02;
                                              LastInactiveTransition: 17.01.2020 10:42:02
AutoActivationPolicyBlocked                 : CurrentState: Inactive; LastActiveTransition: 09.01.2020 10:14:50;
                                              LastInactiveTransition: 09.01.2020 11:00:51
ActivationDisabledAndMoveNow                : CurrentState: Inactive; LastActiveTransition: ; LastInactiveTransition:
                                              15.06.2018 15:22:16
HighAvailabilityComponentStateOffline       : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02;
                                              LastInactiveTransition: 17.01.2020 10:42:02
CriticalForMaintainingAvailability          : CurrentState: Inactive; LastActiveTransition: 31.01.2020 16:52:49;
                                              LastInactiveTransition: 31.01.2020 16:56:49
CriticalForMaintainingRedundancy            : CurrentState: Active; LastActiveTransition: 29.01.2020 11:43:06;
                                              LastInactiveTransition: 29.01.2020 11:42:06
PotentiallyCriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 01.02.2020 05:49:37;
                                              LastInactiveTransition:
CriticalForRestoringAvailability            : CurrentState: Inactive; LastActiveTransition: 06.05.2019 09:16:36;
                                              LastInactiveTransition: 06.05.2019 09:20:36
CriticalForRestoringRedundancy              : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06;
                                              LastInactiveTransition: 29.01.2020 11:43:06
HighForRestoringAvailability                : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06;
                                              LastInactiveTransition: 29.01.2020 11:43:06
HighForRestoringRedundancy                  : CurrentState: Inactive; LastActiveTransition: 10.02.2020 09:05:02;
                                              LastInactiveTransition: 10.02.2020 09:06:02
IsSafeForMaintenance                        : CurrentState: Inactive; LastActiveTransition: 03.11.2019 09:42:35;
                                              LastInactiveTransition: 12.11.2019 06:29:58
IsValid                                     : True
ObjectState                                 : Unchanged

The lines 24-27 show the information we want to know. Both, the CriticalForMaintainingRedundancy and PotentiallyCriticalForMaintainingRedundancy parameters have a CurrentState value of Active. The Primary Activation Manager (PAM) considers the server availability critical to provide redundant availability of the database copies hosted by this server. 

Each of state-parameter shows three pieces of information:

• CurrentState
  The current state, either Active  or Inactive
   
• LastActiveTransition
  The timestamp of the last state change to Active
   
• LastInactiveTransition
  The timestamp of the last state change to Inactive

But there is still the bothering question of why are two of the six servers not safe for activating maintenance?

The reason is simple. The mailbox databases mounted by the member servers of the DAG have a different number of database copies. This configuration is due to data storage capacity constraints.

The mailbox databases storing primary user mailboxes use four database copies per database. Those copies are evenly distributed across all six mailbox servers. Mailbox database storing online archive mailboxes use three copies per database. This database copy layout allows for safely activating server maintenance for one server at a time without risk to database redundancy.

The servers LOCEXS01 and LOCEXS04 hold mailbox databases with just two copies per configured database. Placing one of those two servers into maintenance mode reduces the database availability for these mailbox databases to one. Therefore, PAM informs us that database redundancy is at risk when activating maintenance for those two servers. 

Example - During Maintenance

This example shows the member server redundancy state while LOCEXS06 is in maintenance. The reason for monthly maintenance for installing Windows updates.

Maintenance was activated using the StartDagServerMaintenance.ps1 PowerShell script.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS02        True          False       Normal        True               17.02.2020 11:04:12
LOCEXS03        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS06        True          True        High          True               17.02.2020 11:04:12
LOCEXS05        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS04        True          False       Prohibited    False              17.02.2020 11:04:12

Having a single server in maintenance has a significant impact on all other servers in the DAG. The servers LOCEXS03 and LOCEXS05 are not safe for maintenance as well. Activating maintenance for those two servers would affect the database redundancy for the databases hosted by those two servers.

Example - After Maintenance

After completing all maintenance tasks, e.g., installing Windows Updates or a new Exchange Server Cumulative Update, you end server maintenance using the PowerShell script StopDagServerMaintenance.ps1.

We query the server redundancy state again. 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 11:23:12
LOCEXS02        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS03        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS06        True          False       High          True               17.02.2020 11:23:12
LOCEXS05        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS04        True          False       Prohibited    False              17.02.2020 11:23:12

Server LOCEXS06 is not in maintenance, but the RepairUrgency state is High. The local Exchange Server replication engine is still busy replicating and processing log files, and updating the search indices. When CopyQueueLength and ReplayQueueLength are back to 0, and ContentIndexStates are back to Healthy, the RepairUrgency switches to Normal.

Tip

• You receive an error message when activating maintenance for an Exchange Server not safe for maintenance using
  ​StartDagServerMaintenance.ps1 -serverName [SERVER]
  
  In this case, you must use:

.\StartDagServerMaintenance.ps1 -serverName SERVERNAME -overrideMinimumTwoCopies:$true

Enjoy Exchange Server!

Description

This script copies a single receive connector from a source Exchange Server to a single target Exchange server or all other Exchange servers.

The primary purposes of this script are:

• Simplify migration of legacy Exchange receive connectors (Exchange 2007 or Exchange2010) to a modern Exchange server (Exchange 2013 or Exchange 2016)
• Simplify receive connector distribution across multiple Exchange servers (Exchange 2013, Exchange 2016, or Exchange 2019)

Find the most recent full documentation at GitHub.

Examples

Copy Exchange 2013/2016 receive connector RC2 from server MBX01 to server MBX2

.\Copy-ReceiveConnector.ps1 -SourceServer MBX01 -ConnectorName RC2 `
-TargetServer MBX2 -DomainController MYDC1.mcsmemail.de

Copy Exchange 2013/2016 receive connector RC2 from server MBX01 to all other Exchange 2013 servers

.\Copy-ReceiveConnector.ps1 -SourceServer MBX01 -ConnectorName RC1 `
-CopyToAllOther -DomainController MYDC1.mcsmemail.de

Copy Exchange 2013/2016 receive connector relay from Exchange 2007 server MBX2007 to Exchange 2013 server MBX01 and reset network bindings

.\Copy-ReceiveConnector.ps1 -SourceServer MBX2007 -ConnectorName "relay" `
-TargetServer MBX01 -MoveToFrontend -ResetBindings `
-DomainController MYDC1.mcsmemail.de

Version History

• 1.0, Initial community release
• 1.1 Domain Controller parameter added, permissions group copy added
• 1.2 Move to FrontendTransport added, optional permission copy added, reset bindings added
• 1.3 Update receive connector, if receive connector exists
• 1.4 Fix to handle connector updates properly
• 1.41 Minor fixes and update for Exchange 2016
• 1.5 Issue #2 fixed
• 1.6 Issue #3 fixed
• 1.7 Issue #6 fixed, new parameter UpdateExistingConnector added, tested with Exchange Server 2019

Links

• Download, and follow at Github: https://github.com/Apoc70/Copy-ReceiveConnector
• Download, and like at TechNet Gallery: https://gallery.technet.microsoft.com/Copy-a-receive-connector-b20b9bef

Additional Credits

Additional credits go to Jeffery Land, https://jefferyland.wordpress.com

Follow

• Twitter @stensitzki
• LinkedIn
• Thomas' Tech Talk

Problem

You might encounter EventId 106 errors on Exchange 2013/2016 servers.

There are some article available on how to fix this issue on servers having a full installationof Exchange Server 2013/2016.

But you might encounter this error on servers having the Exchange 2013/2016 Management Tools installed only as well. In this case the solutions described will not work as expected.

Running the New-PerfCounters cmdlet requires the Microsoft.Exchange.Management.PowerShell.Setup PowerShell snapin. This PowerShell snapin cannot be loaded on servers having the Exchange Management Tools installed.

Add-PsSnapin : The Windows PowerShell snap-in 'Microsoft.Exchange.Management.PowerShell.Setup' is not installed on
this computer.
At line:1 char:1
+ Add-PsSnapin Microsoft.Exchange.Management.PowerShell.Setup
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (Microsoft.Excha...owerShell.Setup:String) [Add-PSSnapin], PSArgumentEx
   ception
    + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand

Solution

The required code library is available on servers having the Exchange Management Tools installed. But the library is not added to the registry by default.

Registry of a server running Exchange Management Tools only:

Registry of a fully installed Exchange Server:

Just export the registry key Microsoft.Exchange.Management.PowerShell.Setup from an Exchange Server, fix Exchange file paths (if required) and import the regiytry file on the server having the Exchange Management Tools installed.

Example registry file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.Exchange.Management.PowerShell.Setup]
"CustomPSSnapInType"="Microsoft.Exchange.Management.PowerShell.SetupPSSnapIn"
"ApplicationBase"="D:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin"
"AssemblyName"="Microsoft.Exchange.PowerShell.Configuration, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"Description"="Setup Tasks for the Exchange Server"
"ModuleName"="D:\\Program Files\\Microsoft\\Exchange Server\\V15\\bin\\Microsoft.Exchange.PowerShell.configuration.dll"
"PowerShellVersion"="1.0"
"Vendor"="Microsoft"
"Version"="15.0.0.0"

After adding the registry key, you can successfully fix the performance counter issue.

Add-PsSnapin Microsoft.Exchange.Management.PowerShell.Setup 

New-PerfCounters -DefinitionFileName "$exinstall\setup\perf\WorkerTaskFrameworkPerfCounters.xml”

Links

• Jetze Mellema Post: Fix those silly "106" Performance Counter events on Exchange 2013 servers