May 2010 - Posts

You may - or may not - need to register Filter Packs after you install them.

As a prerequsite for installing Exchange 2010, you must install the Office 2007 Filter Packs. As noted in a recent blog post of mine, Office 2010 Filter Pack for Exchange 2007 and Exchange 2010, the Office 2010 Filter Pack was recently released. After installing Exchange 2010, you can upgrade to the Office 2010 version of the filter pack (and this is also supported for Exchange 2007).

It may be that Exchange 2010 SP1 will require the Office 2010 version of the filter pack.

However, it has recently come to my attention that installing the filter pack, regardless of the version, does not automatically cause the filter pack files to be registered to index the affected document types by Exchange server! After surveying several of my customer's Exchange servers, I determined that the set of documents that would be indexed by Exchange is dependent on what was being indexed by earlier versions of Exchange.

Therefore, after installing the filter pack, you still need to Make This Happen (tm) - i.e., ensure that the filter packs are registered. Smile

For Exchange 2010, the official Microsoft document is Register Filter Pack IFilters with Exchange 2010. An improved version of the script has been created by Pat Richard, and is available here. Pat's version also handles the required registration for the Adobe PDF iFilter pack, if you have downloaded and installed it.

Until next time...

If there are things you would like to see written about, please let me know.

Posted by michael | with no comments

One of the prerequisites for both Exchange 2007 and Exchange 2010 is to install the "filter packs". The filter packs are responsible for "filtering" the content of Microsoft Office documents and passing those contents back to the Indexing Service (ok, it's not called the Indexing Service anymore - it's Microsoft Search - and Exchange 2010 uses a slightly customized version of Microsoft Search called "Microsoft Search (Exchange)").

In Exchange 2003 and before, creating a full-text search index was optional - and "expensive".  Beginning with Exchange 2007, it became cheap (due to Exchange's use of the much improved Microsoft Search engine) and required. All Outlook Web App (Outlook Web Access) searches and all Outlook (online) searches use that index.

So, with the release of Office 2010, Microsoft has also released an update to the filter packs that support Office 2010 (plus a few other document types). The new filter packs can be installed on Exchange 2007 and Exchange 2010 (and it seems likely that they will be required for Exchange 2010 SP1). Filters are built-in for the following formats:

Legacy Office Filter (97-2003; .doc, .ppt, .xls)
Metro Office Filter (2007 and 2010; .docx, .pptx, .xlsx)
Zip Filter
OneNote filter
Visio Filter
Publisher Filter
Open Document Format Filter

You can download the Microsoft Office 2010 Filter Packs here

However, you may notice that a common file format is missing! PDF. In order to scan and index PDFs, you need to install a filter available from Adobe, the Adobe PDF iFilter 9 for 64-bit platforms. That will work with both Exchange 2007 and Exchange 2010.

Bharat Suneja, an ex-Exchange MVP who is now working for Microsoft, provides additional information about index generation and scanning on his blog Exchangepedia.(He gave you some stuff I didn't - and I've given you some stuff he didn't. It all works out!) :-)

Until next time...

If there are things you would like to see written about, please let me know.

Posted by michael | 1 comment(s)

Another Exchange MVP, Pat Richard, posted on Facebook yesterday: It would be nice to be able to import a list of all Exchange related PowerShell cmdlets into the Word and Outlook dictionaries.

Being the helpful guy that I am, I responded: You can do that in one-line of PowerShell.

(That being a famous quote from Jeff Snover, one of the main men behind PowerShell at Microsoft.)

Then I started thinking about it. And well, you CAN do it in one line of PowerShell. It just depends on how clever you want to get and how long a line you are willing to type! Regardless, you should only have to do it once.

Now, be aware, I'm running Office 2010 - file locations might be somewhat different for you.

Let's build that one liner.

First thing was to find where Word 2010 stored custom words added to the dictionary. F1 (Help) in Word gave me that - CUSTOM.DIC.

Second was to locate the physical file:

PS C:\Users\Administrator> cd \
PS C:\> cmd /c dir custom.dic /s
 Volume in drive C has no label.
 Volume Serial Number is D888-0076

 Directory of C:\Users\Administrator\AppData\Roaming\Microsoft\UProof

05/10/2010  08:50 AM            11,902 CUSTOM.DIC
               1 File(s)         11,902 bytes

     Total Files Listed:
               1 File(s)         11,902 bytes
               0 Dir(s)  77,055,504,384 bytes free
PS C:\>

Ah...good. So the filename is:

join-path C:\Users\Administrator\AppData\Roaming\Microsoft\UProof CUSTOM.DIC

or just


If we examine the file, we see it's a simple Unicode file containing one token/symbol per line.  

How do we get the list of Exchange commands? Get-ExCommand, of course. But...if you aren't running the command on an Exchange server or on a workstation where the Exchange Management Tools are installed (e.g., you are using remote PowerShell to connect to an Exchange server), you won't have Get-ExCommand. It's a non-exported function. However, you WILL have the Exchange module you can use. So, to get the Exchange commands:

Get-Command -module $global:importresults

Note that $global:importresults can potentially contain more than just the Exchange module. It is a list of all imported modules.

We notice that this returns more than we want. We really just want imported functions and cmdlets that have valid names. So:

Get-Command -module $global:importresults | ?
    { ($_.CommandType -eq "cmdlet" -or $_.CommandType -eq "function") -and $_.Name -notmatch ":" }

That gives us our valid Exchange cmdlets and functions! However, all we are interested in is the name of the function; not all the other garbage:

Get-Command -module $global:importresults | ?
    { ($_.CommandType -eq "cmdlet" -or $_.CommandType -eq "function") -and $_.Name -notmatch ":" } |
    Select Name

Excellent. Now we have the names we want and we know where we want them to go! So let's save them:

Get-Command -module $global:importresults | ?
    { ($_.CommandType -eq "cmdlet" -or $_.CommandType -eq "function") -and $_.Name -notmatch ":" } |
    Select Name |
    Out-File -Append C:\Users\Administrator\AppData\Roaming\Microsoft\UProof\CUSTOM.DIC

or, since we know that's the per-user AppData folder: 

PS C:\> $env:AppData
PS C:\>

we can also say:

Get-Command -module $global:importresults | ?
    { ($_.CommandType -eq "cmdlet" -or $_.CommandType -eq "function") -and $_.Name -notmatch ":" } |
    Select Name |
    Out-File -Append (join-path $env:AppData Microsoft\UProof\CUSTOM.DIC)

And there you have it. A LONG one-liner, but a one-liner nonetheless.

This does assume that you are running this on the same workstation where the custom dictionary resides.

This procedure should be generalizable (is that a word?) for any module.

Pat and I both worked on this going back and forth on FB. An interesting way to develop a script!

Until next time...

If there are things you would like to see written about, please let me know.

P.S. Pat went on and further developed the script to automatically choose an Exchange server, connect to it, and update the CUSTOM.DIC. To see that, visit his website.

Posted by michael | 3 comment(s)
Filed under: , ,

Public Folder Contacts Can't Replicate

If you have a public folder contact that includes an e-mail address, there is also an e-mail address type field that is associated with every e-mail address.

Note: You cannot see this e-mail address type field by default - but it's still there. To view it, go to a Contacts folder in Outlook and create a custom view. In that view, add "Full Name", then select "E-Mail Address Fields" and add "E-Mail Address" and "E-Mail Address Type". Now, examine the Contacts in the folder using the custom view. You'll see e-mail address types such as "SMTP" for external Internet contacts, "EX" for internal organization e-mail contacts, "FAX" if you have a fax connector installed, etc.

Now, Exchange 2003 (and perhaps Exchange 2007 - I have not checked in my lab) allowed two differerent e-mail address types to indicate "SMTP". I believe this to be a hold-over from Outlook 97, although I have no documented proof of that (but in Outlook 97 we had "Internet mode" and "Corporate or Workgroup mode" - so it makes sense). The two different types are "SMTP" and "POP3/INTERNET".

"POP3/INTERNET" is not valid in Exchange 2010. If you attempt to replicate a public folders to Exchange 2010 that contains this e-mail address type, the replication will abort. Thankfully, you do receive an event log error message that provides SOME clues about this occurring. The error looks like this:

Event Type:      Error
Event Source:    MSExchange Store Driver
Event Category:  (1)
Event ID:        1020
Date:            5/11/2010
Time:            10:00:43 AM
User:            N/A
The store driver couldn't deliver the public folder replication message "Folder Content Backfill Response (" because the following error occurred: Property validation failed. Property = [{00062004-0000-0000-c000-000000000046}:0x8082] Email1AddrType Error = The length of the property is too long. The maximum length is 9 and the length of the value provided is 13... For more information, see Help and Support Center at

What you will have to do is, using Outlook, obtain a list of all the affected contacts as described above, and also using Outlook, change the address type to SMTP.

In Outlook 2010, you can directly edit this field. In Outlook 2007, you will need to open each contact, right click on the e-mail address in the default display, and select Properties. Then, for the Address Type field, click the "Internet" button (this changes the e-mail address type to "SMTP" - the button will now display "Custom"). Then "Save and Close" the updated contact.

In my migrations, I've only had a maximum of about 150 of these. If you have thousands, you will probably need to consider writing a webdav application/script to run against the Exchange 2003 server(s).

Until next time...

If there are things you would like to see written about, please let me know.