Rich Finn

So, earlier I posted how I upgraded WSSv3 to MOSS.

After I completed that task, I wanted to see what it would take to turn my existing top level site collection into a publishing site, as the Publishing Feature is one of the lowest hanging fruit in the MOSS Feature stack that has the greatest benefit to both users and administrators right out of the gates.

The first thing we need to do is enable the Office SharePoint Server Publishing Infrastructure feature in the site collection features list.

Uh oh:

The logs say that access was denied activating the Publishing Resources feature and the message is 'Provisioning did not succeed. Details: Failed to provision the scheduling job definitions.  Page scheduling will not succeed.'  Then there are some other messages in the logs that say that an exception was thrown ensuring dependencies were met for the Publishing Site Feature.

According to a post I found on NetAdminTools.com, you can activate the Publishing Resources via stsadm, then click the Activate button in the site collection Features list.  This seemed to work pretty well:

Then I activated the Office SharePoint Server Publishing Feature in the Site Features list (in the Site Administration group) and the Pages list was created and the site actions menu was expanded, and there was much rejoicing (yaaay)

BUT WAIT!

When I created a new page, something seemed off.  There were only a few pages available in the 'choose page layout' list box.  Looks like some article pages and welcome pages were missing.  I went to the mast page gallery and saw that there weren't any pages missing, but there were some pages, like the welcome page with web part zones page layout - which is the page layout used on the default page of the Collaboration Portal site definition - that were not associated to their proper Content Types! Uh - Weird!  How did this happen, and how can we fix it?

Creating new site collections based on the Team Site template proved that we could activate the Publishing Infrastructure Feature without the access denied error, but the page layouts still didn't have the Content Type associated in the Master Page Gallery. Tried this on four site collections.  PublishingPrerequisites, PublishingResources, Navigation, and PublishingLayouts are the Feature Activation Dependencies on the PublishingSite Feature (the Publishing Infrastructure Feature name) and they are all scoped to the site, so why are the page layouts not getting associated with the Content Types?

Creating a new site collection based on the Collaboration Portal site definition worked fine, and the page layouts were associated correctly. Lame.  Must be the order that the site Features are activated.

After going through the Features listed in the onet.xml file for the Collaboration Portal site definition in the order defined, order's NOT the problem.  What is you ask?

So - turns out that the page layouts are tagged as being part of the Master Page Content Type - what's up with that?!?
 

Eidt the page and change the Content Type to the correct one (Page Layout), then set the Associated Content Type.

Check In, Publish a Major Version, and Approve it. Fixed!

Bug...

This seems to have come up a lot for me lately: We have a client who wants to know what it takes to upgrade from WSSv3 to MOSS. What do they need to do to make the MOSS Features available in their current WSS sites?

Having been primarily only working with MOSS, I haven't done much with just WSS and have never run through the upgrade process to MOSS.  There was very little documentation out there other than some forum posts, so today I ran through it for the heck of it and was impressed, but unsurprised, that it was pretty smooth.

To begin, I installed the slipstreamed WSS+SP1 available from Microsoft downloads onto a fresh Windows Server 2003 virtual.  I set it up using SQL 2005 instead of SQL Express, which was a little lazy on my part, because I should have run through what it would take to move the SQL Express stuff over to SQL 2005. Oh well.

I set up my web application with a site collection at the root based on the standard Team Site definition.  This site then got two sub sites.  All three sites had a single Word document in it's Shared Documents doc library.

Then, I installed MOSS+SP1 from MSDN Subscriber Downloads. Here's the steps with some screen shots that I thought were of value:

1) Ran install of MOSS.  Pretty straightforward.  Extracted files, entered key, selected server type, installation of bits and securing of resources, etc, etc...

2) Ran configuration wizard. Says 'This wizard will upgrade SharePoint Products and Technologies'. Config wizard is aware of config db. Runs through nine tasks without hanging on anything for too long, and then completes.

3) Opened Central Admin. On the Operations tab:

When clicked:

Check and click OK:

Completed pretty quick:


One thing to note here - this just enabled the Enterprise SKU Features, I think because I entered an Enterprise key from MSDN, so none of the Standard Features were activated. FYI...

4) Started new services:

5) Created SSP - nothing special here

6) To get Search lined up, I created a Search Center site at the root of the site collection, and changed the site collection search settings to use the new search center I just created:

That was pretty much it. Like I said, impressed, but not surprised.

In our current SharePoint project, we have a custom site definition based on the out-of-box Publishing Site with Workflow. We found a little problem with this though, because when the out-of-box Features for Publishing and it's Parallel Approval workflow are activated, the default SharePoint Approvers group is the only group that is set to approve a publishing page that has been sent into the workflow. The problem is, we want to inherit the parent site's workflow settings - otherwise known as the association data - because our application has 'channels' of content that each has a different group who can approve the content in their appropriate channel.

The group that can approve publishing pages in each channel is defined in the root web of the channel by doing nothing more than editing the Parallel Approval workflow on the Pages list, and then setting the correct group on the People Picker for the workflow approvers property. Since channel owners can create new sites in their channel using our custom provisioning process, we don't want them to have to go into the Pages list workflow settings to set the correct group every time, because as we all know, people make mistakes. Why not automate this process and set the right approvers group for the channel owner when the new site is created?

To do this, we created a Feature that we included in our custom site definition.  When a new site is created and the Feature is activated, we execute the following code:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using System.Diagnostics;
using Microsoft.SharePoint.Workflow;
using System.Xml;
using Microsoft.SharePoint.Publishing;

namespace Demo
{
    public class FeatureReceiver : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            //get the SPWeb object for the Feature's scope
            SPWeb currentWeb = properties.Feature.Parent as SPWeb;

            //set the AllowUnsafeUpdates property to true so we can apply the change to the workflow
            currentWeb.AllowUnsafeUpdates = true;      

            //get the parent web of the current web - this is where the correct workflow settings are
            SPWeb parentWeb = currentWeb.ParentWeb;
            
            //get the Pages list from the current web using the PublishingWeb object
            SPList currentWebPublishingList = PublishingWeb.GetPublishingWeb(currentWeb).PagesList;

            //get the current web Pages list's workflows
            SPWorkflowAssociationCollection currentWebWorkflows = currentWebPublishingList.WorkflowAssociations;

            //if the site has workflows, we need to get the parent web's workflow and apply the same approvers to it
            if (currentWebWorkflows.Count >= 1)
            {
                //find the parallel approval workflow
                SPWorkflowAssociation currentWorkflowAssociation = currentWebWorkflows.GetAssociationByName("Parallel Approval", currentWeb.Locale);

                //empty container for the parent pages list workflow
                SPWorkflowAssociation parentWorkflowAssociation = null;

                //get the parent site's pages list
                SPList parentPagesList = PublishingWeb.GetPublishingWeb(parentWeb).PagesList;

                //if there's workflows attached, we need to find the Parallel Approval workflow
                if (parentPagesList.WorkflowAssociations.Count > 0)
                {
                    parentWorkflowAssociation = parentPagesList.WorkflowAssociations.GetAssociationByName("Parallel Approval", parentWeb.Locale);
                }

                //if we have the parent workflow, we need to copy the review settings to the child
                if (parentWorkflowAssociation != null)
                {
                    //xmldoc for the parent association data
                    XmlDocument parentAssociationData = new XmlDocument();
                    parentAssociationData.LoadXml(parentWorkflowAssociation.AssociationData);

                    //xmldoc for the child workflow association data
                    XmlDocument currentAssociationData = new XmlDocument();
                    currentAssociationData.LoadXml(currentWorkflowAssociation.AssociationData);

                    //we need to create a namespace manager object because the xml data we want is 
                    //namespaced with 'xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD"'
                    //the following code was obtained from John Wood's blog
                    //url: http://www.dotnetjunkies.com/WebLog/johnwood/archive/2005/08/25/132153.aspx
                    //this code will add all namespaces in the xml to the namespace manager, allowing us to correctly
                    //create XPath queries to retrive the data we need

                    XmlNamespaceManager nsmgr = new XmlNamespaceManager(parentAssociationData.NameTable);
                    foreach (XmlAttribute attr in parentAssociationData.SelectSingleNode("/*").Attributes)
                    {
                        if (attr.Prefix == "xmlns")
                            nsmgr.AddNamespace(attr.LocalName, attr.Value);
                    }

                    //get the Reviewers node from the parent workflow
                    XmlNode parentReviewers = parentAssociationData.SelectSingleNode("//my:Reviewers", nsmgr);

                    //get the Reviewers node from the child workflow
                    XmlNode currentReviewers = currentAssociationData.SelectSingleNode("//my:Reviewers", nsmgr);

                    //set the Reviewer node of the child workflow to be the same as the parent
                    currentReviewers.InnerXml = parentReviewers.InnerXml;

                    //update the child workflow's association data
                    currentWorkflowAssociation.AssociationData = currentAssociationData.OuterXml;

                    //update the child workflow association in the database
                    currentWebPublishingList.UpdateWorkflowAssociation(currentWorkflowAssociation);
                }
            }

            //make sure you dispose of the parentWeb object
            parentWeb.Dispose();
            
        }

        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
        }

        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
        }

        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
        }
    }
}

I just updated the Ajaxify MOSS codeplex release to include the needed web.config entries for using the .Net 3.5 version of System.Web.Extensions.

There is, however, one manual step you still have to perform to the web.config files in order to get this to work right. You still need to add the dependentAssembly elements to the configuration/runtime/assemblyBinding element, as shown below:
 

I tried a whole bunch of different ways to get the xpath in the SPWebConfigModification object to try and get it to work, but I think the problem is that it's either too ambiguous because there's no unique identifier available on the dependentAssembly element, or the namespace on the assemblyBinding element is causing problems.

All the other entries are being applied correctly, though.  Also, I try and help out a little by outputting the nodes in the stsadm command output after the nodes are applied :) - see:

Just mark and copy the lines from there, and you're halfway there.

The command names are on the releases tab in the codeplex project.  If you're upgrading from the ASP.Net AJAX 1.0 framework, make sure you uninstall the config mods first, before you add the 3.5 config mods.

Final note: I hope to be adding the needed lines for SilverLight pretty soon.

A few days ago, I mentioned that we're trying to automate as much as possible in our new SharePoint based product, and I explained how we are creating custom search scopes in a Feature Receiver.

Another component we're automating is the creation of Crawl Rules for the search engine in the SSP the site collection is associated.

According to MSDN crawl rules are defined as follows:

Crawl rules provide you with the ability to set the behavior of the Enterprise Search index engine when you want to crawl content from a particular path. By using these rules, you can:

• Prevent content within a particular path from being crawled. 

• Indicate that a particular path that would otherwise be excluded from the crawl should be crawled.

Here's how we're creating the crawl rules in code using a similar Feature Receiver as before:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.Office.Server.Search.Administration;
using System.Diagnostics;

public class FeatureReceiver : SPFeatureReceiver
{
    SPSite currentSite = null;
    public override void FeatureActivated(SPFeatureReceiverProperties properties)
    {
        //Debugger.Launch();
        this.currentSite = properties.Feature.Parent as SPSite;
        createCrawlRules();
    }

    private void createCrawlRules()
    {
        //get the site SSP's search server instance
        SearchContext searchContext = SearchContext.GetContext(this.currentSite);

        //For this example, I'll just show how to exclude the Explorer view of a list
        //Notice how we're using wildcard characters to specify that every /Forms/WebFldr.aspx page
        //    will be excluded regaurdless of protocol or location in the site collection
        string crawlRule = " *://*/Forms/WebFldr.aspx";

        //get the content source for the search server
        Content sspContent = new Content(searchContext);

        //check to see if the crawl rule exists, and create it if it doesn't
        if (!sspContent.CrawlRules.Exists(rule))
        {
            

            //create the crawl rule, setting the type of crawl rule and the crawl rule string
            CrawlRule crawlRule = sspContent.CrawlRules.Create(CrawlRuleType.ExclusionRule, rule);

            //we want to make sure that the rule still works if there are querystring variables
            crawlRule.FollowComplexUrls = true;

            //at this point, you can set other properties such as authentication information to crawl
            //    content using a different identity or authentication method
            //    for more info , check out http://technet.microsoft.com/en-us/library/cc263150(TechNet.10).aspx

            //commit the rule in the database
            crawlRule.Update();
        }
    } 
public override void FeatureDeactivating(SPFeatureReceiverProperties properties){} 
public override void FeatureInstalled(SPFeatureReceiverProperties properties){} 
public override void FeatureUninstalling(SPFeatureReceiverProperties properties){}       
}

I've recently been working on a SharePoint project which is being offered to clients as a product built on top of the SharePoint framework.  While I can't describe in too much detail exactly what the product is, I figured it might be beneficial to discuss how we've built out certain aspects of the solution.  At the very least, I can compile some notes of my own so I can remember later how tackled some of the issues we had during the dev process.

To give a little background on the product, at the core, this is primarily a publishing-based solution that is deployed into a site collection. One of the goals in the development of the product has been to automate the creation of the site collection as much as possible when a new client purchases the product.  We're handling the bulk of the new client deployment through a Feature called 'Product.SiteConfiguration' that when activated, executes a Feature Receiver that both creates some higher-level components and populates 'default' data in areas of the site that are required for the product to function properly.

One of the things we're creating in the SiteConfiguration Feature Receiver is a locally defined, custom search scope that is specific to the site collection of the product. A search scope allows the narrowing of search results based on rules defined within the scope, so we wanted to create a scope that is specific to the product so that when a user searches from the product's generic search box, only items from within the product are returned.

Here's sample code used to create a new scope in a site collection:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
using Microsoft.Office.Server.Search.Administration;
using System.Diagnostics;

namespace LocalDev.Demo.Code
{
    public class SiteConfiguration : SPFeatureReceiver
    {
        SPSite currentSite = null;

        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            string scopeName = "ProductScope";

            this.currentSite = properties.Feature.Parent as SPSite;
            
            //get the site SSP's search server instance
            SearchContext searchContext = SearchContext.GetContext(this.currentSite);

            //get the current scopes defined in the search server
            Scopes scopes = new Scopes(searchContext);

            //create a URI object for the current site - used in checking for the scope we're creating
            string siteUrl = this.currentSite.Url;
            Uri siteUri = new Uri(siteUrl);
            
            //create scope object for the new scope
            Scope newScope = null;

            try
            {
                //this is a little bit of a hack, but if it bombs, we know the scope doesn't exist
                newScope = scopes.GetScope(siteUri, scopeName);
            }
            catch
            {
                //create the new scope
                newScope = scopes.AllScopes.Create(scopeName, scopeName + " Description", siteUri, true, "/_layouts/product/customsearchresults.aspx", ScopeCompilationType.AlwaysCompile);

                //create the scopes rules for the new scope
                //for example, include content from the site
                newScope.Rules.CreateUrlRule(ScopeRuleFilterBehavior.Include, UrlScopeRuleType.Folder, siteUrl);

                //save the changes to the SSP Content Database
                scopes.Update();

                //start compilation of the scope
                scopes.StartCompilation();
            }

        }

        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
            
        }

        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
            
        }

        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
            
        }
    }
}