Intergen wins Enterprise Content Management category at Partner Awards

A couple of weeks ago Microsoft New Zealand had there annual Partner Awards. I am pleased to announce that we won the Business Productivity Enterprise Content Management Solution of the Year award, based on the work we did building the New Zealand Trade and Enterprise SharePoint website. Microsoft received nearly 100 applications, and there were 17 categories to be won.

The NZTE project was significant in a number of respects. It was one of the country's first truely successful public-facing SharePoint sites, and has received notable commendations and favourable reviews within the industry, and from NZTE itself. NZTE's CEO, Tim Gibson, says: "The new website is fantastic, and is going to be an important part of our delivery as an organisation going forward."

This was a huge effort by all involved an one that I personally take a lot of satifaction from.

Microsoft Office SharePoint Server (MOSS) Content Deployment

Content Deployment is a powerful part of Microsoft Office SharePoint Server (MOSS). It can also be a bit of a challenge in highly customised environments. Recently I had the task of enabling Content Deployment in an Internet-facing situation.

The situation was pretty typical. An Internet-facing site that contains content authored by people on an internal network separated by a firewall. The internal authors need to have the ability to author, edit, and approve content, but also ensure that this environment is shielded from incoming Internet traffic for security purposes.

The brief was to enable content deployment between a site on the client's internal authoring environment and a publicly accessible site in their external DMZ publishing environment. Content deployment needed to run an incremental deployment every hour and a full deployment nightly.

We had some initial problems but managed to overcome these. This is a record of what happened and how we solved these issues.

A little disclaimer: It is very important that any custom developed components are created in-line with SharePoint best practice. Shortcuts in this area will lead to a lot of extra effort further down the track.

Content deployment does not deploy any custom code or file system artifacts. These components have to be present in both the Internet-facing and internal authoring environments for content deployment to succeed. In our situation we had a couple of masterpages, a number of page layouts, and about 20 odd SharePoint custom field controls. Most of the issues we encountered were around the custom field controls.

SharePoint Content Deployment has 3 distinct stages, exporting from the authoring site, transporting to the Internet-facing site, and finally importing at Internet-facing site.

1) The first problem we encountered was that we could export our content successfully from our authoring environment but were unable to import this content into the Internet-facing site.

This was solved by deploying our custom code or file system artifacts to the Shared Services Provider (SSP) on the destination farm.

2) We then had a requirement to add validation to the custom field controls. We followed an article on MSDN (http://msdn.microsoft.com/en-us/library/ms434697.aspx) to implement validation. The first approach in this article suggested that we validate the actual field. This method of validation worked perfectly in the authoring environment. However we encountered problems when we were importing into the destination Internet-facing site.

This was solved by changing our validation strategy to only validate the UI of the control (see second approach in the above article). Theoretically any value could be saved to the field, but if you were using the user interface to save a value (which the content authors were), then only certain correct values could be saved.
What we observed was that by validating the actual field rather than just the UI of the control we were crashing the content deployment process.

3) About this time we were worried about our ability to debug future Content Deployment issues. We investigated ways of using the API to create a Custom Content Deployment application, and can be seen in action in the SPDeploymentWizard codeplex project(http://www.codeplex.com/SPDeploymentWizard).

This was pretty easy to do. We created a console app with some configuration switches to change Import/Export, and logging levels. The major advantage with this is that you can configure the app to have much more verbose logging than is typical with SharePoint OOTB. Basically you can print a line for every object that is being exported and can find the exact object that is causing the deployment to fail.

4) We then created and deployed two new custom field controls, and again the content deployment stopped on the Export.
The controls were created in exactly the same way as the previous controls. If we excluded the controls the content deployment worked fine. The controls were definitely deployed correctly as we could use them within the authoring environment.

To fix this we restarted all the servers. I noticed an error occurring from some code that was no longer present within our solution. I could only infer that SharePoint Content Deployment was caching a temporary version of the DLL somewhere. The restart flushed this cache, and content deployment started immediately.

This didn't take too long to write down but took a while to work out at the time. Hopefully this is useful for someone when they are in the process of enabling content deployment in the future.

New Zealand Trade and Enterpise SharePoint WCM site is now live

We have been hard at work on the new New Zealand Trade and Enterprise website (www.nzte.govt.nz). This has been my first publicly accessible SharePoint WCM website, after working on a couple of WCM extranets.
This was a huge challenge leading a big development team with a short timeframe and a lot of functionality to pack in.

Check it out and let me know what you think.

We learnt a lot on this project so I'll try and get a few posts up over the next month.

Uncustomized (Ghosted) Vs Customized (Unghosted) Files within SharePoint

I beleive that understanding the differences between Uncustomized and Customized files is the key to uncovering the power of the SharePoint platform.

It is what enables SharePoint to provide a rich configration interface for the "power user" but at the same time provide a mechanisim for a more traditional development approach.
It is also the most mysterious part of SharePoint to any new developer as this concept does not really exist in the standard .NET world.

Here is an attempt to explain the difference:

Both Uncustomized and Customized files live within the logical structure of your SharePoint site and hence in the Content Database(both types of files can be seen from within SharePoint designer). However the difference is that with a customized file the "complete file" exists within the content database whereas the uncustomized file the entry within the content database is really just a pointer to a "file" on the physical file system(under the /12 directory).

This "file" could also be thought of as a "template file" and you can have multiple Uncustomized files within your SharePoint site pointing at a single "template file".

This is the area where SharePoint comes to the party for developers and enables us to do things such as easily move content through environments(DEV-> UAT-> PROD as we can move physical files much more easily than the complex database entries of a customized file) and also make changes to SharePoint sites in a centralized place. Lets say you create a new uncustomized "template file" and users use this template to provision 100 pages. Now the business requirements change and we need an extra control on this page. If this were a customized page we would need to add the new control to all 100 pages that are stored within the database. This is a real nightmare. However with uncustomized pages all we need to do is add the control to the "template file" on the physical file system and we have 100 pages immediately satisfying the new business requirement.

The Customized file really tells the story for the "Power User" or "Information Worker". This is where the power of SharePoint Designer comes into play.
A customized file can be created in a couple of different ways.
Firstly you create a customized file by using SharePoint Desginer to modify a template file like the ones mentioned above. The changes you make are now stored in the database and SharePoint no longer looks at the file system based file.
Alternatively you can create new SharePoint content directly in SharePoint Designer, for example a new page layout. This new layout is stored directly in the database.

Obviously this is very powerful as we can now remove developers from the equation, and SharePoint gives the Information Worker the ability to rapidly and extensively change the makeup of the site.

Getting the balance right is one of the fundamentals to any good SharePoint project. Too much work with customized files excludes some the nice things such scalability inherent in the development approach, not enough work with customized files and we find that business owners are not getting all the promised benefits of the SharePoint platform.

A compliant navigation control for SharePoint.

Following on from my post about creating a MOSS WCM website using a div based layout, I am going to describe a simple way to create a web standards compliant navigation control.

One of the short comings of the sharepoint:aspmenu or the asp:menu control is that they render horrible table tags. By using CSS adapters (Check out CSS Friendly) we can still take advantage of the built in controls but render the output in div and ul, li tags to create our site navigation. I use the MOSS PortalSiteMapProvider as my site map provider.

1) Firstly I created an empty class definition (MyMenu) that inherits from System.Web.WebControls.Menu.

 
public class MyMenu : System.Web.WebControls.Menu
{
}

This is done so that we have explicit control over which controls are adapted. If we decided to adapt the System.Web.WebControls.Menu directly all controls of this type would get rewritten even if we didn't want them to. This happened to me the first time I tried it in SharePoint, I ended up modifying every menu in the site including the Site settings and Application pages, obviously these are will not be seen by the anonymous user, hence I am not concerned by the fact they render in table tags.

2) Download the CSS Friendly Adapters either download the source code and sign the assembly (we can now place the code in the GAC) or place the binary in the Web application /bin folder. You may have to raise the trust level in the Web.config also.

3) Create a .browser file that adapts our control in 1) using the adapter in 2) an example of this is shown in the CSS Friendly project.

4) finally I wrapped the MyMenu control and PortalSiteMapProvider into a SharePoint ControlTemplate ascx. This was done to a) to keep my master page clean and tidy, and b) to remove some of the complexity of configuring the site map provider for future reuse.

5) Add the control template to the masterpage.

6) We can now style the control as normal using our custom .css file.

For more information and a tidy implementation of adapting a "wizard" control check out Toke's blog post here.

A pattern for creating a MOSS WCM website

Recently I have been working on MOSS WCM websites. I have developed a successful pattern to create branded websites where the design team doesn't need any specific SharePoint knowledge or experience to create great looking layer(<'div'>) based sites.

1) Created a Site Defintion based on either the STS Blank Site Definition or the base Publishing Site Definition.

2) Create a feature stapler to staple new fuctionality to the new Site Definition. By using a feature staple we can remove the complexity associated with creating Custom Site definitions.

3) Create a "Masterpage Feature"; this feature adds a new (<'div'>) based masterpage extending minimal.master, and a alternate .CSS file to the _catalogs/masterpage library as "ghostable" files.
The feature assigns the .master and .css to the site.
Because the files are set as ghostable all changes affecting sites using this def can be made to a single instance of the .master and .css file in the Feature folder. (This alternate .css file is the last .css rendered in the CSS hierarchy; this means the creative designer can create all their own classes that relate to the .master and effectively ignore all of the OOB SharePoint styling)
This feature also removes the default Page Layouts and stylesheets that get put in the "Style Library" library by default.

4) All creative resources can now be deployed using a Solution to the 12/TEMPLATE/IMAGES/ folder and referenced in the .CSS file


Result; we now a have beautiful a div based site, and the creative designer doesn't need any SharePoint specific knowledge.