Avoiding Bad SharePoint Advice on the Web

As I’m sure everyone knows by now I’m a big fan of community involvement in whatever form it takes – blogs, wikis, CodePlex projects, books, speaking engagements, you name it – if it benefits the greater community and enhances people’s knowledge then you can bet I’ll be behind it 100%. That being said, free information on the web sometimes has to be taken with a grain of salt and it can very much be a "buyer beware" scenario. Case in point – I was recently made aware of the following post: Best Practices of SharePoint Farm configuring and deployment Part 2 – Installation & Configuration. I don’t know the author and I’m sure he’s full of good intentions but there is some very bad and erroneous information in this post and you should be wary of his recommendations. Let’s break it down into some of the more salient points:

"Use Windows 2008 with the following roles: Web Server role, Windows Internal Database, and the Microsoft .NET Framework 3.5"

The proper role for a SharePoint WFE is "Application Server", not just "Web Server" – you need the additional features in the "Application Server" role in order for SharePoint to function. Also, I would dearly love an explanation of what, exactly, is gained by installing the Windows Internal Database on a WFE. It’s extraneous in this context and shouldn’t be installed unless there is a driving non-SharePoint need for it (and, try as I might, I can’t think of one of the top of my head).

"SharePoint can be used with the third party databases, for example Oracle, to store List content and to provide other services such as Authorization or Personalization."

Say what? Since when can list content be stored in Oracle? This is completely false – list data is stored in the SharePoint content database in SQL Server. If the author is referring to lists based on BDC profiles which read from an Oracle database then I could accept it but if that’s what he meant then he should have said so; there’s no mention of the BDC in that sentence. I’m not sure what kind of personalization he’s referring to but that piece is handled by the SharePoint profile database, not by any third-party database (might need some clarification here on exactly what is being implied).

"Install Office 2007 on Application Servers…Install Office SharePoint Designer(SPD)"

Whoa there, big fella…just hang on a second. I cannot think of one good reason why Office or SPD should be installed on *any* production SharePoint server. SharePoint doesn’t need it and you darn sure shouldn’t be working directly on the servers for any type of client operations. Keep desktop apps on the desktop where they belong not on production servers.

"Using WSS/MOSS installation without Service Pakc and applying Service Pack later is error-prone approach"

While I don’t necessarily disagree with the idea of using slipstreamed installers – it can certainly make your life easier – there’s nothing "error prone" about applying patches after the fact. The latest hotfixes are all rollups of previous hotfixes and Service Packs are released throughout the lifecycle of the product. At some point you will have to install a patch after the product is already in place. Plan for it, test it in a dev environment, and then do it in production. This is just a silly statement.

"Take into account that uninstalling of SharePoint is not supported."

Um, seriously? Says who? While it is true that uninstalling SharePoint leaves behind some artifacts that may need to be cleaned up manually, this by itself does not make it an "unsupported" action. We need to be very careful when throwing around terms like "supported" and "unsupported" and make sure that PSS has specifically identified the action in question as being one or the other. I’m not aware of any guidance from the Product Group or PSS relating to uninstalling SharePoint.

"Navigate to the Central Administration Site and activate SharePoint license – Enterprise or Standard."

False. There is no such thing. Standard features are enabled by default but you must enable the Enterprise features in Central Administration. You do have the ability to "Convert license type" (where you manually input your license key) but there is no license "activation" process.

"Navigate to the Central Administration site and disable “Web Application” role for all servers in farm, except application servers."

Read the "Services on Server" page carefully – the description for "Web server for medium server farms" reads as follows: "Web application and Search Query services run on this server". That’s trying to tell you something – that your web front ends need the Web Application service. Refer to Daniel Webster’s post on this topic. Removing the Web Application service after the fact is bad mojo. If you don’t want a WFE to run Central Administration then make that selection when you run the Configuration Wizard – don’t do it after the fact or that server will cease to function as a web front end.

It is unfortunate that some people may actually follow this advice without realizing that they are being led down the wrong path. If you cannot afford to bring in an experienced consultant to help insure that your SharePoint deployment is done properly then my suggestion would be to gather information from several sources before taking the plunge so you have some idea of what the general consensus is within the community (better yet, attend the SharePoint Best Practices Conference and get the information in person from well-known experts). It doesn’t take too much searching to discover when someone is peddling bad advice; they may be doing it for good reasons but at the end of the day it’s *your* portal and *your* butt that’s on the line if it’s goes horribly wrong.