Overview

• CTE Encryption Methods

• Considerations with DFSR

• CTE Configuration Workflow

How you deploy CTE in a DFSR environment depends on the topology you have chosen for your DFSR configuration. Microsoft offers several topology options for DFSR:

• Hub and Spoke. In this configuration, there is a central server (the hub) whose contents is replicated on multiple satellite servers (the spokes). While each spoke server has a two-way communication channel with the hub server, none of the spoke servers can communicate with each other. If the data changes on one spoke server, that server communicates the changes back to the hub server and the hub server initiates the data replication on all other spoke servers.

  This configuration allows you to encrypt servers one at a time, starting with the hub and then moving outwards to the spokes.

• Full Mesh. In this configuration, any server in the mesh has a two-way communication channel with every other server in the mesh, and data replication can be initiated by any server on all the other servers.

  In this configuration, you must stop the replication service while you encrypt the data on all servers in the mesh. You cannot restart the replication service until the initial encryption has completed on all servers.

CTE Encryption Methods

CTE supports two encryption methods:

• Standard offline data transformation, where the data is unavailable while it is being encrypted or rekeyed.

• Live data transformation, where the data is encrypted and rekeyed in the background while it remains accessible to users. This method requires a separate license for the CTE-LDT feature.

While DFSR policies have some unique required components, the basic policy and GuardPoint creation process is identical to non-DFSR environments. For details about offline data transformation, see the CTE Data Transformation Guide. For details about CTE-LDT, see the CTE-Live Data Transformation with Data Security Manager or CTE-Live Data Transformation with CipherTrust Manager.

Considerations with DFSR

If you are using CTE in a DFSR environment, keep in mind the following:

• You should always back up your data prior to beginning the encryption process and you should have a full backup of the data in the hub server before you restore a spoke.

• You cannot place a GuardPoint anywhere on the boot drive, so if your DFSR replication point is currently C:\, or a directory under C:\ such as C:\data\, you need to move that data and its replication point to a new volume on the server before you can encrypt it.

• If you are backing up your DFS data, make sure that your backup software is not backing up the archive bit. File replication gets triggered by file version change or a modified time stamp. As such, there is a chance that updating the archive bit may cause issues that trigger a replication storm, which will then put a heavy encryption load on the servers.

• You must add the CTE GuardPoint at or above the level of the DFSR replication point. For example:

  • If the replication point is D:\, the CTE GuardPoint must also be at D:\. Adding a GuardPoint on a directory in D:\, such as D:\data\, will fail.

  • If the replication point is D:\data\, you can add a GuardPoint at D:\data\ or D:\, but you cannot add a GuardPoint on a subdirectory of D:\data\ such as D:\data\HR-files\.

• When you set a replication point, Microsoft automatically creates a private directory called <dir name>\DfsrPrivate that goes with that replication point. For example, if the replication point is set on D:\, the private directory would be D:\DfsrPrivate. If the replication point is set on D:\data\, the private directory would be D:\data\DfsrPrivate.

  How this private directory must be handled depends on the the encryption method that you are using.

  • For Standard encryption, you must guard the private directory with the same policy that you use for the main GuardPoint. If the GuardPoint is at the root of the volume (for example, D:\), this happens automatically. But if you are guarding a specific directory, such as D:\data\, you need to create a second GuardPoint using the same policy on D:\data\DfsrPrivate. For details, see Creating Standard GuardPoints with the DFSR Hub and Spoke Topology or Creating Standard GuardPoints with the DFSR Full Mesh Topology.

  • For live data transformation, you must guard the private directory with the same policy that you use for the main GuardPoint, even if the GuardPoint is at the root level. (For example, you must have a GuardPoint for both D:\ and D:\DfsrPrivate\.) In addition, you must exclude this directory from CTE-LDT processing. For details, see Creating a CTE-LDT GuardPoint for DFSR.

• The policy you specify for a DFSR GuardPoint cannot contain a resource set in any of the key rules included in the policy. All files in the guarded directory and its subdirectories must be encrypted with the same encryption key without exception. Additionally, if you rekey the GuardPoint, all files must be rekeyed with the same encryption key.

• If you want to change from one encryption key to an entirely different encryption key (as opposed to rekeying the data with a new version of the existing key), you must decrypt the data and remove all existing GuardPoints so that you have a clean environment. Then you can start the CTE encryption process over from the beginning.

  You cannot change from one encryption key to another if any of the existing data is still encrypted with the old key. If you attempt to do so, you may encounter data replication errors and you may need to delete the entire volume and recreate it.

• When CTE encrypts data on a node, the encrypted data must be replicated to other nodes in the configuration. This may result in increased replication activity on the network.

CTE Configuration Workflow

In order to configure CTE with DFSR, you must complete the following tasks: