I could play a game of “state the obvious” and say that SharePoint 2010 search is powerful. It’s really an incredible beast - and that’s even without any FAST goodies in there. But something that isn’t obviously supported OOTB but seems there’s a few people out there trying to do - search within folders, or in my case, Document Sets. SharePoint search was already configured and, actually, I could search within document sets, by doing a site wide search and then using the refinement panel (on the left hand side of a search result page in a search center) to narrow it down to my document set. What I wanted to do was perform this search directly from a search box.

As you use the refinement panel, you’ll notice that the URL changes, as you stack up the filters, and as it happens, that’s all that’s required is a properly crafted URL:

<br /> http://yoursite/_layouts/OssSearchResults.aspx?k=[searchterms] <strong>site:"http://yoursite/yourlibrary/yourdocset"</strong>

Note the highlighted part - you can restrict your search results to a specified document set (or folder) by supplying the URL in to the site: refinement option/filter.

With that bit taken care of, the challenge was to get a searchbox that would do this dynamically - i.e., craft the URL properly to apply the filter and direct through to the search results page properly. It’s possible using a standard search box and the trusty old Content Editor.

Event receivers enable you to run some action when a particular event occurs. For example, every time a new item is added to a list, you may want to run some code, or start a workflow. This is really handy - but be aware of some gotchas. SharePoint event receivers will generally be one of two types - an “-ing” event or an “-ed” event, such as ItemAdding or ItemAdded. As their name suggests, an -ing event runs whilst the the event is happening (and might therefore give you the option to cancel it) and -ed events occur after the event has occurred. You need to be aware of how these events run. Generally, the -ing events run synchronously, that is, they are blocking and run in the same thread/cycle that they were generated in, and -ed events run asynchronously, meaning the opposite - they are not blocking - they will be run in a separate thread and not block the execution of the main thread. You therefore need to be aware of what info may, or may not, be available to you when you run code in an event receiver.

This had me stumped for a while. I was developing a SharePoint-based client to consume a simple web service. I started by writing a console app version of the code before deploying to SharePoint. Fairly straight-forward - added a web reference to my VS2010 project, and used

MyWebService srv = new MyWebService();
srv.DoSomething();

Early on in the project, I didn’t give much to the fact that when calling the method on the web service, I was given a 407 Proxy Authentication Error. I just setup a simple proxy for it:

The Content Organizer (gah! Organiser!) in SharePoint 2010 is a nifty new feature that enables documents to be added to a single library (the “Drop Off Library”) and then let SharePoint route them through to the correct final resting position based on a set of configured rules. Rules can be configured per content type and allow conditions to be set based on metadata on the item. You can even use it to send documents - and document sets - between site collections, e.g., to a Records Center. Very cool.

Depending on your requirements, you may find you need to create a lot of rules which as with most things SharePoint can be cumbersome if you need to do it all through the UI. Fortunately, creating the rules programmatically is straight-forward.

I needed to quickly find all files in a particular web that were checked out. I immediately went to Powershell, and after hacking about for a few minutes did what I should have done first - Google’d it. Doing this revealed that Gary had already done the bulk of what I needed to do. However, I made a couple of changes, namely that I only wanted it to traverse a specific web, but I needed it to traverse any subwebs in that web and lists.

This may be handy when trying to find specific items in a list based on values of various fields:

$web = Get-SPWeb http://yourweb
$list = $web.Lists["Your Library Name"]

// this is the bit - get items of a particular content type
// ? is shorthand for where, and $_ is the item in the pipeline
$listItems = $list.Items | ?{$_.ContentType.Name -eq "Content Type Name"}

// or items based on a custom column - if using -like then the wildcard is *
$listItems = $list.Items | ?{$_["InternalFieldName"] -like "*this*"

// you could join them up using -and
$listItems = $list.Items | ?{$_.ContentType.Name -eq "Content Type Name" -and $_["InternalFieldName"] -like "*this*"

// or iterate the loop and print them out
foreach($item in $listItems) { Write-Host $item.Name, $item["InternalFieldName"] }

or more directly

$list.Items | ?{$_.ContentType.Name -eq "Content Type Name" -and $_["InternalFieldName"] -like "*this*" | foreach { $_.Name, $_["InternalFieldName"]

// or count them
$listItems.Count

or

$list.Items | ?{$_.ContentType.Name -eq "Content Type Name" -and $_["InternalFieldName"] -like "*this*" | foreach {$count++}
$count

Powershell can be infuriating - but when you find the syntax, it can be pretty helpful.

If you’re using SSRS in SharePoint integrated mode, you may come across this error when using report parameters that have a high number of items in them. A recent security bulletin highlighted some issues and vulnerabilities in ASP.net, and a patch was released to cover some of the items. One of these was the maximum number of items you can have in a collection. If you exceed the limit, then you’ll likely get an error like:

You may be trying to set up SharePoint 2010 to act as the report repository for SQL Server Reporting Services report. This is a pretty nifty feature, especially as it’s available in the Foundation (i.e., Free) version of SharePoint. There is a pretty exhaustive guide on how to set it up and for extra help, this blog post is pretty good too, and if you follow the steps, you get pretty far. However, if you’re in a multiple server setup (i.e. your SQL server isn’t on the same server as your Central Admin) you will likely encounter configuration issues surrounding authentication, and there is a great deal of confusion about what it all means - especially when it comes down to Kerberos. That’s beyond the scope of this post - what I’m covering here is one very annoying issue that there was no definitive answer to on the web.

Assuming you get all the server parts setup and Reporting Services configured, you might find that you can browse to your report server address on the machine hosting reporting services, but, if you try to browse to that address from anywhere else, you’ll get an endless stream of login boxes, and no credentials will work. Also, if you go to Central Admin and go to General Application Settings > Reporting Services Integration, when you fill in the details to connect to reporting services, you’ll hit an error like:

Failed to establish connection with report server. Verify the server URL is correct or review ULS logs for more information. Product area: SQL Server Reporting Services, Category: Configuration Pages

and, in the ULS logs, an error like:

SQL Server Reporting Services Configuration Pages Failed to retrieve RS configuration information: System.Net.WebException: The request failed with HTTP status 401: Unauthorized.

Here’s how I fixed it my workaround.

Another example of “when SharePoint goes wrong.” On a dev machine, the search service mysteriously stopped working. I can’t pinpoint what caused it, but SP1 and a CU were recently applied and these seem like good candidates for breaking things. When trying to admin the search service, you would see the following error:

The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component ’{guid}′ in search application ‘Search Service Application’ is in a good state and try again.

…and trying to modify the topology of the search, resulted in a spurious error:

An unhandled exception occurred in the user interface.Exception Information: Exception has been thrown by the target of an invocation.

Something was clearly unhappy. Rather than waste too much time, the simplest solution seemed to be to delete the search application and recreate it, which I duly did, via Central Admin, verified that DBs and application pools disappeared and recreated the search application, using new names and credentials. Same error. I wasted spent some looking at permissions and the usual array of logs, events and other candidates, ran PSConfig and other upgrades, all to no avail.

I figured I could create the search application via Powershell. Why should this make a difference? No idea, but worth a shot. Then thankfully, I found that someone had already done it for me. And yes, this resolved the issues. I can’t explain why seeing as this script shouldn’t do anything that the GUI doesn’t do.

Script:

I just tripped over this problem, and despite a fair amount of Googlage, I didn’t find anything that directly resolved my issue. I was trying to use dbMail in SQL Server 2008 to send an email on a schedule which included the results of a query. Doing this should be fairly straightforward, by executing the sp_send_dbmail stored procedure, which is in MSDB:

This query works fine in SSMS, but when run as a SQL Server Agent Job, it fails, with the error