Jump to content

mcdaniels

Premium Member
  • Gesamte Inhalte

    1.840
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von mcdaniels

  1. die Betonung lag auf teilweise... und wo keine ausreichenden Mittel (das ist aber ein anderes Thema)
  2. Haha, danke! You made my day Auch eine Variante und vlt. hat das ja auch dann einen wirklichen Lerneffekt.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. in der Branche in der alles strikt vorgegeben werden muss, ohne jemals eine Option offen zu lassen.
  10. 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.
  11. ja, aber der Mechanismus selbst war für meine Begriffe und unsere Anforderungen weit besser. Vielleicht schaff ich es ja damit: https://basic-tutorials.de/ratgeber/software/usoclient/ 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).
  12. 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).
  13. naja, wenn sie mir dann auf "Herunterfahren" klicken ... dann werden ja die Updates wieder nicht installiert, oder verstehe ich da jetzt etwas falsch. 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.
  14. 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. ...und welche GPO ist das nun wieder? ...das kann ich dann aber nicht in Kombination mit meinen GPOs oben verwenden, oder? Danke für die Tipps! Wäre eine Möglichkeit, aber das machts dann irgendwie noch komplizierter. Was, wenn die nicht aufwachen, oder es sonstige Troubels gibt etc. 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.
  15. 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...
  16. 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...
  17. Hi Zahni, danke für die Info. hm...dann müssten meine Settings ja passen mit 09:00h, oder sehe ich das dann falsch?
  18. 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!
  19. 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!
  20. 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...
  21. Naja, da warst du eh nicht so knapp daneben. Somit kann ich das knicken. Fehlschläge mag ich nicht Ne, Scherz bei Seite, ich wollt's halt abfragen, aber wenn es nicht sein muss, ist's auch gut. Hm, schau ich mir mal an, danke! Melde mich mit dem Ergebnis.
  22. Das ist in dem Fall unser "Deployuser" der Adminrechte hat. Ich stell das mal auf System um. 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. 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!
  23. 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!
×
×
  • Neu erstellen...