Enable-PSRemoting no erro do Windows Server 2008 R2

1

Ao fornecer o comando Enable-PSSRemoting com ou sem o parâmetro -Force, este erro ocorre

Set-WSManQuickConfig : More data is available.
At line:50 char:33
+           Set-WSManQuickConfig <<<<  -force
+ CategoryInfo          : InvalidOperation: (:) [Set-WSManQuickConfig],
InvalidOperationException + FullyQualifiedErrorId : 
WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand

Eu olhei para este recurso para ajudar na solução deste problema link e alguns outros.

Mas parece que a minha solução não está em nada disso. Eu verifiquei sobre executar como administração, verifiquei que o administrador local não está desativado ou tem uma senha em branco, também atualizou a chave do registro sobre o LocalAccountTokenFilterPolicy. Configure os trustedhosts para *

Isso é feito localmente em um Windows Server 2008 R2 SP1, x64 ENU

Resultado de: winrm quickconfig como sugerido por @tony roth

WSManFault
Message = More data is available.
Error number:  -2147024662 0x800700EA
More data is available.

Resultado de: winrm enumerate winrm / config / listener

Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.108.x.x, 127.0.0.1, ::1, x:0:5ef5:79fb:6b:3590:f593:f4eb, x::5efe:10.108.11.20%13, fe80::6b

: x: f593: f4eb% 11, x :: 8418: 7b59: e7ff: ccd4% 12

Resultado de: dir WSMan: \ localhost \ shell

AllowRemoteShellAccess    true
IdleTimeout               180000
MaxConcurrentUsers        5
MaxShellRunTime           2147483647
MaxProcessesPerShell      15
MaxMemoryPerShellMB       150
MaxShellsPerUser          5

Resultado de: dir WSMan: \ localhost \ client

Name            Value                                        Type
----            -----                                        ----
NetworkDelayms            5000                               System.String
URLPrefix                 wsman                              System.String
AllowUnencrypted          false                              System.String
Auth                                                         Container
DefaultPorts                                                 Container
TrustedHosts              *                                  System.String

Resultado de: Get-Item WSMan: \ localhost \ Service \ RootSDDL

Name     Value                                                        Type
----     -----                                                        ----
RootSDDL O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)   System.String

Resultado de: Test-WsMan localhost

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 2.0

Isso é localmente no servidor, os clientes do WORKGROUP remotos ainda não estão envolvidos neste cenário

    
por gojj 14.08.2013 / 14:30

3 respostas

1

Aqui está o meu guia de resolução de problemas para resolver este problema:

  • A sua máquina está conectada a um domínio ou grupo de trabalho?
  • Você está conectado como administrador local?
  • O PowerShell foi lançado como "Administrador"?
  • Sua senha está em branco?
  • Você está tentando se conectar a um farm do SharePoint?
  • O seu servidor é hospedado / gerenciado por uma empresa de hospedagem?
  • Você está usando o VirtualBox?
  • Você está executando o comando em um computador em que o idioma não está definido para o Inglês?

link

    
por 18.01.2014 / 18:34
1

Apenas encontrei e resolvi esse problema em alguns sistemas. Nesse caso específico, esses dois sistemas não faziam parte de um domínio, e a conta de usuário não era a conta "Administrador" original, mas sim uma conta mais recente que também era membro do grupo Administradores local.

A solução veio da seguinte postagem do blog em que eu passei: WinRM O acesso é negado no computador local . Em resumo, execute o seguinte em um prompt de comando (iniciado como administrador):

> reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Depois disso, reinicie o prompt do Powershell como admin e execute novamente o Enable-PSSRemoting . Simples assim.

    
por 23.04.2014 / 02:52
0

Eu posso reproduzir totalmente esse comportamento em um novo Windows Server 2008 R2 SP1 com o PowerShell 2

Usando um PowerShell elevado, enable-psremoting -force resulta no erro Set-WSManQuickConfig : Access is denied. .

A solução que funcionou para mim foi fazer logon com a conta 'administrador' real (S-1-5 -...- 500) e executar o comando novamente.

Eu não sei porque isso faz a diferença, mas fez por mim.

    
por 03.10.2013 / 14:02