Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2009/09/10/10-sharepoint-deployment-standards.aspx
<update>
For those readers who were directed here from Joel Oleson’s blog, please take a look at my response post:
SharePoint Standards – Indeed, Context is Important
</update>
Everywhere you look there is SharePoint standards this… best practices that… governance out the wazoo. I’ve never seen anything like it in my entire life! Seriously, have any of you? Once upon a time all you needed was a handy dandy API reference and you could do anything you wanted. Then there was SharePoint… with much power comes much responsibility.
Over used clichés: 1, my blog: 0
So yeah, you’ve started using SharePoint, and now you have to be that much more diligent with who and how people are putting things on your farms. As you engage third parties to do SharePoint work for you it is very important that they conform to the standards of your organization so that maintenance on their work corresponds to the maintenance you are already doing for other applications.
To that end it is very important that you have a pretty comprehensive list of SharePoint standards for your organization in the first place so that you can adhere to them and also have them handy to give to any consultants.
Recently Lori Gowin (@lorigowin) and I started putting such a list together and I thought I’d share some of those with you. Thanks for the assist here Lori. So, in no particular order here are 10 standards for our SharePoint deployments:
1) SharePoint Designer must not be required to update any portion of a SharePoint Site
Before you SPD lovers start throwing Zunes at me, let me again state that SPD has it’s place within any organization as a very helpful tool for development. However, you should take what you do in SPD and convert it into a feature. This is crucially important for branding. SPD is a wonderful tool for developing your branding and you are probably tempted to just publish it from SPD. Don’t do it. Say it with me… “FEATURES”. I could go on and on about this (oh, and in fact I did in a previous blog post). I realize there are some organizations that heavily rely on SPD and hopefully are aware of all the gotchas that come along with it.
2) No SharePoint Designer WorkFlows
SPD has some wonderful out-of-the-box workflows. However, these workflows are limited, do not migrate well, and would need to be maintained in production (see #1 above). There are some cryptic blogs out there about taking an SPD workflow and converting it to a feature, but that seems to be more of a headache than doing it right in the first place.
3) All sites must be created using Site Definitions or Site Templates
Now, I understand if you are manually creating some Team sites or some other minor site in SharePoint it would not make sense to create a Site Definition all the time. However, if you bring in a third party to deliver some sites to you that you have to maintain, you better make sure they use Site Definitions or Site Templates, especially if they are doing any branding or you will most likely end up with a scenario that violates #1 up there.
In addition, for your Site Definitions be sure to use minimal Site Definitions and take advantage of feature stapling, otherwise you will not be able to update anything in the Site Definition (does anyone else consider this a bug?? Hopefully there is a good reason for it).
4) No individual permissions on items or sites. All users should be in a SharePoint Group for team sites, and should be in a security group for all other sites.
To cut down on maintenance, make sure you have a strategy for how users are granted access in SharePoint. I highly recommend that, for your tightly governed applications where the business is not site owners, you only add Groups (AD, FBA or whatever) to your SharePoint Groups, and not individual people. If a user needs access to that application add that user to the corresponding Group outside of SharePoint . This will really help keep your SharePoint Admins out of the user management business and allow them to concentrate on serving you. 🙂
5) Large libraries (>2000 items) should be divided across multiple libraries.
There are many reasons why this makes good sense from performance, storage, security, and search standpoint. Also, as always, be aware of versioning in your document libraries.
6) Folders within document libraries should be converted to metadata, with the appropriate site columns and content types defined. Folders should never be used without the strictest governance applied
This is another big one, and fairly common advice out there in the SharePoint world. When possible avoid using folders, otherwise you end up with the same mess you have with your eRooms and Shared Drives. Take advantage of what SharePoint offers in the form of meta-data and work more efficiently here.
7) Team Site Collections should not have more than 1 level of subwebs. (Subwebs should not have sub-subwebs.)
When looking at disaster recovery, along with looking at the number of sites in the content database, you will want to limit the number of levels of sub-webs for each site collection. Backing up and restoring site collections that contain multiple levels of sub-webs makes restoring individual sites and items more time consuming and complex with the absence of a 3rd party backup and restore solution. The other complexity that it adds is if the sub-webs break permission inheritance. All of the groups for security on the sub-webs roll up to the top level of the site collection, and are viewed and able to be managed at that level.
8) Content databases should have no more than 5 site collections (some larger ones should be the only site collection in the content db.)
So this one should be fairly self-evident. You don’t want your Content Databases getting too large and you don’t want to have to dig through hundreds of sites to find what you want to restore. Good rule of thumb is 5 site collections per Content Database, and definitely there are instances when 5 is too many. Use good judgment here. I believe best practice states that your Content Databases should not be larger than 100gb.
9) All images for a site must be stored in image libraries and not on the file system
Sounds like a no brainer, I know. However, when bringing in third parties to create sites (ESPECIALLY if they are converting an old non-SharePoint site to SharePoint) they may be tempted to just stick images on the file system and reference them directly. Believe me, I speak from experience here. Make sure that all images are placed in image libraries and referenced from those libraries, otherwise how will you maintain said images? SPD? See #1
10) All pages must be SharePoint aspx pages that can modified in SharePoint. NO HTML pages
There’s really no excuse to have a static html page in SharePoint, even if it’s ‘static’ content. Every page in your SharePoint deployments should be ‘part’ of SharePoint and modifiable in SharePoint. If someone is converting an old non-SharePoint site to SharePoint there may be some temptation to just copy over some of the smaller html files. Sounds great? Quick and easy and it works? How are you going to maintain those pages?? See #1. Again, speaking from experience here.
11) Naming Conventions!
As an extra added bonus, we are throwing in for you today (and today only) an additional standard ABSOLUTELY FREE! Naming Conventions! Make sure you give meaningful names to your Content DBs, App Pools, and Web Apps! Those default values are really pretty worthless and you’ll be glad you took the time to standardize the naming when you need to find something in a hurry.
Conclusion
So… yeah… there you go. This list is by no means exhaustive and it’s possible I left some critical ones off that someone smarter than me will be kind enough to leave in the comments so I can get it added to my list before my boss finds out that I wasn’t smart enough to think about it on my own!
Even if you do not agree with all of these standards for your organization, I hope we can agree that it is important to have these types of standards and have them documented. And one more time, these standards become crucial when you bring in outside help to work on your SharePoint projects. The more consistent your SharePoint environment is, the more maintainable it will be, your admins will be happier, your users will smile at you when you pass them in the hall, and just maybe they’ll stop spreading those nasty rumors about you and the copy machine.
Families in Germany who are facing divers health problem, such persons can buy drugs from the Web without prescription. With the market flooded with divers web-sites selling sundry medicaments, purchasing medicines from th WEB is no longer a trouble for common man. Certain medications are used to treat infections caused by dental abscesses. Of course it isn’t all. If you’re concerned about erectile soundness problem, you probably know about Xenical and Hoodia. Probably every adult knows about Garcinia. (Read more PhentermineXenical). The symptoms of sexual health problems in men turn on impossibility to have an erection sufficient for sexual functioning. Certain medications may add to sex drive difficulties, so its substantial to cooperate with your soundness care professional so that the prescription can be tailored to your needs. Preparatory to taking Levitra or other medicament, speak to your dispenser if you have any allergies. Talk to your health care purveyor for more details. Preparatory to ordering this remedy, tell your doctor if you are allergic to anything.