On 10 January 2009, I attended the SharePoint Saturday – Virginia Beach event with a friend of mine, looking to see SharePoint from a different angle and take in new perspectives and perhaps learn a thing or two while being refreshed by others in the "community". It was great to meet Paul Galvin, Dan Lewis, Becky Isserman and John Miller.
The first session that I attended was led by Dean Halsted of Microsoft. Dean’s session was entitled, "Technical Best Practices". I cringed. Why did I cringe? Primarily because I’ve learned that the words we use unintentionally influence the thoughts of those that we’re speaking to significantly. If we mention the buzz words "best practice" then regardless of what is said down the line, there is no going back, the "best practice" is essentially canon – there can be no deviation. Lesson Learned – try not to call something a best practice unless it applies regardless of context.
So does that mean? No "best practices"? By no means… there are definitely core things to think about from a technical and functional perspective. There is however the distinction that while keeping things in context and consideration of the technical problem at hand, the solution may not always be the same. Design recipes, patterns and practices are approaches for problems, not necessarily pre-baked cookie batter waiting to be dished out.
Needless to say this got my brain cooking on contextual considerations and is the melding of Dean’s thoughts, those of others and my own, intertwined with commentary. For this post, the primary focus will be just on the “Pre-Deployment Considerations”.
Overall, Dean’s session was informative as he provided information that while common sense to the seasoned SharePoint engineer (though still a good reminder and refresher) a key set of starting points and considerations for the rookies and novices in the crowd.
Prior to the deployment of a SharePoint system in the context of enterprise systems that are rigorous and require change management processes be in place to assist the information worker, several key things should be considered to include:
- System Quotas
- Information Policy
- User and Server Network
- System User Base
- Authentication Mechanisms
Each of these should be planned out so as to ensure that the deployment of SharePoint is seamless and that there are no surprises. As an engineer, we might like surprises and problems that require elegant solutions, but for clients, the preference really should be that we find them out prior to deployment in a test bed. One decent example to make note of in terms of overlooked planning is the use of quotas. Without a quota in place, there is no way to keep a site collection from grow rapidly without oversight. In some instances sprawling uncontrollably causing system failures due to hard disks filling up (you’ll see this often if you’re not using a SAN or DAS). By applying quotas when a system first deploys it provides for greater flexibility and allows all sites with the quotas applied to quickly be updated should you decide to increase the size allowed – similar to the way gMail has a quota for your mailbox. With quotas initially enforced they can be increased dynamically across your entire web application rather than having to go site to site to site. For more on this topic, check out Dan Lewis’ recent post on “Managing and Administering Site Quotas in SharePoint”.
Information policy, while not typically touched upon by the novice administrator can come in quite handy when creating internal and external access boundaries. This additionally comes into use when the need for certain personnel within an organization require access to all items within a particular web application, or when it is required that a specific user cannot access a site, regardless of what permissions a site administrator may attempt to grant the user.
Defining and designing the user and server networks within an organization are never trivial unless working with an organization that resides completely on a single network segment without firewalls or any other boundary. For smaller organizations, it might even be ideal to host the environment on something like Amazon EC2, Microsoft SharePoint Services Cloud, or through a hosting company like 1 and 1. Perhaps your organization is looking to have a centralized deployment with a significantly large farm to provide a high performance end user experience – has the farm been load tested from several systems sitting within the network to ensure that the circuits don’t be come saturated? For most large organizations additional planning and consideration must be taken to ensure that latency is minimal, availability is high and that integration is not degraded.
Defining the System User Base is also a necessary step that should be investigated. Knowing where the users reside, what levels of access they require and the overarching permissions model provides for to include security groups will provide for a more seamless and palatable deployment across an organization. This will cut down on the confusion of how users access sites and what user has permissions which will make your system administrator’s will to live increase significantly 
Authentication mechanisms… figuring out how your users are going to come into the system is key. Are you using ISA server as a proxy in a DMZ to allow for external users or forms authentication? Are you merely using SharePoint on an intranet and don’t require anything fancy so you settle for NTLM? Are you working with integrated systems that require a double hop to occur for credential passing and therefore have to go through the tedious task of setting up Kerberos? All considerations that require diligent investigation based on the context of the environment.
Overall, there are several other factors that should be considered prior to deployment, but I’ll save those for another day. What are some of the key things that were planned prior to your organizations deployment?
Now Playing: Paco De Lucia
– Paco De Lucia, John McLaughlin, Al Di Meola
– Manha De Carnaval
