Troubleshooting

Data Transformation

If the following events occur while Data Transform is running, restart Data Transform after restoring the data from the backup:

1. The file server has rebooted.

2. The file server is the active node of a cluster and there is a fail-over event.

3. If the data is on a NAS and the NAS device becomes unreachable during the Data Transform.

Before restoration, disable the offline policy and clear the Data Transform state. Type:

${dxf} –cleanup <_GuardPoint_>

Client Profiles

Client profiles are used to group common configuration values for multiple clients in both ProtectFile and CipherTrust Transparent Encryption/CTE UserSpace. However ProtectFile client profiles are quite different from CTE-U client profiles, and the pfmigrate utility does not migrate them.

If their associated client profile has the enable su property set, enable the CTE-U su_root_no_auth authenticator in the client settings on the CTE-U client.

Manually Migrating

Performing the migration manually may be unavoidable in some rare cases. In this approach, you need to decrypt all the data in the ProtectFile encrypted paths, and configure and apply CTE-U customized GuardPoint as appropriate.

Make sure that you perform all of the checks listed in the section Prerequisites for Migration. before performing the following steps:

1. Install CipherTrust Transparent Encryption/CTE UserSpace on the file server and perform client registration. For NAS, CIFS, or cluster installations, this must be performed on all of the nodes. Make sure that in the Client section on CM, you select: Communication Enabled and Registration Allowed.

2. In the manual approach, you can skip the step 'Migrating the configuration from classic KeySecure to CM'.

3. If the ProtectFile configuration is already migrated to CM, use the pfmigrate utility to migrate the CM configuration for ProtectFile to CTE-U. Then make changes as appropriate.

   Otherwise, create the CTE-U configuration elements manually. Refer to the section Production Policies for guidelines on mapping ProtectFile configuration elements to CTE-U configuration elements on CM.

4. Navigate to the ProtectFile client on the CM (or KeySecure) and decrypt the first encryption rule.

5. Wait for this operation to finish.

6. After Data Transformation completes, it should automatically remove the encryption rule from the CM (or KeySecure) and the corresponding mount on the file server.

7. Create and enable the CTE-U offline policy.

8. Run the ${dxf}command on the GuardPoint.

9. Create and enable the CTE-U production policy.

At this point, the migration for this encryption rule is complete. The data is converted to the CTE-U format and the access rules are enforced.

Linux File Server: After data migration, close existing login sessions/terminals and then verify the integrity of the data for each protected path.

Windows File Server: After data migration, reboot the file server. Once the file server is rebooted, verify the integrity of the data for each protected path.

• Verify the integrity of the data. Consult the CTE-U documentation for information on how to verify the data integrity.

• The path is now ready for production use. Unless you need to migrate other encryption rules immediately, you can make the full cluster nodes and all of the NAS clients active.

• Repeat the steps for all encryption rules for the ProtectFile client.

• Delete the ProtectFile client entry from the CM.

• Uninstall the ProtectFile software from the file server.

Sample Mapping File

When you convert a Linux client with NFS shares to CTE-U, you must create a mapping file which maps the names of all of the shares on the CM to their mount point on the file server. This file is provided as input for the pfmigrate utility. The mapping file uses the following options for the mapping:

• pf_share_name: Share name designated for share

• mount_point: Directory to which the share is mounted

Following is an example mapping file:

"mapping":  [
                {
                    "pf_share_name": "myshare1",
                    "mount_point": "/mnt/share1"
                }
                {
                    "pf_share_name": "myshare2",
                    "mount_point": "/mnt/share2"
                }
                {
                    "pf_share_name": "myshare3",
                    "mount_point": "/mnt/share3"
                }
            ]
}

Known Issues