Here is essentially how I am using it in a build script, I'll omit all the assorted error checking and variable assignment content to simplify reading, I think the $VariableNames speak for themselves.
Note $ADUserName and $ADDomain are correctly extracted from a $host.ui.PromptForCredential() call.
Get-VMHost -Server $HostFQDN -Name $HostFQDN | Get-VMHostAuthentication | Set-VMHostAuthentication -JoinDomain -Domain $ADDomain -User $ADUserName -Password $creds.GetNetworkCredential().password -Confirm:$false
All of this works perfectly for a user account in the same AD domain as target computer account for the ESXi host, but fails for a user in another domain. This user has rights to the OU and computer object set correctly. (Tested)
I have tried manually entering assorted variations for the Set-VMHostAuthentication -User variable
I.e.
Domain\Username
Username@Domain
"Domain\Username"
"Username@Domain"
These both fail as I know that you already know from reading other discussions here.
Only Set-VMHostAuthentication -User Username works (obviously including the other assorted variables as above, shown here for simplicity)
The only accepted variable for Set-VMHostAuthentication -User is a simple user account in the same domain as the variable provided for the Set-VMHostAuthentication -Domain variable.
It seems to me to be an opportunity for VMware to amend this commandlet, to facilitate usage in a multi-domain AD, Unless someone else has figured out how to do this.
