Problemas com remendar servidores remotamente usando winrm e Microsoft.Update.Session

Question

Eu tenho uma rede com servidores Windows 2003, 2008 e 2008r2. Eu tenho um script powershell que eu escrevi para corrigir uma máquina local usando os objetos com "Microsoft.Update". (Semelhante ao Remoting do Windows Update PowerShell Meu script funciona maravilhosamente localmente, mas eu gostaria de usar suas funções remotamente, pois tenho um bom número de servidores para gerenciar. Nesse caso, ele cai (da mesma forma que o outro post, que não foi resolvido).

No entanto, consegui limitar a falha a dois métodos em uma classe específica.

(New-Object -ComObject "Microsoft.Update.Session").CreateUpdateDownloader()
(New-Object -ComObject "Microsoft.Update.Session").CreateUpdateInstaller()

Se você executá-los em um powershell localmente como administrador, não terá problemas. Se você tentar usar invoke-command (ou enter-session ou winrs), receberá o seguinte erro. (Isso está testando com localhost, mas qualquer host serve. Eu também tentei com métodos de autenticação diferentes, como credssp e kerberos.);

PS C:\> Invoke-Command -ComputerName localhost -ScriptBlock { (New-Object -ComObject "microsoft.update.session").createUpdateDownloader()}
Exception calling "CreateUpdateDownloader" with "0" argument(s): "Access is denied. (Exception from HRESULT: 0x80070005
 (E_ACCESSDENIED))"
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ComMethodTargetInvocation

Eu vi isso mencionado em blogs como um bug, mas sem backup para essa afirmação. Existem duas soluções alternativas e ambas não me fazem feliz.

• Use o psexec para executar comandos como o usuário do sistema. PSExec é o que eu sou tentando não usar como provou não ser confiável. Eu também gostaria de um puro solução powershell.
• Crie uma tarefa agendada e diga para executar seu script como o usuário do sistema. (via t seu post ) Isso não é apenas confuso, mas então eu não terá os resultados da atualização. Vou ter que logar em um arquivo ou atualizar um banco de dados ou algo assim.

Estou aberto a outras maneiras de executar atualizações em um host remotamente, pois isso parece ser um problema que muitas pessoas estão atingindo.

Eu encontrei alguns documentos que explica a mensagem, mas não o motivo ou a solução alternativa.

Return Value Returns S_OK if successful. Otherwise, returns a COM or Windows error code.

This method can also return the following error codes.
Return code   Description
E_INVALIDARGA parameter value is invalid. 
E_ACCESSDENIED    This method cannot be called from a remote computer.

Como ele sabe que estou em um computador remoto?

    

Answer 1

Você simplesmente não pode fazer isso, pois o MS não permite que você o faça através do WUApi.

Detalhes podem ser encontrados aqui: link

Você pode tentar usar a tarefa agendada para fazer isso.

    

Answer 2

Esse comando precisa ser executado com privilégios na máquina remota, daí a necessidade de ser executado como um usuário administrador de domínio ou um administrador na máquina remota.

Se o seu for o primeiro caso, não tenho ajuda, mas você é apenas um administrador local, não remoto, use get-credential desta forma.

$cred = get-credential

Invoke-Command -ComputerName localhost -credential $cred -scriptblock {}

Uma forma alternativa e mais direta é deixar Invoke-Command pedir credenciais:

Invoke-Command -scriptblock {$ENV:username} -Credential ""

    

Answer 3

Consegui que isso funcionasse configurando um ponto de extremidade do JEA no servidor remoto para ser executado como uma conta virtual local.

Em link :

Local Virtual Account

If the roles supported by this JEA endpoint are all used to manage the local machine, and a local administrator account is sufficient to run the commands succesfully, you should configure JEA to use a local virtual account. Virtual accounts are temporary accounts that are unique to a specific user and only last for the duration of their PowerShell session. On a member server or workstation, virtual accounts belong to the local computer's Administrators group, and have access to most system resources. On an Active Directory Domain Controller, virtual accounts belong to the domain's Domain Admins group.