In the previous part of this lab series, we set up the Active Directory, which forms the backbone for everything that follows. If you haven’t gone through that step yet, I strongly recommend doing so first, because the configuration of SQL nodes and clustering relies heavily on the domain and networking setup we completed earlier. In this post, we’ll move forward with installing and configuring SQL Server instances, preparing the environment, and setting up the Windows Server cluster.
Installing Windows Server
The first task is to prepare the SQL Server instances. To do this, I created new virtual machines using the custom installation option, selecting Version 17. One important detail here is that I did not install the operating system during the VM creation stage. There’s a known bug that prevents the OS from installing correctly at this step, so the right approach is to create the virtual machine first and then add the operating system afterwards.
Once the VM was ready, I attached the Windows Server installation media and installed the operating system manually. During this process, I made sure the network configuration was aligned with the domain controller that we set up earlier. Keeping track of IP addresses and DNS entries is critical at this stage, since the nodes need to communicate reliably within the cluster later on.
Configuring Windows instances
With the operating system in place, the next step was to join the SQL nodes to the domain. I started by renaming the machines to meaningful identifiers — in my case, SQLA and SQLB — and then joined them to the Active Directory domain. A quick test using a domain account login confirmed that the domain membership was successful, which meant I could move on to installing SQL Server itself.
The SQL Server 2025 installation was performed on each node with consistent settings across the board. Using the same collation and configuration ensured uniformity in the setup, and I also used the domain service accounts that were created in Part 1 for the SQL services. This approach keeps the environment secure and aligned with real-world best practices.
Installing Cluster Services
With SQL Server installed, it was time to configure the cluster. I launched the Failover Cluster Manager and created a new cluster, adding the SQL nodes I had just configured. Before finalizing the cluster, the wizard runs a validation test to check shared storage (if applicable), network connectivity, and node visibility. Once all these checks passed, I proceeded to complete the cluster creation, leaving me with a functional Windows Server cluster that’s ready for AlwaysOn configuration.
At this point in the lab, we now have the Active Directory configured, SQL nodes installed and domain-joined, and a fully operational Windows Server cluster. In the next part of this series, we’ll move on to enabling and configuring AlwaysOn Availability Groups in SQL Server 2025, which will allow us to simulate real-world high availability scenarios.
This lab is designed not only to walk through the mechanics of setting up AlwaysOn but also to illustrate how each component—Active Directory, SQL nodes, and clustering—fits together in a production-like environment. Following along step by step ensures you build a strong understanding of how high availability is achieved in SQL Server 2025, and sets you up to dive deeper into Availability Groups in the upcoming post.
Check out part 1 below.