Corey Roth [MVP]

One of the things that drove me absolutely nuts about Enterprise Search in MOSS 2007 was that there was no built-in way to export your managed property mappings and install them on a new server.  A third party utility on CodePlex helped, but it was still less than ideal.  With SharePoint 2010, well you still really can’t export your property mappings to a file, but you do get a lot of flexibility using PowerShell.  By taking a proactive approach, we can use PowerShell instead of the UI to create our property mappings. We can then use these same scripts later when its time to move these settings to production.  The SDK does a pretty good job with examples on how to use all of the commands we need, but I found a few minor errors and omissions.  We’ll look at some of the individual commands and then put it all together.  Our goal at the end of this is to have a .ps1 script that you can store in your source control system.

The first thing we need to do is get a reference to our search service application.  By default, it just so happens to be called Search Service Application.  However, if you installed it manually, or are using FAST, it is likely to be called something different.

We assign this to a variable called $searchapp (or whatever you want) so that we can reference it later in the script.  In today’s example, I have some site columns on a document library that I want to use as managed properties.  In this case I have site columns called TestProperty1 and TestProperty2.  If I were to perform a full crawl, Enterprise Search would automatically create crawled properties called ows_TestProperty1 and ows_TestProperty2.  However, I want to save myself some time and skip that full crawl.  This is especially valuable when you have a large index.  Luckily, I can just create these crawled properties using PowerShell using the New-SPEnterpriseSearchMetadataCrawledProperty command (i know that’s a lot to type).  The syntax is pretty simple, but there are a few gotchas.  First the VariantType parameter isn’t entirely obvious.  I know 31 is text, but I’m not sure exactly what value to use on other types.  The link from the SDK give you quite a few values (note they are all in hex), but I still need to figure out the rest of the values sometime.  The other thing is the PropSet parameter is marked as optional when in fact it is required.  I’m really not sure what value you should use here and when so I just used the same GUID most crawled properties used (viewable from the UI), 00130329-0000-0130-c000-000000131346.  We also have to get a reference to the crawled property category that we want (in this case SharePoint) so we call Get-SPEnterpriseSearchMetadataCategory first and pass that to the Category attribute.   Here is what the commands looks like to create TestProperty2.

You can verify that it was created in SharePoint using the UI.

Now, we need to create a managed property using the New-SPEnterpriseSearchMetadataManagedProperty command.  The documentation on the Type parameter for this command is a bit sketchy too.  Currently, it lists the six managed property types Text, Integer, Decimal, DateTime, YesNo, Binary, but it doesn’t say what the value for each one is (the parameter requires an int).  From the example, they give I was able to determine that 1 is a test.  At some point, I’ll go find the enum in the SDK and see what the rest of the values are.  The rest of the command is pretty simple, just specify a name and pass a reference to the service application.

You may have noticed I am assigning the result of each New command to a variable.  This is so that we can pass that in to the New-SPEnterpriseSearchMetadataMapping command.  Just pass in references to the service application, managed property, and crawled property and you are done.

Here is what the command looks like in PowerShell.  It simply gives you info on what was created.

If you need to map multiple crawled properties to a managed property simply call the command repeatedly with a reference to each crawled property.  Once you finish, you can verify in the UI that the managed property was mapped successfully.

At this point, you need to do a full crawl to make use of your managed properties.  Here is what the whole script looks like put together with multiple mappings.

It seems like a lot but it really isn’t.  I create two managed properties (TestProperty1 and TestProperty2).  In the case of TestProperty2, I actually map two crawled properties to it. 

As far as I am concerned this is the only way to go from now on when it comes to doing property mappings.  Once you have the script down, it’s much faster than clicking through the UI and of course you can run it on other servers.  Be sure and give it a try as you start setting up search on all of your new SharePoint 2010 deployments.