SysConfig-Einstellungen für Assets

Dieser Konsolenbefehl trägt die mit dem Ticket verknüpften Assets in das Dynamische Feld "Betroffene Assets" für jedes Ticket ein.

Bei Bedarf können Sie den Befehl auch manuell im Menü System > Konsole ausführen. Dies kann im Rahmen der Migration von KIX 17 auf KIX 18 erforderlich sein.

Die in der Konfiguration des Dynamischen Feldes angegebene maximale Anzahl (Standard: 15) wird ignoriert, so dass mehr Assets eingestellt werden können. In diesem Fall erhalten Sie eine entsprechende Meldung.

Steuert

Die Zuordnungen können auf Basis der Verwendungsstatus erfolgen.

In Kombination mit spezifischen Verwendungsstatus, z.B. "Baseline Configuration" wird die Anzeige von Baseline-Assets oder "Shopping Item"-Versionen von Assets im Self Service Portal möglich.

Durch Angabe von Suchkriterien können Sie die Sichtbarkeit auf post- oder pre-produktive Status beschränken. Somit können Sie bspw. ein statisches Suchkriterium auf Basis des Deployment-Status definieren, damit SSP Nutzer nicht selbst zwischen aktuellen Daten und Alt-Daten unterscheiden müssen (für Warenkörbe oder Baseline-Konfigurationen).

Möglich sind folgende Attribute:

Bei allen 4 Attributen ist als Suchkriterium möglich:

{
   "Contact": {
      "Computer": {
         "SectionOwner::OwnerContact": {
            "SearchAttributes": [
               "ID"
            ]
         },
         "DeploymentState": {
            "SearchStatic": [
               "Production",
               "Planned"
            ]
         },
         "SectionOwner::OwnerOrganisation": {
            "SearchAttributes": [
               "RelevantOrganisationID"
            ]
         }
      },
...

Struktur

(Alle Attribute werden mit OR kombiniert)

{
  "RelevantObject": {
      "DependendObject": {
          "DependendObjectAttribut": {
              "SearchAttribut OR SearchStatic": [
                  "RelevantObjectAttribut OR StaticValue"
              ]
          }
      }
   }
}

{
  "Contact": {
      "Ticket": {
          "OrganisationID": {
              "SearchAttributes": [
                  "RelevantOrganisationID"
              ]
          }
      },
      "TicketArticle": {
          "CustomerVisible": {
              "SearchStatic": [
                  1
              ]
          }
      },
      "FAQArticle": {
          "CustomerVisible": {
              "SearchStatic": [
                  1
              ]
          }
      }
   }
}

{
"Contact": {
    "Ticket": {
        "ContactID": {
            "SearchAttributes": [ "ID" ]
        }
    },
[...]

Definiert die Typen von Verwendungsstatus (produktiv, post-produktiv, pre-produktiv).

Agenten müssen beim Anlegen oder Bearbeiten von Assets einen Verwendungsstatus (Deployment State) angeben.  Dieser beschreibt die Position des Assets innerhalb seines Lebenszyklus.

Im General Catalog können Sie weitere individuelle Verwendungsstatus anlegen und die Zuordnung zum Statustyp vornehmen (Menü Assets > General Catalog).

Hinweis: Assets vom Statustyp "post-produktiv" sind im Asset Modul nicht sichtbar und können nur über die Komplexsuche gefunden werden.

Dies betrifft insbesondere Assets vom Typ "Service" (s. auch: Serviceverträge). 

KIX wird initial mit folgenden Verwendungsstatus ausgeliefert:

Beispielkonfiguration

{
 "Class": "ITSM::ConfigItem::DeploymentState",
 "Data": {
    "postproductive": "postproductive",
    "preproductive": "preproductive",
    "productive": "productive"
    },
 "Desc": "Deployment State Type.",
 "Label": "Deployment State Type",
 "PrefKey": "Functionality"
}

In diesem Schlüssel sind die zu verschlüsselnden Asset-Attribute definiert und welche Nutzerrollen das Recht haben, diese Asset-Attribute im Klartext zu sehen. Dies ist insbesondere nach der Migration von Klassendefinitionen aus KIX 17 nach KIX 18 relevant, da hierbei der Attributtyp "EncrpytedText" zu einem einfachen "Text" migriert wird und somit verschlüsselte Informationen im Klartext angezeigt werden.

Nutzer, die eine Rollenberechtigung auf das jeweilige Attribut haben, sehen die verschlüsselten Informationen als Klartext. Nutzern, die keine Rollenberechtigung auf das jeweilige Attribut haben, werden anstelle der Informationen nur Sternchen (*****) angezeigt.

Die Migration erkennt, welche Attribute in KIX 17 als "Encrypted Text" vorlagen und bereitet die Liste der Schlüssel entsprechend vor. Sie müssen lediglich die entsprechenden Rollen eintragen und ggf. einzelne Attribute ergänzen. Ist keine bekannte Rolle angegeben, wird das Attribut nicht verschlüsselt.

Die Angabe erfolgt als Schlüssel:Wert-Paar. Der Schlüssel setzt sich aus zusammen aus: "<Asset-Klasse>:::<Attributname>" (dreifacher Doppelpunkt). Der Wert ist eine kommaseparierte Liste von Rollen, die dieses Attribut lesen und schreiben dürfen.

Hinweise:

Definiert, welche Verknüpfungstypen in welche Richtung verfolgt werden, um den Vorfallsstatus eines gestörten Assets an abhängige, verknüpfte Assets zu propagieren (bpsw. in der Darstellung der Assetbeziehungen im Graphen).

Die Konfiguration beinhaltet n relevante Verknüpfungstypen und -richtungen als Schlüssel-Wert-Paare:

Wird ein Asset auf "Incident" gesetzt, werden die hier konfigurierten Verknüpfungstypen verfolgt, um die betreffenden Assets ebenfalls auf "Incident" zu setzen. Ist ein solches Asset aber mit weiteren, nicht gestörten Assets verknüpft, wird das betreffende Asset nicht auf "Incident", sondern auf "Warning" gesetzt.

Beispielkonfiguration

{
  "DependsOn": "Both",
  "ConnectedTo": "Target",
  "Includes": "Source"
}

Definiert das Organisation-Attribut für den Import/Export

Der Konfigurationsschlüssel definiert, welches Attribut (ID, Number oder Name) einer Organisation beim Import/Export ausgegeben wird.

Standard: Number

Beachten Sie:  Das Attribut muss beim Export und anschließendem Import gleich sein! Das heißt, wenn der Name der Organisation importiert wird, sollte der SysConfig-Schlüssel ebenfalls auf "Name" stehen. Anderenfalls erhalten Sie eine Fehlermeldung "Could not import Organisation: no Organisation ID found for [Attribut (Wert)]". Der Wert im Import-File muss dann entsprechend geändert werden.

Voraussetzung: Die Verwendung des Moduls muss im SysConfig-Schlüssel ITSMConfigItem::NumberGenerator festgelegt sein.

Das Modul generiert inkrementelle Nummern mit dem Muster <ClassPrefix+Separator><SystemID+Separator><FormattedCounter>

Es ist somit möglich, ein klassenspezifisches Präfix an der Assetnummer anzugeben, z. B. NW für Netzwerk. Wenn kein Klassenpräfix und kein Standardpräfix angegeben ist, wird die Klassen-ID verwendet.

<FormattedCounter> entspricht der Nummerierung innerhalb der jeweiligen Assetklasse (fortlaufendes Increment).

Beispielkonfiguration:

{
   "CounterLength": "7",
   "DefaultPrefix": null,
   "IncludeSystemID": "1",
   "Prefixes": {
      "Building": "BLD",
      "Computer": "CM",
      "Hardware": "HW",
      "Location": "LOC",
      "Network": "NW",
      "Room": "RM",
      "Service": "SRV",
      "Software": "SW"
   },
   "Separator":"."
}

Legt das zu verwendende Modul zum Generieren der Assetnummern fest. Bestimmt damit die Syntax für den Nummernkreis.

Konfiguration zur Verarbeitung eingehender E-Mails zu System Monitoring. Der Focus liegt auf: ITIL-Practice "Monitoring & Event Management".

Parameter

Unterschlüssel	Beschreibung und Hinweise	Beispiel / Vorgabewert
Module	Nicht ändern! Definiert Backend-Code-Module, das zur Mailverarbeitung benutzt wird.	Kernel::System::PostMaster::Filter::SystemMonitoringX
DynamicFieldContent::Ticket	Nicht ändern! Definiert die vom Mechanismus genutzten Dynamischen Felder, die Tickets zugeordnet sind.	SysMonXHost, SysMonXService, SysMonXAddress, SysMonXAlias, SysMonXState
DynamicFieldContent::Article	Nicht ändern! Definiert die vom Mechanismus genutzten Dynamischen Felder, die Tickets zugeordnet sind.
AffectedAssetName	Definiert das Dynamische Feld, welches zur Hinterlegung des betroffenen Assets genutzt wird. Das Feld muss vom Typ "AssetReference" sein. Das Asset wird auf Basis des durch "SysMonXHostRegExp" extrahierten Suchmusters in einer Asset-Namenssuche ermittelt.   Es kann nur ein Asset eingetragen werden. Sollten mehrere Assets dem Suchmuster genügen, wird das erstbeste erfasst.	AffectedAsset
SysMonXStateName	Nicht ändern! Definiert das Dynamische Feld, in welchem der System-Monitoring-Status erfasst wird.	SysMonXState
CreateTicketType	Definiert den Tickettyp, der zur Erstellung des Tickets Verwendung findet. Es muss der nicht-lokalisierte Name verwendet werden.	Incident
CreateTicketState	Definiert den Ticketstatus, der bei Erstellung des Tickets gesetzt wird. Es muss der nicht-lokalisierte Name verwendet werden.	new
CreateSenderType	Nicht ändern! Definiert den Sendertyp des Artikels, welcher zum Ticket erstellt wird.	system
CreateChannel	Nicht ändern! Definiert den Kommunikationskanal des Artikels, welcher zum Ticket erstellt wird.	note
CreateTicketQueue	Definiert das Team, welchem das Ticket initial zugewiesen wird. Es muss der nicht-lokalisierte Name verwendet werden. Es muss der volle Name verwendet werden. Das hier angegebene Team bildet den Default-Wert. Beim Anlegen/Bearbeiten eines E-Mail-Filters (Menü Kommunikation > E-Mail > E-Mail-Filter) kann ein anderes Team gesetzt werden. Das im E-Mail-Filter gesetzte Team besitzt Vorrang gegenüber der SysConfig-Einstellung.	Service Desk::Monitoring
CreateTicketSLA	Definiert den SLA, welcher dem Ticket initial zugewiesen wird.
CloseNotIfLocked	Verhindert das Setzen des Status entsprechend "CloseActionState", wenn das vorhandene Ticket gesperrt ist.	0
StopAfterMatch	Wenn gesetzt ("1"), werden keine weiteren E-Mail-Filter in der Verarbeitung der Mail angewandt.	1
FromAddressRegExp	Diese System-Monitoring-Konfiguration bearbeitet nur E-Mails, deren Absender diesem Muster entspricht.	sysmon@example.com
ToAddressRegExp	Diese System-Monitoring-Konfiguration bearbeitet nur E-Mails, deren To-Empfänger diesem Muster entspricht.	.*
SysMonXAddressRegExp	Definiert das Suchmuster, mit dem die Adresse des betroffenen Systems aus der Mail extrahiert wird. Es wird die erste Capture-Group verwendet.	\s*Address:\s+(.*)\s*
SysMonXAliasRegExp	Definiert das Suchmuster, mit dem ein Alias des betroffenen Systems aus der Mail extrahiert wird. Es wird die erste Capture-Group verwendet.	\s*Alias:\s+(.*)\s*
SysMonXStateRegExp	Definiert das Suchmuster, mit dem der System-Monitoring-Status aus der Mail extrahiert wird. Es wird die erste Capture-Group verwendet.	\s*State:\s+(\S+)
SysMonXHostRegExp	Definiert das Suchmuster, mit dem der Hostname des betroffenen Systems aus der Mail extrahiert wird. Es wird die erste Capture-Group verwendet.	\s*Host:\s+(.*)\s*
SysMonXServiceRegExp	Definiert das Suchmuster, mit dem der betroffene Service aus der Mail extrahiert wird. Es wird die erste Capture-Group verwendet.	\s*Service:\s+(.*)\s*
DefaultService	Wird in der System-Monitoring-Nachricht kein Service gefunden, wird dieser Wert gesetzt.	Host
NewTicketRegExp	Wenn der System-Monitoring-Status diesem Muster entspricht, wird ein neues Ticket erstellt, sofern kein offenes existiert.	CRITICAL | DOWN | WARNING
CloseTicketRegExp	Wenn der System-Monitoring-Status diesem Muster entspricht, wird ein bestehendes Ticket mit einem neuen Ticketstatus entsprechend "CloseActionState" versehen. Kann zu diesem Service oder Host kein offenes Ticket gefunden werden, wird die Email verworfen und ignoriert.	OK | UP
CloseActionState	Definiert den Status, der am Ticket gesetzt wird, wenn eine System-Monitoring-Status entsprechend "CloseTicketRegExp" empfangen wird.	closed
ClosePendingTime	Wird in "CloseActionState" ein Warten-Status gesetzt (z. B. "pending auto close"), wird diese Wartezeit in Sekunden zum Zeitpunkt des Nachrichtenempfangs gesetzt.	172800

{
 "AffectedAssetName": "AffectedAsset",
 "CloseActionState": "closed",
 "CloseNotIfLocked": "0",
 "ClosePendingTime": "172800",
 "CloseTicketRegExp": "OK|UP",
 "CreateChannel": "note",
 "CreateSenderType": "system",
 "CreateTicketQueue": "Service Desk::Monitoring",
 "CreateTicketSLA": null,
 "CreateTicketState": "new",
 "CreateTicketType": "Incident",
 "DefaultService": "Host",
 "DynamicFieldContent::Article": null,
 "DynamicFieldContent::Ticket": "SysMonXHost,SysMonXService,SysMonXAddress,SysMonXAlias,SysMonXState",
 "FromAddressRegExp": "sysmon@example.com",
 "Module": "Kernel::System::PostMaster::Filter::SystemMonitoringX",
 "NewTicketRegExp": "CRITICAL|DOWN|WARNING",
 "StopAfterMatch": "1",
 "SysMonXAddressRegExp": "\\s*Address:\\s+(.*)\\s*",
 "SysMonXAliasRegExp": "\\s*Alias:\\s+(.*)\\s*",
 "SysMonXHostRegExp": "\\s*Host:\\s+(.*)\\s*",
 "SysMonXServiceRegExp": "\\s*Service:\\s+(.*)\\s*",
 "SysMonXStateName": "SysMonXState",
 "SysMonXStateRegExp": "\\s*State:\\s+(\\S+)",
 "ToAddressRegExp": ".*"
}

Return-Path: <sysmon@example.com>
To: nagios-service-mailbox@example.com
Subject: ** PROBLEM alert 1 - ddsrv007 host is DOWN **
Date: Sun, 10 May 2021 01:00:00 +0100 (CET)
From: sysmon@example.com
Mime-Version: 1.0
Message-Id: <20210501000000.1212121212A@xyzabc.example.com>
 
***** Nagios  *****
 
Notification Type: PROBLEM
Host: ddsrv007
State: DOWN for 0d 0h 5m 0s
Address: 192.168.1.2
Info: 1st-critical report for hit in CMDB - should create ticket with aff. asset
 
CRITICAL - Time to live exceeded (192.168.1.2)
 
Date/Time: Mon May 10 00:00:00 CET 2021
 
ACK by:
Comment:

Event-Handler, der Asset-Informationen aus Artikeln oder dynamischen Feldern extrahiert. Versucht Assets zu finden, um sie automatisch an ein dynamisches Ticketfeld anzuhängen.

Ermöglicht zudem die zielgerichtete Suche nach Assets als Ergänzung zur System Monitoring-Integration per Mailfilter.

Die Suche basiert auf in Artikeln (insb. E-Mails) oder Feldern hinterlegten Asset-identifizierenden Informationen wie bspw. IP-Adressen oder FQDNs. Dabei werden die spezifischen Attribute der Assetklassen als Suchkriterien verwendet und Suchen nur in passenden Assetklassen durchgeführt (Focus: ITIL-Practice "Monitoring & Event Management").

{
   "DynamicFieldName": "AffectedAsset",
   "Event": "(ArticleCreate|TicketDynamicFieldUpdate_SysMonXHost|TicketDynamicFieldUpdate_SysMonXAlias|TicketDynamicFieldUpdate_SysMonXAddress)",
   "FirstArticleOnly": "1",
   "Module": "Kernel::System::Ticket::Event::TicketAutoLinkConfigItem"
}

Ergänzend können Sie folgende Schlüssel für Ihre weitere Konfiguration verwenden.

Erstellt automatisch eine Verknüpfung zwischen Ticket und Asset bzw. zwischen Ticket und Service, sobald am Dynamischen Feld vom Typ "Asset Referenz" eine Änderung vorgenommen wird.

Dieses Ereignis erstellt nur Verknüpfungen. Verknüpfungen können nur manuell gelöscht werden.

Beispielkonfiguration "Betroffenes Asset"

{
  "Event": "(TicketDynamicFieldUpdate_AffectedAsset)",
  "LinkType": "RelevantTo",
  "Module": "Kernel::System::Ticket::Event::ITSMConfigItemLinkAdd"
}

Beispielkonfiguration "Betroffener Service"

{
  "Event":"(TicketDynamicFieldUpdate_AffectedServices)",
  "LinkType":"RelevantTo",
  "Module":"Kernel::System::Ticket::Event::ITSMConfigItemLinkAdd"
}

Diese Konfiguration definiert, in welcher Asset-Klasse (Schlüssel), welche Attribute durchsucht werden sollen und mit den gefundenen Suchmustern übereinstimmen müssen.

Mehrere Attribute sind per Komma zu trennen.

Ein Attribut muss den vollen Namen in seiner Asset-Klassen-Struktur enthalten, um eine eindeutige Suche durchführen zu können. Zum Beispiel SectionNetwork::NIC::IPAddress für die Suche nach IP-Adresse.

Diese Konfiguration ist nur für Artikelauswertungen relevant.

Sie erlaubt die Beschränkung der zu durchsuchenden Asset-Klassen auf Basis des To-Empfängers des auslösenden Artikels.

Der Wert enthält eine kommaseparierte Auflistung der zu durchsuchenden Asset-Klassen.

Der Schlüssel enthält dabei eine E-Mail-Adresse.

Es wird nur die reine E-Mail-Adresse (localpart@domainpart  [kein realer Name] ) ausgewertet, unabhängig von Groß-/Kleinschreibung.

Legt fest, aus welchen Ticketattributen welche Muster extrahiert werden sollen.

Dabei wird die erste Capture-Group des als Wert zu hinterlegenden regulären Ausdrucks für die Suche in der CMDB verwendet.

Schlüssel ist das Ticketattribut, z. B. "DynamicField_SysMonXHost" oder "Article_Body".

Sollen mehrere Suchmuster aus dem gleichen Ticketattribut extrahiert werden, können die Schlüssel mit dem Suffix "_ORn" (wobei n 1..N) versehen werden. Zum Beispiel: "Article_Body" und "Article_Body_OR1".