Probleme beim Remote-Patchen von Servern mit winrm und Microsoft.Update.Session

Ich habe ein Netzwerk mit Windows 2003-, 2008- und 2008r2-Servern. Ich habe ein Powershell-Skript, das ich geschrieben habe, um einen lokalen Computer mit den com-Objekten "Microsoft.Update" zu patchen. (Ähnlich wie bei Windows Update PowerShell Remoting .) Mein Skript funktioniert lokal hervorragend, aber ich möchte seine Funktionen remote verwenden, da ich eine angemessene Anzahl von Servern verwalten muss. In diesem Fall fällt es herunter (ähnlich wie bei dem anderen Beitrag, der nicht gelöst wurde).

Ich konnte den Fehler jedoch auf zwei Methoden für eine bestimmte Klasse eingrenzen.

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

Wenn Sie diese in einer Powershell lokal als Administrator ausführen, treten keine Probleme auf. Wenn Sie versuchen, den Befehl invoke (oder enter-session oder winrs) zu verwenden, wird der folgende Fehler angezeigt. (Dies wird mit localhost getestet, aber jeder Host wird es tun. Ich habe es auch mit verschiedenen Authentifizierungsmethoden wie credssp und kerberos versucht.);

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

Ich habe dies in Blogs als Fehler erwähnt gesehen, aber ohne Backup für diese Behauptung. Es gibt zwei Problemumgehungen und beide machen mich nicht glücklich.

• Verwenden Sie psexec, um Befehle als Systembenutzer auszuführen. PSExec ist das, was ich versuche, nicht zu verwenden, da es sich als unzuverlässig erwiesen hat. Ich hätte auch gerne eine reine Powershell-Lösung.
• Erstellen Sie eine geplante Aufgabe und teilen Sie dieser mit, dass Ihr Skript als Systembenutzer ausgeführt werden soll. (über seinen Beitrag ) Dies ist nicht nur chaotisch, sondern ich werde auch nicht die Update-Ergebnisse haben. Ich muss mich bei einer Datei anmelden oder eine Datenbank oder etwas aktualisieren.

Ich bin offen für andere Möglichkeiten, Updates auf einem Host remote auszuführen, da dies ein Problem zu sein scheint, auf das viele Leute stoßen.

Ich habe einige Dokumente gefunden , die die Nachricht erklären, aber nicht den Grund oder die Problemumgehung.

Rückgabewert Gibt bei Erfolg S_OK zurück. Andernfalls wird ein COM- oder Windows-Fehlercode zurückgegeben.

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.

Woher weiß es, dass ich auf einem Remotecomputer bin?

Sie können es einfach nicht tun, weil MS es Ihnen nicht erlaubt, es über WUApi zu tun.

Details finden Sie hier: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387288(v=vs.85).aspx

Sie können versuchen, die geplante Aufgabe zu verwenden, um dies zu erledigen.

Ein solcher Befehl muss mit Berechtigungen auf dem Remotecomputer ausgeführt werden, von wo aus er als Domänenadministratorbenutzer oder als Administrator auf dem Remotecomputer ausgeführt werden muss.

Wenn deins der erste Fall ist, habe ich keine Hilfe, aber Sie sind nur lokaler Administrator, nicht remote, verwenden Sie get-credentialso.

$cred = get-credential

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

In einem alternativen und direkteren Formular werden Sie Invoke-Commandnach Anmeldeinformationen gefragt:

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

Ich konnte dies zum Laufen bringen, indem ich einen JEA-Endpunkt auf dem Remote-Server einrichtete, der als lokales virtuelles Konto ausgeführt werden soll.

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

Lokales virtuelles Konto

Wenn die von diesem JEA-Endpunkt unterstützten Rollen alle zum Verwalten des lokalen Computers verwendet werden und ein lokales Administratorkonto ausreicht, um die Befehle erfolgreich auszuführen, sollten Sie JEA für die Verwendung eines lokalen virtuellen Kontos konfigurieren. Virtuelle Konten sind temporäre Konten, die für einen bestimmten Benutzer eindeutig sind und nur für die Dauer ihrer PowerShell-Sitzung gültig sind. Auf einem Mitgliedsserver oder einer Workstation gehören virtuelle Konten zur Administratorgruppe des lokalen Computers und haben Zugriff auf die meisten Systemressourcen. Auf einem Active Directory-Domänencontroller gehören virtuelle Konten zur Gruppe der Domänenadministratoren der Domäne.