From a Domainless Environment to a Resilient SQL Architecture
For a pharmaceutical company running an application with a drug catalog, database availability was an important infrastructure requirement. The client needed a SQL environment designed to remain operational even when individual servers became unavailable.

Three high-performance servers running on separate physical hardware were reserved for the solution. A fourth, external resource was also considered for the architecture, with Azure Storage among the possible options.

There was one important constraint: the client did not have an Active Directory domain and wanted to build the cluster without introducing one. This shaped the architecture and implementation approach from the very beginning.

Laying the Foundation with a Three-Node Windows Server Cluster
Before building the SQL high-availability layer, we first needed to establish the underlying Windows Server Cluster. The three servers were placed on separate physical hardware to reduce dependency on any single host. The clustering role was then configured across all three machines, creating the infrastructure foundation for the SQL environment. Because the client's servers were operating outside a domain, the standard domain-based approach was not suitable. Instead, we adapted the configuration to the client's existing environment.

A separate DNS server was used to resolve the server names. The same local administrator account was created on each machine, which enabled the three servers to be joined into a Windows Server Cluster within the domainless environment. Once the client's environment had been prepared, the Windows cluster itself was deployed in approximately three hours.

Establishing Secure Communication Between SQL Server Instances
With the Windows Server Cluster in place, we proceeded to the SQL layer. SQL Server was deployed across the three nodes, resulting in three SQL Server instances participating in the high-availability architecture.The absence of an Active Directory domain also influenced how communication between these SQL Server instances had to be established. To address this, three certificates were created through SQL command-line execution, one for each server.

Each SQL Server instance was then configured with information about the other two instances, with certificate-based authentication enabling communication between them. This allowed the instances to participate in a single high availability group while operating on top of the Windows Server Cluster. The SQL cluster configuration was completed in approximately three hours.

Adding an Independent Witness to Support Cluster Resilience
A resilient cluster also needs a mechanism to determine whether a node has become unavailable. For this environment, an independent network share was used as the cluster witness. Because the cluster nodes could access this external resource, it provided an additional reference point when determining cluster state if one of the participating nodes lost connectivity or became unavailable.

The Result: A Three-Node High-Availability SQL Environment
The project resulted in a three-node Windows Server Cluster hosting three SQL Server instances configured within a high availability group. Most importantly, the solution accommodated a fundamental constraint of the client's existing infrastructure: the absence Active Directory domain available for the cluster.

By combining a domainless Windows Server Cluster, DNS-based name resolution, consistent local credentials, certificate-based communication between SQL Server instances, and an independent network-share witness, we created a database architecture designed to continue operating when individual infrastructure components become unavailable.