Ifilters, TIFFs, and OCR...or why don't my TIF files show up in search queries?

You know that SharePoint (That's at least MOSS and WSS3) is capable of indexing the contents of Office files because it comes with built in Ifilters for those products. You, like myself, have also read the hype about the fact that SharePoint was also meant, out of the box, to be able to index content of OCR TIFF files.

But, when you add a TIFF to a library, and then search for it, the file doesn't come up in the results unless your query includes something from the file's metadata.

And that is because, despite the Ifilter being built in, it is not turned on. In order to enable the ifilter for OCR to be enabled you must enable it in the registry of the sharepoint server (and likely all servers on the farm). The KB article outlining what to do is: http://support.microsoft.com/kb/837847. Please note, as I am in the last throes of editing the book I don't have time to try this puppy out. So all I am, at this point, is the messenger girl. But if I get it to work I'll try to squeeze it into chapter 15. If I can't, well, you'll read about here with screenshots and everything.

Meanwhile, feel free to try it out and see if it works for you.

Document Libraries, Forms, Explorer View, and Combine.aspx, or Hmmm, why's that there?

So I am messing around with libraries while I edit the library chapter, and I came across something that puzzled me earlier (when I was writing the chapter) but I didn't have time to mess with it.

I don't have time to mess with it now, but I can't take the chance of ignoring it either.

Have you ever noticed, when you are in a document library, that you can use Explorer view?

Have you noticed, in Explorer View (or if you use Open with Windows Explorer, you get an explorer window), that there is a hidden folder called Forms?

Have you noticed, in the Forms folder that there is a file called Combine.aspx?

Have you ever wondered what it does or why it's there?

Well, for starts, it is a view page that displays the libraries contents with check boxes so you can select several of the library items in one shot, and a Merge Selected Documents button. However, it will never work for a standard library holding standard documents or other files.

It only works with InfoPath 2007 (see http://msdn2.microsoft.com/EN-US/library/ms452435.aspx for more about it).

So why is it available in a document library? I don't know, but maybe it was an oversight and MS should have removed it before RTM. Maybe it's an unfinished feature left in and forgotten in the rush to release.

Nonetheless, Combine.aspx, which opens a Merge Documents view in a library, is supposed to allow you to merge InfoPath forms, if you are using an InfoPath template for the library (and if you are using a Forms Library you are), and if InfoPath is installed locally on the machine you are using to access the site and perform this function.

What I know for sure is, no matter what you do in a document library, you will always get an error dialog box that is completely useless. It tells you, again and again, to make sure you have the correct template associated with the library and if you don't, and you are allowed to administer the library, please change the template to the correct one---- with no mention as to what the correct one would be (my guess is InfoPath).

I think, despite the fact that Combine.aspx exists in the Forms folder, that's why Merge Documents is not a standard view in the view drop down menu for any library--- not even the Forms library.

Now you know.

SharePoint Security? An oxymoron? An after thought?

You know the old adage, "The only secure computer is one that is off, unplugged, in the back of a closet." Securing data has always been a case of how inaccessible you want the data to be. If accessing data easily from anywhere is the main focus of a product, chances are good that security will not be.

I was recently asked to submit some abstracts to a conference in Toronto (absolutely *love* that city, those people rock). It's a hardcore security conference. And they want me to, since I am so into WSS, to focus on WSS security.

Now I am talking hardcore, 300 to 400 level security; threat modeling, hack-this-box kind of stuff. Real white hat/black hat, exploit people.

So, what would I talk about concerning security to this jaded bunch of experts?

How about being prepared for the disgruntled administrator? About *really* securing Central Administration? Or what damage you can do with knowing the server farm account, or content database accounts? Or what nefarious things can be done with policy for web application? I dunno. I have been so busy, so overwhelmed, with documenting all the normal functions of sharepoint, I really haven't had time yet to focus on exploiting it.

And now, in the middle of editing, maybe I should. I know, I am doing something else, but this is how it happens. You never get opportunities when you can do them, only when you are too busy to think about them. But inevitably, those opportunities come up, like a call for papers, months before the actual event takes place.

So, in order to have a job at all in November, I have to find time to respond now.

I'll let you know what I come up with, and whether or not they are accepted, as soon as I can.

I just had to get this off my chest-- something I forgot to say about Closed Web Parts gallery

Okay look, in chapter 4, I talk about, and demonstrate, using the closed web part gallery.

But there's something I forgot to say, and it is driving me nuts.

The closed web parts gallery is page specific. It makes sense. If you close a web part on a page, sharepoint will remember it in case you change your mind.

It is not site wide, it is not site collection wide. If you try to be clever and close a web part on page one, thinking it would go to the closed web part gallery and be available on page two, you would be sorely mistaken. See, that's what exporting and the site collection web part gallery are for.

Further, the closed web part gallery is page view version specific. In otherwords, and this makes sense if you think about it, if you have a web part on a page's shared version, it will be on your personal version of the page. Then if you edit your personal version, and in doing so close the web part, it will show up in the closed web part gallery for that version of the page, only.

If you go back to the shared version of the page, the web part is still there. And if you check the galleries, you'll see that its not on that version's closed web parts.

Something else to keep in mind is if you have many, many closed web parts associated with a page or page version, it might load more slowly. So if slow page loads have begun to plague your home page, check to see how many closed web parts might be lurking in your (or the user's) closed web parts gallery. Consider that when configuring the web parts, you might want to allow delete (which deletes the web part from the users' personal version of the web part page), but not close-- just in case.

I really wish I'd remember to put this in. I just hit send, then remembered.

Sigh, so much minutae, so little time...

W00t, Technorati, claim me away!!!

Technorati Profile

technorati needs to me add this link to a post so it will let me claim my blog so it can start pinging it. Hey, I'm all for that right? So here goes....