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.
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, you 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.
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, you 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.
Comments
Post a Comment