We are having an issue in our environment which contains multiple domains/forests.

All of our admin accounts are on one domain, and we have permissions through these accounts to access workstations on all of the other domains. With WinRM, if we try to PSRemote (Enter-PSSession) to a computer that is on the same domain as our accounts, it works fine. If we try to PSRemote to a workstation on one of the other domains, it will only work if we use FQDN or pass through credentials using the -credential switch.

Example:
ADMIN ACCOUNT on DOMAINA
Computer1 is on DOMAINA
COMPUTER2 is on DOMAINB

Enter-PSSession COMPUTER1 - Connects fine
Enter-PSSession COMPUTER2 - Fails to connect
Enter-PSSession COMPUTER2.FQDNDOMAINB - Connects fine
Enter-PSSession COMPUTER2 -Credential DOMAINA\ADMIN - Connects fine

Does anyone know how we can get this to work by just specifying the computername? DNS is configured properly, we can ping and connect to c$ of the PC's without using FQDN, the issue just lies within WinRM / possible AD configuration?

Hi,

So does the domain B trust domain A?

What is the detail error message when the connect failed?

WinRm requires port 5985 for http, or port 5986 for https. The Enable-PSRemoting cmdlet will auto-configure the Windows software firewall, but do ensure these ports are accessible across your network infrastructure.

http://www.thecodeking.co.uk/2011/02/winrm-with-mixed-domain-environments.html#.VVFxO3kfo5s

Regards.

Thanks for your response. The domains/forests have two-way trusts, Name Suffix Routing is enabled, and Authentication is set to Forest-wide authentication.

WinRM is enabled on the workstations and the ports are not being blocked. We are able to PSRemote if we use FQDN, or use non-FQDN and pass credentials. The issue is due to certain tools we use, we need to be able to PSRemote by hostname only (not FQDN). This should not be a DNS or Firewall issue, but rather a WinRM / Active Directory issue.

I have confirmed the registry key on the above URL is on the workstations. * has been added to TrustedHosts on both the host/client with no luck as well.

The issue lies with the user account that has admin rights to the workstation is not on the domain of the computer we are trying to connect to.

I am starting to think maybe it is an issue with Trust Settings. I am not on our Active Directory team, so I will reach out to them to discuss.

• Edited by hammondjx- Tuesday, May 12, 2015 12:19 PM

Thanks for your response. The domains/forests have two-way trusts, Name Suffix Routing is enabled, and Authentication is set to Forest-wide authentication.

WinRM is enabled on the workstations and the ports are not being blocked. We are able to PSRemote if we use FQDN, or use non-FQDN and pass credentials. The issue is due to certain tools we use, we need to be able to PSRemote by hostname only (not FQDN). This should not be a DNS or Firewall issue, but rather a WinRM / Active Directory issue.

I have confirmed the registry key on the above URL is on the workstations. * has been added to TrustedHosts on both the host/client with no luck as well.

The issue lies with the user account that has admin rights to the workstation is not on the domain of the computer we are trying to connect to.

I am starting to think maybe it is an issue with Trust Settings. I am not on our Active Directory team, so I will reach out to them to discuss.

• Edited by hammondjx- Tuesday, May 12, 2015 12:19 PM

Error message when you attempt to Enter-PSSession a PC on another domain.

If I use FQDN it connects fine, or if I use regular hostname and pass the -credential it works fine as well. Note: The credentials I am passing, are the same credentials I have launched the powershell console with.

enter-pssession : Connecting to remote server COMPUTERNAME failed with the following error message : WinRM cannot process the request. The following error      
occurred while using Kerberos authentication: Cannot find the computer COMPUTERNAME. Verify that the computer exists on the network and that the name provided is
spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.                                                                     
At line:1 char:1                                                                                                                                              
+ enter-pssession msp-003303                                                                                                                                  
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                                  
    + CategoryInfo          : InvalidArgument: (msp-003303:String) [Enter-PSSession], PSRemotingTransportException                                            
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed                                                                                                      

Hi,

Did you mean the workstation that you are trying to connect is not on the domain?

If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the  TrustedHosts configuration setting.

Did you try this to check the result?

https://support.microsoft.com/en-us/kb/2019527/

Regards.

Hi,

Any update about the issue?

Regards.

Hi - sorry for the delay.

Both computers are on the domain, but in different domains/forests. The domains have a forest trust. If the user account is not on the same domain of the workstation I am trying to connect to, I have to provide FQDN or use the -Credential parameter. I am guessing this is by design. I have a case open to premier to verify.

Any other thoughts? Thanks for your help!

Hi,

I think you are right.

If you refer to the article as I mentioned before. We could notice that Mixed domain environments require some additional configuration to get working. We need the credential for the remote server.

So did you have a try to check the result?

Regards.

Received word from MS that this is by design in Multi-Forest domains. Kerberos is failing because it is looking only at the domain that the user account is in.

Premier recommended a possible implementation of a Forest Trust DNS Suffix GPO:

https://technet.microsoft.com/en-us/library/configure-kerberos-forest-search-order-kfso%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

We are in the process of testing this. I will go ahead and close out this forum post. Thanks for your help!

• Marked as answer by hammondjx- Tuesday, May 26, 2015 11:57 AM

Hi,

Thanks for your good sharing, i think it will help the people who have the same issue.

Regards.