Script: Set-Exchange2010FilterConfig.ps1 v2.0 – Cleaner Configuration of the FilterPack for Exchange Server 2010
Description
Late last year, I wrote Cleaner configuration of the FilterPack for Exchange Server 2010 to provide a cleaner script that handles registration of file types for the Office 2007 Filter Pack. This was because the default script would generate a bunch of exception errors when it encountered existing registration entries in the registry. This could be fairly confusing to some people. So my script just did some rudimentary checking before attempting to set the registration. Same end result, just a little cleaner.
Anyways, fast forward to last week, when Microsoft released v2.0 of the Filter Pack. The new version includes support for Office 2010 file types, as well as all of the legacy versions. The registration script didn’t need to change, since it’s based on file extensions, and there aren’t new file extensions in 2010 (like there was in 2007).
But, some people are also installing the Adobe PDF iFilter 9.0 package to enable Exchange to index PDF file attachments as well. Like the Office Filter Pack, the PDF Filter Pack requires a PowerShell script to run to register the file types. Combine that and the update to the script mentioned at Automated prerequisite installation via PowerShell for Exchange Server 2010 on Windows Server 2008 R2 – v2.0, and combining the two filter pack registration scripts just made sense.
This version allows you to register either the Office or the PDF Filter Pack, or both. If you register the PDF Filter Pack, a server reboot is required, as is running the script .\ResetSearchIndex.ps1, which is located in the \scripts folder (typically c:\Program Files\Microsoft\Exchange Server\V14\Scripts). Resetting the search index can be somewhat taxing if there is already a large amount of mail in databases on that server, so you may want to plan when to run this.
Check out the original post for more info, and get the updated script at Set-Exchange2010FilterConfig20.zip
Installation
Execution Policy: Third-party PowerShell scripts may require that the PowerShell Execution Policy be set to either AllSigned, RemoteSigned, or Unrestricted. The default is Restricted, which prevents scripts – even code signed scripts – from running. For more information about setting your Execution Policy, see Using the Set-ExecutionPolicy Cmdlet.
Donations
I’ve never been one to really solicit donations for my work. My offerings are created because *I* need to solve a problem, and once I do, it makes sense to offer the results of my work to the public. I mean, let’s face it: I can’t be the only one with that particular issue, right? Quite often, to my surprise, I’m asked why I don’t have a “donate” button so people can donate a few bucks. I’ve never really put much thought into it. But those inquiries are coming more often now, so I’m yielding to them. If you’d like to donate, you can send a few bucks via PayPal at https://www.paypal.me/PatRichard. Money collected from that will go to the costs of my website (hosting and domain names), as well as to my home lab.
We are just getting around to adding the Adobe filter to our servers which are already populated with mailboxes and databases, and we were very excited to find your script as it looks to be a quick way to get this done consistently.
When installing the Adobe filter I see where the ResetSearchIndex.ps1 script is called with a -Force and -All.
Question – In a mutli-site and multi-node DAG, where no one server has all of the databases, what is the effect of running the imbeded Microsoft script with those commands in your script? I.E. Will it reset just the active databases on the local DAG node, or will it try to grab all the ones in the Org (Which is how I interprit the code inside of ResetSearchIndex.ps1 when the -all is passed to it)?
Also do you know if the Adobe filter needs to be on all of the DAG nodes or just the ones with active databases to being the process of resetting the search index?
Resetting the search index on all of the databases at the same time could prove to be problematic if we have only applied the filter and run the script on the first node, not to mention if our assumption of the logic of the commands being passed through to the imbedded script will cause the databases to be reset each time a node in the DAG is update.
Also I believe DAG node databases require suspension and re-seeding of the rebuilt search index which would require additional steps as well.
I’m hoping that you can clarify how we should proceed in our active/passive multi-node (in each datacenter) DAG in regards to getting the Adobe filter installed.
Just to clarify, I looked at your script again and it looks like you writing to the screen a reminder to run the ResetSearchIndex.ps1 with -Force and -All, but not actually running the command.
Either way we would appreciate your thoughts on how we reset the search database on multiple databases in a multi-site and multi-node DAG. I think we are going to have to do it one at a time (including suspending replication and forcing an update of the CatalogOnly) after all the reboots are done.