Wictor Wilén

Microsoft publishes three posters on upgrading to SharePoint 2010

Wictor Wilén — Sun, 18 Oct 2009 17:11:33 PDT

Just hours before the SharePoint Conference 2009 starts in Vegas, and all information will flood out from the conference, blogs and twitter, Microsoft released ~~three~~ four posters that should help you in planning and updating your SharePoint 2007 installation to SharePoint 2010.

Microsoft SharePoint Server 2010 Upgrade Approaches (added since original posting)
Visually describes the different upgrade approaches

Microsoft SharePoint Server 2010 Upgrade Planning
Takes you through how to upgrade hardware and software on your servers. Shows the available upgrade paths.

Microsoft SharePoint Server 2010 — Test Your Upgrade Process
How to set up a test farm and then install your customizations, copy data and review the results.

Microsoft SharePoint Server 2010 — Services Upgrade
Perhaps the most exciting poster of them all with information on how to do an in-place upgrade of the Shared Service Providers in 2007 and how these services work in 2010.

They are all a good read and should be printed by all SharePoint admins out there...

Last Service Pack for PerformancePoint Server 2007 is out

Wictor Wilén — Thu, 15 Oct 2009 07:25:30 PDT

The long awaited service pack for PerformancePoint Server 2007 is now released to the web - Service Pack 3. This is the last service pack for PerformancePoint Server since the PerformancePoint Server bits will from next week be turned into PerformancePoint Services in SharePoint 2010.

Service Pack 3 is the last update to the standalone version of PerformancePoint, which was announced in January this year when Microsoft changed their BI strategy. After this update Microsoft will not invest any further into the 2007 version and as you hopefully are aware of - the Planning module will not exist in the upcoming 2010 version. The Planning module is instead offered as source code - now called the Financial Planning Accelerator, so that you can safely still use any investments in the Planning Module.

You can grab the bits here: 32-bit and 64-bit. Documentation on the different upgrade scenarios can be found on Technet.

So far the KB (975250) article on what's changed and updated is not live. Some things have popped up on Technet though, such as a updated importsecurity command.

Useful Delegate Controls in Windows SharePoint Services 3.0

Wictor Wilén — Wed, 07 Oct 2009 05:18:50 PDT

Delegate Controls in SharePoint is a blessing when you are customizing the features and interface of SharePoint. The Delegate Controls are areas in the out-of-the-box SharePoint pages where you are allowed to inject your own controls. This is heavily used by Microsoft Office SharePoint Server 2007, which essentially is a set of features on top of Windows SharePoint Services. For example the standard WSS user information page redirects to the MOSS My Site, this redirection is done by inserting a delegate control into a specific delegate control on the userdisp.aspx page. This nifty delegate control can be used in a WSS solution when you want to create a custom profile page, without modifying any of the OOB files and easily reverts to it's original state when you deactivate the feature.

How to export and reuse the Data View Web Part

Wictor Wilén — Fri, 02 Oct 2009 20:07:04 PDT

Inspired by the latest SharePoint PodShow topic; The SharePoint Data View Web Part-Episode 31 and Laura Rogers post on building a permissions dashboard I just had to write this post. In the last paragraph Laura quickly mentions how you can reuse the created Data View Web Part. I think this is really important to know how to export and import this Web Part. What I don't want people to do is to fire up SharePoint Designer and create these Data View Web Parts in the production environment so that the pages get's unghosted or customized. Also when you are working with solutions packages and features to deploy your applications in environments it's necessary to know how to do this.

Exporting

Once you have created and finalized your Data View Web Part in your development environment or sandbox, then you can export your customizations. This is the same for all kinds of Web Parts, as long as they allow exporting. When you export a Web Part through the web interface you will get a .webpart file (read earlier published post on this), containing all the properties and metadata specified for the Web Part.

Just open the Web Part menu on the Web Part and select Export... to export the Web Part. You will be prompted for a location to save the file.

Once you saved it you will have a nnn.webpart file on your disk, which essentially is an XML file with the metadata.

Note: Your exported Web Part will contain the exact properties as you specified in your original location. For example if you connected to it to a list this list id will not be present in the location where you import it. So before importing it you might have to change some values in the .webpart file or at least edit the properties of the Web Part after uploading it.

Importing to the Web Part Gallery

If you have created a Data View Web Part that you will reuse many times throughout a Site Collection it might be worth uploading it to the Web Part Gallery. Just go to the Site Settings and then the Web Part Gallery and select Upload and upload your .webpart file. After this your Web Part is available for all authors to use.

Importing to a page

Importing the Web Part is not that difficult, though it can be hard to find where to do it. To import the Web Part, go to the page where you want to insert it and edit the page and then choose to add a new Web Part. Then you have to select Advanced Web Part gallery options, located in the lower right corner. When the page is re-loaded click on the Browse header and choose Import.

After that you can click on Browse to select your .webpart file and finally click Upload. Once the upload is done the Web Part will appear and you can drag and drop it onto your Web Part page.

Once it is on the page you may have to edit the properties of the Data View Web Part. You might have to change the data sources, if you for instance configured your Data View Web Part to work with a certain Site id or a List id.

Using the Web Part in features

You can also reuse this exported .webpart file in your SharePoint features and have them added to the Web Part gallery when activating the feature.

Another scenario, which I've used to build dashboards and dashboard sites is that you use the SPLimitedWebPartManager to create dashboards on feature activations or certain events. The SPLimitedWebPartManager has an ImportWebPart method that takes an XmlReader as input, which essentially is your .webpart file.

I hope you got something interesting out of this and if you haven't listened to the SharePoint PodShow about the Data View Web Part - do that immediately and understand the power of it!

Time for new adventures

Wictor Wilén — Thu, 01 Oct 2009 07:15:23 PDT

I'm glad and proud to tell you all about that next month I will start a new job. I will start as a SharePoint Architect at Connecta. This is a fantastic opportunity for me and it will let me work with some of the finest SharePoint minds and developers here in Sweden as well as some really awesome customers.

I've been working with basically the same company now since 2000, when I and two good friends founded it, iBizkit. We all came from consultancy firms working with WCM, portals and intranet solutions and had a dream of making a really good semi-product for these kind of solutions. And we did! In 2001 we integrated our product with the first version of SharePoint. We continued this integration in the upcoming versions of SharePoint, but have since the release of SharePoint 2007 focused more and more on the SharePoint platform, and I have personally lived in that world for the latest years. About two years ago, we sold the company to Pdb DataSystem, a natural step to expand and evolve the business.

During the last years I have been headhunted (or is headhaunted?) numerous times and finally I/we found a perfect match.

So in November I will be joining the Connecta forces and have 100% focus on SharePoint and especially the upcoming SharePoint 2010. This will allow me to grow and evolve as a SharePoint architect and developer, which is what I thrive on.

The only downside with this is that I won't be attending the (awesome, fantastic and once-in-a-life-time) SharePoint Conference 2009 in Las Vegas. To all you SharePointers - have a good time and I'll follow the tweets and blogs from over here! I'll even drink a pint while reading them. I hope to join you on upcoming conferences...

But if you're anxious to meet up, then head on over to the SharePoint and Exchange Forum in Sweden (SEF09) and come listen to me talk about PerformancePoint Services 2010 or come visit the free SharePoint 2010 overview event, organized by AddSkills and Connecta, where I'll show you some cool stuff that can be done with the ECM features in SharePoint 2010.

Until next time...

Avoiding Xml Based SharePoint Features - Use The API Way

Wictor Wilén — Wed, 23 Sep 2009 07:11:27 PDT

Developing solutions and features for SharePoint is a nightmare for all beginners, and even for the experienced SharePoint developers. If you ever have had the opportunity to create a SharePoint solution you most probably have had to make a lot of hacking in a bunch of XML files, just to build a simple feature. This is the way you have to do it, and the way taught by tutors and Microsoft, when using it with Visual Studio and no add-ins. This is the way it was, and has been, for most of us SharePoint programmers since the beta releases of SharePoint version 3.

Nowadays you have several tools that help you out; such as Visual Studio Extensions for WSS, WSPBuilder, STSDev and more. Some have a user interface that helps you a lot; such as VSeWSS and SPVisualDev and some does not help much there; such as STSDev. But whatever tool you use you will find that you are digging yourself deep into hacking those Xml files. Unfortunately the documentation is quite poor, but we have the fantastic SharePoint bloggers and MVPs that made their code and samples available through ~~Google~~, sorry Bing.

Lots of XML

For example when you have a site and you would like to create a custom list, you will have to define a Content Type, a list schema, a list template and a list instance and then you have a feature manifest and a solution manifest - that counts to at least five different XML files and a few different schemas. This is an awful amount of job in the beginning and I think in some cases it's a waste of time, especially if it's a custom list that only will be used once. Then we have the thing when we want to update the list or content type when it's deployed...a whole lotta XML in combination with compiled code (for example when updating Content Types)!

I have in my recent projects abandoned the XML way (declarative/CAML) in favor of the The API way (Object Model).

The API Way

Almost everything that these XML files can do can be done using compiled .NET code and utilizing the SharePoint API's. Take the example above - those XML files can be replaced with a few lines of C# code. Create a Content Type, create a List, add a Content Type to the List. There are still few XML files left; the feature and solution manifests; but those two are easy to handle.

All you have to do is put this initialization and creation code in the Feature Receivers of the Features.

Upgrading and developing these features using the API way are also very easy and straightforward. I think it also fits better into a TDD kind of development way. If you have a list that is created through the Feature Receiver and you find that you need to add a field to that list, I just de-activates and activates that feature. This is done by a set of extension I use to create fields if they don't exist, in Lists or Content Types.

API way - Pros

Using the API way has several benefits:

As a beginner, but experienced .NET developer, it might be easier to start working with the SharePoint API
Mistakes are easier discovered:
- You have to deploy and test your feature to find small mistakes in the XML
- Some errors are detected during compilation phases
Debugging - yea try that with XML based features!
Upgrading experience is far much better (de-activate and activate)
Development time is most often faster, just re-register the assembly
Easy to staple the feature, and it's receiver, to Site Defintions
Testing, and TDD, is possible even outside of the SharePoint scope

API way - Cons

Of course there are cons of using the API way. First of all there are some things that you can't do

Create List Templates - for reusable lists, i.e. lists available for the end-user to create
Create Site Definitions
Create Custom Actions
Configure Delegate Controls

The cons with the API way are for example:

Requires installation of assemblies in the GAC
- This is in many installations prohibited due to the fact that it requires that you run in full trust.
I find it easier in some situations to re-use configurations created in XML files
When using XML definitions you can specify ID's of Content Types etc which are required in many situations, for example when you are re-using your Content Type in many farms or Site Collections.
Requires that you really understand how the provisioning works in SharePoint
Requires that you take care of the clean-up when deactivating

Most pros and cons are of course a personal consideration, but as I said, I almost every time nowadays use the API way for my features.

How do you develop your Features, Lists and Content Types?

Basically I try to have a clean and simple Site Definition and then staple my features and it's receivers onto that Site Definition. It comes down to very little XML and some compiled code - very maintainable.

ChartPart 2.0 for SharePoint - Release To Web

Wictor Wilén — Sun, 13 Sep 2009 04:24:38 PDT

Finally I’ve found the time to make the last work on ChartPart 2.0 for SharePoint. I have been working on and off on this release for quite some time – but now it’s here!

ChartPart 2.0 for SharePoint is a Web Part that allows you to instantly create charts based on your existing SharePoint lists. You can make columns, bars, pies and even 3D charts.

ChartPart version 1.0 was released last year and have had up until now close to 10.000 downloads, which I’m very proud of. I’ve received awesome feedback on the Codeplex site, on Twitter, my blog and when I met people and told them that I was the one who made it.

ChartPart 2.0 has been in beta/RC for quite some time and has had about 4.000 downloads, which also is awesome! People have been asking me when is it due, when is it ready…and now it’s done! It’s uploaded and free to download. You can even get the source and make your own implementation.

New Features

ChartPart 2.0 contains a number of new features such as; better 3D charts, more customization etc. But the most interesting two things are 1) you don’t have to install it in the GAC (which several people asked med about) and 2) you can connect the ChartPart to a list view and filter the graph.

For a full list of features just head on over to the ChartPart 2.0 website on Codeplex.

Another interesting feature that is new in 2.0 is that you can edit the .webpart files and set a Lock Down Mode. This allows you to restrict your users from editing certain properties, such as colors, graph types etc. This is one feature that I hope can make the ChartPart 2.0 be used in larger companies.

I’d like to thank all the thousands of people who has helped me out by downloading ChartPart 1.0 and those who has submitted issues on Codeplex. A special thanks to those who helped me with the translation into other languages; Arash Aghajani, Frank, Alexander Bautz, Anders Dissing..

What are you waiting for, go download it…

SharePoint User Group meeting 2009-09-08 recap

Wictor Wilén — Tue, 08 Sep 2009 18:59:18 PDT

Last night we had a SharePoint User Group Meeting here in Stockholm, Sweden. It was a great evening with a lot of attendees, thank you all for showing up. It's always fun to see new and old faces, sorry I didn't have time to talk so much with you (due to my VM's crashing just before my demos…).

First, a big thanks to KnowIT and Jonas who provided us with a great place to host the meeting and some good food and beer!

Two sessions were on the agenda; PowerShell and PerformancePoint.

Niklas Goude started the meeting with some SharePoint and PowerShell love. Great session and demo. Really looking forward to see his, and Mattias Karlssons, book project come to life. You can find Niklas awesome PowerShell scripts here and Mattias automagic create your farm in Excel script here.

The second session was held by yours truly, and I did a brief introduction to PerformancePoint 2007 with some demos on how to create dashboards and publish it to SharePoint. I'm thinking about writing up a post on the last "Dangerous Lists" demo, would you like that? You can find my presentation here. And here are the links that I referred to regarding PerformancePoint 2007 and Microsoft BI.

And if you would like to know some more on what will happen with PerformancePoint in the upcoming 2010 release, please attend the SharePoint & Exchange Forum 2009 and my session on PerformancePoint Services 2010, that will take place in Stockholm in November.

New Permission Reporting Solution in SharePoint Administration Toolkit

Wictor Wilén — Tue, 01 Sep 2009 17:03:12 PDT

The latest version, 4.0, of the great SharePoint Administration Toolkit has been released, read all about it in the post by the SharePoint Team. It contains a lot of interesting and great stuff that you could use for everyday usage.

One new part of the Administration Toolkit is a SharePoint solution called Permission Reporting Solution. This is a solution package that hugely improves the permissions management of your Site Collections and Sites in SharePoint.

Note

The Administration Toolkit was first released about a week ago. It was quickly pulled back, since it contained some erroneous files. It's not currently available from the download site but these links will get you to it; x86 and x64.

Note: I actually started out writing this post while trying to install the permissions reporting solution but eventually found out that the DLL that was released was not signed properly and couldn't be installed into the GAC. My guess is that's why they pulled the release back.

Prerequisites

Before installing the PermissionReporting solution you have to have upgraded your farm to at least the April 09 Cumulative Update and have a version that is equal or higher than 6504.

Installation

After installing the SharePoint Administration Toolkit you have to install the WSP package like this:

stsadm.exe –o addsolution –filename [Full path]PermissionReporting.wsp
stsadm.exe –o deploysolution –name PermissionReporting.wsp –immediate -allowgacdeployment 
stsadm.exe –o activatefeature –name PermissionReporting

The PermissionReporting.wsp is normally found in the c:\Program Files\Microsoft\SPAdministrationToolkit\PermissionReporting\ directory.

I also had to run this command to get it working:

stsadm.exe -o copyappbincontent

How to use it

When you go to Site Settings on a site you will normally find three options under Users and Permissions.

After activating the PermissionReporting feature, on the farm, you have a set of new options.

It will also add new functions to lists and list items:

Check Effective Permissions

The Check Effective Permissions is a really nice feature that allows you to check what are the effective permissions for a specific user on a list, list item or a site.

This is how it looks like when I check the effective permissions for a specific user on a document in a document library:

This user is member of the Visitors group and has read permissions but has been given contribute permissions directly on the object. Handy right?

Compare Permission Sets

When you are working out some permissions issues the Compare Permissions Sets feature is great. It's simply a tree view of your lists and sites in which you can see exactly what permissions are set on a site or a list.

Broken Inheritance Report

The Broken Inheritance Report feature is a report job that every 20 minutes creates XML report files of broken sites in the site collection.

The GrpMembership.xml file shows you what groups users are members of, Rights.xml shows you the rights set for your site collection and Permissions.xml shows you where permission inheritance has been broken and what permissions are set on those objects.

All these XML files can be opened in Excel for easier reading.

With SharePoint 2010 around the corner, we can hope that these features are there from start and we don't have to wait for three years before handy features like this appears :-)

Using custom authentication provider users in SharePoint Timer Jobs

Wictor Wilén — Tue, 01 Sep 2009 00:54:52 PDT

Today I stumbled upon Yet Another SharePoint Problem (YASP) with a custom timer job. The custom timer job is supposed to synchronize some user information between site collections (on a WSS 3.0 installation). In some cases the timer job has to add users to site collections. Sounds like a no-brainer, right!

The problem is that we are using this installation as an internet facing site and the external users are stored in AD LDS (Active Directory Lightweight Directory Services, formerly known as ADAM) and our own custom authentication provider.

When the timer job was running it found users in one site collection and could not add them to the other site collections, using EnsureUser(). It just threw an exception and stated that it could not locate the user.

We made sure we had the right privileges, that the timer service was running under correct account etc. Finally we hooked up the debugger and set some breakpoints in our custom authentication provider to see where it failed when it tried to resolve the users. But the Visual Studio debugger never loaded our provider assembly!

Then it struck me; how would the OWSTimer.exe know what assembly our custom authentication provider is located in, in Central Administration you only specify the name/prefix of the forms authentication provider. The definition for the custom authentication provider is only specified in the web.config of our web application.

So we added a configuration file to the OWSTimer.exe, called OWSTimer.exe.config and specified the authentication provider, see below. Then after a restart of the service, everything worked like a charm.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
    <membership defaultProvider="TODO">
      <providers>
        <!-- Add providers here -->
      </providers>
    </membership>
  </system.web>
</configuration>

Everyday with SharePoint gives you new obstacles…

Web Parts Connections - Introduction

Wictor Wilén — Wed, 26 Aug 2009 05:35:40 PDT

This is the first post in a series on Web Parts Connections. This spring I had a series on Web Part Properties that I think was very successful, they got some good comments and feedback and they get a lot of hits from search engines. Please help me out and evolve this new series of posts with some feedback and questions.

What is Web Parts Connections?

Web Parts Connections allows you to connect the Web Part server controls so that they can exchange information. Web Parts can either be a consumer and/or a provider. Once you connect a consumer with a provider the consumer starts receiving data from the provider, all this is done on the server side. Web Parts can be constructed in such way that it can have several consumer and provider connection-points, i.e.it can consume or provide information from several different sources. A provider connection-point can have several consumers but a consumer connection-point can have only one provider.

The image, to the right, illustrates in the top; one Web Part connected to another. The middle sample shows how one provider Web Part is connected to two consumer Web Parts. The sample in the bottom shows a consumer Web Part that have two consumer end-points that are connected to two different provider Web Parts.

Note: Web Parts Connections are a part of the ASP.NET 2.0 framework

Why Connecting Web Parts?

When you connect Web Parts you enhance the experience for the user. You can for example have one Web Part containing a list of items and let that one act as a provider and then have a consumer Web Part that shows detailed information of the item selected in the provider Web Parts.

In SharePoint most of the default Web Parts are either consumers or providers. For example, with some easy clicks in the interface you can connect lists and make one a consumer and the other provider.

The image above shows two custom lists that are connected. The Regions list contains the names of the regions, used in the Sales list. With this simple action we have built a Filter Web Part to filter our Sales list. More about Filter Web Parts later on in the series. The left image shows how you make the actual connection and the image to the right shows you how you can filter the Sales list using the radio buttons on the Regions list.

I've been working a lot building dashboards and applications for BI-solutions and similar. Using connected Web Parts have both made the end-user experience a whole lot better (and more good looking) as well as the development of the dashboards.

This was an introduction to Web Parts Connections, the next part will be up in a couple of days.

Until next time.

SharePoint Saturday Copenhagen - Thank you!

Wictor Wilén — Sat, 22 Aug 2009 21:39:01 PDT

SharePoint Saturday Copenhagen is over after an awesome Saturday in Copenhagen. Thank you all organizers, attendees, speakers and sponsors, I had a blast. I will definitely attend more SharePoint Saturdays when I can. These kind of events really are special; everyone attending are there because they really love working with SharePoint, on a Saturday, when the sun is shining outside, for free…

You can find my presentation SharePoint Online and Windows Azure - better together here and the solution that I used for the demo here.

Until next time…

Fix the SharePoint DCOM 10016 error on Windows Server 2008 R2

Wictor Wilén — Mon, 17 Aug 2009 16:52:24 PDT

If you have been installing SharePoint you have probably also seen and fixed the DCOM 10016 error. This error occurs in the event log when the SharePoint service accounts doesn't have the necessary permissions (Local Activation to the IIS WAMREG admin service). Your farm will still function, but your event log will be cluttered.

On a Windows Server 2003 or Windows Server 2008 machine you would just fire up the dcomcnfg utility (with elevated privileges) and enable Local Activation for your domain account.

But for Windows Server 2008 R2 (and Windows 7, since they share the same core) you cannot do this, the property dialog is all disabled due to permission restrictions. It doesn't matter if you are logged in as an administrator or using elevated privileges. The change is probably due to some new security improvements.

The reason for it being disabled is that this dialog is mapped to a key in the registry which the Trusted Installer is owner of and everyone else only has read permissions. The key used by the IIS WAMREG admin is:

HKEY_CLASSES_ROOT\AppID\{61738644-F196-11D0-9953-00C04FD919C1}

Image on the left shows the default permissions for Windows Server 2008 R2 and on the right the default settings for Windows Server 2008.

To be able to change the Launch and Activation Permissions with dcomcnfg you have to change the ownership if this key. Start the registry editor (regedit), find the key, click Advanced in the Permissions dialog of this key and select the Owner tab. Now change the owner of the key to the administrators group for example, then set full control to the administrators group. Make sure not to change the permissions for the TrustedInstaller.

Now you have to restart the dcomcnfg application and once find the IIS WAMREG application and then set the Launch and Activation settings that you need to get rid of the DCOM 10016 error.

Good luck!

WARNING: Changing the registry may seriously damage your server. All is on your own risk!

SharePoint Saturday Copenhagen - I'll be there!

Wictor Wilén — Wed, 05 Aug 2009 18:01:04 PDT

SharePoint Saturday is a free informational and educational event that has been held over-there in US several times with a huge success the last year and it is now coming to Europe and Copenhagen, Denmark to be more specific. A SharePoint Saturday is an event for anyone interested in SharePoint and who like to meet similar-minded people and listen to SharePoint professionals and celebrities.

I'm going to be there - it will be a blast! I will do a presentation called SharePoint Online and Windows Azure - better together! And I will of course listen to all the other really cool people showing up such as SharePoint MVP's and gurus.

If you would like to come, did I mention it's free, then head on over to http://www.sharepointsaturday.org/copenhagen/ and register yourself! I look forward to meeting you all!

Use the LayoutsPageBase class when creating SharePoint Application Pages

Wictor Wilén — Thu, 23 Jul 2009 20:30:25 PDT

In most custom SharePoint solution projects you will have to create your own Application Pages, Web Part Pages or other ASP.NET pages to fulfill your requirements. If you are coming from the ASP.NET world you are pretty used to building web forms and similar .aspx pages. Your pages will most of the times then be derived from the System.Web.UI.Page class, but when working with SharePoint you should not use this class as a base.

Instead you should always use one of the following base classes provided in the Microsoft SharePoint APIs.

LayoutsPageBase class

The LayoutsPageBase (in Microsoft.SharePoint.WebControls) class is the most common class to derive application pages from. This is a very basic class but makes your life a whole lot easier in the SharePoint world.

Pages derived from this class should always reside in the _layouts folder. These pages are called Application Pages (or _layouts pages) and are allowed to contain custom code, compared to Content Pages which reside in SharePoint (such as Web Part Pages). These pages cannot contain customizable Web Parts or Web Part Zones. Creating Content Pages is another story.

The advantages with using the LayoutsPageBase as your base class is that you can easily access the current SharePoint Site or Site Collection with the built-in properties and control the security of the application page.

Access the SharePoint objects

With the LayoutsPageBase class you can use the built-in properties for the Site and Web to access the current Site Collection or Site (both these properties are derived from the UnsecuredLayoutsPageBase class, see below) or use the SPContext class to access the current site and web.

Stop long running operations

You have most certainly created some pages that creates reports or similar that may take a long time to generate and consumes server resources. Some times it takes so long that the user shut downs the web browser and go drink a cup of coffee instead. If you have those kind of pages you should use the StopRequestIfClientIsNotValid method. This method ends the request if the client is no longer connected to the page and saves you of some CPU cycles. On the other hand, if you have these kind of pages - think over and use the SPLongOperation class to inform the user that it will take a while.

The page will also automatically call this method in several of the page events, such as OnLoad and Render.

Security in the Application Page

The LayoutsPageBase class contains a virtual property called RightsRequired, this property can be used to programatically set which rights (on the current Site) that are required to use the application page. By default the rights are checked at the end of the OnLoadComplete, but using the RightsCheckModes property you can disable the check or perform it in OnPreInit instead.

There are also a property called RequireSiteAdministrator that can be overridden to make sure that the user is site administrator.

Exit from the Application Page

If you are creating an application page the uses the ButtonSection control template you will have a Cancel button. The target of this Cancel button is controlled using the PageToRedirectOnCancel property. Just override the property and return a string containing the target of your cancel page.

UnsecuredLayoutsPageBase class

The LayoutsPageBase class derives from the UnsecuredLayoutsPageBase class, which derives from the System.Web.UI.Page. Only derive from this one directly if you need anonymous and non-authenticated users to access your application page. Most of the methods and properties used in the LayoutsPageBase class comes from this class.

For example the Login Page uses this one as a base.

This was a quick post to get you started with creating custom application pages in SharePoint. So what are you waiting for...

Creating SharePoint 2010 workflows with Visio 2010

Wictor Wilén — Mon, 20 Jul 2009 00:46:07 PDT

The new Office 2010 clients have been released as a Technical Preview and I'm fortunate to get my hands on them and free to talk about them. The new clients are awesome!

Visio is one of the applications from the Office suite that I use on a daily basis to design, model and draw diagrams, workflows and solutions. Visio 2010 has gotten a really nice facelift and a whole new set of features. The Ribbon has been one of the things I really missed in the 2007 release and the SharePoint integration, that can be seen in the Sneak Peak, looks awesome!

Building workflows for SharePoint has mainly been done using either SharePoint Designer 2007 (dull and not reusable) or Visual Studio (complex). SharePoint 2010 will use the new Windows Workflow Foundation (4.0) and rumors say that SharePoint Designer 2010 and Visual Studio 2010 has even better support for building workflows.

Visio 2010 comes with a brand new template; Microsoft SharePoint Workflow. Using this template you can design your workflow and then export it. This exported file can then be imported to SharePoint Designer 2010 or Visual Studio 2010 (just a guess - Visual Studio 2010 with SharePoint 2010 dev tools is not yet publically available). Another guess is that you can export the workflows from SharePoint Designer 2010 and import them into Visio for better visualization or documentation of the workflow.

You can design your SharePoint workflow just as you would design any other workflow using Visio, drag and drop and make a nice layout. This is great when you are making a specification for your SharePoint solution. Far better is that the ones responsible for the actual workflow or processes can design the workflows for you without knowing a bit about SharePoint, just some basic knowledge of Visio.

Once you're done with your workflow you can validate it, so that you have not missed any branches or any mandatory information. Then you save it as a Visio or file or better export it as a Visio Workflow Interchange (.vwi file).

In Visio you can only make the actual design of the workflow, not the configuration which is done in SharePoint Designer 2010.

The .vwi file is a zip compressed file containing the XOML files (XAML files for workflows) and some Visio information. This XOML file can of course be opened in Visual Studio for editing, you just require the SharePoint 2010 dlls :-)

What I have not been able to test yet is the import in SharePoint Designer 2010, since it requires SharePoint 2010.

I will start using it immediately for designing workflows!

Use Windows Azure as your SharePoint Records Center

Wictor Wilén — Thu, 09 Jul 2009 17:23:30 PDT

Introduction

Microsoft SharePoint contains functionality for Records Management, which essentially is a storage for documents that you would like to store and manage in a separate records center to meet certain legal or other requirements or just to make backups of certain document revisions. To be able to create a Records Center you need to have Microsoft Office SharePoint Server 2007 (MOSS). On the other hand you only need Windows SharePoint Services 3.0 (WSS) to send documents to the Records Center.

You configure the Records Center connection in the Central Administration. When connecting to the Records Center all you do is specify a Url to a web service and a name. The Url points to a special MOSS web service called OfficialFile.asmx (http://server/_vti_bin/OfficialFile.asmx). Your receiving Records Center server does not have to be in the same farm as from where you send the document (and it should probably not be either). Another thing is that the receiving Records Center does not even have to be a SharePoint server. It's just a web service and we can implement it anywhere we like.

I thought why not implement it using the Windows Azure technologies? This would be a great solution when you do not want to invest in either MOSS or a new MOSS farm, when you really want your important documents to be stored on a completely different physical location etc.

Requirements

For this exercise I have used Visual Studio 2008, Windows Azure SDK and the Windows Azure Visual Studio plugin. You also need to have access tokens/claims to the Windows Azure beta.

The Mission

To create our Cloud Records Center we need to create an Azure Web Role, which hosts the Records Management web service and a page to show our documents and some other logic. Our Records Center should also be able to handle some very basic record routing and metadata.

Note: the complete sample code can be downloaded here.

Create the Web Role project

First of all we need to fire up Visual Studio 2008 with the plugins as above and create a new Web Cloud Service called AzureRecordsCenter.

Create the data storage

Without digging to deep into the Windows Azure table and blob storage I just briefly describe how the storage is implemented. This sample has two tables; one for storing the routings and one to store information about the submitted documents. The blob storage is used to store the actual documents. The Windows Azure SDK contains a sample StorageClient which makes it really easy to work with the data, and this sample is used as a reference in the application.

I've created two classes to represent the tables; DocumentEntity and RecordRoutingEntity and a class that handles the actual data services called DataContext. The data classes has a primary key property combination; PartitionKey and RowKey (inherited from TableStorageEntity from the StorageClient sample) - I only use the PartitionKey and RowKey has a static value.

The RecordRoutingEntity is used to store the name and optional description of the record routings and the DocumentEntity contains some information about the documents and a reference (Guid) to the name of the blob.

Take a look at the code for more information.

To be able to add routings the default.aspx was modified and I also added a Setup.aspx page which creates the tables in the Windows Azure storage.

The OfficialFile.asmx web service

To be able to create our own Cloud Records Center we have to implement the same web service as MOSS offers - the OfficialFile.asmx. The .NET Framework SDK contains a great tool, wsdl.exe, for converting a WSDL from a web service into a server side interface. Use the Url to the web service from any of your MOSS servers.

   1: wsdl /out:IRecordsRepositorySoap.cs /n:AzureRecordsCenter_WebRole /serverinterface 
http://xxxxx/_vti_bin/OfficialFile.asmx?WSDL

This will generate an IRecordsRepositorySoap.cs file containing the correct interface for the records management web service. So we create a new Web Service in our project, called OfficialFile.asmx, add our generated interface file to the solution and then we let this new web service implement the interface we extracted from the WSDL. The namespace for the web service is also changed into the same namespace as the official OfficialFile.asmx use.

   1: [WebService(Namespace = "http://schemas.microsoft.com/sharepoint/soap/recordsrepository/")]

   2: [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

   3: [System.ComponentModel.ToolboxItem(false)]

   4: public class OfficialFile : System.Web.Services.WebService, IRecordsRepositorySoap

   5: {

   6: ...

   7: }

This interface now contains four methods:

SubmitFile - the method which retrieves the submitted documents
GetServerInfo - should return info about the implementation
GetRecordRoutingCollection - returns all record routing types
GetRecordRouting - returns info about a specified record routing

The three latter are pretty straight forward and the SubmitFile method receives the file, the route to use (the name of the Content Type) and all metadata of the file. First it creates the document entry in the Document table and the uploads the blob. My sample also validates that there is a valid route and otherwise returns an error.

Put it in the cloud

To get it all to work you have to create a new Hosted Service in the Windows Azure Developers Portal and then you have to create a Storage Account. Modify the Service Configuration of your cloud service to match your storage account.

Build the solution and use the Publish function from Visual Studio to publish your application to the cloud and put it in either the Staging or Production environment and wait for it to start (this may take a while).

Swapping between staging and production has been quite troublesome and results in an error or timeout quite often for me the last few days.

Browse to your cloud web application and add a route or two. The name of the route should correspond to the name of your Content Types.

In the image above I have added a new Route called Document.

Configure SharePoint

To be able to send the documents from SharePoint to our cloud records center, all we have to do is go to Central Administration of your SharePoint farm and configure the Records Center Connection, found under Application Management/External Service Connections/Records Center. Enter the Url of your hosted service and append the OfficialFile.asmx path (http://nnnn.cloudapp.net/OfficialFile.asmx) and enter a name for your Records Center connection.

Record it!

To try it out, just head on over to a Document Library and add a document and the open up the list item menu and choose Send To - Azure Records Center (in my case).

Wait for the file to be uploaded to your Cloud Records Center.

Then head back to your Azure web application and load the default page. You should now be able to see the document there and click on the link to bring it up.

If you upload a document of a content type that is not registered as a route, then you should get an error.

Conclusions

Now you know how to build a simple Records Center utilizing Windows Azure and known .NET techniques. This is in no way limited to Windows Azure, you can host it or similar solutions anywhere on any platform whenever you want.

If you want to have a Records Center and don't want to buy a MOSS license, then this solution can be a good fit.

Disclaimer

The provided code is in no way ready for production. It has no good exception handling nor security checks. It is provided as a sample for you to look at if you need to get started with either building a Records Center or just want to learn something about Windows Azure.

Have a nice summer!

SharePoint Virtualization Survey - results

Wictor Wilén — Sun, 21 Jun 2009 19:31:59 PDT

About two months ago I tried to reach out to the SharePoint community with a small survey on how Virtualization is used with SharePoint. The survey was primarily for my own interest to benchmark what others are doing, but I also thought that I should share this with everyone. SharePoint and Virtualization is an interesting piece of discussion; some despise it and some love it. For more information on SharePoint and virtualization read this great article from SharePointMagazine.net.

And now the results

All but one answering this survey said that they were using virtualization in their SharePoint environment. Not that surprising - I guess that if you don't virtualize then you do not even bother to look at the survey.

Virtualization technology

Since this survey did not specify if it was for production, test, staging or development the answers on what virtualization technology that was used was quite spread. Microsoft Hyper-V and VMWare ESX Server was the two products that most survey participants used. Not surprisingly was Microsoft Virtual PC right behind those two.

What is virtualized?

Almost everyone (95.7%) is virtualizing their development environment and half (50%) of the survey participants is virtualizing their production environment. This was a bit higher than I expected.

But what is virtualized then? The Web Front End was the clear "winner" with the Query service as a runner up. A quite high number of respondents answered that they were virtualizing the database role (73,9%) but only half of them could really recommend it (37,2%). The Excel Services role was something that about half of the participants virtualized (47,8%) and recommended for virtualiztion (44,2%).

The majority did not recommend virtualizing the database role (80%) nor the Index role (43,3%).

Satisfaction!

Almost everyone was very satisfied (40%) or satisfied (53%) with virtualizing their SharePoint environments and only a few were dissatisfied (7%). 98% of the respondents do recommend virtualizing SharePoint.

Why?

One thing that I really wanted to find out was why SharePoint is virtualized and here are what the survey participants thought:

	Agrees	Neutral	Does not agree
Lower hardware cost	82%	14%	5%
Lower license costs	21%	47%	33%
Lower maintenance costs	62%	29%	9%
Better performance	7%	52%	40%
Improves scalability	64%	24%	12%
Improved security	27%	56%	17%
Improved redundancy	60%	36%	5%
Safe backup	55%	31%	14%
Simplifies development	86%	14%	0%
Simplifies deployment	73%	20%	7%
Positive effect on the environment	74%	26%	0%

Simplified development and lower hardware costs was the two ones that was quite expected. When looking at the license costs most people were neutral or thought that the license costs were higher with virtualization, probably due to the fact that you might need more (virtual) servers to have the same performance (only 7% thought performance was better with virtualization).

The numbers speaks for themselves and I do like that 74% also thinks that this has a positive effect on the environment.

Any other comments on this survey, pleas post a comment below.

Have a nice summer

70-630 passed! Do you really call this a certification!

Wictor Wilén — Thu, 11 Jun 2009 07:24:16 PDT

Just in time for next version of SharePoint to arrive I just completed the final certification exam for SharePoint 2007, the 70-630 Microsoft Office SharePoint Server 2007, Configuring. As always I did think that it should be some tricky questions or problems to solve in the exam, I even installed a MOSS RTM last night just to walk through the admin interfaces before the infrastructure upgrade. But to my disappointment this certification was by no means any challenge. This was by far the easiest of the four exams.

After taking the two developer (70-541 and 70-540) and the configuring exams (70-631 and now 70-630) I really think that Microsoft has failed in creating exams that has any kind of value as a certification. To have some kind of validity on these exams/certifications they should give you a challenge, it should be (must be) hard to pass them. I really hope that Microsoft totally changes how these certifications are outlined and put together for the certifications of the next version of SharePoint. Passing these exams today says nothing (and do not even mention if you failed them). Make the questions into more troubleshooting, especially the configuring exams, have questions on the best practices, make some kind of scenario with linked questions and perhaps even some kind of virtual lab I understand that all problems and best practices are not "invented" when the exams hits the streets, but why not having a level 2 exam coming a year or so later, that has some higher status.

Last week at the SharePoint User Group meeting we had a session with Sweden's first SharePoint Master who told us about the Master certification program - and that is what I call certification. Ok, not everyone will be or even have the chance to be a Master (read Spencer Harbars post) and I do not want the standard exams to be this hard/impossible. Those who passes the MCM are not only Masters they are immortals!

Anyways, I know have the four ones and really looking forward to being acquainted with SharePoint 2010. Not all was bad with these exams though, they made me read through a set of books, making some labs on my own and with that I learned a whole lot.

Six ways to store settings in SharePoint

Wictor Wilén — Tue, 09 Jun 2009 05:15:39 PDT

When developing applications or custom solutions for SharePoint you will on several occasions have to store settings for you application of some kind. When developing database driven or other custom solutions you easily create a database table or make the settings in app/web.config file. You can of course use these approaches when developing for SharePoint, but there are some things to consider when doing this. This post will outline some approaches you can use to store your settings.

What I mean with application or solution settings is some kind of settings that you need for you application to work, such as a Url to a web service or a username and password. These settings are normally only editable by administrators, which requires you to have some security plans, and you need an interface to edit the settings.

Worth to have in mind is that SharePoint can span multiple servers and web applications, it also has the Site Collection and Site scopes which might need different settings if your application runs on several places.

Using a SharePoint List

Creating a database table for storing settings is not the best way in a SharePoint solution - you would use a SharePoint list for this instead. This is the easiest way. Creating a custom list with Title and a Value allows you to store all your settings in one place. There is no need to create a user interface, since you use out-of-the-box functionality and you can secure the list by using permissions on it. The drawback is you need some information (read other setting) that tells you where this list is located, so you're back on square one.

Using web.config

Using web.config is another way to store your settings. It's easy to store information in the appSettings element using a key/value combo. The .NET Framework have built-in functionality to read these settings and SharePoint has some (not so good working) features to deploy the settings in your farm with the SPWebConfigModification class. This approach can only be applied if your settings are web-application wide and you either deploy the settings with the SharePoint object model, which can be quite cumbersome, or manually edit the web.config file on all WFE's.

Using the SPWeb object

The SPWeb object has a Properties property that is persistable StringDictionary stored on the Site (SPWeb) level. This is a perfect solution when you have to store Site specific settings and have the setting available over all your farm. The Properties property is used like this:

   1: SPWeb  web = ...;

   2: // set the value

   3: web.Properties["TheSetting"] = "the value";

   4: // update the value

   5: web.Properties.Update();

   6: // get the value

   7: string val = web.Properties["TheSetting"];

Easy and simple when you have to store key/value combinations, but not so good when you have to store more complex objects, then you have to make some Xml serialization/deseralization yourself.

The permissions in this case is controlled by the MangedWeb permission and you have to build your custom interface.

Using the SPSite object

The SPSite object does not have any Properties property like the SPWeb object, so if you have to store your settings on the Site Collection level you just use the SPSite.RootWeb SPWeb object and use the approach above.

Using SPWebApplication Properties

If you need to store your settings on the Web Application level and you don't to make changes to the web.config, then you can use the SPWebApplication object. The SPWebApplication object inherits from the SPPersistedObject which has a Properties property. This property is a HashTable so you can store key/value combos here. The value can be of any type, as long as it can be serialized.

   1: SPWebApplication webApp = ...

   2: object obj = ...

   3: // set value

   4: webApp.Add("TheSetting", obj);

   5: // persist it

   6: webApp.Update();

This approach requires the user to be farm administrator and you have to build your own interface.

Using custom SPPersistedObjects

Perhaps the best (imho) way to store settings for your web application is to use custom SPPersistedObjects. This approach is very handy when you have to store multiple settings and more complex values. You create your own class that derives from the SPPersistedObject and add your settings as properties to the class and marks them with the Persisted attribute.

   1: public class TheSettings: SPPersistedObject {

   2:     public TheSettings() {}

3:

   4:     public TheSettings(string name, SPPersistedObject parent, Guid id)

   5:         : base(name, parent, id) { }

6:

   7:     [Persisted]

   8:     public string WebServiceUrl;

   9: }

Then you use the SPWebApplication GetChild method to retrieve your settings.

   1: TheSettings settigs = webApplication

   2:     .GetChild<TheSettings>("theSettings");

I usually add two static methods to my settings class for easy creating and retrieval of settings:

   1: public static TheSettings GetSettings(SPWebApplication webApplication) {

   2:     TheSettings settings = webApplication.GetChild<TheSettings>("theSettings");

   3:     if(settings == null) {

   4:         return TheSettings.CreateNew(webApplication);

   5:     }

   6:     return settings;

   7: }

   8: public static TheSettings CreateNew(SPWebApplication webApplication) {

   9:    return new TheSettings("theSettings",  webApplication, Guid.NewGuid());

  10: }

This also requires farm administrator to persist and you have to create an interface

That's it

There you have it; six different ways to store and retrieve settings for you SharePoint custom application. When to use which one is up to you and your needs.

What are you preferred ways or do you have any other suggestions or additions?

New release for SPExLib with SharePoint Linq extensions

Wictor Wilén — Fri, 29 May 2009 18:00:39 PDT

I'm really glad that we have managed to get a really nice release of the SharePoint Extensions Lib, SPExLib, out. This brand new release (12.0.0.0) has significantly been improved since the first release a couple of weeks ago.

Keith Dahlby has made some really nice Linq extensions for SharePoint which is available in this release. These extensions are also IDisposable safe when using on SPWeb and SPSite collections.

By referencing the SPExLib.dll and include the namespaces you can easily write code like this (taken directly from one of my current projects):

   1: SPList regions = web.Lists["Regions"];

   2: regions.GetItems("<Where><Eq><FieldRef Name='Customer'/><Value Type='Lookup'>{0}</Value></Eq></Where>"

   3:                     .FormatWith(lookupValue)

   4:                 )

   5:            .ForEach<SPListItem>(

   6:                     item => ddlRegion.Items.Add(new ListItem(item["Title"].ToString(), item.ID.ToString()))

   7:             );

As you can see the sample uses a number of extension methods; SPList.GetItems() can accept a CAML query directly, System.String has a FormatWith method, the SPListItemCollection has a ForEach method.

Download it and try it out, you will find yourself more productive!

Have a nice weekend.

SharePoint Online updated

Wictor Wilén — Wed, 27 May 2009 17:10:38 PDT

Microsoft has updated SharePoint Online with a patch that resolves the bug that prohibited you from getting the service descriptions from the web services, that I previously described.

This means that you now can use Visual Studio or SharePoint Designer (or any other tool that you like) to connect to the SharePoint Online web services and code away, instead of going to some local instance to get the descriptions.

Does anybody know where the Microsoft Online team posts all updates/changes to the BPOS? I got this information from Troy (from the BPOS team) commenting on my post.

SharePoint Service Pack 2 known, found and experienced problems

Wictor Wilén — Thu, 21 May 2009 17:41:18 PDT

Installing a new service pack onto a server product is not just firing up the installer and hit next->next->finish. You should carefully read through the documentation and test it thoroughly. Service Pack 2 for SharePoint has been long awaited and I’ve seen people the last 24 hours installing it like madness just wanting to get their hands on the new features/updates. I did also install it just minutes after it was released (on my dev machine that is being reinstalled any hour now, when Windows 7 RC is out).

Andrew Connell said it well in a tweet just recently: “I’s watching everyone else install #sharepoint SP2 to see if there are issues (ala IU's AAM fiasco)... thanks in advance guys :)”

Twitter is one nice source of real-time update on what is happening right now on just about everything, especially when it comes to #SharePoint. I’ve collected some of the known, found and discovered problems with Service Pack 2 for Windows SharePoint Services 3.0 and Office SharePoint Server 2007.

IMPORTANT UPDATE: Important information on Service Pack 2 from the Microsoft SharePoint Team. (Added 2009-05-22)

Service Pack 2 has unfortunately a serious bug which makes SharePoint time bombed after 180 days. Workaround is described (KB article) and hotfix is on the way!

Nintex Workflow 2007 problem with Service Pack 2 (~~Nintex currently advises users not to install SP2~~) – the forum thread contains a workaround (Updated 2009-05-01)
- Why did they not have a public (or semi-public beta) for SP2 so companies like Nintex could be proactive
- Update 2009-05-08: Nintex Workflow 2007 1.9.4 fixes these issues
Failure when running configuration wizard after applying SP2 (problem and solution)
- The search service seems to be causing trouble for some users, either when running the config wizard or the b2b timer job
Problem with SQL Server and AWE memory allocation
Some people says that it takes some time to start SharePoint after applying the update
- Note that the content-dbs may automatically be defragmented after the update using the new defragmentation job
Me and some others had some problems when running the installer which was due to the fact that the download of the updates failed so the installation package was corrupt. I had to retry a few times to get all the bits
SharePoint SP2 and SPDatabaseGbwSequence error is caused by free SharePoint templates (Added 2009-04-30)
- Another reason to test your installation
SharePoint Designer needs Service Pack 2 to connect to a SharePoint Service Pack 2 farm (Added 2009-04-30)
MSI error 1603 while installing MOSS Service Pack 2 (Added 2009-05-04)

Have you experienced any other troubles, I’ll gladly update the list!

If you’re anxious to install it, here is a great guide by Shane Young.

Introducing SharePoint Extensions Lib

Wictor Wilén — Wed, 20 May 2009 18:40:43 PDT

I've had an idea for some time to gather all mine and others nifty extension, utility and helper methods into a shared library so that these can be reused in different projects and I finally got my act together and created a new project on Codeplex called SharePoint Extensions Lib, http://spexlib.codeplex.com/, SPExLib.

This is a library filled with extension methods to the SharePoint object model and to the Microsoft.NET 3.5 SP1 classes as well as some helper classes. All you have to do is reference it in your solution and add the using SPExLib.Extensions statement to your code and you are ready to go.

The goal with this project is to make SharePoint programming easier and to fill in the gaps left out in the standard SharePoint APIs.

Version 1.0.0.0

This first version contains extension methods such as:

SPWeb.ListExists() - checks if a list exists in a site
SPList.ViewExists() - checks if a list contains a specific view
SPListItem.Contains() - checks if a list item contains a specific field
SPListItemCollection.FindByField() - returns all items with a certain value to a specific field
Extensions to the XElement and XmlNode objects
A set of classes to make creation of WebParts with EditorParts easier to create
and more

New versions will be released as soon as we have some new and cool extensions.

Contributions - I want you

I really would like to see contributions to this library, so feel free to contact me or write suggestions on the Codeplex discussions page. I know that you are sitting on really good stuff out there.

If you have similar or better implementations that the ones already there, please feel free to show me a better implementation. Let's make this first class.

You can also get the source and check it out and borrow some methods if you like. SPExLib is licensed under Ms-PL.

Virtualizing XP applications using Windows 7

Wictor Wilén — Thu, 14 May 2009 18:53:33 PDT

Windows 7 has an upgrade to Virtual PC which allows you to run Windows XP applications virtualized on your Windows 7, without having to run the whole desktop running.

I still have to use Visual Studio 2003 to support some old good applications including SharePoint 2003 apps. So I have used a Windows XP virtual machine to run it, but now I can fire up Visual Studio 2003 directly from my Start menu in Windows 7. As most of you know, you can't install VS2003 on a Vista or Windows 7 machine, and I don't even want it there either.

It's also great for having Internet Explorer 6, 7 and 8 on the same machine!

Here are some pictures of the Windows XP Mode features.

Visual Studio 2003 running on Windows 7 using Windows XP mode

The published Windows XP applications in the Windows 7 start menu.

The Windows XP notification icons appear in the Windows 7 notification area. Note the Windows Update and Windows Security Alert icons. I thought this was really cool.

AdditionalPageHead (allows multiple)	Exists in all the default master pages and allows you to insert controls in the head element of the page.
SmallSearchInputBox	The search input box present on all pages. WSS automatically adds the searcharea.ascx control here. MOSS replaces this one with the MOSS Search input box
GlobalSiteLink0	Exists in the default.master. MOSS uses this one to publish the variations menu
GlobalSiteLink1	Exists in the default.master. MOSS uses this one to add the link to My Site
GlobalSiteLink2	Exists in the default.master. MOSS uses this one to publish the My Links feature
CentralAdminLeftNavBarTop	Used in Central Admin by MOSS. Located in the top of the Quick Launch
DelctlCreateSiteCollectionPanel	Exists on the create site collection page and used by MOSS to insert the categorization of Site Collections.
DelctlCreateSitePanel1	Same as above but when creating Sites
DelctlProfileRedirection	Exists on the userdisp.aspx page. MOSS uses this one to redirect user the the MySite.