Erfahrungen mit der Organisation von Container

Alle Fragen rund Antworten rund um die ACMP Client Commands und Container
Antworten
dirle
Beiträge: 1
Registriert: Di Sep 18, 2018 11:44 am

Hallo,

wir haben seit kurzer Zeit ACMP im Einsatz und diskutieren zur Zeit sehr stark in der Abteilung, wie wir die Struktur/Ordnerhierachie der Container sinnvoll aufbauen.

Zum einen sollte es so logisch aufgebaut sein, dass man sich z.B. einfach zu einem Container durchklicken kann, in dem alle Clients aufgeführt werden, in der Software XY fehlt. Auf der anderen Seite würde wir aber auch gerne schnell eine Übersicht haben, welche CCs durch den Container und zu welcher Zeit starten.

Unabhängig von unseren Gedanken zu dem Thema: Wie habt ihr eure Container (und daranhängende CCs) organisiert?

Vielen Dank und viele Grüße
Dennis
Benutzeravatar
ngottschalk
Beiträge: 293
Registriert: Mi Sep 08, 2010 12:57 pm

Hallo Dennis,

je nachdem, ob eure Firma mehrere Standorte umfasst, würde ich mit einem Container auf der Hauptebene für die Zuweisung der Verteilten File Repositories anfangen, unter dem dann für jedes VFR ein eigener Container steckt, der z.B. je nach IP-Bereich das entsprechende Repo zuweist;
Danach haben wir eine Containerhierarchie für Gruppen, also Desktops, Notebooks, Server, Testclients und Anderes, die bei uns nach Namen gruppiert. Dies ermöglicht es später, auf ganzen Clienttypen ein CC auszuführen, außerdem werden sie zur Zuweisung von Agentenplanervorlagen genutzt.
An dritter Stelle haben wir unser AD nachgebaut, um so aufgeteilt CCs an einzelne OUs schicken zu können. Als Filter prüfen wir den Wert eines individuellen Feldes, in das vom ACMP-Server regelmäßig die OU eines Clients geschrieben wird.
Danach kommt ein Container für die Softwareverteilung; Dieser enthält für jede Software einen eigenen Untercontainer und die Untercontainer dann ggf. weitere, sofern das Programm durch mehrere CCs installiert wird. Die Filter bestehen hier meistens aus einer Kombination von "Ist Software in Version XYZ nicht installiert" und dem Containerpfad (sodass man z.B. alle Server über den Pfad der Servergruppe ausklammern kann).
Desweiteren kommen ein Container mit "Administrations CCs" (also CCs, die in gewissen Intervallen auf bestimmten Gruppen ausgeführt werden), die im Grunde wie die Softwareverteilungscontainer aufgebaut sind, jedoch meist nur nach Gruppen oder OUs filtern.
Als Fünftes haben wir auf der Hauptebene einen Container für Monitoring-CCs, die ebenfalls regelmäßig ausgeführt werden, aber nur Daten sammeln, anstatt Änderungen vorzunehmen (also z.B. die IP an ein individuelles Feld anhängt, sodass man eine Historie der verwendeten IPs erhält).
Als sechstes haben wir (als Platzhalter) einen Container für das Lizenzmanagement erstellt und Container #7 ist für Server-Commands (werden also nur auf dem ACMP-Server selbst ausgeführt), die z.B. die Datenbank aufräumen, freien Speicher auf Servern via WMI überwachen und Ähnliches, dazu dann noch ein Container für PCs mit installierter ACMP-Console (also Admin-PCs), auf denen periodisch CCs ausgeführt werden; Z.B. benachrichtigen diese die Admins, wenn ein nicht hochgepatchter Client online ist, sodass man schnell die Gelegenheit nutzen kann, um den Client zu reparieren/zu aktualisieren.
Abschließend besitzen wir einen Container, in den nur Testclients fallen, um bei Bedarf Tests auszuführen.
Das Ganze sieht dann so aus:
ACMP-Container.PNG
ACMP-Container.PNG (379.33 KiB) 5041 mal betrachtet
Mit freundlichen Grüßen

Niklas Gottschalk (gottschalk@zoller-usa.com)
IT Systems Administrator
Zoller Inc.
mippisch
Beiträge: 18
Registriert: Fr Mär 02, 2018 9:12 am

Hallo Dennis,

bezüglich deiner Frage nach einer Übersicht aller verknüpfter CC mit Startbedingung. Dafür haben wir in Zusammenarbeit mit der ACMP Hotline ein kleines SQL Query gebastelt:

select distinct script.DESCRIPTION as CommandName,
cont.Name as ContainerName,
cont.Path as ContainerPfad,
t.cust.value('(ConditionText)[1]', 'Varchar(100)') Startbedingung

from SYS_SCRIPTS script

inner join SYS_Jobs job on job.ContentId = script.SCRIPTID
inner join CLT_CONTAINER_STRUCTURE cont on cont.ContainerID = job.ContainerId
cross apply job.Conditions.nodes('/TStartConditionFacade') as t(cust)


Ich möchte evtl. das Query nochmal erweitern mit der Anzal der Clients die aktuell in dem verknüpften Container liegen. Daraus könnte man dann auch einen wöchentlichen, oder monatlichen Report generieren.
Strukturiert sind unsere Container zum einen nach Abteilungen, Software und administrativen CC.

Uns stört aktuell noch, dass wir bei dem "Standardcontainer", Software nicht im Versionsstand X, fast immer ein SQL Statement basteln müssen, da Version und Softwarename häufig in zwei verschiedenen Feldern liegen. Dann kommen evtl. noch ein bis zwei andere Bedingungen hinzu, zusätzlich müssen die Server und Testrechner noch ausgenommen werden und schnell wird es kompliziert (und fehleranfällig!)...
Falls jemand eine bessere Idee hat für diese Art von Containern hat wären wir über Tipps sehr dankbar.

Grüße,
Michael Ippisch
FBiehn
Beiträge: 97
Registriert: Do Apr 22, 2010 10:38 am

mippisch hat geschrieben: Mo Sep 24, 2018 8:28 am Ich möchte evtl. das Query nochmal erweitern mit der Anzal der Clients die aktuell in dem verknüpften Container liegen. Daraus könnte man dann auch einen wöchentlichen, oder monatlichen Report generieren.
Das könnte so funktionieren:

Code: Alles auswählen

SELECT DISTINCT 
	[CommandName] = [script].[DESCRIPTION]
	, [ContainerName] = [cont].[NAME]
	, [ContainerPfad] = [cont].[Path]
	, [Startbedingung] = [t].[cust].value('(ConditionText)[1]', 'varchar(100)')
	, [Anzahl Clients] = COUNT([contcli].[LinkID]) OVER (PARTITION BY [contcli].[CONTAINERID])
FROM [SYS_SCRIPTS] [script]
INNER JOIN [SYS_Jobs] [job]
	ON [job].[ContentId] = [script].[SCRIPTID]
INNER JOIN [CLT_CONTAINER_STRUCTURE] [cont]
	ON [cont].[ContainerID] = [job].[ContainerId]
INNER JOIN [CLT_CONTAINER_ITEMS] [contcli]
	ON [cont].[ContainerID] = [contcli].[CONTAINERID]
CROSS APPLY [job].[Conditions].nodes('/TStartConditionFacade') t(cust)
Benutzeravatar
ngottschalk
Beiträge: 293
Registriert: Mi Sep 08, 2010 12:57 pm

Hallo Michael,

bzgl.
Uns stört aktuell noch, dass wir bei dem "Standardcontainer", Software nicht im Versionsstand X, fast immer ein SQL Statement basteln müssen, da Version und Softwarename häufig in zwei verschiedenen Feldern liegen.
hat Herr Koch unter viewtopic.php?f=77&t=2162 einmal eine schöne Zusammenfassung gepostet, die bei uns soweit auch funktioniert, ggf. ist das einen Blick wert;)
Mit freundlichen Grüßen

Niklas Gottschalk (gottschalk@zoller-usa.com)
IT Systems Administrator
Zoller Inc.
mippisch
Beiträge: 18
Registriert: Fr Mär 02, 2018 9:12 am

Hallo Niklas,

danke für die Info. So hatte ich es eigentlich ganz am Anfang schon versucht, aber dann falsche Ergebnisse erhalten.
Bin mir ziemlich sicher das mir dann von einem Aagon Mitarbeiter erklärt wurde das beide Werte von Mehrfachfeldern in einem "Dyn. Filter" nicht korrelieren. Beudetet z.B. Softwarename "ACMP Agent" und Softwareversion "5.3" würde auch Clients finden die zwar einen alten ACMP Agent haben aber eine andere Software mit Version 5.3.
Habe es aber gerade probiert und funktioniert wirklich so wie angenommen. Hatte ich wohl damals einen anderen Fehler und das falsch verstanden :shock:

Wie macht ihr das mit Software die sich bei einem Update nicht sauber aus den Windows "installierte Programme" löscht?
z.B. Irfan View:
2018-09-24 15_32_50-ACMP Console.png
2018-09-24 15_32_50-ACMP Console.png (1.92 KiB) 4978 mal betrachtet
Oder Software die bewusst in verschiedenen Versionen gleichzeitig auf einem Client installiert wird?

Sorry wenn es jetzt hier zu sehr OffTopic wird :)

Grüße,
Michael
Benutzeravatar
ngottschalk
Beiträge: 293
Registriert: Mi Sep 08, 2010 12:57 pm

Hi Michael,

das Problem der nicht korrelierenden Felder wurde zumindest für die Felder Software + Version mehr oder weniger vor längerem behoben, sodass die verlinkte Art von Filter ab diesem Zeitpunkt funktionierte, aber davor war es nicht ohne Weiteres möglich, das ist schon richtig.
Das Problem mit Programmen in der Liste haben wir so nicht, aber für gewöhnlich befinden sich die Einträge hierfür je nach Installationsart in der Registry unter

- 64bit, systemweit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
- 32bit, systemweit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
- 64bit, userbezogen: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
- 32bit, userbezogen: HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Wenn dort der entsprechende Schlüssel gelöscht wird, sollte das Programm nichtmehr in der Liste auftauchen und auch vom ACMP Agent nichtmehr inventarisiert werden.
Mit freundlichen Grüßen

Niklas Gottschalk (gottschalk@zoller-usa.com)
IT Systems Administrator
Zoller Inc.
mippisch
Beiträge: 18
Registriert: Fr Mär 02, 2018 9:12 am

Hallo Niklas,

mit den Filtern nach der Versionsnummer scheint doch noch nicht so ganz zu funktionieren.
Wir haben jetzt einen Container gemacht zum Update von Adobe Reader. Der folgende Client sollte ja nicht gefunden werden, oder?
2018-09-27 08_11_56-ACMP Console -- Angemeldet als michael.ip _ SVACMP (2106).png
2018-09-27 08_11_56-ACMP Console -- Angemeldet als michael.ip _ SVACMP (2106).png (24.88 KiB) 4953 mal betrachtet
Trotzdem erscheint er weiterhin im Container:
2018-09-27 08_13_33-ACMP Console -- Angemeldet als michael.ip _ SVACMP (2106).png
2018-09-27 08_13_33-ACMP Console -- Angemeldet als michael.ip _ SVACMP (2106).png (5.19 KiB) 4952 mal betrachtet
Habe ich hier einen Denkfehler?
Wir haben auch Probleme mit anderen Filtern, die sich nicht so verhalten wie gedacht. Da sind wir aber schon mit der Hotline in Kontakt. Haben da andere auch solche Probleme?

Grüße
Michael Ippisch

//edit:
Sorry den Fehler jetzt doch entdeckt. Es war doch noch eine andere Software enthalten mit der "Adobe Acrobat" im Namen.
Den anderen Fehler den wir haben sind doppelte Verneinungen, also mehr als ein NICHT im UND Tree, scheint ein bekannter Fehler zu sein. Wird gefixt
Antworten