Servus @HKARZ !

Wenn ich deinen post richtig verstanden habe, müsste folgende Service-Modellierung die Abhängigkeiten korrekt abbilden:
LG
Peter

Hallo zusammen,
im Logbuch kann man die Spaltenbreiten nicht ändern, das bedeutet: Auch nicht erkennen, welcher User(name) welche Änderung durchgeführt hat.

Kann man das bitte auf brauchbar ändern?
LG
Peter

Hi @Philipp-Hörselmann
der Link in die KB ist 404, ...

@Fragesteller schlage vor, du verwendest "dynamische Gruppen".

Dazu zuvor einen Report konfigurieren, der die Objekte mit den gewünschten gleichen Eigenschaften ausgibt.

Und danach eine Objektgruppe vom Typ "dynamic", die ebendiesen Report verwendet.

i-doit kann solche "dynamischen Gruppen" jedoch nicht sofort auflösen, daher gibt es einen CLI-Befehl, der über einen CRON-Job regelmäßig aufgerufen werden muss. Damit werden die Gruppen mit allen Objekten und Relationen sauber gebildet.

Siehe auch https://community.i-doit.com/post/17884

Hi all,
probiert mal die CLI in einem CRON-Job mit der Option:

sync-dynamic-groups Synchronize dynamic group members

Das kümmert sich "von extern" um das Auflösen der dynamic groups in "echte" Relationen und sollte euer Problem lösen. Diese im täglichen Betrieb sehr nützliche Funktion ist anscheinend niemanden mehr bekannt.

Bin noch nicht mit allen Eventualitäten durch (wieder Entfernen von group members?) doch zumindest die Aufnahme von "neuen" group members klappt zuverlässig.

siehe auch https://kb.i-doit.com/de/automatisierung-und-integration/cli/console/index.html

Danke @Michael-Huhn für die gute Nachricht!

@Dangerfield
nothing new, unfortunately

@Michael-Huhn
any news?
soll denn künftig auch die Knowledge Base von der Community gewartet werden?

Hallo @c-schroeder

Variante: Mach' dir einen Objektyp der 1:1 den "Services" entspricht, aber in deinem Fall "Produkt" heißt.

Dann hast du Ralationen nach "unten" - die Komponenten sind Services
und
nach "oben" - falls du noch übergeordnete "Produkte" oder "Produktgruppen" zur Bündelung haben willst.

Mit diesem Trick kannst du die Produkte auch gleich im CMDB-Explorer auswählen - dort sind nur "Services" sichtbar - und somit siehst auf einen Blick dein ganzes Produktportfolio, die zugehörigen Services und deren Infrastruktur.

Vergib' zur Sicherheit noch einen Service-Typ zur Einschränkung der Auswahl.

Beispiel Portfolio-Management:

LG
Peter

Hallo,
eure Kunden würden ja gerne, aber:

https://raw.githubusercontent.com/i-doit/scripts/main/idoit-install

Das Install-Script ist von 2022, soll heißen: Mittlerweile seid ihr 11 Versionen weiter. Wollt ihr da mal, ...

btw: Wie sieht's es aus mit dem aktuellem PHP 8.3 und Debian 12?
Beste Grüße
P.

Hallo @StephanBuerger,
in der Regel servicieren Server etwas, sagen wir mal Service dazu. Meistens benötigt man zusätzlich zum Server auch noch andere Komponenten, damit ein Service voll funktionstüchtig ist. Zum Beispiel die wissenden Personen, Support- und Wartungsverträge, externe Partner oder andere Technologie, zum Beispiel auch externe Services aus der Cloud.

Du kannst natürlich auch nur bei den Servern bleiben, fix ist: Services werden tendenziell "größer", wenn du sie mal genau analysierst, als nur Server. Du kannst Services als Container oder Gruppen betrachten und ich empfehle dir von Anfang an Services zu verwenden. Server kommen und gehen, das Service bleibt.

Services sind natürlich auch von anderen Services abhängig.
Auf diese Weise modellierst du Service-Bausteine, ähnlich Lego, mit denen du jedes andere, neue, Service zusammenbaust.

Diese "Service-Chain", also eine Kette von Abhängigkeiten, kannst du sehr einfach in i-doit abbilden und mit dem CMDB Explorer darstellen. Natürlich sind Services auch Objekte, die du im Dokumenten Add-On verwenden kannst und natürlich sind diese Relationen Standard.

Die Reihenfolge beim Wiederanlaufplan (für ein Desaster Recovery) ergibt sich dann nur mehr aus den Services.

Beispiel:
Power(Service) -> Datacenter-Network(Service) -> DB-Service for CMDB(oder shared) -> CMDB Service (der Application Server) -> CMDB OK

Power -> Datacenter-Network -> Active Directory(Service) -> DB-Service for CRM -> CRM Application/Backend (Service)-> User Network (Service) -> CRM OK

Wundere dich nicht: Üblicher Weise hat man als IT Service Provider über hundert technische Services zu betreuen.
Und dann kommen noch die Business Services dazu, also jene, die ausschließlich das Business unterstützen. CRM ist so etwas.

IT Service Management ist genau das: Verwalten, Dokumentieren, Managen und im Notfall: Wiederherstellen von Services.

Wenn du erstmal deine Services kennst, kannst du auch so Planspiele mit den Ansprechpartnern aus dem Business machen wie: Welche Services brauchen wir denn UNBEDINGT, damit unsere Firma überlebt? Und die gruppierst du dann zu einer Gruppe oder wiederum zu einem "Notfall-Service".

Gutes Gelingen und beste Grüße!
Peter

P.S.: Das mit "unterhalb" und "oberhalb" musst du dir nochmals genau ansehen, am besten mit dem CMDB Explorer. In der ITSM Branche ist es üblich zu sagen: wenn das "untere" Objekt einen Fehler hat, kann das "obere" nicht, oder nur eingeschränkt funktionieren. Bäume oder Maps oder Graphen in der CMDB, oder wie auch immer du es nennen willst, sind also "Abhängigkeiten" im Sinne der Verfügbarkeit. Dein Beispiel vom Switch wäre also umgekehrt zu modellieren: Der Switch "ermöglicht" das Core-Network-Service und dieses Service ist ziemlich weit "unten".