Always On AG Setup Checklist
A structured checklist for configuring SQL Server Always On Availability Groups — from Windows Failover Cluster prerequisites through listener setup and post-failover validation.
Always On Availability Groups have a lot of moving parts — Windows Failover Clustering, SQL Server configuration, network infrastructure, backup strategy, and monitoring all have to align for the AG to behave correctly under pressure. This checklist is organized by phase to be worked through sequentially during setup, or used as a post-setup audit to confirm existing configurations are complete.
For help with AG setup or troubleshooting, see SQL Server Consulting Services.
Prerequisites and Environment
- SQL Server Enterprise Edition is in use (Standard Edition supports Basic AGs — limitations documented)
- All nodes are running the same SQL Server version and edition
- All nodes are joined to the same Active Directory domain
- All nodes are running a supported Windows Server version
- All nodes have the Failover Clustering Windows feature installed
- All nodes have the same SQL Server collation
- Service accounts are domain accounts with appropriate permissions on all nodes
- SQL Server service account has "Perform volume maintenance tasks" right (instant file initialization)
- Dedicated network adapters are in place for the cluster heartbeat network (separate from client traffic)
- Firewall rules allow SQL Server port (1433), AG endpoint port (5022), and cluster ports across all nodes
Windows Failover Cluster (WSFC)
- Cluster Validation has been run and passed (or documented exceptions reviewed)
- Windows Failover Cluster is created with a meaningful cluster name object (CNO)
- Cluster IP address is assigned and resolvable on the network
- Quorum model is appropriate for the number of nodes (node majority, node and disk, node and file share, cloud witness)
- A cloud witness or file share witness is configured for even-node clusters
- Cluster log has been reviewed — no recurring resource failures or network issues
- Cluster name object (CNO) has permissions to create computer objects in AD (required for listener creation)
SQL Server AG Endpoint Configuration
- Database Mirroring endpoint is created on all nodes (CREATE ENDPOINT … FOR DATABASE_MIRRORING)
- Endpoint is in STARTED state on all nodes
- Endpoint port (default 5022) is open in Windows Firewall on all nodes
- Service account has CONNECT permission on the endpoint on all nodes
- Endpoint encryption algorithm matches across all nodes
Availability Group Creation
- AG name is documented and does not conflict with existing SQL Server names
- Databases being added to the AG are in FULL recovery model
- Initial full backups of all AG databases have been taken on the primary
- Backups have been restored WITH NORECOVERY on all secondary nodes
- AG is created with appropriate availability mode (synchronous vs. asynchronous) per node
- Failover mode is set correctly — automatic failover only configured for synchronous replicas
- Connection access on secondary replicas is configured (read-intent only, all, or none)
- Backup preferences are set (primary, secondary only, prefer secondary, any)
- All databases have joined the AG on all secondary replicas
- AG state shows SYNCHRONIZED (synchronous) or SYNCHRONIZING (asynchronous) — not NOT SYNCHRONIZING
Listener Configuration
- AG listener is created with a unique DNS name
- Listener IP address is assigned and does not conflict with existing addresses on the network
- Listener port is documented (default 1433 or a non-default port if multiple instances)
- DNS registration of listener name is confirmed — resolves correctly from client machines
- Connection string in applications uses the listener name, not a node name directly
- MultiSubnetFailover=True is set in connection strings if the AG spans subnets
- ApplicationIntent=ReadOnly is used in connection strings routing to readable secondaries
Backup Strategy on Secondaries
- Backup jobs are configured to honor AG backup preferences (using sys.fn_hadr_backup_is_preferred_replica)
- If backups run on secondaries, copy-only full backups are used to avoid breaking the log chain on primary
- Backup jobs exist on all nodes and handle the case where the node is not the preferred backup replica
- Transaction log backups run at the required frequency on whichever node is preferred
- Backup file paths are accessible from all nodes (shared network location or cloud storage)
- A restore has been tested from backups taken on a secondary replica
Monitoring and Alerting
- AG health state is monitored — alerts configured for NOT SYNCHRONIZING state
- SQL Server Agent alerts for severity 17–25 and AG-specific errors are configured on all nodes
- Database Mail and operators are configured on all nodes (alerts need to fire after failover)
- SQL Agent jobs critical to operations exist on all nodes and are enabled/disabled appropriately based on AG role
- AG Dashboard in SSMS has been reviewed and shows expected state
- sys.dm_hadr_availability_replica_states is being queried in monitoring
- Estimated data loss (last_commit_time delta) is within acceptable RPO thresholds
Failover Validation
- A planned manual failover has been tested — primary and secondary roles swap correctly
- Applications reconnect to the new primary via the listener without manual intervention
- Backup jobs and SQL Agent jobs function correctly after failover
- Database Mail continues to work after failover (operator on new primary is configured)
- Read-only connections continue routing to the secondary after failover (if readable secondaries are in use)
- A failover runbook exists documenting the manual failover procedure, verification steps, and rollback path
- Recovery time during the test failover was within acceptable RTO thresholds
- Post-failover, synchronization resumed and secondary returned to SYNCHRONIZED state
More SQL Server references
SQL Server Health Check Service · SQL Server Health Check Checklist · SQL Server Migration Planning Guide · SQL Server Consulting Services
Frequently Asked Questions
Does this checklist apply to SQL Server Standard Edition?
Standard Edition supports Basic Availability Groups, which are limited to one database per AG, no readable secondaries, and no distributed AGs. The core WSFC and listener configuration is the same, but several items — readable secondaries, multiple databases per AG, advanced backup routing — do not apply.
What if the AG is already set up — can I use this as an audit checklist?
Yes. Work through each phase and note gaps. The most commonly missed items in existing AGs are: SQL Agent jobs not configured on all nodes, backup jobs not honoring AG backup preferences, and failover never having been tested.
Who is Michael Paycer?
Michael Paycer is a SQL Server DBA and Developer based in Saint Cloud, Minnesota with 20+ years of experience in SQL Server administration, development, performance tuning, reporting, ETL, HA/DR, and database design.
How can I contact Michael Paycer?
Email michael.paycer@gmail.com or reach out via LinkedIn or Upwork.