Estou tentando administrar uma máquina com Windows 7 remotamente. Eu habilitei o WinRM e posso usar o Enter-PsSession para se conectar à máquina remota.
No entanto, estou percebendo a diferença entre executar um comando específico localmente, vs executá-lo remotamente, mesmo que eu esteja conectando com a mesma conta de usuário (que é um administrador de domínio).
A saída da sessão remota é:
> enter-pssession -computername REMOTEHOST
[REMOTEHOST} > Get-WURebootStatus
New-Object : Creating an instance of the COM component with CLSID {C01B9BA0-BEA7-41BA-B604-D0A36F469133} from the IClassFactory failed due to the following error: 80070005.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\pswindowsupdate\Get-WURebootStatus.ps1:52 char:33
+ $objSystemInfo= New-Object <<<< -ComObject "Microsoft.Update.SystemInfo"
+ CategoryInfo : NotSpecified: (:) [New-Object], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewObjectCommand
ExecutionPolicy é definido como 'Irrestrito' e esse comando funciona muito bem quando estou usando uma sessão de powershell local na máquina remota.
Existe um contexto de segurança diferente para sessões remotas do powershell?
editar : a linha específica em que está falhando é esta:
$objSystemInfo= New-Object -ComObject "Microsoft.Update.SystemInfo"
A API do Windows Update é especial. Ele verifica especificamente e não permite o acesso remoto, verificando se o seu token está marcado como remoto. Eu não sei porque foi escrito dessa maneira.
Acabei criando uma tarefa agendada e invocando a API de atualização do windows dentro disso - um grande incômodo.
Dependendo de como o cmdlet Get-WURebootStatus acessa suas informações, acho que isso pode estar relacionado ao problema do "segundo salto" no PowerShell.
Quando você entra em uma sessão remota do PowerShell, está pedindo ao WinRM para criar uma sessão no host remoto usando suas credenciais. Se, nessa mesma sessão, você tentar acessar outro sistema (remoto) ou serviço que requeira essas credenciais, a solicitação falhará porque a máquina remota não está autorizada a usar suas credenciais para autenticação em qualquer outra coisa. Ei, cara da equipe de scripts! blog explica bem isso:
Você veria esse mesmo problema (ou semelhante) quando, após remoting em uma máquina e, em seguida, tentasse acessar outro caminho de compartilhamento de máquina remota com Test-Path, pelo mesmo motivo.
A solução (conforme apresentada no artigo do blog) é ativar e usar o CredSSP como o mecanismo de autenticação ao criar a PSSession.
Você também pode agrupar o comando em uma tarefa agendada e executá-la imediatamente, mas isso é muito trabalho extra que pode ser desnecessário.
Tente usar Get-WURebootStatus -ComputerName <your remote computer> -Silent .
Tags remote-access powershell winrm