My setup is simply WSS3.0 on a single server using the built-in embedded SQL edition.
1) Download and install the latest Adobe Reader 8. Since release 8, Reader has come with the necessary iFilter built-in.
2) Edit this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\{GUID}\Gather\Search\Extensions\ExtensionList
Add a new string value with Name=(next sequential number available - usually 37 or 38 I believe) and set the Data=pdf
3) Although the Adobe Reader 8 install should have made the following registry change for you, I always like to double-check it:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\Filters
There should be a Key with Name=.pdf
Within the .pdf key, the following entries should be present:
String Value with Name=Extension and Data=pdf
Binary Value with Name=FileTypeBucket and Data=1 (0x00000001)
String Value with Name=MimeTypes and Data=application/pdf
If the entries are not present, add them.
4) The Adobe Reader 8 install should also have made the following registry change for you, but I still check it too:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension
There should be a Key with Name=.pdf
and within the .pdf Key, there should be the following:
Default with Data={AdobeReaderGUID} (in my case it was = E8978DA6-047F-4E3D-9C78-CDBE46041603)
If the entries are not present, add them.
5) Add the Installation directory of Adobe Reader 8 to the System Path:
System Properties (Windows Key + Pause/Break key) - Advanced Tab.
Click Environment Variables button
Scroll down to Path in System Variables and click Edit
Append "C:\Program Files\Adobe\Reader 8\Reader" (or whatever your install path) to the end of the list.
6) Restart the WSS Search service:
net stop spsearch
net start spsearch
7) You are now ready to upload PDFs and they will be indexed for Searching. FYI, any PDFs already uploaded are NOT indexed. I've read you can update them (or their properties) and the Indexer will index them on the next run - but to be safe I generally DELETE and WAIT for the indexer to run again (so I'm sure it deletes any references to them) - and then I REUPLOAD them and WAIT for the indexer to run again. Then after it runs you're sure everything is indexed and searchable.
Showing posts with label Tips and Tricks. Show all posts
Showing posts with label Tips and Tricks. Show all posts
Wednesday, August 19, 2009
Monday, February 16, 2009
Feed your CAML some IntelliSense
Do you have problems in remembering all the key words and formats in CAML? Now this isn't a problem anymore! Thanks to John Holiday and his CAML.NET IntelliSense project. You can find more information about this on his blog: http://johnholliday.net/post/2009/01/18/Feed-your-CAML-some-IntelliSense-so-it-doesnt-bite-you-in-the-you-know-what!.aspx
To download the installer for the project follow this link: http://code.msdn.microsoft.com/camlintellisense/Release/ProjectReleases.aspx?ReleaseId=2212
Friday, December 5, 2008
Hide search on all application screens in SharePoint
Application screens (a.k.a. "_layouts" screens) usually don't display the search in the header. There does appear to be a few screens out there that do, and depending on your design for application screens, this may throw a wrench in how your page looks. To stop the search from showing in any application screen, add the following CSS style to your theme or alternate CSS file:
.ms-searchform
{
display: none
}
.ms-searchform
{
display: none
}
Wednesday, November 19, 2008
Lookup issue for custom content types
If you have the following situation:
You have a couple of lists in your SharePoint application and you want to export their schema.xml file (to make content types based on custom lists created by you in SharePoint). Let us suppose we have some of those lists linked with lookup columns. Then we'll have a problem:
If we'll have the Department list and the Employee list and the Employee list has a column named Department witch is a lookup to the Department list and we extract the schema.xml files from both lists (with the help of SharePoint Solution Generator or OCDExportList) and we'll make a feature with those 2 content types and after that we'll deploy the feature to a different server and we'll create instances from those content types we'll see that the relation between the instances does no longer exist. The Department lookup column from the Employee list will not refer the Department list. Why is that?
If you'll look at the schema.xml file from the Employee list you'll find that your lookup column looks like that:
<field id="{92680819-4656-406f-9eb7-21377cb4eec8}" version="1" group="" rowordinal="0" colname="int2" name="Departament" staticname="Departament" sourceid="{d129f702-1314-4fef-8bdc-4826bc720cd7}" unlimitedlengthindocumentlibrary="FALSE" showfield="Title" list="{A83FD6BE-DE5A-49A6-A369-DA72AF737408}" required="TRUE" displayname="Departament" type="Lookup">
What is interesting here is the following attribute: List="{A83FD6BE-DE5A-49A6-A369-DA72AF737408}”. This attribute tell SharePoint that the lookup field will link to the list instance with the id equals with the GUID given. When you'll deploy it to a new server, the list instance with this id does not exist anymore so it doesn't know how to link the Employee list, so the relations between your lists are not longer used.
To resolve this issue you have to make the following modification:
List="Department" - if you'll provide the name of the instance here (where SharePoint expects a GUID) when you'll create instances from your content types SharePoint will search your current web for lists with the name you provided there, if it will find something it will make the replacement for this instance.
And if you want to be more abstract you should use resources files, so we'll change the attribute with something like: List="$Resources:empmon,list_Departament;" where empmon is your resource file deployed in your 12/Resources folder, and list_Department is your mapping name for your Department list. So when you want to change the lookup for a column (to refer another list) you just have to modify your resource file and when you'll create another instance of that list the new lookup column knows to refer the right list.
You have a couple of lists in your SharePoint application and you want to export their schema.xml file (to make content types based on custom lists created by you in SharePoint). Let us suppose we have some of those lists linked with lookup columns. Then we'll have a problem:
If we'll have the Department list and the Employee list and the Employee list has a column named Department witch is a lookup to the Department list and we extract the schema.xml files from both lists (with the help of SharePoint Solution Generator or OCDExportList) and we'll make a feature with those 2 content types and after that we'll deploy the feature to a different server and we'll create instances from those content types we'll see that the relation between the instances does no longer exist. The Department lookup column from the Employee list will not refer the Department list. Why is that?
If you'll look at the schema.xml file from the Employee list you'll find that your lookup column looks like that:
<field id="{92680819-4656-406f-9eb7-21377cb4eec8}" version="1" group="" rowordinal="0" colname="int2" name="Departament" staticname="Departament" sourceid="{d129f702-1314-4fef-8bdc-4826bc720cd7}" unlimitedlengthindocumentlibrary="FALSE" showfield="Title" list="{A83FD6BE-DE5A-49A6-A369-DA72AF737408}" required="TRUE" displayname="Departament" type="Lookup">
What is interesting here is the following attribute: List="{A83FD6BE-DE5A-49A6-A369-DA72AF737408}”. This attribute tell SharePoint that the lookup field will link to the list instance with the id equals with the GUID given. When you'll deploy it to a new server, the list instance with this id does not exist anymore so it doesn't know how to link the Employee list, so the relations between your lists are not longer used.
To resolve this issue you have to make the following modification:
List="Department" - if you'll provide the name of the instance here (where SharePoint expects a GUID) when you'll create instances from your content types SharePoint will search your current web for lists with the name you provided there, if it will find something it will make the replacement for this instance.
And if you want to be more abstract you should use resources files, so we'll change the attribute with something like: List="$Resources:empmon,list_Departament;" where empmon is your resource file deployed in your 12/Resources folder, and list_Department is your mapping name for your Department list. So when you want to change the lookup for a column (to refer another list) you just have to modify your resource file and when you'll create another instance of that list the new lookup column knows to refer the right list.
Subscribe to:
Posts (Atom)
