Avoiding Performance Problems When Deploying a Safe Senders List

I'm trying to use the policy template for Microsoft Office Outlook 2003 to specify a Safe Senders list for the Junk E-mail Filter for my users. I've set up the Group Policy Object (GPO) and added the policy setting. I also created a text file that contains only one line (@hotmail.com), saved the file as safe.txt in the \domaincontrolleretlogon folder, and used that file path in the Specify path to Safe Senders list policy. But no matter what we try, the users' Safe Senders lists don't change. How can we fix this so that we can deploy a Safe Senders list?

When I tried using a GPO to deploy a Safe Senders list, I had the same result—the users' Safe Senders list didn't change. So I tried deploying the list through the Custom Maintenance Wizard instead, following the procedure described in the Office Resource Kit article "Helping Users Avoid Junk E-Mail Messages in Outlook 2003" (http://office.microsoft.com/en-us/assistance/HA011402621033.aspx). That approach worked fine and added the desired domains and addresses to users' Safe Senders list.

To determine why the Custom Maintenance Wizard approach worked and the GPO didn't, I used the CMW File Viewer to examine the .cmw file that the Custom Maintenance Wizard creates. The CMW File Viewer (cmwview.exe) is part of the Office Resource Kit toolset. (You can download the Office 2003 Editions Resource Kit at http://www.microsoft.com/office/orkarchive/2003ddl.htm.) The CMW File Viewer displays a text file in Notepad that shows all the changes in a given .cmw file. From that file, I learned that the Custom Maintenance Wizard sets a junk list–related registry value that isn't present in Group Policy Editor (GPE).

The missing registry value is a REG_DWORD value named JunkMailImportLists. Setting it to 1 causes Outlook to import junk lists the next time it starts. You can modify the Outlk11.adm administrative template on your domain controller (DC) to add a policy setting so that you can manage the JunkMailImportLists registry entry either as a user preference (in HKEY_CURRENT_USERSoftware MicrosoftOffice11.0OutlookOptionsMail) or a policy setting (in HKEY_CURRENT_USERSoftwarePoliciesMicrosoftOffice11.0OutlookOptionsMail). However, when I discussed this approach with Outlook deployment experts at Microsoft, I learned that using a GPO to deploy the entry can cause performance problems.

The usual process is that Outlook checks the JunkMailImportLists value and, if it equals 1, imports the junk lists and resets the value to 0. But if you deploy JunkMailImportLists as a policy setting in HKEY_CURRENT_USERSoftwarePoliciesMicrosoftOffice11.0OutlookOptionsMail, Outlook can't reset the value to 0. As a result, Outlook periodically checks the value of JunkMailImportLists, sees that it's still 1, and performs the import again and again, causing excessive remote procedure call (RPC) traffic as Outlook repeatedly updates the user's junk mail filters, which are actually stored in the Exchange mailbox. The potential for performance problems isn't quite as bad if you deploy JunkMailImportLists as a user preference in HKEY_CURRENT_USERSoftware MicrosoftOffice11.0OutlookOptionsMail, but you'll still encounter a situation in which a policy refresh resets JunkMailImportLists to 1 and Outlook repeats the import.

Instead of using a GPO, Microsoft recommends handling junk list importation by using the Custom Installation Wizard or Custom Maintenance Wizard to deploy JunkMailImportLists as a user preference setting. But recognizing that some organizations want to use a GPO for this task, an Outlook 2003 hotfix is available that avoids the performance problems by changing the junk mail list import so that it takes place only once per Outlook session, when Outlook starts. The Microsoft article "The JunkMail-ImportLists registry value may cause poor performance in Outlook 2003" (http://support.microsoft.com/?kbid=893057) provides details.