Maxime Bombardier - SharePoint Architecture & Development : STSADM Extensions

Deploying resource files across a farm

MaximeB — Sat, 26 Apr 2008 16:19:01 GMT

I've been looking a little bit more on finding the easiest way to deploy resource files (.RESX) in the App_GlobalResources directory and I found various solutions that includes Features and Timer Jobs to synchronize these resource files. Mikhail Dikov has a very good article explaining different process and types of resources.

However, I find that having features and timer jobs that copy files aren't very elegant and also impractical when you want to add a farm server, when you extend a web application (new zone), etc. While we could still develop something around it, I couldn't find an elegant solution.

In fact, I think the only elegant solution would be for the WSP to deploy App_GlobalResources correctly and that'd be the end of it. Note that you can use WSP to deploy resources in the 12 hive for all Web Applications and also "feature resources". Since I didn't find a way to have that elegant solution, I reverted to asking myself "How did we do it with out of the box Publishing Sites?". The answer is simple, all resources in the ...12\Resources directory are ALL copied in the App_GlobalResources of each web application during the standard Web Application creation (or extension) process.

This means that simply copying your Resource files in the 12\Resources directory will automatically deploy your resources when you create a web application, extend a web application, and even when you add a server in the farm. Now the next question was "How do I update my resource files?". First of all, you will need to upgrade your WSP with your updated Resource files. This will copy the RESX in the 12\Resources directory again. After this, you will need to run "STSADM -o CopyAppBinContent" on all servers in the farm.

Now, there are 2 things that I find "less elegant" in this solution, one that is fixable, one that depends on your architecture:

First of all, running that command on all servers isn't fun for your automated deployment scripts since it would require either doing it manually on all servers or use a remote execution (like PSEXEC) process on all servers. You would either use a CMD with a list of servers (not very dynamic), or create a command that lists all farm servers. I'll outline a solution a bit further.
For the second, it depends how you want your architecture. If you only have one portal, it's fine to deploy it centrally. If you have more than one, it will depend if you "mind" if all resources are available on all web applications. However, in an Intranet scenario, it's probably very acceptable. If you are an ISP, I would stay away from this solution altogether and you will unfortunately have to resort to a less interesting scenario.

What I ended up creating for executing remotely the STSADM command on all servers was of course another STSADM :)! I'll soon create a post with the outline of this STSADM (and add the link here). For now, the extension does the following:

Accepts a parameter with quotes that includes the command that needs to be executed on all servers. I also noticed that you cannot have a parameters that includes "-o" between quotes so I might modify my command so that it accepts an input file that lists the command to be executed on all servers (just to be safe I can catch all parameters).
Retrieves the list of servers (of which the server role isn't "Invalid" like the database server)
For each server, I add an entry in the Central Administration's "Administrator Tasks" list that describes the command (title) with the server name in it, and in the description, I add the command to execute
For each server, I create a Timer Job with a schedule of SPOneTimeSchedule. That will essentially execute the job now on each servers and they will automatically delete themselves.
On each server, when the Timer Job kicks in, it goes back in the Central Administration, reads the Administrator Tasks and find the entry with the "local" server name in order to read the Description column and execute the command defined there

The original command also check that there isn't a timer job and task with the same name prior to executing. Last, if the command doesn't execute successfully on a server, the task isn't deleted and stays on the Administrator Tasks list that shows on the first page of the Central Administration. This allows to have a visual knowledge that the task didn't execute correctly.

Cheers!

Maxime

Feature Stapling is really just for out of the box site definitions

MaximeB — Sat, 08 Mar 2008 15:02:56 GMT

A couple months ago, when I started reading about Feature Stapling on blogs (I don't recall the MSDN documentation having been updated at the time but it is now), not only did I think that it was a mechanism to attach a feature to a site definition (it's true) but it was also touted as a way to update a site after it has been deployed. As a little note, Feature Stapling is basically a feature that contains FeatureSiteTemplateAssociation nodes that attaches a FeatureId to a Site Definition name and configuration.

Now I have carefully worded the last sentence. it's still true, you can use it to update a site after it has been deployed, however, what I didn't know is that Feature Stapling will ONLY work on new site that will be created. Sites already created will not have the feature activated on it and will require a different process (custom).

Now that's a little bit more interesting because Feature Stapling simply adds a <Feature Id=... /> tag to site, which you can do in the ONET.xml anytime unless it's an out of the box Site Definition. Since modifying those definitions isn't supported, Feature Stapling is then the mechanism to attach custom features to OOB definitions. For your own custom site definitions, while you can still use stapling, you can also simply modify your custom ONET.xml and it will do the same.

Now, what do you really do to attach the feature to created sites (which is really what you want to do)? Since Feature Stapling or site definition modifications only works for future sites, you need to activate the feature "now" to all existing sites. The best way is to create a custom STSADM extensions that will run through all sites and subsites, validate if the feature's (SPWeb.Features) is there on the SPWeb. If it is, keep going, otherwise, add the feature to the collection and update (and dispose) the SPWeb object. You can use something simple in the lines of :

   1: using(SPSite site = new SPSite(http://servername/))   2: {   3:     foreach(SPWeb web in site.AllWebs)   4:     {   5:         if(web.Features[featureId] == null)   6:             web.Features.Add(featureId,true);   7:     }   8: }

In summary, you absolutely have to use Feature Stapling on out of the box site definitions to add your custom features to it. For your custom site definitions, you can either modify your ONET.XML file or use Stapling. For already created sites, create an STSADM extension to activate that feature on all of them.

Maxime

Deployment lifecycle when using Site Definitions and Features (including post production day)

MaximeB — Sat, 23 Feb 2008 16:14:22 GMT

Summary

As you have noticed, I've changed my latest SharePoint focus to look at Site Definitions (and obviously Features but I played with them a lot prior to this). The reason for this is that I was looking at the "best" way to deploy artifacts for SharePoint WCM portals. While I had a very good working solution prior to me playing more with Site Definitions, I now think that I am ready to handle the task much better. This is also a follow-up to a previous article : http://blogs.msdn.com/maximeb/archive/2008/01/13/real-life-team-based-development-for-web-content-management-with-sharepoint-2007.aspx

The reason for this is that there is no single way to deploy SharePoint artifacts. Worst, once you deployed the first time, your original mechanism may not work anymore or if it does, it's probably not what you should use! What I'll attempt to do here is to define a few SharePoint artifacts that we deploy in a Web Content Management scenario for both production day and post production day, as well as the deployment lifecycle for the developers pre-production-day and post-production-day.

SharePoint artifacts we'll cover:

Master pages
Page Layouts
CSS / JavaScripts / Images (for the masterpages and layouts)
Site Columns & Site Content Types
Library content types association
Custom Lists
Event Handlers on libraries
Feature Receivers
Timer jobs

SharePoint topics discussed:

Site Definitions
Features
Variations
Feature Stapling
Timer Jobs
Content Deployment

Why Site Definitions?

The timing of me digging Site Definitions more and this post, http://www.andrewconnell.com/blog/archive/2008/02/15/You-dont-need-to-create-site-definitions.aspx, from Andrew Connell was interesting. First of all, he's right, you do not need to create a Site Definition all the time. However, there are also general guidelines. When you look at the Publishing portal that is available out of the box, it really looks like a good sample for reverse-engineering (and believe me, I opened it often to learn stuff!). How often have you kept the original "Press Releases" sub-site or used "Blueband" or any other master for your site? What Andrew mentions is that you should create your own minimal publishing site or you can take a look at this one here on CodePlex but I suggest you still take it apart with your requirements.

Also, I'm almost always in a multilingual scenario (i.e.: SharePoint Variations) and then Site Definitions takes its full meaning. Why? well the Variation mechanism is really just a system that provision sites. It is not a copy of the source site. When the variation timer job kicks in, it will detect a new site in the source variation. When it reads it, it takes the title, the description, the URL and the Site Template (i.e.: site definition). Then it simply does a standard Create Site... with those parameters. Once that is done, it will replicate only the publishing fields of the welcome page. Last, it will provision the other publishing pages the same way and replicate only the publishing fields on those pages. Note that any customization done manually at the source, beside publishing pages and fields, will NOT be brought to the other variations. That includes libraries undefined in the site definitions, documents or images, versioning settings, workflows, and everything else you see in the user interface that isn't a publishing field!

I think my last sentence was obvious enough that if you customize something at the source, you will customize it again at the destination. While there may be scenarios when you might want this, it'll be unusual and the solution is to use Site Definitions so that the provisioning brings as much as possible.

I'll finish this section with an example: today, if you have a Publishing site with the OOB site definition and that your welcome pages aren't "WelcomeLinks", what do you do? First of all, at the source, you created a new page with your layout. Then you updated the welcome page of your site to your new page and deleted the old "default.aspx". Now all your welcome pages are not "default.aspx" but it's no big deal. When you created a 2nd variation label, all the default.aspx/WelcomeLinks are back and they are the welcome pages of your sites in that variation!! So you again updated the welcome page and deleted the default.aspx. That's not very user friendly. Also, if you wanted to ended up renaming your custom page to "default.aspx", the variation mechanism would break when trying to provision the site since it's the name for the WelcomeLinks.

As you can see, Site Definitions becomes a must when using variations.

What defines a Site Definitions?

First of all, there is no golden rule for this but here's what I personally follow to determine if I use the same definition or a new one:

A different welcome page layout
I want to pre-provision a default set of web parts in a welcome page layout
(f) I want to associate specific content types to libraries
(f) I want to allow specific page layouts creation (i.e.: a "news" only section, a "product" only section, etc.)
(f) I want to add special Site Actions for some sites
(f) I want to have a special workflow for some sites
(f) I want to update library settings for some sites

Note that the items prefixed by "(f)" are items where the delivery mechanism is Features but they are associated in some site definitions.

Also, one note that will affect your site definition architecture are Feature Stapling. That functionality is one of the very practical mechanism to apply a feature to a site definition. Unfortunately, it's also "only that". What I mean is that if you have multiple sites with the same definition, it will apply the feature on all those sites. This is great inside a single Site Collection but when your SharePoint farm contains multiple site collections (possibly for different customers), you may not want to apply a feature to all of them. Unfortunately, I do not personally know of a better solution than to create your Site Definitions "per site collection" only (i.e.: in the naming). They will still likely use the same features though.

And really, when I design Site Definitions, I created a Feature that contains all the Features that I use for ALL sites. That way, my Site Definitions are very small and only contains the customization for that site. Also, I suggest taking a look at this tool to read your sites definitions : http://blogs.msdn.com/maximeb/archive/2008/02/16/site-definition-viewer-a-windows-net-2-0-tool-to-read-site-definition-and-features-configurations-version-0-1.aspx. I also created some CMD files to automate development of site definitions and they come in handy to maximize your time. I will post them soon.

Before taking a look at the SharePoint artifacts, I need to give you a bit of background on how we get the artifacts: We set up a MOSS server only for "web integrators". The Site Collections in there contains the files directly in the database edited through SharePoint Designer. We hooked up an event on the libraries that, when a check-in is done, it brings the file in a Team Foundation Server. Then, we have someone maintaining the build process and when he get the "go" from the web integrators, he builds the feature containing the files and that is sent to the developers for updates and eventually to production.

SharePoint artifact deployment - Master Pages - Page Layouts - CSS/JS/Images

1) Pre-production "day 1"

You should create a site-scoped Feature containing your master pages and other files (pages layouts and css/js/images). Take a look at the PublishingLayouts for ideas. When this feature is activated on a site collection, it will add the file in the libraries in a ghosted format which means that there are no customization on them. Note that if you ever unghost it at the destination, your feature will never update the file after.

2) Post-production "day 2+"

We'll have to define some sub-scenarios but first, let's start that, yes, you may be able to uninstall the feature and reinstall it while using the -force command but I do not recommend it. First, as I just mentioned, if you unghosted a file, it will not be updated. So if you plan on using this technique, make sure you test first. Also, I had some issues with BlobCache with CSS/JS/GIF/JPG but only when they were ghosted, never when unghosted.

Scenario #1 Updates to some/all the files

I would suggest creating an STSADM extension that update files defined in your Feature. This extension will unghost the file and it will act as your mechanism to deploy updates. What I use is a simple extension with an Xml input file that defines the files to update. This file simply grows over time since I only append to it. It gives me an added benefit with "change management" since it's not simply a build that picked up all files and sent it in the feature which may contain an update.

Scenario #2 New files

If you have new files, you probably have a "business reason" behind. For a new master pages or page layout, is it only for a new type of site (i.e.: defined in a site definition) or would you like to apply it automatically on some/all sites? That you have a new site definition or not, you are likely to have a new feature that brings the file. This feature may contain a Feature Receiver that will do some actions with those files such as :

Assigning the master page to some sites
Allowing the page layout to be created in some/all sites
If you have a new site definition, you may want to add it in the list of available web templates

Once you have your feature, you may want to create another one to staple the first feature with your site definition (some or all of them).

For new CSS/JS/images, they are probably used by a new page layout or master to being with so they will go in the same new feature.

3) Developers Pre/Post production day

During the initial development phase "pre-production day", developers should update their environment when they need it. Since I have everything in Team Foundation, I created special CMD/Bath files for developers that helps them clean/create a site definition with some sub-sites already pre-populated. This is enough for most cases. It's clean and fast and they are up and running quickly.

"Post-production day", the site definitions will not be updated (although they can be appended), nor the features, so they should run the same script that add files in the database and install the new features.

SharePoint artifact deployment - Site Columns and Site Content types + library association

1) Pre-production "day 1"

Feature is the best mechanism to bring columns and content types. Note that the feature has to be Site scoped so it will not bring the content types to a library unless you manually create a page through the GUI or that you use a content type association feature in your site definition. You can take a look at Andrew Connell's STSADM extension for a good sample of exporting your columns/content types.

2) Post-production "day 2+"

Well we learned the hard way, since the MSDN documentation wasn't available back then, that if you add a column to a content type (in a feature), a "reinstall" of the feature will only bring the new column at the Site Collection level and it will not be replicated down to each libraries using that content type. Fortunately, the user interface works great so if you do not have many columns to add, you may simply want to document the manual update.

But you know I like automation ... so yes, we are also fortunate with the API and it replicates down the change as well. An STSADM extension that adds column + associate it to a content type can be done easily so that it reads an Xml input file with all the updates since Day 1. When it runs, if the column's already there, it simply skips it and go check if the content type contains the association to it.

3) Developers Pre/Post production day

The same process will apply for developers. However, since the "STSADM extension" isn't created until Day 1, they may either recreate their site collection or manually add the column/content types when a change occurs. In my case, since creating a site definition is scripted, it goes very fast.

SharePoint artifact deployment - Custom lists

1) Pre-production "day 1"

A custom list is defined in a feature. The definition contains the columns and types. An instance of a list is defined in a Site Definition or through the user interface. You can also populate rows of data for an instance of a list defined in the Site Definition.

2) Post-production "day 2+"

That one is tricker, you can update and reinstall the feature. However, that will only affect new list creation. I personally haven't gotten the need to add columns and data to a list post-production but I would likely need another little STSADM extension to update it.

3) Developers Pre/Post production day

Same process as the content types, if it's only a feature, then reinstall it. If it's in the site definition, run the creation script.

SharePoint artifact deployment - Event Handlers, Feature Receivers, and Timer Jobs

1) Pre-production "day 1"

All of these are class items. You may want to run code for a specific event on a library, run code when a feature's activated, or run code through a timer job at a specific time. All of them are also originally brought through a feature.

2) Post-production "day 2+"

Now, this can be either very easy or much harder depending on how "politically correct" you want to be. Technically (or less politically correct), the classes are either in the BIN or the GAC, if you need to update the code, you can simply deploy them without touching anything in SharePoint (beside an application recycling or an IISRESET). That is, only if you kept the same assembly version.

Unfortunately, if you want to be more politically correct, you'd have to change the feature, since it contains the assembly version, and reinstall it but there are cases when it seems that some references are "ghosted" somewhere in a database so it may not work. If you want to be politically correct (and normally, we should) with assembly versions, I would strongly suggest doing tests.

3) Developers Pre/Post production day

For pre-production day, it's easy, the version isn't likely to change much so you are good to deploy the DLL and reset IIS/app pool. Post production day will depend on what you chose in scenario 2.

Content Deployment with all this

As long as your site definitions, features, and assemblies are all deployed at the destination, Content Deployment will work great with your artifacts. Sounds simple but even with all my run-ins with Content Deployment, it works good in that scenario.

Hope it helps a bit. I know it's a bit sad that there isn't a "single scenario" and I'm still using STSADM extensions to do some updates, but remember, most of the updates are doable from either SharePoint Designer or the web user interface. These 2 tools works good for the updates. Unfortunately, this version of the product doesn't seem to include the fact that field WCM deployments often have a more rigid and secure environment and SPD users aren't likely to play in production or even staging. That's when we, developers, want to automate the process and that's when we create STSADM extensions to fill the gap.

Maxime

Setting Major/Minor versions and Content Deployment issues

MaximeB — Thu, 14 Feb 2008 02:19:05 GMT

Just a quick heads-up when you want to limit versions in a Web Content Management scenario and you have Content Deployment set up.

First of all, let me explain why you would like to do this: Basically, if you happen to execute routinely a Full Content Deployment, a new version of every document (pages, images, document, etc.) at the destination. Since the default library settings are set to accept unlimited major and minor versions, you will likely run into a disk space issue before long. I noticed that on a WCM portal that was planned for about 100 MB of web content that turned out to have 600 MB quickly because not all content had been "web-ified" and was still in PDF and document. That 600 MB was being added at each Full Content Deployment, that a modification occurred or not!

So now you have a fully deployed portal with 150+ sub-sites that you want to limit the versions on at least "/documents" and "/images" (and likely "/pages" as well). At the time, we didn't know enough (or anything really) about Feature Stapling to use them so we created an STSADM extension that updates a library's versioning settings (i.e.: does it require approval, the major & minor versions supported, etc.). I would suggest using Feature Stapling for yourself (with the same codebase really) since it will also affect new sites.

To get back to the primary subject: if you set a major or a minor version limit in the GUI, apply the change, and deploy the update to the publishing farm; then you go back and update to only have a major limit and do not support minors, the GUI will work correctly when you apply. In fact, the "staging or authoring" farm will work correctly. Unfortunately, when you use content deployment, it will say that you cannot set minor version limit on a library that only supports major versions!

I happened to know that error exactly since, when creating the STSADM extension, I got that error when playing with the properties in the "wrong" order. It seems that Content Deployment do use the right order either. You will have to remove the version limits, use content deployment, and then update to have only major versions.

Maxime

Missing Content Types association with variations - an STSADM extension solution

MaximeB — Sat, 27 Oct 2007 15:28:50 GMT

I ran into an issue the other day where all content for most pages where missing when viewing a "target variation" (I define a variation as "target" when it's not the source variation). After taking a closer look, we could see the titles and description, but any custom fields were missing unless the page was a System Page or an Article.

After more investigation, I went in the Pages Library Settings and could see that the associated Content Types were only with Page & Article. Now, all custom types I create are based on Page so what was happening was that only the fields available in Page were showing since it's my base type. I could simply, even in the GUI, add the associated content type to the library and the content was showing.

Basically, while the column's data are replicated to each variations, if the content type isn't associated to a library, the library won't show data from that content type at all even if a page references it. Obviously, creating all of those by hands would be quite a feat and so I ended up working out an STSADM extension that was reading the source variation and updating the ContentTypes collection of each Pages library for each variation (based on the source available content types).

Update :

Here's a snippet of code to apply Content Types on a Pages library. You will need a reference to the Site's content types (in snippet, variable name : _publishingSiteContentTypes) which you can get by having an SPWeb on the site collection (or root web) and reading its "ContentTypes" collection:

   1: private void ApplyPagesContentTypes(SPWeb spWeb, PagesContentTypes pagesContentTypes)   2: {   3:     _log.WriteLine(Environment.NewLine + String.Format("Applying {0} Pages Document Library Content Types", spWeb.Title));   4:     _log.WriteLine(LogStepLineBreak);   5:     6:     if (pagesContentTypes.Items != null)   7:     {   8:         SPList pages = spWeb.Lists["Pages"];   9:    10:         SPContentType contentType = null;  11:         string contentTypeName = null;  12:    13:         for (int i = 0; i < pagesContentTypes.Items.Length; i++)  14:         {  15:             contentTypeName = ((ContentTypeName)pagesContentTypes.Items.GetValue(i)).Value as string;  16:    17:             SPContentType pagesContentType = pages.ContentTypes[contentTypeName];  18:             contentType = _publishingSiteContentTypes[contentTypeName];  19:    20:             if (contentType != null && pagesContentType == null)  21:             {  22:                 pages.ContentTypes.Add(contentType);  23:                 _log.WriteLine("\t" + contentType.Name + " assigned");  24:             }  25:             else if (contentType == null)  26:             {  27:                 _log.WriteLine("\tError: " + contentTypeName + " wasn't found in the available content types");  28:             }  29:         }  30:    31:         spWeb.Update();  32:     }  33:    34:     _log.WriteLine(LogStepLineBreak);  35: }

Maxime

You receive an error when you create a page, as a SharePoint Member, for the first time in a sub-site

MaximeB — Sat, 27 Oct 2007 15:19:11 GMT

We ran into a little issue the other day when using an account with only Member rights (yes yes, we are usually admins :)), we were creating a page for the first time in a sub-site and we were receiving a beautiful stack trace of nothingness. We refreshed the page and it was working fine, the page was added. With an account that's admin or owner, we didn't have that problem.

Now, we are creating the whole site structure programmatically through an STSADM and we are setting the AvailablePageLayouts collection per web application as to limit the type of pages authors can create for each sub-site. And I remembered an issue with Variations where the ContentTypes collection for each "target" variations weren't set correctly by the variation job. So I guessed right, we pre-populated the ContentTypes collection for each sub-site to contain a reference of all site content types that we accept for each sub-site and the error disappeared. Since we had the whole extension with an Xml input, it wasn't hard at that point to add "Available" ContentTypes to it.

It's quite possible that the GUI for updating AvailablePageLayouts does that, I didn't use Reflector on it nor did I check the ContentTypes collection when using the GUI, but my guess would be that the error's a bug since if you refresh the page creation, the content type is indeed added at that point and the 2nd creation will work.

Maxime

Programmatically create a site lookup column in SharePoint

MaximeB — Sat, 27 Oct 2007 15:08:37 GMT

We have automated almost everything about creating a "blank" publishing web site with landing pages, navigation parameters, even content pages. One thing we found out with Features or even code is that you cannot create a list with its GUID; it will be provided to you after creation. Obviously, if you have a Feature with a List and a site lookup column pointing to that list through its GUID, the feature will not work.

So we had to break our list & lookup columns from our features and create them programmatically after the feature is installed (or it could be part of the Activated event if you want). In our case, we created an STSADM extension that creates a SharePoint Custom List, add its columns, add its data rows, create site lookup columns, and add them to the specified content type. The input's obviously an Xml file.

Down to the point, creating a Lookup Column isn't terribly different than creating a standard column where you have to add it to the site columns collection. However, instead of using the Add method, there's also an AddLookup method. Basically, you need an SPWeb instance and an SPList instance pointing to your list and you can add the column with this :

web.Fields.AddLookup(myNewColumnDisplayName, list.ID, list.ParentWeb.ID, myNewColumnIsRequired);

SPFieldLookup lookup = (SPFieldLookup)web.Fields[myNewColumnDisplayName];

lookup.AllowMultipleValues = myNewColumnAllowMultipleValues;

lookup.Group = myNewColumnGroup;

lookup.LookupField = myNewColumnLookupField;

lookup.Update(true);

I've put in bold the parameters you have to include but that's about it, you now have a site lookup column created. Beware, you can create the column with the same display name multiple times so you will want to verify first if the column already exists. After that, you will want to add it to content types.

                newField = (SPField)lookup;

SPContentType ct = web.ContentTypes[contentTypeName];

bool fieldLinked = false;

foreach (SPFieldLink fieldLink in ct.FieldLinks)

{

if (fieldLink.DisplayName.Equals(columnLookup.DisplayName))

{

fieldLinked = true;

break;

}

if (!fieldLinked) {

ct.FieldLinks.Add(new SPFieldLink(newField));

ct.Update(true);

}

Again, you have to validate that the link isn't already there (if you plan on being able to re-run your code as I can with an STSADM. You are now all set with your lookup columns!

Maxime

Content Deployment : The URL "Style Library/en-us" is invalid

MaximeB — Thu, 11 Oct 2007 01:00:08 GMT

I came across this error yesterday while testing a Content Deployment for a customer and had this error "The URL "Style Library/en-US" is invalid ..." with the stack trace mentioning that it was updating a File or Folder. The kind of message where you say "yeah I know, I'm deploying this so you should bring it up!".

I couldn't find what was causing the issue. For a recap, when you use first use Content Deployment (for a Publishing Site), your destination must be a "Blank Site" of the same language than the source's site collection language. However, a coworker mentioned to me another issue he had with content deployment and the solution was to add another step prior to the first deployment :

For a successful Publishing Content deployment, your destination must have first created a Publishing Site collection, deleted it, and then created the Blank Site. That will add elements to the Web Application and your Content Deployment will complete successfully after that.

I had heard of issues where Resource files weren't fully brought by the Content Deployment, that would also fix it.

Maxime

My STSADM extension toolbox

MaximeB — Sat, 06 Oct 2007 21:34:14 GMT

Here's a listing of custom STSADM extensions myself and my coworkers have created. Feel free to ask questions regarding the namespaces for these. I'd like to thank those who contributed to this : Stéphane Perron, Louis Fournier, and Vincent Trépanier at Orckestra, an outstanding partner for SharePoint, Biztalk, and Commerce in Montreal; and a co-worker Philippe Bédard.

BaseStsAdmExtension

The basic class for all my extensions. It adds up default classes for a common output, verbose output switch, Url switch, and a wait switch to allow a developer to attach to the process.

ContentBuilder

Generates all columns, content types, page layouts, style sheets, site collection images, and master pages in a Feature. The "files" have to be exported (and we have another mechanism for that) in order to import them in another site. This was originally taken from http://andrewconnell.com/blog/articles/MossStsadmWcmCommands.aspx and then updated to fix a few issues and add more elements. You can also find information on Features here : http://msdn2.microsoft.com/en-us/library/ms460318.aspx and here http://www.codeproject.com/spoint/ExtendingSPS.asp.

PreloadWebSites

A simple extension that reads an input Xml file and hits all the specified Urls with HttpWebRequests. This helps loading specific content types & page layouts in the JIT after you ran the Warm up scripts.

PublishAllItems

An extension that will approve items in SharePoint. It has 2 main switches, one to approve "web integrators" libraries (Master pages, Style Library, Site Collection images); and one to approve "Pages" libraries starting a given path and downward. It will also cancel any workflow associated with the element's it's approving. You can also take a look at the one available at http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html as it ended up being very similar to mine.

ResetMasterPages

This one I had to create to automate the master pages settings when using Content Deployment. There is a known bug where, when doing the first Full Content Deployment, the master page parameters aren't kept at the destination. This will bring them over.

ListBuilder

This will read an input Xml file and create custom lists with custom columns. It can also add Lookup site columns and add those columns to content types. This was done because we used Features to add content types but found out that a list was always recreated and used a different GUID. We couldn't provision Lookup columns to them and if we used a Feature to bring a list over, then the GUID was changing every time and causing issues with Content Deployment. It can also provision a BDC column in the list.

SiteBuilder

This extension will create a whole lot of things for a portal : sites with title/description, content pages with content (fields) values, set master pages, set available page layouts, set the content types per libraries (to fix a little bug), and set security (coming soon). It's great when you have features for the containers/artefacts and you want to add a default

AddLocalFile / DeleteLocalFile

We needed a little help to add and remove files other than through Features. Basically, we first had the issue when deploying updates to ItemStyles.xsl and other OOB files. This extension was deleting the OOB files from that web site and then applying the ones from our Feature (and we needed it in ItemStyles and couldn't have a custom file).

AddPublishingWorkflow/RemovePublishingWorkflow

This one is in development;I want to be able to add and remove the Publishing workflow for all sites so that we can switch between requiring a "publish" or an "approve" through the extension. We often want publishing only in development but an approval requirement for other environments; this extension would permit this.

There's also a bunch of custom extensions available by Gary Lapointe at the following address : http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html.

I'll update this list with blog links when I create them and add new extensions.

Maxime

Listing all sites per variations - an STSADM extension solution

MaximeB — Tue, 25 Sep 2007 01:37:57 GMT

A little while ago, we ran into an issue with the Variation label creation process; it was ending successfully without creating everything. To make matters worst, it wasn't picking the missing sites/pages with the Synchronization Timer Job.

So it was very difficult to figure out what was missing in a particular variation except by browsing to each pages and figuring out if the page was missing. While we only had 150 sub-sites, it could create 10 or 140 of them.

For those interested, it seems that the issue is due to 3 things combined:

Memory leak in the variation creation process (scheduled to be fixed)
Potential memory leak when the farm is on a VMWare virtual environment
Not enough memory on the server :)

Now, while waiting to have more memory and a fix, we still had to create variations correctly. So far, we could only delete a variation and recreate it while hoping it would be done successfully. In order to assert that we had an incorrect variation label and to what extend, I ended up creating a small STSADM extension that was simply listing each sub-sites in an Xml format along with a counter on each node to mention how many sub-sites is under.

Essentially, create a class that implements ISPStsadmCommand and in the main class, call the EnumSites method passing the output file name & Url. Here's the Visual Basic.NET code excerpt :

        Private Function EnumSites(ByVal vOutputFile As String, ByVal vUrl As String) As String
            Dim output As String = String.Empty
            Dim siteMOSS As SPSite = Nothing
            Dim rootWeb As SPWeb = Nothing
            Dim publishingRootWeb As Publishing.PublishingWeb = Nothing
 
 
            Try
                siteMOSS = New SPSite(vUrl)
                rootWeb = siteMOSS.OpenWeb
                publishingRootWeb = PublishingWeb.GetPublishingWeb(rootWeb)
                Dim xmlDoc As New XmlDocument()
 
 
                Dim xmlDeclaration As XmlDeclaration = xmlDoc.CreateXmlDeclaration("1.0", "UTF-8", Nothing)
                xmlDoc.AppendChild(xmlDeclaration)
 
                Dim xmlRoot As XmlElement = xmlDoc.CreateElement("Variations")
 
 
 
                For Each web As PublishingWeb In publishingRootWeb.GetPublishingWebs
                    If web.Label IsNot Nothing Then
 
                        Dim variation As XmlElement = xmlDoc.CreateElement("Variation")
                        Dim attrSource As XmlAttribute = xmlDoc.CreateAttribute("source")
                        Dim attrName As XmlAttribute = xmlDoc.CreateAttribute("name")
                        Dim attrSiteCount As XmlAttribute = xmlDoc.CreateAttribute("numOfSubSites")
                        Dim numOfSubSites As Integer = 0
 
                        attrSource.Value = web.Label.IsSource.ToString
                        attrName.Value = web.Name
 
                        variation.Attributes.Append(attrName)
                        variation.Attributes.Append(attrSource)
 
                        output &= "Variation : " & web.Name & ", isSource=" & web.Label.IsSource.ToString & Environment.NewLine
                        numOfSubSites += EnumSites(xmlDoc, variation, web.Web.GetSubwebsForCurrentUser(), output)
 
                        attrSiteCount.Value = numOfSubSites.ToString
                        variation.Attributes.Append(attrSiteCount)
                        xmlRoot.AppendChild(variation)
                    End If
                Next
                xmlDoc.AppendChild(xmlRoot)
 
                output &= "Saving Xml output file ..."
                xmlDoc.Save(vOutputFile)
 
                Return output
            Catch ex As Exception
                output &= "Error : " & ex.Message & Environment.NewLine
            Finally
                If siteMOSS IsNot Nothing Then _
                    siteMOSS.Dispose()
                If rootWeb IsNot Nothing Then _
                    rootWeb.Dispose()
            End Try
 
            Return output
        End Function
 
        Private Function EnumSites( _
            ByVal vXmlDoc As XmlDocument, _
            ByVal vXmlParent As XmlElement, _
            ByVal vWebs As SPWebCollection, _
            ByRef rOutput As String _
        ) As Integer
            Dim numOfSubSites As Integer = 0
 
            Try
 
                For Each web As SPWeb In vWebs
                    numOfSubSites += 1
 
                    Dim site As XmlElement = vXmlDoc.CreateElement("Site")
                    Dim attrName As XmlAttribute = vXmlDoc.CreateAttribute("name")
                    Dim attrWelcomePage As XmlAttribute = vXmlDoc.CreateAttribute("welcomePage")
                    Dim attrSiteCount As XmlAttribute = vXmlDoc.CreateAttribute("numOfSubSites")
 
                    attrName.Value = web.Name
                    Try
                        attrWelcomePage.Value = PublishingWeb.GetPublishingWeb(web).DefaultPage.Name
                    Catch ex As Exception
                        attrWelcomePage.Value = "N/D --- " & ex.Message
                    End Try
 
                    site.Attributes.Append(attrName)
                    site.Attributes.Append(attrWelcomePage)
 
                    Dim numofSubSubSites As Integer = EnumSites(vXmlDoc, site, web.GetSubwebsForCurrentUser, rOutput)
                    numOfSubSites += numofSubSubSites
 
                    attrSiteCount.Value = numofSubSubSites.ToString
                    site.Attributes.Append(attrSiteCount)
 
                    vXmlParent.AppendChild(site)
                Next
            Catch ex As Exception
                rOutput &= "Error : " & ex.Message & Environment.NewLine
            End Try
 
            Return numOfSubSites
        End Function

You can essentially do the same for pages if you want to list them and do a compare with the source variation in order to list exactly what's missing, however, when we found out that the memory was the issue, we didn't extend this application so it's still in the "napkin format" :)

Maxime