Conseils de dépannage d'IPCC Express pour la mise à jour, la sauvegarde, et les questions de restauration

Introduction

Ce document décrit comment dépanner la mise à jour CRS, la sauvegarde, et les questions de restauration.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco Unified Contact Center Express

• Système de sauvegarde de Téléphonie sur IP de Cisco et de restauration (BARRES)

Composants utilisés

Les informations dans ce document sont basées sur des versions 3.x de Cisco Unified Contact Center Express, 4.x,6.x, et 7.x.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

CRS 3.x et 4.x : Erreurs communes reçues pendant la sauvegarde, la restauration, et la mise à jour

Socket de TCP fermé inopinément

Quand un de sauvegarde/restauration/mise à jour (B/R/U) échoue, vous pourrait recevoir un message (affiché en texte rouge) sur l'écran de BARRES ce des états que le socket de TCP s'est fermés inopinément. La restauration/sauvegarde/mise à jour ont manqué.

Ce message est générique et affiché en cas de n'importe quelle panne dans l'exécution de sauvegarde/restauration/mise à jour. Ce n'est pas une indication de l'interruption de la connexion TCP ou d'aucune question de connexion réseau entre les CRS et les ordinateurs de BARRES.

Erreur de communication d'applet

Problème

La sauvegarde/restauration/correctif/mise à jour CRS échoue dans les BARRES dues à un délai d'attente attendant la transmission d'applet (l'applet Java CRS ne charge pas au navigateur en lequel BARRE des passages d'admin dans un délai de 5 minutes). L'admin de BARRES prouve qu'il a extrait les fichiers d'archivage dans la fenêtre d'état, et il semble s'arrêter pour environ 5 minutes avant qu'il signale la panne. Le fichier journal MCVD/MARC affiche la raison de panne en tant que « chronométré initialisant la transmission de l'applet. » Cette question est documentée dans l'ID de bogue Cisco CSCef91551 (clients enregistrés seulement).

Cette question peut se produire si le navigateur qui est utilisé pour exécuter l'admin de BARRES n'inclut pas les configurations priées.

• Le périphérique prêt à brancher de Javas n'est pas installé encore ou il ne fait pas installer la bonne version de JRE ou le périphérique prêt à brancher de Javas.

  1. Dans la boîte de dialogue d'options Internet de l'Internet Explorer, cliquez sur l'onglet Avancé, et le faites descendre l'écran au titre de Javas (Sun).

  2. Vérifiez que Java d'utilisation 2 v.14.2_xx pour le <applet > la case est cochée.

• Le paramètre de sécurité par défaut a été modifié.

  1. Dans la boîte de dialogue d'options Internet, cliquez sur l'onglet Sécurité.

  2. Pour la zone locale d'intranet, le niveau par défaut de clic et s'assurent que le niveau de Sécurité est placé au niveau par défaut (Support-bas) ou ci-dessous.

  3. Si vous personnalisiez vos paramètres de sécurité, cliquez sur le niveau fait sur commande, et assurez-vous que des autorisations de Javas n'est pas placées de désactiver Javas. Choisissez un des trois niveaux de sécurité à la place.

  4. Dans la boîte de dialogue de niveau faite sur commande, assurez-vous que le script des applet Java est placé pour activer ou inciter.

• La configuration par défaut d'intimité a été modifiée.

  1. Dans la boîte de dialogue d'options Internet, cliquez sur l'onglet d'intimité.

  2. Assurez-vous que la configuration d'intimité est placée au niveau par défaut (support) ou ci-dessous.

• Le serveur proxy qui est configuré dans le navigateur n'est pas accessible.

  1. Dans la boîte de dialogue d'options Internet, cliquez sur l'onglet de connexions, et puis cliquez sur les configurations de RÉSEAU LOCAL.

  2. Si un serveur proxy est configuré, assurez-vous qu'il est accessible ou décochez cette option pour l'usage d'un serveur proxy.

• L'alerte de sécurité est activée.

  1. Dans les options Internet dialoguez le bx, cliquez sur l'onglet Avancé, et le faites descendre l'écran au titre de Sécurité.

  2. Assurez-vous l'avertissement si changer entre la case sécurisée et non sécurisée de mode est décoché.

Solution

• Cochez si le NIC liant sur la case CRS est approprié et c'est NIC 1 suivi de NIC 2.

• Assurez-vous que la case CRS est accessible du serveur de BARRES.

• Assurez-vous que le bloqueur d'afficher est arrêté.

• Assurez-vous que les instructions mentionnées dans la section précédente est suivies.

• Une fois incité par le navigateur à télécharger et exécuter l'installateur de périphérique prêt à brancher de Javas, répondez avec l'oui de la manière opportune. La restauration pourrait encore échouer si l'installation prend plus long que 5 minutes ou si l'installation exige une reprise du navigateur. Redémarrez en pareil cas, simplement le navigateur, et réexécutez la restauration de nouveau avec les mêmes archives. En outre, répondez opportun dans les boîtes de dialogue instantanées de navigateur Internet Explorer l'un des, puisque des temps CRS si l'applet n'obtient pas chargé dans le navigateur en 5 minutes. S'il chronométrait déjà, redémarrez simplement la restauration de nouveau.

Si le problème persiste, assurez-vous que les configurations sont correctes, et puis terminez-vous ces étapes :

1. En Internet Explorer, allez aux outils > à la console Java de Sun afin d'afficher la console Java.

   Remarque: Si la version de l'Internet Explorer que vous utilisez n'affiche pas ceci dans la barre de menus, localise le logo de Javas dans la barre des tâches Windows, clique avec le bouton droit le logo, et choisit la console ouverte.

2. Une fois que la console Java s'ouvre, appuyez sur la touche 5 afin d'activer l'élimination des imperfections.

3. Employez les BARRES de ce navigateur Internet Explorer afin d'exécuter la restauration de nouveau.

4. Si la restauration échoue de nouveau, revenez à la fenêtre de console Java, copiez tout le texte, et collez-le dans un fichier texte afin de le sauvegarder pour dépannage du but.

Exception de LDAPProviderUnavailable

Si la sauvegarde échoue avec le message d'erreur, terminez-vous ces étapes :

1. Vérifiez les logs pour les valeurs suivantes : LDAP_CON_WARNING et LDAP_CON_ERROR. Si les deux valeurs existent, le de sauvegarde/restauration/processus de mise à niveau ont manqué parce que le LDAP ne reçoit pas des connexions du Cisco CRS.

2. Assurez-vous que les serveurs LDAP (CallManagers) sont accessibles de la case de Cisco CRS. Amenez le serveur LDAP s'il ne s'exécute pas.

3. Redémarrez le serveur CRS.

Remarque: Cette question est documentée dans l'ID de bogue Cisco CSCse15624 (clients enregistrés seulement).

Erreur : GET_FROM_ARCHIVE_REQUEST a manqué avec error:-2147417842

Problème

La sauvegarde \ restauration CRS échoue quand la sauvegarde de tentatives de serveur de BARRES BARRE la cible. Le fichier de suivi de BARRES (localisé dans le répertoire de C:\Program Files\Cisco\Trace\BARS sur le serveur de BARRES) affiche cette erreur :

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

Affichages de log de BARRES :

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.

Solution

Terminez-vous ces étapes afin d'arrêter des BARRES sur le serveur de BARRES :

1. Clôturez tous les exemples d'Internet Explorer.

2. Sur le serveur de BARRES, allez au Start > Programs > Administrative tools > des services composants.

3. Développez les services > les ordinateurs composants > mon ordinateur > applications COM+.

4. Dans le volet de droite, les BARRES de clic droit, et choisissent arrêté.

5. Redémarrez le service d'admin de l'Internet Information Server (IIS) du panneau de commande de contrôle des services.

6. Exécutez de nouveau la restauration/sauvegarde qui ont manqué.

Problématiques spécifiques trouvées pendant la sauvegarde/restauration/mise à jour

Question 1

Si vous avez atteint le processus de RESTAURATION, découvrez qui font un pas et le pourcentage précis du processus de RESTAURATION auquel le processus de mise à niveau a manqué. Il y a 2 étapes pour le processus de restauration : étape 1 et étape 2.

• L'étape 1 est de 0 - de 19% pour la restauration et de 0-33% pour corriger. Pendant le Stage1, jusqu'à ce que les BARRES s'interrompe, toutes les informations sont ouvertes une session à CiscoMARC.log. Si le processus de mise à niveau échoue pendant ce temps, regardez dans CiscoMARC.log. Il est pendant l'étape 1 seulement que les informations de niveau de batterie sont mises à jour (CCNApps > groupe > profilename > OU clusterdependent). Les informations de niveau de noeud (CCNApps > groupe > profilename > Noeuds > nodeid > OU clusterdependent) sont mises à jour pendant l'étape 2. Quand les BARRES s'interrompt, il donne une liste de serveurs CRS qui doivent être redémarrés. Suivez le processus ensuite.

• Débuts de l'étape 2 après 19%, quand le serveur de Cisco CRS redémarre donner l'accusé de réception aux BARRES pour reprendre. Toutes les informations sont MCVD.log ouvert une session. Recherchez _FAILED dans MCVD.log en cas de pannes. En CRS 4.x/6.x, nous utilisons les CRS avec des BARRES pour faire un de sauvegarde/restauration/mise à jour des versions préalables comme CRS 3.x/4.x.

Issue 2

Vers la fin de la RESTAURATION, les BARRES interrompt et puis attend des CRS pour monter. Une fois qu'il s'interrompt, il ferme le socket. Les BARRES attend le signal pour provenir le serveur CRS une fois que CRS 4.x sont installés. Il est normal de voir ce message dans barbi.log :

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

Question 3

Pour des mises à jour du Cisco CRS 4.0(4), vous devez cliquer sur l'aucun, je redémarrerez ma case d'option postérieure d'ordinateur dans l'étape 27 de la procédure améliorant le logiciel de Cisco CRS dans la fenêtre complète de maintenance afin de supprimer la version 3.x de la clé de registre. Si vous cliquez sur oui, je veux redémarrer, le processus de mise à niveau échoue avec des erreurs, telles qu'une version plus ancienne de 3.x existe toujours à l'étape 28 entre les puces e et F. Les informations ci-dessus s'appliquent pour 4.0.5 mises à jour de serveur unique (Co-résident) dans l'étape 31 de la procédure améliorant le logiciel de Cisco CRS.

Question 4

Quand vous améliorez du Cisco CRS 3.5 au Cisco CRS 4.0(5)/4.1(1)/6.0(1), le processus échoue pendant la phase de restauration de Spanlink si les noms d'équipe configurés à Cisco Desktop Administrator contiennent un slash. Cette question est documentée dans l'ID de bogue Cisco CSCsj23469 (clients enregistrés seulement).

Solution :

Les noms d'équipe configurés à Cisco Desktop Administrator ne peuvent pas contenir un slash. Si un slash existe dans n'importe quel nom d'équipe, terminez-vous ces étapes avant que vous commenciez la mise à jour.

1. Ouvrez Cisco Desktop Administrator, et supprimez les noms d'équipe qui contiennent un slash.

2. Créez un nom alternatif d'équipe sans slash et configurez le même mappage pour le nouveau nom d'équipe.

   Remarque: Le manque de recréer des noms d'équipe sans slashs pourrait avoir comme conséquence la panne pendant la mise à jour.

Question 5

Tout en dépannant les questions corrigeantes, assurez-vous que le chemin au fichier d'archivage de correctif dans la case CRS ne contient pas les espaces. Cette question est documentée dans l'ID de bogue Cisco CSCsa98554 (clients enregistrés seulement).

Question 6

Pendant la mise à jour de 3.x à 4.0.4, après que réussi restaurez, sous-système des informations de l'entreprise et VOIP surveillant le sous-système sont hors service. Vérifiez les logs de CDBRTool sous C:\programfiles\Cisco\Desktop\logs sur le serveur CRS. Recherchez l'erreur CDBRAPI : : RestoreAllLCCs RestoreLCCData a manqué. Voici l'extrait approprié de log :

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.

Comme contournement, retournez à la version précédente CRS et retirez l'entrée vide de l'annuaire téléphonique à Cisco Desktop Administrator. Maintenant, prenez la sauvegarde sur la vieille version des CRS, l'améliorez à 4.0, et puis exécutez l'exécution de restauration.

Cette question est documentée par l'ID de bogue Cisco CSCse63244 (clients enregistrés seulement).

Remarque: Si le code retour est 19 au lieu de 2, assurez-vous que l'annuaire téléphonique des employés ne contient une virgule ou aucun caractère autre qu'un chiffre numérique dans le champ Numéro de téléphone.

Question 7

Problème

Quand vous essayez manuellement à la sauvegarde l'application UCCX 7.X, cette erreur est retournée : * 1326 - Panne de connexion : nom d'utilisateur ou mot de passe incorrect inconnu.

Solution

Afin de résoudre le problème, vérifiez d'abord les logs MCVD (voir la procédure pour analyser la section de logs pour vérifier les logs).

Si le mot de passe utilisé est incorrect, l'UCCX emploie les vieilles qualifications afin d'accéder au dossier partage. Voici les contournements pour cette question :

• Gardez les vieilles qualifications au site serveur de sauvegarde.

• Si vous changez le mot de passe utilisateur sur le serveur de sauvegarde, mettez à jour le mot de passe dans l'UCCX, et puis la réinitialisation du serveur UCCX.

Autrement, terminez-vous ces étapes :

1. Configurez un compte dans votre serveur de sauvegarde de Windows.

2. Créez un nouveau répertoire de sauvegarde.

3. Assignez le nouveau plein contrôle d'utilisateur du répertoire, et partagez le répertoire.

4. De l'emplacement de sauvegarde de serveur UCCX, placez à de nom de chemin \ \ server> de <backup \ folder> <shared, le nom d'utilisateur au server> de <backup \ au < user-id >, et au mot de passe

Cette question est documentée dans l'ID de bogue Cisco CSCth19279 (clients enregistrés seulement).

Logs requis pour la sauvegarde/restauration/mise à jour du serveur de BARRES

• Des logs de sauvegarde/restauration de BARRES sont enregistrés à ces emplacements :

  • Fichiers de C:\Program Files\Common \ Cisco \ logs \ BARRES \ Backup*.*

  • Fichiers de C:\Program Files\Common \ Cisco \ logs \ BARRES \ Restore*.*

• Les BARRES tracent des logs sont enregistrées chez C:\Program Files\Cisco\Trace\BARS *.*

• Le log de Barbi de BARRES est enregistré chez C:\WINNT\system32\barbi.log

Procédure pour analyser des logs

1. Regardez dans les logs de sauvegarde (ou restauration) situés des fichiers de C:\Program Files\Common \ Cisco \ logs \ BARRES \ sauvegarde (ou restauration) dans le serveur de BARRES.

2. Basé sur le groupe date/heure, l'aspect dans le suivi se connecte. Ils sont disponibles chez C:\Program Files\Cisco\Trace\BARS dans le serveur de BARRES.

3. Les logs de suivi fournissent de brèves informations au sujet de l'exception. Afin de visualiser les détails, aller au serveur CRS respectif, et vérifier les logs MCVD pour cette période. Search for backup_failed, mnémonique restore_failed et upgrade_failed dans ces logs pour l'exécution respective (B/R/U) panne. Si la panne se produisait avant que les BARRES s'interrompe à 19%, vérifiez les logs de MARC.

4. Une fois que vous atteignez la mnémonique spécifiée dans l'étape ci-dessus, vous pouvez visualiser la description précise de l'erreur. Par exemple, vous pourriez voir ces messages :

   • Erreur de communication d'applet

   • Exception de composant de database archive

   • Exception de composant d'archives de Spanlink

   • L'outil CDBR a manqué

   Ces messages sont instructifs et indiquent l'en raison fait face par erreur de quel B/R/U a manqué. Basé sur le composant, des logs supplémentaires sont nécessaires comme suit (indépendamment de ceux mentionnés ci-dessus) :

   Composant d'archives SL : c:\program files\cisco\desktop\log\CDBRTool. * Composant d'archives de DB :

Les problèmes courants ont fait face pendant le test de sauvegarde CRS 6.0 et de restauration

Question de délai d'attente d'applet

Problème

Les temps d'applet et le processus de restauration échoue quand le bouton CORRECT n'est pas cliqué sur pendant les alertes sécurité et les alertes d'intimité. Ces alertes sécurité sont souvent affichées derrière la fenêtre d'enfant sur la fenêtre de page de BARRES de parent. Des logs de suivi, vous pouvez localiser cette question parce qu'il y a un écart de exactement 5 minutes. Exemple :

[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

Solutions possibles

1. Faites glisser manuellement la fenêtre d'enfant vers le coin de l'écran, et réduisez la taille de la fenêtre, de sorte que le centre soit visible pour toutes les alertes sécurité.

2. Gardez le foyer sur la page principale de BARRES, et réduisez la fenêtre d'enfant. Maintenez toutes les boîtes de dialogue instantanées.

3. Dans les options Internet, ramenez les paramètres de sécurité et les configurations d'intimité au bas avant que vous commenciez le processus de restauration. Retournez de retour après le processus de restauration. (Ceci n'est pas recommandé comme implications de cette action du navigateur que le point de vue de Sécurité n'a pas été vérifié).

Mise à jour de CRS 3.5 6.0 dans l'installation autonome

Les CRS 3.5 à la mise à jour 6.0 doivent être suivis comme décrit dans le guide d'installation de Cisco Customer Response Solution seulement. Prenant une sauvegarde de CRS 3.5, la nouvelle création d'images, et essayer de la restaurer au-dessus des CRS 6.0 installés n'est pas un scénario valide.

Puisque ce n'est pas un scénario pris en charge, le seul contournement est de revenir à CRS 3.5.

CRS 4.0(x) à mise à jour 6.0

Pendant des CRS 4.0 à la mise à jour 6.0, si vous avez téléchargé un module différent de permis (pas le même module qui a été téléchargé en CRS 4.0) après que la mise à jour, le type de module de permis n'en affiche aucun en page de données de licence dans AppAdmin, et certains des menus d'AppAdmin manqueront.

Par exemple, si le client a CRS 4.1 avec un permis standard et mises à jour à CRS 6.0 avec une licence premium, alors après que la mise à jour aux CRS 6.0 quelques menus manquent dans AppAdmin. En page d'AppAdmin > de Control Center > de données de licence, le type de module de permis n'en affiche aucun.

Solution : Changez la valeur de filtre de permis CRS dans le LDAP au nouveau type de licence.

Entrée de filtre de permis de LDAP : CCNApps/clusters/<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

Après que vous exécutiez les changements du LDAP, redémarrez le gestionnaire de noeud CRS sur le serveur CRS.

L'installation/processus de mise à niveau est partie sans surveillance

Les procédés d'installation, de mise à jour, et de restauration sont des processus très essentiels et doivent être suivis très soigneusement selon le guide. Parfois, les BARRES mettent en boîte la transition à l'état ne répondant pas. Cisco recommande que vous soyez témoin du processus complet de la mise à jour, de l'installation, et de la restauration.

Utilisation d'outil de Pré-mise à jour

Comme décrit dans le guide d'installation, vous devez exécuter l'outil de Pré-mise à jour (MIS) avant que vous exécutiez le processus de restauration. Son utilisation est d'injecter le permis CRS 6.0 dans le LDAP, de sorte que les archives de sauvegarde contiennent les 6.0 permis.

Les BARRES paginent aller le blanc

La page d'affichage de BARRES va le blanc par intermittence pendant le processus de restauration. Cette question est documentée par l'ID de bogue Cisco CSCsa82969 (clients enregistrés seulement). C'est une question cosmétique. Afin de résoudre ce problème, régénérez la fenêtre d'enfant (presse F5). Ceci devrait être fait seulement sur la fenêtre d'état de BARRES et pas sur la fenêtre principale de restauration de BARRES.

Collecte de logs de BARRES

Avant que vous re-image le serveur Cisco CallManager, les logs de BARRES deviez être enregistré. Référez-vous aux logs requis pour le pour en savoir plus de sauvegarde/restauration/mise à jour. Les détails de fichier sont mentionnés dans le guide d'administration de sauvegarde de Téléphonie sur IP de Cisco et de restauration de système (BARRES).

Échouer de sauvegardes avec cette erreur : * 86 - L'erreur inconnue s'est produite tout en se connectant à l'hôte

Problème

Les sauvegardes programmées et manuelles manquent avec l'erreur * 86 - erreur inconnue se sont produites tout en se connectant pour héberger. Le système de sauvegarde reçoit le chemin réseau et les informations du compte, mais la sauvegarde échoue.

Solution

Procédez comme suit pour résoudre ce problème :

1. Accédez au serveur UCCX et naviguez vers le Start > Run, et tapez le CET.

2. Quand le message d'avertissement apparaît, cliquez sur NON.

3. Choisissez com.cisco.crs.cluster.config.ArchiveAdminConfig.

4. Du côté droit, double-cliquer l'ID record.

5. Cliquez sur l'onglet com.cisco.crs.cluster.config.ArchiveAdminConfig, et effacez le mot de passe sous le stockage de sauvegarde.

6. Cliquez sur Apply.

7. Naviguez vers Appadmin > outils > de sauvegarde et restauration.

8. Sous l'emplacement de stockage de sauvegarde, tapez le nouveau mot de passe, et cliquez sur la mise à jour.

Après que vous vous terminiez ces étapes, vous pouvez exécuter la sauvegarde. Si la sauvegarde échoue, redémarrez le serveur, et essayez la sauvegarde de nouveau. Si la sauvegarde échoue toujours, vous pouvez naviguer vers le CET, effacez tous les champs, et puis tapez les nouvelles informations pour l'emplacement de mémoire.

UCCX 7.x : Panne de sauvegarde de BARRES

Problème

La sauvegarde de BARRES échoue avec ce message d'erreur :

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

Cette question est documentée dans l'ID de bogue Cisco CSCsy04635 (clients enregistrés seulement).

Solution

Afin de résoudre ce problème, redémarrez le gestionnaire de noeud.

UCCX 8.x : La sauvegarde de BARRES échoue à 87 %

Problème

La sauvegarde s'arrête à 87% avec CCXCOMPONENT donnant l'erreur à 30%.

Solution

Afin de résoudre ce problème, exécutez cette commande de l'interface de ligne de commande :

utils service restart Cisco DRF Master

La restauration UCCX 7.x de la sauvegarde s'arrête à 15%

Problème

Quand vous tentez de restaurer une sauvegarde d'UCCX 7.x, elle s'arrête à 15% et vous recevez ce message d'erreur :

Puisque la sauvegarde a été prise quand ha et puisque ce autre noeud n'existe pas actuellement dans la batterie il ne peut pas continuer.

Solution

Puisque la sauvegarde a été rentrée un environnement à haute disponibilité les deux Noeuds doivent être dans la batterie pour que vous restauriez les informations. Vous pouvez restaurer les fichiers de sauvegarde dans un déploiement facilement disponible utilisant une de ces options :

• Si l'installation facilement disponible est déjà en place et les deux Noeuds sont ajoutés en tant qu'élément de la même batterie, le processus de restauration est semblable au déploiement de simple-noeud ; il peut être fait de n'importe quel noeud et restaurera des données sur les les deux les Noeuds.

• Si l'installation facilement disponible n'est pas en place et les les deux les Noeuds sont frais installé ou réimagé avant d'installer l'Unified CCX, terminez-vous ces étapes afin de restaurer :

  1. Initiez le processus de restauration du premier noeud. La restauration se terminera 15% et vous incitera à ajouter le deuxième noeud pour grouper.

  2. Ajoutez le deuxième noeud par l'assistant de configuration. Une fois que vous ajoutez le deuxième noeud, la restauration sera complète et l'installation facilement disponible sera prête.

La restauration échoue à 69%

Problème

Quand vous promouvez le serveur UCCX 4.5 à 7.0, la restauration des données UCCX 4.5 échoue avec cette erreur :

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

Solution

Cette question est documentée dans l'ID de bogue Cisco CSCsr56145 (clients enregistrés seulement). Le contournement est de corriger 7.0(1) le système avec le plus défunt lancement du service (SR) et d'exécuter la restauration de nouveau.

Informations connexes

• La restauration de données UCCX échoue avec échouer du message d'erreur le « pour mettre à jour l'état primaire de Datastore de config CRS dans le noeud 1"
• Support et documentation techniques - Cisco Systems