License to Fill: Licensing SharePoint for the Extranet

There are a number of technical articles about how to configure Windows SharePoint Services (WSS) 3.0 to serve as both a local, intranet collaboration site and an extranet portal for clients, partners, vendors, etc. There are issues relating to URL namespaces and Web applications, Secure Sockets Layer (SSL) and other security concerns, and using multiple authentication providers—using Windows authentication for your employees and forms-based authentication (FBA) for your extranet, for example. You also need to know that, generally, you'll want a unique site collection for each constituency (e.g., for each client) for user and group management reasons.

There are lots of ways to make WSS work, technically, for an extranet. However, there should be only one set of guidelines for how to license an extranet server. It should be easy to figure out, so that everyone who cares about being "legal" can be so easily, and so that Microsoft can make every dollar it deserves from the product. Unfortunately, it is not easy to figure out, partly because there are several moving parts to a WSS extranet and Microsoft does not clearly lay out the interaction of the parts, from a licensing perspective. To make matters worse, different Microsoft offices around the world are giving customers different guidance, and software vendors and implementers, some unscrupulous and some just as confused as the rest of us, provide further, different guidance.

This week, the lack of licensing clarity became particularly salient as my peers went around and around trying to make sense of it and as several customers complained to me about the crazy and confusing issues.

So I'm going to step into the ugly, sticky, dark, slimy place that I as a consultant try to avoid like the black plague it is: licensing. Over the next two weeks, I'm going to lay out the concerns as I see them and summarize what I have gleaned from Microsoft (from its Web site) and from peers and customers. I will tell you right now, and I emphasize: This stuff *is* insanely stupidly confusing, so my guidance is just that - guidance. You must consult with your Microsoft reps to make sure you are compliant. I hope this discussion will help you carry on an intelligent conversation with Microsoft. I'm also hoping that the high visibility of this newsletter prompts a clear response from Microsoft, which I'll obviously pass on to you if it contains clarification or corrections.

Identify the Components You Must License
These are the components of a WSS implementation that you must license or purchase:

• Windows Server (2003 or 2008): The server OS on which the WSS front-end runs or on which the storage (SQL Server) runs.
• Client access licenses (CALs) for access to Windows Server
• CALs for access to SQL Server

An important note is that the server and client licensing for Windows 2003 R2 and Windows Server 2008 has not changed. However, I found the Web pages describing licensing in Server 2008 were generally easier to understand.

Windows Server (2003 or 2008) Server

Details are at Windows Server 2003 and Windows Server 2008

You must purchase or otherwise license Windows 2003 or Server 2008 as an OS. The server license allows you to install the server, but doesn't in itself allow users to access it - that's where CALs come in. Of course, sometimes this includes a certain number of CALs.

You will need the license for the server running the WSS front-end. If you are running SQL Server on a separate system, you will also need a license for that instance of Windows Server.

Virtualization
Of course, there are now licensing options for virtualization. If you are licensed for Windows 2003 R2 Enterprise Edition or Server 2008 Enterprise Edition, you can run one instance of Windows Server on the physical system and up to four instances in virtual machines (VMs) on that physical system. With Server 2008 Standard Edition, you can run one instance on the physical system and one in a VM on that system. Both Windows 2003 and 2008 Datacenter provide unlimited server instances in VMs.

So, if you have a single license for Windows 2003 Enterprise Edition (or better) or Server 2008 Standard Edition (or better), you could run SQL on the physical system and WSS in a VM, or vice versa. Of course you'd also need to have appropriate licenses for virtualization software, but that's another story and there are plenty of free options (e.g., Microsoft Virtual Server, VMware Server, Server 2008 Hyper-V.

You can also use your downgrade rights to run a version of Windows Server prior to your licensed version. For example, if you have a Server 2008 Standard or Enterprise Edition server license, you could run the WSS front end on the physical system, leveraging the strengths of IIS 7.0 on Server 2008, and you could run SQL Server 2005 in a VM running Windows 2003 R2, because SQL Server 2005 doesn't gain a tremendous advantage from Server 2008, and since it's easier to install on Windows 2003, requiring fewer patches.

Bottom line
You'll need one or two Windows Server licenses. With virtualization and a Windows 2003 Enterprise or Server 2008 Standard license, you can save yourself one server license. Whether that makes sense from a performance perspective is left to your analysis.

Client Licensing for Authenticated Access to Windows Server

Just having the server OS isn't enough: The server must be licensed for access by clients. This is the first place it gets tricky. You can find details about Windows Server 2003 and Windows Server 2003 R2 client licensing here.
Windows Server 2008 CALs are covered here.

The crux of the client licensing issue is authentication. If users are authenticated in any way, you need a CAL. That means any exchange of credentials, through logon, IIS authentication—anything—requires a CAL. The only thing that doesn’t require a CAL is anonymous access, such as a wide-open public Internet site.

CALs
That said, you have two basic ways to purchase access: CALs or an External Connector license. CALs are sold per-device/per-user or per server, and are fairly well understood. In an extranet scenario, it’s unlikely you’ll be able to manage device connections, so let’s assume you go with per-user licensing. You need a user CAL for each server a user accesses. For example, every user requires a CAL to access the WSS server. Similarly, each user requires a CAL to access the SQL server.

This is a very important point. You need Windows Server CALs for SQL Server access, even though technically the user isn't touching the SQL Server, but rather WSS is a middleman, grabbing data from SQL on the user’s behalf. That doesn’t matter; you need the CALs. So if your SQL Server is on a separate physical or virtual instance of Windows Server, and you’re using per-user CALs, you’ll need two CALs per user! This is an economic (if not technical) reason why some organizations choose to run SQL Server on the same Windows Server system as WSS.

I’ve just described per-user licensing. But you can also choose per-server licensing, in which case you must have CALs for the maximum number of users or devices that might simultaneously access or use the software. Again, you need to do this on both the WSS front-end server and the SQL Server. It doesn't matter that the SQL Server is not authenticating the users—it's providing services (indirectly) to authenticated users.

External Connector
If your users are internal users with Active Directory (AD) accounts, there must be CALs (either per-user/per-device or per-server). There is no option. If they are external users—for example partners, customers, or vendors—who will authenticate in any way, then you can either provide CALs for those individuals as part of your per-user or per-server CALs, or you can use the External Connector license. The External Connector license allows an unlimited number of authenticated users, as long as those users are external. Again, you would do this for both the WSS front-end server and for the SQL Server if they're running on separate instances of Windows Server.

Virtualization
If you’re running Windows Server inside a VM, the CALs or External Connector license must be purchased only for the physical system. For example, if you have run Windows Server (2003 or 2008) Enterprise Edition for the physical system, you can run four instances of Windows Server in VMs, and the CALs or External Connector for the physical system are valid for the four VMs.

Web Edition
Finally, you can use the Web editions of Windows Server—Windows 2003 Web Edition or Windows Web Server 2008—which don't require CALs or an External Connector license. You can't run the storage (SQL) for WSS on that system, so you will still need CALs or an External Connector license for the box running SQL Server. If, however, your design prescribes a Web front end and a SQL back end, using the Web edition for the front end might save you some license cost.

Bottom line
Do the math: You must have per-user (or per server) CALs for all internal users. You can choose per-user CALs, per-server CALs, or an External Connector license for external users, whichever is most economical. That’s the “Windows Server client license.” If SQL Server and WSS are on the same physical box (or running in licensed virtual instances on one physical box), you only need one “set” of that Windows Server client license package. If SQL Server and WSS are on separate physical boxes, then you’ll need two sets of your chosen client license solution. Microsoft makes this so easy, doesn't it?

SQL Server Licensing

Ya gotta have storage for WSS, and your choice of SQL Server edition and the placement of the SQL Server service affect licensing. Details are here.

If you install WSS with the Basic option, the setup routine configures the Windows Internal Database, which is SQL Server Embedded Edition (Microsoft Office SharePoint Server --MOSS--installs SQL Server Express). The Windows Internal Database is free to use, has no database size limit, but cannot be accessed remotely, making it an ideal solution for a single-server WSS implementation. Basic installation prevents that server from being added to a farm (which would require reinstallation of WSS). By using the Windows Internal Database, you do not incur costs for WSS storage. Note you're not allowed to run the storage for WSS on the Web editions (Windows Server 2003 Web Edition or Windows Web Server 2008).

If you use SQL Server 2005 Express Edition, you can avoid licensing fees, access the server remotely (i.e. configure a SQL Server back-end and a WSS front-end) but you have a 4GB database size limitation which effectively prevents you from using it for site collections with large document libraries.

Therefore, most split-server implementations will use SQL Server 2005 Standard or Enterprise Edition, for which you must have licenses. There are three options: Server plus device, Server plus user, or per processor. The Server plus device option is probably not realistic for extranet scenarios because you can't easily control the number of devices accessing WSS. Per-user licensing might make sense for very small implementations. Per-processor licensing is most common, as it allows unlimited connections to the WSS database and to any other application databases on the server. Each physical or virtual processor to which SQL processes have access must be licensed.

Don’t forget, if SQL Server (any edition) is running on a physical box other than the WSS server, you must have the Windows Server OS license and either Windows Server CALs or an External Connector license.

If you are running SQL Server in an appropriately licensed virtual instance, the Windows Server CALs or External Connector license is applied only to the physical system. Those licenses also apply to each licensed virtual instance of Windows Server.

Bottom line
Small, simple implementations will use Basic Installation and, by using the WID, avoid SQL license costs. Larger implementations and farms will typically use SQL Server 2005 Standard or Enterprise Edition and will generally find that per-processor licensing is most economical.

Clear as Mud?

This two-part article took five single-spaced pages in Microsoft Word to summarize licensing. You can see why even Microsoft’s own employees can’t understand the licensing requirements. They are convoluted and there’s nowhere that puts the different pieces of the puzzle together to make it easy.

Although I’ve done my best to interpret all of Microsoft’s online licensing guides and have confirmed my interpretations with some very smart people, be sure to take this knowledge and confirm your licensing with your Microsoft representative. You might just know more than they do, now, so use this information to carry on an intelligent discussion.

I will revise this blog entry if I receive corrections or "nuances" from Microsoft.

Thanks to all the MVPs who contributed their experience and expertise to this round-up, particularly to Spencer Harbar (check out his blog) for helping untangle this web!