mcdaniels

Gerade eben schrieb testperson:

Kann ich mir vorstellen, dass User keinen Bock auf Updates haben..

die Betonung lag auf teilweise... und wo keine ausreichenden Mittel (das ist aber ein anderes Thema)

vor 16 Minuten schrieb testperson:

Benutzer informieren, dass das jetzt so ist und danach gilt halt "Lernen durch Schmerz". Man kann halt nicht immer alles (sinnvoll) technisch lösen.

Haha, danke! You made my day

Auch eine Variante und vlt. hat das ja auch dann einen wirklichen Lerneffekt.

vor 4 Minuten schrieb Nobbyaushb:

Läuftseit Jahren auch mit aktuellen OS einwandfrei bei meiner ehemaligen Firma, hatte heute Kontakt mit dem derzeitigen Admin und habe gefragt

 

das glaube ich sofort. Dort wird vermutlich recht aktuelle Hardware laufen. (Hier sind Clients tlw. 10J+ alt).

Wir müssen jetzt mal evaluieren, ob unsere NICs da überall mitspielen und kompatibel sind usw. dann das ganze konfigurieren (wenn).

Es ist vermutlich (wenn das mit den Skript nicht läuft) eh die einzige Variante, die uns dann noch bleibt. Ich weiß, ich kann es noch 100x sagen, aber ich versteh nicht, weshalb man so eine Funktion entfernt. Aber MS wird das schon genauer wissen.

vor 4 Minuten schrieb zahni:

Wie gesagt: Es geht nicht.

Jep, ich habs jetzt auch aufgegeben bzw. sagen wir mal so: Ich schau noch, ob ich das via Powershell und Shut-Down-Script "bauen" kann.

Hallo,

das mit dem Stichtag funktioniert offenbar. Zumindest hat sich mein Testclient (ohne den User zu informieren) neu gestartet und das Win10 Cumul. Update 10/2023 installiert.

Würde dann aber bedeuten, dass (wäre da was geöffnet gewesen) alles weg wäre. Würde ich das wiederum an ein "nicht neu starten, wenn User angemeldet" koppeln, beißt sich die Katze wieder selbst in den Schwanz.

Das bringt mich wieder auf den Anfang zurück: Die Option "Herunterfahren" müsste einfach immer ein "Herunterfahren und Updates installieren" sein (sofern welche da sind). Ich nehme mit, dass das in der Form nicht mehr funktioniert und ich bestenfalls auf Wake on Lan zurückgreife, was wiederum ganz sicher weitere Probleme auslösen wird (da bin ich mir ziemlich sicher).

Jedenfalls DANKE nochmal.

vor 2 Minuten schrieb testperson:

Bzw. wäre das Stichwort "Wake on LAN".

ok, das hatten wir schon

@testperson sorry, hab dich vorher bei der Danksagung vergessen !

Ich werde wie gesagt noch einiges testen, auch wenn ich dafür kaum Zeit habe.

vor 1 Minute schrieb Nobbyaushb:

Mein ehemaliger Kollege hatte das so eingestellt, das die Clients die Updates Nachts bekommen

Danke, aber leider laufen bei uns die PC in der Nacht nicht.

Vielen Dank an euch alle @Nobbyaushb @Sunny61 @NorbertFe ich werd noch ein paar Dinge testen.

vor 1 Stunde schrieb Sunny61:

 

Dann dürften diese MA doch eigentlich keinen PC bedienen, wenn sie schon das nicht schaffen.

Deshalb hatte ich schon mal Schreibmaschinen vorgeschlagen, kam nicht so gut an.

Der Punkt ist : Der User darf keine Wahl haben und Ende. (Sozusagen)

Sind Updates da und wurden vom Client vom WSUS geholt, muss beim herunterfahren installiert werden. 

Aktuell wird trotz Anzeige von "Updates installieren und Herunterfahren" ein PC bei Herunterfahren abgeschaltet und das Update danach nicht weiter installiert.

vor 7 Minuten schrieb NorbertFe:

abgesehen von Vorgaben der IT, denn die muss man nicht befolgen. Schließlich ist die IT dafür zuständig, dass ich hier einen sicheren pc habe. ;) Ich kann hier nicht den Job der IT übernehmen. 

vor 2 Minuten schrieb NorbertFe:

In welcher Branche bist du denn? 🤔😬😂

in der Branche in der alles strikt vorgegeben werden muss, ohne jemals eine Option offen zu lassen.

vor 9 Minuten schrieb testperson:

jetzt könnte man noch einwerfen, dass WSUS / WU evtl. nicht zu euren Anforderungen passt. Hast du mal in Richtung 3rd Party Patchmanagement / Endpoint Management geschaut?

ich habe PDQ Deploy im Einsatz, das allerdings wiederum nur mit PDQ-Inventory wohl die Dinge machen könnte, die du oben erwähnst. Sind halt wieder Zusatzkosten.

Im Grunde kann man aber wohl sagen: Der WSUS ist -Stand heute- nicht dafür ausgelegt, in einer Umgebung eingesetzt zu werden, in der die PC nicht 24/7 durch laufen und es innerhalb dieses Zeitrahmens keine Leerlaufzeiten gibt, in denen er (WSUS) die Updates installieren könnte und ohne Userinteraktion dann neu startet. Finde ich ehrlich gesagt richtig schwach.

vor 2 Stunden schrieb NorbertFe:

Auch damals (tm) gabs spezialisten, die dann die steckdosenleiste einfach ausgeschaltet haben, weils zu lange gedauert hat oder sie immer als erstes auch den Monitor ausschalten und dann nicht sehen was da noch steht. ;)

ja, aber der Mechanismus selbst war für meine Begriffe und unsere Anforderungen weit besser.

vor 2 Stunden schrieb testperson:

Ich habe es noch nie versucht, aber ggfs. könnte man mit einem Shutdown Script nachhelfen. Evtl. auch einen Task der beim / vorm Herunterfahren triggert. Dann wäre es am Ende egal, ob "Herunterfahren" oder "Aktualisieren und Herunterfahren" geklickt wurde.

Vielleicht schaff ich es ja damit:

https://basic-tutorials.de/ratgeber/software/usoclient/

vor 2 Stunden schrieb Sunny61:

Man sieht ja im WSUS welcher Rechner nach einem Reboot verlangt, bei uns hat es schon geholfen, Spezialisten gezielt anzusprechen, danach kam das nicht mehr vor. ;)

das hilft hier zu 99,9% nicht.

Das Kernproblem ist einerseits die Problematik, dass Updates bei "Herunterfahren" nicht installiert werden und wir beim nächsten Patchday noch nicht mal 50% der "vorhergehenden" Updates installiert haben (Auf den Clients).

Das läuft einfach zu unzuverlässig auf die "Standard-Art-und-Weise". Ist auch eine Frage der Zeit (die ich nicht habe): laufendes prüfen ob die Updates eh installiert werden, wenn nicht, prüfen warum (da ist's halt dann weil der User das ums Verrecken nicht macht), dann das ganze händisch anwerfen, damit überhaupt mal etwas weiter geht.... , weil ich auf gefühlten 1000 Baustellen gleichzeitig aktiv bin (innerhalb eines Betriebs), schaff ich das so einfach nicht.

Und so kommt es dann, dass man etliche ungepatchte Systeme hat....

Für mein Umfeld gibt es nur eine Möglichkeit, bezogen auf die Updateeinspielung und das ist das Zauberwort "Zwang". (leider).

vor 39 Minuten schrieb Sunny61:

Funktioniert bei uns im großen und ganzen recht gut. Am besten auch den Usern mitteilen dass z.B. heute Updates freigegeben worden sind und man bitte beim Herunterfahren an die Updates denken soll.

Danke jedenfalls für deine/eure Hilfe. Ich finde es echt schade, dass das nur so funktioniert und es da immer eine Benutzerinteraktion geben muss. (Das ist nie gut, weil du immer welche dabei hast, die das eben nicht machen, was dann wieder mehr Aufwand bedeutet.) War viel schöner mit Herunterfahren (und dann wurden ganz einfach heruntergeladene Updates installiert).

vor 44 Minuten schrieb Sunny61:

Windows Updates beim Shutdown dürften die User schon selbst hinkriegen, ist normalerweise nur einmal im Monat. ;)

naja, wenn sie mir dann auf "Herunterfahren" klicken ... dann werden ja die Updates wieder nicht installiert, oder verstehe ich da jetzt etwas falsch.

vor 44 Minuten schrieb Sunny61:

Sorry, Arbeitszeit ist die Nutzungszeit. ;)

ok, danke! Hab das jetzt halt von 08:00 bis 15:00 eingestellt und hoffe, dass die Updates dann nach 15:00h installiert werden.

Das wird so aber nie und immer zeitgerecht und kontrolliert funktionieren, da bin ich mir ziemlich sicher. Was MS sich da dabei gedacht  hat, möchte ich auch gerne mal verstehen.

Alles und jeder redet von Nachhaltigkeit (ich weiß, das ist jetzt nicht das Thema) aber man soll die PCs 24/7 laufen haben, obwohl man sie nicht braucht, nur um die Updates nach einem Schema zu installieren, das halt so ist wie es ist.

Echt nicht böse gemeint und nix gegen MS, aber das verstehe ich beim besten Willen nicht.

vor 39 Minuten schrieb Sunny61:

MSFT geht davon aus, dass die Rechner immer alle eingeschaltet sind und sie deshalb die Updates außerhalb einer festgelegten Nutzungszeit installieren können. Also musst Du noch eine Nutzungszeit konfigurieren. Und eine Arbeitszeit von Anfang bis Ende. ;)

Unsere Rechner werden zwischen ca. 06.00 und 10.00 eingeschaltet und können dann theoretisch bis 22.00h laufen (Dienstbetrieb) Das ist vollkommen unterschiedlich.

Es ist unmöglich, dass sie 24/7 laufen.

vor 39 Minuten schrieb Sunny61:

Also musst Du noch eine Nutzungszeit konfigurieren. Und eine Arbeitszeit von Anfang bis Ende. ;)

...und welche GPO ist das nun wieder?

vor 39 Minuten schrieb Sunny61:

Das hier hab ich noch im Angebot:

...das kann ich dann aber nicht in Kombination mit meinen GPOs oben verwenden, oder?

Danke für die Tipps!

vor 39 Minuten schrieb Sunny61:

 

Du könntest die Rechner in der Nacht aufwecken und dann die Updates installieren lassen. Anschließend wieder herunterfahren.

Das ist für Workstations natürlich doof, für Benutzer von Mobil Devices ist es schöner die Auswahl zu haben, ansonsten sitzt man ein paar Minuten da und wartet auf das Ende der Installation.

Wäre eine Möglichkeit, aber das machts dann irgendwie noch komplizierter. Was, wenn die nicht aufwachen, oder es sonstige Troubels gibt etc.

vor 39 Minuten schrieb Sunny61:

as hier hab ich noch im Angebot:

 

Warnbenachrichtigungszeitplan für den automatischen Neustart zur Updateinstallation konfigurieren Aktiviert  

Geben Sie den Zeitraum für Warn-/Erinnerungsbenachrichtigungen über den automatischen Neustart an: Erinnerung (in Stunden):  4 
Geben Sie den Zeitraum für Warnbenachrichtigungen über einen bevorstehenden automatischen Neustart an: Warnung (Min.):  30 
 

Hab ich jetzt mal zusätzlich zu meinen Einstellungen (ganz oben) gesetzt.

Ich denke allerdings dass ich vielleicht einfach auf z.B. PDQ Deploy umsteige... das haben wir eh schon im Einsatz. Dann stampfe ich den WSUS einfach ein und hab dann mit PDQ eventuell mehr Kontrolle.

Nutzungszeit hab ich definiert. 

Arbeitszeit find ich nicht.

Nebenbei erwähnt: Gerade auf die Updatemechanismen sollte man sich verlassen können, .... kann man aber irgendwie auch nicht so recht.

Hab das jetzt wie oben geschrieben umgesetzt. Der Client installiert die Updates (bei einem User der "Standarduser" ist). Danach sieht man unten rechts die Info, dass ein Neustart ausstehend ist. Wenn der User jetzt auf Ausschalten / Herunterfahren geht, schaltet sich der PC/Notebook etc. einfach ab, ohne die Updates zu installieren.

Jetzt hätte ich da rund 150+ Clients im Angebot, die sich vermutlich alle so verhalten. Das ist natürlich ganz toll...... :-/ weil da hat man dann gar keine Kontrolle mehr über die Updates bzw. könnte das dann ja gleich alles händisch machen (da ja eigentlich kein wirklicher Automatismus mehr gegeben ist).

Sofern ich da jetzt nicht irgendwo einen "Bock" in der Konfiguration / GPO habe (siehe oben), verstehe ich nicht ganz, wieso man eine erzwungene Installation beim Herunterfahren einfach entfernt...

vor 31 Minuten schrieb zahni:

Du musst noch ein Wartungsfenster in dieser Zeit definieren. Per Default liegt das, glaube ich, ub 19:00 Uhr. Und es wird meiner Meinung nach nichts nachgeholt. Wenn der PC um 9.00 Uhr noch nicht eingeschaltet ist, klappt es u.U. nicht.

sorry, dass ich da jetzt vermutlich nerve. Aber reden wir jetzt nicht vom Installationszeitpunkt? Weil ich kann ihm ja da nur sagen, dass er zum Zeitpunkt X installieren soll und zusätzlich dazu "Während der automatischen Wartung" anhaken.

Falls nein: Welche GPO meinst du da?

EDIT: Du meinst Computerkonfiguration>Richtlinien>Administrative Vorlagen>Windows-Komponenten>Wartungszeitplan

So, ich hab jetzt mal bei der Richtlinie für die "Aktivierungsgrenze für die automatische Wartung 12:00" eingestellt und "Richtlinie für die Aktivierung der automatischen Wartung " auf aktiviert gesetzt.

Mal schauen, was jetzt passiert...

Gerade eben schrieb zahni:

Ganz kurz und allgemein: Das ging zum letzten Mal bei Windows XP. Danach hat Microsoft den Update-Client "verbessert".

Eigentlich kann man die Updates nur noch mittags im Hintergrund installieren. Dann werden sie beim Herunterfahren auch aktiviert.

Hi Zahni, danke für die Info.

hm...dann müssten meine Settings ja passen mit 09:00h, oder sehe ich das dann falsch?

vor 10 Minuten schrieb q617:

Warum keine moderne Cloud-Lösung?

?

Hallo zusammen,

ich denke, ich hab irgendwo einen Konfigurations- und/oder Denkfehler in meinem Setup.

Server 2019 (WSUS)

Windows 10 Pro Clients

Erreichen will ich, dass der User spätestens beim Herunterfahren gezwungen wird, Updates installieren zu lassen, sofern Updates da sind. Wie ich soeben fest stellen musste, funktioniert das nicht so wie ich will.

Folgende Einstellungen sind konfiguriert:

• Erinnerungsbenachrichtigungen über den automatischen Neustart zur Updateinstallation: Aktiviert - 60 Minuten
• Erforderliche Benachrichtigung für automatischen Neustart zur Updateinstallation konfigurieren: Aktiviert - 2 Benutzeraktion
• Automatische Updates konfigurieren: 4 - autom. herunterladen und lt. Zeitplan installieren (Installzeit 09:00h)
• Internen Pfad für MS Update angeben: Aktiviert: entspr. WSUS Einstellungen (funktioniert alles)
• Suchhäufigkeit: 2h
• Zugriff auf Updates aussetzen entfernen : Aktiviert
• Wechsel zum erzwungenen Neustart und Benachrichtigungsplan für Updates festlegen: Aktiviert
  • Qualitätsupdates: Wechsel 3 Tage, Verzögern 1 Tag, Frist: 0 Tage (inaktiv) 
  • Funktionsupdate: Wechsel 2 Tage, Verzögern 2 Tage, Frist: 0 Tage (inaktiv)

• Automatische Updates sofort installieren: Aktiviert
• Kein autom. Neustart für geplante Installationen autom. Updates durchführen, wenn Benutzer angemeldet sind: Aktiviert
• Erneut zu einem Neustart für geplante Installation auffordern: Aktiv - 120 Minuten
• Zeitplan für geplante Installationen neu erstellen: Aktiviert - Wartezeit : 5 Minuten
• Anzeigeoptionen für Updatebenachrichtigungen: Aktiviert - 0 Standardmäßige Benachrichtigung
• Option Updates installieren und Herunterfahren im Dialogfeld "Windows herunterfahren" nicht anzeigen: Aktiviert
• Automatische Updates konfigurieren: 4 - autom. herunterladen und lt. Zeitplan installieren
  • Tag: Täglich
  • Zeit: 09:00h
  • Während der autom. Wartung installieren : angehakt
  • Updates für andere MS Produkte installieren: aktiv
• Die Standardoption "Updates installieren und herunterfahren" im Dialogfeld "Windows herunterfahren" nicht anpassen: Nicht konfiguriert

Wie müsste man die GPO anpassen, dass Updates spätestens beim Herunterfahren installiert werden, ohne dass der User auch nur irgendeine Möglichkeit hat, die Updates nicht zu installieren.

Ich dachte ja, dass die Option:

• Updates installieren und Herunterfahren im Dialogfeld "Windows herunterfahren" nicht anzeigen: Aktiviert

bedeutet, dass der User dann nur auf Neustart oder Herunterfahren gehen kann und Updates (wenn vorhanden) gezwungenermaßen installiert werden. Scheint aber nicht so zu sein.

Danke jedenfalls schon mal!

Es sieht nun wie folgend aus:

Ich habe den Task angepasst.

Trigger: Jeden Tag um 06:00h, täglich

Aktion: Programm starten: "c:\Program Files\Fortinet\FortiClient\update_task.exe"

Argumente hinzufügen (optional): -s vd_01

Einstellungen angehakt:

Ausführung bei Bedarf zulassen 

Aufgabe so schnell wie möglich nach einem verpassten Start ausführen

Falls Aufgabe scheitert, neu starten alle: 10 Minuten

Neustartversuche max: 1x 

Aufgabe beenden, falls Ausführung länger: 1h

Beenden der aktiven Aufgabe erzwingen, falls sie auf Aufforderung nicht beendet wird

und

Keine neue Instanz starten, falls bereits ausgeführt.

Die Umleitung der Ausgabe via > c:\update.log hat nie funktioniert, weshalb ich selbige raus genommen hab. 

Wenn ich am Client den Task auslöse (im Taskplaner) sehe ich im Forticlient, dass Updates gesucht werden. D.h. der Task funktioniert.

Ich hoffe nun, dass mir die Clients nach dem hochfahren checken, dass  - wenn der Task um 06.00h nicht ausgeführt wurde - dieser eben so schnell wie möglich nachgeholt wird und im Fehlerfall dann noch 1x versucht wird den Task auszuführen.

Grund für die ganze Übung ist, dass der liebe Forticlient zwar schon Updates sucht, dies aber in der  Regel sehr stark verzögert (nach dem Systemstart) stattfindet. Dies wiederum löst das Windows  Security Center aus mit der Meldung "Dass der AV nicht mehr aktuell" ist. Ich hoffe nun, dass die Updates der Clients durch den Task kurz nach dem Client-Start erfolgen und somit diese Meldung unterbleibt.

Der Fortinetsupport war bislang übrigens keine große Hilfe.

Danke für eure Hilfe!

vor 50 Minuten schrieb cj_berlin:

Mach's einfach als SYSTEM. Wenn Du das ganze z.B. für SCCM paketieren würdest, müsste das Paket auch als SYSTEM laufen.

Ich hab das jetzt (wie oben erwähnt) als GPO aktiv als Task mit User SYSTEM / Befehlszeile: "c:\Program Files\Fortinet\FortiClient\update_task.exe" -s vd_01 > fortiupdate_av.log

Es wird mir am Client zwar keine fortiupdate_av.log erstellt. Der Task ist aber am Client angekommen.

lt. gpresult (scope Computer) scheint die Aufgabe jedenfalls anzukommen.

Es wird mir sogar in der Aufgabenplanung angezeigt (am Client)

Ergebnis ist allerdings 0x41301 (Task läuft schon..)

Mal weiter suchen...

vor 1 Stunde schrieb cj_berlin:

Du kannst ja seit gefühlt 7 Jahren (und genauer seit Mai 2014 - da siehst Du, wie die Gefühle trügen bei einem alten Mann ) in GPOs keine Passwörter mehr speichern. Das heißt, ein Schtask mit einem benannten User kann nur unter der Voraussetzung laufen, dass dieser User interaktiv angemeldet ist. 

Naja, da warst du eh nicht so knapp daneben.  Somit kann ich das knicken.

vor 1 Stunde schrieb BOfH_666:

Richtig. Das Ergebnis wäre aber das gleiche. Wenn der Client noch nicht installiert ist, schlägt der Task eben fehl. ¯\_(ツ)_/¯

 

Fehlschläge mag ich nicht Ne, Scherz bei Seite, ich wollt's halt abfragen, aber wenn es nicht sein muss, ist's auch gut.

vor 1 Stunde schrieb cj_berlin:

Kann man SYSTEM nicht verwenden, kannst Du gMSA nehmen, da ist es aber ein wenig fummelig, die Policy zu erstellen, da der Editor gMSA nicht auswählen lässt.

Hm, schau ich mir mal an, danke!

Melde mich mit dem Ergebnis.

vor 1 Minute schrieb BOfH_666:

Welcher User ist das? Üblicherweise nimmt man hier den lokalen Built-In User "SYSTEM"

 

Das ist in dem Fall unser "Deployuser" der Adminrechte hat. Ich stell das mal auf System um.

vor 6 Minuten schrieb BOfH_666:

Hast Du den ndafür gesorgt, dass das Batchfile auf dem Computer auf existiert? 

hätte ich erwähnen müssen, ich hab den UNC Pfad zum Skript angegeben (im Task) und den Ordner wo es drinnen liegt für alle (lesbar) freigegeben. Getestet von den Clients.

vor 11 Minuten schrieb BOfH_666:

Ich würde mir das Leben leichter machen und einfach die "update_task.exe" als Task ausführen - nicht das Script.  ¯\_(ツ)_/¯

 

Ok, dann würde mir aber die Abfrage wegfallen, ob denn der "Forticlient" auf den PCs etc. installiert ist. (Momentan ist das noch nicht überall der Fall), wäre aber sicher einfacher.

Dann bräuchte ich das Scirpt gar nicht mehr und würde mir allerdings auch die Verrenkung ersparen, dass ich das Script von den Clients aus zugänglich machen muss. Werde darüber nachdenken.

Grundsätzliche Frage: Müsste ich den geplanten Task der via GPO an die Clients geht nicht in deren Taskplaner sehen?

Danke für  deine Hilfe!

Guten Morgen,

ich will  bzw. (in dem Fall) muss einen Updatetask (für einen Virenschutz) eine Minute verzögert (nach Anmeldung) ausführen.  Dieser Updatetask muss als Admin ausgeführt werden. Hierfür gibt es ein Batchfile, das ich erstellt habe.

@echo off
set file="c:\Program Files\Fortinet\Forticlient\Forticlient.exe"

if not exist %file% (
exit   
) Else (

cd "c:\Program Files\Fortinet\Forticlient"
update_task.exe -s vd_01 >c:\fortiupdate.log
)

Damit ich die Möglichkeit habe, dass das Batchfile als Administrator ausgeführt wird (bitte korrigiert mich), zu lassen hab ich es via GPO:

• Computerkonfig -> Einstellungen -> Systemeinstellungen -> geplante Aufgaben -> geplante Aufgabe (min Win7) eingebunden.
• Ausführen als: User mit Adminrechten
• unabhängig von der Benutzeranmeldung ausführen
• Mit höchsten Berechtigungen ausführen
• Trigger: Bei Anmeldung (Jeder Benutzer)
• Aufgabe verzögern für: 1 Minute

Ich sehe auch, dass die GPO entsprechend umgesetzt wird (GPRESULT /Scope Computer), allerdings wird das Batchfile offenbar nicht ausgeführt, denn ich müsste (wenn es läuft) auf den PCs unter c:\ ein logfile sehen (fortiupdate.log).

Fragen dazu:

Ist die Vorgangsweise grundsätzlich korrekt?

Gehe ich recht in der Annahme, dass das File bei Ausführung auf C:\ abgelegt werden müsste (auch wenn es via Computerkonfiguration läuft). Sollte ja unerheblich sein.

Starte ich das Batchfile (als Admin) lokal auf einem Client läuft es problemlos.

Im Eventlog (auf den Clients) sehe ich unter Anwendungs- und Dienstprotokolle / Windows / Taskscheduler mein Batchfile nirgendwo...

Danke euch!