What I did to resolve this issue was to create a proxy function for Enter-PSSession that resolves the CNAME for me. This might not work in your case, depending on why you need to use the CNAME, but this works for me.
Details on proxy powershell functions: http://www.windowsitpro.com/blog/powershell-with-a-purpose-blog-36/windows-powershell/powershell-proxy-functions-141413
Full function:
function Enter-PSSession {
[CmdletBinding(DefaultParameterSetName='ComputerName')]
param(
[Parameter(ParameterSetName='ComputerName', Mandatory=$true, Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
[Alias('Cn')]
[ValidateNotNullOrEmpty()]
[string]
${ComputerName},
[Parameter(ParameterSetName='Session', Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
[ValidateNotNullOrEmpty()]
[System.Management.Automation.Runspaces.PSSession]
${Session},
[Parameter(ParameterSetName='Uri', Position=1, ValueFromPipelineByPropertyName=$true)]
[Alias('URI','CU')]
[ValidateNotNullOrEmpty()]
[uri]
${ConnectionUri},
[Parameter(ParameterSetName='InstanceId', ValueFromPipelineByPropertyName=$true)]
[ValidateNotNull()]
[guid]
${InstanceId},
[Parameter(ParameterSetName='Id', Position=0, ValueFromPipelineByPropertyName=$true)]
[ValidateNotNull()]
[int]
${Id},
[Parameter(ParameterSetName='Name', ValueFromPipelineByPropertyName=$true)]
[string]
${Name},
[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[switch]
${EnableNetworkAccess},
[Parameter(ParameterSetName='ComputerName', ValueFromPipelineByPropertyName=$true)]
[Parameter(ParameterSetName='Uri', ValueFromPipelineByPropertyName=$true)]
[system.management.automation.pscredential]
${Credential},
[Parameter(ParameterSetName='ComputerName')]
[ValidateRange(1, 65535)]
[int]
${Port},
[Parameter(ParameterSetName='ComputerName')]
[switch]
${UseSSL},
[Parameter(ParameterSetName='ComputerName', ValueFromPipelineByPropertyName=$true)]
[Parameter(ParameterSetName='Uri', ValueFromPipelineByPropertyName=$true)]
[string]
${ConfigurationName},
[Parameter(ParameterSetName='ComputerName', ValueFromPipelineByPropertyName=$true)]
[string]
${ApplicationName},
[Parameter(ParameterSetName='Uri')]
[switch]
${AllowRedirection},
[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[ValidateNotNull()]
[System.Management.Automation.Remoting.PSSessionOption]
${SessionOption},
[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[System.Management.Automation.Runspaces.AuthenticationMechanism]
${Authentication},
[Parameter(ParameterSetName='Uri')]
[Parameter(ParameterSetName='ComputerName')]
[string]
${CertificateThumbprint})
begin
{
try {
$outBuffer = $null
if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer))
{
$PSBoundParameters['OutBuffer'] = 1
}
$PSBoundParameters['ComputerName'] = ([System.Net.Dns]::GetHostByName($PSBoundParameters['ComputerName'])).HostName
$wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Microsoft.PowerShell.Core\Enter-PSSession', [System.Management.Automation.CommandTypes]::Cmdlet)
$scriptCmd = {& $wrappedCmd @PSBoundParameters }
$steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
$steppablePipeline.Begin($PSCmdlet)
} catch {
throw
}
}
process
{
try {
$steppablePipeline.Process($_)
} catch {
throw
}
}
end
{
try {
$steppablePipeline.End()
} catch {
throw
}
}
<#
.ForwardHelpTargetName Enter-PSSession
.ForwardHelpCategory Cmdlet
#>
}
The only line I added was:
$PSBoundParameters['ComputerName'] = ([System.Net.Dns]::GetHostByName($PSBoundParameters['ComputerName'])).HostName
This simply resolves the CNAME to the FQDN in the proxy function before calling the native Enter-PSSession.
This allows me to set *.mydomain.local in my TrustedHosts via Group Policy, and I can still use "Enter-PSSession ShortName" or "Enter-PSSession CNAME" without having to mess with additional SPNs, etc.
PSRemoting to an IP address always gives me an error, could be something to do with computer names and certificates, I haven't bothered to look into it. FQDN however works for me. Remember that the FQDN can be separate than your domain's name, which won't work.
Microsoft says the period is a valid character in a NETBIOS name, however changing the computer name on my Windows 7 computer to add a dot gives me an error. Upon further investigation, MS has this to say about that special character:
A period character separates the name into a NetBIOS scope identifier and the computer name. The NetBIOS scope identifier is an optional string of characters that identify logical NetBIOS networks that run on the same physical TCP/IP network. For NetBIOS to work between computers, the computers must have the same NetBIOS scope identifier and unique computer names.
This is slightly different than using a period when specifying an fqdn. In fact, I'll go so far as to say that it may be interpreting the dot as specifying an fqdn and that's what is causing the problem.
Best Answer
You can add the IP address to the TrustedHost list:
Using this I managed to connect to a Windows 2003 server in a different domain, which I could connect to using either, the NETBIOS or FQN name yesterday.