One of the things I (for I read we) have been working on recently (at my day job) is looking at the ‘Store Compression’ feature in Exchange 2010.

Store Compression is a new feature in Exchange 2010 whereby some of the content of an email object is compressed as it is inserted into the Exchange Information Store (and decompressed on the way out – when it is being displayed to the user). The reason we were looking at this was we initially thought it might compete with our MaX Compression product – a seriously fab product that transparently compresses and uncompresses attachment data in both Outlook/Exchange.

Anyway, this isn’t a sales pitch – so…

I had one of the QA guys do some testing and a side by side comparison. From the results it seemed that our MaX Compression product still gives enormous savings – as significant as it did under Exchange 5.5 – Exchange 2007, so given the general perception that Store Compression compressed the whole email, I wondered whether the feature was actually implemented / enable in the Exchange 2010 beta. Checking with a few MVP colleagues it seems they had been assured it was… so a bit more digging was required.

After speaking to some contacts on the Exchange team at Microsoft, it seems that the Store Compression feature is in the beta (MVPs are never wrong ), but the feature does not compress the whole email object, as many people think – it just compresses some elements of the email object.

It turns out that, as you would expect, compressing and decompressing the whole email object (including attachments etc) as it goes in/out of the Information Store is way too processor intensive and in fact the design goal of the feature was not storage footprint reduction anyway – the original design goal was to reduce I/O throughput to the store so that the (bigger ?) goal of being able to use secondary storage for Exchange could be realized.

So, Store Compression actually only compresses the email headers and any text or html body text. This apparently gave sufficient reduction in the I/O to allow effective performance with secondary storage; it also gave a good balance of I/O optimization against CPU usage (for the overhead of compressing data).

This chart shows the kind of reductions that can achieved with MaX Compression (or any other method of compression attachments), even with the Store Compression feature of Exchange 2010 in action. The two products/features actually work hand in hand, each compression a different aspect of the email object.

More details of MaX Compression and Exchange 2010, how we tested, the results and conclusions can be found here or on the C2C Website.

Today I was looking around for some MSCRM info. I came across a great document on the Microsoft Website, Using Microsoft Dynamics CRM 3.0 Small Business Edition. It is a PDF file but on their Website it has a little Word icon next to it and is described as a 'Microsoft Word file'.

This got me wondering if they were now describing it as this because Word 2007 can work with PDF files ?

I have the PDF add-in for Office 2007 so I right clicked on the file (after downloading it to my desktop) and chose 'Open With'  ..  'Microsoft Word 2007'.

I was then presented with a ' File Conversion' dialog. I left the settings as default and cracked on (clicked OK).

This opened Word and munged in a load of initial PDF data from the file.

About 8 minutes later after a lot of repagination. It tells me that I have exceeded the maximum number of pages supported by Word.

and from the Word status bar I can see the limit is 32,767 

Note to self: Read PDF's in Foxit Reader, not Word.

This is pretty cool. Microsoft (in the UK) are creating downloadable dictionaries for Office that contain words from local dialects.
It is only a matter of time before I can type:

It wisnae me that smashed the windae wi the fitba!     (TRANS: it was not I that smashed the window with the soccer ball)

Without the little red squiggles underneath.