Pepuri Server world Eng Version

This time, we will cover the topic of ADFS & WAP Upgrade & Migration.

As indicated in the title, the upgrade and migration will be performed from Windows Server 2022 to 2025.

For reference, the ADFS configured on Windows Server 2022 will be referred to as ADFS2022, and the WAP configured on Windows Server 2025 will be called WAP2025.

Youtube: https://youtu.be/BYR4fl7o29o

Step 1. Installing ADFS 2025

First, join the server where you will install ADFS to the Active Directory.

Go to Server Manager -> Add Roles and Features.

Proceed with installing the Active Directory Federation Services role.

Click Install.

Next, select Configure the federation service on this server.

Choose Add a federation server to a federation server farm.

Click Change and enter the credentials of a Domain Admin account.

Enter the information of the existing ADFS server.

Specify the certificate (ensure the certificate installation has been completed beforehand).

Provide the ADFS service account details.

Proceed with the installation process.

Close

Once the installation is complete, launch AD FS Management.

You will see that the current server is set as Secondary. A switch between Primary and Secondary needs to be performed.

On the newly installed 2025 server, run the following command to switch it to Primary:

Set-AdfsSyncProperties -Role PrimaryComputer

To change the existing ADFS 2022 server to Secondary, run this command on the 2022 server:

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName <2025서버>

When you open the management console on ADFS 2022, you will see it is now set as Secondary.

On ADFS 2025, confirm that it has switched to Primary.

Finally, update the internal DNS to point the ADFS address to the new server’s IP.

Step 2. Remove the Existing ADFS 2022

From the Roles installation menu, start the Remove Roles and Features Wizard.

Uncheck the Active Directory Federation Services role and proceed with the removal.

Close

Once the removal is complete, change the server’s membership from the domain to a Workgroup.

Step 3. Install WAP2025

Open the hosts file on the existing WAP2022 server with Notepad, copy its contents, and save it to the WAP2025 server.

Note that while published configurations are migrated, certificates are not included, so make sure to back up and import each certificate separately.

On WAP2025, proceed to install the Remote Access Role.

Check Web Application Proxy and continue with the installation.

Open the Web Application Proxy Wizard

Enter the ADFS service URL and credentials.

Select the pre-installed certificate.

Configure

Close

The interface will display as if a cluster is configured.

You can verify the current connected servers with the command:

Similar to 2019 and 2022 versions, the Configuration Version remains as Windows Server 2016.

Step 4. Remove WAP2022

On WAP2022, start the Remove Roles and Features Wizard.

Uncheck the Remote Access – Web Application Proxy role and proceed with removal.

Update the currently connected server information using the following command on WAP2025:

Set-WebApplicationProxyConfiguration -ConnectedServersName <WAP2025>

Confirm that the connection information has been updated correctly.

Successful login was also confirmed via Office.com, indicating that no additional action is required in Entra ID Connect and no major issues are expected.

Youtube: https://youtu.be/VEyKbmwxoaU

Exchange Server Subscription Edition (SE) Has Finally Been Released

Exchange Server Subscription Edition (SE) is now available | Microsoft Community Hub

Copilot AI Summary

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:

Exchange Server build numbers and release dates | Microsoft Learn

Over time, the term RTM may be phased out.

Let’s walk through what happens when you upgrade from CU15, for comparison.

Mount the ISO file and run the Setup file.

You’ll notice the label SUBSCRIPTION EDITION at the top of the installer screen.

The installation proceeds the same way as in previous versions.

After the installation completes, you’ll see the version number has been updated.

DAG is also maintained without any issues.

Previous Post

2024.12.31 - [Exchange] - Exchange Server 2019. Deployment (2): Configuration (CU14, Nov24SUv2 / Windows Server 2022)

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.

https://youtu.be/oJbLbREw1zA

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.

Database availability groups | Microsoft Learn

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:

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:

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 click Update to 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.