Licensing Windows SharePoint Services

All about SharePoint licensing

In the last issue, "License to Fill: Licensing Windows SharePoint Services for the Extranet," I began a discussion about the lack of clarity in Windows licensing and how it relates to Windows SharePoint Services (WSS). This week, I continue that discussion in an effort to bring clarification to a messy subject.


Client Licensing for Authenticated Access to Windows

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.

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.

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.




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.

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


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.

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.

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’ll revise this if I receive corrections or clarification from Microsoft.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.