Just can't get enough of IT

Description

When you want to migrate your modern public folders from Exchange 2013 or newer to modern public folders in Exchange Online, you must prepare the public folder names for migration.

Public folder names are not allowed to contain the following:

• A backslash "\"
• A forward slash "/"
• A semicolon ";"
• A comma ","
• A colon ":"
• Leading or trailing spaces

The script Fix-ModernPublicFolderNames.ps1 fixes the public folder names to prepare migration to modern public folders in Exchange Online.

Examples

# EXAMPLE 1
# Rename and trim public folders

.\Fix-ModernPublicFolderNames.ps1

# EXAMPLE 2
# Rename and trim public folders, export list of renamed 
# folders and folders with renaming errors as text files

.\Fix-ModernPublicFolderNames.ps1 -ExportFolderNames

Version History

• 1.0, Initial community release

Links

• Download and follow at Github: https://github.com/Apoc70/Fix-PublicFolderNames

Follow

• Twitter @stensitzki
• LinkedIn

Community

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. 

I was involved in a troubleshooting request for a hybrid mail flow issue. Before I take a closer look at the issue, let's talk about the hybrid setup.

Hybrid Setup

A managed service provider runs separated on-premises Exchange Organizations for various clients. Also, the service provider runs it's own Exchange Organization in a hybrid setup with Exchange Online (EXO) utilizing centralized mail flow. Let's name the managed service provider Varunagroup, using the primary domain varunagroup.de.

The on-premises IT-Infrastructure consists of the following email components:

• Centralized Third-Party Email Gateway Solution with two nodes
  TLS certificates in use
  • mx01.varunagroup.de
  • mx02.varunagroup.de
     
• Varunagroup on-premises Exchange Organisation
  • Hybrid setup with Exchange Online
  • Hybrid mail flow using Edge Transport Servers
    TLS certificate in use
    • smtpo365.varunagroup.de
  • Centralized mail flow with EXO inbound connector configured by HCW 
  • Tenant name: varunagroup.onmicrosoft.com
  • Internet Send Connector with address space '*' uses the centralized Third-Party gateways as smart hosts
     
•  Multiple separated on-premises Exchange Organization hosted for SPLA-clients
  • Internet Send Connector with address space '*' uses the centralized Third-Party gateways as smart hosts

The following diagram illustrates the setup and the expected mail flow.

Let's name one of the clients Setebos AG, using setebos-ag.com as their primary domain. 

The Issue

Varunagroup's IT department activated journaling in Exchange Online, using an on-premises Journaling mailbox. After a few days, an IT administrator checked the inbox folder for journaling messages and journaling reports. The journaling inbox did not contain messages of Varounagroup senders or recipients only, but messages from client sender domains, e.g., setebos-ag.com.

In reality, the mail flow from on-premises to external recipients from any of the local Exchange organizations looked like shown in this diagram.

Question

Why does the Variangoup journaling mailbox contain messages from Setebos senders sent to external recipients?

We choose a single message for troubleshooting purposes, originating from the Setebos.com domain, sent to a non-Varunagroup recipient.

Analysis

1. The first thing to check is the Exchange Online Message Trace.
   In this case, the administrator already checked the Message Trace using the legacy Exchange Online Admin Center.
   
   The Exchange Online message trace showed the Varunagroup Exchange Online tenant received the Setebos message.

• Row 1: Exchange Online received the message for Varunagroup 
• Rows 2-5: The DLP Journaling rule processed the message, and the journaling report got routed to the journaling mailbox
• Row 6: The message was sent to an external mail server using the Exchange Online DNS resolver
• Row 7: Spam diagnosis for outgoing messages

The interesting piece of information is row 6. 

You see that EXO resolves the target mail exchanger via DNS. The target is another Microsoft 365 tenant as we see an xxx.mail.protection.outlook.com host.
 

2. Why did this message end up in the Varunagroup tenant?

When checking the on-premises mail gateway connection log, we found the distracting information that the gateway resolved the target mail exchanger as xxx.mail.protection.outlook.com.

As a next step, we checked the extended message tracking log using the new Exchange Admin Center. We created a new custom query with the following search criteria:

• Time range: Last 7 days
• Message-Id: The message Id fetched from the outbound connection log 
• Report type: Extended report

When you troubleshoot connection issues with Exchange Online, always select the extended report. You'll receive the report as a CSV file attachment. Use the Data tab in Excel to import the CSV file. Do not access the content by simply clicking the received file attachment. 

The interesting information is stored in the custom_data column for row source=SMTP and event_id=RECEIVE. 

S:ProxyHop1=HE1EUR01FT049.mail.protection.outlook.com(10.152.0.221);
S:ProxyHop2=AM0PRxxCAxxxx.outlook.office365.com(2603:10a6:208:fa::40);
S:InboundConnectorData=Name=Inbound from [EXCHANGE ORG GUID];
ConnectorType=OnPremises;
TenantId=[VARUNAGROUP GUID];
S:InboundTlsDetails=TLS=SP_PROT_TLS1_2_SERVER [...];
S:CorrelationId=d9ac6a10-8de9-4308-4205-07d865e8909b;
S:MimeParts=Att/Emb/MPt:0/0/1;
S:MessageValue=MediumHigh;
S:Replication=AM6PRxxxxMBxxxx;
S:FirstForestHop=AM0PRxxxxMBxxxx.eurprd03.prod.outlook.com;
S:FromEntity=HybridOnPrem;
S:Oorg=varunagroup.de;
S:ProxiedClientIPAddress=81.173.212.44;
S:ProxiedClientHostname=mx01.varunagroup.de;
S:DeliveryPriority=Normal;
S:AccountForest=EURPRxxAxxx.PROD.OUTLOOK.COM

The information in line 3 shows the actual name of the configured Varunagroup inbound connector, as shown in the Exchange Online connector configuration. The message did not enter the Varunagroup EXO tenant due to a mysterious connection, it was received by the dedicated inbound connector, configured by HCW.

3. Why was the Hybrid Inbound Connector chosen?

The key to this question is the TLS certificate used by the centralized email gateway and the TLS common name filtering in Exchange Online.

• The email gateways use the following TLS certificate with the two following common names
  • mx01.varunagroup,de
  • mx02.varunagroup.de
    ​
• The hybrid inbound connector used the TLS common name filtering, controlled by the TlsSenderCertificateName attribute, with the following name
  • *.varunagroup.de

The wildcard name *.varunagroup.de resulted in a matching string comparison for the incoming TLS common names of mx01.varunagroup.de and mx02.varunagroup.de. At the same time, the inbound connector matched the Edge Transport TLS certificate smtpo365.varunagroup.de.

Nobody knew, how the inbound connector configuration got "changed" to the wildcard name or for how long that configuration resulted in outbound messages from customer domains routed via the service provider tenant.

Solution

The solution contains two configurations.

1. Ensuring that the FQDN attribute of the Edge Send Connector is set to smtpo365.varunagroup.de
   
   This ensures that Exchange Server Transport selects the installed and SMTP-enabled TLS certificate for that name.  
    
2. ​Changing the TlsSenderCertificateName to smtpo365.veruangroup.de 
   
   This ensures that Exchange Online selects the hybrid inbound connector for Edge Transport established connections only.
    

The TLS common name behavior is by design and described in this blog post as FAQ #6(b). As a customer, you identify this as a misbehaving SMTP receive connector. But as described in the blog post, this is by design.

It is required that you understand the inbound routing behavior of Exchange Online if you have complicated outbound routing requirements. The blog post provides detailed information on how Office 365 inbound routing works and what you should be aware of.
 

Links

• Office 365 Attribution
• Hybrid Deployment Requirements
• Hybrid Configuration Wizard

Enjoy Exchange Online.

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. 

I am honored to speak at TeamsFest 2020. 

TeamsFest 2020 is a TeamsFest is a 100% free, 100% community-driven conference dedicated to Microsoft Teams. It aims to bring together exceptional technical talent and thought leaders to democratize knowledge about Microsoft Teams, encourage participation in the Microsoft Teams community, and give those who are struggling financially an opportunity to attend a first-class Teams conference.

My session will cover the requirements for implementing an Exchange Hybrid configuration with Exchange Online when utilizing on-premises mailboxes with Microsoft Teams.

Date

• 7th October
• 08:00h - 18:30h (CEST)

Links

• TeamsFest 2020 Registration
• TeamsFest Overview and agenda

See you at TeamsFest 2020!

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. 

Exchange Server uses Receive Connectors for providing SMTP endpoints for incoming connections. A modern Exchange Server provides a default connector on TCP port 25. 

Sometimes you might have a requirement to create a new receive connector for selected incoming SMTP connections. A standard requirement is a receive connector for relaying messages to external recipients. This cannot (should not) be achieved using the default connector.

Each connector uses the RemoteIPRanges attribute to store the list of IP addresses of remote systems that can connect to that connector. The default connector utilizes the full IPv4 and IPv6 addresses ranges.

Your new receive connector requires at least a single IP address for a selected remote system that is supposed to connect to that receive connector. You can add a single IP address, address ranges, or IP addresses using CIDR notation.

The attribute RemoteIPRanges is a multi-value attribute and has a limit of IP address entries that can be added. 

The maximum number of address entries that you can add to that attribute varies. You can store approximately 1,300 entries.

When you exceed the number of values you receive the following error message:

The administrative limit for this request was exceeded.
    + CategoryInfo          : NotSpecified: (:) [Set-ReceiveConnector], AdminLimitExceededException
    + FullyQualifiedErrorId : [Server=EX01,RequestId=ee9d45ad-418b-4172-9235-963eca1a7830,TimeStamp=18.08.2020
    20:07:54] [FailureCategory=Cmdlet-AdminLimitExceededException] AC1E336E,Microsoft.Exchange.Management.SystemConfi
  gurationTasks.SetReceiveConnector
    + PSComputerName        : ex01.varunagroup.de

I have tested the number of values that can be stored in that multi-value attribute. Depending on the IP address format I was able to add 1,238 (172.80.x.y) or 1,244 (10.1.x.y) single IP addresses to the RemoteIPRanges attribute.

Plan your IP address configuration requirements carefully and avoid using single IP addresses. Preferably, you should use IP address ranges or IP address CIDR notation for networks.

Links

• Set-ReceiveConnector

Enjoy Exchange Server!

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.