Fehler & Diagnose

Fehlercodes

FehlercodeBeschreibung
1000Domäne nicht gefunden!
Ursachen können sein:
  • Beispiel: Mustermann@firma1.de
    • Domäne, in dem Fall firma1.de ist im CI-Cloud Portal nicht registriert.
    • Siehe im CI Cloud-Portal unter: Unternehmens-Profil –> Domäne(n)
1001Kunde nicht gefunden!
Ursachen können sein:
  • Siehe Domäne nicht gefunden


Lösung: Melden Sie sich im CI-Cloud-Portal an. 14-Tage kostenfreier Testzeitraum.
1002Keine Signaturen für Sie gefunden!
Ursachen können sein:
  • Haken in der CI-Sign Konfiguration nicht gesetzt.
    • Gehen Sie hierfür auf die CI-Cloud –> Übersicht. Klicken Sie dann auf den schwarzen CI-Sign Button und setzen Sie den Haken für “Signaturen im Vorschau Add-In anzeigen.
  • CI-Sign nicht gebucht
1003Benutzer nicht gefunden!
  • Benutzer befindet sich nicht im Cache oder in der Azure!
    • Prüfen Sie die Gruppe, die unter Konnektoren angegeben ist.
1004E-Mail Adresse nicht gefunden!
Ursache dafür können sein:
  • Siehe Benutzer nicht gefunden.
1005Zugangsdaten nicht gefunden!
Ursachen können sein:
  • Unautorisierte Zugriff!
1006Vorschau zurzeit nicht verfügbar! Signatur wird dennoch beim versenden angehängt!
Ursachen dafür können sein:
  • Server für die Disclaimer Vorschau stehen zurzeit nicht zur Verfügung.
  • Die Signatur wird dennoch beim Versenden angefügt!
1007Ausgewählte Signatur nicht gefunden!
Ursachen können ein:
  • Server hat die angeforderte Signatur nicht mehr.
  • Aktualisieren Sie einmal, damit Sie den aktuellen Stand der Signaturen wieder haben!

Logdatei finden und prüfen

image-20220920083342838

Unter %temp% wird IMMER nach Ausführung von CI-Sign eine Logdatei als Testdokument erstellt.
Dazu am besten im Explorer in der Suche „CI-Sign“ eingeben und nach Änderungsdatum sortieren.
In vielen Fällen ist die Logdatei sehr aufschlussreich, prüfen Sie diese vorab, bzw. senden Sie uns diese zu.

Änderungen werden innerhalb der Signaturen nicht angezeigt

Falls Änderungen innerhalb der Signaturen nicht angezeigt werden:
Wir halten die Daten in einem Cache vor.
Signaturen werden alle 30 Minuten neu erzeugt.
Außer Sie ändern etwas an der Konfiguration, dann werden die Signaturen sofort aktualisiert.
Nehmen Sie hierfür einfach in der CI-Sign Konfiguration mal eine Option raus und wieder rein oder umgekehrt.
Benutzerdaten werden alle 60 Minuten aktualisiert, was Änderungen an Gruppe usw. angeht.
Wir abreiten daran, dass Sie zukünftig den Cache bei Bedarf sofort leeren können.

The remote server returned an error: (400) Bad Request

Betrifft:
CI-Sign CI-Cloud Version

Problem:
CI-Sign kann bei Ausführung keine Signaturen/Änderungen abrufen.

Ursache:
Virenscanner, Personal Firewall oder Ihre Firewall lassen über diese URL keine Daten herunterladen!
Hier ein Auszug aus einem Beispiel-LOG:

Information | 07/12/2023 13:27:11 | User | V: 7.0.0.53- Protocol need set to : TLS 1.2
Information | 07/12/2023 13:27:11 | User | Protocol is set to : TLS 1.2
Information | 07/12/2023 13:27:13 | User | Response Status Code is OK and StatusDescription is: OK
Information | 07/12/2023 13:27:13 | User | CheckNewUrl Returns: True
Error | 07/12/2023 13:27:13 | User | GetConfigurationFromCloud_API Ex: The remote server returned an error: (400) Bad Request.

Zunächst wird hier der neue Endpunkt abgefragt.

… CheckNewUrl Returns: True
Nun wird die Konfiguration aus der CI-Cloud abgeglichen:
Es wird also eine Datei angefordert.
…GetConfigurationFromCloud_API Ex: The remote server returned an error: (400) Bad Request.

Allerdings wird dieser Vorgang eben durch Ihr System unterbrochen.

Lösung:

Erstellen Sie für folgenden Endpunkt eine Ausnahme:

https://ci-service-365.ci-solution.com

Not able to receive user either from cache nor from azure

image-20221013151503918

Die o.g. Fehlermeldung stammt aus dem CI-Sign LOG.

Situation:

CI-Sign wird aus der CI-Cloud genutzt. CI-Sign wird dabei lokal ausgeführt.
Ein lokales AD ist nicht vorhanden, CI-Sign sucht den lokalen User also im CI-Cloud Benutzer Cache (1).

image-20220926131204271

Problem:

Es kann in diesem Beispiel jedoch kein Bezug hergestellt werden, der lokale Benutzeranmeldename wird gegen die Azure AD Attribute onPremisesSamAccountName und employeeId geprüft.

Ein Attribut muss matchen.

Lösung:

In diesem Fall haben Sie die Möglichkeit, im Azure AD die employeeId bzw. „Mitarbeiter-ID“ zu setzen.
Darüber können wir den Account dann finden.

https://portal.azure.com > Benutzer > Benutzer auswählen

“Mitarbeiter-ID” (“Employee-ID”) anpassen.

img

Azure Only User oder Gruppen werden von CI-Sign lokal nicht wunschgemäß verarbeitet

CI-Sign holt bei lokaler Ausführung die Daten für den angemeldeten User im Standard aus dem lokalen AD.
Wird der User nicht im AD gefunden, oder steht dieses nicht zur Verfügung, versucht CI-Sign den User
im CI-Cloud Benutzer Cache zu finden und die Daten (also Azure AD) zu holen.
Damit der User im CI-Cloud Benutzer Cache ist, muss dieser direktes Mitglied der synchronisierten Gruppe innerhalb des CI-Cloud Portals unter Nachrichtenfluss sein.

Es kann nun folgende Konstellationen geben, die durch den o.g. Ablauf zu einem nicht wunschgemäßen Ergebnis führen:

  • Die Daten für den angemeldeten User sind im AD unvollständig, nur im Azure AD vollständig.
    Problem –> Somit ist die Signatur auch unvollständig.

  • Die verwendete(n) Gruppe(n) zur Signatur Zuweisung sind Azure Only Gruppen.
    Problem –> Die User erhalten falsche oder keine Signaturen.

Um die o.g. Probleme zur vermeiden, sollte lokale AD sollte mittels “Azure AD Connect” mit dem Azure AD synchronisiert werden (empfohlen).

Ansonsten ist es möglich, das CI-Sign die Daten für den angemeldeten User immer aus dem CI-Cloud Benutzer Cache holt.

image-20221219143000682

Hierfür aktivieren Sie in der CI-Sign Konfig unter “CI-Cloud / EWS” (1) die Option “Benutzer aus CI-Cloud-Portal (sonst AD)” (2).