Подтвердить что ты не робот

Не удается создать сеанс удаленной PowerShell после Enable-PSRemoting

Я не могу удалиться на любую машину, чтобы спасти свою жизнь! Я попробовал все, что смог найти. Если бы кто-нибудь мог устранить неисправность или направить меня, я был бы признателен, поскольку это было бы отличным инструментом для добавления в мой домен.

SETUP:

  • Клиентская машина внутри домена
  • Серверная машина внутри или вне домена - виртуализированная и используемая для WSUS Computername: wsustest
  • КЛИЕНТСКАЯ СЕРВЕРНАЯ МАШИНА физическое имя: epizzi-pc

ШАГОВ:

enable-pssremoting done! on all machines
trustedhosts configured with * or client machine added
Firewalls with public profile off just in case

Enter-PSSession -ComputerName wsustest -Credential wsustest\administrator
Enter-PSSession -ComputerName epizzi-pc -Credential epizzi-pc\administrador
Enter-PSSession : Connecting to remote server epizzi-pc failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 
occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.  
 Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
 After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
 Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession -ComputerName epizzi-pc -Credential epizzi-pc\administrador
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (epizzi-pc:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Enter-PSSession -ComputerName wsustest -UseSSL -Credential wsustest\administrator

*Enter-PSSession : Connecting to remote server wsustest failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is 
valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM 
firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession -ComputerName wsustest -UseSSL -Credential wsustest\administrato ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (wsustest:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed*
ERRORs:
4b9b3361

Ответ 1

Я получал ту же проблему при удаленном взаимодействии с сервером и нашел этот пост очень полезным - http://jeffgraves.me/2013/10/14/powershell-remoting/

Для моего конкретного случая я сделал следующее:

На локальной машине

  1. winrm quickconfig (хотя это уже было настроено)
  2. winrm s winrm/config/client '@{TrustedHosts = "myservername.domain"}'

На удаленной машине

  1. enable-psremoting -force
  2. Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Имя Microsoft.PowerShell -force

Ответ 2

Вот как я это делаю. Я использую это в своих сценариях.

# This is only done once
Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File
c:\Windows\temp\securepass.txt

# Setup credentials
$SecureString = Get-Content c:\Windows\temp\securepass.txt | ConvertTo-SecureString
$mycredentials = New-Object -TypeName System.Management.Automation.PSCredential
    -ArgumentList "yourDomain\userID",$SecureString

# Open remote session:
$MyRSession = New-PSSession -ComputerName Computer1 -Credential $mycredentials
    -Authentication default

# Use remote session:
Enter-PSSession $MyRSession

Ответ 3

Если между клиентским и серверным компьютерами нет доверия, вам необходимо включить базовую проверку подлинности на стороне сервера. Сделайте это, переключив правильные свойства на диске WSMAN: на сервере. Очевидно, что вам придется делать это в интерактивном режиме на консоли или через удаленный рабочий стол из-за проблемы с курицей и яйцом:) Кроме того, это может также вступить в игру:

http://www.nivot.org/blog/post/2009/10/30/PowerShell20EnablingRemotingWithVirtualXPModeOnWindows7

Ответ 4

У меня возникла проблема с использованием полного входа в систему. Вместо "netbiosdomain\accountname" я использовал имя fqdn\accountname, как в Microsoft.com\myaccount в приглашении get-credential. Может не работать для всех, но это стоит того.

Ответ 5

Избавьтесь от -UseSSL. Я включил PSRemoting и имел проблемы с этим. Думаю, я мог бы посмотреть на это позже, но пока это не имеет значения.

Ответ 6

Я достиг удаленного сеанса с командой Enter-pssession, должен был следовать этим точным параметрам

$creds =  get-credential (the -credential parameter in enter-pssession does not work properly, thus u must         previously enter the object at another variable)
Enter-pssession -computername wsustest -authentication Default -credentials $creds

Мне также пришлось установить как клиентский, так и удаленный сервер в доверенных хостах wsman: space

другое решение, которое, несомненно, сработало бы, но я havent попытался, установил https: это сложнее сделать.

спасибо для всех, ваши комментарии, безусловно, привели к решению!

Ответ 7

Я получал ту же ошибку currently no logon servers available. Проблема была решена путем использования вместо Domain\Username в качестве учетных данных имени пользователя UPN или [email protected].