Policies are special registry entries designed to help control the configuration of either the operating system or any applications designed to respect policy settings. Applications respecting policies are expected to have an associated ADM template that administrators use to set policy entries. The ADM template must be loadable by the Group Policy snap-in that is included with Microsoft® Windows® 2000 and Microsoft Windows XP.

The ADM templates for use with Microsoft Office 2003 applications are included with the Office Resource Kit tools. In a typical installation of the tools on the Microsoft Windows XP or Microsoft Windows 2000 platform, the templates can be found in the INF folder of the WINDIR path — for example, C:\Windows\INF. Typically, the policies for the installed operating system are found in the system.adm policy template.

As part of the design of policies, a special node exists on both the HKLM and HKCU branches of the registry. Microsoft operating systems such as Windows 2000 and Windows XP respect policy settings specifically designed for use with these systems. Policies can be used to configure the user interface to appear with specific configuration changes specially suited for a business need — such as disabling access to software, utilities, or special features of the operating system that may be deemed unnecessary or detrimental to productivity. Or, policies can be used to enable a feature that is not normally turned on when the product is installed in a default configuration.

Structure of a policy registry entry

The two most important registry branches in the registry are HKLM and HKCU. HKLM stands for HKEY_Local_Machine and HKCU stands for HKEY_Current_User. Policy settings set in the Local Machine branch are expected to apply to all users and are generally considered the most enforceable and best protected from user changes. Policy settings set in the Current User branch are specific to only the logged-on user.

Both the HKLM and HKCU registry branches are designed to have a Policies node. This is not an absolute for all custom applications, but it is the preferred design approach and is recommended for all developers. Applications are expected to follow the order of precedence indicated in the example provided below, as do all Microsoft applications designed specifically for Windows 2000 and Windows XP.

• HKLM\Software\Policies\Microsoft\
• HKLM\Software\Microsoft\
• HKCU\Software\Policies\Microsoft\
• HKCU\Software\Microsoft\

Registry entries found in the Policies node are mirror entries to those found in the non-policy entries. For example:

HKLM\Software\Policies\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

HKLM\Software\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

HKCU\Software\Policies\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

HKCU\Software\Microsoft\Office\11.0\Common\Toolbars

AutoExpandMenus DWORD 1

Any of the above registry entries would be respected by any Office 2003 application. However, the difference is, the Policies registry entry cannot be set by the user, only by the administrator who has created a POL file by using the Office11.adm policy template. However, if the user knows where this entry is in the registry, the user could manually change the entry.

Unless the permissions for the registry are set so that only the administrator can make changes, it is possible for users to defeat policy settings. Therefore, it is common practice for administrators to apply permissions to the registry in order to block changes to the Policies node by users. For Terminal Services–enabled systems, applying registry permissions is performed automatically by the operating system when Terminal Services is enabled.

It is common for the operating system and applications to respect both the HKLM and HKCU nodes of the registry if a Policies node is found in the registry.

If you develop a custom application that you want to add policy support to, there are general guidelines available within the MSDN Web site, though there may not be support for the development of ADM templates. Examining existing ADM templates will generally provide enough information and examples for you to develop ADM templates if needed.

First-time installation policy concerns

As part of a first-time installation of Office, administrators are usually concerned about security-related policies such as:

• Trust all installed add-ins and templates
• Security Level (macro security)
• Trust access to Visual Basic Project
• Disable VBA for Office applications
• Unsafe ActiveX initialization
• Automation Security
• Prevent users from changing Office encryption settings
• Specify Trusted Alert Sources
• Prevent users from uploading settings to the Internet
• Feedback URL
• Prevent access to Web-based file storage
• Disable Information Rights Management User Interface
• Disable hyperlinks to Web templates in File | New and task panes
• Prevent users from customizing attachment security settings
• Allow access to e-mail attachments
• Outlook virus security settings
• Configure Add-in Trust level
• Task Manager security key
• Prohibit access to Control Panel
• Prevent access to the Command Prompt (DOS window)

Each of these policies is available within the various Office 2003 ADM policy templates. Their related non-policy registry entries are usually also settable through the Custom Installation Wizard and the Custom Maintenance Wizard within the Change Office User Settings and the Specify Office Security Settings pages. By setting non-policy registry entries in three places — in the Specify Office Security Settings page, through the Change Office User Settings page, and then in the Group Policy snap-in — the desired settings are enforced in all possible places. And if permissions to the registry nodes are set to only accept changes from administrators, the settings are enforced to the greatest extent possible. However, if a user gains access to the most secure and highest order of precedence settings (usually the HKLM node), the user can defeat the setting.

Administrators should guard their user accounts and review the Administrator's network group account to be sure no one has forged access to permission-restricted levels of their systems.

Important policies

Below are noted the registry settings for important policies that were requested by administrators. The ActiveX® control initialization registry entry is somewhat complex in that it has six possible settings (even though only three are revealed through the Custom Installation Wizard and Custom Maintenance Wizard). Administrators who need to set ActiveX initialization to a more refined setting can review the ActiveX initialization documentation below.

Macro Security Level

If you use the Specify Office Security Settings page of either the Custom Maintenance Wizard or the Custom Installation Wizard, and you change the Default Security Level for an application, this process is the same as using the Security dialog box available through the application's user interface. Use of this registry entry sets the macro security level for each application specified in the <APP> portion of the key to the respective value data listed below.

<APP> = Word, Excel, Access, PowerPoint, Publisher, Outlook

HKCU\Software\Microsoft\Office\11.0\<APP>\Security

The parallel policy key is:

HKLM\Software\Policies\Microsoft\Office\11.0\<APP>\Security

Value name: Level

Value type: REG_DWORD

Value data: [ 1 | 2 | 3 | 4 ]

1   Low

2   Medium

3   High

4   Very High

Use of the policy is recommended in situations where you never want users to have the ability to change the macro security level. See the security topic Macro Security Levels in Office 2003 for a complete description of this option.

ActiveX initialization

Through the use of the common security key, you can instruct Office to set ActiveX initialization security for all Office applications. This registry entry can be set by using the Specify Office Security Settings page of either the Custom Installation Wizard or the Custom Maintenance Wizard.

HKCU\Software\Microsoft\Office\Common\Security

The parallel policy key is:

HKLM\Software\Policies\Microsoft\Office\Common\Security

HKCU\Software\Policies\Microsoft\Office\Common\Security

The value name UFIControls can be set for either of these nodes to the following values and respective actions:

Value name: UFIControls

Value type: REG_DWORD

Value Data: [ 1 | 2 | 3 | 4 | 5 | 6 ]

Safe For Initialization (SFI) is a term used by ActiveX developers to mark a control as being safe to open and run and not capable of causing ill effects to any systems, regardless of whether it has persisted data values or not. If a control is not marked SFI, it is possible for the control to adversely affect a system — or it is merely possible the developers did not test the control in all situations and are not sure whether their control may be compromised at some future date.

The value data can be explained as follows:

1   Regardless of how the control is marked, load it and use the persisted values (if any). This setting does not prompt the user.

2   If SFI, load the control in safe mode and use persisted values (if any). If not SFI, load in un-safe mode with persisted values (if any), or use the default (first-time initialization) settings. This setting does not prompt the user.

3   If SFI, load the control in un-safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with default (first-time initialization) settings.

4   If SFI, load the control in safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with default (first-time initialization) settings.

5   If SFI, load the control in un-safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with persisted values.

6   If SFI, load the control in safe mode and use persisted values (if any). If not SFI, prompt that it is marked unsafe. If the user chooses No at the prompt, do not load the control. Otherwise, load it with persisted values.

If you are a programmer interested in knowing more about ActiveX controls marked as SFI, see the documentation on ActiveX control development for information about safe mode for ActiveX controls. Look for the following object and method: IObjectSafetyImpl::SetInterfaceSafetyOptions. The IObjectSafety interface allows a client to retrieve and set an object's safety levels. For example, a Web browser may call IObjectSafety::SetInterfaceSafetyOptions to set a control to safe for initialization or safe for scripting.

---

 Note    Not all ActiveX controls respect the safe mode registry setting and therefore may load persisted data even though you instructed the control to use safe mode from this registry setting.

---

When setting the Unsafe ActiveX Initialization option in the Custom Installation Wizard or Custom Maintenance Wizard, the following conditions apply:

• Prompt user to use control defaults

  Sets the UFIControls registry entry to a data value of 4. If the control is marked Safe For Initialization (SFI), the control is loaded in safe mode and uses any persisted values. If the control is not marked SFI, the user is prompted that the control is marked unsafe. If the user chooses No at the prompt, the control is not loaded at all. If the user chooses Yes, the control is loaded with default (first-time initialization) settings.

• Prompt user to use persisted data

  Sets the UFIControls registry entry to a data value of 6. If the control is marked Safe For Initialization (SFI), the control is loaded in safe mode and uses any persisted values. If the control is not marked SFI, the user is prompted that the control is marked unsafe. If the user chooses No at the prompt, the control is not loaded at all. If the user chooses Yes, the control is loaded with persisted values.

• Do not prompt

  Sets the UFIControls registry entry to a data value of 1. This setting loads the control, uses any persisted data, and runs it regardless of whether or not the control is marked as SFI.

• <do not configure>

  Leaves the default configuration for this option set to 3 – Prompt user to use control defaults.

It is possible for an administrator to set the ActiveX initialization settings to one of the six possible values by using the Add/Remove Registry Entries page of either the Custom Installation Wizard or the Custom Maintenance Wizard.

UserForms and ActiveX initialization

You can instruct Office to set UserForm ActiveX initialization security for all Office applications that support UserForm. If the setting of the key is 2 or 3, the user will be prompted to determine how UserForm forms will load. The prompt only appears once per session within an application. The location of the registry key is the following:

HKCU\Software\Microsoft\VBA\Security

The parallel policy key is:

HKCU\Software\Policies\Microsoft\VBA\Security

In either the registry or policy node, the value name LoadControlsInForms can be set to the following values and respective actions:

Value name: LoadControlsInForms

Value type: REG_DWORD

Value Data: [ 1 | 2 | 3 | 4 ]

Safe For Initialization (SFI) is a term used by ActiveX developers to mark a control as being safe to open and run — that is, it is not capable of causing ill effects to any systems, regardless of whether it has persisted data values. If a control is not marked SFI, it is possible for the control to adversely affect a system; it's also possible the developers did not test the control in all situations and are not sure whether their control may be compromised at some future date.

Unsafe For Initialization (UFI) is a term used to mark an ActiveX control as unsafe to open and run, and may be capable of causing ill effects to a user’s system.

The value data can be explained as follows:

1 For a UFI or SFI signed control that supports safe and unsafe mode, load the control in unsafe mode. For an SFI signed control that only supports a safe mode configuration, load the control in safe mode.

2   (default setting) For a UFI signed control, if the user responds with a Yes to the prompt, load the control in unsafe mode. If the user responds with a No, load using the default properties. For an SFI control that supports both a safe and unsafe mode, if the user responds to the prompt with a Yes, load the control in unsafe mode. If the user responds with a No, load the control using safe mode. If the SFI control can only support safe mode, load the control in safe mode

3   For a UFI signed control, if the user responds with a Yes to the prompt, load the control in unsafe mode. If the user responds with a No, load the control with its default properties. For an SFI control, load in safe mode.

4   For a UFI signed control, load with the default properties of the control. For an SFI control, load in safe mode (considered to be the safest mode).

These settings are supported in both run and design mode.

Microsoft Office Outlook® 2003 supports a similar key and does not recognize the LoadControlsInForms registry entry. The value name AllowActiveXOneOffForms manages this behavior; the key for this is found here:

HKCU\Software\Policies\Microsoft\Office\11.0\Outlook\Security

Value name: AllowActiveXOneOffForms

Value type: REG_DWORD

Value data: [ 0 | 1 | 2 ]

Outlook does not support this registry entry for published forms. Published forms are assumed to be trusted.

0 Load only the frm20.dll, the Outlook View Control (OVC), Outlook Recipient Control (ORC), and the docsite control.

1   Allow only controls marked as SFI to load.

2   Allow all ActiveX controls to load.