Webex für BroadWorks-Fehlerbehebungsprozesse

Eskalieren eines Problems

Nachdem Sie einige der Anweisungen zur Fehlerbehebung befolgt haben, sollte eine angemessene Idee davon sein, wo das Problem gerootet wird.

1

Sammeln Sie so viele Informationen wie möglich von den Systemen, die mit dem Problem in Verbindung stehen

2

Wenden Sie sich an das entsprechende Team von Cisco, um einen Fall zu öffnen (siehe Abschnitt "Kontakte")

Welche Kundeninformationen müssen gesammelt werden?

Wenn Sie der Ansicht sind, Sie müssen einen Fall öffnen oder ein Problem eskalieren, erfassen Sie während der Fehlerbehebung mit dem Benutzer die folgenden Informationen:

  • Benutzeridentifikator: CI-E-Mail-Adresse oder Benutzer-UUID (dies ist der Webex-Bezeichner, aber wenn Sie auch den BroadWorks-Bezeichner des Benutzers erhalten, hilft dies)

  • Organisationsbezeichner

  • Ungefährer Zeitraum, in dem das Problem zu erleben war

  • Clientplattform und -version

  • Senden oder Sammeln von Protokollen vom Client

  • Tracking-ID wird auf dem Client angezeigt

Überprüfen Sie die Benutzerdetails in Helpdesk

1

Melden Sie sich bei https://admin.webex.com/helpdesk an.

2

Suchen Sie nach einem Benutzer und klicken Sie anschließend auf diesen. Dadurch wird der Übersichtsbildschirm des Benutzers geöffnet.

3

Klicken Sie auf Benutzername, um eine detaillierte Benutzerkonfiguration zu sehen.

Nützliche Informationen in dieser Ansicht umfassen die UUID des Benutzers, ein CI-Cluster, ein Webex-App-Cluster, Anrufverhalten, BroadWorks-Konto-GUID.

4

Klicken Sie auf Kopieren, wenn Sie diese Informationen in einem anderen Tool verwenden müssen, oder hängen Sie sie an einen Cisco-Fall an.

Anzeigen der Kundenorganisation in Helpdesk

1

Melden Sie sich bei https://admin.webex.com/helpdesk an.

2

Suchen Sie nach einem Unternehmen des Kunden, und klicken Sie dann auf den Namen der Kundenorganisation.

3

Scrollen Sie nach unten, bis die Kundenportalansicht angezeigt wird, und klicken Sie auf Kundenname anzeigen, um eine schreibgeschützte Ansicht der Kunden-Organisation zu sehen, einschließlich Benutzer und Konfiguration.

Abrufen von Benutzerprotokollen aus dem Partner Hub

Bei der Behebung von Problemen mit dem Desktop und mobilen Clients ist es wichtig, dass Partner (und TAC) die Client-Protokolle anzeigen können.

1

Bitten Sie den Benutzer, Protokolle zu senden.

2

Bitten Sie den Benutzer, die Anrufumgebung zu exportieren. Senden Sie Ihnen die Datei ced.dat.

3

Erhalten Sie die Clientprotokolle vom Partner Hub oder Helpdesk (siehe unten).

Partner Hub-Option:

  1. Melden Sie sich bei Partner Hub an und suchen Sie die Kundenorganisation des Benutzers.

  2. Wählen Sie Fehlerbehebung aus.

  3. Wählen Sie Protokolle aus.

  4. Suchen Sie nach dem Benutzer (per E-Mail).

  5. Sie können die Clientprotokolle als ZIP-Datei anzeigen und herunterladen.

Helpdesk Option:

  1. Melden Sie sich an, Helpdesk.

  2. Suchen Sie nach der Organisation.

  3. Klicken Sie auf die Organisation (öffnet den Übersichtsbildschirm).

  4. Scrollen Sie nach unten, um auf Kunden anzeigen zu klicken.

  5. Wählen Sie Fehlerbehebungaus.

  6. Wählen Sie Protokolleaus.

  7. Suchen Sie nach dem Benutzer (per E-Mail).

  8. Sie können die Clientprotokolle als ZIP-Datei anzeigen und herunterladen.

So finden Sie die Client-Version

1

Geben Sie diesen Link an den Nutzer weiter: https://help.webex.com/njpf8r5.

2

Bitten Sie den Nutzer, Ihnen die Versionsnummer zu senden.

Client-Prüfung für Anrufdienst

1

Melden Sie sich beim Webex-Client an.

2

Überprüfen Sie, ob das Symbol "Anrufoptionen" (ein Handset mit einem Zahnrad darüber) in der Seitenleiste angezeigt wird.

Wenn das Symbol nicht vorhanden ist, ist der Benutzer möglicherweise noch nicht für den Anrufdienst in Control Hub aktiviert.

3

Öffnen Sie das Menü Einstellungen/Einstellungen und gehen Sie zum Abschnitt Telefondienste. Während der Sitzung, SSO Sie angemeldet sind, sollte der Status angezeigtwerden.

(Wenn ein anderer Telefondienst, z. B. Webex Callingwird angezeigt, verwendet der Benutzer nicht Webex für BroadWorks.)

Diese Verifizierung bedeutet:

  • Der Client hat die erforderlichen Webex-Microservices erfolgreich überquert.
  • Der Benutzer wurde erfolgreich authentifiziert.
  • Dem Client wurde ein langlebiges JSON-Webtoken von Ihrem BroadWorks-System ausgestellt.
  • Der Client hat sein Geräteprofil abgerufen und sich bei BroadWorks registriert.

Erhalten Kundenprotokolle oder Feedback

  • Im Abschnitt "Ressourcen" können Sie nach bestimmten Client-Protokollen auf Webex-Desktopclients suchen oder Benutzer zum Senden von Protokollen auffordern.

  • Bitten Sie Benutzer von mobilen Clients, Protokolle zu senden. Sie können sie dann über die Partner-Hub oder den Help Desk erhalten.


Das Senden von Protokollen ist unbestummt. Wenn ein Benutzer jedoch Feedback sendet, wird es an das Cisco Webex-Devops-Team gehen. Stellen Sie sicher, dass Sie die Feedback-Nummer des Nutzers aufzeichnen, wenn Sie Cisco weiter verfolgen möchten. Zum Beispiel:

Anrufumgebungsdaten erhalten

Webex-Clientprotokolle sind stark umgekämmt, um persönlich identifizierbare Informationen zu entfernen. Sie sollten die Anrufumgebungsdaten aus dem Client in derselben Sitzung exportieren, in der Sie das Problem bemerken.

1

Klicken Sie im Client auf das Profilbild, und klicken Sie dann auf Hilfe> Anrufumgebungsdaten exportieren.

2

Speichern Sie die resultierende Datei ced.dat, um Probleme bei Anrufen für diesen Benutzer zu beheben.

Wichtig: Wenn Sie sich vom Client abmelden oder neu starten, wird der interne Cache leert. Wenn Sie anschließend ced.dat exportieren, entsprechen die exportierten Daten keinen Protokollen, die vor dem Cache gesendet wurden.

Webex-Datenbank zurücksetzen

1

Klicken Sie auf dem Client > auf > Integritätsprüfung.

2

Wählen Sie Datenbank zurücksetzenaus.

Dies löst einen vollständigen Reset des Clients aus und lädt den Anmeldebildschirm der Webex-App.

Webex sollte sich bei BroadWorks registrieren

Die Webex-App überprüft die folgenden Informationen, um festzustellen, ob eine Registrierung bei BroadWorks durchgeführt werden soll:

  • Benutzerberechtigung für Broadworks-Connector

  • Anrufverhalten für Organisation und Benutzer

Überprüfen des Anrufverhaltens und der Connector-Berechtigung eines Benutzers

  1. Melden Sie sich an Helpdesk (https://admin.webex.com/helpdesk) mit Ihren Partneradministrator-Anmeldeinformationen an.

  2. Suchen Sie nach dem Benutzer.

  3. Klicken Sie auf den Benutzer und überprüfen Sie den Eintrag Anrufverhalten. Dies sollte "In Webex anrufen" sein.

  4. Klicken Sie auf Benutzername, um den Bildschirm Benutzerdetails zu öffnen.

  5. Scrollen Sie nach unten, um den Abschnitt Berechtigungen zu finden, und stellen Sie sicher, dass broadworks-connector enthalten ist.


    Ein Webex-Benutzer für BroadWorks sollte NICHT die bc-sp-Standardberechtigung haben, wenn er Webex für BroadWorks verwenden möchte. Dies ist die Berechtigung für "Webex Calling (Broadcloud)", bei dem die Webex-App über einen von Cisco verwalteten Cloud-Anrufdienst anruft.

Überprüfen des Anrufverhaltens der Organisation

  1. Melden Sie sich an Helpdesk (https://admin.webex.com/helpdesk) mit Ihren Partneradministrator-Anmeldeinformationen an.

  2. Suchen Sie nach der Organisation.

  3. Klicken Sie auf die Organisation und überprüfen Sie den Eintrag Anrufverhalten. Dies sollte "In Webex anrufen" sein.

PSLog für Probleme mit der Benutzerbereitstellung analysieren

Verwenden Sie das PSLog des Anwendungsservers, um die HTTP POST-Anforderung zur Bereitstellungsbrücke und die Antwort von Webex zu sehen.

Im korrekten Arbeitsfall beträgt die Antwort 200 OK, und nach einigen Minuten können Sie den Benutzer – und die neue Kunden-Organisation, wenn es sich um den ersten Benutzer handelt – in Webex erstellen.

Sie können dies verifizieren, Helpdesk E-Mail-Adresse im POST finden.

Vorbereitungen

Sammeln Sie eine PSLog vom Anwendungsserver während eines Flowthrough-Bereitstellungsversuchs mit einem Testbenutzer.

1

Der erste zu überprüfende Punkt ist der HTTP-Antwortcode:

  • Alles andere als 200 OK ist ein Fehler bei der Benutzerbereitstellung.

  • 200 OK könnte immer noch einen Fehler anzeigen, wenn etwas am Abonnentenprofil in den Webex-Diensten, die an der Provisioning-Bridge angeschaltet sind, nicht funktioniert.

  • In der Antwort kann 400 einen Nachrichtenknoten enthalten. Die Bereitstellungsbrücke konnte etwas im Abonnentenprofil nichtverarbeiten. Möglicherweise stimmt etwas mit den Abonnentendetails oder mit einer Einstellung in der Vorlage nicht zusammen.

  • 401 bedeutet, dass die im AS eingegebenen Bereitstellungsnachweise nicht mit den in der Vorlage im Partner Hub eingegebenen Anmeldeinformationen übereinstimmen.

  • 403 könnte auf etwas falsch konfiguriertes Auf Anwendungsserver hindeuten. Überprüfen Sie das Ziel der Anfrage. es sollte keine IP-Adresse sein, es sollte die Bereitstellungs-Bridge-URL sein, die Sie in Ihrer Vorlage im Partner Hub sehen können.

  • 409 zeigt einen Konflikt zwischen dem gelieferten Abonnentenprofil und bestehenden Webex-Daten an. Möglicherweise gibt es einen Benutzer mit dieser E-Mail-Adresse. Überprüfen Sie die Nachricht in der Antwort.

2

Sie können auch das ursprüngliche HTTP POST auf möglicherweise möglicherweise fehlschlagende Werte überprüfen, die zu einem Ausfall der Bereitstellung führen könnten.

Post enthält eine SubscriberProfile XML-Struktur. In dieser sind die nützlichen Knoten, die Sie überprüfen können, wie:

  • -user: Verwenden Sie diese Datei, um das Abonnentenprofil zu finden, wenn Sie es in BroadWorks bearbeiten müssen.

  • Gruppe: Wenn die Vorlage im "Dienstleister"-Modus vor sich geht, wird sie als Name der Kunden-Organisation angezeigt, die im Partner Hub angezeigt wird.

  • serviceProvider: Wenn die Vorlage im "Enterprise-Modus" angezeigt wird, wird diese kleinformatiert und wird zum Namen der Kunden-Organisation, die im Partner Hub angezeigt wird.

  • primaryPhoneNumber(Telefonnummer): Muss vorhanden sein. Die Bereitstellung schlägt ohne sie fehl.

  • E-Mail-Adresse: Wird zum Benutzer-ID in Webex. Muss für Webex gültig und eindeutig sein, andernfalls schlägt die Bereitstellung fehl.


 

Die Dienste ignorieren: es wurde von AS erstellt und akzeptiert, aber nicht von Webex verwendet.

Analysieren von XSP-Protokollen zur Fehlerbehebung bei der Abonnenten-Anmeldung

Dieser Ablauf beschreibt den BroadWorks-Authentifizierungsmodus. Sie können den Authentifizierungsmodus auf der BroadWorks-Vorlage im Partner Hub sehen. Siehe Kundenvorlagen konfigurieren in https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Der folgende Kontaktplan zeigt die Interaktion zwischen dem Benutzer, dem Client, den Webex-Services und dem BroadWorks-System an, wenn der Benutzer eine BroadWorks-Authentifizierung in der Webex-App vor sich hat. Außerdem ist die Verbindung zwischen Webex und XSP durch MTLS gesichert.

In der folgenden Diskussion wird erklärt, was zu erwarten ist, wenn Sie die Protokolle für eine erfolgreiche Anmeldung untersuchen.

Abbildung 1. BroadWorks-Authentifizierung und Gerätekonfiguration

Der Benutzer interagiert mit dem Client, der Client interagiert mit Webex-Diensten:

  • Der Benutzer gibt seine E-Mail-Adresse an die Webex-App an (1 im Diagramm).

  • CI weiß, dass dieser Benutzer umgeleitet wird, um sein BroadWorks-Passwort einzugeben (über UAP) (2 im Diagramm).

  • Der IDP-Proxy übermittelt eine Anforderung zum Erhalten eines Profils an die Xsi-Schnittstelle auf XSP.

Im Tomcat-access_log:

  • Suchen Sie nach der GET-Anforderung für das Abonnentenprofil, von Webex zur Xsi-Actions-Schnittstelle (2.1 im Diagramm). Sie verfügt über die Webex-Benutzer-ID. E.g.

    GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

Im XsiActionsLog:

  • Suchen Sie nach der GET-Profilanfrage von Webex (2.1 im Diagramm). Sie verfügt über die Webex-Benutzer-ID. E.g.

    GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

    Die Kopfzeilen enthalten Autorisierung: Basic und User-Agent: broadworksTeamsClient

  • Das XSP führt dann OCI-P Basic-Authentifizierung gegen BroadWorks (AuthenticationVerifyRequest und AuthenticationVerifyResponse, wie jede andere Anwendung, die grundlegende Authentifizierung über Xsi aus) sowie einen UserGetRequest und ServiceProviderGetRequest aus, um die Abonnenteninformationen zu erfassen.

  • Die Xsi-Antwort auf Webex enthält einen XML-Profilblock, der die Benutzer-ID (BroadWorks) und andere Details enthält (im Diagramm 2.2).

Interaktionen zwischen Client- und Webex-Diensten:

  • IDP-Proxy stimmt mit Benutzerprofil von BroadWorks erhaltenen Und Problemen der SAML-Assertion mit dem Client ab (2.3 im Diagramm)

  • SamL-Assertion für den Client-Austausch für ein CI-Token (3 im Diagramm)

  • Der Client überprüft, ob der angemeldete Benutzer über die Broadworks-Connector-Berechtigung verfügt (4 im Diagramm). Sie können die Benutzerberechtigungen in der Helpdesk)

  • Client verwendet CI Token, um einen JSON Web Token (JWT) vom IDP-Proxy an fordern (5 im Diagramm)

  • IDP-Proxy validiert CI-Token bei CI

  • IDP-Proxy fordert JWT vom Authentifizierungsdienst an

Im Authentifizierungsserviceprotokoll:

  • Suchen Sie nach der Tokenanforderung von Webex (5.2 im Diagramm), z. B.:

    GET /authService/token

    die http_bw_userid Kopfzeile und andere hat.

  • XSP führt OCI-P UserGetLoginInfoRequest aus, um zu überprüfen, ob die angegebene Nutzer-ID einem BroadWorks-Benutzer entspricht (im Diagramm 5.3). AuthService hat aufgrund der mTLS-Verbindung eine Vertrauensstellung mit Webex aufgebaut, sodass LLT aus angezeigt werden kann.

  • Suchen Sie nach der Antwort (im Diagramm 5.4) von LongLivedTokenManager – Token generiert, Betreff: bwksUserId@example.com, Aussteller: BroadWorks ...

    und StatusCode=200, die Sie mit der TrackingID der ursprünglichen Anfrage zuordnen können: CLIENT... Header.

Im XsiActionsLog:

  • Der Client kann nun das langlebige Token auf der Xsi-Actions-Benutzeroberfläche präsentieren, um sein Geräteprofil abzurufen (6 im Diagramm). E.g.:

    GET /com.broadsoft.xsi-actions/v2.0/user/ksUserId%40example.com/profile/device

    Mit der Überschriftenautorisierung: Inhabertoken und Benutzer-Agent: WebexTeams(Variante/Version)

  • Die Xsi-Actions-Schnittstelle POSTs das Token zum Authentifizierungsservice (konfiguriert, um auf der Loopback-Schnittstelle zu sein), z. B.: 127.0.0.1:80 NACH http://127.0.0.1:80/authService/token

    die Sie mit der trackingid in Beziehung setzten: CLIENT... Kopfzeile in der Kopfzeile GET und X-BROADSOFT-CORRELATION-ID: CLIENT... im POST -Header.

Im Authentifizierungsserviceprotokoll:

  • Empfang des POST von Xsi (Loopback)

  • Ein StatusCode=200 zurück zu Xsi

  • Und eine Tokenvalidierungsantwort mit einem "Token"-JSON-Block im Text.

  • Mit der trackingid korreliert: Kunde...

Im XsiActionsLog:

  • Nachdem sie 200 OK von authservice erhalten haben, wodurch das Token des Clients validiert wurde, sendet die Xsi-Actions-Anwendung jetzt eine OCI-P-Anforderung für UserPrimaryAndSCADeviceGetListRequest

  • Empfängt OCI-P UserPrimaryAndSCADeviceGetListResponse, die die accessDeviceTable-XML-Struktur enthält.

  • Die OCI-P-Antwort wird als Xsi-Antwort an den Client codiert, einschließlich der AccessDevices-XML-Struktur, die über die DeviceTypes verfügt (z. B. Business Communicator – PC) und die URLs, über die der Client die Gerätekonfigurationsdateien abrufen kann.

Client wird normal fortgesetzt:

  • Wählt einen Geräteeintrag aus und interagiert mit DMS, um ein Geräteprofil zu erhalten (6 im Diagramm)

  • Registrierung bei BroadWorks über SBC in Konfiguration vom DMS abgerufen (im Diagramm 7)