SysConfig-Schlüssel des Systems

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": {
            "OrganisationIDs": {
                "SearchAttributes": [
                    "RelevantOrganisationID"
                ]
            }
        }
    }
}
            

{
"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: ???). 

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"
}

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".

Konfigurationsparameter

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.

Vollständige Domainnamen für das KIX Frontend, Backend und SSP.

Abb.: Die im SysConfig-Schlüssel "FQDN" hinterlegten Domains

Auf die hinterlegten Werte kann mittels KIX-Platzhalter zugegriffen werden, bspw. um den Domainnamen in der Standard-E-Mail-Adresse zu verwenden. Dann wird die Domain automatisch vom System gezogen.

Zum Beispiel:

Die FQDN für das KIX Frontend, Backend und SSP können bereits im System gesetzt werden.

Die hier angegebene E-Mail-Adresse definiert die Standard-E-Mail-Adresse für (Ticket-)Benachrichtigungen. Sie wird vom System genutzt, um darüber die Benachrichtigungen zu versenden.

Die E-Mail-Adresse wird verwendet, um den vollständigen Anzeigenamen für den Benachrichtigungsmaster zu bilden (z. B.: KIX Notifications kix@your.example.com).

Sie können im Feld Wert eine andere Absenderadresse angeben. Dann wird diese für den Versand von Benachrichtigungen verwendet.

Wurde im Setup Assistent der Frontend-FQDN angegeben, wird dieser hier übernommen (Hashwert).

Die Verwendung eines KIX Platzhalters für den Domainnamen ist möglich (<KIX_CONFIG_FQDN> oder <KIX_CONFIG_FQDN_Frontend>). Dann wird die im SysConfig-Schlüssel FQDN hinterlegte Domain verwendet.

Ist nichts angegeben, wird der Standard (Vorgabewert) verwendet. Dieser verwendet die im SysConfig-Schlüssel FQDN angegebene Domain zur Bildung der Absender-Adresse.

Abb.: Der Schlüssel für die Standard-Absenderadresse

Der hier angegebene Name definiert den E-Mail-Absender für Benachrichtigungen. Dieser wird standardmäßig als Absender-Name beim Versand von Benachrichtigungen verwendet.

Der Absendername wird verwendet, um den vollständigen Anzeigenamen für den Benachrichtigungsmaster zu bilden (z. B.: New KIX Notifications kix@your.example.com).

Sie können im Feld Wert eine andere, frei definierte Absenderbezeichnung angeben. Dann werden Benachrichtigungen standardmäßig mit dieser gekennzeichnet (z. B. Neue KIX-Nachricht). Ist nichts angegeben, wird der Standard (Vorgabewert) verwendet.

Abb.: Der geänderte Schlüssel für den Standard-Absendername

Sie können Ihre ausgehenden E-Mails in eine Art "Briefumschlag" (Envelope) stecken. Für den Mailtransport ist dann nur erkennbar, was auf dem "Briefumschlag" steht.

In diesem Konfigurationsschlüssel können Sie eine E-Mail-Adresse angeben, welche in ausgehenden Benachrichtigungen als Absenderkopf des Umschlages verwendet wird.

Wenn hier keine Adresse angegeben ist, ist die Absender-Adresse des Umschlages leer oder es greift das Fallback (SysConfig-Schlüssel SendmailNotificationEnvelopeFrom::FallbackToEmailFrom).

Alternativ können Sie die Adresse auch im Setup Assistent hinterlegen (Konfiguration Postausgang).

Diese Konfiguration greift, wenn im SysConfig-Schlüssel SendmailNotificationEnvelopeFrom keine gültige Adresse angegeben ist.

Standard: 1 (aktiviert)

De-/Aktiviert die Eindeutigkeitsprüfung für E-Mail-Adressen von Kontakten.

Mögliche Werte: 0 - aktiv | 1 - inaktiv

Jedem Kontakt in KIX muss eine eindeutige E-Mail-Adresse zugeordnet sein. Dies wird durch eine Validitätsprüfung beim Anlegen des Kontakts sichergestellt, welche im Fehlerfall einen Warnhinweis ausgibt.

Zum Abdecken diverser B2C-Anwendungsfälle kann es erforderlich sein, die Validitätsprüfung zu deaktivieren und somit Kontakte ohne bzw. ohne eindeutige E-Mail-Adresse in der CMDB zu hinterlegen. Beispielsweise, wenn Sie Ihre Kunden ausschließlich via SMS kontaktieren oder wenn Sie Kontakte ohne gültige Mailadresse automatisiert per Schnittstelle generieren.

Zum Deaktivieren der Validitätsprüfung setzen Sie den Wert im Schlüssel auf 1.

Bei deaktivierter Validitätsprüfung werden eingehende E-Mails dem ersten Kontakt - geordnet nach dem Nachnamen - zugeordnet, wobei der Vorname der E-Mail-Adresse zugeordnet wird.

Einige Funktionen wie:

werden deaktiviert, wenn kein anderer Nachschlagewert als E-Mail angegeben wird.

Bei einem Datenimport sind keine Namensänderungen möglich - unabhängig davon, ob die Validitätsprüfung aktiviert oder deaktiviert ist. Als Identifikator dienen: E-Mail-Adresse + Name + Vorname. Erst wenn die Daten im System angelegt sind, können sie bearbeitet werden.

KIX ruft die E-Mail-Konten in regelmäßigen Zeitabständen automatisch ab. Der Zeitabstand beträgt initial 10 Minuten. Bei Bedarf können Sie hier diese Standardeinstellung ändern.

Vollständige Domainnamen für das KIX Frontend, Backend und SSP.

Abb.: Die im SysConfig-Schlüssel "FQDN" hinterlegten Domains

Auf die hinterlegten Werte kann mittels KIX-Platzhalter zugegriffen werden, bspw. um den Domainnamen in der Standard-E-Mail-Adresse zu verwenden. Dann wird die Domain automatisch vom System gezogen.

Zum Beispiel:

Die FQDN für das KIX Frontend, Backend und SSP können bereits im System gesetzt werden.

Der Filter prüft im Nachgang, nach allen anderen Prüfungen, ob eine E-Mail-Adresse dem angegebenen RegEx entspricht. Ist dies der Fall, so wird die E-Mail - unabhängig von allen anderen Einstellungen - nicht versendet.

Damit kann bspw. verhindert werden, dass auf eine "noreply"-Adresse geantwortet wird.

Die Überprüfung eingehender E-Mails auf mögliche Follow-ups (Rückantworten) übernehmen die nachfolgend aufgeführten Module in Reihenfolge ihrer Nummerierung.

Bei Bedarf können Sie die Module im Menü System+SysConfig de-/aktivieren und somit festlegen, welche E-Mail-Inhalte geprüft werden sollen.

Weiterführende Informationen siehe: E-Mail-Verteilung

Legt ein stufenweises Postmaster-Debug-Level für gezielte Log-Informationen fest.

Die Einstellung kann unabhängig von anderen oder globalen Debug-Optionen gesetzt werden, so dass Sie im Log gezielte Debug-Informationen für die E-Mail-Abholung erhalten.

Das Debug-Level wird für Postmaster mit Mailabholung und E-Mail-Filter-Mechanismen beachtet (Email-Filter, SysMonX-Filter).

Es können 4 Stufen eingestellt werden:

Die Konfiguration gilt nur beim MailAccountFetch und steht an 2. Stelle. Das bedeutet: ist bereits ein Debug (per Konsolenkommando) aktiv, dann wird dieses bevorzugt.

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

Konfigurationsparameter

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:

Definiert das Standard-Team (Default Queue), in welchem die abgeholten E-Mails als Tickets angelegt werden.

In diesem Team werden alle neuen Tickets erstellt, wenn bei der Einrichtung von E-Mail-Konten als Verteilung die Option "Standard" ausgewählt ist.

Können E-Mails keinem Team zugeordnet werden, dann dient das hier angegebene Standard-Team als Fallback.

Achten Sie auf die korrekte Schreibweise des Teams, wenn Sie ein anderes Standard-Team festlegen. Anderenfalls können die Tickets nicht zugeordnet werden.

Definiert, welchen Status ein Ticket nach einer Rückantwort erhält.

Sie können den zu setzenden Status ändern. Das kann sinnvoll sein, wenn Sie eigene Status angelegt haben (z. B. "in Arbeit").

Definiert die maximale Größe der E-Mails, die über POP3, POP3S, IMAP, IMAPS abgeholt werden können.

Wenn Sie den Wert nach oben korrigieren, achten Sie darauf, das das System nicht überlastet wird.

Reihe von SysConfig-Schlüsseln zur Konfiguration des Postausgangs.

Suchen Sie diese Konfigurationsschlüssel unter Angabe der Sternchen: *sendmail*

Sie können Ihre ausgehenden E-Mails in eine Art "Briefumschlag" (Envelope) stecken. Für den Mailtransport ist dann nur erkennbar, was auf dem "Briefumschlag" steht.

In diesem Konfigurationsschlüssel ist die E-Mail-Adresse hinterlegt, welche als Absender auf dem "Briefumschlag" stehen soll, z.B. absender@example.de oder mbox/RFC 5321 . Diese Adresse wird in ausgehenden Nachrichten als Absender für Umschläge verwendet.

Ist keine Absender-Adresse angegeben, wird die E-Mail-Adresse des Teams als Absender verwendet

Alternativ können Sie die Adresse auch im Setup Assistent hinterlegen (Konfiguration Postausgang).

Diese Einstellung gilt nicht für Ticket-Benachrichtigungen.

Definiert das Modul zum Versenden von E-Mails. Legt somit fest, welches Übertragungsprotokoll genutzt werden soll (z. B. SMTP | SMTPS | TLS)

"Sendmail" verwendet direkt das Sendmail-Binary Ihres Betriebssystems. Jeder der SMTP-Mechanismen verwendet einen angegebenen (externen) Mailserver.

"DoNotSendEmail" sendet keine E-Mails und ist für Testsysteme nützlich.

Beispiel: Kernel::System::Email::SMTP

Wenn einer der SMTP-Mechanismen als SendmailModule ausgewählt wurde und eine Authentifizierung gegenüber dem Mailserver erforderlich ist, muss hier ein Passwort hinterlegt werden.

Hinterlegen Sie hier den Benutzernamen für den Login am Mailserver. Dieser entspricht häufig dem Namen des E-Mail-Kontos.

Wenn einer der SMTP-Mechanismen als SendmailModule ausgewählt wurde und eine Authentifizierung gegenüber dem Mailserver erforderlich ist, muss ein Benutzername angegeben werden.

Tragen Sie die Adresse des Mailservers ein.

Wenn einer der SMTP-Mechanismen als SendmailModule ausgewählt wurde, muss der Host des Mailservers angegeben werden, der die E-Mails versendet.

Tragen Sie den Port des Mailservers ein. Der Port ist vom gewählten Übertragungsprotokoll abhängig.

Wenn einer der SMTP-Mechanismen als SendmailModule ausgewählt wurde, muss der Port angegeben werden, an dem Ihr Mailserver auf eingehende Verbindungen wartet.

Häufige Ports sind für:

Definiert, welchen Status ein Ticket erhält, wenn auf ein Ticket geantwortet wird. Sie können die Statuszuteilung ändern oder weitere Status festlegen, um die Statuszuteilung stärker zu granulieren.

Bei geschlossenen Tickets erfolgt die Statusaktualisierung nur, wenn das relevante Team ein Follow-up erlaubt.

Die Statusänderung greift auch für Notizen, die im Self Service Portal erstellt wurden. Sofern jedoch bei Erstellung der Notiz eine Aktualisierung des Ticketstatus vorgenommen wurde (z. B. durch einen Job), erfolgt keine weitere Statusaktualisierung für die SSP-Notiz.

Die Zuordnung der Ticketstatus erfolgt als Schlüssel-Wert-Paar:

Beispiel: 

Ein Ticket hatte den Status "Warten zur Erinnerung" bevor es geschlossen wurde. Wird auf dieses geschlossene Ticket geantwortet, so erhält es wieder den Status "Warten zur Erinnerung".

{
  "closed":"_PREVIOUS_",
  "new":"new",
  "pending auto close":"open",
  "pending reminder":"open"
}

Systemweiter Standardwert

Legt wiederkehrend freie Tage systemweit fest (Feiertage).

Legt wiederkehrend freie Tage (gesetzliche Feiertage) für den entsprechenden Kalender fest.

Initial werden in allen Kalendern die in Deutschland und Österreich geltenden einheitlichen Feiertage ausgeliefert:

Beispielkonfiguration:

[{
   "Day":"1",
   "Month":"1",
   "Translatable":"1",
   "content":"New Year's Day"
},
{
   "Day":"24",
   "Month":"12",
   "Translatable":"1",
   "content":"Christmas Eve"
},
{
   "Day":"25",
   "Month":"12",
   "Translatable":"1",
   "content":"First Christmas Day"
}]

Wert im Schlüssel bitte nicht ändern!

Bewegliche Feiertage werden automatisiert für jedes Kalenderjahr ermittelt und entsprechend der für diesen Tag konfigurierten Arbeitszeit betrachtet. Üblicherweise ganztägig keine Arbeitszeit. 

Ein aktivierter Feiertag wird für den jeweiligen Kalender bei allen relevanten Berechnungen, insbes. SLA-Eskalationen, berücksichtigt. Das heißt, Tickets eskalieren nicht an Feiertagen, SLA-Zeiten werden ausgesetzt.

Folgende bewegliche Feiertage sind aktiv (gültig)

Folgende bewegliche Feiertage sind initial inaktiv (ungültig). Sie können bei Bedarf aktiviert werden:

Systemweiter Standardwert

Legt einmalige freie Tage systemweit fest.

Legt einmalige freie Tage für den Kalender fest.

Kann verwendet werden, wenn für einen bestimmten Tag Betriebsruhe festgelegt ist (z. B. Brückentag)

Beispielkonfiguration:

[{
   "Day":"5",
   "Month":"19",
   "Year":"2023",
   "content":"Brückentag"
}]

Systemweiter Standardwert

Definiert die Tage und Zeiten, die als Geschäftszeiten zählen.

Legt die täglichen Arbeitszeiten für den Kalender fest.

Sie können auch die Bezeichnung des im SysConfig-Schlüssel TimeVacationDaysOneTime::<CalendarNr> unter content definierten Ferientag angeben (z. B. "Brückentag").

Es können mehrere Zeitintervalle pro Tag durch Komma getrennt angegeben werden, um feste Pausenzeiten zu hinterlegen.

Wenn ein Tag als "Feiertag" hinterlegt ist, und es keinen Zeiteintrag für diesen Tag gibt, werden keine Geschäftszeiten für diesen Tag betrachtet.

Legt die täglichen Arbeitszeiten für den Kalender fest. Angaben als Schlüssel-Wert-Paar:

Beispielkonfiguration:

{
  "Fri":"8:00-21:00",
  "Mon":"8:00-21:00",
  "Thu":"8:00-21:00",
  "Tue":"8:00-21:00",
  "Wed":"8:00-21:00"
}

Hinweise:

Der für die Arbeitszeit verwendete Schlüssel wird in folgender Reihenfolge gewählt:

Handelt es sich um einen Urlaubstag und für den Schlüssel existiert kein Eintrag, so gibt es keine Arbeitszeit für diesen Tag.

Gibt es keine gültige Definition oder ist die Konfiguration deaktiviert, so wird die Standardfunktion von KIX verwendet.

Systemweiter Standardwert

Legt die Zeitzone systemweit fest.

Legt den Namen der für den Kalender zu verwendenden Zeitzone fest (z. B.: local)

Wird verwendet, um den Versatz für Zeitzonen mit Sommerzeit zu berechnen. Erfordert ein System mit UTC als Systemzeit.

Legt den Namen für den Kalender fest (z. B.: Calender Name 4).

Im Konfigurationsschlüssel können Sie festlegen, ab welcher Stufe die Informationen protokolliert und im Log der Job-Historie angezeigt werden sollen.

Folgende Werte sind möglich:

Die angegebene Anzahl legt fest, wieviel alte Logfiles behalten werden sollen.

Gilt nur, wenn im SysConfig-Schlüssel LogModule der Wert ::File gewählt wurde (Kernel::System::Log::File).

Angabe der max. Größe der Logfiles in Bytes.

Die Einheit kann in Groß- oder Kleinbuchstaben angegeben werden, muss aber direkt nach der Ziffer folgen (kein Leerzeichen)!

Zum Beispiel: 10M | 5K | 3G oder 10m | 5k | 3g

Bei Rotation nach Größe werden alle Logfiles um 1 verschoben und das aktuelle File mit dem Suffix "_1" versehen

Legt den Zyklus fest, in dem die Logfiles rotieren sollen.

Definiert, ab welchem Log-Level die Systemmeldungen protokolliert werden.

Die Konfiguration der Passwort-Richtlinien erfolgt unter dem Eintrag Config{...}:

{
  "MinCount": "2",
  "RegExp": "[A-Z]",
  "Required": "1"
},
{
  "MinCount": "3",
  "RegExp": "[a-z]",
  "Required": "1"
},
{
  "MinCount": "1",
  "RegExp": "[0-9]",
  "Required": "1"
},
{
  "MinCount": "1",
  "RegExp": "[äAöÖüÜ]",
  "Required": "0"
}

Beispiel: 

{
  "Config": {
    "Checks": [
      {
        "MinCount": "2",
        "RegExp": "[A-Z]",
        "Required": "1"
      },
      {
        "MinCount": "2",
        "RegExp": "[a-z]",
        "Required": "1"
      },
      {
        "MinCount": "1",
        "RegExp": "[0-9]",
        "Required": "1"
      }
    ],
    "MaxSize": null,
    "MinChecks": null,
    "MinSize": "6",
    "RequirementMessage": "Password has to be at least 6 characters long. It needs at least 2 upper case, 2 lower case and 1 digit.",
    "Stopwords": null
  },
  "ConsiderOperationRegEx": "User(Create|Update)",
  "IgnoreOperationRegEx": null,
  "Module": "Kernel::API::Validator::UserPasswordValidator",
  "Validates": "UserPw"
}

In diesem Konfigurationsschlüssel ist die Anzahl möglicher Fehlversuche eines Nutzer-Log-ins definiert. Hat ein Nutzer die hier angegebene Anzahl an Fehlversuchen erreicht, wird dessen Log-in gesperrt. Der Nutzer wird dazu temporär ungültig gesetzt.

Standard: 5

Die Einrichtung der Authentifizierungs-Backends erfolgt über die Konfiguration des JSON-Strings im SysConfig-Schlüssel. Der enthaltene JSON-String ist bereits grundlegend vorbereitet. Für die Verwendung eines LDAP-Verzeichnisdienstes müssen lediglich die entsprechenden Parameter wie Domain, Pfad, Verzeichnis und Attribute angegeben werden.

Ausführliche Informationen siehe: Authentifizierung/Autorisierung und Anbindung Active Directory

Synchronisiert die im Konfigurationsschlüssel Authentication###000-Default unter ContactUserSync angegebenen Kontaktdaten in KIX mit dem konfigurierten Verzeichnisdienst.

Beispiel für ContactUserSync:

"ContactUserSync": {
  "City": "l",
  "DynamicField_ContactRole": "title",
  "Email": "mail",
  "Fax": "facsimileTelephoneNumber",
  "Firstname": "givenname",
  "Lastname": "sn",
  "Mobile": "mobile",
  "Phone": "telephoneNumber",
  "Street": "streetAddress",
  "Title": "title",
  "UserLogin": "sAMAccountName",
  "Zip": "postalCode"
}

Beispiel für AuthSynchronize: 

{
  "Function": "Execute",
  "MaximumParallelInstances": "1",
  "Module": "KIXPro::Kernel::System::Console::Command::Maint::Auth::Sync::Synchronize",
  "Params": [
    "--invalidate-unsynced",
    "--page-size",
    "100"
  ],
  "Schedule": "0 4 * * *",
  "TaskName": "AuthSynchronize"
}

De-/Aktiviert die Multifaktor-Authentifizierung (kurz: MFA) zur Überprüfung der Zugangsberechtigungen der KIX Nutzer.

Die Multifaktor Authentifizierung wird als zusätzliches Authentifizierungsbackend für Kunden- oder Agentenkontext eingerichtet. Anschließend müssen Sie in den Nutzereinstellungen für die betreffenden Nutzer die MFA aktivieren und die OTP-Secrets generieren.

Parameter	Beschreibung
Enabled	De-/Aktiviert die Multifaktor-Authentifizierung Der Schlüssel ist initial "gültig", jedoch deaktiviert: Enabled": 0. Zum Aktivieren der Multifaktor-Authentifizierung setzen Sie den Parameter "Enabled": 1 Die Multifaktor-Authentifizierung muss aktiviert sein, damit sie in der Nutzerkonfiguration zur Verfügung steht.
UsageContext	Optional: Legt fest, für welches Portal die Multifaktor-Authentifizierung gilt. Hinweis Darf nur angegeben werden, wenn die Authentifizierungs-Methode eingeschränkt werden soll. Nur für Agentenportal: "UsageContext":"Agent" Nur für Self Service Portal: "UsageContext":"Customer" Für beide Portale: 2 separate Authentifizierungs-Backends erforderlich [ { "AuthType":"LOGIN", "Config":{ "Algorithm":"SHA1", "AllowEmptySecret": 1, "Digits": 6, "MaxPreviousToken": 0, "SecretLength": 8, "TimeStep": 30 }, "Enabled": 1, "Module":"Kernel::System::Auth::MFA::TOTP", "Name":"TOTP-Agent", "UsageContext":"Agent" }, { "AuthType":"LOGIN", "Config":{ "Algorithm":"SHA1", "AllowEmptySecret": 1, "Digits": 6, "MaxPreviousToken": 0, "SecretLength": 8, "TimeStep": 30 }, "Enabled": 1, "Module":"Kernel::System::Auth::MFA::TOTP", "Name":"TOTP-Customer", "UsageContext":"Customer" } ]
Name	Frei konfigurierbarer Name des MFA-Backends Haben Sie mehrere Authentifizierungs-Backends konfiguriert, können Sie jedem einen anderen Namen geben. So können Sie die einzelnen Authentifizierungs-Backends in der Nutzerkonfiguration unterscheiden. Standard: TOTP-Example

Definiert die maximale Dauer einer untätigen, inaktiven Anmeldung in Anzahl von Minuten.

Nach der hier definierten Anzahl von Minuten ohne Nutzeraktivität wird der Zugangstoken ungültig gesetzt. Der Nutzer muss sich daraufhin erneut anmelden/authentifizieren.

Nach der hier definierten Anzahl von Minuten wird der Zugangstoken ungültig gesetzt. Der Nutzer muss sich daraufhin erneut anmelden/authentifizieren.

KIX kann einem neuen Kontakt automatisch eine Organisation zuordnen, z. B. beim:

Die Organisation wird (je nach Konfiguration) anhand der Domain des E-Mail-Absenders zugewiesen. Dafür können an jeder Organisation bis zu 25 Domain-Pattern hinterlegt werden. KIX prüft die Domain des E-Mail- Absenders bzw. der angegebenen E-Mail-Adresse und sucht das entsprechende Pattern in den Organisationen. Wird die Domain im Domain-Pattern einer Organisation gefunden, so wird diese Organisation dem neuen Kontakt zugewiesen.

Beispiel: An der Organisation "capeIT" sind die Domains "*kixdesk.com" und "*.capeIT.de" hinterlegt. Die bislang unbekannten E-Mail-Absender "info@capeIT.de" oder "mail@kixdesk.com" werden automatisch der Organisation "capeIT" zugeordnet.

Das Event wird ausgelöst, wenn beim Anlegen oder Aktualisieren eines Kontakts keine Organisation angegeben ist. Sofern (manuell) eine Organisation angegeben wurde, gilt diese. Der Automatismus greift dann nicht.

Das Event umfasst 3 Zuordnungs-Methoden, welche Sie nach Bedarf de-/aktivieren können. KIX arbeitet die Methoden in nachfolgend angegebener Reihenfolge ab. Ist eine Methode deaktiviert oder konnte eine Methode nicht erfolgreich angewendet werden (Fehler/kein Ergebnis), wird die nächste Methode geprüft und angewendet. Sind alle Methoden deaktiviert oder gab es Fehler bzw. kein Ergebnis, so wird keine Organisation am Kontakt gesetzt.

In diesem Konfigurationsschlüssel können Sie konfigurieren, welche Kontakt-Attribute in Volltextsuchen berücksichtigt werden sollen.

Das kann bspw. erforderlich sein, wenn die Kontaktsuche nach dem Namen der Organisation unscharfe Ergebnisse liefert. unscharfe Ergebnisse liefert. In diesem Fall können Sie konfigurieren, dass nicht nach dem Namen der Organisation gesucht werden soll, sondern nur nach Vor- und Nachname. Die Suchergebnisse werden somit optimiert.

Standardmäßig werden folgende Attribute durchsucht:

Passen Sie im Konfigurationsschlüssel den Parameter FulltextAttributes nach Bedarf an: Entfernen Sie die Attribute, die in der Volltextsuche keine Berücksichtigung finden sollen bzw. fügen Sie weitere Kontakt-Attribute hinzu.

Unterstützt werden alle Attribute, welche auf der Resource GET api/v1/objectsearch/Contact mit "IsFulltextable": 1 markiert sind.

Die Angabe Dynamischer Felder vom Typ Text, TextArea und Selection wird unterstützt.

Hinweis: Die Suche in Auswahlfeldern (Selection) berücksichtigt die internen Werte der Datenbank. Werte die nur im Anzeige-Wert enthalten sind, liefern keinen Treffer.

{
  "FulltextAttributes": [
    "Firstname",
    "Lastname",
    "Phone",
    "Mobile",
    "Email",
    "myDFContactSelection",
    "myDFShortName"
  ],
  "Module": "ObjectSearch::Database::Contact"
}

In KIX können einer Organisation weitere Organisationen untergeordnet werden. Die Organisationen können somit in einer hierarchischen Baumstruktur organisiert werden. Sie können diesen Konfigurationsschlüssel aktivieren, wenn der einer Organisation zugeordnete Kontakt virtuell auch allen zugehörigen Unterorganisationen zugeordnet werden soll.

Wenn aktiviert, werden einem Kontakt automatisch alle Organisationen zugeordnet, die seinen Organisationen direkt oder indirekt untergeordnet sind - auch ohne, dass diese explizit am Kontakt hinterlegt sind. Dies wirkt sich auf die Organisationsauswahl in Tickets, am Kontakt, in der Komplexsuche und im Self Service Portal aus. Agenten und Nutzer des Self Service Portals können somit auch die Tickets der untergeordneten Organisationen sehen.

Mögliche Werte: 0 - aktiv | 1 - inaktiv

Nach Änderungen am Konfigurationsschlüssel sollten Sie im Menü System → Konsole den Befehl Console::Command::Maint::Cache::Delete ausführen, um den Cache zu bereinigen. Gegebenenfalls müssen die Agenten ihr Frontend ebenfalls aktualisieren.

Bei Nutzung der Komplexsuche oder bei der Suche nach Kontakten in einem Ticket können Operatoren (&, +, |, *) verwendet werden, um nach mehreren Parametern zu suchen. So entsteht ein Suchstring, der von KIX verarbeitet wird, z. B. Max+Mustermann.

Das einer Telefonnummer vorangestellte + für die Landesvorwahl kann jedoch bei der kombinierten Suche von bspw. Name und Telefonnummer zu einem fehlerhaften Suchergebnis führen. KIX betrachtet das der Telefonnummer vorangestellte + als Operator und nicht als Teil der Telefonnummer. Somit ergibt die Suche nach "Max" und "+49123456" den Suchstring "Max+49123456" - und damit mit falscher Telefonnummer.

Sie können dies umgehen, wenn Sie die Verwendung von Wildcards im SysConfig-Schlüssel ContactSearch::UseWildcardPrefix aktivieren. Dadurch wird ein Wildcard-Präfix (* bzw. % auf Datenbankebene) als Platzhalter vor die gesuchten Parameter gesetzt. Der daraus resultierende Suchstring "*Max+*49123456" liefert ein korrektes Ergebnis, da alle den Ziffern vorangehende Zeichen berücksichtigt werden.

Die alleinige Suche nach der Telefonnummer, auch mit vorangestelltem +, ist hingegen unproblematisch.

Im Organisationen Dashboard ist für die Suche nach Organisationen bzw. Kontakten die Verwendung eines Wildcards (*) am Ende des Suchbegriffs nicht erforderlich. Es ist ausreichend, nur den Suchbegriff ins Suchfeld einzutragen. KIX setzt intern automatisch ein Sternchen nach dem Suchbegriff (Wildcard-Suffix). Gleiches gilt für die Autocomplete-Felder. Das Sternchen vor dem Suchbegriff (Wildcard-Präfix) wird aus Gründen der Performance nicht automatisch gesetzt. Es kann bei der Eingabe des Suchbegriffs vom Nutzer manuell gesetzt werden.

Für On-Premises (lokal) genutzte KIX-Instanzen auf PostgreSQL-Datenbankbasis oder Umgebungen mit überschaubarer Anzahl an Organisationen und Kontakten können Sie KIX so einrichten, dass das Wildcard- Präfix für Kunden und/oder Organisationen automatisch gesetzt wird. Sie können die Unterstützung des Wildcard-Präfixes getrennt für Organisationen und Kontakte in folgenden Konfigurationsschlüsseln de-/aktivieren:

Legt die vom System zu verwendende Standard-Priorität fest.

Diese wird automatisch am Ticket gesetzt, wenn vom Agent/Job/Aktion keine Priorität am Ticket gesetzt wurde oder gesetzt werden konnte.

Default: 3 normal

Festlegen der Standardsprache für das Frontend.

Default: de

Die Spracheinstellung beeinflusst sowohl die Bezeichnungen in den Benutzeroberflächen als auch die verwendeten Benachrichtigungen.

Hat der Nutzer kein Sprachschema gesetzt oder ist noch nicht authentifiziert, wird die Sprachkennung des Browsers verwendet. Ist diese nicht zuordenbar oder ist kein entsprechendes Schema vorhanden, wird die in diesem Schlüssel definierte Standardsprache verwendet.

Im Konfigurationsschlüssel sind die vom System zu verwendenden Sprachen hinterlegt. Initial werden Deutsch (de) und Englisch (en) verwendet; Französisch ist vorbereitet. Sie können weitere Sprachen ergänzen.

Abb.: Hinzugefügte Sprachen: Französisch und Italienisch

Das Ergänzen weiterer Sprachen kann erforderlich sein, wenn die Benutzeroberfläche auch in anderen Sprachen wie bspw. Französisch oder Italienisch zur Verfügung stehen soll.

Damit die Basiszeichenketten der Benutzeroberfläche auch in diese Sprache übersetzt werden, müssen Sie die Pattern für die Übersetzung manuell einpflegen (Menü Internationalisierung → Übersetzungen ).

Die hier angelegten Sprachen stehen in den Auswahlfeldern Sprache zur Auswahl (z. B. Persönliche Einstellungen, FAQ oder Konfiguration von Textbausteinen).

Legt fest, welcher Status automatisch am Ticket gesetzt wird, nachdem die Ziel-Wartezeit erreicht wurde.

Die Ziel-Wartezeit ist im SysConfig-Schlüssel Ticket::Frontend::PendigDiffTime angegeben.

Definiert die Ziel-Wartezeit für Tickets, die den Status Warten auf [...] erhalten.

Die hier angegebene Sekunden-Anzahl wird zur aktuellen Zeit hinzuaddiert. Das Ergebnis wird automatisch ins Feld Wartezeit gesetzt, wenn am Ticket ein Warten-Status ausgewählt wird.

Angegeben ist die Zeit in Sekunden.

In diesem Konfigurationsschlüssel können Sie globale Einstellungen für das Modul Tickets vornehmen.

Mit diesem Konfigurationsschlüssel können Sie die Basisberechtigungen der Agenten auf ehemalige Tickets erweitern.

Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).

Sie können den Konfigurationsschlüssel bei Bedarf aktivieren. Suchen und öffnen Sie dazu diesen Konfigurationsschlüssel im Menü System → SysConfig und setzen Sie die Gültigkeit auf gültig.

Wenn aktiviert (gültig): Agenten können auf ein Ticket zugreifen, welches zu irgendeinem Zeitpunkt in einem der unter Meine Teams (Persönliche Einstellungen des Agenten) gesetzten Teams war, auch wenn sich dieses Ticket jetzt in einem Team befindet, auf welches sie sonst keinen direkten Zugriff haben.

Der Parameter Permission definiert, welche Rechte die Agenten auf die betreffenden (ehemaligen) Tickets haben. Mögliche Werte sind:

Definiert, mit welchem Präfix die Tickets in der Ticket Detailansicht gekennzeichnet werden. Zum Beispiel:

Standard: Ticket#

Definiert, welches Modul für das Generieren der Ticketnummern verwendet wird. Das gewählte Modul bestimmt, wie die Ticketnummern aufgebaut sind.

Überprüft die SystemID bei der Erkennung von Ticketnummern in Rückfragen.

Default: 1

Verwenden Sie "0", wenn die SystemID nach der Verwendung des Systems geändert wurde.

Aktiviert den SysConfig-Schlüssel Ticket::NumberGenerator::MinCounterSize für den Ticketzähler, wenn "Date" oder "DateChecksum" als TicketNumberGenerator ausgewählt ist.

Legt die minimale Ticketzählergröße fest, wenn "AutoIncrement", "Date" oder "DateChecksum" als TicketNumberGenerator ausgewählt wurde.

Default: 5 (der Zähler beginnt bei 00001, z. B. 2022113017000011)

Beispiel: 3 (der Zähler beginnt bei 001, z. B. 20221130170011)

Setzt den Bearbeiter eines Tickets automatisch als Verantwortlichen am Ticket. Voraussetzung dafür ist, dass der Konfigurationsschlüssel Ticket::Responsible aktiviert (gültig) ist.

Dies funktioniert nur bei manuellen Aktionen des angemeldeten Benutzers. Bei automatisierten Aktionen, z. B. Automation, Postmaster und API, funktioniert dies nicht.