Tipps zur IPCC Express-Fehlerbehebung bei Problemen mit Upgrades, Backups und Wiederherstellung

Einführung

In diesem Dokument wird beschrieben, wie Sie Probleme mit CRS-Upgrades, -Backups und -Wiederherstellungen beheben können.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Cisco Unified Contact Center Express

• Cisco IP Telefony Backup and Restore System (BARS)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den Versionen Cisco Unified Contact Center Express 3.x, 4.x, 6.x und 7.x.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

CRS 3.x und 4.x: Häufige Fehler beim Sichern, Wiederherstellen und Upgrade

TCP-Socket unerwartet geschlossen

Wenn ein Backup/Restore/Upgrade (B/R/U) fehlschlägt, erhalten Sie möglicherweise eine (rot angezeigte) Meldung auf dem BARS-Bildschirm, die besagt, dass der TCP-Socket unerwartet geschlossen ist. Wiederherstellung/Backup/Upgrade fehlgeschlagen.

Diese Meldung ist allgemein gehalten und wird angezeigt, wenn bei der Sicherung/Wiederherstellung/Aktualisierung Fehler auftreten. Es ist kein Hinweis darauf, dass die TCP-Verbindung abbricht oder Netzwerkverbindungsprobleme zwischen dem CRS und den BARS-Geräten auftreten.

Applet-Kommunikationsfehler

Problem

CRS Backup/Restore/Patch/Upgrade schlägt in BARS fehl, da das Applet-Kommunikationsintervall (CRS Java Applet kann nicht in den Browser geladen werden, in dem BARS Admin innerhalb von 5 Minuten ausgeführt wird). Der BARS-Administrator zeigt, dass er die Archivdateien im Statusfenster extrahiert hat, und er scheint etwa 5 Minuten zu hängen, bevor er den Fehler meldet. Die MCVD/MARC-Protokolldatei zeigt den Fehlergrund als "Zeitüberschreitung bei der Initialisierung der Kommunikation von Applet" an. Dieses Problem ist in der Cisco Bug-ID CSCef91551 dokumentiert (nur registrierte Kunden).

Dieses Problem kann auftreten, wenn der Browser, der zum Ausführen von BARS Admin verwendet wird, nicht die erforderlichen Einstellungen enthält.

• Das Java-Plug-in ist noch nicht installiert oder es hat nicht die richtige Version von JRE oder das Java-Plug-in installiert.

  1. Klicken Sie im Dialogfeld Internetoptionen in Internet Explorer auf die Registerkarte Erweitert, und führen Sie einen Bildlauf nach unten zur Überschrift Java (Sun) durch.

  2. Stellen Sie sicher, dass das Kontrollkästchen Java 2 v.14.2_xx für <applet> verwenden aktiviert ist.

• Die Standardsicherheitseinstellung wurde geändert.

  1. Klicken Sie im Dialogfeld Internetoptionen auf die Registerkarte Sicherheit.

  2. Klicken Sie in der lokalen Intranetzone auf Standardstufe und stellen Sie sicher, dass die Sicherheitsstufe auf die Standardstufe (Mittel-Niedrig) oder niedriger eingestellt ist.

  3. Wenn Sie Ihre Sicherheitseinstellungen angepasst haben, klicken Sie auf Stufe anpassen, und stellen Sie sicher, dass die Java-Berechtigungen nicht auf Java deaktivieren eingestellt sind. Wählen Sie stattdessen eine der drei Sicherheitsstufen aus.

  4. Stellen Sie im Dialogfeld für die benutzerdefinierte Ebene sicher, dass Scripting von Java-Applets auf Aktivieren oder Auffordern eingestellt ist.

• Die Standardeinstellung zum Datenschutz wurde geändert.

  1. Klicken Sie im Dialogfeld Internetoptionen auf die Registerkarte Datenschutz.

  2. Vergewissern Sie sich, dass die Datenschutzeinstellung auf die Standardstufe (Mittel) oder niedriger eingestellt ist.

• Der im Browser konfigurierte Proxyserver ist nicht erreichbar.

  1. Klicken Sie im Dialogfeld Internetoptionen auf die Registerkarte Verbindungen und anschließend auf LAN-Einstellungen.

  2. Wenn ein Proxyserver konfiguriert ist, stellen Sie sicher, dass er erreichbar ist, oder deaktivieren Sie diese Option für die Verwendung eines Proxyservers.

• Die Sicherheitswarnung ist aktiviert.

  1. Klicken Sie im Dialogfeld Internetoptionen auf die Registerkarte Erweitert, und führen Sie einen Bildlauf nach unten zur Überschrift Sicherheit durch.

  2. Vergewissern Sie sich, dass das Kontrollkästchen Warn, wenn Sie zwischen gesichertem und ungesichertem Modus wechseln, deaktiviert ist.

Lösung

• Überprüfen Sie, ob die NIC-Bindung im CRS-Feld korrekt ist und es sich um NIC 1 gefolgt von NIC 2 handelt.

• Stellen Sie sicher, dass die CRS Box vom BARS-Server aus erreichbar ist.

• Stellen Sie sicher, dass der Popupblocker deaktiviert ist.

• Stellen Sie sicher, dass die im vorherigen Abschnitt erwähnten Richtlinien befolgt werden.

• Wenn Sie vom Browser aufgefordert werden, das Java-Plug-in-Installationsprogramm herunterzuladen und auszuführen, antworten Sie rechtzeitig mit "Ja". Die Wiederherstellung kann immer noch fehlschlagen, wenn die Installation länger als 5 Minuten dauert oder wenn die Installation einen Neustart des Browsers erfordert. In solchen Fällen starten Sie einfach den Browser neu und führen Sie die Wiederherstellung erneut mit dem gleichen Archiv aus. Reagieren Sie außerdem zeitnah auf die Popup-Dialogfelder des Internet Explorer-Browsers, da CRS das Zeitlimit überschreitet, wenn das Applet nicht in 5 Minuten im Browser geladen wird. Wenn es bereits ein Zeitlimit überschritten hat, starten Sie die Wiederherstellung einfach erneut.

Wenn das Problem weiterhin besteht, stellen Sie sicher, dass die Einstellungen korrekt sind, und führen Sie die folgenden Schritte aus:

1. Gehen Sie in Internet Explorer zu Extras > Sun Java Console, um die Java Console anzuzeigen.

   Hinweis: Wenn die von Ihnen verwendete Version von Internet Explorer diese nicht in der Menüleiste anzeigt, suchen Sie das Java-Logo in der Windows-Taskleiste, klicken Sie mit der rechten Maustaste auf das Logo, und wählen Sie Open Console (Konsole öffnen).

2. Wenn die Java Console geöffnet ist, drücken Sie die 5-Taste, um das Debuggen zu aktivieren.

3. Verwenden Sie BARS von diesem Internet Explorer-Browser, um die Wiederherstellung erneut auszuführen.

4. Wenn die Wiederherstellung wieder fehlschlägt, kehren Sie zum Java-Konsolenfenster zurück, kopieren Sie den gesamten Text und fügen ihn in eine Textdatei ein, um ihn zur Fehlerbehebung zu speichern.

LDAPProviderNicht verfügbare Ausnahme

Wenn die Sicherung mit der Fehlermeldung fehlschlägt, führen Sie die folgenden Schritte aus:

1. Überprüfen Sie die Protokolle auf folgende Werte: LDAP_CON_WARNING und LDAP_CON_ERROR. Wenn beide Werte vorhanden sind, ist der Backup-/Wiederherstellungs-/Upgrade-Prozess fehlgeschlagen, da das LDAP keine Verbindungen vom Cisco CRS akzeptiert.

2. Stellen Sie sicher, dass die LDAP-Server (CallManager(s)) über die Cisco CRS Box erreichbar sind. Rufen Sie den LDAP-Server auf, wenn er nicht ausgeführt wird.

3. Starten Sie den CRS-Server neu.

Hinweis: Dieses Problem ist in der Cisco Bug-ID CSCse15624 dokumentiert (nur registrierte Kunden).

Fehler: GET_FROM_ARCHIVE_REQUEST ist fehlgeschlagen mit dem Fehler:-2147417842

Problem

CRS backup\restore schlägt fehl, wenn der BARS-Server versucht, das BARS-Ziel zu sichern. In der BARS-Ablaufverfolgungsdatei (die sich im Ordner C:\Program Files\Cisco\Trace\BARS auf dem BARS-Server befindet) wird folgender Fehler angezeigt:

Inside function modGetFromArchive
Connecting to \\10.10.10.38\C$
modGetFromArchive =-2147417842
GET_FROM_ARCHIVE_REQUEST failed with error: -2147417842

Das BARS-Protokoll wird angezeigt:

Staging Cisco Customer Response Solutions target Ipcc
Opening session for backup on Ipcc
Opened session successfully on Ipcc
Backup is 1% complete.
Copying /STI/Backup/CRS/clusters.properties to
     C:\DOCUME~1\CRSADM~1\LOCALS~1\Temp\_8EF792BE_4448_46CF_9403_1006E8579197_20366\GetProperties23293.properties on 10.10.10.38
[Error]	Error: unable to load clusters.properties; nested exception is: 
	com.cisco.archive.ArchiveSystemIOException: UNSPECIFIED_ERROR; Failed to retrieve /STI/Backup/CRS/clusters.properties
Session closed successfully
[Error]	Could not backup Cisco Customer Response Solutions successfully on Ipcc.

Lösung

Gehen Sie wie folgt vor, um BARS auf dem BARS-Server herunterzufahren:

1. Schließen Sie alle Instanzen von Internet Explorer.

2. Gehen Sie auf dem BARS-Server zu Start > Programme > Verwaltung > Komponentendienste.

3. Erweitern Sie Komponentendienste > Computer > Arbeitsplatz > COM+-Anwendungen.

4. Klicken Sie im rechten Teilfenster mit der rechten Maustaste auf BARS, und wählen Sie Herunterfahren aus.

5. Starten Sie den Internetinformationsserver (IIS)-Admin-Dienst in der Dienststeuerung neu.

6. Führen Sie die fehlgeschlagene Wiederherstellung/Sicherung erneut aus.

Spezifische Probleme bei der Sicherung/Wiederherstellung/Aktualisierung gefunden

Ausgabe 1

Wenn Sie den RESTORE-Prozess erreicht haben, ermitteln Sie den Schritt und den genauen Prozentsatz des RESTORE-Prozesses, bei dem der Upgrade-Prozess fehlgeschlagen ist. Es gibt zwei Schritte für den Wiederherstellungsvorgang: Phase 1 und Phase 2.

• Phase 1: 0 - 19 % für "Wiederherstellen" und 0 - 33 % für "Patchen". In Phase 1 werden alle Informationen bis zur Sperrung des BARS bei CiscoMARC.log angemeldet. Wenn der Aktualisierungsvorgang während dieser Zeit fehlschlägt, lesen Sie CiscoMARC.log. In Phase 1 werden nur die Informationen auf Cluster-Ebene aktualisiert (CCNApps > Cluster > Profilename > clusterabhängig ou). Die Informationen auf Knotenebene (CCNApps > Cluster > Profilename > Nodes > nodeid > clusterabhängig ou) werden in Schritt 2 aktualisiert. Wenn BARS ausgesetzt wird, wird eine Liste der CRS-Server angezeigt, die neu gestartet werden müssen. Befolgen Sie anschließend den Prozess.

• Phase 2 beginnt nach 19 %, wenn der Cisco CRS-Server neu startet und BARS zur Wiederaufnahme bestätigt. Alle Informationen sind in MCVD.log angemeldet. Suchen Sie bei Fehlern im MCVD.log nach _FAILED. In CRS 4.x/6.x verwenden wir das CRS mit BARS für die Durchführung einer Sicherung/Wiederherstellung/Aktualisierung von vorherigen Versionen wie CRS 3.x/4.x.

Ausgabe 2

Gegen Ende der WIEDERHERSTELLUNG setzt BARS ein und wartet dann, bis das CRS erscheint. Sobald er ausgesetzt ist, schließt er den Socket. BARS wartet, bis das Signal vom CRS-Server kommt, sobald CRS 4.x installiert ist. Es ist normal, diese Nachricht in der barbi.log zu sehen:

596: Fri Aug 10 21:17:02.141 - TCPSocket::readFully err=10054
597: Fri Aug 10 21:17:02.141 - MessageReader can not read Message Header
598: Fri Aug 10 21:17:02.141 - .. release class com_cisco_archive_impl_barbi::
     AbstractSession *, refCnt: 11
599: Fri Aug 10 21:17:02.141 - .. release class com_cisco_archive_impl_barbi::
     InputStream *, refCnt: 1
600: Fri Aug 10 21:17:02.141 - .. release class com_cisco_archive_impl_barbi::
     BlockingPriorityQueue *, refCnt: 2
601: Fri Aug 10 21:17:02.141 - MessageReaderThread id=2264 completed, closed=0
602: Fri Aug 10 21:17:02.141 - .. release class com_cisco_archive_impl_barbi::
     Thread *, refCnt: 1
603: Fri Aug 10 21:17:02.141 - getMessage: null
604: Fri Aug 10 21:17:02.141 - getMessage from protocol layer returns null
605: Fri Aug 10 21:17:14.125 - TCPSocket::writeFully err=10054
606: Fri Aug 10 21:17:14.125 - HeartbeatDispatherThread returns SESSION_SOCKET_ERROR
607: Fri Aug 10 21:17:14.125 - .. release class com_cisco_archive_impl_barbi::
     AbstractSession *, refCnt: 10
608: Fri Aug 10 21:17:14.125 - .. release class com_cisco_archive_impl_barbi::
     OutputStream *, refCnt: 1
609: Fri Aug 10 21:17:14.125 - .. release class com_cisco_archive_impl_barbi::
     BlockingPriorityQueue *, refCnt: 1
610: Fri Aug 10 21:17:14.125 - HeartbeatDispatherThread id=3744 completed, closed=0
611: Fri Aug 10 21:17:14.125 - .. release class com_cisco_archive_impl_barbi::
     Thread *, refCnt

Ausgabe 3

Bei Cisco CRS 4.0(4)-Upgrades müssen Sie auf Nein klicken. Ich starte meinen Computer später mit dem Optionsfeld in Schritt 27 des Verfahrens Aktualisieren der Cisco CRS-Software im Fenster Maintenance Complete (Maintenance Complete) neu, um die 3.x-Version aus dem Registrierungsschlüssel zu löschen. Wenn Sie auf Ja klicken, möchte ich neu starten, schlägt der Upgrade-Prozess mit Fehlern fehl, z. B. ältere Version von 3.x existiert noch in Schritt 28 zwischen den Aufzählungszeichen e und f. Die oben genannten Informationen gelten für 4.0.5-Upgrades auf einem Server (gleichzeitig vorhanden) in Schritt 31 des Verfahrens zur Aktualisierung der Cisco CRS-Software.

Ausgabe 4

Wenn Sie ein Upgrade von Cisco CRS 3.5 auf Cisco CRS 4.0(5)/4.1(1)/6.0(1) durchführen, schlägt der Prozess in der spanischen Wiederherstellungsphase fehl, wenn die im Cisco Desktop Administrator konfigurierten Teamnamen einen Schrägstrich enthalten. Dieses Problem ist in der Cisco Bug ID CSCsj23469 dokumentiert (nur registrierte Kunden).

Lösung:

Im Cisco Desktop Administrator konfigurierte Teamnamen dürfen keinen Schrägstrich enthalten. Wenn ein Schrägstrich in einem Teamnamen vorhanden ist, führen Sie die folgenden Schritte aus, bevor Sie mit der Aktualisierung beginnen.

1. Öffnen Sie Cisco Desktop Administrator, und löschen Sie die Teamnamen, die einen Schrägstrich enthalten.

2. Erstellen Sie einen alternativen Teamnamen ohne Schrägstrich, und konfigurieren Sie die gleiche Zuordnung für den neuen Teamnamen.

   Hinweis: Wenn Teamnamen nicht ohne Schrägstriche wiederhergestellt werden, kann es während des Upgrades zu Fehlern kommen.

Ausgabe 5

Stellen Sie bei der Fehlerbehebung von Patching-Problemen sicher, dass der Pfad zur Patch-Archivdatei im CRS-Feld keine Leerzeichen enthält. Dieses Problem ist in der Cisco Bug ID CSCsa98554 dokumentiert (nur registrierte Kunden).

Ausgabe 6

Während des Upgrades von 3.x auf 4.0.4 sind nach der erfolgreichen Wiederherstellung das Enterprise Data Subsystem und das VOIP Monitoring Subsystem außer Betrieb. Überprüfen Sie die CDBRTool-Protokolle unter C:\programfiles\Cisco\Desktop\logs auf dem CRS-Server. Suchen Sie nach dem Fehler CDBRAPI::RestoreAllLCCs RestoreLCCData failed. Der folgende Protokollausschnitt ist relevant:

20:59:18 09/29/2007 MAJOR     CDBRPhonebookContact_200::PutPhonebookContactToLdap: 
     AddPhonebookContactProfile failed.  Return <2>.
20:59:18 09/29/2007 MAJOR     CDBRAPI::RestorePhonebookContacts  
     PutPhonebookContactToLdap failed.
20:59:18 09/29/2007 MAJOR     CDBRAPI::RestoreLCCData  RestorePhonebookContacts failed.
20:59:18 09/29/2007 MAJOR     CDBRAPI::RestoreAllLCCs  RestoreLCCData failed.
20:59:34 09/29/2007 INFO    LC0059 LDAPConnectionMgr::EstablishConnection: Connected to 
     LDAP server on <172.24.1.13>.
20:59:35 09/29/2007 INFO      CDBRAPI::RestoreCompany RestoreCompany ended.

Kehren Sie als Problemumgehung zur vorherigen CRS-Version zurück, und entfernen Sie den leeren Eintrag aus dem Telefonbuch im Cisco Desktop Administrator. Nehmen Sie jetzt die Sicherung für die alte Version von CRS, aktualisieren Sie auf 4.0, und führen Sie dann den Wiederherstellungs-Vorgang aus.

Dieses Problem wird durch die Cisco Bug ID CSCse63244 dokumentiert (nur registrierte Kunden).

Hinweis: Wenn der Rückgabecode 19 anstatt 2 lautet, vergewissern Sie sich, dass das Telefonbuch des Mitarbeiters kein Komma oder anderes Zeichen als eine Ziffer im Feld Telefonnummer enthält.

Ausgabe 7

Problem

Wenn Sie versuchen, die UCCX 7.X-Anwendung manuell zu sichern, wird dieser Fehler zurückgegeben: * 1326 - Anmeldefehler: unbekannter Benutzername oder ungültiges Kennwort.

Lösung

Um das Problem zu beheben, überprüfen Sie zunächst die MCVD-Protokolle (siehe Abschnitt Verfahren zur Analyse von Protokollen).

Wenn das verwendete Kennwort falsch ist, greift UCCX auf den Freigabeordner über die alten Anmeldeinformationen zu. Die Problemumgehungen für dieses Problem sind wie folgt:

• Behalten Sie die alten Anmeldeinformationen am Backup-Server-Standort bei.

• Wenn Sie das Benutzerkennwort auf dem Backup-Server ändern, aktualisieren Sie das Kennwort in UCCX, und starten Sie dann den UCCX-Server neu.

Gehen Sie andernfalls wie folgt vor:

1. Konfigurieren Sie ein Konto auf Ihrem Windows-Sicherungsserver.

2. Erstellen Sie einen neuen Sicherungsordner.

3. Weisen Sie dem neuen Benutzer die vollständige Kontrolle über den Ordner zu, und geben Sie den Ordner frei.

4. Legen Sie vom UCCX-Speicherort für Server-Backups den Pfadnamen auf \\<Backup-Server>\<freigegebener Ordner>, den Benutzernamen auf <Backup-Server>\<Benutzer-ID> und das Kennwort fest.

Dieses Problem ist im Cisco Bug ID CSCth19279 (nur registrierte Kunden) dokumentiert.

Erforderliche Protokolle für Backup/Wiederherstellung/Upgrade vom BARS-Server

• Die BARS-Sicherungs-/Wiederherstellungsprotokolle werden an diesen Speicherorten gespeichert:

  • C:\Program Files\Common Files\Cisco\Logs\BARS\Backup**

  • C:\Program Files\Common Files\Cisco\Logs\BARS\Restore**

• BARS Trace-Protokolle werden unter C:\Program Files\Cisco\Trace\BARS*.* gespeichert.

• BARS Barbi-Protokoll wird unter C:\WINNT\system32\barbi.log gespeichert.

Verfahren zum Analysieren von Protokollen

1. Überprüfen Sie die Sicherungsprotokolle (oder Wiederherstellungsprotokolle) unter C:\Program Files\Common Files\Cisco\Logs\BARS\Backup (oder Wiederherstellen) im BARS-Server.

2. Überprüfen Sie anhand des Zeitstempels die Ablaufverfolgungsprotokolle. Sie finden sie unter C:\Program Files\Cisco\Trace\BARS im BARS-Server.

3. Die Ablaufverfolgungsprotokolle enthalten kurze Informationen über die Ausnahme. Um die Details anzuzeigen, gehen Sie zum entsprechenden CRS-Server, und überprüfen Sie die MCVD-Protokolle für diesen Zeitraum. Suchen Sie in diesen Protokollen nach backup_failed, restore_failed, upgrade_failed mnemonics für den entsprechenden Ausfall des Vorgangs (B/R/U). Wenn der Fehler aufgetreten ist, bevor BARS mit 19 % unterbricht, überprüfen Sie die MARC-Protokolle.

4. Wenn Sie die im obigen Schritt angegebene Kurzbeschreibung erreicht haben, können Sie die genaue Beschreibung des Fehlers anzeigen. Sie sehen z. B. folgende Meldungen:

   • Applet-Kommunikationsfehler

   • Ausnahme für Datenbasis-Archivkomponenten

   • Spanlink Archive Component-Ausnahme

   • CDBR-Tool fehlgeschlagen

   Diese Meldungen sind informativ und zeigen den Fehler an, der durch B/R/U-Fehler verursacht wurde. Basierend auf der Komponente werden zusätzliche Protokolle wie folgt benötigt (mit Ausnahme der oben genannten):

   SL-Archivkomponente: c:\program files\cisco\desktop\log\CDBRTool.* DB-Archivkomponente:

Häufige Probleme beim Testen von Sicherungen und Wiederherstellungen mit CRS 6.0

Applet-Timeout-Problem

Problem

Das Applet reagiert nicht mehr, und der Wiederherstellungsvorgang schlägt fehl, wenn die Schaltfläche OK nicht während der Sicherheits- und Datenschutzwarnungen angeklickt wird. Diese Sicherheitswarnungen werden häufig im übergeordneten Fenster der BARS-Seite hinter dem untergeordneten Fenster angezeigt. In den Nachverfolgungsprotokollen können Sie dieses Problem lokalisieren, da eine Lücke von genau 5 Minuten besteht. Beispiel:

[06:49:34 PM]   Get next message
[06:54:34 PM]   FailureResponse id=2 from Session# 19, pArchiveId={C0E85DB3-D35-
                1-40FF-AE8F-6482B9A90D3B}, errorCode=UNSPECIFIED_ERROR, statusM-
                essage=timed out initializing applet's communication

Mögliche Lösungen

1. Ziehen Sie das untergeordnete Fenster manuell in die Ecke des Bildschirms, und reduzieren Sie die Fenstergröße, sodass die Mitte für Sicherheitswarnungen sichtbar ist.

2. Behalten Sie den Fokus auf die BARS-Hauptseite, und minimieren Sie das untergeordnete Fenster. Alle Popup-Dialogfelder im Auge behalten.

3. Reduzieren Sie unter Internetoptionen die Sicherheitseinstellungen und Datenschutzeinstellungen auf Niedrig, bevor Sie mit dem Wiederherstellungsprozess beginnen. Nach dem Wiederherstellungsvorgang zurückkehren. (Dies wird nicht empfohlen, da die Auswirkungen dieser Aktion aus der Browser-Sicherheitsperspektive nicht überprüft wurden.)

Upgrade von CRS 3.5 auf 6.0 bei eigenständiger Einrichtung

Das Upgrade auf CRS 3.5 auf 6.0 muss wie im Installationsleitfaden für Cisco Customer Response-Lösungen beschrieben befolgt werden. Ein Backup von CRS 3.5, eine erneute Bildgebung und der Versuch, diese über die CRS 6.0-Konfiguration wiederherzustellen, ist kein gültiges Szenario.

Da dies kein unterstütztes Szenario ist, besteht die einzige Problemumgehung darin, auf CRS 3.5 zurückzukehren.

CRS 4.0(x) bis 6.0-Upgrade

Wenn Sie während eines CRS 4.0-6.0-Upgrades ein anderes Lizenzpaket (nicht dasselbe Paket, das in CRS 4.0 hochgeladen wurde) nach dem Upgrade hochgeladen haben, zeigt der Lizenzpakettyp in AppAdmin auf der Seite mit den Lizenzinformationen "Keine" an, und einige der AppAdmin-Menüs fehlen.

Wenn der Kunde beispielsweise über CRS 4.1 mit einer Standardlizenz und Upgrades auf CRS 6.0 mit einer Premium-Lizenz verfügt, fehlen nach dem Upgrade auf CRS 6.0 einige Menüs in AppAdmin. Auf der Seite AppAdmin > Control Center > Lizenzinformationen wird als Lizenzpakettyp Keine angezeigt.

Lösung: Ändern Sie den CRS-Lizenzfilterwert in LDAP in den neuen Lizenztyp.

LDAP-Lizenzfilter-Eintrag: CCNApps/Cluster/<ProfileName>/ClsuterSpecific.xxxxx/License.xxxxx/FilterType

If the new license package is Standard , changes the FilterType to 3
If the new license package is Enhanced, changes the FilterType to 4
If the new license package is Premium, changes the FilterType to 5

Nachdem Sie die Änderungen im LDAP durchgeführt haben, starten Sie den CRS Node Manager auf dem CRS Server neu.

Der Installations-/Aktualisierungsprozess bleibt unbeaufsichtigt.

Die Installation, Aktualisierung und Wiederherstellung sind sehr wichtige Prozesse und müssen entsprechend dem Handbuch sehr sorgfältig befolgt werden. In manchen Fällen kann BARS in den Status Keine Antwort wechseln. Cisco empfiehlt, den gesamten Vorgang der Aktualisierung, Installation und Wiederherstellung mitzuverfolgen.

Verwendung des Pre-Upgrade-Tools

Wie im Installationsleitfaden beschrieben, müssen Sie das Pre-Upgrade Tool (PUT) ausführen, bevor Sie den Wiederherstellungsvorgang durchführen. Es wird verwendet, um die CRS 6.0-Lizenz in LDAP einzufügen, sodass das Backup-Archiv die 6.0-Lizenzen enthält.

BARS-Seite leer

Die BARS-Anzeigeseite wird während des Wiederherstellungsvorgangs gelegentlich leer. Dieses Problem wird durch die Cisco Bug ID CSCsa82969 dokumentiert (nur registrierte Kunden). Dies ist ein kosmetisches Problem. Um dieses Problem zu beheben, aktualisieren Sie das untergeordnete Fenster (drücken Sie F5). Dies sollte nur im BARS-Statusfenster und nicht im Haupt-BARS-Wiederherstellungsfenster geschehen.

Erfassung von BARS-Protokollen

Bevor Sie ein neues Image des Cisco CallManager-Servers erstellen, müssen die BARS-Protokolle gespeichert werden. Weitere Informationen finden Sie unter Protokolle, die für Backup/Wiederherstellung/Upgrade erforderlich sind. Die Dateidetails werden im Administratorleitfaden für das Cisco IP Telefony Backup and Restore System (BARS) beschrieben.

Backups schlagen mit diesem Fehler fehl: * 86 - Beim Herstellen einer Verbindung zum Host ist ein unbekannter Fehler aufgetreten.

Problem

Geplante und manuelle Sicherungen fehlschlagen mit Fehler * 86 - Unbekannter Fehler ist bei der Verbindung mit dem Host aufgetreten. Das Backup-System akzeptiert Netzwerkpfad- und Kontoinformationen, aber die Sicherung schlägt fehl.

Lösung

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

1. Rufen Sie den UCCX-Server auf, navigieren Sie zu Start > Ausführen, und geben Sie CET ein.

2. Wenn die Warnmeldung angezeigt wird, klicken Sie auf Nein.

3. Wählen Sie com.cisco.crs.cluster.config.ArchiveAdminConfig aus.

4. Doppelklicken Sie auf der rechten Seite auf die Datensatz-ID.

5. Klicken Sie auf die Registerkarte com.cisco.crs.cluster.config.ArchiveAdminConfig, und löschen Sie das Kennwort unter Backup Storage.

6. Klicken Sie auf Übernehmen.

7. Navigieren Sie zu Appadmin > Tools > Backup and Restore.

8. Geben Sie unter Speicherort für Backup-Speicher das neue Kennwort ein, und klicken Sie auf Aktualisieren.

Nachdem Sie diese Schritte ausgeführt haben, können Sie die Sicherung ausführen. Wenn die Sicherung fehlschlägt, starten Sie den Server neu, und versuchen Sie die Sicherung erneut. Wenn die Sicherung immer noch fehlschlägt, können Sie zum CET navigieren, alle Felder löschen und die neuen Informationen für den Speicherort eingeben.

UCCX 7.x: BARS-Sicherungsfehler

Problem

Die BARS-Sicherung schlägt mit der folgenden Fehlermeldung fehl:

%MCVD-AC_SPANLINK-7-UNK:Exception thrown
while invoking and running BarsCLI:
Exception=com.cisco.archive.ArchiveException: 
BarsCLI failed to backup Spanlink config

Dieses Problem ist in der Cisco Bug ID CSCsy04635 dokumentiert (nur registrierte Kunden).

Lösung

Um dieses Problem zu beheben, starten Sie den Node Manager neu.

UCCX 8.x: BARS-Sicherung fehlschlägt bei 87 %

Problem

Die Sicherung hängt bei 87 % ab, wobei CCXCOMPONENT einen Fehler von 30 % gibt.

Lösung

Führen Sie zur Behebung dieses Problems diesen Befehl über die Befehlszeilenschnittstelle aus:

utils service restart Cisco DRF Master

UCCX 7.x-Wiederherstellung aus Sicherung hat einen Wert von 15 %

Problem

Wenn Sie versuchen, eine Datensicherung von UCCX 7.x wiederherzustellen, liegt sie bei 15 %, und Sie erhalten die folgende Fehlermeldung:

Da die Sicherung durchgeführt wurde, wenn HA und dieser andere Knoten derzeit nicht im Cluster vorhanden ist, kann sie nicht fortgesetzt werden.

Lösung

Da die Sicherung in einer Hochverfügbarkeitsumgebung durchgeführt wurde, müssen sich beide Knoten im Cluster befinden, damit Sie die Informationen wiederherstellen können. Sie können die Sicherungsdateien in einer Hochverfügbarkeitsbereitstellung wiederherstellen, indem Sie eine der folgenden Optionen verwenden:

• Wenn die Hochverfügbarkeits-Konfiguration bereits vorhanden ist und beide Knoten im gleichen Cluster hinzugefügt werden, ähnelt der Wiederherstellungsprozess der Bereitstellung mit einem Knoten. Sie kann von jedem Knoten aus durchgeführt werden und stellt Daten auf beiden Knoten wieder her.

• Wenn die Hochverfügbarkeits-Konfiguration nicht vorhanden ist und beide Knoten frisch installiert oder neu erstellt wurden, bevor Sie Unified CCX installieren, führen Sie die folgenden Schritte aus, um Folgendes wiederherzustellen:

  1. Initiieren Sie den Wiederherstellungsprozess vom ersten Knoten aus. Die Wiederherstellung wird 15 % abgeschlossen und fordert Sie auf, den zweiten Knoten zum Cluster hinzuzufügen.

  2. Fügen Sie den zweiten Knoten über den Setup-Assistenten hinzu. Wenn Sie den zweiten Knoten hinzufügen, ist die Wiederherstellung abgeschlossen, und die Hochverfügbarkeits-Einrichtung ist bereit.

Wiederherstellung schlägt fehl bei 69 %

Problem

Wenn Sie ein Upgrade von UCCX 4.5-Server auf 7.0 durchführen, schlägt die Wiederherstellung der UCCX 4.5-Daten mit dem folgenden Fehler fehl:

Exception occured while contacting the Call Manager com.cisco.archive.ArchiveException:
Unable to process restore request; nested exception is:
com.cisco.archive.ArchiveException: Exception thrown while downloading Recordings to the
Recording Folder:C:\Program Files\Cisco\Desktop_Audio

Exception=com.cisco.archive.impl.ArchiveFailureException: Unable to contact Call Manager.
Please make sure that the Call Manager is running and connected to the network
com.cisco.wf.spanlinkBackupRestore.SLRcrdgArchiveComponent; nested exception is:
com.cisco.archive.ArchiveException: Unable to process restore request; nested exception
is:com.cisco.archive.ArchiveException: Exception thrown while downloading Recordings to the
Recording Folder:C:\Program Files\Cisco\Desktop_Audio

Lösung

Dieses Problem ist in Cisco Bug ID CSCsr56145 (nur registrierte Kunden) dokumentiert. Die Lösung besteht darin, das 7.0(1)-System mit der neuesten Service Release (SR) zu patchen und die Wiederherstellung erneut auszuführen.

Zugehörige Informationen

• Die Wiederherstellung der UCCX-Daten schlägt fehl und es wird die Fehlermeldung "Fehler beim Aktualisieren des primären CRS-Konfigurationsdatenspeichers in Knoten 1" angezeigt.
• Technischer Support und Dokumentation - Cisco Systems