For some reason a new web application on my development VM always returns a 503 Service Unavailable when you go to it.
It turns out that this is due to the app pool supporting 32 bit applications! Change the setting in IIS (App Pool > Advanced Settings > Enable 32 Bit applications should be false)
I had a problem that one of our development machines had been configured in a ‘Least Privileges’ configuration – and it was a bit too least. The content app pool could not write to the logs. OWSTimer and WebAnalytics both could, but there was nothing from W3WP for that web app.
Just a reminder to myself…
Well, the solution was to add the app pool account to the ‘Performance Log Users’ group in AD. You find it under BUILTIN. Reset ISS. Voila!
A curious problem – Timer Jobs have a Title (which you can set), and a description, which you can’t set – as it has no setter:
This is a shame, as I like that you can see a description about the time job in Central Admin:
The solution – strange as it seems, override the Description property in your new timer job.
I had two of my colleagues come to me with the same complaint – that the Basic Search Center site template in SharePoint 2010 doesn’t have any navigation to get ‘back’ to the rest of the site collection:
I pointed out to them that there are good reasons to consider having the Search Center separated from the rest of your content. I’d even suggest a separate Site Collection if using the Enterprise Search Center. (This uses the publishing features, and you might not want them turned on in your existing site collection).
However, my colleagues didn’t need all that, and really did just want a simple search center in the same site collection as their content. For example, a departmental site collection needed its own search center and search experience. But they’d really like users to be able to navigate back to the rest of the site collection.
So, I set forth to fix this dire state of affairs for them. Continue reading “Annoying Navigation in Search Centers”
With SharePoint 2007, WSPBuilder became our standard packaging tool for SharePoint solutions. It was simple, powerful, and a damn site easier than trying to write your own manifest.
Well, SharePoint 2010 and Visual Studio 2010 followed later, and Microsoft introduced much better tooling of their own. However, we’ve still got a lot of code being packaged by WSPBuilder, and we didn’t want to have to refactor all those projects just to package them for 2010.
Fortunately, Carsten Keutmann wrote a 2010 version (still in ‘BETA’, but it works fine). It offers many of the same extensions to Visual Studio as the previous version did.
However, I recently had to automate (in Team Foundation Server 2010) the build of one of our WSPBuilder based solutions, and that’s where things got more interesting… Continue reading “WSPBuilder 2010 and TFS2010”
With SharePoint 2010, Microsoft gave us a better framework for logging that SharePoint 2007, which relied on writing most of your own. Sadly, though, the SPDiagnosticsServiceBase does lack in a couple of areas. Consequently, I’ve ended up writing my own Diagnostics service to try and address those issues. I am far from the only one (See the references below), but I’d like to present what I’ve written, not least ‘cos I’ve been meaning to blog about it for about 8 months.
First, though, let’s look at the limitations of the SPDiagnosticsServiceBase. Continue reading “My Logging Diagnostics Service for SharePoint 2010”
Something that has bothered me repeatedly in the past is that ListViewWebParts didn’t seem to allow their titles to be set via CAML. The View element for a site (i.e. in the ONET.xml file) doesn’t have a title element, and the ‘Name’ and ‘DisplayName’ elements don’t set the web part’s title. Instead, the ListViewWebPart always seemed to pick up the name of the list it referred to. This was a problem if you had a page that showed two ListViewWebParts refering to the same list. E.g.:
<View List="Lists/Tasks" BaseViewID="7" WebPartZoneID="Left" WebPartOrder="5" /> <View List="Lists/Tasks" BaseViewID="9" WebPartZoneID="Left" WebPartOrder="6" />
would result in:
How can we set those titles to be different? Continue reading “Set the Title of a ListViewWebPart”
A reminder to myself – there is a response header for SharePoint requests called the X-SharePointHealthScore. It indicates how stressed the server is with a score from zero (unstressed) to 10 (highly stressed). I first stumbled across it when debugging something in Fiddler, but others have written about it:
So how do we test the loadbalancer if we set it up in this fashion? Do we need to DDoS a WFE? There is a better way 😉 There is a registry setting that will override the Health Score and it will return the value from the registry.
Create a DWORD with the name ServerHealthScore in the following location: HKLMSOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0WSS and give it the value you want.
So what’s it useful for? Well, the main things that strike me would be:
When you run a CAML query, you have to specifiy a value you’re searching for:
query.Query = "<Where><Eq><FieldRef Name='MyField' /><Value Type='Text'>WhatILookFor</Value></Eq></Where>";
Well, that’s fine, but what about lookup columns? They actually have 2 elements – the text, and an ID.
E.g. You might have a lookup to a ‘Country’ list, and “United Kingdom” might be ID 45.
If I wanted to find items on my list that referenced the “United Kingdom” value, my query would be:
query.Query = "<Where><Eq><FieldRef Name='MyField' /><Value Type='Lookup'>United Kingdom</Value></Eq></Where>";
However, this doesn’t make much sense. The ID is our primary key to the ‘country’ list. Why are we querying by value? I mean, if the United Kingdom had a revolution and suddenly became, say, the ‘United Republic’, all of my CAML queries would break.
(That might be the least of my worries, but you get my point).
So, we’d like to query by ID. Well, you can – I’ve mentioned it before, and the MSDN documents neglect to mention it themselves. There is a property on the FieldRef of LookupId. Set that to True, and you can query by ID.
query.Query = "<Where><Eq><FieldRef Name='MyField' LookupId='TRUE' /><Value Type='Lookup'>43</Value></Eq></Where>";
Edit: One of my colleagues pointed out that in SharePoint 2010, if you update the text of a referenced item, it is updated within the items that reference it. This is different to SharePoint 2007, where the referencing items retained the original text value. He’s right – but I’d still prefer to query by ID as it’s indexed, unique, and simple.
For God’s sake, don’t reuse SPQuery objects!
Now, with that out of the way, let me explain. I’ve inherited some code. In that code, it’s performing a couple of queries on a List, using an SPQuery object. It’s querying a boolean column, and only one item in the list should be true. It’s a long story why, but that’s the way it is. The list is something like this:
The code needs to query this list for true items (which should only be one) and false items (which you can see above, is more than one). However, these queries didn’t seem to be working. Continue reading “Don't Reuse SPQuery objects!”
Andy Burns' Blog 