Should You Depend on Content Deployment?

Content Deployment is a great new feature of MOSS that can be used to create a very nice staging environment. It can also help you with deployment and in maintaining sensible data in your test and development environments.

In short it has a great and promising feature set.

Unfortunately it is a very bug ridden feature.

I made it work and addressed a number of issues in an earlier post. Looking at the number of comments and additional bugs that I encountered later on it seems that this feature is simply broken. And that is not counting all the bugs that you’re likely to encounter when you go into production with this. Another scary post worth a read by Maurice Prather on the issue.

To balance things Stefan Goβner (nice guy by the way, he personally helped me) has made a valiant effort with some great advice on how you can/should use the beast.

Did any of you guys ever take this into production?

I decided not to use it for any of our portal sites as it is simply too uncertain whether or not it will work any given day and if your next code deployment breaks something new. If something goes wrong, how can you ensure that it’s even fixable? Almost anything else that goes wrong can be fixed by some code that performs some changes through the OM, but content deployment is really a big black box.

I would rather code my own – less ambitious – content deployment than rely on a barely tested module that I got no means to fix. Or more probable I would design the platform so I didn’t rely on it.

If you do decide to go with the feature you should a) ensure that you can survive it breaking down for a period (a few months) and b) ensure that you got a premier support license with Microsoft, so they should be able to help you when you hit that rock.


Let’s start some 😉

Apparently Redmond is very much aware of this problem and a large number of their hotfixes addresses various issues with content deployment. And they are probably aware of a whole lot more that we haven’t discovered yet – after all you should expect many if you try to go into production with it.

So, they are working on a large patch (service pack?) that addresses these issues. The bad news is that it is nowhere ready yet. My (educated) guess would be that they will announce it at the SharePoint conference in March in Seattle.

Lock Down Security: My Best Practices (and restoring usability)

I’m sure many of you are need to establish and implement a security matrix on your SharePoint sites. What do you need to do to ensure that your users can actually do the stuff they need to do? After all they are the business they are bringing the actual money home.

This is my first of probably many blog articles about SharePoint security. It is a rather complex and annoying issue that most of us don’t really want to think about too much. Generally most people solve it in one of three ways:

  1. Grant everybody some standard permissions and forget about it
  2. Grant (too) many administrative rights and trust them not to mess it up
  3. Lock down security and accept the loss of usability as many features stop working

I tend to go with either 1 or 3. For my more advanced setup the standard groups (option 1) doesn’t quite cut it and I’m stuck with option 3. That being said I do take pains to ensure that as much functionality as possible continue to work – the very purpose of this article.

I usually think of (and use) SharePoint Groups as roles and permission levels as role definitions. Note that the security setup has changed substantially since WSS 2.0, so you might need to read up on it (see bottom).

Designing the Security Matrix

When you need to implement security you quickly discover that there really is no way to import/export the security definitions and you are stuck with manual configuration. Sorry. It’s on my to-do list of tools that I would like (someone) to build. I know of only one way to “copy” the security setup from one environment to the next and that is a stsadm backup/restore of the site collection. It can be useable once or twice if you plan it right.

So what you need to do is to document and plan it thoroughly before you start. Nobody likes to do the same work 5 times over which you will otherwise end up doing. And sadly you’ll need to involve your client/customer/user and get them to buy in on whatever security you end up implementing. If you are like me you’ll want them to be able to maintain it after the project is delivered and then you need them to understand what you are doing, why and how they should use it in the future.

I prefer to use excel with a simple sheet with the site hierarchy as the first column and subsequent user groups/roles on the next columns. In the cells you simply write something the places where you’ll break the security inheritance and invent some labels that describe what that particular group should be able to do at that particular site. Don’t be too creative and don’t use a 20 letter encoding of the SharePoint permission levels. Use a label and map that to a custom permission level later (client probably don’t care about that).

It almost goes without saying that you should plan for as much inheritance as possible so the spreadsheet should be fairly sparse. If it contains lists or individual list items you should consider other options as that will certainly go awry in a very short time.

Deciding on AD or SharePoint Groups

So should you use SharePoint groups or should you use AD security groups (I’ll skip the discussion of AD group scope here – domain local, universal etc.)? You’ll probably end up with both as there are benefits and tradeoffs with both:

AD Security Group SharePoint Group
Contains both users and other AD security groups Contains both users and other AD security groups, but not other
SharePoint groups
Must be maintained in the AD, usually by IT department and/or IT administrators Permission to maintain groups can be assigned within SharePoint
Can be used (directly) within SharePoint for permissions Can be used for permission assignment (obviously)

And there are many more that I didn’t consider important here. Sharp readers will notice that I omitted server local groups here. Don’t ever use them. They are simply confusing, impossible to maintain and they don’t go well with a multi-server farm.

I usually prefer to have the AD deliver as much as possible, e.g. at least domain membership, probably department membership. I then assign those groups to a number of SharePoint groups that I use as roles and don’t worry too much about those. E.g. if you want to assign every user in the domain reader rights and a few (10%) some additional rights, then 90% of the users will be correctly assigned after adding “Domain Users” to your reader SharePoint group.

One word of warning: If your organization has been very creative in their domain setup and use excessively deep nesting in AD it might not work within SharePoint. It has been seen to happen. If you can assign that group properly to file share on the SharePoint server you should be quite certain that it also works in SharePoint.

The most important missing feature of the SharePoint groups is that they cannot be nested. It is a shame and the consequence is that you might need to add a given user to, say, 4 different SharePoint groups to make everything work. If it requires somebody to grant permissions on individual basis somewhere on the portal chances are that you should rethink your design.

Be sure to write down what is needed to grant a new user access to your portal that can be used as a reference for the SharePoint business owners at a later stage.

Managing Membership

One very helpful tip in managing the memberships of the SharePoint groups is that each group is assigned a owner that can adjust the memberships (by default), but it will also work if you assign a SharePoint group that role.

Go to the edit group page to modify it and set your custom SharePoint administrator group as owner of the group. From that point on your membership handling can be delegated to somebody without excessive rights e.g. farm administrators.

Implementing the Security Matrix

One thing that I’ll always recommend: Don’t use the standard SharePoint permission levels. They are well designed and therefore you should take a copy of them and assign the copy to your groups where you need it. That will enable you to later modify the permission levels in one place (as opposed to going through everywhere you assigned permission to that group) without compromising the integrity of the standard permission levels. Nothing is worse than a Contributor permission that actually grants administrative rights…

Ensure that the right people can administrate various group memberships by making sure who the owner of the SharePoint groups is.

When you implement (click through it) your matrix make extensive use of the “View Group Permission” feature (from settings menu when viewing group memberships, people.aspx). Another thing for my to-do list is to extend this feature to handle users as well – it’s not as hard as it sounds.

In the following I’ll cover some specific quirks that you might need to remember to ensure that your users can still use the site after you did your work (oh, they will resent you for it…)

Making the Galleries Work (Again)

The web part, list and site template galleries might need special permissions (if you try to limit access to the site collection root), to continue to work. To go to the permission setup, go to the actual galleries through Site settings, then gallery settings and finally the permissions.

  • Web Part Template Gallery: You should assign read permissions to this gallery to everybody (their group!) that should be able to add webparts somewhere. Otherwise the Add Web Part popup will be rather empty
  • List Template Gallery: Users that need to create lists from saved list templates obviously needs read access and the people creating the list templates should have contribute/write permissions.
  • Site Template Gallery: Users that need to create sites from the templates require read access. Users creating the site templates need contribute permissions on the gallery as well as the Site permission “Manage Permissions” (available on the permission level settings) on the target site that they want to save

Reuseable content

On a publishing web site, i.e. publishing or collaboration site, there is a list in the site collection root named “Reuseable content”.

If you want the functionality to work on any subsites you need to assign all editors contributor right to the list and all other users read permissions. If some users lack the permissions they simply won’t see that particular item of content on your publishing page. There will be no sign that they do not see the complete page, which tend to be pretty confusing to end users.

Content Types

Sadly there is no list or permission level that governs the customization of content types. You can’t prevent this through permissions if you also require some users to be able to manage your site permissions, i.e. add users.

You will want to prevent “people” (administrators) from changing all the content types that you defined in xml through feature deployment as that will disconnect your content type (see my two posts on that, 1 and 2) from the underlying xml source.

You can mark your content type as either read only or sealed with following tradeoffs

  • Read only: Will prevent accidental changes and allow inherited content types to delete/hide inherited columns. Administrators can actually override this setting if they really want to (but then they are not “in good faith”)
  • Sealed: Will prevent all changes through the GUI, but will also lock child content types so they can only hide inherited columns, not delete them

Both cases will not affect your ability to update the underlying xml files, i.e. it is actually not supported to change them after initial deployment. You can do it, but then you’ll need to update all inherited content types to preserve or restore their “inheritance” (see post). (A proper fix for this is another item on my to-do list)

Master Pages, Page Layouts and Styles

Just maintain the default “Style Readers” group and you should have no problems with these lists. If you do change the style readers group too much you need to ensure that

  • all users can read from the master pages catalog (“/_catalogs/”), otherwise they are completely blocked from your pages
  • all users can read from “/Style Library”

Final Words

I hope that these guidelines will help you a little bit. They helped me, but don’t for a minute consider them to be complete.

There are a number of features that require some special permission here and there if you tighten security on something else. It’s bound to happen and it is tedious and hard to test thoroughly.

Additional Resources

You can find some general information from Microsoft that defines all the basics and provides some guidelines here.

As usual Joel Oleson has something worthwhile to read on the subject.