Ok – so recently I’ve been asked several times about using Sharepoint Services as an extranet to securely exchange documents with customers and business partners. The short answer is that this is very possible with Windows Sharepoint Services. However, you must be familiar with the licensing considerations, and how those apply to vanilla Windows Server compared to Small Business Server . . .
First, Windows Sharepoint Services is a free add-on to Windows Server 2003 – and as such, access to WSS is bound by Windows Server licensing for the product it is installed on. With vanilla Windows Server, we have two licensing modes – Per Server and Per User / Device. It is also important to note that while you can enable anonymous access to WSS sites and bypass licensing considerations, for the purposes of enabling a secure extranet, we’re assuming that anonymous access will not be enabled.
With Per Server mode, you are using a concurrent licensing model – so you can have an unlimited number of users accessing the server (and thus any WSS sites) just as long as the maximum number of concurrent connections does not exceed the number of installed CALs.
With Per User / Per Device mode (formerly Per Seat mode), you must have a User or Device CAL for each unique User or Device that connects to the server. Therefore, if you wanted 100 separate users to access the server (and thus any WSS sites), you would need 100 User CALs.
Now, for vanilla Windows Server, you can also purchase an External Connector – which allows for an unlimited number of external users to connect to your server (and thus any WSS sites). Note that an external user is defined as “a person who is not an employee, or similar personnel of the company or its affiliates, and is not someone to whom you provide hosted services using the server software” – so you would still require the necessary CALs for internal users.
So – to use Windows Sharepoint Services as an extranet solution on vanilla Windows Server, the licensing structure that works best is dependant on the number of concurrent external connections that you are anticipating, as well as the licensing mode you’re using for any other Windows servers in your domain. For a stand-alone server, you would probably be best served with a Per Server licensing mode and a smaller number of CALs – as you would only need to license the maximum number of concurrent connections (whether internal or external users). For a domain member server where the rest of the domain is using a Per User / Per Device mode, it makes sense to use the same Per User / Per Device mode on the WSS server, since your users / devices are already licensed. In this scenario, you would then need to purchase User CALs for each named external User. Once an organization is looking at more than 40 external users, then the External Connector makes sense (as Windows CALs are ~ $50 each, and the External Connector is ~ $2k). Again, the External Connector only licenses external users – so you would need CALs for internal users.
Now, things get a little less flexible when we start to talk about Small Business Server. First, remember that WSS is bound to the licensing mode / restrictions of the OS it’s installed on. Second – we all know that SBS is always in Per User / Per Device licensing mode – we can’t do Per Server licensing with SBS. As a result, we have to provide a CAL for each named User or Device that is going to be accessing (authenticating with) our SBS domain (we can’t use a concurrent connections model). Third – there is no External Connector for SBS. So what does this mean? In simple terms, this means that if you want to use WSS on SBS as a secure extranet, you need an SBS CAL for each external user. And since SBS is limited to 75 CALs total – you’re limited as to the number of external users who can access your WSS extranet (internal users + external users <= 75).
Does this suck for SBSers? Yeah – kinda. Although it is important to note that this wasn’t an intentional restriction. Microsoft is aware of this restriction, and members of the SBS team have publicly stated* that they are going to correct this in future versions. While they haven’t provided specifics on how they are going to correct this – I’m guessing we’ll either have an updated EULA that explicitly allows external authenticated connections to WSS sites, or the addition of an SBS External Connector sku.
* Guy Haycock stated this during the Microsoft Partner Tour stop here in Omaha on 3/28