Tool for Deployment of SSP search settings

I recently had the dubious honor to transfer search settings from one SSP to another. Going through every managed property, content source, search scope etc. just wasn’t something I looked forward to. On top of that – in the near future I will have to do it again when we deploy another SharePoint site to production.

Searching the net I found a tool created by Sahil Malik that could create the managed properties for me (link), provided that you manually merged some xml dumps of crawled and managed properties. Thanks Sahil for that great start – I needed something more therefore this post.

I modified Sahils code to suit my additional needs. It took me two full days to complete and test the code and in the end I guess that about 30% of the code base is Sahils original code.

I now have a tool that can import/export content sources, crawled properties, managed properties and (shared) search scopes – and it works!

I designed the import procedures so that they create, or synchronize, the destination SSP search settings with the xml files given, but do not delete anything not in those files, i.e. it will synchronize/create all the managed properties in the input xml file but not tough the existing ones not mentioned in the input file.

Ok, here are the details for the various operation types. The order listed here is the order that they should be imported in a complete SSP import.

Content Sources

Type, name, schedules, start addresses etc. are all handled. As far as I know that is everything, I’ve not been able to test the Exchange and BDC content sources, but they should work.

If you are transferring settings between two servers you probably want to correct the search start addresses as they are likely wrong. I’ve not tried to do anything fancy with automatic recognition of the local farm address and the like as the risk of error is too great, I wanted to keep the focus on the SSP settings not the various sites and their access mappings etc. Sorry for that you can’t have everything.

There is an option to start – and wait – for a full crawl after the import (“-FullCrawl”). This will allow the indices to be built and crawled properties will automatically be added for the crawled content. This is the “normal” way to create crawled properties.

Currently the program will wait a maximum of two hours for the crawl to complete, it will probably be configurable in the future (if I need it).

Crawled Properties

It is possible to import as well as export these. I should stress that the import operation should be considered experimental.

Why would you want to import crawled properties? They are usually created by the crawler and are available for use in managed properties immediately afterwards. However if the content in question have not yet been created (e.g. you are deploying a site to a new farm) or if you don’t want to wait for a full crawl before you create the managed properties, you might want to import them.

I’m not really using this feature myself so I don’t consider my testing to be conclusive enough.

Managed Properties

The code to import and export managed properties is originally from Sahil Malik, though considerable redesigned and bug fixed. It is now possible to dump all managed properties from one site and import them to another – there is no need to extract the standard system managed properties from your own custom (you are welcome if you want to), all can be imported with no changes.

The import will fail if one of the managed properties maps to an unknown crawled property, then you might need to either schedule a full crawl to create the crawl properties or import them too.

The “remove excess mappings” option (“-RemoveExcessMappings”)can be used to delete mappings from existing managed properties to crawled when those properties exists in the input xml file with other mappings, i.e. using this option will ensure that the SSP managed properties are exactly the same as those in the xml file after the import.

Search Scopes

The shared search scopes (those defined in the SSP) are fully supported – settings and rules are all transferred. The import will prune the scope rules to match the import xml file.

The import will fail for scopes that use property rules if the managed properties used has not been defined or marked for use in scopes (the “allow this property to be used in scopes” switch. Import of the managed property includes this setting).

The option “-StartCompilation” starts a scope compilation after the import but not wait for completion (not much point in waiting for that).

The one thing is missing from the scope import is scope display groups. They are of used on sites to populate the search scope dropdown (and some of my own search webparts as well) and are quite important for the end user search experience. You will have to set those yourself as I limited the scope (sorry for the pun) of the program to the setting stored in the SSP. Should be fairly easy for a site collection administrator to enter them however. In a similar vein any site specific search scopes are not handled. I don’t use that feature at all so there’s no support. Perhaps a topic for future improvement.

which assumes the presence of input files “output_contentsources.xml”, “output_managedproperties.xml” and “output_searchscopes.xml” generated above.

Code Design Notes

Sahil Malik named the program SSPC (supposedly short for “Shared Services Provider Property Creation”) and the corresponding project name on the codeplex site is SSSPPC (“Sharepoint Shared Services Search Provider Property Creation”). It’s a mess and now that I’ve expanded the scope of the program considerably the name is even more misleading now.

Just to avoid further confusion I’ve refrained from renaming the program.

Sahil Malik spent some time doing a proper code design for the initial version. I personally think that he did go a bit over the top (sorry Sahil), but I’ve nevertheless retained most of the basic design.

He split up the code in a number of layers (we all love that) where each layer is a different class-library project. I kept that design and therefore the download will contain a number of dll files as well as the actual exe file. Just keep them all in the same directory and all should be well.

Some comments:

I did not change the naming of the existing projects (i.e. they are all named “Winsmarts.*” though I did change a lot of the code) but the ones I added are named “Carlsberg.*”

I redesigned/recoded the managed property import section as I simply hate duplicated code and deleted the duplicated BO classes that were present in the old “MAMC project” (now moved to “Winsmarts.SSPC.ManagedProperies”).

The import code is now always present in the same project that performs the export.

The managed property import/export is now complete in the sense that it can now export and import everything including the system properties. No need to sort through it all and find the ones you are responsible for (though it might still be a good idea to sift through and ensure that old test data are removed)

I renamed a number of the classes as some of the BO objects were named as their SharePoint counterparts and the code was quite a bit harder to read than it needed to be.

Version number of all (sub) projects has been changed to 1.1.0.0.

Error handling is still pretty basic so you’ll get an exception with a stack trace in the console if anything is amiss

[Updated]

My code changes has now been merged into the main code base at the codeplex site. These changes breaks everything in the original code, so you will need to update xml and script files…

Future Improvements

This is the list of future improvements I’ve noted that might be added if I find the time and need for it.

[Updated: Done] The code could be cleaned up somewhat (there shouldn’t be any todo’s in released code)

Perhaps site scopes should be added

Scope display groups might be added (requires some connection from SSP to the sites)

It might make sense to add these commands to the list of operations supported by stsadm, which is fairly easy to do (see Andrew Connells excellent post for a sample)

[Updated: Done] I’m not too fond of the serialization classes – basically the same piece of code is copied four times with minimal changes. I always consider duplicated code as a bug

Downloads

[Updated]

The code has now been merged with the existing code base at codeplex, so head over there for the latest download.

I get the error message “”The propset 9a93244d-a7ad-4ff8-9b99-45ee4cc09af6 is not contained within this category Category 12”, while this crawled property did exist on the system I exported my crawled properties from it won’t let me dynamically create these properties on the new system.

I do understand that if I run a full crawl on the new system then the crawled property will be discovered but the situation I’m running into that at the time my importing code is being run its not guarantied that the system has run a full crawl and I don’t want to wait for a full crawl to complete before finishing my import.

Have you run into this situation? Any suggestions on why the CreateCrawledProperty isn’t working as I expected?

Neither me nor Sahil apparently needed that feature so it was never implemented. It shouldn’t be too hard to do though.
Copy/paste the existing code structure for a new branch and define how to export/import crawl rules.

whether that is enough to ease your mind is up to you. However if everything goes down the drain and my tool kills your search (it has never happened to me!) you can always just delete the SSP and create a new one (you can maintain mysites regardless). The backup plan is sound.

I am personally in the process of doing complete search settings replication from “known set” to a series of dev + test + QA + finally production servers.
However, for sanity reasons, I tend to use powershell. I know. Lose my sanity trying to command sharepoint from there. What I mean is, to be able to “see” and understand completely what search settings are moved etc, and limiting and changing the code without vstudio and executables and worrying about context and so forth and so on.

I have successfully done the search content source settings, BDC I prefer to import manually, SSO manually as well as the settings vary per environment.
I am yet to do managed properties export + import but I will do so using powershell, hopefully the codeplex code will give me pretty much all of it.
Then I only have display group and search scope settings, and those can be done easily using powershell.
I also prefer to do all of these in separate scripts, which can of course be chained if desired. This allows complete freedom since it’s text files, to the “end user” using the scripts.
Also, powershell 2.0 (which was never distributed continuing the ctp name but under the Microsoft name “windows management framework), allows nice write-to-xml and read from xml direct functionality.

I am merely stating this as a comment, and I guess I will approach gary lapointe to add the scripts to his sets or something at some point.

Not directly. All values are exported, however it is possible to modify the xml afterwards to remove some values. Or perhaps more to the point to only include the small subset that you are actually interested in.

It works well for us to only maintain the few managed properties that we actually care about and only import those into the SSP.