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!

Today I delivered a session entitled, Unleash the Productivity: Microsoft Office Applications as SharePoint Clients, as part of the live online event, SharePoint In Action.

Thanks to all of you who attended!! 

Slides can be downloaded here.

You can view the event archive at

http://events.unisfair.com/index.jsp?eid=268&id=186

I'm awaiting the full Q&A report from Unisfair.  As soon as I get that, I'll post the Q&A that makes sense to be "public" to this blog, so come back soon!

All the best,

Dan

I just ran across a very strange behavior that I figured I'd better blog about, in case it might help someone else.  I'm not yet sure what the problem is, but I found the solution.

I was configuring a machine for demonstration purposes that had Outlook 2007 running on a Windows Server 2008 domain controller/DNS server (again this was just for demo purposes) that has an SMTP server running on it.  Outlook would not connect to POP3, SMTP or IMAP when I used the DNS name of the server.  I had to use the IP address. This is despite the fact that DNS is configured perfectly and there are no other IP or DNS related problems on the machine.  Again, I'm not sure why this is happening, but the fix was just to configure the mail account in Outlook with an IP address.

It's conference season, and I'm lucky enough to be representing our community in several events, including the upcoming SharePoint Pro Live events in several cities in March and April.

At these events, I'm speaking on the "State of SharePoint."  I certainly have my opinions, but what I really value are yours.  What do you think about SharePoint's role in your enterprise?  What are your experiences?  Your trials and tribulations? Your hopes?

I'm curious:

• What do you wish someone had told you about SharePoint "earlier" (so it wasn't so painful to learn yourself)?
• What have you leaned that you want to share with others?
• What are the biggest gaps in the product? 
• Where is SharePoint delivering the biggest value for you?
• What were the easiest, and the hardest things for you in your learning curve?

I'm definitely interested in the technical, but I am even more interested in the "meta"--the business, the strategy, the governance, the process...

I don't want to start a religious war or a whine-fest, nor do I want to produce a bunch of sugar-coated schlock. I'm interested in real, constructive thoughts from you.  I'll assemble my experiences and opinions, and yours, and present them to you at these upcoming events and through this newsletter.

Please come to my new SharePoint blog  and tell me what you think!  16 months into the SharePoint (V3/MOSS) lifecycle, and on the dawn of Office 14, I think it's time we pooled our thoughts!

So if you didn’t already know that SharePoint was “big,” Microsoft announced that it is now a $1 billion (with a “b”) business!  Wow.  After 18 months of v3/2007, I’d say that rocks!  Microsoft also claims that there are already 100 million licenses sold, though I’m quite skeptical about how that number was determined, given that the same announcement mentions 17,000 businesses using SharePoint.  My guess is that the 17,000 number (which is impressive in its own right since, according to Microsoft, it is actual “in use” deployments) is the one to watch, and that the 100 million number is some voodoo related to Software Assurance or Vista or some kind of “included” license.  100 million licenses—that suggests 1 out of every 50-60 people on the planet have a license to SharePoint. Hmmm…

Not to detract from how big SharePoint really is, however, and how much people are spending on the platform.  Case in point:  Microsoft’s SharePoint conference for IT Pros this week drew in the neighborhood of 4,000 attendees.  The last two TechEd events drew roughly 10,000 to 15,000 attendees and that included developers and IT Pros across all Microsoft technologies. It’s clear where the focus is right now!  It’s going to be a great year!

Microsoft has released Office 2007 SP1, an update for all Office clients. This is the client application Service Pack -- a rollup of bug fixes and other patches that Microsoft has released in year since Office 2007 went public. 

The service pack is a mere 218MB (50% of the size of the original distribution)… ha!  Why’s it so big? Well, Microsoft also incorporated a number of fixes for bugs that they previously had pretended didn’t exist, unless “called to task”, like the highly problematic (and baffling as to how it slipped by) bug related to Excel’s handling of 65534 and 65536. A quick analysis of the Excel file that lists fixes shows over 300 fixes that had no KB article, versus less than half that amount that did.

There are enough fixes and security tweaks that this service pack, like all major updates, should be tested extensively before it is widely deployed. Microsoft has not had a great track record with Office service packs, so listen to the “buzz” as others stub their toes.

The Service Pack is not (yet) on Microsoft Update, but can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=9EC51594-992C-4165-A997-25DA01F388F5&displaylang=en

The KB article about the Service pack is http://support.microsoft.com/?kbid=936982.

And the Excel file that lists all the changes is at http://download.microsoft.com/download/B/C/F/BCFBEC81-ED9E-40A3-BBF0-1410B67A365A/Office%202007%20Service%20Pack%201%20Changes_all.xls

Windows SharePoint Services (WSS) 3.0 SP1 and Microsoft Office SharePoint Server (MOSS) 2007 SP1 is around the corner, and product team member and all-around-great-guy Joel Oleson posted an overview of what's to be expected on the Microsoft SharePoint Products and Technologies Team Blog. Start planning now--there's great news both for IT pros and for developers (can you say "AJAX"?).