For those that follow me on twitter ( you probably already know about these fixes but I’ll try to provide more details here. While I was waiting to start my new job (see my previous post) I decided to take a look at a few of the STSADM commands that I built and fix some things that’s been nagging me for a while. The one I spent the most time on was the gl-convertsubsitetositecollection command and more specifically its partner the gl-repairsitecollectionimportedfromsubsite command.

This command is undoubtedly my most popular command – it’s corresponding blog post is consistently the top requested post on my blog every week. The problem is that I had some direct access database calls in the code which never really set well with me – it violated everything I always tell people – never hit the database directly. The reason for the code was due to two issues: the ContentType field of the master page gallery was getting incorrectly set to a Text type instead of a Choice type and there was no way via the API to change this; discussion lists were getting flattened and there was no way via the API to change this without recreating each item (copy/move operation) which messes up historical/audit information.

There are two things that enabled me to get rid of this DB access code: I’m smarter than I was 2 years ago when I originally wrote the code and SP2 came out. Using code that I wrote for copying lists I was able to simply export the original source master page gallery and import it on top of the target gallery thus forcing the content type field to be fixed. I also found that, in every case I tested, activating the PublishingResources feature now fixes the list (I believe this is the result of SP2 but I’ve not had time to confirm specifically). Also, I removed some code to deal with an earlier bug that was resulting in items being put in arbitrary locations (under the wrong folder) so now discussion list items are correctly imported and not flattened.

So, what does all this mean – if you are not running SP2 then most everything with these commands should work just fine for you but I can’t guarantee everything I’m accounting for will be fixed (particularly discussion lists) – so if you plan on using these commands I strongly recommend you deploy SP2. I also added some additional logging and removed the unnecessary site template related parameters.

Another command that I “fixed” was the gl-createsiteindb command. This one never really sat well with me because I was using reflection to call an internal method in order to pass the target database in – it just seemed like there had to be a way to do this without using reflection. Turns out there was but for whatever reason I just missed it (maybe it’s new with an update or something or maybe I just brain farted). Once you get the SPContentDatabase object you can simply use the Sites property which returns an SPSiteCollection object and then call it’s Add method to add the site to the database – seems so obvious now. Anyways, the code has been updated to use this approach thus avoiding the use of reflection.

The following remaining commands also had some minor fixes done:

  1. gl-copylistsecurity: Fixed issues for list items (document libraries were not affected) where the target items was being located via the file name property (SPListItem.Name) which was not necessarily set for a generic list. I now first try the FileLeafRef field and if that fails then I use the index of the item in the list.
  2. gl-importaudiences: The XML file that I was outputting was reversing the value of the SearchString and ReplaceString attributes.
  3. gl-copycontenttypes: If the document template pointed to an existing document outside the current web the code now correctly copies the value of the document template property without attempting to copy the document itself (previously it would ignore the property if it couldn’t access the file).
  4. gl-replacefieldvalues: I was previously checking the document out, making the change, and checking the document back in. For various reasons I’ve decided to not attempt to check the document out and instead simply call SystemUpdate to save the changes. I went back and forth on this and would be curious to get peoples thoughts – is it better to have a separate version for each change or leave it as I’ve got it now where no version history is generated?

I’ve not yet updated the documentation for all of these commands but I will attempt do so this week.