The other requirement was that the Title of the Web Part should be that of the current site, so Information Technology if the user was view pages from that site, Operations for the Operations site etc.

Out of the box, this would not be possible as the CQWP is linked to a single library and it’s Title is set from the Web Part Properties. You obviously could add a CQWP to each page but this is inefficient and beyond most content editing users. So for a more elegant solution you’ll need to use Visual Studio to create your own Web Part, however the code is extremely straightforward and is derived from ContentByQueryWebPart. You will need to include a reference to Microsoft.SharePoint.Publishing.WebControls in your project which is in the Microsoft.SharePoint.Publishing namespace and the code below should be enough to get you up and running.

public class ContentNavigation : ContentByQueryWebPart
{
 protected override void CreateChildControls()
 {
   SPWeb web = SPContext.Current.Web;
   SPList list = web.GetList(web.Url + "/Pages");
   this.ListGuid = list.ID.ToString();
   this.ListName = list.Title;
   base.CreateChildControls();
 }

 protected override void OnPreRender(EventArgs e)
 {
   this.Title = SPContext.Current.Web.Title;
   base.OnPreRender(e);
 }
}

Once packaged and deployed, it’s then straightforward to create a Page Layout containing this web part.

A lot of code examples use:

$(xData.responseXML).find("z\\:row").each(function(){

whilst this works in IE & Firefox, it won’t function in Chrome or Safari, but if you are using JQuery 1.5 or greater, change this line to the following and you’ll have a working solution in all browsers.

$(xData.responseXML).find("[nodeName='z:row']").each(function(){

It’s a problem I’ve come across a few times as it’s been around since MOSS.  It occurs if the relative path between site collections or web application is different and therefore breaks the link to PageLayout.  For example moving these pages:

http://sharepoint/sites/wiki/home.aspx

to a subsite

http://sharepoint/wiki/home.aspx

will result in an invalid relative link to the pagelayout, in this case it will be http://intranet/sites/wiki/_catalogs/…. so as you can see there is an erroneous sites reference within the link.

Initially it’s best to view the current Pagelayout assigned to each page, to do so you can use this script, replace [Site URL] with the url of the site containing your publishing pages.

$Site = "http://[Site URL]"

$web = Get-SPWeb -Identity $Site
$publishingWeb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)
$publishingPages = $publishingWeb.GetPublishingPages()
foreach ($publishingPage in $publishingPages)
{
  write-host $publishingPage.ListItem[[Microsoft.SharePoint.Publishing.FieldId]::PageLayout]
}

To resolve the issue, I wanted a flexible solution which could work with any pagelayout or even replace them if needed and therefore opted for a script which used a simple search and replace.   In the following script, update the [Site URL], the [Search for] for the string to search for, for example the old link and [Replace with] for the new value, such as the new site.

$Site = "http://[Site URL]"
$SearchFor = "[Search For]"
$ReplaceWith = "[Replace With]"

$web = Get-SPWeb -Identity $Site
$publishingWeb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)
$publishingPages = $publishingWeb.GetPublishingPages()
foreach ($publishingPage in $publishingPages)
{
  $url = $publishingPage.ListItem[[Microsoft.SharePoint.Publishing.FieldId]::PageLayout]
  if ($url -match $SearchFor)
  {
    write-host Updating Page Layout for $publishingPage.Name
    $newurl = $url -replace $SearchFor, $ReplaceWith
    $publishingPage.CheckOut()
    $publishingPage.ListItem[[Microsoft.SharePoint.Publishing.FieldId]::PageLayout] = $newurl
    $publishingPage.ListItem.UpdateOverwriteVersion()
    $publishingPage.ListItem.File.CheckIn("Corrected page layout URL", [Microsoft.SharePoint.SPCheckinType]::MajorCheckIn);
  }
}

First you need to create a new masterpage using SharePoint Designer, to do this take a copy of your existing custom masterpage or default.master and name it blank.master. Edit the file in Advanced Mode and find the main table which starts with <table class=”ms-main”.  Now add this style=”display:none” tag to the end.  It should look something like this:

<table cellpadding=”0″ cellspacing=”0″ border=”0″ width=”100%” height=”100%” style=”display:none”>

Next find this content holder <asp:ContentPlaceHolder id=”PlaceHolderMain” runat=”server”></asp:ContentPlaceHolder> and copy this to the clipboard, delete it from it’s original location and place it under the closing tag for the main table.  Also, to avoid scrollbars appearing in my iFrame, I amended to the body tag to set scroll=”no”.

Checkin, publish and approve your new masterpage.  Now if you haven’t already, create the content which you wish to host in the blank master page, then return to SharePoint Designer.  Next we need to detach the content page from it’s Page Layout, so open the library which contains your content, select the file, right click  and choose Detach from Page Layout then click Yes to the warning.  If the library is under source control, click Yes to check it out.  Now right click again and choose Edit file in Advanced Mode.

Now replace this line:

<%@ Page language=”C#” Inherits=”Microsoft.SharePoint.Publishing.PublishingLayoutPage,Microsoft.SharePoint.Publishing,Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c” meta:progid=”SharePoint.WebPartPage.Document” meta:webpartpageexpansion=”full” %>

with this:

<%@ Page language=”C#” MasterPageFile=”~/_catalogs/masterpage/blank.master” Inherits=”Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,Version=14.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c” meta:progid=”SharePoint.WebPartPage.Document” meta:webpartpageexpansion=”full” %>

Save the file and if all is well, you’ll see the content without branding and navigation.

As you can see from the changes, this content now inherits from Microsoft.SharePoint.WebPartPages.WebPartPage which enables the MasterPage to be set.  With Microsoft.SharePoint.Publishing.PublishingLayoutPage this isn’t possible without custom code overriding OnPreInit.

One drawback is that users have to review and approve/reject each item  individually and on a list with many items, this can be quick time consuming.  The way to implement this functionality would be a custom action on the ribbon and looking around the Internet, I found a great solution from Sohel Rana to do exactly this.

The only problem, was that this was not ready for prime time and as Sohel states, “The code is not just download-and-deploy mode. This is just a piece of how you can implement. You may need to fine tuning the code as per your needs. But I’ve tried to give the gist of how this can be done.” Therefore I decided to build on his ideas and create a new solution that is just download and deploy and has a more consistent SharePoint look and feel.

This is a farm solution, so it is deployed though Central Admin.  The feature is scoped at Web level so to enable this functionality active the feature in Site Features within Site Settings.

Once enabled you’ll find a new action on the ribbon bar which is active when multiple items are selected as shown below.

This will then create a dialog which uses the familiar SharePoint Approve/Reject item look and feel.

Clicking on OK will set all selected items to the approval status and the comment text is also applied to all items.  Any workflows that are in-flight on these items are cancelled.

You can download the solution here

This consumes a TfL datafeed so your server will need Internet access and the solution needs to be deployed at the farm level.  I’m not going to post how you can deploy this web part but a generic farm solution deployment guide can be found here.  I’ve tested this on SharePoint 2010 only but should work fine on MOSS too.

The code doesn’t use Ajax and there is no automatic refresh.  More information about lines with problems will appears on a mouse over on the status.  I’ve not included the source but happy to post if it helps anybody, and I am considering writing a tube departure board web part showing the trains from a configurable station, so if this is of any interest then please leave a comment.

Download Tube Status Web Part

Making the Organization Browser work in a web application other than MySite host

This is only required if you are not yet running SharePoint 2010 SP1 or later and are trying to add the Organisation Browser to a page which resides in a web application than does not house your MySite host.  In this instance it will appear blank, a problem that is caused by SilverLight security and the lack of a cross domain policy.  To over come this, a crossdomain.xml file  needs to be placed in the root of the web application where your MySite host resides.

A basic CrossDomain.xml file:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
	<allow-access-from domain="*" />
	<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>

This is a very liberal cross domain policy, in a production environment I recommend you limit the domain setting to suit your environment.

Copy the content above and save it locally as crossdomain.xml and then launch SharePoint Designer.  In SharePoint designer open the root site which hosts your MySite host and select All Files from the left hand navigation.  Click Import Files from the ribbon and add the CrossDomain.xml file you saved earlier. The end result should look like this.

In a browser test that you can access this file http://<mysitehost web application>/CrossDomain.xml, next test a page which contains the Organization Browser hosted on another web application, this should now render correctly in the SilverLight view.  The focus will be set to the current user, so unless you are the CEO, there is still a little bit of work to do.

Setting the initial focus of the Organisation Browser to a specific user.

So now you have a page containing the web part but you want to set the initial focus to the CEO or a department head, this is exactly how the web part works in the users profile when you click on Organization.  This is controlled by a query string parameter containing the account name that looks like this accountname=domain%5Cian%2Eankers. You will need to add this parameter for the user you wish to set the focus too to the links that reference your new page, for example OrgChart.aspx?accountname=domain%5Cian%2Eankers

However before this is going to work, the file hosting the web part needs to be edited in Advanced Mode using SharePoint Designer.  Open the page in Code view and under the last <%@ Register tag, add this line.

<%@ Register Tagprefix=”SPSWC” Namespace=”Microsoft.SharePoint.Portal.WebControls” Assembly=”Microsoft.SharePoint.Portal, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>

Next search for this line: <asp:Content ContentPlaceholderID=”PlaceHolderMain” runat=”server”> and directly beneath it, add the following.

<SPSWC:ProfilePropertyLoader runat=”server” />

Now save the file and you should now have the Organization Browser running in a separate web application and with the focus set to the user specified in the accountname query string  parameter.

The problem is caused by the Silverlight application, attempting to communicate with the WCF endpoint using the Client Object Model when Security Validation is turned off for the web application.

To resolve, in Central Administration click on Manage Web Applications, highlight the problematic Web application and click General Settings from the ribbon.  Scroll down to Web Page Security Validation  and ensure Security Validation is On 

You will now be able to create sites using the Silverlight interface.

If you are attempting to upgrade the Admin Content Database then Get-SPContentDatabase will not work, or at least it didn’t for me so refer to the extra steps at the end of this article.

The upgrade status reflects the current state of the database and hence this is not resolved via PSConfig but  rather by PowerShell.  If you need to perform this on a production or any other important environment, make sure you have an agreed maintenance window plus backups before beginning!

• Using the farm account or equvilently privileged user, start the SharePoint 2010 Management Shell
• Enter $DB = Get-SPContentDatabase -Identity [ Your Database Name]
• Now enter Upgrade-SPContentDatabase -id $DB
• You’ll now be prompted to confirm, just hit enter to accept the default of Yes
• The upgrade will begin and a percentage complete will be displayed

When the process completes, return to Manage Databases Upgrade Status in Central Admin and the status will not be No action required.

Upgrading the Admin Content Database

As stated at the beginning of this article, Get-SPContentDatabase will not work with the Admin Content Database so another method needs to be found.  As long as you know the DB GUID, you can still execute Upgrade-SPContentDatabase so a simple query of the Config database could be used to find this.  However a better solution is to use Powershell.

The following script iterates though all Content DBs for a given Web Application, so can be used to upgrade the Central Admin Content Database.  You will need to the replace <WA URL> in the script with your Central Administration URL.

$wa = Get-SPWebApplication -Identity "<WA URL>"
foreach($ContentDB in $wa.ContentDatabases)
{
   Upgrade-SPContentDatabase -id $ContentDB
}

Diagnosis

Open central administration and follow this procedure.

• Click Monitoring then Check Job Status under the Timer Jobs heading.
• Click Job History on the left hand side under Timer Links.
• On the right hand side, select failed jobs from the view drop down.

You’ll now see the most recent failed jobs on your farm and most likely this includes CEIP Data Collection.  If it does, follow the resolution below.

Resolution

For completeness it is worth disabling CEIP, first do this as the farm level.

• In Central Administration, select System Settings
• Click Configure privacy options under Farm Management
• Under Customer Experience Improvement Program, select ‘No, I don’t wish to participate’

Next this needs to be disabled for all web applications, including Central Administration.

• Select Application Management, then Manage Web Applications
• Select the first Web Application in the list and click General Settings
• At the very bottom of list, select No in the Enable Customer Experience Improvement Program
• Repeat for all Web Applications in the farm.

In theory, this should be sufficient to disable CEIP across the farm, however running SP1 and the June CU, you will find that the error still appears, therefore the last resort is to disable the Timer Job.

• Click Monitoring then Review  Job Definitions under the Timer Jobs heading.
• In the list, click on CEIP Data Collection.
• At the bottom of the page, click Disable.

The errors will not longer appear and although you could simply just disable the timer job to begin with, I feel it’s better to have the farms configuration set correctly too.