{"id":2504,"date":"2013-11-29T00:01:00","date_gmt":"2013-11-29T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2013\/11\/29\/remoting-week-non-domain-remoting\/"},"modified":"2013-11-29T00:01:00","modified_gmt":"2013-11-29T00:01:00","slug":"remoting-week-non-domain-remoting","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/remoting-week-non-domain-remoting\/","title":{"rendered":"Remoting Week: Non-Domain Remoting"},"content":{"rendered":"

Summary<\/strong>: Richard Siddaway explains how to use Windows PowerShell remoting to access machines that aren’t in your domain.\n\"Hey, Hey, Scripting Guy! I’ve just starting learning Windows PowerShell, and I understand how to use it as a scripting language and shell on the local machine. How do I work with remote machines?\n—AP\n\"Hey, Hello AP,\nHonorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. This is the final part of a series of five posts about remoting. To catch up on the previous posts, see:<\/p>\n

    \n
  1. Remoting Recap<\/a><\/li>\n
  2. Remoting Sessions<\/a><\/li>\n
  3. Configuring Remoting<\/a><\/li>\n
  4. Remoting Security<\/a><\/li>\n<\/ol>\n

    So far in this series, you have seen how to perform ad hoc remoting to systems by using the ComputerName<\/strong> parameter on various cmdlets. This leads into Windows PowerShell remoting sessions where you create a persistent connection to one or more remote machines. You can use that connection to run multiple commands, and only set up and tear down the connection once, instead of once per command.\nAny remote connectivity system needs to be secure and that is certainly true of Windows PowerShell remoting. In the third part of the series, you saw how HTTPS can be used to secure traffic between the remote system and your administration machine. You also saw how the configuration of the endpoints can be modified to give you more control and lock down the endpoint.\nCustom endpoints can be used to control who can access the endpoint and what they can do. This includes the Windows PowerShell language features and the cmdlets that are available. You can control a range; for example, you can make available the full language and all the installed cmdlets, or you can create a situation where the admin who is connecting to that endpoint can’t use the Windows PowerShell language and can only run a hand full of cmdlets. You can connect to that endpoint by using the Windows PowerShell tools, or you can use Windows PowerShell Web Access to give you a Windows PowerShell session that is hosted in your browser by accessing that endpoint.\nIn all of these examples, the assumption is that you are remoting within the domain. You may think that Windows PowerShell Web Access doesn’t fit this model, but the Windows PowerShell Web Access server may be in the domain, so the remoting sessions are between machines in the same domain.\nWhat about the situation where the machines aren’t in the same domain? You can recognize three broad scenarios for non-domain remoting:<\/p>\n

      \n
    1. Remoting into a domain<\/li>\n
    2. Remoting across domains<\/li>\n
    3. Remoting in workgroups<\/li>\n<\/ol>\n

      Remember that you need network connectivity to the remote machine over the ports that WSMAN will be using. The defaults are HTTP over port 5985 or HTTPS over port 5986.\nYou have already seen one way to solve the issues around options 1 and 2: use Windows PowerShell Web Access.  It provides a gateway into the domain that can be used to easily access remoting endpoints within that domain in a secure manner.\nIf the domain to which you are remoting is in the same forest, your environment may be configured to allow the use of your standard credentials. If not, you are back to a situation that can span all three options: you need to remote to a system that isn’t in your current domain. Even the workgroup situation can be regarded as a special case in this scenario.\nSo what happens if you try to remote to a machine that isn’t in your domain?<\/p>\n

      £> $cred = Get-Credential<\/p>\n

      £> $sess = New-PSSession -ComputerName server02<\/p>\n

      New-PSSession : [server02] Connecting to remote server server02 failed with the following error message : The WinRM client cannot process the request. 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. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help<\/p>\n

      config. For more information, see the about_Remote_Troubleshooting Help topic.<\/p>\n

      At line:1 char:9<\/p>\n

      + $sess = New-PSSession -ComputerName server02<\/p>\n

      +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<\/p>\n

          + CategoryInfo          : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin<\/p>\n

         gTransportException<\/p>\n

          + FullyQualifiedErrorId : ServerNotTrusted,PSSessionOpenFailed\nTrying to use an IP address such as the following will generate a similar error:<\/p>\n

      $sess = New-PSSession -ComputerName 10.10.54.201 -Credential $cred\nThe issue is that the client machine and the remote machine are not able to mutually authenticate as they would within a domain. The error messages are useful in that they provide a couple of possible answers:<\/p>\n