“Angel Falls (indigenous name: Parakupa-vena or Kerepakupai merú which means the fall from the highest point, in Pemon language” -Wikipedia
On endusersharepoint.com Ben Curry shares a list of SharePoint bad practices. In the shared post Ben jumps right to the #2 bad practice, deploying SharePoint without a governance plan. If I could contribute to the great list Ben has started, #1 at the very top would be lack of an architecture document. Like Angel Falls the highest waterfall in the world this bad practice towers high above all others. “The height of the falls is so great that before getting anywhere near the ground, the water is atomized by the strong winds and turned into mist”
The architecture document and planning is essential with migrations to SharePoint 2010.
You have the software media ready to install, you grab your morning coffee, lock yourself in the datacenter and double click on setup.exe to install SharePoint. Whoa tiger! Did you take the time to create even a basic one page architecture document? If you haven’t, In the world of SharePoint you have just fallen of the deep end. Like being thrown from atop the waterfall you will tumble violently through meaningless database names, random security errors, unmanaged paths, URL access errors and more. The following hours and days of turbulence and troubleshooting will feel like many minutes spent holding your breath underwater.
This avoidable bad practice of not having an arhitecture document can be resolved with less than a day’s worth of planning in most situations. Get rid of the infamous “System Account” in the welcome menu and resolve other security related issues by adding the following section to your pre-install architecture document. One of the many benefits of following these best practices with security accounts is a seamless transition to Kerberos authentication.
Over the past several years I have spent about 80% of my time traveling, training and consulting thousands of SharePoint developers, administrators and architects. I am enjoying three weeks at home at the end of August, sailing, beaching, reading, prepping SharePoint 2010 and relaxing. This is the first time I have been home for more than two weeks straight in over a year! So why on earth am I sitting in the air conditioning, writing this blog post instead of prepping the sailboat? The answer is simple. I want to help the community avoid these mistakes so we all look better as professionals. Some of these common mistakes that can be solved with documentation include:
1. GUIDS in database names
2. Default install names like ‘SharedServices1’
3. System Account in the welcome menu
4. Application pools that don’t match IIS web site descriptions.
5. Lack of managed paths
6. Lack of alternative mappings
7. All content in one database
8. User concurrency issues
9. ‘Access Denied’ errors
10. Lack of storage requirements
In an attempt to ‘vet’ this bad practice I will create a couple of posts over the next weeks and share a few sections of a proven architecture document. Please email with any questions or comments you might like to see added to the posts. Finally, if you are working with SharePoint consultants to assist in your SharePoint installation; one of the deliverables should be an architecture document. You should not have to ask for this artifact. If your consultants have not produced and submitted such a document please do us ALL a favor and send them over the waterfall.
Sample section of architecture document: Security Accounts
Screen cast on SharePoint architecture documents and how they might help prepare for SharePoint 2010
**Update: Due to the many, many requests I have received for this proven architecture document I have started to sell the document with one day of consulting. Toal cost for the 30-40 page document customized for your environment is $2250. Please email me or post a comment for more information.
