Note: I practically installed Exchange Server SE role Mailbox server on Windows Server 2025. In an environment with different internal and public DNS domain and Split DNS (Split-Brain DNS). Into existing Exchange 2016 organization using DAG (Database Availability Group).
Mail Flow
- Exchange Server 2016 Mail Flow - Mail Routing and Connectors - my older article
- Mail flow and the transport pipeline
- Configure mail flow and client access on Exchange servers
Mail transport between servers in the organization and between external servers (internet) is performed using the SMTP protocol. Exchange Server uses Transport Pipeline, which is a set of services, components and queues. Important components are Transport Service and Connectors, where we are interested in Receive Connectors and Send Connectors.
Many configurations are common to the entire Exchange organization, so we already have configured for example Accepted Domains and Email Address Policies. There are also Send Connectors, where it's enough to add the new server as a source for sending.
Receive Connectors
During installation, five default Receive Connectors for SMTP message reception are automatically created on the server. Usually we need to modify some settings as we use them on current servers. Or create a new special connector. Always we should have the same connectors on all servers.
Default Frontend <ServerName>Client Frontend <ServerName>Default <ServerName>Client Proxy <ServerName>Outbound Proxy Frontend <ServerName>
Connector Information
We can check and configure connectors manually using EAC.
- EAC - Exchange Admin Center
- Mail Flow - Receive Connectors
We can find out more information using Exchange Management Shell (EMS), where we can list all connectors in the organization, connectors on a specific server or details of a specific connector. Some values are more interesting because they change in practice.
Get-ReceiveConnector -Server MAIL0 Get-ReceiveConnector -Identity "MAIL0\Default Frontend MAIL0" | FL * Get-ReceiveConnector -Identity "MAIL0\Default Frontend MAIL0" | FL Server,*Message*,*Logging*,Bindings,Remote*,Tls*,AuthM*,*Groups
We can use various scripts. If we are creating multiple new servers, it's best to prepare configuration using PowerShell, which we can easily run on other servers.
Example script for displaying differences between two connectors (on old and new server).
$con1 = Get-ReceiveConnector -Identity "MAIL0\Default Frontend MAIL0"
$con2 = Get-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1"
$props = ($con1 | Get-Member -MemberType Properties).Name |
Where-Object { $_ -notin @('RunspaceId', 'Guid', 'DistinguishedName', 'IsValid', 'Id', 'PSComputerName', 'WhenChanged', 'WhenCreated', 'WhenChangedUTC', 'WhenCreatedUTC' , 'ObjectClass') }
$differences = foreach ($prop in $props) {
$val1 = $con1.$prop
$val2 = $con2.$prop
if($val1 -ne $val2) {
[PSCustomObject]@{
Property = $prop
Value1 = $val1
Value2 = $val2
}
}
}
$differences | FT -AutoSize
Connector Configuration
We can then configure the required values using EMS, many also using EAC.
Set-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 Set-ReceiveConnector -Identity "MAIL1\Client Proxy MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 ` -ProtocolLoggingLevel Verbose -MessageRateLimit unlimited Set-ReceiveConnector -Identity "MAIL1\Default MAIL1" -MaxMessageSize "40 MB" -ProtocolLoggingLevel Verbose Set-ReceiveConnector -Identity "MAIL1\Outbound Proxy Frontend MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 Set-ReceiveConnector -Identity "MAIL1\Client Frontend MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 ` -ProtocolLoggingLevel Verbose
Creating Connector
On the internet we can find various scripts for copying connectors, for example Copy-ReceiveConnector. Or advice Copy receive connector to another Exchange Server. We can create a new connector manually in EAC or EMS.
New-ReceiveConnector -Name "Connector AS1 MAIL1" -Usage Custom -TransportRole Frontend -Bindings 0.0.0.0:25 ` -RemoteIPRanges 10.10.0.50 -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 -ProtocolLoggingLevel Verbose
Permissions and Authentication
Using EAC we can easily configure security mechanisms for authentication and permissions using Permission Groups. If groups are not sufficient, we must configure Permissions directly.
List authentication mechanisms and permission groups
Get-ReceiveConnector -Server MAIL0 | Sort-Object Identity | FT Identity,AuthMechanism,PermissionGroups -AutoSize
List permissions on connector
Get-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" | Get-ADPermission |
Where-Object {$_.IsInherited -eq $false -and $_.User -ilike "NT*"} | Sort-Object User | FT User, ExtendedRights
Copy permissions from one connector to another
$sourcePermissions = Get-ReceiveConnector -Identity "MAIL0\Connector AS1 MAIL0" | Get-ADPermission |
Where-Object {$_.IsInherited -eq $false -and $_.User -ilike "NT*"}
$sourcePermissions | ForEach-Object {
Get-ReceiveConnector "MAIL1\Connector AS1 MAIL1" | Add-ADPermission -User $_.User -Deny:$_.Deny -AccessRights $_.AccessRights `
-ExtendedRights $_.ExtendedRights
}
Check limit on number of sent messages
Get-ReceiveConnector -Server MAIL1 | FT Name, MessageRateLimit
Send Connectors
Send Connectors are used for SMTP sending of messages outside the organization. They are not created automatically, but in an existing organization we already have them created. It's enough to add the new server as a source for sending (Source Server) to the given connector. We must have at least one Send Connector for sending to the internet. If we have Exchange Hybrid, then another one exists for sending messages to Exchange Online.
- EAC - Exchange Admin Center
- Mail Flow - Send Connectors
- Edit - Scoping - Source server
Server Certificates for Encryption and Authentication
In the first part we described certificate issuance from internal CA and configuration for Exchange server services. Today we will add more information about certificates and using certificates from publicly trusted CA (commercial CA).
Default Certificates
After Exchange Server installation there are several self-signed certificates on it. We should not delete any of them. The first two are created by Exchange, others by Windows for IIS and Entra ID. Certificates that we see in EAC (their Friendly name is displayed):
Microsoft Exchange- validity 5 years, IMAP, POP, IIS, SMTP, all Exchange servers in the organization trust it, encrypts internal communication between Exchange servers, within server services and for client connections that are proxied from CAS to backendMicrosoft Exchange Server Auth Certificate- validity 5 years, SMTP, serves for authentication between servers and integration using OAuth, created with the first server in the organization and copied to others, if its validity expires, we must issue a new one Exchange OWA login not working, OAuth certificate expired, MonitorExchangeAuthCertificateWMSVC-SHA2- validity 10 years, for remote IIS management (used by Web Management service), must not be deleted, otherwise this service won't start and then Exchange updates cannot be installedMS-Organization-P2P-Access [2025]- validity 1 day, for devices connected to Microsoft Entra ID, trust within Tenant
Certificate from Commercial CA
Certificate we need for
- encrypting communication during client access (internal and external) to services (HTTPS running on IIS)
- encrypting SMTP communication between Exchange server and external servers
- if we use Exchange Hybrid and possibly for other services like POP and IMAP
It is recommended to use
- as few certificates as possible (ideally one and use SAN or wildcard)
- as few names as possible in the certificate (addresses / hostnames)
- the same certificate on all Exchange servers
- for client connections and external servers use certificates from commercial certification authority
If we use Load Balancer, Reverse Proxy or Firewall, where TLS is terminated, then we configure the certificate for HTTPS there. If we have Edge Transport server or other SMTP gateway, then we configure the certificate for SMTP there.
If we have primarily internal certificate on Exchange server, we may still need to configure commercial certificate for some services (e.g. for Exchange Hybrid).
Import and Service Assignment
- certificate we often get as PFX and import into Windows using
certlm.msc - for better overview it's good to set Friendly Name
Service assignment, if we primarily use internal certificate, then we configure only SMTP.
- EAC - Exchange Admin Center
- Servers - Certificates
- choose the new Exchange server and select the imported certificate
- click on the pencil (Edit)
- in the Services tab select SMTP
- click Save
- when asked if we want to replace the existing default SMTP certificate, answer No (so that the certificate for internal communication is not overwritten)
Note: In some cases (such as changing the certificate for IIS Exchange Back End), it is necessary to restart IIS after changing the certificate, for example using the cmd iisreset.
Send and Receive Connectors
On connectors the default SMTP certificate is used by default. If we want to configure a different one, or be sure which certificate is used, we can configure using EMS.
For sending mail we use Send Connectors, which is global, so already configured. I described the configuration in SMTP over TLS encryption on MS Exchange and Cisco Email Security. If we have Exchange Hybrid, we also have another outbound connector to Exchange Online.
$TLSCert = Get-ExchangeCertificate -Thumbprint AC445208321CCE5AA22588700D8864F0E8BCC052 $TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)" Set-SendConnector -Identity Internet -TlsCertificateName $TLSCertName
For receiving mail we have Receive Connectors. If we have Exchange Hybrid, then normally mail from Exchange Online (its Outbound connector) arrives at Default Frontend Receive Connector and it's necessary that the correct certificate is there (verification is performed).
Set-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" -TlsCertificateName $TLSCertName
We can look at the configured certificate for Exchange Hybrid.
Get-HybridConfiguration | FL TlsCertificateName
Mailbox Databases
When installing Exchange server, the first database with the name Mailbox Database <number> was created. Database files and transaction logs are located by default in the path C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\. It is recommended to have data files and logs located each on a different disk (and elsewhere than the operating system).
Database Renaming
- EAC - Exchange Admin Center
- Servers - Databases
- select the database and click on the pencil (Edit)
- change the name and save Save
Using Exchange Management Shell (EMS):
Set-MailboxDatabase "Mailbox Database 0375312042" -Name "DBPraha"
Moving Database and Logs
Because we should not have database files and their transaction logs on C drive, we move them to separate disks. We must use EMS. During the move, the DB will be dismounted.
Move-DatabasePath -Identity DBPraha -EdbFilePath D:\DBPraha\DBPraha.edb -LogFolderPath E:\DBPraha\
Creating New Database
- EAC - Exchange Admin Center
- Servers - Databases
- click on the plus (New)
- Mailbox database - database name
- Server - on which server it should be created
- Database file path - path to data files
- Log folder path - path to logs
After creating new Mailbox DB it is necessary to restart the Microsoft Exchange Information Store service (due to cache). Either through services.msc or PowerShell.
Restart-Service MSExchangeIS
Problem with Database Creation
When creating database, more precisely during its mounting (Mount), I repeatedly encountered a problem and an error was displayed:
Failed to mount database "DBPraha". Error: An Active Manager operation failed. Error: Couldn't find the specified mailbox database with GUID '3835a9b8-a055-45ca-8672-f2312b07bce9'. [Database: DBPraha, Server: mail1.firma.local]
The database was created (although it was necessary to click Cancel in the creation dialog). Its status showed as Unknown, it was enough to wait a few minutes until it changed to Dismounted. Then the DB could be mounted (Mount).
Limit on Number of Mounted Databases
When mounting database we may encounter the error below. Exchange Server Standard has a limit of maximum 5 mounted mailbox databases. It won't allow mounting more and will display an error:
Failed to mount database "DBPraha". Error: An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to select a database copy for possible activation. Error: The database 'DBPraha' was not mounted because errors occurred either while validating database copies for possible activation, or while attempting to activate another copy. Detailed error(s): MAIL1: An Active Manager operation failed. Error: Operation failed with message: MapiExceptionTooManyMountedDatabases: Unable to mount database.
Database Parameters
For each new database (including the default one) we need to configure its parameters. This mainly concerns limits (Limits) on mailbox sizes, assignment of Offline address book, and possibly for testing (when we don't backup the DB) enable Circular Logging (deletion of transaction logs, this cannot be used when we want to add DAG copy).
- EAC - Exchange Admin Center
- Servers - Databases
- select the database and click on the pencil (Edit)
- tabs maintenance, limits, client settings
- save Save
Using Exchange Management Shell (EMS):
Get-MailboxDatabase | FT Name,IssueWarningQuota,*SendQuota,*ReceiveQuota,*book Set-MailboxDatabase DBPraha -IssueWarningQuota "3,5 GB" -ProhibitSendQuota "3,9 GB" -ProhibitSendReceiveQuota "4 GB" ` -OfflineAddressBook "\Default Offline Address List (Ex2013)"
Database Availability Group (DAG)
- Exchange Server 2016 Database Availability Group - my older article
- Database availability groups
- Managing high availability and site resilience in Exchange Server
DAG technology serves to ensure high availability of mailboxes. Databases are replicated between multiple servers that are DAG members. Each database has one active copy and one or more passive copies, which serve for automatic failover in case of outage. Within DAG there can be multiple databases, where each can be active on a different server. This distributes the load between servers and at the same time ensures high availability.
DAG members can only be servers with the same version of Exchange Server. When migrating to a new Exchange version it is therefore necessary to create a new DAG and perform mailbox migration. It is recommended to operate DAG without IP address, i.e. without cluster administrative access point, cluster name object (CNO) in AD and DNS name.
For DAG an object is created in AD of class msExchMDBAvailabilityGroup. We can look at it using ADSI Edit in the path Configuration - Services - Microsoft Exchange - organization - Administrative Groups - Exchange Administrative Group (FYDIBOHF23SPDLT) - Database Availability Groups.
Creating DAG
Configuration can be performed using EMS, but most things can also be configured in EAC, which we will focus on. We need Witness server, where Exchange will create a shared folder (Quorum Witness Resource). It must be Windows OS, where we add the domain group Exchange Trusted Subsystem to the local administrators group.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- click on the plus (New)
- enter unique name, address and folder of Witness server, don't add any IP address
Adding Server to DAG
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- select our DAG and click on the computer icon with gear wheel (Manage DAG membership)
- click on the plus (Add) and add our server, save with Save button
When adding the first server the following is performed
- installation of Windows Failover Clustering component
- Failover Cluster is created for DAG with the specified name, to which the server is added
- server is added to DAG object in AD DS
- cluster database is updated with information about databases that are mounted on the added server
- not performed (we have DAG without IP) creation of CNO in default Computers container AD, DNS record registration for DAG name
When adding the second server to DAG performs
- installation of Windows Failover Clustering component
- adding server to Failover Cluster
- server is added to DAG object in AD DS
- witness directory and share is created
- server is added to DAG object in AD DS
- cluster database is updated with information about databases that are mounted on the added server
DAG Networks
DAG network consists of one or more subnets that serve for MAPI traffic and database replication. Each DAG must have at least one MAPI network and can have multiple networks for replication. We can use a common network for both types of traffic, but it is recommended to separate them.
Replication network should not have default gateway configured and it is recommended to disable Client for Microsoft Networks, File and Printer Sharing for Microsoft Networks and Register this connection's addresses in DNS. DAG members must have the same network adapters.
Network listing using EMS.
[PS] C:\>Get-DatabaseAvailabilityGroupNetwork
Identity ReplicationEnabled Subnets
-------- ------------------ -------
MailDAG\MapiDagNetwork False {{10.20.0.0/24,Up}}
MailDAG\ReplicationDagNetwork01 True {{10.100.0.0/24,Up}}
ExchangeDAG\MapiDagNetwork True {{10.20.0.0/24,Up}}
ExchangeDAG\ReplicationDagNetwork01 True {{10.100.0.0/24,Up}}
DAG networks are automatically configured by the system. If we have properly configured network adapters, then DAG networks will be created reasonably. But replication is enabled on all. If we want to make any changes, we must first enable manual configuration on the DAG.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- select our DAG and click on the pencil icon (Edit)
- check Configure database availability group networks manually, save with Save button
For example, we don't want replication on MAPI network. After enabling manual configuration we can modify networks.
- EAC - Exchange Admin Center
- Servers - Database Availability Groups
- select our DAG, on the right we see DAG Network
- for individual networks we can choose Disable Replication or View details
Adding Database Copy
We have created DAG with several Mailbox servers. Now we can create copies for existing or newly created mailbox databases (Mailbox DB). Continuous replication is automatically configured between the existing database and its copy. The same disks must exist on servers because for the copy the same paths are used for data files and logs. Circular Logging must not be configured.
- EAC - Exchange Admin Center
- Servers - Databases
- select DB, click on three dots (More) and Add database copy
- Specify Mailbox server - choose server where we want to place the copy
- Activation preference number - we can modify copy priority (1 is highest)
- Replay lag time (days) - optional option for delayed replications
I repeatedly encountered the following error when adding database copy.
The seeding operation failed. Error: An error occurred while running prerequisite checks. Error: The specified database isn't configured for replication and therefore cannot be used to perform seed operations. [Database: DBPraha, Server: mail1.firma.local]
Microsoft has article Error when running Add-MailboxDatabaseCopy command: The seeding operation failed. Here it states as the cause that source and target server is connected to different domain controller. In my case, however, both servers used the same DC.
Although an error was displayed, after closing the window (had to use Cancel) the copy was created. It showed status Passive Failed and Suspended. It was enough to choose Update, select source server and run Seeding (if warning was displayed, let cleanup be performed).
Server Status Check
Using cmdlet we can display server status in DAG and check replications.
[PS] C:\>Test-ReplicationHealth Server Check Result Error ------ ----- ------ ----- MAIL1 ClusterService Passed MAIL1 ReplayService Passed MAIL1 ActiveManager Passed MAIL1 TasksRpcListener Passed MAIL1 TcpListener Passed MAIL1 ServerLocatorService Passed MAIL1 DagMembersUp Passed MAIL1 MonitoringService Passed MAIL1 ClusterNetwork Passed MAIL1 QuorumGroup Passed MAIL1 FileShareQuorum Passed MAIL1 DatabaseRedundancy Passed MAIL1 DatabaseAvailability Passed MAIL1 DBCopySuspended Passed MAIL1 DBCopyFailed Passed MAIL1 DBInitializing Passed MAIL1 DBDisconnected Passed MAIL1 DBLogCopyKeepingUp Passed MAIL1 DBLogReplayKeepingUp Passed
Exchange Server Logs
On Exchange Server a huge amount of logs is constantly created, many of them are not automatically deleted (rotated). These are mainly two types of logs (location):
- IIS logs in path
C:\inetpub\logs\LogFiles - Exchange server logs in path
C:\Program Files\Microsoft\Exchange Server\V15\Logging - some logs can also be found in
C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs, but these are apparently deleted
Therefore we must not forget about regularly run script that will delete old logs.
Message Tracking - Mail Flow Logging
- Exchange Server 2016 DSN, Message Tracking and Messaging Analytics - my older article
- Transport logs in Exchange Server
Additional logs on the Exchange server include transport logs (what happens in the Transport Pipeline), such as the Message Tracking log used to monitor mail flow. Default log path:
C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking
By default, circular logging is used, where logs older than 30 days are deleted or when the log folder reaches 1 GB in size. In practice, we may want to increase these values.
Get-TransportService | FL Name, MessageTracking* Set-TransportService -Identity MAIL1 -MessageTrackingLogMaxAge 60 -MessageTrackingLogMaxDirectorySize 4GB
Protocol Logging - logging of SMTP conversations
Similarly, there are detailed protocol logs (SMTP logs), which log communication on connectors. By default, logging is enabled only on selected connectors, but it is recommended to enable it everywhere. Logs are saved into different folders based on the service and connector type.
- Front End Transport service
- Receive connectors:
%ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive - Send connectors:
%ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
- Receive connectors:
- Transport service
- Receive connectors:
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive - Send connectors:
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend
- Receive connectors:
- Mailbox Transport Delivery service
- Receive connectors:
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive\Delivery
- Receive connectors:
- Mailbox Transport Submission service
- Send connectors:
%ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend\Submission
- Send connectors:
Note: Typically, %ExchangeInstallPath% = C:\Program Files\Microsoft\Exchange Server\V15\.
By default, circular logging is used, where logs older than 30 days are deleted or when the log folder reaches 250 MB in size. In practice, we may want to increase these values for selected services.
Get-TransportService | FL Name, *ProtocolLog* Get-FrontEndTransportService | FL Name, *ProtocolLog* Set-TransportService -Identity MAIL1 -ReceiveProtocolLogMaxDirectorySize "1.5 GB" -SendProtocolLogMaxDirectorySize "1.5 GB" Set-FrontEndTransportService -Identity MAIL1 -ReceiveProtocolLogMaxDirectorySize "1.5 GB" -SendProtocolLogMaxDirectorySize "1.5 GB"
Mail Queue
The mail.que file is not related to logging, but it can take up tens of GB on the system disk. All queued messages are stored in the queue database file. The queue can be moved to another disk. The default path is
C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue
Exchange Server Health Checker
Once we have completed the basic configuration, it's a good idea to run the Exchange Health Checker script. This script detects common configuration issues and checks many Exchange server parameters. It will notify us about the settings that can affect the performance and security of your organization. It's a good idea to always download the latest version and use it regularly.
.\HealthChecker.ps1 .\HealthChecker.ps1 -BuildHtmlServersReport
Automatic Windows Updates
Personally, I think that if we have an Exchange cluster (DAG), it is not a good idea to use automatic updates. The server will not be switched to Maintenance Mode, so everything will behave as if the server crashed. Exchange can handle this, but it is better to switch and install updates manually.
You can switch Windows Update to manual mode, for example, using the Server Configuration tool SConfig in the command line.
There are no comments yet.