When Outlook starts up and logs on to an Exchange server, it looks for a registry key (shown later in Table 13-2) that tells it which version of a special public folder to look for. This folder can be named either Outlook Security Settings (which applies to Outlook 98 and Outlook 2000) or Outlook 10 Security Settings (which applies to Outlook 2002 and Outlook 2003). Based on what Outlook finds in the folder, it might use security settings that vary from the default. The contents of those public folders determine which settings Outlook uses; you post messages to the public folder using a special form.

You are reading tip #2 from "8 tips in 8 minutes: A Microsoft Outlook email security tutorial," excerpted from Chapter 13 of Secure Messaging with Microsoft Exchange 2003 by Paul Robichaux, copyright 2004, published by Microsoft Press.

If you want your users to have customized security settings, there's a registry key that must be set on each individual client, which you'll normally set as part of the deployment. When the key is present, Outlook looks on the server for custom security settings that apply to that user; if any exist, they are used. If the key is not present, the built-in security settings are applied to the computer. Microsoft chose to store these settings in a public folder because that provides a degree of security; as long as you set the folder permissions correctly, no one can sneak in new settings or change existing ones.

Installing the Microsoft Outlook security package

The administrative tools for the Outlook Security Update consist of several files (including documentation) that are normally packaged as a single executable, Admpack.exe, which can be installed from the Office Resource Kit CD or the Office product CD. You can also download it from the Office Resource Kit Toolbox site. You should probably download it to ensure that you're getting the most current version.

The two administrative files that you will work with are the following:

OutlookSecurity.oft, the published Outlook form that you use to post messages in the public folder; in and of itself, this template doesn't provide any security.

Hashctl.dll, the file for the Trusted Code control, a tool used by the template to specify which COM add-ins you trust to run within Outlook (remember, this only applies to Outlook 2002 and later versions).

To install the Outlook security package, run Admpack.exe. When you run Admpack, it installs the necessary files to a location you specify. However, you still have to use those files to implement the necessary security settings.

Installing the Trusted Code control for Microsoft Outlook

Outlook allows you to write add-ins that are loaded into Outlook's process space; these add-ins use COM to communicate back and forth with Outlook. Because these add-ins run in-process, it's not a good idea to run add-ins from untrusted sources. When you install the security package, you gain the ability to create a list of trusted add-ins that clients can run without being prompted by Outlook security, provided you install the Trusted Code control. You only need this on your administrative machines; end users don't need it (and, in fact, shouldn't have it). Because the Hashctl.dll file is already installed on your machine, the only thing you really need to do is to register it, although Microsoft recommends moving the Hashctl.dll file to the \System32 folder in your Windows directory. To register the dynamic-link library (DLL), use this command: regsvr32 hashctl.dll

Creating a public folder for Microsoft Outlook security settings

Before you can create any settings, much less apply them, you'll need to create a top-level public folder to host the settings. The name of the folder is critical because Outlook is hardwired to look in that folder. You have three choices: if you create a folder named Outlook 10 Security Settings, Outlook 2003 (and Outlook 2002) uses the settings there, but Outlook 2000 won't see them. If you name the folder Outlook Security Settings, Outlook 2000, Outlook 2002, and Outlook 2003 use the same settings. If you create both folders, each version uses its own folder (assuming that you've properly set the client-side registry key discussed later). Once you've created the folder (or folders), give all users Read access. Users who are allowed to change security settings should have permission to create, edit, and delete items in the folder. Once you've created the folder, you're ready to publish the template and create an instance of the form. Do the following:

1. Start Outlook.

2. Open the OutlookSecurity.oft file. Outlook will prompt you for a location to save the new item you're creating from the template. The new item is never actually saved, so it doesn't matter which folder you choose.

3. While the template is open, use the Tools | Forms | Publish Form command. Give the form a meaningful name; if you're replacing the Outlook 2000–specific version of the form, give this form the same name as the old one. Make sure you specify the security settings public folder you created as the target location for the published form! Click Publish to publish the form.

4. Close the Default Security Settings template window. When Outlook asks if you want to save changes, make sure you do not do so.

5. Switch to the General tab of the public folder Properties dialog box, then use the When Posting To The Folder, Use drop-down list to specify the published form as the default.

6. After Outlook installs the template, open the public folder, then create a new item—name it Default Security Settings. You'll customize the default security settings by editing this item, and create new settings for different groups by creating copies of that default item or by creating new, blank entries and customizing them.

Filling out the Microsoft Outlook form template tabs

The Outlook security form template has three tabs, each of which has its own set of controls that govern how Outlook's security features work, as follows:

• The Outlook Security Settings tab controls general settings that are applied to Outlook clients.

• The Programmatic Settings tab controls what happens when outside applications try to use certain Outlook methods and properties, including sending mail, and retrieving address information.

• The Trusted Code tab lets you specify which Outlook COM add-ins you want to allow users to run without security prompts; note that these settings don't apply to other Office applications.

Note: You cannot create or update the security settings template when you're using an Outlook profies that's set to use cached Exchange mode; Outlook will complain and tell you to switch to online mode when you attempt to save your updated form.

The Microsoft Outlook Security Settings tab

The Outlook Security Settings tab allows you to configure default settings that apply to all users. You can also apply settings to individual users or groups of users. The normal way to accomplish this is to create multiple post items using the form: one for the default settings you want to apply and one for each individual or group that needs special settings. When you use Microsoft Exchange 2000 Server or Exchange Server 2003, Outlook lets you specify Windows 2000 Server distribution groups to indicate who you want settings to apply to. If you're still hosting the folder on Microsoft Exchange 5.5, you must enter the name of each individual mailbox in the group, separated by semicolons, up to the hard-coded limit of 1000 names. The tab itself is shown in Figure 13-2. The controls at the very top control who this copy of the form applies to. By default, the Default Security Settings For All Users option is selected, meaning that these settings apply to all Outlook users on this Exchange server. If you want to apply these settings to a subset of your users, select the Security Settings For Exception Group option, then fill in the Security Group Name and Members fields. Here's what the rest of the form's controls do:

Figure 13-2 The Outlook Security Settings tab gives you control over how Outlook handles attachments.

The Level 1 File Extensions and Level 2 File Extensions control groups let you specify which file types are included in each group. You can add or remove attachment types by putting the extensions in the appropriate fields and saving the items; unfortunately, there's no way to see the current list of Level 1 or Level 2 extensions.

The Miscellaneous Attachment Settings controls give you control over Outlook behavior when it encounters a Level 1 item.

The Show Level 1 Attachments check box tells Outlook whether or not you want the names of Level 1 attachments to be visible in the InfoBar, even though users might not be able to get them.

The Do Not Prompt About Level 1 Attachments When Sending An Item and Do Not Prompt About Level 1 Attachments When Closing An Item check boxes govern whether Outlook warns you when you include a forbidden attachment in a message you're composing.

The Allow In-Place Activation Of Embedded OLE Objects check box controls whether Outlook allows in-place activation or not. In-place activation actually turns on an embedded application, making its menus and toolbars visible and active within the multiple-document interface (MDI) frame of an existing application. Because this actually cedes control of the current application to the automation server for the embedded object, it poses a small security risk, so Microsoft turns it off by default. This option lets you turn it on.

The Show OLE Package Objects check box controls whether Outlook shows OLE binder objects; again, this represents a small security risk.

The Miscellaneous Custom Form Settings control group includes some oddball options that don't really fit anywhere else. The Enable Scripts In One-Off Outlook Forms check box controls whether individual unpublished Outlook forms (that is, those distributed as .oft files or by using the Send Form Definition With Item check box when the item is sent) can run scripts or not; the remaining options regulate what happens when external code, macros, forms, or COM add-ins attempt to use the Outlook object model to execute forms' custom actions or access the properties of a form control that specifies what Outlook item it's bound to. You have three options:

• The Prompt User option causes Outlook to display a dialog box prompting the user to choose whether to allow access or not.

• The Automatically Approve option tells Outlook to allow all access without displaying a warning.

• The Automatically Deny option tells Outlook to deny all requests without asking.

The Microsoft Outlook Programmatic Settings tab

The Programmatic Settings tab, shown in Figure 13-3, features an impressive set of options. Fortunately, these break down into a fairly simple taxonomy; you use this form to specify which actions various types of code can take, according both to the requested action and the type of interface used to make the request. Applications, macros, add-ins, and other executables can use three different interfaces to request services from Outlook, as follows:

Figure 13-3 Control programs' access to the Outlook object model and address book with the Programmatic Settings tab.

Outlook object model. The Outlook object model allows you to manipulate data stored in Outlook folders using a set of built-in interfaces that work with any language that supports COM; most of the time, people leverage this object model with code written in Visual Basic (VB) or Microsoft Visual Basic for Applications (VBA) to do this.

Simple MAPI. MAPI comes in two varieties: Simple and Extended. Simple MAPI enables developers to add basic messaging functionality, such as sending and receiving messages, to their Windows-based applications. Extended MAPI allows applications more control; it's also the only way an external application can use Outlook's data without triggering the Outlook object model guards.

CDO. CDO provides messaging and collaboration functionality; CDO lets you do things like schedule appointments, look up contacts, and perform other neat tricks. CDO 1.21 is actually a client-side COM wrapper for the MAPI library; any language that can use COM can use CDO. CDO implements most—but not all—MAPI functionality (but more than Simple MAPI). Don't confuse this CDO with the CDO for Exchange Management (CDOEXM) or CDOSYS libraries shipped as part of Exchange and Windows—same name, but different functionality.

Each potential action (sending items using CDO, looking up address book items with Simple MAPI, and so on) is independently controlled. When any third-party software on the client attempts to do something, the behavior you specify takes effect: the client either approves the request automatically (which is what happens in Outlook 2000 without the security update), automatically denies it, or prompts the user (the default behavior in Outlook with the security update).

The Microsoft Outlook Trusted Code tab

The Trusted Code tab is visually uninteresting, so I don't show it here. It contains a list box and two buttons: Add and Remove. You use the buttons to add or remove COM add-ins to the list; Outlook clients trust (that is, allow to run) any COM Outlook add-in on the list. However, remember that specifying an add-in on this tab doesn't make it run, nor does it install it on the client. Specifying an add- in here just means that the add-in has permission to call the Outlook object model without triggering the object model guards; add-ins that call CDO are still subject to the guards. There are a few nuances to using this tab. First of all, you can only specify Outlook add-ins, not, for example, a Microsoft Word add-in that happens to call Outlook object model functions. Second, if you later replace a trusted add-in with a newer version, you'll need to remove the old version from the list and add the new one, even if they have the same file name.

Deploying Microsoft Outlook security settings

After you configure the settings you want by creating items on the Exchange server, you still have to force Outlook to use those settings. To enable this behavior, you'll need to deploy a new registry key to the client computers; that's why this is best done during your initial rollout of Office or Outlook.

The simplest way to do this is to use the Custom Installation Wizard to include the registry key in a transform when you deploy the Office System. If you've already deployed Office, you can use the Custom Maintenance Wizard to add the registry key information to the client. However, neither of these methods is enforced, so clients can manually change their local settings. If you want the new registry key to be enforced, you'll need to deploy it with a system or group policy.

If you're managing your Office installation with policies, adding this behavior is simple. Just add the correct policy template (.adm file) so that your policy object includes the necessary key, then set the policy to apply to the target users. If you use the System Policy Editor provided with the Office Resource Kit Toolbox, the correct templates are already loaded. If you use the Active Directory Group Policy Object snap-in, you'll need to add the templates manually. The policy file automatically passes your customized security settings to client computers each time users log on to the system.

So, what's the magic key you have to modify? The registry value is a DWORD named CheckAdminSettings and located under HKEY_CURRENT_USER\Software\Policies\Microsoft\Security\. The value you put here determines where Outlook searches for security settings. Table 13-2 shows which values do what.

Note: You can't save this registry key to a file and mail it out because .reg files are blocked by the security update, and they're also blocked by the default Outlook settings that apply when no security settings are present on the server. Besides, the best way to ensure that users don't change these settings is to force their application using Group Policy Objects (GPOs), so that's what Microsoft recommends (although you can certainly add a .reg files that runs as part of a user logon script as an alternative).

Table 13-2: CheckAdminSettings Values

Value	What Outlook 2003 Does
Key not present	Uses its default settings.
0	Uses its default settings.
1	Looks for settings in the Outlook Security Settings folder, applying them according to the defaults and specific users you've specified.
2	For Outlook 2002 and Outlook 2003 only: Looks for settings in the Outlook 10 Security Settings folder, ignoring any settings in the Outlook Security Settings folder. Use this value when you want Outlook 2002 or Outlook 2003 and Outlook 2000 to use different settings.
Anything else	Uses its default settings.

8 tips in 8 minutes: A Microsoft Outlook email security tutorial

 Home: Introduction
 Tip 1: An overview of Microsoft Outlook email security features
 Tip 2: Customizing the Microsoft Outlook Security Update
 Tip 3: Customizing Outlook email security settings for end users
 Tip 4: Setting up RPC over HTTP for Microsoft Outlook
 Tip 5: Using S/MIME in Microsoft Outlook
 Tip 6: Using Information Rights Management in Microsoft Outlook
 Tip 7: Reaching into Microsoft Outlook's email security toolbox
 Tip 8: Related resources on Microsoft Outlook email security

This chapter is an excerpt from Secure Messaging with Microsoft Exchange 2003 by Paul Robichaux, copyright 2004, published by Microsoft Press. Click here for the chapter download or purchase the book here.

Dig Deeper

• People who read this also read...

  • An overview of Microsoft Outlook email security features
  • Configuring Outlook 2010 send/receive groups
  • Customizing Microsoft Outlook email security settings for end users
  • Related resources on Microsoft Outlook email security
  • Using S/MIME in Microsoft Outlook

• Related tags

  • email
  • outlook
  • security
  • update

• Related glossary terms

  Terms for Whatis.com - the technology online dictionary

  • Microsoft Outlook
  • bacn
  • Stuff I've Seen
  • MAPI (Messaging Application Program Interface)
  • offline folder file
  • whitelist
  • seat
  • bounce email (bounce mail)
  • email bankruptcy
  • OST file (.ost)

Show me more

This was first published in May 2007