SQL Server Always On setup prerequisites

SQL Server Always On is Microsoft's umbrella name for high availability and disaster recovery features. On Windows, production Availability Groups and Failover Cluster Instances use Windows Server Failover Clustering as the cluster layer.

An Availability Group protects databases. Each replica is a SQL Server instance on a separate WSFC node, and data moves through SQL Server log-based replication. A Failover Cluster Instance protects an instance name. The SQL Server service, virtual network name, IP resources, and shared storage move between possible owner nodes.

The setup prerequisites are therefore partly SQL Server and partly Windows infrastructure. Before setup, the team needs node names, domain membership, edition, storage approach, DNS, FQDNs, static IPs or reserved virtual IPs, cluster quorum, service accounts, firewall paths, and the connection name applications will use.

Enter the planned Always On type, node count, edition, subnet count, listener or virtual name choice, witness type, and the design details that change the prerequisite list. The calculator gives planning counts and warnings; it does not replace Microsoft cluster validation or licensing review.

Choose the technology before counting IPs. Availability Groups and FCIs both depend on WSFC, but they solve different problems and need different prerequisites.

Edition choice is not a purchasing footnote. It changes what the Always On setup can actually be.

Every planned node needs a supported Windows Server version, the Failover Clustering feature, domain membership, consistent patching, working DNS, working time sync, and enough permissions for cluster creation and SQL Server setup. For Availability Groups, Microsoft documents that participating computers should be WSFC nodes and not domain controllers.

Run cluster validation before treating the design as build-ready. A failed storage, network, system configuration, or inventory validation means the SQL Server setup may succeed while the HA design is still not ready for production.

# Run from an elevated PowerShell session on a management host or cluster node.
# Replace node names before using.

Test-Cluster -Node SQLNODE01,SQLNODE02 -Include "Storage","Inventory","Network","System Configuration"

# After cluster creation, confirm quorum and node visibility.
Get-ClusterNode
Get-ClusterQuorum
Get-ClusterNetwork

One working production NIC per node is the usual minimum, but that is not the same as a complete production design. Most real Always On builds need a deliberate traffic model for client access, cluster communication, replication, backup, and management.

Count IPs before setup. You need static IPs for nodes, an agreed WSFC cluster access point, and the listener or FCI virtual network name when used. In multi-subnet designs, plan one listener or FCI virtual IP per subnet and make sure client drivers and connection strings are ready for that behavior.

An AG listener is a DNS name, port, and one or more IP addresses that applications use instead of connecting to a specific replica. An FCI virtual network name is the stable instance connection name that follows the SQL Server resource group during failover.

For either design, the name must be unique, registered in DNS, backed by the right virtual computer object, and reachable through the firewall. If port 1433 is used, confirm port ownership and side-by-side instance behavior. If a non-standard port is used, the application connection string has to include it.

WSFC quorum decides whether the cluster is allowed to stay online. A two-node Always On design without a witness is fragile because losing one vote can leave the cluster without a majority.

For even node counts, plan a witness before setup. File share witness is common for SQL Server Availability Groups because AGs do not require shared disks. Cloud witness can be useful where Azure storage and outbound HTTPS are allowed. Disk witness belongs only where shared disk is part of the design and makes sense.

Availability Groups do not need shared storage for database replication. Each replica has its own database copy, and SQL Server moves log records between replicas. That still leaves storage decisions for data paths, log paths, tempdb, backup locations, seeding, and restore operations.

FCIs are different. An FCI needs shared storage visible to every possible owner node, because the instance moves to another node and brings the same databases online there. The shared storage can be SAN/shared disk, SMB file share, or another supported Windows clustering storage design, but it must pass validation before SQL Server setup.

For Availability Groups, every replica needs Always On enabled, a compatible SQL Server version and edition, endpoint planning, firewall access between replicas, and databases in full recovery model with a full backup taken before joining. Jobs, logins, linked servers, credentials, certificates, operators, and alerts need their own review on each replica.

-- Run on each SQL Server instance that will host an AG replica.
-- Adjust endpoint name, port, and service account before using.

CREATE ENDPOINT [Hadr_endpoint]
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (ROLE = ALL);

-- Every availability database must use full recovery model.
ALTER DATABASE [YourDatabase] SET RECOVERY FULL;
BACKUP DATABASE [YourDatabase] TO DISK = N'\\backupshare\sql\YourDatabase_full.bak' WITH CHECKSUM;

Always On setup needs more than a DBA login. The build touches Windows clustering, SQL Server services, DNS, AD computer objects, SPNs, firewall rules, and sometimes storage permissions.

Port planning should happen before the listener name is handed to application teams. At minimum, plan the SQL instance port, listener or FCI port, AG endpoint port where AGs are used, DNS, SMB, RPC, Windows cluster communication, monitoring, backup, and management paths.

Multi-subnet designs need extra care. The application should use a supported client driver and connection settings such as MultiSubnetFailover=True where appropriate. Otherwise a technically healthy failover can still look like a long application outage.

Use this as the practical gate before setup day. If one row is vague, the build is probably not ready yet.