User Forum

Derzeit wird bei Installation eines Agenten dessen Konfiguration in die Registry des Clients abgelegt, leider auch die der Setup-Aufrufe. Ich halte eine Trennung für erwägenswert. Die Verteilung des Agenten ist derart zäh und langwierig, dass man den Agenten einmalig verteilen sollte mit einer Konfiguration, die ihn beim Starten in die Lage versetzt, die weiteren, eher veränderlichen und optionalen Konfigurationen vom Empirum-Server zu beziehen.
Die Aktion wäre so, dass der Agent lediglich wissen müsste, welcher Empirum-Server zu verwenden ist. Sobald der Agentendienst startet, verbindet er sich mit dem angegebenen Server, und holt zunächst die Konfigurationsdaten ab. Erst dann schaut er nach aktualisierten Zuweisungen etc. Da der Agent beim Start ohnehin beim Server nach Zuweisungen schaut, ist das wenige an zusätzlichen Daten verschmerzbar.

Im Gegenzug erhalte ich ein System, bei dem ich an zentraler Stelle vorgebe, wie sich der Agent aller Geräte beim nächsten Aufruf verhalten soll - ohne dass ich Tage beschäftigt bin, Agenten zu schieben, bis auch der letzte PC begriffen hat, was er machen soll.

Ich finde die Idee so gut, dass ich ein virtuelles Trullalla erwarte. Was denkt ihr dazu?

Um welche unterschiedlichen Konfigurationen geht es denn hier?
Bei den Installation die ich bisher betreut habe kamen in der Regel eine, wenn es hoch kommt zwei, verschiedene Agenten-Konfigurationen zustande.
Bis auf den Servernamen (den man ggf. per DHCP rausschickt) ist doch alles fest konfiguriert, oder?

Beispielsweise hatten wir eine desaströse Netzwerkstörung, die das Netzwerk sehr langsam machte. Der Agenten-Zeitzyklus hat den Rest des noch verfügbaren Netzes zu hoch belastet. Hätte ich den Agenten nun umkonfiguriert, und neu gepusht, wäre die Netzlast noch zusätzlich gestiegen. Ich hatte nur noch die Wahl, die Registry-Keys des Agenten auf den Maschinen gescriptet anzupassen. Dabei kam mir die Idee, wie viel eleganter es sein könnte, auf allen Geräten eine Einstellung anzupassen, wenn die Einstellungen ebenfalls jeweils vom Server gezogen werden.

Andere Beispiele aus der Vergangenheit:

• Ein (ehemaliger) Partner hatte den Agenten einmal falsch konfiguriert, schlecht getestet und dann über das Wochenende gepusht. Nicht nur, dass der Agent nicht funktionierte, er war auch noch gesprächig konfiguriert, und hat an allen Maschinen im Zehnminutentakt Fehlermeldungen erzeugt. Wir waren Tage damit beschäftigt, eien korrigierten Agenten auf die Maschinen zu bringen.
• Nachdem eine Zeit lang Installationen und PatchManagement Silent konfiguriert waren, hatten die Beschäftigten angeregt, den Agenten umzukonfigurieren, so dass mehr Informationen verfügbar wären. Das erfolgte über die Anzeige der SW-Depot-Liste der zu installierenden Pakete. Die Folge war, dass die Beschäftigten es nicht begriffen. Beim Patchmanagement regte sich helle Empörung, da die Mehrheit der Meinung war, die Prüfung auf Patches sei schon eine Installation, und tägliches Patchen sei eine Belästigung.

Mit zentraler Konfiguration könnte man solche Änderungen einmal festlegen, und jeder bereits installierte Agent würde diese Änderungen beim nächsten Start schlicht übernehmen - ohne dass ich einen Agenten erneut mühsam auf die Rechner schiebe, Agenten als Paket verteile, oder Änderungen scripte, und ebenfalls als Paket verteile. Zumal habe ich nicht das Problem, einer Übergangsphase - bis schliesslich noch der letzte verbliebene PC den neuen Agenten erhalten hat vergeht Zeit, wenn nicht jeder PC jeden Tag gestartet wird. Verwirrte Vor-Ort-Betreuer rufen dann an, und fragen, warum das doch bereits als gelöst angekündigte Problem wieder auftauche usw.

Kleinigkeiten, die einem das Administrieren aber einfacher machen.

Darf ich sie noch auf http://www.matrix42.de/forum/viewtopic.php?t=5044 aufmerksam machen - ich wusste nicht, wohin damit - kein Top schien mir zu passen. Hierüber könnte ein Benutzer die Gesprächigkeit seines Agenten u.U, sogar selbst in gewissem Rahmen einstellen, und somit von der zentralen Vorgabe abweichen (es sei denn, die zentrale Vorgabe würde "erzwungen").

"Der Benutzer was Einstellen".. Ui.. Dann hat man ja keine Kontrolle mehr! Schlieslich ist es besser einen Securitypatch draufzuhaben und 100User können 3min nicht Arbeiten als ein ganzes Netzwerk voller Blaster o.Ä.

Wann immer der User etwas einstellen kann wird er es 100% schaffen damit auch was zu zerstören... mörfi und so

Wieviele Agenten laufen denn die da pollen? Wenn das das Netzwerk lahm legt, dann geht aber auch nichts anderes mehr, oder?

Ich habe ja geschrieben "im Rahmen" etwas einstellen gegenüber einer "Erzwingung". Der Benutzer könnte etwa einstellen, er möchte während einer Installation einen Warnsound höhren, oder den installationsbildschirm sehen, oder einfach nichts. Keine schlimmen Einstellungsmöglichkeiten natürlich.

Es laufen ~ 1000 Agenten. Klar, es war - bei diesem einen Beispiel - eine besondere Situation, denn zentrale Netzwerk-Knoten hatten von heute auf morgen beschlossen, zu 95% Fehlpakete zu erzeugen. Auf dem Netz lief nicht mehr viel - es hätte aber einiges gebracht, die Agenten mal vorübergehend in einen anderen Status zu versetzen. Das hätte noch die Luft geschaffen, einigen OWA zu ermöglichen. Das rudimentäre Restnetz ist stattdessen im Zyklus der Agenten jeweils völlig zusammengebrochen.

Habe mir die Sache heute noch mal durch den Kopf gehen lassen (zooooom...)

Wir können das HEUTE schon: Und zwar mit den DHCP-Optionen:
- DHCP-Option "AgentParameter" definieren (z.B. DHCP-Option 242).
- Dann diesen String %AgentParameter" in der Registry eintragen statt "/K600 /Z2 ..."

Getestet habe ich es nicht.
So kann man über den DHCP-Server jederzeit die Agents umkonfigurieren.

Das ist so genial, das ich es nicht verstehe
Wo und wie genau?

Im Agenten gibt es den Schlter "DHCP-Optionen". Und im DBUTIL gebe ich die Option wie ein? Und wie erfährt der DHCP-Server davon?

Naja - einfach so verfahren als wenn man einen Empirumserver per DHCP bekannt machen will (in der Agent-Konfig DHCP-Optionen aktivieren).
Dann in den DHCP-Optionen dort die Nummer der Option der Systemvariablen zuordnen, die durch das swdepot automatisch gefüllt wird (normalerweise so was wie 240=EmpirumServer, 241=EmpirumServer-Backup). In unserem Fall dann 242=EmpirumOptionen.

Nun in der Registry RUN1 und RUN2 bzw. Dienste-Schlüssel statt der Optionen %EmpirumOptionen% eintragen.

Da das SWDEPOT vor dem Start des eigentlichen Depots die DHCP-Optionen ausliest vom DHCP-Server müßte das so klappen.

Noch Verständnislücken?

Ja, das swdepot liest jeweisl die DHCP-Optionen aus? Ich dachte, diese sind an das PXE gebunden?

Hat eigentlich nix mit einander zu tun.
Nur wenn man keinen richtigen DHCP-Server hat KANN man auch den Empirum PXE-Server einsetzen um die DHCP-Optionen zu setzen.
Normalerweise würde man diese Optionen im Linux- bzw. Windows-DHCP-Server eintragen.

Aber hier müsste es über den PXE-Dienst des dbutil geschehen? So zumindest schreibt es das Handbuch. Der Schalter im Agenten bewirkt dann nur, dass die DHCP-Optionen auch ausgelesen werden?

Der Teil mit den Optionen ist mir auch noch nicht klar, denn ich habe dem DHCP noch nie Optionen beigebracht. Ich muss der Option den Registrierungsschlüssel mitgeben, in dem der Agent seine Konfiguration sucht - oder heisst die DHCP-Option RUN1, RUN2, mit dem jeweiligen Wert der Konfigurationszeile des Agenten?

Wenn KEIN DHCP-Server im Unternehmen ist, muss es über DBUTIL eingetragen werden. Sonst NICHT.

Agent: Ja, genau. Das bewirkt der Schalter.

DHCP-Optionen: Siehe ggf. Anleitung des DHCP-Servers.

Die SWDEPOT.EXE liest nur die Option Nummer X vom DHCP und trägt den Wert in die Systemvariable Y des Windows ein. Mehr nicht. Diese Variable kann nun überall verwendet werden. u.a. auch als Aufrufparameter für das SWDEPOT selbst - hoffe ich

Hendrik_Ambrosius wrote:Wenn KEIN DHCP-Server im Unternehmen ist, muss es über DBUTIL eingetragen werden. Sonst NICHT.

Ah! Das habe ich an der Hilfe nicht erkennen können. Das macht dann auch Sinn.

DHCP-Optionen: Siehe ggf. Anleitung des DHCP-Servers.

Die SWDEPOT.EXE liest nur die Option Nummer X vom DHCP und trägt den Wert in die Systemvariable Y des Windows ein. Mehr nicht. Diese Variable kann nun überall verwendet werden. u.a. auch als Aufrufparameter für das SWDEPOT selbst - hoffe ich

Unglücklich finde ich, dass ich hier einen Systembruch habe - also Empirum-Aspekte in DHCP-Server abgelegt werden. Diese Informationen auf dem Empirum-Server selbst auszulesen wäre nicht nur hübscher - es funktionierte auch fraglos einfacher wenn man mehrere DHCP-Server betreibt.

Ich werde es aber mal mit einem Testrechner und einem Testagenten versuchen. Vielen Dank!

Gern.

Idee noch: Auch einige DHCP-Server lassen sich per Script konfigurieren