Hallo Support-Forum,
kann mir mal jemand bitte die grundsätzliche Funktionsweise des Patchmanagement erklären?
Beim Aufruf des Patchmanagements wird als erstes geprüft, ob die aktuelle PM2Client.exe auf dem PC vorhanden ist. Falls nein, wird die aktuelle nach C:\Programme\Gemeinsame Dateien\Setup32 kopiert und gestartet. Soweit ist alles klar.
ABER: Woher erhält die PM2Client.exe die Informationen, welche Patches es überhaupt gibt? Auf dem Empirum-Server habe ich mal die geöffneten Dateien verfolgt. Es sieht so aus als öffnet der Client jedes einzelne Patchpaket. Da dies aber gepackt ist (.gz) müsste dies doch bedeuten, dass jeder PatchClient alle Patches auf dem Server "durchsucht", entpackt, in das Paket reinschaut und ggf. installiert.
Ist das richtig so?
Danke Euch schon mal im Voraus.
Gruß
Langer
Patchmanagement (grundsätzliches)
Moderators: MVogt, moderators
Patchmanagement (grundsätzliches)
Stadt Frankfurt am Main (Amt 51)
Ganz grob nur beschrieben:
Die *.gz Dateien sind nicht die Patches sondern nur die Steuerdateien. Und es ist eine Abstufung drin, also es werden nur die Steuerdateien gelesen, die auf das OS und eventuelle Applikationen passen (z.B. Office) Das passiert nach unten mehrstufig (über Selektion der Sprache, der Version, etc.) bis zur eigentlichen Patchdefinition - welche Kriterien also geprüft werden müssen (Reg-Key, Dateiversion, ...) Wird auf diesem Weg ein Patch als fehlend ermittelt, schreibt PM2Client.exe die GUID in die Registry, kopiert dann den entsprechenden Patch selbst nach lokal und installiert diesen.
Die *.gz Dateien sind nicht die Patches sondern nur die Steuerdateien. Und es ist eine Abstufung drin, also es werden nur die Steuerdateien gelesen, die auf das OS und eventuelle Applikationen passen (z.B. Office) Das passiert nach unten mehrstufig (über Selektion der Sprache, der Version, etc.) bis zur eigentlichen Patchdefinition - welche Kriterien also geprüft werden müssen (Reg-Key, Dateiversion, ...) Wird auf diesem Weg ein Patch als fehlend ermittelt, schreibt PM2Client.exe die GUID in die Registry, kopiert dann den entsprechenden Patch selbst nach lokal und installiert diesen.
Jens Beimel
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Danke für die schnelle Antwort.
Wenn ich mir vorstelle, dass derzeit bei einem Windows XP PC mit Office ca. 100 Patches verfügbar sind und die PM2Client.exe sämtliche Steuerdateien auf dem Server anfasst und das mal 1300 PCs .... dann verstehe ich nun endlich, warum beim Patchen der Clients diese Woche unser Netz fast lahm gelegt wurde...
Wenn ich mir vorstelle, dass derzeit bei einem Windows XP PC mit Office ca. 100 Patches verfügbar sind und die PM2Client.exe sämtliche Steuerdateien auf dem Server anfasst und das mal 1300 PCs .... dann verstehe ich nun endlich, warum beim Patchen der Clients diese Woche unser Netz fast lahm gelegt wurde...
Stadt Frankfurt am Main (Amt 51)
sämtliche notwendigen Steuerdateien 
Bei 1300 Clients ist eine Überlegung in Richtung Depotserver und zeitversetztem Lauf des Patchmanagements eventuell eine Möglichkeit.
Bei 1300 Clients ist eine Überlegung in Richtung Depotserver und zeitversetztem Lauf des Patchmanagements eventuell eine Möglichkeit.
Jens Beimel
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Principal Consultant
Matrix42 AG
info@matrix42.de
http://www.matrix42.de
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 AG.
Hi,
um die Situation etwas zu entschärfen würde ich alle Patches rauswerfen, die Sie nicht brauchen. Wenn Sie z.B. nur XPSP2 ausrollen können sie alles vor SP2 wegschmeissen. Wenn Sie kein Englisches OS einsetzen, dann brauchen Sie auch die Englische Sprache nicht. Ich sehe immer wieder , dass die Kunden "blind" alles runterladen und zuweisen.
Sie können auch mal über die Aktivierung von Tokens nachdenken. Dadurch wird die gleichzeitige Anzahl von Paket-Installationen begrenzt. In Summe muss natürlich die gleiche Menge Daten
übers Netz, es verteilt sich aber besser.
Je nachdem wie Ihre Umgebung (z.B. unterschiedliche Gebäude) aufgebaut ist, können Depotserver die Last ebenfalls sehr gut verteilen. Hierzu sollten Sie sich aber unbedingt mal beraten lassen.
Bitte prüfen Sie doch auch einmal, ob sie den Empirumserver besser an das Netz anbinden können, z.B. GBit Switch, sofern der Server noch mit 100 MBit angebunden ist, oder auch 2 geteamte GBit NICs kommen in Frage. Wie Sieht die CPU-Last des Servers in solchen "Ballungszeiten" aus Welche Last hat der SQL-Server? Manchmal wirken etwas gestreckte Intervalle bei den Empirum Services Wunder. Fast niemand benötigt auf 15 sec. genaue Logs oder Inventardaten...
nur so als Anregung für den PM-Client:
was mich am PM-Client stört ist, das die Prüfung halt recht lange dauert. Je mehr Patches im PM drin sind desto länger.
Der PM-Client prüft jedesmal alles ab, auch wenn sich an der Patch-Klasse zwischenzeitlich nichts geändert hat.
Könnte man die Klassen nicht mit einer Checksumme versehen und die Checksumme beim ersten Lauf mit auf den Client kopieren? Beim nächsten Lauf dann erstmal prüfen ob sich die Checksumme geändert hat. Wenn Nein, dann kann der PM Client sich gleich wieder schlafen legen, wenn doch wird halt losgelegt und zum Schluss die neue Checksumme kopiert.
Das Zweite was mich stört ist die Präsenz des PM-Clients. Klar, man kann ihn silent machen, aber dann merkt der User nicht mehr das was auf seiner Maschine passiert. Wie wäre es denn mit einem Taskbar Modus? PBackup macht es vor wies funktionieren könnte.
Gruss,
Micha.
um die Situation etwas zu entschärfen würde ich alle Patches rauswerfen, die Sie nicht brauchen. Wenn Sie z.B. nur XPSP2 ausrollen können sie alles vor SP2 wegschmeissen. Wenn Sie kein Englisches OS einsetzen, dann brauchen Sie auch die Englische Sprache nicht. Ich sehe immer wieder , dass die Kunden "blind" alles runterladen und zuweisen.
Sie können auch mal über die Aktivierung von Tokens nachdenken. Dadurch wird die gleichzeitige Anzahl von Paket-Installationen begrenzt. In Summe muss natürlich die gleiche Menge Daten
übers Netz, es verteilt sich aber besser.
Je nachdem wie Ihre Umgebung (z.B. unterschiedliche Gebäude) aufgebaut ist, können Depotserver die Last ebenfalls sehr gut verteilen. Hierzu sollten Sie sich aber unbedingt mal beraten lassen.
Bitte prüfen Sie doch auch einmal, ob sie den Empirumserver besser an das Netz anbinden können, z.B. GBit Switch, sofern der Server noch mit 100 MBit angebunden ist, oder auch 2 geteamte GBit NICs kommen in Frage. Wie Sieht die CPU-Last des Servers in solchen "Ballungszeiten" aus Welche Last hat der SQL-Server? Manchmal wirken etwas gestreckte Intervalle bei den Empirum Services Wunder. Fast niemand benötigt auf 15 sec. genaue Logs oder Inventardaten...
nur so als Anregung für den PM-Client:
was mich am PM-Client stört ist, das die Prüfung halt recht lange dauert. Je mehr Patches im PM drin sind desto länger.
Der PM-Client prüft jedesmal alles ab, auch wenn sich an der Patch-Klasse zwischenzeitlich nichts geändert hat.
Könnte man die Klassen nicht mit einer Checksumme versehen und die Checksumme beim ersten Lauf mit auf den Client kopieren? Beim nächsten Lauf dann erstmal prüfen ob sich die Checksumme geändert hat. Wenn Nein, dann kann der PM Client sich gleich wieder schlafen legen, wenn doch wird halt losgelegt und zum Schluss die neue Checksumme kopiert.
Das Zweite was mich stört ist die Präsenz des PM-Clients. Klar, man kann ihn silent machen, aber dann merkt der User nicht mehr das was auf seiner Maschine passiert. Wie wäre es denn mit einem Taskbar Modus? PBackup macht es vor wies funktionieren könnte.
Gruss,
Micha.
-
Hendrik_Ambrosius
- Moderator
- Posts: 7965
- Joined: 13. Dec 2004, 23:10
- Location: Adendorf/Lüneburg
Für den neuen Advanced-Agent (Sommer 2007) ist so eine Taskbar-Info geplant.
Hendrik Ambrosius / Senior Presales Consultant
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 GmbH | Elbinger Straße 7 | 60487 Frankfurt am Main | Germany | www.matrix42.com
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 or of the support team.
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 GmbH | Elbinger Straße 7 | 60487 Frankfurt am Main | Germany | www.matrix42.com
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 or of the support team.
@Trickser: Erst mal vielen Dank für die vielen Tipps.
Wir synchronisieren natürlich nur die benötigten Updates (Deutsch, Windows XP und Office 2003 .. mehr nicht).
Hardware-technisch dürfte der Server keine Probleme bereiten (HP DL 380 G4, Dual Xeon, 4 GB Ram, geteamter 2 GBit/s Anschluss). Ansonsten flaches Netz, alle Liegenschaften mit 100 MBit/s angebunden. Der Backbone mit GBit/s.
Der Tipp mit den Intervallen der Empirum-Services ist gut. Wir haben derzeit alles auf dem Standard stehen (15 Sekunden). Was wäre denn da so eine Empfehlung?
Insbesondere der Activation Dienst hatte eine sehr hohe CPU-Auslastung letzte Woche.
Bezüglich Depotserver verweise ich auf die Aussage des Empirum-Consulters, der uns bei der Implementierung beriet: "Bei den paar Clients (derzeit 1300) und dem geswitchten 100 MBit/s Netz wäre das nicht erforderlich!"
Gruß
Klaus
Wir synchronisieren natürlich nur die benötigten Updates (Deutsch, Windows XP und Office 2003 .. mehr nicht).
Hardware-technisch dürfte der Server keine Probleme bereiten (HP DL 380 G4, Dual Xeon, 4 GB Ram, geteamter 2 GBit/s Anschluss). Ansonsten flaches Netz, alle Liegenschaften mit 100 MBit/s angebunden. Der Backbone mit GBit/s.
Der Tipp mit den Intervallen der Empirum-Services ist gut. Wir haben derzeit alles auf dem Standard stehen (15 Sekunden). Was wäre denn da so eine Empfehlung?
Insbesondere der Activation Dienst hatte eine sehr hohe CPU-Auslastung letzte Woche.
Bezüglich Depotserver verweise ich auf die Aussage des Empirum-Consulters, der uns bei der Implementierung beriet: "Bei den paar Clients (derzeit 1300) und dem geswitchten 100 MBit/s Netz wäre das nicht erforderlich!"
Gruß
Klaus
Stadt Frankfurt am Main (Amt 51)
Hi,
der Activation Service ist der der sicherlich am "spontansten" reagieren soll/muss, weil es sonst doch relativ lang dauert bis die Aktivierungsaktionen aus der DB in das Filesystem geschrieben wurden.
Deshalb würde ich hier zuletzt drehen, ggf. das Intervall auf 30 sec. erhöhen.
Unkritisch sind aus meiner Sicht die Intervalle für Inventory und SWDepot Log. Für den Regelbetrieb sollten hier Werte zwischen 120 und 300 absolut ausreichen. Wenn man temporär mal kürzere Intervall braucht, kann man das ja immer noch zeitlich begrenzt runterschrauben.
PM braucht sicher auch nicht alle Nase lang zu prüfen ob sich in der Konfig irgendwas geändert hat, da würde ich vielleicht noch höhere Werte nehmen.
WOL würde ich nicht anpacken.
Kannst du auch mal den SQLServer-Prozess überwachen (Lokale Installation?) Wie ist der denn ausgelastet. Ich geh mal davon aus, dass ihr einen vollwertigen SQL einsetzt und nicht die MSDE...
Wie habt ihr das mit dem PXE geregelt (Modus?) und wie ist die Segmentierung des Netzes (Alle Clients in einem Netz?, werden IP-Helper verwendet, IP-Vergabe statisch?)
Wenn du "flaches Netz" schreibst und du damit Class B oder so meinst, dann wäre u.U. die Einstellung "PXE Only" aus meiner Erfahrung raus (schon woanders hier diskutiert) suboptimal. Lass mal den Debugviewer mitlaufen wenn die meisten MA schon da sind und die Rechner oben haben. Schätz mal ein, ob der PXE dann immer noch sehr oft meldet.
Mal abseits der Services - Wie ist der Agent vom Polling (K=?) her eingerichtet.
Gruss,
Michi.
der Activation Service ist der der sicherlich am "spontansten" reagieren soll/muss, weil es sonst doch relativ lang dauert bis die Aktivierungsaktionen aus der DB in das Filesystem geschrieben wurden.
Deshalb würde ich hier zuletzt drehen, ggf. das Intervall auf 30 sec. erhöhen.
Unkritisch sind aus meiner Sicht die Intervalle für Inventory und SWDepot Log. Für den Regelbetrieb sollten hier Werte zwischen 120 und 300 absolut ausreichen. Wenn man temporär mal kürzere Intervall braucht, kann man das ja immer noch zeitlich begrenzt runterschrauben.
PM braucht sicher auch nicht alle Nase lang zu prüfen ob sich in der Konfig irgendwas geändert hat, da würde ich vielleicht noch höhere Werte nehmen.
WOL würde ich nicht anpacken.
Kannst du auch mal den SQLServer-Prozess überwachen (Lokale Installation?) Wie ist der denn ausgelastet. Ich geh mal davon aus, dass ihr einen vollwertigen SQL einsetzt und nicht die MSDE...
Wie habt ihr das mit dem PXE geregelt (Modus?) und wie ist die Segmentierung des Netzes (Alle Clients in einem Netz?, werden IP-Helper verwendet, IP-Vergabe statisch?)
Wenn du "flaches Netz" schreibst und du damit Class B oder so meinst, dann wäre u.U. die Einstellung "PXE Only" aus meiner Erfahrung raus (schon woanders hier diskutiert) suboptimal. Lass mal den Debugviewer mitlaufen wenn die meisten MA schon da sind und die Rechner oben haben. Schätz mal ein, ob der PXE dann immer noch sehr oft meldet.
Mal abseits der Services - Wie ist der Agent vom Polling (K=?) her eingerichtet.
Gruss,
Michi.
Hi again,
also ich habe jetzt mal folgende Intervalle gnadenlos
gesetzt:
Inventory: 900
SWDepotLog: 600
Activation: 15
WOL: 60
Patchmanagement: 1800
Wir haben in der Tat derzeit noch ein flaches Klasse-B Netz. In den nächsten Wochen und Monaten werden wir aber komplett auf Subnetting umstellen. IPs gibt es per DHCP und in Empirum ist "nur PXE" ausgewählt.
Ich habe jetzt folgendes für diese Woche geplant:
Jeden Tag werden 2 Liegenschaften für das PM aktiviert und somit die Last gesteigert. Dabei werde ich jeweils die Last auf dem Server beobachten. D.h. Ende der Woche legen dann alle los. Ich werde auf jeden Fall über das Ergebnsi berichten.
Ja, vollwertiger SQL 2000 und die Pollingintervalle sind /K10800
Gruß
Klaus
also ich habe jetzt mal folgende Intervalle gnadenlos
gesetzt:Inventory: 900
SWDepotLog: 600
Activation: 15
WOL: 60
Patchmanagement: 1800
Wir haben in der Tat derzeit noch ein flaches Klasse-B Netz. In den nächsten Wochen und Monaten werden wir aber komplett auf Subnetting umstellen. IPs gibt es per DHCP und in Empirum ist "nur PXE" ausgewählt.
Ich habe jetzt folgendes für diese Woche geplant:
Jeden Tag werden 2 Liegenschaften für das PM aktiviert und somit die Last gesteigert. Dabei werde ich jeweils die Last auf dem Server beobachten. D.h. Ende der Woche legen dann alle los. Ich werde auf jeden Fall über das Ergebnsi berichten.
Ja, vollwertiger SQL 2000 und die Pollingintervalle sind /K10800
Gruß
Klaus
Stadt Frankfurt am Main (Amt 51)
Hi,
das Intervall für den Agent dürfte komfortabel sein.
Für den PXE würde ich dir vorschlagen den auf den Kompatibilitätsmodus umzustellen und parallel dazu im DHCP 2 Sachen machen:
Option 60 erstellen und mit dem String PXEClient als Value besetzen.
Dann der etwas "kryptische" Teil:
Seit PFPR2 gibts im AddOns-Verzeichnis ein Tool Option43Generator.
Dort die IP des PXE/TFTP (also wahrscheinlich des Empirumservers) eintragen. Den dort generierten Binären Array im DHCP in die Option 43 eintragen.
Damit erreichst du u. anderem dass du spätzer keine zusätzlichen IP-Helper für Empirum in den Routern konfigurieren musst, ausserdem kriegst du damit die Broadcasts deutlich reduziert Der Client kann den PXE direkt fragen und muss keinen Broadcast machen, der PXE kann direkt antworten, denn er kennt die IP des Clients.
Ich habe ausserdem die Beobachtung gemacht, dass dadurch dann auch der PXE insgesamt deutlich entlastet wird, da nicht so viele DHCP-Requests von ihm beantwortet werden müssen und er damit sinnloser Weise auf die Datenbank zugreift. Bei 1300 Clients läuft ja dauernd irgendwo eine Lease ab und allein das sorgt schon wieder für eine Abfrage in der Datenbank.
Gruss,
Micha.
das Intervall für den Agent dürfte komfortabel sein.
Für den PXE würde ich dir vorschlagen den auf den Kompatibilitätsmodus umzustellen und parallel dazu im DHCP 2 Sachen machen:
Option 60 erstellen und mit dem String PXEClient als Value besetzen.
Dann der etwas "kryptische" Teil:
Seit PFPR2 gibts im AddOns-Verzeichnis ein Tool Option43Generator.
Dort die IP des PXE/TFTP (also wahrscheinlich des Empirumservers) eintragen. Den dort generierten Binären Array im DHCP in die Option 43 eintragen.
Damit erreichst du u. anderem dass du spätzer keine zusätzlichen IP-Helper für Empirum in den Routern konfigurieren musst, ausserdem kriegst du damit die Broadcasts deutlich reduziert Der Client kann den PXE direkt fragen und muss keinen Broadcast machen, der PXE kann direkt antworten, denn er kennt die IP des Clients.
Ich habe ausserdem die Beobachtung gemacht, dass dadurch dann auch der PXE insgesamt deutlich entlastet wird, da nicht so viele DHCP-Requests von ihm beantwortet werden müssen und er damit sinnloser Weise auf die Datenbank zugreift. Bei 1300 Clients läuft ja dauernd irgendwo eine Lease ab und allein das sorgt schon wieder für eine Abfrage in der Datenbank.
Gruss,
Micha.
Hi @Trickser,
meinst du mit Kompatibilitätsmodus in der DBUtil unter Dienste konf. den PXE umstellen auf PXE/DHCP? Soviel ich mich erinnern kann steht bei uns der eintrag auf NUR PXE (@Langer berichtige mich wenn ich jetzt was falsches sage). Bei der Implementierung wurde uns vom M42 Consulter diese Option abgeraten und gesagt, dass PXE/DHCP nur eingestellt werden soll/darf wenn der PXE der gleiche ist wie der DHCP, dies ist nicht der Fall.
meinst du mit Kompatibilitätsmodus in der DBUtil unter Dienste konf. den PXE umstellen auf PXE/DHCP? Soviel ich mich erinnern kann steht bei uns der eintrag auf NUR PXE (@Langer berichtige mich wenn ich jetzt was falsches sage). Bei der Implementierung wurde uns vom M42 Consulter diese Option abgeraten und gesagt, dass PXE/DHCP nur eingestellt werden soll/darf wenn der PXE der gleiche ist wie der DHCP, dies ist nicht der Fall.
Hi @NKurzweg,
Nein, ich meine nicht PXE/DHCP, sondern den Kompatibilitätsmodus im DBUtil.
Bei PXE/DHCP spielt Empirum den DHCP und antwortet nur an bekannte IP-Adressen. Dieser Modus ist als "Notnagel" für eigentlich DHCP-lose Umgebungen gedacht, ich hab ihn aber bisher noch nie verwenden müssen.
(Man berichtige mich, wenn ich da falsch liege).
Gruss,
Micha.
Nein, ich meine nicht PXE/DHCP, sondern den Kompatibilitätsmodus im DBUtil.
Bei PXE/DHCP spielt Empirum den DHCP und antwortet nur an bekannte IP-Adressen. Dieser Modus ist als "Notnagel" für eigentlich DHCP-lose Umgebungen gedacht, ich hab ihn aber bisher noch nie verwenden müssen.
(Man berichtige mich, wenn ich da falsch liege).
Gruss,
Micha.
-
Hendrik_Ambrosius
- Moderator
- Posts: 7965
- Joined: 13. Dec 2004, 23:10
- Location: Adendorf/Lüneburg
Genau. Kann aber auch gut dafür benutzt werden, wenn Empirum parallel zu einem anderen Tool läuft, das auch PXE nutzt. So kommen sich die beiden nicht ins Gehege.
Hendrik Ambrosius / Senior Presales Consultant
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 GmbH | Elbinger Straße 7 | 60487 Frankfurt am Main | Germany | www.matrix42.com
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 or of the support team.
Mobile: +49 172 408 4447 | hendrik.ambrosius@matrix42.com
Matrix42 GmbH | Elbinger Straße 7 | 60487 Frankfurt am Main | Germany | www.matrix42.com
Disclaimer: I participate in this forum on a voluntary basis. Views expressed are not necessarily those of Matrix42 or of the support team.
So, wie versprochen nun der "Abschlussbericht" 
Um es kurz zu machen: Läuft alles gut. Derzeit läuft das Patchmanagement bei jedem Client täglich einmal. Zwar ist während der Stoßzeiten (zwischen 8 und 9 Uhr) die Netzwerklast auf dem Server hoch, aber noch nicht im kritischen Bereich.
Der von Matrix angekündigte Taskbar-Modus erwarten wir (bzw. unsere User) schon sehnsüchtig. Ich denke das Problem ist, dass das Patchmanagement wie ein Stück Software (das zu verteilen ist) behandelt wird. Ist es aber nicht. Es ist mehr und es ist wichtiger. Vielleicht sollte Matrix über einen eigenen Agent dafür mal nachdenken. Auf jeden Fall sollte aber die Prüfung, ob ein neuer Patch zum Installieren vorhanden ist oder nicht, beschleunigt werden. Trickser hat da schon mit der Checksummen-Prüfung einen guten Vorschlag gemacht.
Danke an alle, die sich hier beteiligt haben ... bis demnächst
Um es kurz zu machen: Läuft alles gut. Derzeit läuft das Patchmanagement bei jedem Client täglich einmal. Zwar ist während der Stoßzeiten (zwischen 8 und 9 Uhr) die Netzwerklast auf dem Server hoch, aber noch nicht im kritischen Bereich.
Der von Matrix angekündigte Taskbar-Modus erwarten wir (bzw. unsere User) schon sehnsüchtig. Ich denke das Problem ist, dass das Patchmanagement wie ein Stück Software (das zu verteilen ist) behandelt wird. Ist es aber nicht. Es ist mehr und es ist wichtiger. Vielleicht sollte Matrix über einen eigenen Agent dafür mal nachdenken. Auf jeden Fall sollte aber die Prüfung, ob ein neuer Patch zum Installieren vorhanden ist oder nicht, beschleunigt werden. Trickser hat da schon mit der Checksummen-Prüfung einen guten Vorschlag gemacht.
Danke an alle, die sich hier beteiligt haben ... bis demnächst
Stadt Frankfurt am Main (Amt 51)
Who is online
Users browsing this forum: No registered users and 7 guests