3.1.1.1.1.1 Checkpoints

A resource provides an external data checkpoint mechanism for binding data stored outside of the cluster to a resource. An application can have data associated with it that is not stored as part of the nonvolatile cluster state but that needs to be present on the node hosting the application and its resource in order to ensure proper operation.

A resource checkpoint supports two sources of checkpoint data: server registry data and cryptographic keys. Registry checkpoints are rooted underneath the "HKEY_LOCAL_MACHINE" key in the server's registry, as described in [MS-RRP] section 3.1.1.7. Registry checkpoints recursively include all values, subkeys, and their values under the key to be checkpointed.

Cryptographic keys are stored in a server implementation-specific database.

The location of the registry data is specified as a null-terminated Unicode string containing a registry path that is relative to the well-known registry key "HKEY_LOCAL_MACHINE". A server can provide an alternate registry for backward compatibility with non-native applications. If the alternate registry exists, a server will allow the client to specify a path to a checkpoint in the alternate registry as long as the same path in the native registry has not already been checkpointed for a given resource; that is, the registry path namespace is common to both registries.

The location of the cryptographic keys is specified as a null-terminated Unicode string, and is present as the string representation form of the numeric cryptographic service provider (CSP) type, followed by a "\", the CSP name, followed by a "\", and the key container name. A server SHOULD support CSPs. For more information on CSPs, see [MSDN-CSP].