Planning Considerations for Encryption of Office Documents

Updated: September 17, 2012

Applies To: Windows Server 2012

Active Directory Rights Management Services (AD RMS) is an information protection technology that can be used with dynamic access control to protect files as they are flexibly exchanged within an organization or across organizational boundaries. AD RMS works with Microsoft Office to help safeguard documents by enabling information rights management (IRM) features when you create documents using enabled applications such as Microsoft Word and Microsoft Outlook.

By using AD RMS to support the IRM feature capabilities within Microsoft Office, you can create documents or email messages and protect them from unauthorized use as they are flexibly shared in digital form. When assigning rights, content owners can define exactly how a recipient can use the information; including such rights as the ability to open, modify, print, or forward the information.


AD RMS can be implemented to provide a comprehensive information-protection platform in complex business environments. Additionally, it can be effectively implemented to protect information shared among multiple organizations. For more on planning deployment scenarios around AD RMS, see AD RMS Architecture Design and Secure Collaboration Scenarios(

This topic provides guidance around the following additional considerations that should be looked at when you are using AD RMS to protect and encrypt Office documents that you will provide limited access to by sharing them using dynamic access control. (For more about how dynamic access control works, see Dynamic Access Control: Scenario Overview.)

  • Determining files to automatically encrypt

  • Determining the rights policy template to use when encrypting files

  • Multi-machine considerations

Determining files to automatically encrypt

In determining which files or folders to automatically encrypt using AD RMS technology, there are two aspects to consider. First, you should determine what types of files need to be encrypted. For example, do you have files containing confidential information or personal information?

Next, you should determine which resource properties are useful ways to describe those types of files. To get started, try to use the predefined resource properties whenever possible. Typically, this will mean selecting the most appropriate resource property from the list of resource properties that are either built-in or user-defined using Active Directory Administrative Center. For example, the following table provides suggestions for some of the exact built-in resource properties you might choose to use when identifying files to be marked for encryption and rights protection.

Resource Property Description


The Personal Identifying Information (PII) resource property can be used to identify files that have PII within them to ensure those files are protected at the appropriate assigned level of sensitivity. For example,


The Compliancy property for confidentiality purposes according HIPAA guidelines in an organization that provides health care services.


This resource property can be used to set a list of name values for which the name of a special project in your organization could be applied to all of its related files. This could identify project files for the purposes of them having encryption and protection applied to them, ensuring that only project team members have access to open and view these files.

In addition to the above resource properties, you might choose to have other custom resource properties defined in your deployment that apply the following criterion:

  • Based on file location. You might create a new resource property definition called "Location" and then set list of supported values for it to the names of specific sites or locations within your enterprise or organization. You could then assign the values to this resource property for each of the files by their location. This might be a good strategy to implement if you have a secure location that requires all documents within it to be encrypted and protected.

  • Based on file contents. Another way to create a resource property to help protect content based on identifying the type of content it is. For example, if you only need to protect files or documents that have sensitive financial or payroll information, you might choose to use "Financial" or "Payroll" as supported values for a "Content" resource property and use that property to identify and tag files that need to be encrypted and protected.

  • Based on manual classification. Another possible way to identify files for classification is to manually classify them. Manual classification gives users and content owners the ability to classify their files and folders by using the properties sheet of that file or folder. For example, you can classify folders so that any file added to the folder will inherit the classifications of the parent folder. For more information, see Working with File Classification.

Determining the rights policy template to use when encrypting files

Rights policy templates are used in AD RMS to control the rights that a user or group has on a particular piece of rights-protected content. When you are deciding upon which rights policy template to use when encrypting files in your organization, it's helpful to consider the purpose and scope of how you are planning to protect content.

For example, you might consider using a rights policy template for the purpose of protecting PII content that would be generated by the finance or payroll department within your organization. In this case you could name the template "Finance" and select the following configuration user and rights settings when creating the template in the AD RMS console.

  • Configure an Active Directory group to be assigned use of the template, one that contains only the regular staff employees who work within the finance or payroll department. Note that this group will also need to be configured for an email name for AD RMS to use in identifying it such as "" or "".

  • Select View and View Rights to limit the department employees in their ability to modify payroll or other financial details for documents.

Similar template configurations might also be done to protect content considered to be High Business Impact (HBI) information by having a "Company Confidential" template that enforces similar view-only rights and limited to all full-time employees only.

Another way of determining a rights policy template to use would be to apply scope as the determining factor. One way to do this would be to reserve the use of separate network mapped drives or volumes for each department so they can be used by workers within the department to store their documents. In this scenario, you might have templates that are specific to each department and ensuring that they are only available to be applied to files on that department's mapped drive or volume.

For example, the finance department might have their work files managed using a template for volume (drive) F and the engineering department might use volume G for storing their protected work files. File management has been configured so that workers in each department do not have access to the other department's volume. This will be useful if you if you need to create more than one file management task to manage protection for multiple departments and rights policy templates.


There should be only a 1:1 relationship between templates and file management tasks. In general, you should try to use only a single file management task and rights policy template throughout your organization to schedule and manage template usage. If you do use more than one template and file management task as suggested here, be sure to take the suggested precautions and manage separate scope well so that tasks and volumes where files are managed are not able to be assigned protection using more than a single template to avoid rights conflicts or collisions.

For more information on working with AD RMS rights policy templates, see the following additional resources:

Multi-machine considerations

In working to plan encryption for the files you use in your organization, there are a number of aspects to consider in preparing for multi-machine deployment. To begin with, there is no easy way to push file management tasks and classification rules out to multiple computers. Therefore, it is common practice for those working with dynamic access control to do new configuration by transferring settings from one computer to another manually, although there are some tools that can assist in this process.

Dynamic scope using the FolderUsage property

For each file management task and classification rule, you can use a management property in a way that allows for dynamic scoping in contrast to a statically specified scope. In static scoping, a file management task, a classification rule or a report is defined using specific folder shares, paths or volumes that are specific to the computer where the rule was made. Since each computer has a different share / folder / volume structure, a statically scoped rule is likely not work if copied to other computers.

Dynamic scoping allows a task, rule or report to be defined in such a way that it can be correct calculated on any computer where the task, rule or report is placed. A dynamically scoped rule might use a management property to help calculate and apply the rule to folders by looking at how they are marked for usage. For example, you might have two servers, Server1 and Server2. On Server1, D:\share might contain files with user data and on Server2, E:\share is the share used for the same purpose. To apply dynamic scope, you could then specify a file management task that applies to all folders marked as containing FolderUsage="User Data". By doing so, the rule would work correctly on both servers with no modification.


For dynamic scope, always use the FolderUsage property definition, one of three special management property definitions that are built in to the File Services infrastructure.

Setting management property values

While "User Data" (as was described in the previous section) is one possible value for the FolderUsage management property that could be applied, others include "Collaboration Data" or "Application Data" and these classifications can be modified, extended or deleted as needed. If you do want to modify a management property such as FolderUsage, the following are all possible ways to do so:

  1. You can set the management property in the New Share Wizard.

  2. In the File Services Resource Manager (FSRM) console, in the treeview on the left, select Classification Properties, and then select Set Management Properties in the task pane on the right.

  3. Using Windows PowerShell, you can use the Get-FSRMMgmtProperty and Set-FSRMMgmtProperty cmdlets to view status on management properties or configure them.

Moving configurations between computers

Once you have set or updated management properties on a single computer you will want to be able to move your configuration changes to others computers. The following are three possible options for doing so:

  • Write a script that configures File Classification Infrastructure (FCI).

    To alter the FCI configuration on multiple computers, you can write a COM-based script that uses the FCI API to create new file classifications and to store new properties. You can then create applications or scripts that can be initiated by file management tasks in File Services Resource Manager (FSRM) or you can also use Group Policy to launch completed scripts. For more information on the FCI API, see IFsrmPipelineModuleImplementation Interface

  • Use Windows PowerShell remoting to use the File Services Resource Manager (FSRM) cmdlets to configure computers.

    Windows PowerShell provides another scripting platform you can leverage to perform configuration updates. For more information on using Windows PowerShell to create FCI scripts, see Using Windows PowerShell Script for File Classification.

  • Use the Data Classification Toolkit to export and then import configurations.

    The Data Classification Toolkit provides another option for exporting and importing FCI configurations. It was designed to help enable an organization to identify, classify, and protect data on its file servers and it provides out-of-the-box classification and rule examples that can help organizations build and deploy their policies to protect critical information in a cost-effective manner. For more information, see Data Classification Toolkit.