Geeks With Blogs

News





The SharePoint Hillbilly Fewer Big Words... More Pretty Pictures...

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

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. 

Posted on Thursday, September 10, 2009 2:21 PM | Back to top


Comments on this post: 10 SharePoint Deployment Standards

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Good list! Very helpful guidance. I have been surprised at SharePoint "expert" consultants who violate many of these guidelines. Apparently being able to run SPD qualifies you to be a SharePoint Developer in the same way that running FrontPage made one a Web Programmer (no irony that SPD basically is just a new rev of FP).

Spelling nazi: "very helpful too for development"? Tool?
Left by Todd Williamson on Sep 10, 2009 4:00 PM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Agree for the most part except #2, I think small workflows for simple approvals have their place.
Left by Kunal on Sep 14, 2009 8:51 AM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Hey, regarding point two, and also the other post you have about SPD:

Have you tried using some 3rd party utility? "SPDToolkit.Workflows.Utility" it's a free utility that extracts the SPD workflows into a folder, then you move this folder into another server and paste it, then just like that the workflows are moved, this of course won't make sure the site, components and so on are there, but you can move the production site, develop, then move only the workflow back to production server.

There are some downsides, but this provides a good way to work with SPDs when the user is skeptic to WWF developments (times more than anything).

I would like to know your opinion on the matter, it's always enlightening to cooperate.
Left by Ricardo Irineo on Sep 18, 2009 12:52 PM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
With Kaldeera, a 3rd party workflow designer, you can directly design graphically your process, publish on the server, export and import into diferent environments. If these are identical (structure), Kaldeera solve all site-collection specific ID's of lists, webs, ...
Left by Pau Codina on Sep 23, 2009 9:29 AM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Great Post! It is always a great benefit to us to see how someone else is deploying MOSS! I wish that everyone would write posts like this so that we can learn more about how to deploy for all different size companies.
Left by Cathy Dew on Sep 28, 2009 3:38 PM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Hey Mark,

Well the utility works in command line in which you provide some parameters and it will extract all workflows from the specified server (I assume it works with the credentials it's been running as), from this feature and Workflows folder you can copy any given Workflow folder, which includes everything you see in the SharePoint Designer Workflow folder, then you open the destination new server with SPD, and paste the workflow in the workflows folder of the site, if there is none you can create a simple workflow to get it created, once you paste it you have to open it to associate it with a list and well go through hell if you have many columns (it's associated with ids, if it's not the exact same it will not work).

This of course has its downsides, but provides some help when there is no other way, when dealing with simple scenarios, or when moving a ton of small user-created workflows when the server is being moved.

I'll have to run some test on farm settings to see how multiple WFE would affect this solution, but I think it should work.
Left by Ricardo Irineo on Oct 12, 2009 1:26 PM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Thanks for the info.

What is the best development strategy/approach for SharePoint? Is it (DEV, QA, PROD) approach or just do everything on the production server?
Left by sim on Oct 26, 2010 5:52 AM

# re: 10 SharePoint Deployment Standards
Requesting Gravatar...
Where is the extra bonus Naming Conventions? Please please I need this .. thanks!!!
Left by Rosario Lomeda on Jun 03, 2011 4:38 AM

Your comment:
 (will show your gravatar)


Copyright © Mark Rackley | Powered by: GeeksWithBlogs.net