How to set foreign-domain alias for a Failover Cluster client access point?

I have a migration scenario with a Failover Cluster file service where I would like to add the alias for the old file server name pointing to the cluster service client access point name.

Using CNAMEs or A-RRs with DNS and creating client access points for the cluster is easy enough, but my trouble is that the Cluster Manager is only allowing for single-label CAP names and seems to only be appending the primary DNS suffix to the name.

So given a deprecated file service called \\oldserver.olddomain.example.com and a cluster CAP named oldserver, the names the cluster CAP will respond to will be \\oldserver.clusterdomain.example.com and \\oldserver. I can't seem to be able to get it responding at \\oldserver.olddomain.example.com, it is throwing 0x80004005 (unspecified error) upon my access attempts.

The packet trace is showing an SMB2 IoCtl Response packed with STATUS_ACCESS_DENIED from the CAP's IP address after my client has established a Tree Connect and has sent the FSCTL_VALIDATE_NEGOTIATE_INFO request.

The "How to Configure an Alias for a Clustered SMB Share" blog post suggests setting an alias using `Set-ClusterParameter. Unfortunately, it is not accepting FQDNs either erroring out with "The format of the specified network name is invalid"

I also have already registered SPNs for oldserver.olddomain.example.com and oldserver to the CAP's domain computer account, so Kerberos should not be a problem.

Edit: adding DisableStrictNameChecking to the registry of the cluster nodes unfortunately does not help either.

D'oh!.

I should have rebooted my client(s) before testing - this would have helped. It turns out this has not been about foreign domains at all, just a temporary SMB signature verification issue.

Windows 8¹: SMB reconnections fail with “Invalid Signature” upon server upgrade to SMB 3.0²:

1. The Windows 8 client maps a share on a server with the SMB 2.1 dialect, the server’s highest dialect.

Example using Powershell command: New-SmbMapping -LocalPath Y: -RemotePath \FileServer\Share

2. The server disconnects TCP and its software is upgraded to a version that supports SMB 3.0.

3. The client negotiates SMB 3.0 dialect, the newest server’s highest dialect, and attempts re-connecting to the same share.

4. The server fails to validate the signature the client sent in the IOCTL FSCTL_VALIDATE_NEGOTIATE_INFO. The server returns an error ACCESS_DENIED to the client.

[...]

A possible workaround is to have the Windows 8 client disconnect and delete that connection/session before it can re-establish a new connection. This requires un-mapping the drive (and wait for about 20 seconds for the client to cleanup data related to that connection entry) and then remap it again.

A client reboot the client will also achieve the same result but it is not required.

¹: I have this
²: I have done this