Creating a SQL Server Availability Group via PowerShell

This is tangibly related to SharePoint and this took me awhile to figure out the correct syntax.  I’ve been building a SQL AG on Server 2012 with the Core installation option.  To accomplish this, you will need a workstation with SQL Management Studio installed (which also installed the SQL PowerShell module).  Some background on this setup: 2 servers with Windows Server 2012 and SQL Server 2012 SP1 CU5 3 network adapters per server Features installed (note that “D:” has the Windows Server ISO loaded) on the servers: [crayon-5200c71bd19b3440395112/] IP all of the adapters appropriately.  Next, rename the secondary and tertiary network adapters for clarity: [crayon-5200c71bd19c2633051971/] Note that you may want to disable or modify the Firewall Policy for the “Domain” and “Private” profiles.  You can do this via the Set-NetFirewallProfile cmdlet. On the client workstation with the RSAT tools installed (Failover Cluster), run the following to import the Failover Cluster module, create the cluster with a static IP address, then rename the network adapters to fit the adapter name on the server.  Finally, set the Ethernet adapter (this is the adapter that is used for standard client to server communication) Host Record TTL to 300 seconds. [crayon-5200c71bd19cd877534054/] Next, on each server, install SQL via batch script.  Real quick hint here, make sure to exit the PowerShell prompt prior to running this.  The SQL installation media needs .NET 3.5, but because we’re running Server 2012 and PowerShell 3.0, we’re using .NET 4.  This will cause the installation to fail.  The following will install SQL Server 2012 with the Database Engine, SQL Agent, Replication, Integration Services, and Client Connectivity with the specified username and password to the E: drive while the CD/ISO is present in the D: drive.  Do not forget to edit the /PID value.  It will also enable TCP/IP connectivity to the instance. [crayon-5200c71bd19d8018918680/] Once complete, download SQL Server 2012 SP1 and I’ve chosen to also install CU5.  Once downloaded, extract the executable using the following command, making sure to extract each package to a unique path: [crayon-5200c71bd19e5451029078/] Next, for each package, run: [crayon-5200c71bd19ee879232558/] This will install the package applying the patch to all instances on the server.  You may or may not need to reboot in between patches. Next, move to the workstation.  I have a workstation running Windows 8 x64 with SQL Management Studio 2012 SP1.  Open Management Studio and go to View -> Registered Servers.  Add the two instances under Local Server Groups. Next, run PowerShell as Administrator on the Workstation.  Run “sqlps” or [crayon-5200c71bd19f7729270153-i/] to import the SQL PowerShell module.  Validate the previous server registration by executing [crayon-5200c71bd1a00457629451-i/] , and running [crayon-5200c71bd1a08657140847-i/] .  Both servers should appear here.  The next step is to connect to each server, which can be done by executing [crayon-5200c71bd1a10549591693-i/] . For each SQL Server, the next step is to enable AlwaysOn and create the HADR Endpoint.  Both cmdlets have a few options, so review them prior to execution.  Note that when enabling AlwaysOn, the Database Engine service must be restarted, which the -Force switch does (or should do, it didn’t work in my case). [crayon-5200c71bd1a19086150981/] Next, create the Availability Replicas (in memory), create the Availability Group with the Primary server specified, and finally Join the secondary server to the Availability Group.  Again, these cmdlets have a lot of options, so it is best to review them so the setup fits your environment. [crayon-5200c71bd1a22055318608/] After this, via Management Studio, you should now be able to review the Availability Group status.  In my case, I had a critical error which was due to my HADR endpoint being in a stopped state, preventing the secondary replica from connecting to the primary.  To resolve this, I ran the following T-SQL: [crayon-5200c71bd1a2d355367795/] Once this completed, the secondary replica joined automatically.  Note it is normal to have warnings as there are no synchronized databases at this point. The final step to create the Availability Group is to create the Listener, which can be done with the following cmdlet: [crayon-5200c71bd1a36754872419/] And now you have two complete SQL Servers, ready to have SharePoint databases added to the Aavailabity Group!  Make sure to test failover to validate functionality.  Do not forget the following resources with regards to supportability of SharePoint databases on an Availability Group. Supported high availability and disaster recovery options for SharePoint databases (SharePoint 2013) Configure SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013