Plan Your SharePoint Farm Right with a SQL Server Alias

Mask (thumb)

I was speaking at SPTechCon San Francisco earlier this month, and the topic of SQL Server aliases came up during Q&A towards the end of a half-day tutorial I was delivering. I’m glad I was able to spend a few minutes talking about the topic and its importance, but after thinking about the questions that were asked, I thought it would be a good idea to cover the topic in blog post – especially for those who are new to SharePoint or getting ready to stand-up a new farm.

What is a SQL Server Alias?

This is a fairly common question, particularly amongst new SharePoint administrators and those who don’t have any real familiarity or background with SQL Server. The essence of a SQL Server alias and what it does can be found in the following Microsoft TechNet definition:

An alias is an alternate name that can be used to make a connection. The alias encapsulates the required elements of a connection string, and exposes them with a name chosen by the user.

What does this mean from a practical standpoint? Well, consider a simple farm like the one shown below:

When the lone SharePoint Server (SPWFE1) needs to connect to a database (such as WSS_Content_MyContentDB) on the back-end SQL Server (PRODSQL1), it might create a connection string that looks similar to the following.

Server=PRODSQL1;Database=WSS_Content_MyContentDB;IntegratedSecurity=true;

In this situation, the SharePoint server is directly coupled to the SQL Server because SPWFE1 directly references the production SQL Server (PRODSQL1) by name. This works just fine for day-to-day operations, but it doesn’t provide any real flexibility to accommodate topology changes that might be required (or “just happen”) in the future.

Consider the same farm when a SQL Server alias is used instead of a direct reference to the SQL Server:

The corresponding connection string that is built by SharePoint to connect to the SQL Server looks a little different; note the difference in Server name:

Server=SPSqlAlias;Database=WSS_Content_MyContentDB;IntegratedSecurity=true;

The SQL Server alias serves as an abstraction layer between the SPWFE1 and PRODSQL1. Whenever SharePoint needs to access a database, it indicates that it wants to connect to SPSqlAlias instead of PRODSQL1. When this happens, the SQL Server Native Client maps SPSqlAlias requests through to PRODSQL1 at runtime; SharePoint doesn’t specifically know about PRODSQL1, so direct coupling doesn’t occur.

Why an Alias is Important for SharePoint

Configuring one or more SQL Server aliases is simple enough, and Microsoft recommends using aliases to harden your farm environment. Despite these points, the utility of an alias may not be immediately apparent. There are a handful of different situations in which SQL Server aliases come in useful, though, both before a farm has been set up and after it has been operational for some time.

Non-Standard SQL Server Port Usage

By default, connections that are made to SQL Server take place on TCP port 1433. To improve security in your environment, administrators may choose to alter the port on which SharePoint SQL Servers listen.

When changes are made to the port on which SQL Server listens, SQL Server aliases provide an easy way to use the new port without explicitly referencing the (non-default) port value each time a connection/server name is needed.

The image above and to the right demonstrates how such an alias might be set up using the SQL Server Client Network Utility. In this example, the Dynamically determine port checkbox was unchecked and a Port number of 12345 was specified. Once this is in-place, subsequent connections to SPSqlAlias (for database activity) would take place on TCP port 12345. This would be helpful if PRODSQL1 were setup to listen on TCP port 12345 instead of port 1433.

Moving (or Losing) SQL Servers

Migrations and server moves are the most common usage scenarios that involve SQL Server aliases. To illustrate how a SQL Server alias can help in these situations, consider the previous small farm that includes the SPWFE1 and PRODSQL1 servers. What happens if the PRODSQL1 server crashes and a new SQL Server is brought-up for SPWFE1 to use? What occurs when the capacity of PRODSQL1 is no longer adequate and a newer (and beefier) SQL Server must be used with SharePoint?

If a SQL Server alias like SPSqlAlias is in-place, then swapping-out the SQL Server back-end becomes a five minute exercise in reconfiguration. As shown above and to the left, the only thing that needs to change to point SPWFE1 to NEWSQL2 (instead of PRODSQL1) is the server name referenced by the SPSqlAlias SQL Server alias on each SharePoint server.

It is worth noting that a SQL Server alias can be added after-the-fact if it wasn’t in place to begin with, and Todd Klindt provides a fantastic walk-through on how this can be done on his blog. The biggest downside with waiting “until later” to implement a SQL Server alias, in my opinion, comes in the form of confusion.

To understand what I mean by “confusion,” consider the diagram on the right. Even though an alias has been added to the SharePoint server and SPWFE1 is now using NEWSQL2 for database operations, it’s probably going to be pretty doggone confusing to administrators to see PRODSQL1 in Central Administration and all other farm dialogs/messages when they know (hopefully) that NEWSQL2 is actually the SQL Server back-end that is in-use.

By starting with a SQL Server alias before farm implementation, it makes it easy to use an alias name that is obviously an alias – like SPSqlAlias. This avoids the confusion and potential administrative misconfiguration that might arise due to alias names that match old (or other currently operational) servers.

Simplifying Farm Expansion and Reconfiguration

For administrators who are expecting growth and want to simplify future expansion, it’s possible to establish and make use of additional aliases up-front to enable redistribution of databases across multiple SQL Servers at a later time. For example, what if you knew that you’d eventually need to separate content databases from service application databases in your SharePoint environment? You might configure your farm to use aliases similar to the ones shown above and to the left. All databases would start off on PRODSQL1, and the SharePoint farm would hum along just fine for as long as PRODSQL1 proved adequate to service the load.

When the time arrived for expansion and break-out of the databases, an additional SQL Server (for example, PRODSQL2) could be brought in and the service application databases migrated to it. Updating the farm to accommodate this change would then be as simple as altering the SPAliasServices alias to point at the new server PRODSQL2 server as shown on the right.

In the example shown, I chose to logically partition databases along a content/service boundary. This concept could be further extended to partition databases by service type (breaking out Search specifically, for example), by content nature (read/write content versus read-only content), and more.

Wrapping It Up

Mask

SQL Server aliases are exceptionally useful in addressing a variety of operational concerns, and they are most effective (and least confusing) when implemented prior to the build-out of a SharePoint farm environment.

If you’re planning to build a new SharePoint farm sometime soon, make SQL Server aliases a part of your plan. Not only are aliases a best practice and way to improve security in your environment, they’re also a way of “buying some insurance” against changes and curveballs that might come your way in the future.