Working mainly on the administration and architecture side of SharePoint, I don't get to do a lot of development. That's not necessarily a bad thing as it means that I can be more objective when it comes to deploying solutions to SharePoint farms and making changes to our infrastructure.
However, I do like to keep an eye on the development side to help ensure that we follow best practice, and frequently come across articles detailing common mistakes made during development (such as this one on SharePoint Magazine). I figured that I have seen - and made - a fair few "common mistakes" over the years on the infrastructure side that might be helpful for those new (and perhaps not so new) to SharePoint administration.
Note that this list:
- Should not be considered authoritative (I've worked in this space for around 3 years).
- Is by no means complete (there are a lot more than 10 common mistakes in my view).
- Focuses purely on technical issues as opposed to taking a holistic view of things (which is of course at least as important!).
- Also applies to earlier versions of the product – especially SharePoint 2007.
In no particular order:
1. Not having "SharePoint" in your job title.
This is probably the most controversial "mistake" listed so thought I would get it out of the way first.
This obviously isn't a hard and fast rule but the point is that Windows server administrators cannot expect to learn SharePoint overnight. Don't get me wrong – I'm sure that there are dozens of Windows admins that also know SharePoint; however, if you have just taken on the role of "SharePoint administrator" in your company I highly recommend you ask your boss for some training. It's a big, scary product and it's not just "another Web site" to look after from within an IIS MMC snap in. Be warned that if you are taking this on in addition to dozens of other responsibilities you might be in for a tough time and you will probably need some extra hands on deck.
2. Creating too many Web applications.
Frequent readers of my blog (and anyone who has said the words "Web application" to me) are probably bored to death of this one. However, it's an important point that I think is worth underlining.
I think Neil Hodgkinson summed this up nicely at the European Best Practices Conference last week by stating that he could not think of any typical reason why anyone would require more than 4 Web applications (intranet/portal, mysites, teamsites and partner access).
Inside Microsoft SharePoint 2010 also summarises this well by explaining that creating a Web application is "typically required only when initially installing and configuring SharePoint Foundation or SharePoint Server 2010." It's a great book that I recommend you check out.
Plan your logical architecture. Refuse to create Web apps for every public site / project / client / <insert apparent reason for a Web app here>. I go into much more detail in my Web applications blog post.
3. Making changes in IIS manually.
This one is covered off nicely in this article by Michal Pisarek. My rule of thumb here is that "if the option is in Central Admin, never make the change from within IIS". At its roots, SharePoint is a provisioning engine and it likes to store Web site configuration information in its configuration database if at all possible – examples include a list of Web applications and corresponding IIS sites, Alternate Access Mappings and Authentication Providers. It will save you a lot of headaches if IIS and SharePoint settings match.
There are some things that you must change from within IIS (such as applying SSL certificates and logging settings) – just make sure the options not in Central Admin first.
4. Failing to use the SharePoint solutions framework.
This one overlaps the administration and development space. My rule is simple: if a developer gives you a bunch of files that aren't in a WSP, don't deploy them to your servers.
Making changes manually to the SharePoint Root folder (some call it the "14 hive" due to legacy terminology) will lead to a world of hurt when it comes to adding additional servers to your farm and will lead to inconsistencies including missing files and permissions. In case you are wondering this includes features, templates, branding, sandboxed solutions and farm solutions (don't drag files in into the GAC!). Also watch out for web.config changes: again, changes should be made via code as opposed to manually.
Try to avoid manual changes to the SharePoint farm at all costs.
5. Inadvertently installing a standalone server.
Most green SharePoint admins make this mistake without even realising it simply due to the almost laughable manner in which the SharePoint installer UI repeatedly invites you down the standalone route. Before you know it you have yourself a single server deployment using SQL server express that has very limited scalability and will inevitably be more complex to upgrade.
Don't accept the default options. Think long and hard before clicking "next" as it can have significant ramifications later on. More info is available on Joel Oleson's blog.
6. Using the default SQL DB growth settings.
In a lot of cases, SharePoint administrators will simply use the UI to create content databases. While this will work, SQL performance will be limited due to the somewhat out-dated default size and growth settings. Consider the fact that by default, your content database will grow by 1MB each time: that means that a 10MB file upload will result in your DB growing ten times!
SharePoint is optimised for downloads, not uploads: give your Web applications their best shot at performance by optimising your SQL growth settings. I cover this in some detail in this post and plan to revisit this at a later date.
7. Failing to document the farm configuration.
So you've just set up a comprehensive SQL DB backup plan. That means that the entire farm is safe should disaster strike, right? Wrong.
A common misconception is that you can happily restore the SharePoint configuration database. This is a myth which is covered in Sean McDonough's post on the Configuration-only backup. I also covered this at around the same time here.
In short, a full-fidelity farm backup (that can be used for in-place restoration) is still not possible without using third party tools. If you don't have those tools available you must document your configuration possible, as long as it is taken using SharePoint-aware Backup tools and not just using SQL or DPM. See Back up a farm configuration in SharePoint Server 2010.
8. Manually changing SharePoint databases to "fix" things.
Manual changes to SharePoint databases are not supported.
This is a simple rule that is often misunderstood or ignored. There are some exceptions to this rule (such as a support situation with Microsoft and the logging database) but this rule hasn't changed. Always use the object model or Microsoft supported third party tools to make changes. See this post for more details.
9. Believing that PowerShell is only for developers.
PowerShell is new for SharePoint 2010 and while it might seem scary at first it is a very handy administration tool. You can use it to rapidly check logs. Remove those pesky database GUIDs. Setup a test environment. There are dozens of reasons to use PowerShell that I won't go into here.
Spend some time with PowerShell and you will learn to love it. I've also blogged some of my thoughts on it if you are interested.
10. Disregarding SharePoint capacity planning recommendations.
Every time I go to a SharePoint conference in the UK I hear someone ask the same question: "I have a <insert massive number> GB content database, what do I do?" I think this nicely illustrates a common problem: technical capacity limitations are often brushed under the carpet.
Read the authoritative technet article on SP2010 capacity planning. Note that meeting the supported limitations often involve some form of compromise (e.g. A Document Library can currently store up to 30 million documents. The default maximum document size is 50MB. The recommended maximum size for a site collection for is 100GB: something has to give!).
If you are fortunate enough to be deploying a green field SharePoint farm, make the business aware of these limitations and deal with them today (even if it involves a navigation / structural change). If you currently have site collections that exceed the 100GB limit, consider splitting up content to improve performance and save you further headaches.
I hope this information was useful to you. If you have any further suggestions add a comment or grab me on Twitter.
Ben