Whilst doing so though I happened to come across a really great resource on MSDN for SharePoint Enterprise Search queries – showing what is possible and the various ways of doing so. Did you know for example that you can define synonyms in your query, e.g.:

WORDS(TV, Television)

Or that you can’t include any white space between the property name, property operator and property value when restricting by specific property, e.g. this will not restrict to results authored by me:

author: “Glyn Clough” – note there’s a space after the colon!

So mostly for myself, but also in case this is valuable to you – here are the relevant links:

• Free-Text Keyword Queries
• Property Restriction Keyword Queries
• Using Operators in Keyword Queries

I definitely recommend giving these a skim to refresh your memory on just how powerful SharePoint Search is!

Fortunately the job history is available to access through PowerShell. I found this TechNet forum post which pointed me in the right direction, and also a useful blog post and script by Dave Hancock. (Dave’s script looks like it does exactly what I needed but unfortunately I had issues getting it to run).

So, below is a script I’ve put together which I run in the Windows Integrated Scripting Environment to output a grid view of all timer jobs between two dates and times, for all web applications in the farm:

Update 19/12/2011: I’ve made a small modification (at the suggestion of Jaap Vossers) so that the script now lists any jobs that either start in the specified range, or end in the specified range.

cls
# Add SharePoint cmdlets reference
Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue

function Get-TimerJobs {
    param(
        [DateTime] $startTime,
        [DateTime] $endTime
    )

    Get-SPWebApplication | foreach {
        $_.JobHistoryEntries |
             where{ ($startTime -le $_.StartTime -and $_.StartTime -le $endTime) -or
                    ($startTime -le $_.EndTime -and $_.EndTime -le $endTime) } |
                sort StartTime |
                select JobDefinitionTitle,WebApplicationName,ServerName,Status,StartTime,EndTime,@{Expression={($_.EndTime - $_.StartTime).TotalSeconds};Label="Duration (secs)"}
    }
}

$startDate = Get-Date "15/12/2011 11:00 AM"
$endDate = Get-Date "15/12/2011 11:50 AM"

$results = Get-TimerJobs -startTime $startDate -endTime $endDate
$results | Out-GridView

Which gives an output like the below (I’ve removed server name and web application name from the screenshot) from which I can easily spot if there are any failed jobs or jobs that took an unusually long time:

However, what if there’s an issue that you want to track down that doesn’t result in the error message being displayed? E.g. perhaps something isn’t firing when it should and you need to track down this “non-event”.

Well, thanks to a little trick gleaned from working with the talented Jaap Vossers, I’ve seen that this is easy to do! Fiddler is an invaluable tool for all web development, and SharePoint is no exception. What is really useful in this scenario is that SharePoint returns the Correlation ID as a HTTP response header – as you can see in the screenshot below the SPRequestGuid is what we’re after.

The technique goes something like:

1. Get a count of how many items to choose a random item from, say RowCount
2. Return a random number between 1 and RowCount
3. Use that random number to display a list item

The important bit is discovering/ remembering that there is a function available to use in SharePoint in the ddwrt namespace that generates a random number between two given numbers. It is this ddwrt:Random(1, RowCount) function that allows us to achieve our objective.

The XSL could look something like this:

<xsl:stylesheet
  version="1.0"
  exclude-result-prefixes="x d xsl ddwrt"
  xmlns:x="http://www.w3.org/2001/XMLSchema"
  xmlns:d="http://schemas.microsoft.com/sharepoint/dsp"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime">
  <xsl:template match="/">
	<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row" />
	<xsl:variable name="RowCount" select="count($Rows)" />
	<xsl:variable name="RandomNumber" select="ddwrt:Random(1, $RowCount)" />

	<xsl:for-each select="$Rows[position() = $RandomNumber]">
		<xsl:value-of select="@Title" />
	</xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

Note, even though we’re only displaying a single item we are still querying and returning potentially many items. For this reason I’d only recommend using this technique on relatively small lists.

 
Hmmm. Now leaving aside the intelligent conversation the interesting thing here is that Tristan has a photo associated with his account, but yet I can’t see it? Why not?
 
Well it appears that Tristan’s Lync contact card details are synced with an on-premises Active Directory, and that this is where the photo property is being set. Tristan is using what I believe to be the default setting of ‘Default corporate picture‘ in his Lync client, and not explicitly providing a public web address to a photo.
 

 
I think the interesting observation from a user perspective here is that when Tristan is using Lync with guys inside his organisation then they can see the corporate pictures and yet people outside the organisation can’t. However, as Lync Online easily allows me to create a contacts list with people both in and outside my organisation one may be expecting all of the contacts to have a similar experience. To ensure that consistent experience then it appears that the option to show a picture from a web address needs to be chosen.
 
So what does this mean? Well first up, I think it’s just something that if you’re federating your AD to Lync Online it’s good to be aware of. On a technical level then I’m guessing that it means that the AD user picture (thumbnailPhoto?) isn’t included as part of the federation – and perhaps is never likely to be because it’s stored as a BLOB. To get consistency perhaps some form of one-off sync could be used or maybe store a public URL in AD? I don’t know, but maybe somebody out there can work it out; Tristan…?

Assuming that you have access to the logs it’s actually quite a straight forward process to see the query that’s being used. Here’s an example:

First I’ll create a CQWP on a page which simply goes away and gets all pages across the site collection which have ‘Glyn’ in the title and where created after the turn of the year. I set this up like so:

Having done this I can now see the results as I expect:

Now assuming that I want to view the underlying CAML query that is used for this web part I simply have to look in the log files. To do this I use the essential ULS Viewer, and open up the logs so that I can see real-time results (having first ensured that I have temporarily increased the logging level to ‘verbose’).

Next I simply add a filter to the logs to see entries where the message field contains the string “<where>”. I could also filter by the Product: Web Content Management and the Category: Publishing. From here I can actually see the CAML query that is being used for my web part!

Stripping out the relevant bits of the CAML I see that in my example the query looks like this (note how it uses the GUIDs of the field names):

<Query>
	<Where>
		<And>
			<Gt>
				<FieldRef ID="{8c06beca-0777-48f7-91c7-6da68bc07b69}" Nullable="True" Type="DateTime"/>
				<Value Type="DateTime">2011-01-01T00:00:00Z</Value>
			</Gt>
			<Contains>
				<FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Nullable="True" Type="Text"/>
				<Value Type="Text">Glyn</Value>
			</Contains>
		</And>
	</Where>
	<OrderBy>
		<FieldRef ID="{8c06beca-0777-48f7-91c7-6da68bc07b69}" Nullable="True" Type="DateTime" Ascending="FALSE"/>
	</OrderBy>
</Query>

I’ve therefore added this post to my series:

• View settings lost on saved XSLT List View Web Part
• Content type enabled list XLV can’t be added to sites
• XSL Link Property and the ECB Menu
• Multiple web front ends, conflicts and the XLV
• Unable to use folders with cross-site XLV (this post!)

The Bug

This is a very straight forward bug to describe. You place an XSLT List View Web Part of your document library onto a different site than where the library resides – perhaps by saving the web part into the gallery through SharePoint Designer, or perhaps by creating the .webpart file manually. After doing so you try to click on a folder item to see the contents of that folder in your XLV – as per the expected behaviour. In doing so you get to see an error message like this:

This error seems to occur no matter if you add the web part through SharePoint Designer or via the browser.

Example

Here’s an example of this in action. I’ll first create a document library containing a folder. Using SharePoint Designer 2010 I’ll then save a web part to the gallery for this document library. Adding this web par to the site where the library exists via the browser and I get the web part, fully functional, as expected.

Now, I navigate to a different site and add the web part again. At first glance it appears that everything is working as expected – however I then click on a folder to view the contents of that folder. BOOM – that’s where I see the error message shown above.

Explanation & Workaround

I haven’t been able to find the root cause of this issue – however my suspicion is that this is an error in the out of the box XSL. This is because the error message seems fairly clear that it is looking in the ‘wrong place’, i.e. in the current site rather than the library’s site. This feels like an error that could be foreseen/ bypassed in the XSL to me.

In terms of a workaround then I’m stumped again unfortunately. The only option I can think of is to avoid the situation by setting up your view to not sure folders – which is less than ideal.

The series will consist of:

• View settings lost on saved XSLT List View Web Part (this post!)
• Content type enabled list XLV can’t be added to sites
• XSL Link Property and the ECB Menu (published in May 2011)
• Multiple web front ends, conflicts and the XLV
• Unable to use folders with cross-site XLV

The Bug

Having configured your list view exactly how you need; possibly having spent a while adding/ removing columns, choosing sort orders and filters etc you now decide that you want to re-use all your effort by having exactly the same XLV on a different page, or even site.

The first step is to export your web part. This can be done via SharePoint Designer 2010 or by the XLV export/ import method that I’ve previously posted. You now try and add your web part to a page using the browser, i.e. not using SharePoint Designer.

Immediately after adding the web part everything is looking great – the list view is displayed exactly as it was on wherever you exported it from. Now you hit Save or Check In… and the XLV reverts to the default view on the list! Your carefully configured view has just been lost – and that’s the bug

Example

Here’s an example of this in action. First I add a simple custom list to a page, modify the view and, just because we can, jump into SPD 2010 to add some custom formatting:

I now use SharePoint Designer to export the web part and add it to the gallery:

Now, I go back to the browser, create a new page and add the web part. There’s my nicely configured view…

But now I hit save on the page and BOOM there goes my view back to the default on the list:

So my view has been changed, including my sort order and columns chosen to display – but strangely my custom formatting is still there! What is going on…

Explanation

I lack the skills to step through the underlying code of what exactly happens when the imported web part is attempted to be saved back to the page – however I think we can infer a few things from the behaviour and by inspecting the web part properties (of an exported XLV).

Firstly – why is the custom formatting still there, plus the web part title, chrome settings etc etc. Well I think we can confidentially assume that those particular properties of the web part are persisting. Looking at the .webpart file of an XLV we can find the corresponding properties and their values.

So where are the view settings defined in the properties. Well, I can only assume that this is in the property called XmlDefinition. Looking at this property we can see that it defines the CAML necessary for the view – plus it seems to reference an actual view on the list itself…

I found this excellent post by Stefan Stanev who goes into a great amount of detail explaining that when you add a list view web part to a page there is actually a view created on the list itself! The view is set to hidden and so you never know it’s there – but it’s fascinating that it exists.

Now we think we know that the XmlDefinition property is where an XLV gets its view settings from we should be able to use this to give an XLV a particular view which can be imported again and again right? Well, you’d think so… but unfortunately I haven’t been able to get it to work yet.

It feels like I’m tantalising close to working this out – but then hey, why should I have to? I can add an exported XLV into the gallery using a supported tool like SPD. When adding to a page this then appears to take on the view settings, only to have them lost on saving a page. That sounds like a bug to me!

Workarounds

The (only slightly) good news is that you can use SharePoint Designer to add a web part to the page and it will remember the view settings! Obviously there is something going on behind the scenes different to what happens when adding through the browser.

Another option is to set the default view on the list to be the same as your web part view – and then this will be the view used when adding the web part.

[This was done on SP2010 RMT – I haven’t looked at SP1 yet]