Installing PDF iFilter for SharePoint 2010

One of the most common things you will ever need to do on a new SharePoint server is to install the PDF iFilter to ensure pdf’s are crawled and hence searchable.  I found a good blog post here written by Syed Adnan Ahmed from which I have copied the following content.

Follow the steps below to install and configure PDF iFilter on SharePoint Server 2010 or Search Server Express 2010.

1. Install PDF iFilter 9.0 (64 bit) from here.
2. Download PDF icon file from pdf16.gif and copy at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IMAGES\.
3. Add the following entry in docIcon.xml file, which can be found at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\XML.

   <Mapping Key="pdf" Value="pdf16.gif" /> 

   
   
4. Add PDF file type on the Manage File Type page under Search Service Application.
   
5. Open registry by executing regedit on the Start --> Run.
   
6. Navigate to the following location:

   \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\
   14.0\Search\Setup\ContentIndexCommon\Filters\Extension 

   
   
7. Right-click Extension, a menu will appear.
   
8. Click New--> Key to create a new key for .pdf. See screen shot below:
   

   

   
   
9. Enter .pdf and save key.
   

   

   
   
10. 
    

    Now add the following GUID in the default value as shown in the figure below.

    {E8978DA6-047F-4E3D-9C78-CDBE46041603} 

    
    

    

    
    
11. If you are configuring SharePoint Server 2010, then restart Search service by executing the following command on the command line:

    net stop osearch 
    net start osearch 

    
    
12. If you are configuring PDF iFilter on Search Server 2010, then restart the SharePoint Server Search 14service as shown in the figure below:
    

    

    
    
13. Perform incremental to include PDF files.
    
14. PDF iFilter is successfully configured. Now you can search for the content of PDF file. See screen shot below:
    

    

Note: SharePoint Server 2010 or Search Server 2010 Express provides out of the box search support for .ZIPfiles, so you download and have to install Microsoft Filter pack as you used to do with MOSS 2007

SharePoint user profiles

Just thought I would write a quick note to remind myself about a good post that I found a while back.  I’ve been fire fighting a problem with a botched migration where the user profiles are all out of sync with the new domain.  This blog explains in enough detail the steps you need to take to resolve user profile sync issues, especially between WSS and MOSS profiles (beyond doing a full profile import):

http://sharepointnotes.wordpress.com/2008/05/05/syncing-wss-and-moss-user-profile-properties-with-active-directory/

Migration techniques

Just a quick note on migrations. I am currently performing migration for a client from 1 domain to another. Now due to certain security issues, I couldn't have access to the source database/ SharePoint installation. The only details that were provided were the SharePoint version including service pack number as well as the database backups for each web application.

On attempting to use the STSADM tool to backup and restore, I had version mismatch errors. Unfortunately, there was not more details for me regarding version numbers. Therefore the only way to restore the sites, was to create blank site collections and then to delete/ re-attach the content databases.

I came across a problem. After restoring a single site collection once. I couldn't restore this site collection again for testing purposes - even on a different web application. This is because the GUID that is stored in the config database is unique to the site collection. Detaching and Re-attaching the content database does not give any site collections new GUIDS - hence you can only have one instance of them in a farm.

If you use the STSADM tool, when you use the command -restore, a new ID is generated for each site collection and hence you can use the same site collection as many times as you want.

Grouping documents through folder content types

With the advent of document sets in SharePoint 2010 and the ability to provide grouping between sets of documents, I thought it would be nice to see how we can mimic similar behaviour in SharePoint 2007/ WSS 3.0.

 

A nice way to group documents is to create a new folder content type by extending the OOTB one.

 

To start with you will need to create site columns which you want to use to classify your folders. You can do this via the GUI interface, or release these in a feature as part of a WSP package. For the purpose of this example I have created an 'IsClient' site column which is a multi-choice field with 3 options.

 

You can then go to create a new site content type via Site Settings -> Site content types. On this screen, ensure you select the parent 'Folder Content types' and select the 'Folder' option as the parent:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

After creating the content type, you must specify which site columns you wish to use with the content type:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In this case, you can see the IsClient site column I created earlier. After we have created our site content type and allocated the relevant site columns to this folder, we need to add this new folder content type to a document library. First you need to make sure you can manage the content types for the document library by going to the 'Advance Settings' page of the document library and setting the 'Allow management of content types?' to YES.

 

You can now add the 'Client Folder' content type to the document library by clicking on 'Add from existing site content types' and selecting your folder content type:

 

 

 

 

 

 

After you have done this you will be able to see the folder option on the toolbar for the document library:

 

 

 

 

 

 

 

 

 

 

 

 

 

Now you will be able to classify this new folder using the metadata you have specified in its columns:

 

 

 

 

 

 

 

This feature is extremely useful if you want to quickly group documents based on specific meta data. You can also use this new folder for filtering document library views based on the folder metadata. I have since integrated this into SharePoint search to allow for us to search for specific folder types.

SPFile.Versions

Recently I had a task to run an audit of a document library and to retrieve files and versions where specific fileds had changed for a version or a new version of the file had been uploaded.

Comparing changes in metadata fields across versions is easy, you simply get the versions collection of a listitem using: SPLIstItem.Versions[int] and then use the field properties to get the value for a field for a specific version e.g. SPLIstItem.Versions[int]["Revision"].ToString().

I tried to do the same thing for file sizes : SPLIstItem.Versions[int]["FileSize"]. One would think that this would retrieve the size of the file for this specific version. The answer is no. This code retrieves the latest size of the file, meaning no matter which version is specified, it will always return the same value.

The way to determine the file size for a specific version is to use the versions collection of the SPListItem i.e. SPistItem.File.Versions. When iterating through the SPFile.Versions colelction, there is an important point to note.

The interesting point is in comparing the version count for the 2 methods of retrieving versions:

SPListItem.Versions.Count vs SPListItem.SPFile.Versions.Count

SPListItem.Versions.Count is always 1 more than SPListItem.SPFile.Versions.Count. The reason for this is because SPFile deems the latest version as the current version and therefore does not include this in its version collection. Therefore SPListItem.Versions.Coun[1] represents the same entity as SPListItem.SPFile.Versions.Count[0].

An example of how I have used this is :

int versionCount = 2;
//current_Item is an SPListItem object;
string status = current_Item.Versions[versionCount]["Status"].ToString();
int currentSize = current_Item.File.Versions[versionCount - 1].Size;

I hope this saves someone some time!