Let’s suppose you are migrating from an existing Records Management solution to Records Center in SharePoint 2010 to manage your records retention and disposition. How do you import and/or create your existing file plan in SharePoint? The Microsoft.Office.RecordsManagement.InformationPolicy assembly that ships with SharePoint Server 2010 has some methods to help you.

1. If you are enforcing policy based on library and/or folder, you would use ListPolicySettings.SetRetentionSchedule provided by SharePoint 2010.
2. If you are using Content Types to enforce your retention schedule, then you would use Policy.CreatePolicy on the Content Type and put your retentionXml in the CustomData of the PolicyItem.

When you read through the msdn article, it is unclear exactly how to construct the retentionXml parameter to provide a retention threshold/duration/activity. A sample retentionXml fragment that will start a workflow ten years after a document is created is included below. Another great blog post that outlines how to define custom expiration formulas and activities (as well as more xmlRetention samples) is available as well.

<Schedules nextStageId="2" default="false">

   <Schedule type="Default">

      <stages />

   </Schedule>

   <Schedule type="Record">

      <stages>

         <data stageId="1"><formula id="Microsoft.Office.RecordsManagement.PolicyFeatures.Expiration.Formula.BuiltIn">

            <number>10</number>

            <property>Created</property>

            <propertyId>8c06beca-0777-48f7-91c7-6da68bc07b69</propertyId>

            <period>years</period></formula>

            <action type="workflow" id="3b3dc6ae-283f-4455-a156-175dd2fa87e9" />

         </data>

      </stages>

   </Schedule>

</Schedules>

I was recently patching some servers when I ran into an issue with the October 2011 Cumulative Update updating on all of the servers. It would get to 17% and fail. When I looked in the Event Logs, there was an error from SPUpgradeJobDefinition that has some standard text followed by localStoragePath. This is a new one for me, but after looking around a little bit, I found this article that describes the problem. Sure enough, the search topology was throwing errors. We deleted the SSA and reran psconfig and it ran through with no errrors.

This was a reminder to me that there is a defined process for patching and upgrading SharePoint, and I had skipped “Document the environment”. If I had taken the time to review the environment before getting started, I would have seen this error and fixed it before I got started. So review the process, learn it, love it, and live it.

Has the question of SharePoint Search vs. FAST Search come up in your planning sessions? Do your users have requirements that can “only” be met with FAST Search? Is Search Server Express an appropriate decision in your environment? Microsoft has provided a range of enterprise search products so teams have options when deciding how to provide search functionality in their project. This means that teams need to make an additional decision when choosing to provide search, which product is right for me? Every situation needs to be evaluated on the merits, but I’ll provide you some quick questions to point you towards an appropriate product.

1. Installation on a single server and no licensing costs? Go with Search Server Express. This edition provides for up to 10 million items(which requires installation on an external database. No database, you’re limited to approx 500,000 items.)

2. Provide Search using out-of-the box features for up to 50 million items? Go with SharePoint Server 2010. SharePoint Server 2010 provides search capability for up to 100 million items, so 50 million items still provides plenty of upside room to grow. However, if the corpus of information to be searched is under 50 million items, SharePoint Server 2010 should be capable of meeting your needs.

3. Searching between 50 million and 100 million items? This range is not so cut and dry, both SharePoint Server 2010 and FAST Search are reasonable choices at this range. The hardware requirements for both search technology will be similar, so more research is necessary at this level? Are you sure that you won’t go over 100 million items to index? Are you planning on augmenting SharePoint Search with third party functionality that may be available in FAST Search? What are the needs defined by your search administrator (at this level, search rankings, relevancy, and sources needs to be actively managed, and is likely becoming a full time role).

4. Searching over 100 million items? Go with FAST Search for SharePoint. Microsoft has tested FAST Search with over a billion items and provides prescriptive guidance for sizing and operating farms well over 500 million items.

5. Building a Search specific application? In addition to customer/user facing applications, these technologies are appropriate for component use by developers. Your architect and development team needs to define their needs and look at the extension points available in these products to determine the proper product. The FAST Search architecture provides many more extension points to allow developers to customize how the engine crawls, indexes, and organizes search data. Episode 64 of the SharePoint Pod Show goes into detail about these types of decisions, and I encourage you to give it a listen.