[BUG] Moc checks for Powershell Remoting are incorrect in assumptions about single-node availability

[eponerine]

Describe the bug When you run Initialize-AksHciNode or Set-AksHciConfig, the Moc cmdlet has to do some stuff to determine if a node has Powershell Remoting enabled:

The first step is to check and enable Powershell Remoting (Common.psm1)...

function Enable-Remoting
{
    <#
    .DESCRIPTION
        Enables powershell remoting on the local machine.
    #>

    Write-Status $($GenericLocMessage.comm_ps_remote) -moduleName $global:MocModule

    Enable-PSRemoting -Force -Confirm:$false
    winrm quickconfig -q -force
}

And then after it needs to test it (Moc.psm1)...

function Test-Remoting
{
    <#
    .DESCRIPTION
        Validate that powershell remoting to a node is working.

    .PARAMETER nodeName
        The node to remote to.
    #>

    param (
        [String]$nodeName
    )

    try
    {
        Invoke-Command -ComputerName $nodeName -ScriptBlock { return $null } -ErrorAction Stop
        return $true
    } catch {}

    return $false
}

The problem is this logic assumes that on a single-node system, you can Invoke-Command against yourself without it throwing an error and thus you receive a false-negative. This specifically happens when CredSSP hardening is configured and you are not specifying an FQDN to yourself.

As an example, here are screenshots proving that the "raw" commands to enable remoting work fine on the single-node:

Invoke-Command from a remote server works fine:

But Invoke-Command with shortname to itself fails:

And Invoke-Command with FQDN to itself succeeds:

And to no surprise, specifying shortname and a fresh set of creds also works perfectly fine:

Why this happens makes perfect sense if you run Get-WSManCredSSP. Only the FQDN of the "local machine" is specified in WSMan for delegating creds:

Other than hacking up the Powershell module to use FQDN, I am unsure how to proceed here.

[eponerine]

Well, after smashing my head against a keyboard for awhile, it appears that this user's Hyper-V host was misconfigured to use incorrect DNS servers that couldn't resolve shortnames, but obviously if the FQDN was specified, it conditionally-forwarded and resolved correctly.

I'm still not 100% convinced that my issue is self-inflicted, but you know what they say:

Let me tweak a few more things and I'll confirm if this should be closed or not. Stay tuned!

[eponerine]

Negative, def not a DNS problem on my side. Brand new server with correct DNS, the same error occurs:

I just edited Moc, Kva, and AksHci modules and replaced $env:ComputerName with something that generates the full FQDN and it appears to work!

[eponerine]

There appears to be a few spots in KVA, MOC, and AKSHCI cmdlets that also use hostname instead of $env:COMPUTERNAME. Again, by replacing that with something that generates an FQDN, everything has been happy in my world.

[eponerine]

@madhanrm - was this something looked at in newer PowerShell modules?