none
Automatisch WSUS Updates installieren RRS feed

  • Frage

  • Hallo,

    ich möchte folgendes Script über die Aufgabenplanung starten. Dies funktioniert mit meinem Account (lokaler Admin). Jetzt möchte ich es mittels Dienst-Konto starten. Das Dienstkonto soll aber nicht unbedingt die Rolle lokaler Admin bekommen. Welche Rechte benötigt das Dienstkonto um folgendes Script ausführen zu können?

    try{
    #Define update criteria.
    $Criteria = "IsInstalled=0 and Type='Software'"
    
    #Search for relevant updates.
    $Searcher = New-Object -ComObject Microsoft.Update.Searcher
    $SearchResult = $Searcher.Search($Criteria).Updates
    
    #Download updates.
    $Session = New-Object -ComObject Microsoft.Update.Session
    $Downloader = $Session.CreateUpdateDownloader()
    $Downloader.Updates = $SearchResult
    $Downloader.Download()
    
    #Install updates.
    $Installer = New-Object -ComObject Microsoft.Update.Installer
    $Installer.Updates = $SearchResult
    $Result = $Installer.Install()
    
    #Reboot if required by updates.
    If ($Result.rebootRequired) { shutdown.exe /t 0 /r }
    
    }catch{
      $logSrc="atWsusUpdInstaller"
      Write-EventLog -LogName Application -source $logSrc -EntryType Error -EventId $error.Count -message "$PSItem"
    }
    

    Donnerstag, 1. August 2019 14:04

Antworten

  • https://ss64.com/ps/syntax-elevate.html

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    • Als Antwort markiert Zero3000 Montag, 16. September 2019 08:43
    Donnerstag, 29. August 2019 14:49

Alle Antworten

  • Da gibt es nicht so viele Möglichkeiten:
    Was gibt denn dein Log im Catch-Fall für Fehler aus?
    Fehlen da nicht u.U. Admin-Rechte;-)?
    Es gibt nur User oder Admins. User dürfen eher selten installieren.
    Donnerstag, 1. August 2019 15:33
  • Moin,

    soweit ich weiß, die Standardeinstellungen der betroffenen COM-Komponenten erfordern lokale Adminrechte. Was Du ggfls. machen kannst, um nicht auf jedem Rechner Admin-Credentials zu hinterlegen, ist den obigen Scriptblock remote aufzurufen. 


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 1. August 2019 21:16
  • Für Batchautomatisierungen sind die COM+ Berechtigungen für User häufig deaktiviert.
    Hier kann man dann bei der COM+-Verwaltung noch entsprechende Rechte vergeben.

    https://docs.microsoft.com/en-us/windows/win32/cossdk/automating-com--administration

    Freitag, 2. August 2019 09:20
  • Danke für den Hinweis. Allerdings tue ich mich schwer damit die Komponente bspw. "Microsoft.Update.Session" zu identifizieren, d.h. unter welcher Collection das Objekt zu finden ist. Da ich das C++ Beispiel hier nicht in PowerShell übersetzt bekomme. Für das VB Beispiel findet man im Netz ein PowerShell Analogon, allerdings weiß ich auch hier nicht in welcher Collection ich überhaupt suchen soll oder wie ich von da aus den ICOMAdminCatalog ansteuere. 

    Die Komponente als solche finde ich in der Komponentendienste Konsole nicht.

    BTW: das log liefert im Catch-Fall folgende Ausgabe:

    Ausnahme von HRESULT: 0x80240024

     



    • Bearbeitet Zero3000 Montag, 5. August 2019 14:24
    Montag, 5. August 2019 14:20
  • Ggf. sollte die Standardconfig ausreichend sein.
    Ich finde, das ist hier ganz gut erklärt:
    https://ca-computer-automation.de/opc-dcom-einstellungen/

    Hier muss dann unter Arbeitsplatz halt der User BATCH noch hinzugefügt werden, das sollte für den Taskscheduler ausreichen.

    Für 32-Bit gibts noch einen eigenen Aufruf:
    mmc comexp.msc /32

    Aber auch mit "BATCH" und "Jeder" kann ich z.B. Excel.Application unter Windows 10 unbeaufsichtigt nicht mehr starten. Der Prozess wird zwar aufgerufen, aber die interne COM-Registrirung (ROT Running Objekt Table) erfolgt nicht. Was immer Microsoft da wieder mal gedreht hat.

    Montag, 5. August 2019 16:24
  • Ggf. sollte die Standardconfig ausreichend sein.
    Ich finde, das ist hier ganz gut erklärt:
    https://ca-computer-automation.de/opc-dcom-einstellungen/

    Hier muss dann unter Arbeitsplatz halt der User BATCH noch hinzugefügt werden, das sollte für den Taskscheduler ausreichen.

    Dann gibt man dem Nutzer mehr Rechte als nötig, oder sehe ich das falsch? Hatte den Nutzer unter Komponentendienste -> Computer -> Arbeitsplatz -> Eigenschaften -> COM Sicherheit schon einmal testweise hinzugefügt. Wenn ich dann eine Shell für meinen BATCH-User ausführe und das Script starte kommt wieder

    Ausnahme von HRESULT: 0x80240024
    In Zeile:1 Zeichen:1
    + $Downloader.Download()
    + ~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OperationStopped: (:) [], COMException
        + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException


    Dienstag, 6. August 2019 11:31
  • Da bist du dann doch schon einen Schritt weiter.
    Es lag nicht an der generellen COM-Berechtigung.

    Mit der Funktion Download() wird nun aufs Netzwerk zugegriffen.
    Auf Netzwerk kannst du aber nur zugreifen, wenn du zusätzlich das Kennwort bei unbeaufsichtigter Ausführung speicherst. Ansonsten hat man nur Zugriff auf lokale Ressourcen.

    Dienstag, 6. August 2019 12:54
  • Mit der Funktion Download() wird nun aufs Netzwerk zugegriffen.
    Auf Netzwerk kannst du aber nur zugreifen, wenn du zusätzlich das Kennwort bei unbeaufsichtigter Ausführung speicherst. Ansonsten hat man nur Zugriff auf lokale Ressourcen.

    Daran sollte es aber auch nicht liegen, denn die Option: "Kennwort nicht speichern. Die Aufgabe greift nur auf lokale Computerressourcen zu." ist auch nicht angehakt.
    Mittwoch, 7. August 2019 07:55
  • Wenn ich nach dem Fehler suche gibt es viele Hinweise auf den gestörten Windows-Update.
    Bevor du da also weiter versuchst, prüfe mal ob der Windows Update überhaupt noch funktioniert und wenn nicht, behebe diese Probleme erst mal.

    Mittwoch, 7. August 2019 09:25
  • Danach habe ich natürlich auch gegoogelt. Die Standard Updatefunktion liefert Updates, als auch das Script weiterhin unter einem Admin Account fehlerfrei durchläuft. Wegen Zweiterem dachte ich, wie im Eingangspost erwähnt, man könnte dem Dienstkonto die Rechte so geben, dass man auch ohne lokaler Admin die entsprechenden Funktionen ausführen kann.

    • Bearbeitet Zero3000 Mittwoch, 7. August 2019 12:51
    Mittwoch, 7. August 2019 11:50
  • Hi.

    angenommen ich öffne eine Session via:

    Enter-PSSession -ComputerName $SERVER -Credential $USER

    dann bekomme ich u.s. Fehlermeldung auch wenn der User als lokaler Admin eingetragen ist. der Unterschied zum Sheduledtask liegt hier an dem Häckchen "Mit höchsten Berechtigungen ausführen". Dies kann ich mittels Remote-Session nicht bewerkstelligen zumindest weiß ich nicht wie. Kannst du das bitte genauer erklären.

    Ausnahme beim Aufrufen von "CreateUpdateDownloader" mit 0 Argument(en):  "Zugriff verweigert (Ausnahme von HRESULT: 0x800
    70005 (E_ACCESSDENIED))"

    Donnerstag, 29. August 2019 13:49
  • https://ss64.com/ps/syntax-elevate.html

    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    • Als Antwort markiert Zero3000 Montag, 16. September 2019 08:43
    Donnerstag, 29. August 2019 14:49