At the time of this writing, I have around three years of experience with Microsoft Sharepoint Services for Windows Server 2003, and here is a bit of what I’ve learned during my fight with the beast.

There are two different versions of Sharepoint for Windows Server 2003: Sharepoint Services and Sharepoint Portal. Sharepoint Services are free for Windows Server 2003 customers and do not require any additional CALs (Client Access Licenses), it is licensed through the regular Server CALs. Sharepoint Services are designed for one Sharepoint Site and they do not have a search function.

Sharepoint’s main function is that of some sort of basic repository for (Microsoft Office) documents. If you use Microsoft Office 2003 or higher and click on a document stored in the Sharepoint repository, it will automatically be ‘checked out’ from the repository and automatically marked as ‘in use’. When the user saves the checked out document from Word or Excel or any other Office application, it is automatically checked in again and marked as ‘last edited by <user>’.
Of course, Sharepoint also has discussion areas, image libraries and what-not. It can also be extended with custom applications or external web services.

The Portal Server now is exactly what its name says: A portal, and actually a portal for a multitude of Sharepoint Services sites. It includes a search function that works for all the Sharepoint Services Sites that it hosts. If you want to use Sharepoint Portal, you have to buy a base license for the Sharepoint Portal Server and Sharepoint Portal Server CALs for each user who is going to use the Portal Server. Naturally, all these users also require regular Windows Server CALs in addition to that. This quickly becomes expensive, but once you have a larger amount of users, it will be worth it. We only used Microsoft Sharepoint Services at my last employer, because it was cheaper and more or less sufficient for what we needed to do. But our user’s really missed the search feature in the end.

Let’s go back in time a bit. Three years ago at my now ex-employer, we needed a working document repository so that a larger amount of external partners could collaborate with our own staff. It was my job to come up with a technical solution for that, and naturally, I gave the Open Source world a thorough look and evaluated a couple of WIKIs and other offerings of the Open Source community. Although we already had a collection of Windows Servers in our basement, I was willing to add a GNU/Linux box to the mix, if it would do the job and save us some money.

Microsoft Sharepoint Services are not really a WIKI, because WIKIs allow anybody to edit any article on them. In our case, this eventually became the killer argument against all Open Source solutions that I had looked at, because we did not want everybody on the planet to be able to access the document repository, and we certainly did not want everybody to be able to edit and upload documents.

This is the main philosophical difference between Sharepoint and WIKIs: Sharepoint thinks like an Enterprise thinks - it supports different user accounts, user roles and access privileges and restrictions. WIKIs manifest the Open Source way of thinking: Anybody can access, download, change and upload again. Implementing granular access permissions as I can do it in Sharepoint is a royal pain in the neck in all Open Source products that I had experimented with.

Sharepoint Services had exactly what we needed, and back then, it was the only product that had all those enterprise features, so I chose it. I had actually spent three months or so evaluating different products, most (but not all) of them had been Open Source. Actually, I badly wanted to use an Open Source solution, but compared to Sharepoint Services, they all sucked for our purposes or simply lacked the functionality. So in the end, I had to follow my own advice.

Naturally, Sharepoint integrates great into a Windows and Microsoft Office environment, but it’s also an administrative headache on its own merits: It’s not enough if you add a user account into Active Directory. You also have to add that Active Directory User Account to Sharepoint’s own user database through Sharepoint’s administrative webpage and you have to define the user’s role and access rights there. Actually, depending on the level of permission granularity that you want to use, you also have to define the user’s role and permissions for EACH sub site in Sharepoint. It can become messy. Very messy. But the point is: In Sharepoint, at least you can do it.

Sharepoint Services ’sit’ on Microsoft IIS (Internet Information Server) and ASP.NET, and you can enhance it with own ASP.NET applications, if you need to. BUT: The setup is complex and you really have to know what you’re doing or you will break something and Sharepoint or the other web pages/applications running on the same server won’t work anymore. To avoid any problems, I simply ran Sharepoint on a dedicated machine.

Sharepoint Services come with an enhanced version of the MSDE 2000; you cannot add your own database or tables to that special version of Microsoft SQL Server, but unlike its smaller and free (as in beer) sibling MSDE 2000, it does not have a limit on the database size or the number of CPUs that it can use. Alternatively, you can also configure Sharepoint to use an existing MS SQL Server. You can also start with its own database engine and then migrate later to SQL Server, but it’s a bit clumsy to do that. If you have a SQL Server in place, I’d suggest that you use it right from the start.

Here is an important difference between Sharepoint Services and Sharepoint Portal when it comes to Backup solutions like Veritas/Symantec BackupExec: For Sharepoint Services, you would need an MS SQL Server backup client. For Sharepoint Portal, you will need a special Sharepoint Portal Backup client. Not knowing this, I bought Sharepoint Portal Backup clients and naturally they did not work with Sharepoint Services.

Like Windows Server 2003, Sharepoint is a very stable and robust product: Neither Server 2003 nor Sharepoint ever crashed on me in the last four years. And I am serious: Provided that you feed it with the regular updates, including a server anti-virus software, these products are really reliable and dependable. Since Windows Server 2003, I can hardly say anything negative about Microsoft Server products. The administration sucks in many different ways, but so do the other systems as well.

Exchange Server 2003 is a different story, especially when you run out of database storage or when the database reaches the limit defined in the Windows registry. (Ok, this is probably only an issue with the Standard Edition of Exchange 2003.) But it’s part of the family, so you have to make the best out of it.

I haven’t touched any competing Open Source products since that evaluation phase three years ago. But I don’t think that there now is a serious competition to Sharepoint on the market - provided that you actually need Enterprise features like the ones Sharepoint has. Even the Open Source and GNU/Linux geeks that I have been working with grudgingly admit that Sharepoint is Microsoft’s killer product in that specific market and that there is no real competition for it in the OSS world - again, at least not when you need real integration with Office applications and Enterprise-level user access control.

When you are in a place where you already have Microsoft Servers running, the decision is a no-brainer: Sharepoint it is. Nothing integrates better into the Microsoft world.

If you have, let’s say, one hundred users or less, Sharepoint Services might be sufficient for you. The only thing your users will sometimes miss is the search function. But if you keep the site well organized, that shouldn’t be a real issue. Of course, if you have the budget, directly start with Sharepoint Portal. It’s just a bit more complex to setup and administer.