If you have a SBS 2003 server running Intelligent Message Filtering, and you're using ORDB as one of your Real Time Block lists, some time around January 7th, your SBS server may have stopped routing inbound faxes to an email recipient.  The official SBS Blog wrote this post on the issue a couple days ago, but we started experiencing the problem about a week ago, before we could find any information on it.

We resolved the problem by using the Custom Weighting feature in Exchange.  This is a feature that allows you to specify key words or phrases that if IMF finds in an email message, will cause it to allow the message through.  You can find this discussed about half way down the page here:  http://download.microsoft.com/download/f/b/5/fb5c54af-fe5c-48e9-be97-f9e8207325ab/Ex_2003_SP2_RelNotes.htm

We added a line like this:

<CustomWeightEntry Type="SUBJECT" Change="MIN" Text="FAX"/>

Admittedly, this isn't the best solution for the problem, but the custom weighting feature is still something that should be enabled on SBS if you're using IMF.  We likely won't remove the line, and we can quickly add more strings any time.

Over on my OZ blog, I wrote a couple of posts about using folders in SharePoint lists and document libraries.  I bemoaned the use of folders in SharePoint document libraries and lists as a way to organize large quantities of documents. 

Finding something in a digital folder hierarchy can be impossible unless you already know the hierarchy. For example, I've seen top level folders in these hierarchies that align with a company's departments or divisions, beneath these are folders for fiscal years, then maybe some folders that describe activities.  What's the problem with this? If I'm new to the company, I pretty much need to understand the business before I can find the document I need.

It seems pretty natural to want to organize things just like you might in your physical filing cabinet, but a filing cabinet doesn't do things like search or filtering, and a computer doesn't expose things in a tactile way like a filing cabinet.  Back in the DOS days, if you had a folder hierarchy like the one I described above and you wanted to find a file with a certain string of characters in the file name, you could issue a command like this:

DIR budget*.xls /s

This would search through the hierarchy relatively quickly and list the files matching the pattern along with the folder in which the file resides.  In Windows, you could use Search, but it's fairly slow because windows has to parse through the contents of the hierarchy one file at a time.  Then along came desktop search which indexes the file system, making searches much faster. Nice, but we're still using a pretty blunt tool. What if we could label files with certain terms appropriate to our business and then quickly expose them based on those labels? 

We can add custom document properties to a file, but in Windows explorer, there's no way to include the custom property as a column and then filter or group on that column.  For example, what if I put all my files in one folder, and all my documents had custom properties called "Fiscal Year" and "Division"? Then, what if I could have a shortcut on my desktop that opened Windows Explorer and showed a list of files from my folder whose custom properties contained 2007 for Fiscal Year, and Manufacturing for Division?  Or what if another shortcut listed all the files in my folder, but grouped things by Division and then by fiscal year? This would be like a Pivot Table for your files... but to me it's like Microsoft gave us these Custom Properties and then didn't give us anything we could do with them.

The bad news is that the file system can't do this.  The good news is that SharePoint can. 

Custom Document Properties are metadata.  Being able to manipulate file listings based on their metadata is one of the core pieces of functionality in SharePoint.  My opinion?--- don't use folders in the file system OR SharePoint.  In a SharePoint document library, custom document properties can be promoted or demoted to/from the document library's columns (effectively linking the two). I believe we should use SharePoint, properly describe our documents with Columns (and/or custom properties), and then use custom views to filter and/or group based on these.  It gives you the ability to simulate a folder like experience, but it's important to note that in SharePoint, if you nest documents in folders, this doesn't work.