Hello @Schoch ,
Is it possible that your connections use a proxy server if a FQDN is used and connect directly if a plain (local) name is used?
Gary
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hello
Since a short time I have the problem, that I can't connect to other computers in my network with WinRM, but only if I use the FQDN.
When I use only the computer name without the DNS suffix then it works.
The problem occurred on Windows 10 and also Windows Server 2019.
This is the error message if I use the FQDN:
Enter-PSSession: Processing data for a remote command failed with the following error message: The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.
I have also a strange behavior if I open for example the Hyper-V Snap-In and try to connect to another computer with Hyper-V. Then I see this message:
The object contained a value in property "Started" that is not valid.
Does anyone have any idea what causes this strange behavior?
DNS resolution is working fine, without FQDN and with.
Thanks for help.
Hello @Schoch ,
Is it possible that your connections use a proxy server if a FQDN is used and connect directly if a plain (local) name is used?
Gary
Have you recently done anything with certificates? Is it possible that the hostname has been used on a certificate(s) instead of the fqdn?
Have you checked the "trust" list in the WinRM configurations on the clients (if you're not using Kerberos for authentication)?
I have checked the certificates, but they use all the fqdn and I don't know anything about recently certificate changes.
Interestingly, I have some VMs that don't have this problem. From these VM's I can connect to any other VM's in my domain without problem with the fqdn.
These VM's are all in the same OU. So I tried to move a problematic VM to the OU where WinRM is working and I updated the group policies. But it doesn't helped.
For me that would indicate there is a problem with the WinRM client and not the WinRM server, because I can connect on the working VM's to all other VM's with the fqdn. But with the problem VM's no connection to any other VM with the fqdn is working.
I checked also the WinRM client settings, but they are the same on the working and the problem VM's:
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false [Source="GPO"]
Auth
Basic = false [Source="GPO"]
Digest = false [Source="GPO"]
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
Any idea if there is something else which I can check? Thanks.
Does this quick test work?
Test-NetConnection <FQDN> -port 5985
I suppose it's possible that the size of the token is too large if the user is a member of a large number of security groups. I haven't encountered that problem in many years, but I remember having that problem. This describes a way to circumvent that problem: winrm-client-http-bad-request-status-400
How about checking DNS? Does your server have both an IPv4 and IPv6 address? Does a reverse lookup on the addresses return the correct name? Do all your DNS servers return the same IP addresses in a forward lookup for the FQDN?
How about (from the client) running "winrm id -remote:<FQDN>" and/or "winrm id -remote<FQDN> -auth:none"?
Test-Connection succeeds yes. Because WinRM returns an error 400 I supposed this.
The size of the token could not be the problem, because I have only a small deployment with one rootdomain and one DC as DNS server.
I use only IPv4 in my network, but link local IPv6 is enabled. The problem occurs within the same subnet and also across subnets. The reverse lookup is working also.
I have only one DNS server, so the DNS answers are always the same.
Here you can see my console output:
PS C:\> Resolve-DnsName rdgateway.blabla.ch
Name Type TTL Section IPAddress
rdgateway.blabla.ch A 1200 Answer 10.137.0.44
PS C:\> Resolve-DnsName 10.137.0.44
Name Type TTL Section NameHost
44.0.137.10.in-addr.arpa PTR 1200 Answer rdgateway.blabla.ch
PS C:\> winrm id -remote:rdgateway.blabla.ch
IdentifyResponse
ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor = Microsoft Corporation
ProductVersion = OS: 10.0.17763 SP: 0.0 Stack: 3.0
SecurityProfiles
SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/spnego-kerberos
PS C:\> winrm id -remote:rdgateway.blabla.ch -auth:none
WSManFault
Message = The WinRM client cannot process the request. The destination computer (rdgateway.blabla.ch:5985) returned an 'access denied' error. Specify one of the authentication mechanisms supported by the server. If Kerberos mechanism is used, verify that the client computer and the destination computer are joined to a domain. Possible authentication mechanisms reported by server: Negotiate Kerberos
Error number: -2147024891 0x80070005
Access is denied.
PS C:\> Enter-PSSession rdgateway.blabla.ch
Enter-PSSession: Processing data for a remote command failed with the following error message: The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.
PS C:\> Enter-PSSession rdgateway
[rdgateway]: PS C:\Users\testuser\Documents> exit
PS C:\>