3.1.4.3.1.36 CLUSCTL_RESOURCE_NETNAME_RESET_VCO
The CLUSCTL_RESOURCE_NETNAME_RESET_VCO resource control code resets the password for the associated security principal of the alternate computer name. How the server constructs the new password is implementation-specific.
ClusAPI Protocol version 2.0 servers fail this method by using error code 0x00000001 (ERROR_INVALID_FUNCTION).
The server MUST fail this method by using error code 0x00000001 (ERROR_INVALID_FUNCTION) if the designated type of the resource does not support the functionality of an alternate computer name.
The server MUST fail this method with 0x000013B8 (ERROR_CLUSTER_INVALID_REQUEST) if the resource designated by the hResource parameter does not correspond to the primary cluster name, as defined in section 3.1.1.5.
The client MUST provide the alternate computer name whose security principal password is to be reset, as a null-terminated Unicode string, in the buffer that is designated by lpInBuffer.
The client MUST provide the name of the security principal, as a null-terminated Unicode string, in the buffer that is designated by lpInBuffer. The server MUST fail this method with ERROR_CLUSTER_INVALID_REQUEST (0x000013B8) if the resource designated by the hResource parameter does not correspond to the primary cluster name. The server SHOULD fail this method with ERROR_ACCESS_DENIED (0x00000005) if the buffer designated by lpInBuffer contains the alternate computer name associated with the primary cluster name. For example, the client can designate the primary cluster name with the hResource parameter and the NetBIOS name of a non-primary cluster name with the lpInBuffer parameter.
After successful completion of the method, the server SHOULD NOT write any data to the buffer that is designated by lpOutBuffer.
The server SHOULD accept a CLUSCTL_RESOURCE_NETNAME_RESET_VCO resource control code request if its protocol server state is read-only and MUST accept the request for processing if it is in the read/write state, as specified in section 3.1.1.
For ClusAPI Protocol version 3.0, the server MUST require that the access level associated with the hResource context handle is "All" (section 3.1.4). For ApiNodeResourceControl, the server MUST also require that the access level associated with the hNode context handle is "All" (section 3.1.4).