Thomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.
He is an MVP for Office Apps & Services since 2018.
Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.
He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. These certifications make him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Microsoft 365, and hybrid configurations.
Follow Thomas: LinkedIn, Twitter
His sessions: https://sessionize.com/thomas-stensitzki
MVP Blog: https://blogs.msmvps.com/thomastechtalk Personal blog: http://justcantgetenough.granikos.eu Personal website: http://www.stensitzki.de Thomas' Tech Talk: youtube.com/ThomasStensitzki
Contact Thomas at thomas@mcsmemail.de
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.
See you at TeamsFest 2020!
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.
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.
This problem occurs primarily when using an Enterprise Certificate Authority using certificate templates with individual template settings.
Get-TransportService | ft Name,InternalTransportCertificateThumbprint
certutil -v -store my > cert.txt
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
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.
openssl pkcs12 -in CERT.pfx -out cert.pem -nodes
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.
Get-ExchangeCertificate -Server SERVERNAME
# 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
# 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
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:
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.
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
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.
Enjoy Exchange Server!
The Microsoft 365 Virtual Marathon took place on May 27-28 2020.
The recording of my session "Exchange Hybrid - What, Why, and How" is available on YouTube.
Browse all recordings of the Microsoft 365 Virtual Marathon here: https://www.youtube.com/channel/UCrtmT6Ir1MIs0ZES7sKMmqA
Enjoy!
This is a post summarizing the configuration values for important Exchange-related Active Directory object attributes.
Whenever you need to look up these values for troubleshooting, or editing the values manually.
Note: You should not edit any of the values manually, just because you can. Edit any Exchange-related attributes, if you are familiar with the result of your changes.
Attribute