Do you know who your Site Collections Owners are?

If you run a large farm with thousands of sites it's unlikely that you will know all your site collections owners.

However,  there are at least two things you should know about them.

For example, do they still work in your company, have they changed email etc?

Why is this important?

Here are a few reasons:

• Communication - Downtime, upgrades, new functionality.
• Site lifecycle - If you enabled the "Site use and confirmation" feature in WSS then this is imperative. Sites that are actively used might be accidentally deleted because the emails was sent to a user who has left!
• Charge back - If you have an internal charge model in place it would make sense to have a valid person to send then bill to.

So, what tools do we have available to make sure the site owner information is correct?

How to ensure valid email address.

If you are running MOSS, then this is not a problem. All you have to do is configure the "Profile and Import" settings in your SSP. Once setup, all user profile information will be kept in sync with the information in your AD.
See Technet for more info on how to configure this.

Things get a little trickier if you run WSS only.

You can either purchase a 3rd party tool, like Bamboo Solutions User Profile Sync or code your own solution. What's most cost effective is up for you to decide :)

Checking for invalid users

Unfortunately, there is no built-in functionality in either MOSS or WSS 3.0 to deal with "Dead accounts".

DeliverPoint offers an a "Dead Account" detection and removal feature. I have not personally used the product extensively but I assume it does what it says on the tin.

Also, once again there is the option to code you own solution. Using the classes in System.DirectoryServices namespace would allow you to check if a user account still exist in the Active Directory or not.

To dispose or not dispose, that is the question...

Most SharePoint developers now know the importance of disposing SPSite and SPWeb objects.

Most of this information are not coming from the SDK but are trickling out by Microsoft employees, mainly from Roger Lamb and Stefan Goßner blogs.

Stefan's latest post is a very good and should be required reading

However, the advice and guidance keep changing and being amended.

This means developers need to make sure they are keeping up with the latest information.

For example, at one stage we were told to dispose the SPWeb object after calling SPSite.Owner. Now we should no longer do that.

This is not an ideal since it will require another review of your code.

Also, are these blogs to be viewed as official guidance from Microsoft?

For example, the newly released "Patterns and Guidance" links to Rogers blog.

We are almost two years into the product lifecycle and we are still learning best practice when it comes to writing memory efficient code.

For the next version of SharePoint it would be a lot better for this information to be provided in the SDK from day one.

Also, don't get me wrong!

I think Roger's and Stefan's contributions are fantastic.
Everyone really appreciate the work they are doing.

For the time being, make sure you subscribe to Roger's and Stefan's blogs!

Slides from SUGUK presentation

Really enjoyed presenting at the SharePoint User group in London last week!
I had a great time and I hope the audience got something out of it.

I intend to follow up with a few blog posts where I will talk about some of the topics covered in the presentation.

You can download the presentation here.

Centrally controlling "SharePoint Desinger Contributor Settings"

SharePoint Designer 2007 is a powerful tool used to design and modify SharePoint sites.

Some of you might have seen this recent post from the SharePoint Designer team. It discuss various ways of removing permissions, either at web application or site level to limit what a user can or can't do.

The post also talks about "SharePoint Designer Contributor Settings" and how they are controlled at site level.

I would like to share a way we found to centrally control the contributor settings.

Before doing that it might be useful to understand what happens when contributor settings are turned on.

1. An .htm file is saved to the _contributor_settings folder at root of the site. This file contains the settings specified by the site owner.
   
2. "vti_safeditingconfigurl" is created at the sites property bag (spweb.properties). This property contains the URL for the .htm file created in step one.

The "vti_safeditingconfigurl" property will read by SharePoint designer every time the site is opened.

Knowing that the "vti_safeditingconfigurl" contains the URL gives us an opportunity to manipulate its value!

Our solution uses two components.

1. A contributor settings .htm file (spdsettings.htm) which we store in the "_layouts" folder.
   (The file was created in SharePoint Designer and then exported).
   Storing the file in the "_layouts" folder means that all users have access to the file and that no one can modify it without access to the file system.


2. A hidden feature receiver to set the "vti_safeditingconfigurl" property to "/_layouts/spdsettings.htm" at site creation time. We achieve this by using a Feature Staple.
   (See here and here for more info regarding Feature Stapling.)

Now every time a user creates a site, the "vti_safeditingconfigurl" property will be set and point to the location of our centrally controlled file.

If a site owner tries to disable the contributor settings, they are met a message saying "Couldn't persist Contributor Settings configuration."

This is good news because it means no one can disable our centrally stored contributor settings!

So remember: "vti_safeditingconfigurl" is the key to control SharePoint Designer Contributor settings!