This page announces the general availability of Exchange Server Subscription Edition (SE). The main points are as follows:
Background of the Release: Exchange SE continues Microsoft’s tradition of providing enterprise-grade email services across cloud, on-premises, and hybrid environments.
Service and Licensing Changes: Exchange SE follows the Modern Lifecycle Policy, meaning there is no predefined end-of-support date.
Upgrade Details: In-place upgrades from Exchange Server 2019 CU14 or CU15 to Exchange SE are recommended.
Differences: While Exchange SE RTM is functionally the same as Exchange 2019 CU15, the name and version number have been updated.
Future Plans: After October 2025, Exchange SE will be the only supported on-premises version. New features and installation requirements will be added in the future.
The page also mentions the release of Skype for Business Server Subscription Edition.
It’s really convenient to have Copilot summarize the page like this.
AI makes it easy to understand and concisely presents the key points.
As of now, Subscription Edition is more of a version rename than a functional update.
So if you're upgrading from 2019, there's no need to rebuild your environment — an in-place upgrade is enough.
That’s why it feels more like an update rather than a full upgrade.
You can download the installation file from the link below:
While creating a YouTube video, I also decided to write this blog post. I revisited DAG configuration after a long time, thinking it would be useful when setting up a test environment for the upcoming Subscription Edition upgrade.
In Korea, DAG is often referred to as "redundancy." It is a feature in Exchange Server that provides automatic failover in case of database issues. A more detailed explanation involves multiple scenarios, but for now, I will keep it simple and focus on the basic setup.
The environment and specifications remain the same as in the previous post, with three Exchange Servers making up the DAG. The final architecture is as follows:
IPLess DAG Configuration
This time, I am using the IPLess configuration approach.
The IPLess configuration has the following characteristics:
No IP address is assigned to the cluster/DAG, so there is no IP resource in the cluster core resource group.
No network name is assigned to the cluster, meaning there is no network name resource in the cluster core resource group.
The cluster/DAG name is not registered in DNS and cannot be resolved on the network.
A Cluster Name Object (CNO) is not created in Active Directory.
The cluster cannot be managed using Failover Cluster Manager but must be managed using Windows PowerShell, with cmdlets executed on individual cluster members.
I asked GPT to compare the traditional DAG approach with the IPLess approach, and the results are summarized in the table below:
Active Directory Dependency
Requires CNO and AD objects
No AD objects required
IP Address
Requires static IP
No IP required
DNS Registration
Required
Not required
Failover Speed
Relatively slower
Relatively faster
Management Complexity
Requires AD and network management
Reduced management burden
Security Concerns
Requires AD object management and permissions
No AD objects needed
If there are no compatibility issues with third-party solutions, IPLess DAG is recommended.
Prerequisites
When setting up a DAG, the disk structure must be identical across all servers. If the DB disk is set as drive D: on one server, all other servers must also configure their DB disks as drive D:
Step 1. Creating the Witness Directory
Before proceeding, let's understand what a Witness is.
1. What is a Witness Server?
A Witness Server is a server that provides a quorum vote to maintain the cluster quorum within a Database Availability Group (DAG). A DAG requires an odd number of votes (Quorum) to function properly, and the Witness Server helps achieve this.
DAGs operate as Windows Failover Clusters consisting of multiple Mailbox Servers, maintaining a quorum for high availability. If the number of Mailbox Servers in the DAG is even (e.g., 2, 4, 6...), an additional vote is needed, which is provided by the Witness Server.
You might wonder why a Witness is necessary when there are already three servers in the DAG. GPT provided the following explanation:
Server Count
Total Votes (Including Witness)
Operation Status
Quorum Status
All 3 servers operational
4 (3 servers + 1 Witness)
✅ Running normally
OK (4/2 = 2 or more required)
1 server fails (2 remaining)
3 (2 servers + 1 Witness)
✅ Running normally
OK (3/2 = 1.5 → Rounded to 2)
2 servers fail (1 remaining)
2 (1 server + 1 Witness)
✅ Running normally
OK (2/2 = 1 or more required)
All servers fail (0 remaining)
1 (Witness only)
❌ DAG stops
Failed (1/2 = 0.5 → Less than 1 required)
To ensure stable operation, a Witness is essential.
2. What is a Witness Directory?
A Witness Directory is a shared folder on the Witness Server used for DAG operations. It stores files that record the cluster state and helps determine quorum status during a failover.
Default Witness Folder Settings:
A shared folder must be created on the Witness Server.
Typically located at C:\DAGWitness.
The Witness Server must be able to communicate with all Mailbox Servers in the DAG.
The Exchange Trusted Subsystem group must have Read/Write permissions on the folder.
The Witness Server must be a separate system, and a Witness folder must be created on it. In my setup, I am using the Azure AD Connector server as the Witness Server (recently renamed to Entra ID Connect).
Creating the Witness Folder on the Witness Server
Right-click the folder -> Properties
Navigate to Sharing -> Share
Click Find People
Enter Exchange Trusted Subsystem -> Check Names -> OK
Set Permission Level: Read/Write -> Share
Click Done
Right-click Start Button -> Computer Management
Go to Local Users and Groups -> Groups -> Administrators
Click Add
Enter Exchange Trusted Subsystem -> Check Names -> OK
The Witness folder is now created and configured with the necessary permissions.
Step 2. Configuring the DAG
Next, let's configure the Exchange Servers into a DAG.
Open Exchange Admin Center (ECP) -> Servers -> Database Availability Groups -> Add
Specify the DAG name -> Enter Witness Server details -> Click Save
The DAG is created as shown below.
Click Manage DAG Membership
Add one Exchange Server first -> Click Save
The configuration process starts.
Add the remaining Exchange Servers using the same steps.
Step 3. Database Replication
After setting up the DAG, replicate the databases as follows:
Navigate to Databases -> Select a DB -> Click Add Database Copy
Add the Exchange Server -> Click Save
If circular logging is enabled, an error will occur. Disable circular logging before proceeding, then re-enable it later.
If an error occurs initially,
wait a moment and clickUpdateto force replication.
Once complete, verify that the replication status is Healthy.
Check the other servers to confirm that replication is functioning correctly.
With this setup, your Exchange Server DAG is now fully configured using the IPLess approach, providing high availability and redundancy.
After reviewing that video, viewers requested a guide on how to configure alerts via Email. In this session, I will demonstrate how to create that flow. Recently, chatbots generated in Copilot Studio have been referred to as Agents. Unless there are changes, I will continue to define them as Agents. The environment is set to USA (Early), the browser language is set to English, and the work is being done using the Preview URL.
