Corey Roth [MVP]

How to: Activate a feature on multiple site collections using PowerShell

CoreyRoth — Fri, 10 Feb 2012 02:40:37 GMT

A lot of times we have a need to activate a feature on multiple site collections. This could be a custom feature to do branding or you may simply be activating publishing on multiple site collections. PowerShell makes tasks like these easy. We’ll take what we learned from my original Activating Features with PowerShell post and use some common techniques to iterate through the site collections and activate the desired feature.

For this example, we’ll activate the SharePoint Server Publishing Infrastructure. The internal name of that feature is actually PublishingSite so we’ll start by using PowerShell to get a reference to that feature. We’ll assign the result of that value to a variable.

$feature = Get-SPFeature PublishingSite

If this is your first time working with this feature, be sure and test it by typing it into PowerShell to ensure that you are getting the reference to the feature correctly. Once you have the feature we can get a list of site collections. Retrieving site collections is simple.

$siteCollections = Get-SPSite

However, this will return every site collection from every web application. You probably want to limit it to a single web application using the –WebApplication parameter like this:

$siteCollections = Get-SPSite –WebApplication http://sp2010

We can then just use ForEach-Object to iterate through each site collection and then activate the feature. I use a pipe bind with the $siteCollections variable. Then I just use the Enable-SPFeature command passing it $feature for the feature and the Url to the site collection which we can get from the Url property of the $_ object. I also wrote some output to the screen so we could see which site collection was activating. Here is what the whole script looks like.

$feature = Get-SPFeature PublishingSite
$siteCollections = Get-SPSite –WebApplication http://sp2010
$siteCollections | foreach-object {
Write-Host "Activating" $feature.DisplayName "on" $_.Url
Enable-SPFeature $feature -Url $_.Url
}

Of course this works with deactivation as well too. I just updated the script to use Disable-SPFeature instead.

$feature = Get-SPFeature PublishingSite
$siteCollections = Get-SPSite –WebApplication http://sp2010
$siteCollections | foreach-object {
Write-Host "Deactivating" $feature.DisplayName "on" $_.Url
Disable-SPFeature $feature -Url $_.Url -confirm:$false
}

Note that I added –confrim:$false to the Disable-SPFeature line to prevent being prompted by the script.

This is a simple script that makes it easy to activate and deactivate features in bulk. This same logic could be applied to site scoped features as well if you had the need.

A look at the list editor in Visual Studio 11

CoreyRoth — Fri, 10 Feb 2012 01:28:10 GMT

I’ve written a number of posts in the last couple of weeks about the new SharePoint features in the Visual Studio 11 developer preview. These posts include publishing to SharePoint Online, Visual Web Parts, Silverlight Web Part, and the Content Type Editor. I’ll wrap up this series with a look at the new list editor. The list editor looks fairly similar to the content type editor actually. You start by choosing the List SharePoint Project Item from the New Item menu.

Selecting the List SPI will take you to the next screen where you have the choice of creating a new list which is based off of an existing list (i.e. tasks or document library) or to create a new instance of an existing list type.

Once it is complete, you will see the list editor where you can edit site columns and content types. The site column editor works very similar to the one used for new content types.

The only difference in this interface is that you can actually create new list columns here. If you click the Content Types button at the bottom, you will see a window allowing you to select content types from those available on the server as well as in your current project.

After you have set your content type, the site columns of the content type will automatically be added to the site column list. From here, you can click on the Views tab to edit the existing views (or add a new one). You’ll notice that all views are visible (including ones you normally wouldn’t touch). Be careful with what you do here. You can customize the columns in each view. Unfortunately, the user interface doesn’t give you any control over how things look, row groupings, or sort order though.

Finally, the Common Properties tab lets you set the title, URL, description, whether the list is hidden or not and on the Quick Launch bar.

Once you have finished your list, you can deploy it to a local SharePoint server or publish it to SharePoint Online. When you visit the site, an instance of the list will be there ready to go.

That’s just a quick look at what you can do with Visual Studio 11 Developer Preview. If you haven’t checked it out yet be sure and visit the developer center on MSDN.

A quick look at the content type editor in Visual Studio 11

CoreyRoth — Mon, 06 Feb 2012 16:52:10 GMT

Visual Studio 11 introduces a new content type editor that you might find useful when building your next content type. It starts with a SharePoint Project Item that you can pick from the New Item menu.

From this screen, give your new content type a name and then you’ll be presented with this next screen allowing you to pick a content type to inherit from. This pulls a list of every content type currently on the site collection that you have your Visual Studio project associated with.

Pick the content type you want to inherit from and you will then see the new content type editor.

From here you can begin adding exiting site columns to your new content type.

Selecting one will bring over the type automatically. Unfortunately the only option you get here is whether the column is required or not. However, you can click on the elements.xml file in the solution explorer to edit the XML directly. I’ve tested and it will preserve any additional attributes you add to your site column references there.

You might be wondering what about site columns that have not been created yet. The editor is actually smart and knows to look at any site columns defined in the same project as well. For example, I created this new site column below.

Unfortunately, creating site columns still requires XML, but Visual Studio at least gets you started. After you save your new site column, you will find the site column in the list.

You can also set some of the common properties such as the group and description of the content type itself by clicking on Common Properties.

What about inheriting from your own content type in the same project? That actually works as well. However, you will have to look for it at the top of the content type list.

That’s a quick look at what Visual Studio offers for content type editing. I think the SharePoint Designer still has a few more features, but the main difference is what you create here can actually be deployed elsewhere. This will work with SharePoint Online as well. Just use the new publish feature I have talked about earlier.

For more information on Visual Studio 11, go to the Developer Preview site.

End User Quick Tip: Use SharePoint Workspace to create friendly links to documents

CoreyRoth — Mon, 30 Jan 2012 17:49:21 GMT

SharePoint URLs can be quite long. When you paste a link to a document in an E-mail they can prove to be quite long. The community has developed a number of solutions for SharePoint URL shorteners. However, I thought I would share a quick solution that you can take advantage of as an end user without requiring any SharePoint customizations. I regularly use SharePoint Workspace to work on my most common projects. If you haven’t worked with it before, see this post for more on how to get started. Whenever, you need to share a link to a document, just right click on the document and use the Copy as Link menu item.

You can then paste the link into Outlook, a Word document, or wherever. When you do, it creates a nice link using the filename of the document instead of the full URL of the document.

It’s that simple. Sometimes, you may get an error when using the Copy as Link feature but when that happens it still copies the link to your clipboard.

How to: Use the Silverlight web part with Visual Studio 11

CoreyRoth — Wed, 25 Jan 2012 14:11:14 GMT

Visual Studio 11 adds a new feature that makes working with Silverlight in SharePoint 2010 a bit easier. The new Silverlight Web Part feature automates deploying your Silverlight applications to SharePoint and can really save you a bit of time. We took a look at how the Visual Web Part works in VS11 a while back. Now, let’s see what happens when we use Silverlight.

To work with Silverlight,you can either create a new project or simply add a new item to an existing project. I’ll start by creating a new project by choosing the item SharePoint 2010 Silverlight Web Part. Remember the number of project types has been reduced in VS11.

After you provide the usual SharePoint specific information, a new screen will prompt you for information on your Silverlight application. You can use an existing application or let it create a new project for you.

You have a choice of Silverlight version 4.0 or 5.0. Once you finish, you’ll have two new projects to work with. The designer opens up and then we’ll just create a simple Silverlight application.

Now, let’s take a look at the files. They prove to be a lot simpler than you might think.

If we click on the web part itself, we actually see the contents of the .webpart file. Taking a quick look at it, reveals its simplicity.

<?xml version="1.0" encoding="utf-8"?>
<webParts>
  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
    <metaData>
      <type name="Microsoft.SharePoint.WebPartPages.SilverlightWebPart, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL" />
      <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name="Title" type="string">SilverlightWebPartProject1 - SilverlightWebPart1</property>
        <property name="Description" type="string">My Silverlight Web Part</property>
        <property name="Height" type="unit">300px</property>
        <property name="Width" type="unit">400px</property>
        <property name="Url" type="string">/SiteAssets/SilverlightWebPartProject1/SilverlightWebPart1/SilverlightProject1.xap</property>
      </properties>
    </data>
  </webPart>
</webParts>

It simply has a reference to the existing SilverlightWebPart included in SharePoint 2010. It sets a few properties such as Title, Description, Height, Width, and Url. Here you will notice that it’s actually copying the .xap file from your Silverlight project into the SiteAssets library. Note, that this is the only place to set the dimensions of your web part.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/" >
  <Module Name="SilverlightWebPart1" List="113" Url="_catalogs/wp">
    <File Path="SilverlightWebPart1\SilverlightWebPart1.webpart" Url="SilverlightWebPartProject1_SilverlightWebPart1.webpart" Type="GhostableInLibrary" >
      <Property Name="Group" Value="Custom" />
    </File>
  </Module>
  <Module Name="SilverlightWebPart1">
    <File Path="SilverlightWebPart1\SilverlightProject1.xap" Url="SiteAssets/SilverlightWebPartProject1/SilverlightWebPart1/SilverlightProject1.xap" />
  </Module>
</Elements>

If we take a look at the Elements.xml file, we see that it deploys both the .webpart file and the .xap file using a Module element.

When you are ready to deploy just use the Deploy command in Visual Studio. It will build the Silverlight application, the .wsp file and send it to SharePoint. You no longer have to manually upload the .xap file (or add it manually to your package). Now, we can just add the web part to a page from the Insert ribbon.

Then you’ll have your Silverlight application on your page. Don’t be jealous of how great this one looks. :)

What about SharePoint Online? Does it work there too? Indeed it does. Just use the Publish feature I talked about earlier to deploy that solution to the cloud. One issue I did notice is that the path configured in the SilverlightWebPart is absolute. If you publish into a site collection not on the root, you’ll need to modify the path. I need to look at this one more since it might be based off of the local SharePoint site URL that you specified originally. Still it’s nice to know that it works. I tried it with an E3 account and I’m pretty sure it will work with P accounts as well.

How to: Query sites and site collections using SharePoint Search

CoreyRoth — Fri, 13 Jan 2012 19:41:21 GMT

I often refer to my Handy Keywords in SharePoint Search because it forms the building blocks you need to become a rock star at writing SharePoint keyword queries. Today, I want to expand upon that post on how you can use search to return a list of sites or site collections. This is useful when you want to quickly inspect a SharePoint farm using the Search Center. The secret behind returning sites with Search is use of the contentclass managed property. You just have to know what value to specify. To return a list of all sites in the search index, we specify a value of STS_Web (remember our translation guide). Here is what it looks like.

contentclass:"STS_Web"

This works pretty well. However, if you inspect the results on your own server, you might quickly notice one thing missing. The root web of all the site collections is not present in the search results. To get the site collections, we specify STS_Site instead.

contentclass:"STS_Site"

Notice, I now have all of the site collections on my particular tenant. If you want the results combined, you simply combine the queries.

contentclass:"STS_Site" contentclass:"STS_Web"

Now you might be thinking this is great, but you don’t want every site and site collection on the farm. You want to restrict it to a particular web application. That’s actually pretty easy, just refer back to the handy keywords post and use the Site managed property. In my case, I’ll restrict the URL to my main web application.

contentclass:"STS_Site" contentclass:"STS_Web" site:https://dotnetmafia.sharepoint.com

There are lots of ways to get lists of sites in SharePoint, but I find this one works well since it doesn’t require a line of code for you to try. Of course, as a developer, you can make use of this with the KeywordQuery class inside your own application. This works with SharePoint on-premises as well as SharePoint Online. All screenshots were from my personal SPO site.

A look at Visual Web Parts in Visual Studio 11

CoreyRoth — Thu, 12 Jan 2012 16:23:15 GMT

I recently published my first post about SharePoint development with Visual Studio 11 and I mentioned that there were some changes in how the Visual Web Part worked. If you are familiar with the Visual Web Part in Visual Studio 2010, you know it really is just a glorified user control and it doesn’t work in the sandbox. Luckily, the community stepped up and provided some alternatives that do work. Visual Studio 11 now provides a Visual Web Part that works in the sandbox out of the box. Since I am always curious about how things work, I decided to take a deeper look to see just how this web part is implemented now.

Let’s first take a look at the files that we get when we add a Visual Web Part to the project.

There are actually a few less files that we had in Visual Studio 2010. We’ll see why here shortly. What we get are the following

Elements.xml – Used to deploy the .webpart file via module element
A .ascx file – The actual user control with the design surface
A .ascx.cs file – The code behind for the user control
A .ascx.g.cs file – This file is generated by the designer. We’ll talk about it more
A .webpart file – The file that goes into the Web Part gallery that has the assembly path to the web part

If we look at the .ascx.cs file, we’ll see our first difference.

using System;
using System.ComponentModel;
using System.Web.UI.WebControls.WebParts;
 
namespace SharePointProject1.HelloWorldWebPart
{
    [ToolboxItemAttribute(false)]
    public partial class HelloWorldWebPart : WebPart
    {
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
            InitializeControl();
        }
 
        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

You’ll notice that this file inherits from WebPart now instead of UserControl. At this point, you might be wonder how does all of this work. Well, the magic is in the designer and what ends up in the .ascx.g.cs file. Let’s take a look at it when it’s first created.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.5448
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
 
namespace SharePointProject1.HelloWorldWebPart {
    using System.Web;
    using System.Text.RegularExpressions;
    using Microsoft.SharePoint.WebPartPages;
    using Microsoft.SharePoint.WebControls;
    using System.Web.Security;
    using Microsoft.SharePoint.Utilities;
    using System.Web.UI;
    using System;
    using System.Web.UI.WebControls;
    using System.Collections.Specialized;
    using Microsoft.SharePoint;
    using System.Collections;
    using System.Web.Profile;
    using System.Text;
    using System.Web.Caching;
    using System.Configuration;
    using System.Web.UI.WebControls.WebParts;
    using System.Web.SessionState;
    using System.Web.UI.HtmlControls;
 
 
    public partial class HelloWorldWebPart {
 
        public static implicit operator global::System.Web.UI.TemplateControl(HelloWorldWebPart target) 
        {
            return target == null ? null : target.TemplateControl;
        }
 
        [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        private void @__BuildControlTree(global::SharePointProject1.HelloWorldWebPart.HelloWorldWebPart @__ctrl) {
        }
 
        private void InitializeControl() {
            this.@__BuildControlTree(this);
            this.Load += new global::System.EventHandler(this.Page_Load);
        }
 
        [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        protected virtual object Eval(string expression) {
            return global::System.Web.UI.DataBinder.Eval(this.Page.GetDataItem(), expression);
        }
 
        [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        protected virtual string Eval(string expression, string format) {
            return global::System.Web.UI.DataBinder.Eval(this.Page.GetDataItem(), expression, format);
        }
    }
}

It may not make a lot of sense at this point, but when you start adding controls, it makes more sense. I added a label, textbox, and button control to the design surface.

This looks like a typical user control that you are confortable working with. Now let’s take a look at what the .ascx.g.cs file has now. I’ll just include the parts that changed.

[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private global::System.Web.UI.WebControls.Label @__BuildControlLabel1() {
    global::System.Web.UI.WebControls.Label @__ctrl;
    @__ctrl = new global::System.Web.UI.WebControls.Label();
    this.Label1 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this.Page);
    @__ctrl.ID = "Label1";
    @__ctrl.Text = "Label";
    return @__ctrl;
}
 
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private global::System.Web.UI.WebControls.TextBox @__BuildControlTextBox1() {
    global::System.Web.UI.WebControls.TextBox @__ctrl;
    @__ctrl = new global::System.Web.UI.WebControls.TextBox();
    this.TextBox1 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this.Page);
    @__ctrl.ID = "TextBox1";
    return @__ctrl;
}
 
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private global::System.Web.UI.WebControls.Button @__BuildControlButton1() {
    global::System.Web.UI.WebControls.Button @__ctrl;
    @__ctrl = new global::System.Web.UI.WebControls.Button();
    this.Button1 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this.Page);
    @__ctrl.ID = "Button1";
    @__ctrl.Text = "Button";
    return @__ctrl;
}
 
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private void @__BuildControlTree(global::SharePointProject1.HelloWorldWebPart.HelloWorldWebPart @__ctrl) {
    System.Web.UI.IParserAccessor @__parser = ((System.Web.UI.IParserAccessor)(@__ctrl));
    @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n<div>\r\n    "));
    global::System.Web.UI.WebControls.Label @__ctrl1;
    @__ctrl1 = this.@__BuildControlLabel1();
    @__parser.AddParsedSubObject(@__ctrl1);
    @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n    "));
    global::System.Web.UI.WebControls.TextBox @__ctrl2;
    @__ctrl2 = this.@__BuildControlTextBox1();
    @__parser.AddParsedSubObject(@__ctrl2);
    global::System.Web.UI.WebControls.Button @__ctrl3;
    @__ctrl3 = this.@__BuildControlButton1();
    @__parser.AddParsedSubObject(@__ctrl3);
    @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n</div>\r\n"));
}

The designer creates methods for each ASP.NET control you drag onto the page and then the @__BuiltControlTree method calls those methods to effectively add those controls to the page. The HTML div elements that I added to the page simply get included as a LiteralControl. Needless to say you don’t want to mess with this file. I have to give props to the Visual Studio and SharePoint teams. I am sure this was a lot of work to implement. :) Give it a try if you want. It seems to work well and the best part is what I have tried so far works with SharePoint Online.

If you haven’t checked out Visual Studio 11 yet, head over to the developer site where you can get the download link and find out everything that’s new.

How to: Use Visual Studio 11 to publish solutions to SharePoint Online

CoreyRoth — Wed, 11 Jan 2012 05:23:27 GMT

So I’ve been living under a rock again and I had never gotten around to checking what’s new in Visual Studio 11. The Developer Preview has been around a while and I wanted to check it out today and was surprised to see some new SharePoint development features that I am really excited about. If you have been following me, you know I have been doing some work with Office 365 and SharePoint Online, so when I read about the new Publish feature in Visual Studio 11, I had to check it out. Let’s start by creating a new project with a simple web part. We’ll look and what’s new and see how exactly we can publish to SharePoint Online.

Open Visual Studio 11 and go to the New Project menu. If you are familiar with this menu in Visual Studio 2010, you will quickly notice some differences.

First, you will notice you have a lot less choices. I really like this change. I always found it confusing that there was many project types that really just equated to a SharePoint Project Item that you would create in any project using the New Item menu. I always used the blank SharePoint project and we now refer to this simply as a SharePoint 2010 Project. Be sure and change the framework to .NET Framework 3.5 as it default to .NET Framework 4.5 by default. One other change you might notice is that there are no longer any SharePoint 2007 projects available.

Create a SharePoint 2010 Project and then be sure and check Sandboxed Solution since we are going to the cloud. Go ahead and create a new Visual Web Part next. Now you might be thinking, that you can’t do Visual Web Parts in sandboxed solutions. In the past, we had to rely on tools from the community to make this happen. Now Visual Studio 11 supports Visual Web Parts out-of-the-box. We’ll talk more about these in my next post. Drag a label or whatever ASP.NET controls you want onto the design surface and create your “Hello, World!” text. When you are done, click Build. Don’t bother deploying it though.

Now we want to publish this solution to SharePoint Online. Visual Studio 11 actually makes it quite easy. Right click on the project and click Publish. This brings up a new dialog prompting you for the URL to your site. You can specify another SharePoint 2010 server or in our case we’ll specify my URL to a site collection in SPO.

Once you click the Publish button, it will take a few seconds to connect and finally it will prompt you for authentication.

Enter your credentials and the solution will publish soon. When it is done, you will be taken to the Solutions gallery. At this point, you need to select the solution and click the Activate button to make your solution available.

At this point, you can edit any page and find your web part in the list. I just added it to the home page of the site as you can see in the screenshot below.

I’ve talked about how to deploy solutions to SharePoint Online in the past and this makes things much easier. This will definitely reduce development time. We still have to throw our solution “over the fence”, but at least it’s somewhat automated now. I can only hope for debugging in the cloud some day. :)

One thing to note is that you still have to do the development on a machine that has SharePoint installed. I even tried to trick it, but it wouldn’t cooperate.

Now, you might be thinking this is great and wondering if you should switch to Visual Studio 11 for SharePoint Online development. At this point, I don’t see any huge risk in doing that, but don’t blame me if things blow up. :) Make use of source control and backups and you should be able to correct anything that VS11 manages to break. When you are using source control, I see the worst that could happen is that you might have to go back a version or two in source control. For the extreme pessimist, I am sure worse could happen, but you always take that risk with pre-release software.

If you haven’t checked out Visual Studio 11 yet, head over to the developer site where you can get the download link and find out everything that’s new.

Quick Tip: Use % to return all items in the search index (FAST Search for SharePoint and SharePoint Online)

CoreyRoth — Fri, 06 Jan 2012 18:55:40 GMT

Ever wanted to see what exactly is in your SharePoint search index with a simple query? Sure, you can take a look at the crawl log, but you can’t see that in SharePoint Online. With SharePoint 2010, you can use queries using the ContentSource keyword to return everything in that content source (i.e.: Local SharePoint sites). However, you may want to see the entire index. Well that’s actually pretty easy. Just use type % in the search box and submit your query. It will return everything there is.

This is a great way to see what is in your search index. It can also help you find things that maybe you didn’t want indexed. It even works with SharePoint Online as well.

What about people search? It works there too with SharePoint Online.

However, this doesn’t work in FAST Search for SharePoint (which is just SharePoint Search when it comes to people) for me. Even still, % is a useful operator that you can use to help troubleshoot issues with search.

UPDATE: Erich Stehr pointed out that % does not work on regular SharePoint Enterprise Search. He is correct. What is odd is that it does work in SharePoint Online. That will make you think about things. As an alternative, you can issue the query Size>=0 (no spaces) to return the entire index as well.

How to: Query People Search in SharePoint Online (and other SharePoint platforms too!)

CoreyRoth — Wed, 04 Jan 2012 04:38:12 GMT

At my Search talk at SPC11, I demoed how to build a Silverlight application that could query search in SharePoint Online. I also built a separate application that could query people search, but I haven’t posted on it yet until today. To query people search, we have to know a few things about how SharePoint operates. It all starts with understanding the scopes involved. If you take a look at your Search Scopes link in your site collection settings, you’ll see a similar list to the one below.

What’s funny here is that SPO actually returns item counts for the entire (non-partitioned index). This tells me that there are 205,000 items and 96,000 people on my particular Office 365 SharePoint host.

Ultimately, querying people search is just a matter of executing a query against the scope People, but there are a few catches. In SharePoint 2007, you could actually execute the query Scope:”People” on a results.aspx with a CoreResultsWebPart and you would actually get results. It wouldn’t display pictures or additional user information such as department or phone number, but it would work. With the introduction of federated search in SharePoint 2010, people search now gets executed by it’s own federated location named LocalPeopleSearchIndex (see my post on the QueryManager class for more information). This means that a regular CoreResultsWebPart will not return results for Scope:”People” no matter what you do.

However, a PeopleCoreResultsWebPart will.

Issuing the query Scope:”People” will return every user in the user profile store. Including service accounts like you see above. The fact that I couldn’t issue a people search query to the regular CoreResultsWebPart actually threw me off for quite some time. It just didn’t make sense to me what was going on behind the scenes. It didn’t become ultimately clear, until I tried issuing the query to Search.asmx. The Scope:”People” query works just fine when calling the web service. Today you will learn how to query people search using the web service. I’m going to use the exact same application I have been using with my other search demos, we’ll just tweak the input a little bit.

For today’s example, I am going to build off of the Silverlight 4 application I used at SPC. I’m using Silverlight, but you could just as well write a console application or call this web service from some other ASP.NET application. We still want to start by creating a service reference to /_vti_bin/search.asmx. We then create an instance of the web service so that we can use it. We also bind an event handling method to handle the results of the web service call.

QueryServiceSoapClient queryService = new QueryServiceSoapClient();

queryService.QueryExCompleted += new EventHandler<QueryExCompletedEventArgs>(QueryService_QueryExCompleted);

Once we have a reference to the web service, it’s just a matter of constructing the input XML document and sending it to the web service. For SharePoint Online and SharePoint 2010, we actually don’t have to change any of the XML at all. We just need to change the query. That means our input will look like the following. Note, we’re using a type of STRING (even if using FAST Search for SharePoint).

<Format>urn:Microsoft.Search.Response.Document.Document</Format>

</SupportedFormats>

<QueryText language="en-US" type="STRING">Scope:"People"</QueryText>

</Context>

</Query>

</QueryPacket>

If we are using FAST Search for SharePoint, we need to add to a ResultProvider element inside the Query element. Remember, People Search is handled by the SharePoint 2010 search engine in FAST Search for SharePoint.

<ResultProvider>SharePointSearch</ResultProvider>

Just like before, I assemble this XML string using a StringBuilder. I allow the user to type in a query and I just automatically append Scope:”People” to the query ensuring we only get people results.

StringBuilder queryXml = new StringBuilder();
 
queryXml.Append("<QueryPacket xmlns=\"urn:Microsoft.Search.Query\" Revision=\"1000\">");
queryXml.Append("<Query domain=\"QDomain\">");
queryXml.Append("<SupportedFormats>");
queryXml.Append("<Format>");
queryXml.Append("urn:Microsoft.Search.Response.Document.Document");
queryXml.Append("</Format>");
queryXml.Append("</SupportedFormats>");
queryXml.Append("<Context>");
queryXml.Append("<QueryText language=\"en-US\" type=\"STRING\">");
queryXml.AppendFormat("{0} Scope:\"People\"", SearchTextBox.Text);
queryXml.Append("</QueryText>");
queryXml.Append("</Context>");
queryXml.Append("</Query>");
queryXml.Append("</QueryPacket>");
 
queryService.QueryExAsync(queryXml.ToString());

We’ll then bind the resulting XML to a textbox so that we can look at the results.

ResultsTextBox.Text = e.Result.Nodes[1].ToString();

That’s all that is involved in this first round of code. Compile the code and upload the Silverlight application to a document library and use the Silverlight web part just like before. If you want more details on how the above code works, be sure and check out the original Search with Silverlight 4 post. Let’s take a look at the results. Here’s the application running.

I issues a query and I got results. Let’s look at the XML in the results a bit more though.

<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
  <Results xmlns="">
    <RelevantResults diffgr:id="RelevantResults1" msdata:rowOrder="0">
      <WorkId>72787</WorkId>
      <Rank>100000000</Rank>
      <Title>Craig Johnson</Title>
      <Size>0</Size>
      <Path>https://dotnetmafia-my.sharepoint.com/Person.aspx?accountname=i%3A0%23.f|membership|craig.johnson%40dotnetmafia.onmicrosoft.com</Path>
      <Write>2011-09-09T18:20:05-07:00</Write>
      <SiteName>https://dotnetmafia-my.sharepoint.com</SiteName>
      <CollapsingStatus>0</CollapsingStatus>
      <HitHighlightedSummary />
      <HitHighlightedProperties>&lt;HHTitle&gt;Craig Johnson&lt;/HHTitle&gt;&lt;HHUrl&gt;https://dotnetmafia-my.sharepoint.com/Person.aspx?accountname=i%3A0%23.f|membership|craig.johnson%40dotnetmafia.onmicrosoft.com&lt;/HHUrl&gt;</HitHighlightedProperties>
      <ContentClass>urn:content-class:SPSPeople</ContentClass>
      <IsDocument>false</IsDocument>
      <PictureThumbnailURL>https://dotnetmafia-my.sharepoint.com/User Photos/Profile Pictures/i_0_.f_membership_craig.johnson@dotnetmafia.onmicrosoft.com_MThumb.jpg</PictureThumbnailURL>
    </RelevantResults>

We have the user’s name in the Title field and we have some links to a picture and the user’s profile. For the most part though, these fields aren’t entirely useful. That’s because SharePoint treats this result as a regular document result instead of a person. If we want useful information about the user, we have to ask for that information in our original query. Specifically, we need to specify the names of the managed properties that we want returned (i.e.: JobTitle and Department). How do we know what the names of those properties are? In SharePoint 2010, we can just go look in the search service application. However, we don’t have that option in SharePoint Online. There’s another way though. Go back to your PeopleResults.aspx page in your Search Center and edit it. Then, you need to modify the PeopleCoreResultsWebPart. Expand Display Properties and then uncheck Use Location Visualization. The contents of the XML in Fetched Properties has the answer.

Here is what the XML looks like.

<Columns>
  <Column Name="WorkId"/>
  <Column Name="UserProfile_GUID"/>
  <Column Name="AccountName"/>
  <Column Name="PreferredName" HitHighLight="true"/>
  <Column Name="YomiDisplayName" HitHighLight="true"/>
  <Column Name="JobTitle" HitHighLight="true"/>
  <Column Name="Department" HitHighLight="true"/>
  <Column Name="WorkPhone" HitHighLight="true"/>
  <Column Name="OfficeNumber" HitHighLight="true"/>
  <Column Name="PictureURL"/>
  <Column Name="HierarchyUrl"/>
  <Column Name="WorkEmail" HitHighLight="true"/>
  <Column Name="Path"/>
  <Column Name="HitHighlightedSummary"/>
  <Column Name="HitHighlightedProperties"/>
  <Column Name="Responsibility" HitHighLight="true"/>
  <Column Name="Skills" HitHighLight="true"/>
  <Column Name="SipAddress" HitHighLight="true"/>
  <Column Name="Schools" HitHighLight="true"/>
  <Column Name="PastProjects" HitHighLight="true"/>
  <Column Name="Interests" HitHighLight="true"/>
  <Column Name="OrgNames" HitHighLight="true"/>
  <Column Name="OrgUrls"/>
  <Column Name="OrgParentNames" HitHighLight="true"/>
  <Column Name="OrgParentUrls"/>
  <Column Name="Memberships" HitHighLight="true"/>
  <Column Name="AboutMe" HitHighLight="true"/>
  <Column Name="BaseOfficeLocation" HitHighLight="true"/>
  <Column Name="ServiceApplicationID"/>
  <Column Name="SocialDistance"/>
</Columns>

This gives you quite a few choices to display in your results. The column names are pretty self explanatory. Now, we just have modify our input XML to specify which managed properties we want. Do you remember how to specify managed properties with the Search web service? If not, we start by adding a Properties element inside the Query element. We then add a Property element for each managed property. One thing to remember is that the managed properties must be specified in lower case. You will get a NotFound exception if they are not. Here is an example:

<Properties>
  <Property name="accountname" />
  <Property name="preferredname" />
  <Property name="jobtitle" />
  <Property name="department" />
  <Property name="workphone" />
  <Property name="officenumber" />
  <Property name="pictureurl" />
  <Property name="workemail" />
</Properties>

Remember, once you specify any column, you must specify every column you want. The default columns will no longer be returned. When we recompile, upload the new application, and execute a query again, we now get much better results.

<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
  <Results xmlns="">
    <RelevantResults diffgr:id="RelevantResults1" msdata:rowOrder="0">
      <accountname>i:0#.f|membership|craig.johnson@dotnetmafia.onmicrosoft.com</accountname>
      <preferredname>Craig Johnson</preferredname>
      <jobtitle>Accountant</jobtitle>
      <department>Accounts Receivable</department>
      <workphone>123-555-1215</workphone>
      <officenumber>123455</officenumber>
      <pictureurl>https://dotnetmafia-my.sharepoint.com/User Photos/Profile Pictures/i_0_.f_membership_craig.johnson@dotnetmafia.onmicrosoft.com_MThumb.jpg</pictureurl>
      <workemail>craig.johnson@dotnetmafia.onmicrosoft.com</workemail>
    </RelevantResults>

You can query with these same managed properties as well. For example, I could use the department managed property to see who is in Accounting with the following query.

department:”accounting”

Maybe, you want to look up who the CEO of the company is. To do that use the jobtitle managed property. Resist the urge to capitalize the words in the managed property. They must be in lower case. Note: that the title managed property is reserved for personal titles such as Jr., Sr. etc.

jobtitle:”CEO”

Now, that we can query with all of these properties, we can make a nice advanced people search application. In my demo at SPC11, I used the Telerik RadGridView control to display the user information along with the picture from the user profile. Here’s a screenshot of what the application looked like.

You can use the same techniques that I detailed in the Advanced Search with Silverlight 4 post to build a people search application like the one above. This code will work on-premises (SharePoint 2010 or FAST Search for SharePoint) or in the cloud with SharePoint Online. I’ve confirmed this works with both the P1 and E3 SKUs of Office 365.

How to: Use Refiners with the Search Web Service (FAST Search for SharePoint)

CoreyRoth — Wed, 28 Dec 2011 18:50:47 GMT

Yesterday, I talked about how we can use FQL with the Search Web Service. As promised, I am continuing the series about the search web service to talk about how we can take advantage of refiners. As you may know, FAST Search for SharePoint gives you exact counts in refinement so why not take advantage of them in your custom search application. We’ll take a look at how to specify which refiners are returned with your search results. After that we’ll take a look at how to use those refiners in a query.

Returning refiners with your results is also quite easy. All we have to do is add a few elements to the input XML document of the Query or QueryEx method. Before you add these elements though, you need to know what you want to refine on. You can refine on any managed property configured to allow refinement (or deep refinement) on the FAST Search Administration page. We’ll work with some out of the box properties. You can look up the names for these by examining the Refinement Panel. In this post, I talk about the Refinement Panel in SharePoint search but in FAST, the Refinement Panel has a different XML file (and managed property names). Take a look at the XML below and take note of the MappedProperty attribute. These are out-of-the-box managed properties that we can use including format (file extension), author, sitename, and write (modified date).

<?xml version="1.0" encoding="utf-8"?>
<FilterCategories>
  <Category    Title="Result Type"    Description="The file extension of the item"    Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator"    MetadataThreshold="1"    NumberOfFiltersToDisplay="4"    MaxNumberOfFilters="20"    ShowMoreLink="True"    MappedProperty="format"    MoreLinkText="show more"    LessLinkText="show fewer"    ShowCounts="Count" />
  <Category    Title="Site"    Description="Which site this document is from"    Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator"    MetadataThreshold="1"    NumberOfFiltersToDisplay="4"    MaxNumberOfFilters="20"    ShowMoreLink="True"    MappedProperty="sitename"    MoreLinkText="show more"    LessLinkText="show fewer"    ShowCounts="Count" />
  <Category    Title="Author"    Description="Use this filter to restrict results authored by a specific author"    Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator"    MetadataThreshold="1"    NumberOfFiltersToDisplay="4"    MaxNumberOfFilters="20"    ShowMoreLink="True"    MappedProperty="author"    MoreLinkText="show more"    LessLinkText="show fewer"    ShowCounts="Count" />
  <Category    Title="Modified Date"    Description="When the item was last updated"    Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator"    MetadataThreshold="1"    NumberOfFiltersToDisplay="6"    SortBy="Custom"    ShowMoreLink="False"    MappedProperty="write"    ShowCounts="Count" >
    <CustomFilters MappingType="RangeMapping" DataType="Date" ValueReference="Relative" ShowAllInMore="False">
      <CustomFilter CustomValue="Past 24 Hours">
        <OriginalValue>-1..</OriginalValue>
      </CustomFilter>
      <CustomFilter CustomValue="Past Week">
        <OriginalValue>-7..</OriginalValue>
      </CustomFilter>
      <CustomFilter CustomValue="Past Month">
        <OriginalValue>-30..</OriginalValue>
      </CustomFilter>
      <CustomFilter CustomValue="Past Six Months">
        <OriginalValue>-183..</OriginalValue>
      </CustomFilter>
      <CustomFilter CustomValue="Past Year">
        <OriginalValue>-365..</OriginalValue>
      </CustomFilter>
      <CustomFilter CustomValue="Earlier">
        <OriginalValue>..-365</OriginalValue>
      </CustomFilter>
    </CustomFilters>
  </Category>
  <Category    Title="Company"    Description="Use this filter to restrict results by company"    Type="Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator"    MetadataThreshold="1"    NumberOfFiltersToDisplay="4"    MaxNumberOfFilters="20"    ShowMoreLink="True"    MappedProperty="companies"    MoreLinkText="show more"    LessLinkText="show fewer"    ShowCounts="Count" />
  <Category    Title="Managed Metadata Columns"    Description="Managed metadata of the documents"    Type="Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator"    MetadataThreshold="3"    NumberOfFiltersToDisplay="3"    MaxNumberOfFilters="20"    ShowMoreLink="True"    MappedProperty="owsmetadatafacetinfo"    MoreLinkText="show more"    LessLinkText="show fewer" />
  <Category    Title="Tags"    Description="All managed metadata of the documents and social tags"    Type="Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator"    MetadataThreshold="3"    NumberOfFiltersToDisplay="3"    MaxNumberOfFilters="20"    ShowMoreLink="True"    MappedProperty="owsmetadatafacetinfo"    MoreLinkText="show more"    LessLinkText="show fewer"    ShowCounts="Count" />
</FilterCategories>

We’ll take a look at format and author first. The managed property for managed metadata fields, owsmetadatafacetinfo, requires a bit more explaining. To add Refinement to your search results, you just need to add the IncludeRefinementResults element somewhere inside your Query element. You then specify the name of the managed properties that you want in individual Refiner elements. Here is what the raw XML looks like.

<IncludeRefinementResults>
  <Refiners>
    <Refiner>author</Refiner>
    <Refiner>write</Refiner>
    <Refiner>sitename</Refiner>
    <Refiner>format</Refiner>
    <Refiner>owsmetadatafacetinfo</Refiner>
  </Refiners>
</IncludeRefinementResults>

To use it in the code, I am using a StringBuilder like before. Here is what the whole string looks like.

queryXml.Append("<QueryPacket xmlns=\"urn:Microsoft.Search.Query\" Revision=\"1000\">");
queryXml.Append("<Query domain=\"QDomain\">");
queryXml.Append("<SupportedFormats>");
queryXml.Append("<Format>");
queryXml.Append("urn:Microsoft.Search.Response.Document.Document");
queryXml.Append("</Format>");
queryXml.Append("</SupportedFormats>");
queryXml.Append("<Range>");
queryXml.Append("<Count>50</Count>");
queryXml.Append("</Range>");
queryXml.Append("<Context>");
queryXml.Append("<QueryText language=\"en-US\" type=\"FQL\">");
queryXml.Append(searchQuery);
queryXml.Append("</QueryText>");
queryXml.Append("</Context>");
queryXml.Append("<IncludeRefinementResults>");
queryXml.Append("<Refiners>");
queryXml.Append("<Refiner>author</Refiner>");
queryXml.Append("<Refiner>write</Refiner>");
queryXml.Append("<Refiner>sitename</Refiner>");
queryXml.Append("<Refiner>format</Refiner>");
queryXml.Append("<Refiner>owsmetadatafacetinfo</Refiner>");
queryXml.Append("</Refiners>");
queryXml.Append("</IncludeRefinementResults>");
queryXml.Append("</Query>");
queryXml.Append("</QueryPacket>");

I added several refiners in my case which we will talk about. The rest of the code to execute the query is exactly the same from yesterday’s post. Let’s look at a snippet of the results. For each refiner returns you will get a RefinementResults element returned along with your regular RelevantResults elements that you may be accustomed to by now. Note, that the RefinementResults elements are not grouped in any sort of parent element like the RelevantResults are. Here is a snippet.

<RefinementResults diffgr:id="RefinementResults19" msdata:rowOrder="18">
  <RefinerName>format</RefinerName>
  <RefinementName>Microsoft Word</RefinementName>
  <RefinementValue>^"Microsoft Word"$</RefinementValue>
  <RefinementToken>AQ5NaWNyb3NvZnQgV29yZAZmb3JtYXQBAl4iAiIk</RefinementToken>
  <RefinementCount>28</RefinementCount>
</RefinementResults>
<RefinementResults diffgr:id="RefinementResults20" msdata:rowOrder="19">
  <RefinerName>format</RefinerName>
  <RefinementName>Web Page</RefinementName>
  <RefinementValue>^"Web Page"$</RefinementValue>
  <RefinementToken>AQhXZWIgUGFnZQZmb3JtYXQBAl4iAiIk</RefinementToken>
  <RefinementCount>27</RefinementCount>
</RefinementResults> 

If you were to write custom code to display these, I recommend using LINQ to XML and grouping elements that have matching RefinerName values. In the case above, format is allowing us to refine by file extension. The RefinementName element contains (usually) a human-readable value to display for the refiner. The exact count of results can be found in RefinementCount. Lastly, I will point out the RefinentToken. This allows us to issue a subsequent query using that refiner. We’ll talk about that shortly after I cover some more details on the results.

When refining by date managed properties (such as write), things get a little more complicated. Take a look at the refinement results, it gave me.

<RefinementResults diffgr:id="RefinementResults16" msdata:rowOrder="15">
  <RefinerName>write</RefinerName>
  <RefinementName>From 2010-11-11T07:18:13.4998560Z to 2010-11-11T18:49:08.4997920Z</RefinementName>
  <RefinementValue>[2010-11-11T07:18:13.4998560Z;2010-11-11T18:49:08.4997919Z]</RefinementValue>
  <RefinementToken>AREERnJvbSAyMDEwLTExLTExVDA3OjE4OjEzLjQ5OTg1Nj…==</RefinementToken>
  <RefinementCount>27</RefinementCount>
</RefinementResults>
<RefinementResults diffgr:id="RefinementResults17" msdata:rowOrder="16">
  <RefinerName>write</RefinerName>
  <RefinementName>From 2010-11-11T18:49:08.4997920Z to 2011-12-27T17:12:11.4998400Z</RefinementName>
  <RefinementValue>[2010-11-11T18:49:08.4997920Z;2011-12-27T17:12:11.4998399Z]</RefinementValue>
  <RefinementToken>AREERnJvbSAyMDEwLTExLTExVDE4OjQ5OjA4LjQ5OTc5MjBaIH…==</RefinementToken>
  <RefinementCount>19</RefinementCount>
</RefinementResults>
<RefinementResults diffgr:id="RefinementResults18" msdata:rowOrder="17">
  <RefinerName>write</RefinerName>
  <RefinementName>2011-12-27T17:12:11.4998400Z or later</RefinementName>
  <RefinementValue>[2011-12-27T17:12:11.4998400Z;]</RefinementValue>
  <RefinementToken>ARUCMjAxMS0xMi0yN1QxNzoxMjoxMS40OTk4NDAwWiBvciBsYXRlc…=</RefinementToken>
  <RefinementCount>22</RefinementCount>
</RefinementResults>

It gives you a few date ranges by default. You have to carefully examine the values of RefinementName to figure it out, but effectively it comes down to documents from yesterday, documents in the last 6 weeks or so, and anything before that. The refinement documentation on MSDN, seems to indicate that you can specify exact dates for it to refine on, but I haven’t fully explored it.

Finally, we’ll talk about how Managed Metadata results get returned. These come from the managed property, owsmetadatafacetinfo.

<RefinementResults diffgr:id="RefinementResults1" msdata:rowOrder="0">
  <RefinerName>owsmetadatafacetinfo</RefinerName>
  <RefinementName>CompanyName|CompanyName|SIY8F/QVWEiQVLpg6IwnCg==|SL8RuOhIpUekTSlmeLc0AQ==|#04cbd472-7446-45cd-87c3-57ea2e142888|Contoso;#</RefinementName>
  <RefinementValue>^CompanyName|CompanyName|SIY8F/QVWEiQVLpg6IwnCg==|SL8RuOhIpUekTSlmeLc0AQ==|#04cbd472-7446-45cd-87c3-57ea2e142888|Contoso;#$</RefinementValue>
  <RefinementToken>ARkHQ29tcGFueU5hbWV8Q29tcGFueU5hbWV8U0lZOEYvUVZXRWlRVkxwZzZJd25DZz09fFNMOFJ1T2hJcFVla1RTb…==</RefinementToken>
  <RefinementCount>19</RefinementCount>
</RefinementResults>
<RefinementResults diffgr:id="RefinementResults2" msdata:rowOrder="1">
  <RefinerName>owsmetadatafacetinfo</RefinerName>
  <RefinementName>ProductLine|ProductLine|SIY8F/QVWEiQVLpg6IwnCg==|HQGuvm9zUUGAE1lO7yojyA==|#5bff12c1-ed32-4e0e-aadb-f9bbdd436432|Office;#</RefinementName>
  <RefinementValue>^ProductLine|ProductLine|SIY8F/QVWEiQVLpg6IwnCg==|HQGuvm9zUUGAE1lO7yojyA==|#5bff12c1-ed32-4e0e-aadb-f9bbdd436432|Office;#$</RefinementValue>
  <RefinementToken>ARgHUHJvZHVjdExpbmV8UHJvZHVjdExpbmV8U0lZOEYvUVZXRWlRVkxwZzZJd25DZz09fEhRR3V2bTl6VVVHQUUxbE83e…Ek</RefinementToken>
  <RefinementCount>7</RefinementCount>
</RefinementResults> 

In this case, I have two managed metadata properties defined: CompanyName and ProductLine. Actually, these names map back to underlying site columns. In my case CompanyName is mapped to the built-in managed property Company. The RefinementName element gives you a ton of date that you will have to parse through including the name of the site column, tokens, the GUID of the term and ultimately the text value. Have fun parsing that. :)

Now, that we have our refiners, we can use the RefinementToken to refine a subsequent query. To do this, we just add a RefinementFilters element inside our Query element. We include a RefinementFilter element with the token of each refiner we are using. For example, to filter by Word documents from our previous results, we’ll add the values like this.

<RefinementFilters>
  <RefinementFilter>AQ5NaWNyb3NvZnQgV29yZAZmb3JtYXQBAl4iAiIk</RefinementFilter>
</RefinementFilters>

You’ll get another set of results back like you did before only the results are now refined. You can include multiple RefinementFilter elements if you want as well. I know that’s a lot of XML for one post, but hopefully it’s useful.

How to: Query FAST Search for SharePoint with FQL and the Search Web Service

CoreyRoth — Wed, 28 Dec 2011 02:04:37 GMT

I’ve written many posts on how to query search (Keyword in 2010, Keyword in 2007, QueryManager, Web Service, FQL using Keyword) and I wanted to keep up the tradition and talk about how easy it is to get started using FQL with the Search Web Service. Our same techniques apply from my previous web service article with only some slight changes. It may seem simple at first, but it’s the first building block that we need for a series of posts I am starting.

QueryServiceSoapClient queryService = new QueryServiceSoapClient();
queryService.QueryExCompleted += new EventHandler<QueryExCompletedEventArgs>(QueryService_QueryExCompleted);

Once we have a reference to the web service, it’s just a matter of constructing the input XML document and sending it to the web service. This input XML is typically the same for a basic query. However, the difference here is in the type attribute of the QueryText element. We want to specify a value of FQL instead of STRING.

<Format>urn:Microsoft.Search.Response.Document.Document</Format>

</SupportedFormats>

<QueryText language="en-US" type="FQL">productline:"*ice"</QueryText>

</Context>

</Query>

</QueryPacket>

That is what the XML looks like. In this case, I am using a simple FQL query to return anything matching the managed property using a wildcard operator. In this case, I was looking for the word Office but you can see how I use “*ice” and still get results. This prefix wildcard operator only works with FQL. If you change the query back to type STRING (keyword), it would not work. You can store it in a separate file or just build it with a StringBuilder. We’ll go with a StringBuilder today for simplicity.

queryXml.Append("<QueryPacket xmlns=\"urn:Microsoft.Search.Query\" Revision=\"1000\">");
queryXml.Append("<Query domain=\"QDomain\">");
queryXml.Append("<SupportedFormats>");
queryXml.Append("<Format>");
queryXml.Append("urn:Microsoft.Search.Response.Document.Document");
queryXml.Append("</Format>");
queryXml.Append("</SupportedFormats>");
queryXml.Append("<Context>");
queryXml.Append("<QueryText language=\"en-US\" type=\"FQL\">");
queryXml.Append("productline:*ice");
queryXml.Append("</QueryText>");
queryXml.Append("</Context>");
queryXml.Append("</Query>");
queryXml.Append("</QueryPacket>");

We then need to make the call to the Search web service. Remember that you can call QueryEx to get a DataSet and Query to get an XML document. I always prefer to work with the raw XML since I can use LINQ to XML with it.

queryService.QueryExAsync(queryXml.ToString());

We then jump implement our event handling method QueryService_QueryExCompleted. Remember, that the XML we want is always in the node element in position 1. We can bind this data to a textbox, like the snippet below or you can use my example from the SPC article to bind to a grid.

ResultsTextBox.Text = e.Result.Nodes[1].ToString();

Here is what my example looks like.

As I said it’s pretty simple. One thing I have noticed with the Silverlight application is that if you get the syntax of an FQL query wrong, it won’t return gracefully, it will throw a NotFound exception. Who knows why?

In the above example, I didn’t specify the managed property with lower case letters. It must be lower case or you will always get an exception. This varies from the KeywordQuery syntax. I hope this example helps. Remember, if you do need help getting started with this application, take a look at the sample code I provided in the previous article. In the following articles, I’ll start demonstrating how to leverage some of the more advanced FAST Search for SharePoint features using the web service. I figured it would be good to write this article as a starting point first though.

Configuring Site Collection Search Settings with PowerShell

CoreyRoth — Wed, 21 Dec 2011 16:28:11 GMT

I’m always looking for a way to automate things and configuring the search settings of a site collection is no exception. I’ve talked about the Search Settings page before and how important it is for configuring contextual search and the scope drop down on your master page. Wouldn’t it be nice to be able to automate these changes instead of having to manually set it on every site collection?

To configure these settings, we first must understand where they are. It turns out that they can be found in the AllProperties collection of the root SPWeb object in a site collection. On a new site collection or on one where you have never configured the search settings, no values will exist in the property bag for search. However, one you go to the search settings page and click save, it will write the values into the property bag. As you may know, the search settings page has three configurable fields. These values on the search settings page map to the values below in the property bag.

Setting	Property Bag Name
Site Collection Search Center	SRCH_ENH_FTR_URL
Site Collection Search Dropdown Mode	SRCH_SITE_DROPDOWN_MODE
Site Collection Search Results Page	SRCH_TRAGET_RESULTS_PAGE

Now what goes in each value? SRCH_ENH_FTR_URL typically takes a relative URL (i.e. /search/pages). However, it can take full URL as well. SRCH_SITE_DROPDOWN_MODE requires you pass a special string based upon what you want the drop down to display (i.e.: Show Scopes, Don’t Show Scopes, Default to s parameter, etc.) How do you know what string to pass? Well the easiest way to determine this is to go to the Search Settings page of the site collection and view source. Search for the drop down mode you want and you will find the string in the value parameter of an option element. Here is what it looks like.

<option selected="selected" value="HideScopeDD_DefaultContextual">Do not show scopes      
    dropdown, and default to contextual scope</option>      
<option value="HideScopeDD">Do not show scopes dropdown, and default to target results      
    page</option>      
<option value="ShowDD">Show scopes dropdown</option>      
<option value="ShowDD_DefaultURL">Show, and default to 's' URL parameter</option>      
<option value="ShowDD_DefaultContextual">Show and default to contextual scope</option>      
<option value="ShowDD_NoContextual">Show, do not include contextual scopes</option>      
<option value="ShowDD_NoContextual_DefaultURL">Show, do not include contextual scopes,      
    and default to 's' URL parameter</option>

For example, I typically use the option Show and default to contextual scope, so I would choose ShowDD_DefaultContextual.

The last value, SRCH_TRAGET_RESULTS_PAGE cracks me up. Note how the word target is misspelled. It looks like something slipped past QA there. This value specifies the URL to the contextual search page. Typically, I change this to use the URL to my search center as I have mentioned before. Anyhow, if you want to set this value be sure and misspell it.

Now that we know what values we need to set, how do we put it all together with PowerShell? It’s pretty simple. First we need access to the SPWeb object of the root web of the site collection we want to change. You can use Get-SPSite first to do this, but if you know the URL, then you can just use Get-SPWeb. Either way you do it, get yourself an SPWeb object. Here is an example:

$web = Get-SPWeb http://server/sitecollection

If you have the right permissions, you should get a blank prompt back without error. If you get an access denied error, then you need to go make use of Add-SPShellAdmin.

Now that you have the SPWeb object, you can see if any values have been set for search by using the AllProperties collection.

$web.AllProperties

In my case, no properties have been set yet. Now I can set my values. You can set one or more of these in your script.

$web.AllProperties["SRCH_ENH_FTR_URL"] = "/search/pages";
$web.AllProperties["SRCH_SITE_DROPDOWN_MODE"] = "ShowDD_DefaultContextual";
$web.AllProperties["SRCH_TRAGET_RESULTS_PAGE"] = "http://server/search/pages/results.aspx";

After you set your values, don’t forget to call .Update() just like you would when working directly with the object model.

$web.Update();

Executing the script should just return you to the PowerShell prompt if everything worked. You can verify your settings, by looking in the AllProperties collection. For example. Just make sure you get a new instance of the SPWeb object first or you won’t see the changes.

$web = Get-SPWeb http://server/sitecollection
$web.AllProperties["SRCH_ENH_FTR_URL"]

As you can see it’s really simple. Now what if you wanted to set these settings on all site collections?

$webApp = Get-SPWebApplication http://server;
$siteCollections = $webApp | Get-SPSite –limit all;
$siteCollections | ForEach-Object {
$web = $_.RootWeb
$web.AllProperties["SRCH_ENH_FTR_URL"] = "/search/pages";
$web.AllProperties["SRCH_SITE_DROPDOWN_MODE"] = "ShowDD_DefaultContextual";
$web.AllProperties["SRCH_TRAGET_RESULTS_PAGE"] = "http://server/search/pages/results.aspx";
$web.Update();
}

Try that out and see if that works for you.

Using search to find recently modified files in SharePoint 2010

CoreyRoth — Thu, 08 Dec 2011 20:15:24 GMT

Last week, I posted about how we can extend CoreResultsWebPart to show documents created by the current user. Using this same technique, we can also use search to find recently modified documents. If you are a long time follower of my blog, you might remember that I posted how to do with using the Wildcard Search Web Part in SharePoint 2007. In an effort to keep posts updated, I thought I would post a follow up on how we can do the same thing in SharePoint 2010. Since the CoreResultWebPart has changed quite a bit, the solution is quite a bit cleaner and still only requires two lines of code. Again, we are going to create a web part that inherits from CoreResultsWebPart as described in my Wildcard Search Web Part for SharePoint 2010 post.

The first thing we need to do is change the QueryNumber. By default it is set to Query1 (or UserQuery back in 2007) which meant that it was expecting input from the user. In this case, I just change it to Query2.

this.QueryNumber = QueryId.Query2;

Then we just need to construct a query using the Write keyword. I’ve explained its use before in my handy keywords post. It’s syntax is usually something like this. Note that there are no spaces anywhere in the string below.

Write>=”12/1/2011”

Of course this would hard code the date and we don’t want that. So what I do instead is use DateAdd and subtract a number of days. In my case, I want to show all documents from the last seven days. We assign this query to the FixedQuery property. Here is what it looks like.

this.FixedQuery = string.Format("Write>=\"{0}\"", DateTime.Today.AddDays(-7));

Compile your code and deploy it and then you are good to go. Just use this web part in lieu of the regularCoreResultsWebPart. Here’s what it looks like on my page.

That’s all there is to it. One addition, you might want to make to your code is to allow the number of days to be user configurable. You can easily make a web part property that allows the user to specify the number of days.

Using SharePoint Search to display the documents of the current user

CoreyRoth — Fri, 02 Dec 2011 17:43:59 GMT

I see requests for this in the SharePoint forums a lot and I always figured it was pretty easy to do with a few lines of code. Sometimes users want to display a list of documents that the worked on throughout the farm. The CoreResultsWebPart has the ability to execute fixed static queries. However, there is no way for you to specify the current user in the query. I had a need for this myself soon so I thought I would try it out and see if I could implement it. It turns our this can be done with two lines of code.

To implement this we need to create a class that inherits from CoreResultsWebPart. I am doing this in the exact same way I built the Wildcard Search Web Part for SharePoint 2010. You can download that web part from CodePlex if you want to use it as a starting point. What we want to do is set the FixedQuery property. Normally when we do query manipulation, we do it after it has been submitted by the user with GetXPathNavigator(). We don’t need to override that method in this case. Instead, I just put the code I need in the constructor.

this.QueryNumber = QueryId.Query2;

Next, we write a query using the Author keyword. I’ve explained its use before in my handy keywords post. It’s syntax is usually something like this.

Author:”Display Name”

So for example, to search for my documents I would use:

Author:”Corey Roth”

We want to put the user’s name in the Author query dynamically, so we look it up using SPContext.Current.Web.UserQuery. We then just use the keyword syntax above and assign it to the FixedQuery property.

this.FixedQuery = string.Format("Author:\"{0}\"", SPContext.Current.Web.CurrentUser.Name);

Compile your code and deploy it and then you are good to go. Just use this web part in lieu of the regular CoreResultsWebPart. Here’s what it looks like on my page.

Try it out and let me know if you have any questions.

@coreyroth