Problemy ze zdalnym łataniem serwerów za pomocą winrm i Microsoft.Update.Session

Mam sieć z serwerami Windows 2003, 2008 i 2008r2. Mam skrypt PowerShell, który napisałem, aby załatać lokalną maszynę za pomocą obiektów com „Microsoft.Update”. (Podobnie jak w Windows Update PowerShell Remoting .) Mój skrypt działa wspaniale lokalnie, ale chciałbym korzystać z jego funkcji zdalnie, ponieważ mam sporo serwerów do zarządzania. W takim przypadku spada (podobnie jak w przypadku innego postu, który nie został rozwiązany).

Byłem jednak w stanie zawęzić błąd do dwóch metod w danej klasie.

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

Jeśli uruchomisz je w PowerShell lokalnie jako administrator, nie będziesz mieć problemów. Jeśli spróbujesz użyć polecenia invoke (lub Enter-session lub Winrs), pojawi się następujący błąd. (To jest testowanie z localhost, ale zrobi to każdy host. Próbowałem też z różnymi metodami uwierzytelniania, takimi jak credssp i 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

Widziałem to na blogach jako błąd, ale bez kopii zapasowej tego roszczenia. Istnieją dwa obejścia i oba nie sprawiają, że jestem szczęśliwy.

• Użyj psexec do uruchamiania poleceń jako użytkownik systemu. PSExec jest tym, czego staram się nie używać, ponieważ okazało się niewiarygodne. Chciałbym również czystego rozwiązania PowerShell.
• Utwórz zaplanowane zadanie i powiedz, aby uruchomić skrypt jako użytkownik systemu. (przez jego post ) Jest to nie tylko niechlujne, ale nie będę miał wyników aktualizacji. Będę musiał zalogować się do pliku lub zaktualizować bazę danych lub coś.

Jestem otwarty na inne sposoby zdalnego uruchamiania aktualizacji na hoście, ponieważ wydaje się, że jest to problem, z którym boryka się wiele osób.

Znalazłem kilka dokumentów, które wyjaśniają przesłanie, ale nie podają przyczyny ani obejścia tego problemu.

Zwracana wartość Zwraca S_OK, jeśli się powiedzie. W przeciwnym razie zwraca kod błędu COM lub 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.

Skąd ma wiedzieć, że jestem na komputerze zdalnym?

Po prostu nie możesz tego zrobić, kolego, bo stwardnienie rozsiane nie pozwala ci tego robić przez WUApi.

Szczegóły można znaleźć tutaj: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387288(v=vs.85).aspx

Możesz spróbować użyć Zaplanowanego zadania, aby to zrobić.

Takie polecenie należy uruchomić z uprawnieniami na zdalnym komputerze, skąd należy je uruchomić jako administrator domeny lub administrator na zdalnym komputerze.

Jeśli twój jest pierwszym przypadkiem, nie mam pomocy, ale jesteś tylko lokalnym administratorem, a nie zdalnym, użyj get-credentialtego.

$cred = get-credential

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

Alternatywną i bardziej bezpośrednią formą jest Invoke-Commandprośba o poświadczenia:

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

Udało mi się to uruchomić, konfigurując punkt końcowy JEA na zdalnym serwerze, aby działał jako lokalne konto wirtualne.

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

Lokalne konto wirtualne

Jeśli wszystkie role obsługiwane przez ten punkt końcowy JEA są używane do zarządzania komputerem lokalnym, a konto administratora lokalnego wystarcza do pomyślnego uruchomienia poleceń, należy skonfigurować JEA do korzystania z lokalnego konta wirtualnego. Konta wirtualne to konta tymczasowe, które są unikalne dla konkretnego użytkownika i trwają tylko przez czas trwania ich sesji PowerShell. Na serwerze członkowskim lub stacji roboczej konta wirtualne należą do grupy Administratorzy komputera lokalnego i mają dostęp do większości zasobów systemowych. Na kontrolerze domeny Active Directory konta wirtualne należą do grupy Administratorzy domeny.