Sharepoint Observations - Installation
There has been an explosion in recent days regarding the number of people blogging about Sharepoint, and having just spent 4 days testing and installing the system on my own servers, I thought I'd throw my observations into the ring.
Installation
All and all, installation was pretty simple. Before I got started installing, I tried to find a role-based installation guide. You know, something that helped walk you through installation in a simple manner based on your existing server setup. While the included documentation came close, it was way to jargon heavy for regular users to be able to figure out. Obtuse documentation strikes again! Fortunately, I was able to figure it out relatively quickly, and my test installation on a VMWare instance of Windows Server 2003 was a smart move on my part. I screwed it up twice, and had to start over, so I didn't bring down any websites with my lack of experience.
Tip #1: If your SQL Server is on another machine, download and run the Sharepoint Services installer (Observation: Why is the installation program named with the initials of its former name, “Sharepoint Team Services”?). As soon as it unpacks everything, it will begin to run the main installer. Click cancel, and it will close out. Open up a command prompt, and navigate to the “Program Files\STS2Setup_1033” folder. The type “setupsts remotesql=true”. The installer will run with a new “Web Farm” setup optin underneath the “Typical Installation” section.
Microsoft Suckage Alert #1: More often than not, the SQL server will be located elsewhere. I should not have to fire up a command prompt to be able to get this option.
Microsoft Suckage Alert #2: What's with the “Web Farm“ crap? I can have a SQL Server and a Web Server on two different machines (oh wait, I DO have that) and not be in a Web Farm. That's way confusing. Call them “Single Server“ and “Multiple Server“ installations, and stop trying to preserve market share through consumer confusion.
Next, it's going to ask you to set up your SQL Server connection. Supply your credentials, select a database name, and continue.
Microsoft Suckage Alert #3: If you look at the database structure, you'll see tables named “Sites“ and “VirtualServers“, and Stored Procedures named “sproc_dropSite“. They assume that you'll always have a separate database, and would never integrate it with another existing database. a) Don't make undocumented assumptions, and b) It's safe to assume that if it shows up in the “Stored Procedures“ section of SQLEM, it's a SPROC. MS, you really need to change the DB structure to prefix everything with something like “WSS_“ or “sharepoint_“ so that Sharepoint stuff can reside in existing databases.
Configuration:
Configuration is an interesting and complex process. Because there is no dynamic UI, get ready to spend A LOT of time with click-throughs and postbacks. ASPnetMenu, anyone? Anyways, after the installer completes, it will launch the Windows Sharepoint Services administration page, where it will give you a bunch of confusing options regarding “Extending Virtual Servers“ and “Creating Top-Level Sites“. More jargon to wade through. You're probably going to want to “Create or Extend a Virtual Server“.
Tip #2: DO NOT install Sharepoint services on an IIS web that has content in it. Windows Sharepoint Services is based on ASP.NET, and uses a bunch of HttpHandlers to intercept requests. Your best bet is to run them out of a separate DNS Subdomain, like http://sharepoint.yourwebsite.com. Better to eliminate the possibility for hassles by keeping things separate.
Along those same lines, the documentation says to uninstall FrontPage Extensions is they exist on the server. The problem is, they don't make the distinction between IIS virtual servers, and the machine itself. I'll clarify this for you here: You can leave FPSE installed on the machine, but it cannot be installed on the IIS Web. If you extend a clean IIS web in a separate subdomain, like I said in Tip #2, you should be fine.
When you click “Extend or upgrade virtual server“, you will be given a list of IIS webs on the server. If you have FPSE install, chances are you'll see is how that site's version as “5.0.2.5012“, and it will ask you to upgrade that site. Do not mess with these sites, unless of course you enjoy making your life more difficult. Click on http://sharepoint.yourwebsite.com, and you'll be taken to the confirmation page, where you are given two options: “Extend and create content database“ or “Extend and map to another virtual server“. The first option is the one you want, unless you already have a Sharepoint site, and you want to map another site to it. This would be the option to use in load-balancing situations.
Microsoft Suckage Alert #4: This one rates about a 9.7 on Robert's Scale of Software Suckage (S3 - Patent Pending). When you get to the next page, among other things, it asks you for database access information. The default option says “Use default content database server”. Ladies and gentlemen, if you haven't been paying attention thus far, please do so now. Selecting this option DOES NOT default to the database settings you entered earlier. That database stores only data about the sites that are installed on the server. Unless you specify name and credentials here, Sharepoint will come up with some database name like “STS_server41_1956784809”. The naming convention stands for the server name, and then the IIS web index, which is a hash of the name if you are using IIS6. The only reason this sucks so bad is because it is not very well documented, and the “default” behavior is not the expected behavior. If I created a database in the beginning, I would expect all of the websites I create on that server to be stored in the same database, unless I tell it otherwise.
That's about it for todays's post. I'll be recording my other observations over the days and weeks ahead. Oh yeah, and MS Sharepoint Team, it would be really cool if you could make these things not suck in the rext release.