Microsoft 365
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 righ