Services 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.
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
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.
You 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.
# 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 }
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.
Enjoy.
I am honored to be a speaker at the Virtual Scottish Summit 2021 conference, taking place on Saturday, 27. February.
The Scottish Summit is a truly European event. You can choose from 365 sessions covering mostly any about Microsoft 365 workloads in seven languages:
Attend my session when you are interested in the challenges of implementing Exchange Server Hybrid, and the requirements to make it work with Microsoft Teams and on-premises mailboxes.
My session at Scottish Summit 2021:
See you online for the Virtual Scottish Summit.
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:
The script Fix-ModernPublicFolderNames.ps1 fixes the public folder names to prepare migration to modern public folders in Exchange Online.
# 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
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.
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.
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:
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.
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.
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.
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.
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:
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.
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 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.
The solution contains two configurations.
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
Enjoy Exchange Online.