Problemi con i server di patch in remoto tramite winrm e Microsoft.Update.Session

Ho una rete con server Windows 2003, 2008 e 2008r2. Ho uno script PowerShell che ho scritto per patchare una macchina locale usando gli oggetti com "Microsoft.Update". (Simile a Windows Update PowerShell Remoting .) Il mio script funziona meravigliosamente localmente, ma mi piacerebbe usare le sue funzioni da remoto poiché ho un buon numero di server da gestire. In quel caso cade (in modo simile a quell'altro post, che non è stato risolto).

Sono stato comunque in grado di restringere il fallimento a due metodi su una classe particolare.

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

Se li esegui in una PowerShell localmente come amministratore, non avrai problemi. Se si tenta di utilizzare invoke-command (o enter-session o winrs) verrà visualizzato il seguente errore. (Questo è il test con localhost, ma qualsiasi host lo farà. Ho anche provato con diversi metodi di autenticazione come 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

Ho visto questo citato sui blog come un bug, ma senza backup di tale affermazione. Esistono due soluzioni alternative ed entrambe non mi rendono felice.

• Utilizzare psexec per eseguire comandi come utente del sistema. PSExec è ciò che sto cercando di non utilizzare in quanto si è dimostrato inaffidabile. Vorrei anche una soluzione PowerShell pura.
• Creare un'attività pianificata e comunicarlo per eseguire lo script come utente di sistema. (tramite il suo post ) Questo non è solo disordinato ma poi non avrò i risultati dell'aggiornamento. Dovrò accedere a un file o aggiornare un database o qualcosa del genere.

Sono aperto ad altri modi per eseguire gli aggiornamenti su un host in remoto poiché questo sembra essere un problema che molte persone stanno colpendo.

Ho trovato alcuni documenti che spiegano il messaggio ma non il motivo o la soluzione alternativa.

Valore restituito Restituisce S_OK in caso di successo. In caso contrario, restituisce un codice di errore COM o Windows.

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.

Come fa a sapere che sono su un computer remoto?

Non puoi farlo amico, perché MS non ti consente di farlo tramite WUApi.

I dettagli sono disponibili qui: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387288(v=vs.85).aspx

Puoi provare a utilizzare l'attività pianificata per farlo.

Tale comando deve essere eseguito con i privilegi sul computer remoto, da cui la necessità di essere eseguito come utente amministratore di dominio o come amministratore sul computer remoto.

Se il tuo è il primo caso, non ho aiuto, ma tu sei solo amministratore locale, non remoto, usa get-credentialcosì.

$cred = get-credential

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

Un modulo alternativo e più diretto è Invoke-Commandchiedere credenziali:

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

Sono stato in grado di farlo funzionare impostando un endpoint JEA sul server remoto per l'esecuzione come account virtuale locale.

Da https://docs.microsoft.com/en-us/powershell/jea/session-configurations :

Account virtuale locale

Se i ruoli supportati da questo endpoint JEA sono tutti utilizzati per gestire il computer locale e un account amministratore locale è sufficiente per eseguire correttamente i comandi, è necessario configurare JEA per utilizzare un account virtuale locale. Gli account virtuali sono account temporanei unici per un utente specifico e durano solo per la durata della sessione di PowerShell. Su un server o una workstation membro, gli account virtuali appartengono al gruppo Administrators del computer locale e hanno accesso alla maggior parte delle risorse di sistema. Su un controller di dominio Active Directory, gli account virtuali appartengono al gruppo Domain Admins del dominio.