MVP - Most Valuable Professional
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft technologies like Exchange Server, Microsoft 365, Microsoft Teams, and Cloud Security.

These are the results of the  Exchange Server Questionnaire from August 2021.

First of all, I want to thank all of you who participated in the questionnaire. The results are pretty interesting. Even though, that the results are not 100% representative they provide a high-level view of the Exchange Organizations, the mail flow configurations, and the future plans regarding hybrid and Exchange Online.

With 55 replies the questionnaire is far from being a comprehensive representation of the Exchange organizations. But the answers provide an idea of the Exchange landscape used by organizations globally.

  

1. Exchange Server Versions in use (Production)

Exchange Server 2016 is the dominant version currently in use, followed by Exchange Server 2019. The vast majority of 93% runs modern Exchange Server versions. But there are still older and unsupported Exchange Server versions in use. 7% use Exchange Server 2010 and older. 

 

Diagram Exchange Server Versions in use (Production)

 

2. How many Exchange Server systems do you operate?

76% of the organizations maintain up to ten Exchange servers. 20% prefer to rely on just one Exchange server. It is interesting that only 2 (not percent) plan to go hybrid or to move to Exchange Online.  

 

Diagram How many Exchange Servers do you operate?

 

3. How many mailboxes do your Exchange Servers host?

The majority of on-premises Exchange organizations are in the 1,000 - 10,000 mailboxes range. Nevertheless, the SMBs with 1 to 1,000 mailboxes adds up to 50% of the Exchange organizations that took part in this questionnaire. There are just a few organizations that host more than 50,000 mailboxes.    

 

Diagram How many mailboxes do your Exchange Servers host?

 

4. Do you use an on-premises or cloud-based SMTP gateway solution?

There are Exchange organizations that do not use an SMTP-Gateway solution as part of the mail-flow implementation. Thor organizations that do not use a gateway solution run 1 to 10 Exchange servers on-premises. The majority of those have less than 1,000 mailboxes but there are a few that are responsible for more than 1,000 mailboxes. That leaves the question of why an organization prefers to not secure mal-flow with a gateway.

 

Diagram Do you use an on-premises or cloud-based SMTP gateway solution?

 

5. Which product do you use as a gateway solution?

The use of SMTP gateways is a must, as you do not want to expose your domain member servers to the Internet, not even for the SMTP protocol. A majority of 28 answers for other gateways shows, that there are so many products available and that I did not choose valid answer options upfront. 

 

Diagram Which product do you use as a gateway solution?

The Other answers include:

  • Cisco ESA
  • Clearswift
  • Eleven
  • Fortigate
  • IronPort
  • Postfix
  • Reddoxx
  • Trustwave

 

6. Is your current Exchange organization using a hybrid configuration with Exchange Online?

65% of the Exchange organizations of this questionnaire already run in a hybrid configuration with Exchange Online. Only 35% are (still) not using a hybrid setup.  

 

Diagram Is your current Exchange organisation using a hybrid configuration with Exchange Online?

 

7. Do you plan to implement a hybrid Exchange configuration or to move to Exchange Online?

Of those who currently do not run a hybrid configuration only 37% plan on implementing Exchange Hybrid or migrate fully to Exchange Online. Staying on-premises is the only option.

 

Diagram Do you plan to implement a hybrid Exchange configuration or to move to Exchange Online?

 

8. Until when do you plan to implement a hybrid configuration or go cloud-only?

The majority of the organizations still running only an on-premises Exchange organization plan on implementing Exchange Hybrid or migrating to Exchange Online by the end of 2021. None of the participating organizations has plans scheduled after 2022.

Diagram Until when do you plan to implement a hybrid configuration or go cloud-only?

 

9. Which hybrid model did you choose?

It is no surprise that Classic Full Hybrid is the most adopted hybrid configuration. And, no surprise either, none of the other classic hybrid options is implemented. The modern hybrid approach is implemented but with lesser.

Diagram Which hybrid model did you choose?

 

10. What are the reasons for staying 100% on-premises?

The reasons for staying with an on-premises Exchange organization vary. the reasons mentioned are:

  • Enclosed environment, external access with BlackBerry UEM, due to public sector data security requirements
  • Mailbox data is classified as too sensitive
  • Too expensive and low internet bandwidth
  • Legal and clients audits 

There are still organizations that choose an on-premises Exchange organization in favor of Exchange Online. I wonder if company policies for reducing the carbon footprint might drive the migration of on-premises data center resources to hosted cloud services.  

 

11. Will you implement Exchange Server vNEXT?

Exchange Server vNEXT is in scope for 47% of the organizations. When comparing it with the used Exchange Server version currently in use (~50% Exchange Server 2016) it is an indicator that some companies just skip Exchange Server 2019. Some organizations prefer not to follow the full life-cycle of Exchange Server. s7% of those who do not want to implement Exchange Server vNEXT and want to stay on-premises are single server implementations of Exchange. 

Diagram Will you implement Exchange Server vNEXT?

 

 

Summary

The product Exchange Server is still widely used in on-premises deployments. The reasons vary from legal and compliance requirements, network bandwidth constraints, and the overall costs for Exchange Online. Exchange Server vNEXT is a must-have for nearly 50% of the organizations participating in this questionnaire. There are still older and unsupported versions in productive use. Why this is the case is unanswered in this questionnaire.

Organizations running a hybrid Exchange configuration primarily use a Classic Full Hybrid configuration. This might be due to an early implementation in those days when nothing else was available, or due to requirements using Microsoft Teams with on-premises mailboxes. The adoption of Modern Hybrid shows that the Hybrid Agent approach helps organizations that cannot implement a Classic Full Hybrid. 

I leave the results of this questionnaire to your interpretation and look forward to your replies, either to this blog post or by social media on Twitter and LinkedIn. Please use the hashtag #ExchangeQuest2021.

There will be a new Exchange Server questionnaire in early 2022, covering various implementation scenarios in more detail. If you want to see a specific Exchange topic covered in the 2022 questionnaire, just let me know.

Again, thank you all for participating in this questionnaire.

 

 

Read More »

The Exchange Product Group announced Exchange Server vNEXT for fall 2021. angekündigt. We are all very excited to see what the new version has to offer.

But what is the current situation in on-premises Exchange organizations? I have put a short questionnaire online for gathering information from you. 

The questionnaire deals with the currently used product versions of Exchange Server, the size of your Exchange organization in terms of the number of servers and mailboxes, and the use of planning for a hybrid configuration with Exchange Online.

Screenshot Exchange Server Questionnaire

Take the questionnaire following this link: https://forms.office.com/r/d9syBcgkMk

Thank you for your participation.

 

Viel Spaß mit Exchange Server.

 

Read More »

Exchange Server 2019 LogoServices of third-party software solutions often interfere with installing a new Exchange Server cumulative update, because these services have a file lock active. 

To avoid any issues when installing a CU, or having the prerequisites check fail due to open files, you simply stop the Windows services and ensure that those services do not restart automatically. Especially monitoring solutions that use some kind of watchdog service are a candidate that you must disable for installing an Exchange Server CU.

The following two PowerShell examples help you to prepare the Windows services for installing an Exchange Server CU.

 

Prepare for CU installation

In preparation for the installation of an Exchange Server cumulative update, you can use the following PowerShell commands.

# Disable and stop services or just stop services
# Add other services as needed

# Set SMEX service to manual and stop services
Get-Service -Name 'ScanMail*' | Set-Service -StartupType Manual
Get-Service -Name 'ScanMail*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

# Stop SMEX SQL Express instance
Get-Service -Name 'MSSQL*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

# Disable and stop ENow monitoring services
Get-Service 'ENow*' | Set-Service -StartupType Disabled
Get-Service 'ENow*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

# Stop NetBackup service
Get-Service -Name 'NetBackup*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force

 

Post CU installation

After installing the Exchange Server cumulative update you should restart your computer. I recommend initiating a check for additional Windows Updates for the CU. This helps to ensure that you do not only have the latest CU installed, but required security updates as well.

# Enabling and starting services
# Adjust the list of services as needed

# Enable and start SMEX services
Get-Service -Name 'ScanMail*' | Set-Service -StartupType Automatic
Get-Service -Name 'ScanMail*' | Start-Service

# Enable and start ENow Monitoring services
Get-Service -Name 'ENow*' | Set-Service -StartupType Automatic
Get-Service -Name 'ENow*' | Start-Service

 

Enjoy Exchange Server.

 

 

Read More »

PowerShellYou sometimes need some (or even many) test user objects in Active Directory.

This script helps you create any number of test users in your Active Directory domain, which you can easily enable for on-premises or remote mailboxes afterward.

 

The Script

# Number of user accounts to create
$UserCount = 5
$RandomPassword = $true
$DefaultPassword = 'Pa55w.rd'

# User name prefix
# New user object will be named TestUser1, TestUser2, ...
$TestUserPrefix = 'TestUser'

# User object properties
$GivenName = 'Test'
$Surname = 'User'
$Company = 'Varunagroup'
$JobTitle = @('Junior Consultant','Senior Consultant','Technical Consultant','Business Consultant')
$PreferredLanguage = 'de-DE'

# Name of the new organizational unit for test user object
$TestOU = 'Test User'

# Target OU path where the script creates the new OU 
$TargetOU = 'OU=IT,dc=varunagroup,dc=de'

# Import Active Directory PowerShell Module
Import-Module -Name ActiveDirectory 

# Build OU Path
$UserOUPath = ("OU={0},{1}" -f $TestOU, $TargetOU)

# Check if OU exists
$OUExists = $false

try {
   $OUExists = [adsi]::Exists("LDAP://$UserOUPath")
}
catch {
   $OUExists =$true   
}

if(-not $OUExists) { 
   # Create new organizational unit for test users
   New-ADOrganizationalUnit -Name $TestOU -Path $TargetOU -ProtectedFromAccidentalDeletion:$false -Confirm:$false
}
else {
   Write-Warning ('OU {0} exists please delete the OU and user objects manually, before running this script.' -f $UserOUPath)
   Exit
}

Write-Output ("Creating {0} user object in {1}" -f $UserCount, $UserOUPath)

# Create new user objects
1..$UserCount | ForEach-Object {

   # Get a random number for selecting a job title
   $random = Get-Random -Minimum 0 -Maximum (($JobTitle | Measure-Object). Count - 1)

   # Set user password
   if($RandomPassword) {
      # Create a random password
      $UserPassword = ConvertTo-SecureString -String (-join ((33..93) + (97..125) | Get-Random -Count 25 | % {[char]$_})) -AsPlainText -Force
   }
   else {
      # Use a fixed password
      $UserPassword = ConvertTo-SecureString -String $DefaultPassword -AsPlainText -Force
   }

   # Create a new user object
   # Adjust user name template and other attributes as needed
   New-ADUser -Name ("{0}{1}" -f $TestUserPrefix, $_) `
   -DisplayName ("{0} {1}" -f $TestUserPrefix, $_) `
   -GivenName $GivenName `
   -Surname ("$Surname{0}" -f $_) `
   -OtherAttributes @{title=$JobTitle[$random];company=$Company;preferredLanguage=$PreferredLanguage} `
   -Path $UserOUPath `
   -AccountPassword $UserPassword `
   -Enabled:$True `
   -Confirm:$false
}

 

Enable mailboxes

Use your on-premises Exchange Management Shell to enable all test users with an on-premises mailbox.

$UserOU = 'OU=Test User,OU=IT,dc=varunagroup,dc=de'
Get-User -OrganizationalUnit $UserOU | Enable-Mailbox -Confirm:$false

 

Use your on-premises Exchange Management Shell to enable all test users with a new remote mailbox in Exchange Online. Do not forget to change the tenant name of the remote routing address.

Get-User -OrganizationalUnit 'OU=Test User,OU=IT,dc=varunagroup,dc=de' | %{Enable-RemoteMailbox
 -Identity $_ -Confirm:$false -RemoteRoutingAddress "$($_.SamAccountName)@TENANT.mail.onmicrosoft.com"}

 

You find the most recent version of the script at GitHub.

 

Links

 

Enjoy.

 

Read More »
Last updated: 2020-09-17

 

Exchange Server 2010Exchange Server 2013Exchange Server 2016Exchange Server 2019Problem

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.
When you encounter this error I recommend removing the Edge Subscription from the internal and the Edge Transport Server. Fixing this issue will take some time and the Edge Subscription might become invalid.

 

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. 

So far, I have not seen this issue when using public certificates issued by trusted 3rd-party Certificate Authorities.

 

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

 

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

Read More »