En este documento se describe cómo resolver problemas de upgrade, copia de seguridad y restauración de CRS.
Cisco recomienda que tenga conocimiento sobre estos temas:
Cisco Unified Contact Center Express
Cisco IP Telephony Backup and Restore System (BARS)
La información en este documento se basa en las versiones 3.x, 4.x,6.x, y 7.x del Cisco Unified Contact Center Express.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.
Si se produce un error de Copia de Seguridad/Restauración/Upgrade (B/R/U), es posible que se visualice en la pantalla de BARS un mensaje (en color rojo) anunciando un cierre inesperado del socket TCP. Error de Restauración/Copia de Seguridad/Upgrade.
Este mensaje es genérico y visualizado en caso de cualquier error en el respaldo/la operación del restore/de la actualización. No es una indicación de la interrupción de la conexión TCP o de ninguna problemas de la conexión de red entre CRS y las máquinas de las BARRAS.
Problema
CRS el respaldo/el restore/la corrección/la actualización falla en las BARRAS debido a una comunicación del applet del descanso que espera para (CRS los subprogramas java no pueden ser cargados al navegador en quien BARRA los funcionamientos admin en el plazo de 5 minutos). La página de administración de BARS muestra que extrajo los archivos en la ventana de estado y que se queda bloqueado durante 5 minutos aproximadamente antes de notificar el error. El archivo de log de MCVD / MARC indica que la razón del error es que “se agotó el tiempo de espera para inicializar la comunicación con el applet”. Este problema se documenta en el Id. de bug Cisco CSCef91551 (clientes registrados solamente).
Este problema puede ocurrir si el navegador que se utiliza para ejecutar las BARRAS admin no incluye las configuraciones requeridas.
Aún no se ha instalado el plug-in de Java o la versión de JRE o del plug-in de Java no es la correcta.
En el cuadro de diálogo Opciones de Internet de Internet Explorer, haga clic en la pestaña Opciones avanzadas y desplácese hacia abajo hasta el encabezado Java (Sun).
Verifique que la casilla de verificación Usar Java 2 v.14.2_xx para <applet> está marcada.
Se ha modificado la configuración de seguridad predeterminada.
En el cuadro de diálogo Opciones de Internet, seleccione la pestaña Seguridad.
Para la zona Intranet local, haga clic en Nivel predeterminado y asegúrese de establecer el nivel de seguridad en el valor predeterminado (Media-Baja) o inferior.
Si personalizó la configuración de seguridad, haga clic la Nivel personalizado, y asegúrese de que los permisos de Java no están establecidos en Deshabilitar Java. En lugar de ello, elija uno de los tres niveles de seguridad.
En el cuadro de diálogo de nivel personalizado, asegúrese de que la opción Scripting de applets Java está establecida en Habilitar o Preguntar.
Se ha modificado la configuración de privacidad predeterminada.
En el cuadro de diálogo Opciones de Internet, seleccione la pestaña Privacidad.
Asegúrese de que la configuración de Privacidad está establecida en el nivel predeterminado (Media) o inferior.
El servidor proxy configurado en el navegador no es accesible.
En el cuadro de diálogo Opciones de Internet, haga clic en la pestaña Conexiones y, a continuación, haga clic en Configuración de LAN.
Si se configura un servidor proxy, asegúrese de que es accesible o desmarque esta opción para utilizar un servidor proxy.
Se habilita la advertencia de la seguridad.
En el cuadro de diálogo Opciones de Internet, haga clic en la pestaña Opciones avanzadas y desplácese hacia abajo hasta el encabezado Seguridad.
Asegúrese de que la casilla de verificación Avisar si se cambia entre los modos seguro y no seguro esté desmarcada.
Solución
Verifique si la vinculación NIC del cuadro CRS es adecuada y es NIC 1 seguido de NIC 2.
Asegúrese de que el cuadro CRS es accesible desde el servidor BARS.
Asegúrese de que el Bloqueador de elementos emergentes está desactivado.
Asegúrese de seguir las pautas mencionadas en la sección anterior.
Cuando el navegador le pregunte si desea descargar y ejecutar el instalador del plug-in de Java, responda que sí de manera oportuna. La restauración puede fallar si la instalación dura más de 5 minutos o si requiere un reinicio del navegador. En estos casos, simplemente reinicie el navegador y vuelva a ejecutar la restauración con el mismo archivo de almacenamiento. Responda también oportunamente a los cuadros de diálogo pop-up de Internet Explorer, ya que se agotará el tiempo de espera de CRS si no se carga el applet en el navegador en 5 minutos. Si ya se agotó el tiempo de espera, simplemente reinicie la restauración.
Si el problema persiste, asegúrese de que la configuración es correcta y siga estos pasos:
En Internet Explorer, vaya a Herramientas > Sun Java Console para visualizar la consola de Java.
Nota: Si la versión de Internet Explorer que usted utiliza no visualiza esto en la barra de menú, localiza el logotipo de las Javas en la barra de tareas de Windows, hace clic con el botón derecho del ratón el logotipo, y elige la consola abierta.
Cuando se abra la consola de Java, presione la tecla 5 para habilitar el debugging.
Utilice las BARRAS de este buscador Internet Explorer para ejecutar el restore otra vez.
Si la restauración vuelve a fallar, vuelva a la ventana de la consola de Java, copie todo el texto y péguelo en un archivo de texto para guardarlo con fines de troubleshooting.
Si la copia de seguridad falla con este mensaje de error, siga estos pasos:
Marque los registros para los valores siguientes: LDAP_CON_WARNING y LDAP_CON_ERROR. Si existen ambos valores, el respaldo/el restore/el proceso de actualización fallaron porque el LDAP no valida las conexiones de Cisco CRS.
Aseegurese que los servidores LDAP (CallManageres) son accesibles del cuadro de Cisco CRS. Críe al servidor LDAP si no se está ejecutando.
Reinicie el servidor CRS.
Nota: Este problema se documenta en el Id. de bug Cisco CSCse15624 (clientes registrados solamente).
Problema
CRS el respaldo \ el restore falla cuando el servidor de las BARRAS intenta la blanco de las BARRAS del respaldo. El archivo de traza de las BARRAS (situado en la carpeta de C:\Program Files\Cisco\Trace\BARS en el servidor de las BARRAS) visualiza este error:
Inside function modGetFromArchive Connecting to \\10.10.10.38\C$ modGetFromArchive =-2147417842 GET_FROM_ARCHIVE_REQUEST failed with error: -2147417842
Visualizaciones del registro de las BARRAS:
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.
Solución
Siga estos pasos para cerrar BARS en el servidor BARS:
Cierre todos los casos del Internet Explorer.
En el servidor de las BARRAS, vaya al Start (Inicio) > Programs (Programas) > Administrative Tools (Herramientas administrativas) > a los servicios del componente.
Expanda Servicios de componente > Equipos > Mi PC > Aplicaciones COM+.
En el panel derecho, haga clic con el botón derecho del ratón en BARS y elija Cerrar.
Reinicie el servicio de administración de Internet Information Server (IIS) en el panel de control de servicios.
Funcione con otra vez el restore/el respaldo que fallaron.
Si usted ha alcanzado el proceso del RESTORE, descubra que caminan y el porcentaje exacto del proceso del RESTORE en el cual el proceso de actualización falló. El proceso de restauración consta de 2 etapas: etapa 1 y etapa 2.
La etapa 1 va del 0 al 19% para la Restauración y del 0 al 33% para la aplicación de una revisión. Durante la etapa 1, hasta que se suspenda BARS, toda la información se registrará en CiscoMARC.log. Si se produce un error en el proceso de actualización durante este tiempo, mire en CiscoMARC.log. Durante la etapa 1 solamente se actualiza la información del nivel de clúster (CCNApps > clusters > profilename > clusterdependent ou). La información de nivel de nodo (CCNApps > clusters > profilename > Nodes > nodeid > clusterdependent ou) se actualiza en la etapa 2. Cuando BARS se suspende, proporciona una lista de servidores CRS que hay que reiniciar. Siga el proceso de ahí en adelante.
La etapa 2 comienza después del 19%, cuando el servidor Cisco CRS se reinicia y da a BARS la confirmación de reanudación. Toda la información se registra en MCVD.log . En caso de error, busque _FAILED en MCVD.log. En CRS 4.x/6.x, se utiliza CRS con BARS para hacer una operación de Copia de seguridad/Restauración/Upgrade desde las versiones anteriores, como CRS 3.x/4.x.
Hacia el final del proceso RESTORE, BARS se suspende y espera a que se active CRS. Una vez suspendido, cierra el socket. BARS espera a que llegue la señal del servidor CRS una vez que CRS 4.x está instalado. Es normal ver este mensaje en 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
Para upgrades de Cisco CRS 4.0(4), debe hacer clic en el botón de opción No, I will restart my computer later en el paso 27 del procedimiento Actualización del software de Cisco CRS en la ventana Maintenance Complete para eliminar la versión 3.x de la llave del Registro. Si hace clic en Yes, I want to restart, el proceso de upgrade falla con errores, como existe una versión más antigua que la 3.x en el paso 28, entre las viñetas e y f. La información anterior es aplicable para upgrades de un solo servidor 4.0.5 (corresidente) en el paso 31 del procedimiento Actualización del Software de Cisco CRS.
Al hacer un upgrade de Cisco CRS 3.5 a Cisco CRS 4.0(5)/4.1(1)/6.0(1), el proceso falla en la fase de restauración de Spanlink si los nombres de equipo configurados en Cisco Desktop Administrator contienen una barra diagonal. Este problema se documenta en el Id. de bug Cisco CSCsj23469 (clientes registrados solamente).
Solución:
Los nombres del equipo configurados en Cisco Desktop Administrator no pueden contener una barra diagonal. Si existe una barra diagonal en cualquier nombre de equipo, siga estos pasos antes de que iniciar el upgrade.
Abra Cisco Desktop Administrator y elimine el nombre de equipo que contiene una barra diagonal.
Cree un nombre de equipo alternativo sin barra diagonal y configure la misma asignación para el nuevo nombre de equipo.
Nota: El error reconstruir los nombres del equipo sin las rayas verticales pudo dar lugar al error durante la actualización.
Al resolver problemas de revisiones, asegúrese de que la ruta al archivo de revisión especificada en el cuadro CRS no contiene espacios. Este problema se documenta en el Id. de bug Cisco CSCsa98554 (clientes registrados solamente).
Durante el upgrade de 3.x a 4.0.4, tras una restauración exitosa, el subsistema de datos empresariales y el subsistema de monitoreo de VoIP están fuera de servicio. Verifique los logs de CDBRTool C:\Archivos de programa\Cisco\Desktop\logs en el servidor CRS. Busque el error CDBRAPI:: Error de RestoreAllLCCs RestoreLCCData. A continuación se muestra el fragmento de log correspondiente:
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.
Como solución temporal, vuelva a la versión anterior de CNR y remueva la entrada en blanco de la agenda telefónica en Cisco Desktop Administrator. A continuación, utilice la copia de seguridad en la versión antigua de CRS, haga el upgrade a 4.0 y realice la operación de restauración.
Este problema está documentado con el ID de bug de Cisco CSCse63244 ( clientes registrados solamente).
Nota: Si el código devuelto es 19 en lugar de 2, asegúrese de que la agenda telefónica de empleados no contiene una coma o ningún carácter distinto de un dígito numérico en el campo Phone Number.
Problema
Cuando usted intenta manualmente al respaldo la aplicación UCCX 7.X, se vuelve este error: * 1326 - Error del inicio: nombre o contraseña incorrecta de usuario desconocido.
Solución
Para resolver el problema, la en primer lugar controle MCVD registra (véase el procedimiento para analizar la sección de los registros para marcar los registros).
Si la contraseña usada es incorrecta, el UCCX utiliza las credenciales viejas para acceder la carpeta de la parte. Aquí están las soluciones alternativas para este problema:
Guarde las credenciales viejas en el sitio de servidor de backup.
Si usted cambia la contraseña del usuario en el servidor de backup, ponga al día la contraseña en el UCCX, y entonces la reinicialización del servidor UCCX.
Si no, complete estos pasos:
Configure una cuenta en su servidor de backup de Windows.
Cree una nueva carpeta Backup (Copia de respaldo).
Asigne el control total del usuario nuevo de la carpeta, y comparta la carpeta.
De la ubicación del backup del servidor UCCX, fije a \ \ del nombre del trayecto el server> del <backup \ el folder> <shared, el Nombre de usuario al server> \ <user-id> del <backup, y la contraseña
Este problema se documenta en el Id. de bug Cisco CSCth19279 (clientes registrados solamente).
Los logs de copia de seguridad y restauración de BARS se almacenan en las siguientes ubicaciones:
C:\Archivos de programa\Archivos comunes\Cisco\Logs\BARS\Backup*.*
C:\Archivos de programa\Archivos comunes\Cisco\Logs\BARS\Restore*.*
Los logs de BARS Trace se almacenan en C:\Archivos de programa\Cisco\Trace\BARS *.*
El log de BARS Barbi se almacena en C:\WINNT\system32\barbi.log
Mire en los logs de Copia de seguridad (o Restauración) que se encuentran en C:\Archivos de programa\Archivos comunes\Cisco\Logs\BARS\Backup (o Restore) en el servidor BARS.
Mire en los logs de seguimiento según el sello de fecha/hora. Están disponibles en C:\Archivos de programa\Cisco\Trace\BARS en el servidor BARS.
Los logs de seguimiento proporciona información descriptiva de la excepción. Para ver los detalles, vaya al servidor CRS respectivo, y verifique los logs de MCVD correspondientes a ese período. Busque en esos logs las mnemónicas backup_failed, restore_failed, upgrade_failed de la falla de funcionamiento (B/R/U) correspondiente. Si el error se produjo antes de que se suspendiera BARS en el 19%, verifique los logs de MARC.
Cuando llegue a la mnemónica especificada en el paso anterior podrá ver la descripción exacta del error. Por ejemplo, podría ver estos mensajes:
Error de Comunicación de Applet
Excepción de Componente de Archivo de Almacenamiento de Base de Datos
Excepción de Componente de Archivo de Almacenamiento de Spanlink
Error de la Herramienta CDBR
Estos mensajes son informativos e indican el tipo de error que hizo que la operación B/R/U fallara. Según el componente, serán necesarios los logs adicionales siguientes (aparte de los mencionados anteriormente):
Componente de Archivo de Almacenamiento SL: c:\program files\cisco\desktop\log\CDBRTool. * Componente de Archivo de Almacenamiento DB:Problema
Se agota el tiempo de espera del applet y el proceso de Restauración falla si no se hace clic en el botón OK cuando surgen las alertas de seguridad y las alertas de privacidad. Estas alertas de seguridad se suelen visualizar detrás de la ventana secundaria en la ventana de la página principal de BARS. Puede localizar este problema en los logs de seguimiento porque hay un intervalo de exactamente 5 minutos. Por ejemplo:
[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
Soluciones posibles
Arrastre manualmente la ventana secundaria hacia la esquina de la pantalla y reduzca el tamaño de la ventana, de forma que el centro quede visible para cualquier alerta de seguridad.
Mantenga el foco en la página principal de BARS y minimice la ventana secundaria. Haga un seguimiento de los cuadros de diálogo pop-up.
En Opciones de Internet, rebaje la configuración de seguridad y de privacidad a Baja antes de iniciar el proceso de restauración. Revierta después del proceso de restauración. (Esto no se recomienda, ya que no se han verificado las implicaciones de esta acción desde la perspectiva de la seguridad del navegador).
El upgrade de CRS 3.5 a 6.0 debe realizarse solamente según lo descrito en la Guía de Instalación de Soluciones de Cisco Customer Response . Realizar una copia de seguridad de CRS 3.5, regenerar la imagen e intentar restaurarla sobre la configuración de CRS 6.0 no es un escenario válido.
Puesto que este escenario no se soporta, la única solución es revertir a CRS 3.5.
Durante un upgrade de CRS 4.0 a 6.0, si se sube un paquete de licencia distinto (que no esté en el mismo paquete que se subió en CRS 4.0) después del upgrade, en License Package Type se visualiza None en la página License Information de AppAdmin, y faltarán algunos de los menús de AppAdmin.
Por ejemplo, si el cliente tiene CRS 4.1 con una licencia estándar y se hace un upgrade a CRS 6.0 con una licencia superior, después del upgrade a CRS 6.0 faltarán algunos menús en AppAdmin. En AppAdmin > Control Center > License Information Page, el valor de License Package Type es None.
Solución: Cambie el valor del filtro de licencia de CRS en LDAP al nuevo tipo de licencia.
Entrada del filtro de licencia de LDAP: CCNApps/clusters/<nombre_perfil>/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
Después de realizar los cambios en LDAP, reinicie el CRS Node Manager en el servidor CRS.
Los procesos de Instalación, Upgrade y Restauración son muy críticos y se debe realizar un seguimiento minucioso de los mismos como se indica en la guía. A veces, BARS puede pasar al estado Not Responding. Cisco recomienda vigilar todo el proceso de Upgrade, Instalación y Restauración.
Como se indica en la guía de instalación, debe ejecutar la Herramienta de Preparación del Upgrade (PUT) antes de realizar el proceso de Restauración. Se utiliza para inyectar la licencia de CRS 6.0 en LDAP, de forma que el archivo de almacenamiento de la copia de seguridad contenga las licencias de la versión 6.0.
La página de BARS se queda en blanco de forma intermitente durante el proceso de Restauración. Este problema está documentado con el ID de bug de Cisco CSCsa82969 ( clientes registrados solamente). Este problema es cosmético. Para resolverlo, actualice la ventana secundaria (presione F5). Esto debe hacerse solamente en la ventana de estado de BARS, no en la ventana principal de restauración de BARS.
Antes de regenerar la imagen del servidor de Cisco Callmanager debe guardar los logs de BARS. Refiérase a Logs Requeridos para Copia de Seguridad/Restauración/Upgrade para obtener más información. Los detalles del archivo se mencionan en la Guía de Administración del Sistema de Copia de Seguridad y Restauración (BARS) de Telefonía IP de Cisco.
Problema
Los respaldos programados y manuales están fallando con el error * 86 - Error desconocido ocurrieron mientras que conectan para recibir. Sistema de respaldo valida el trayecto de red y la información de la cuenta, pero el respaldo falla.
Solución
Complete estos pasos para resolver este problema:
Acceda el servidor UCCX y navegue al Start (Inicio) > Run (Ejecutar), y teclee el CET.
Cuando aparece el mensaje de advertencia, haga clic NO.
Elija com.cisco.crs.cluster.config.ArchiveAdminConfig.
En el lado derecho, haga doble clic el expediente ID.
Haga clic la lengueta com.cisco.crs.cluster.config.ArchiveAdminConfig, y borre la contraseña bajo almacenamiento de reserva.
Haga clic en Apply (Aplicar).
Navegue a Appadmin > a las herramientas > de reserva y Restore.
Bajo ubicación de almacenamiento de reserva, teclee la nueva contraseña, y haga clic la actualización.
Después de que usted complete estos pasos, usted puede funcionar con el respaldo. Si el respaldo falla, recomience el servidor, e intente el respaldo otra vez. Si el respaldo todavía falla, usted puede navegar al CET, borra todos los campos, y después teclea la nueva información para la ubicación de almacenamiento.
El respaldo de las BARRAS falla con este mensaje de error:
%MCVD-AC_SPANLINK-7-UNK:Exception thrown while invoking and running BarsCLI: Exception=com.cisco.archive.ArchiveException: BarsCLI failed to backup Spanlink config
Este problema se documenta en el Id. de bug Cisco CSCsy04635 (clientes registrados solamente).
Para resolver este problema, recomience Node Manager.
El respaldo cuelga en el 87% con CCXCOMPONENT que da el error en el 30%.
Para resolver este problema, funcione con este comando de la interfaz de la línea de comandos:
utils service restart Cisco DRF Master
Cuando usted intenta restablecer un respaldo de UCCX 7.x, cuelga en el 15% y usted recibe este mensaje de error:
Puesto que el respaldo fue tomado cuando HA y puesto que este otro nodo no existe actualmente en el cluster no puede continuar.
Puesto que el respaldo fue admitido un entorno de gran disponibilidad ambos Nodos deben estar en el cluster para que usted restablezca la información. Usted puede restablecer los archivos de backup en un despliegue de gran disponibilidad usando una de estas opciones:
Si la configuración de gran disponibilidad es ya en el lugar y ambos Nodos se agregan como parte del mismo cluster, el proceso del restore es similar al despliegue del nodo único; puede ser hecho de cualquier nodo y restablecerá los datos sobre ambos los Nodos.
Si la configuración de gran disponibilidad no es en el lugar y ambos los Nodos están frescos instalado o reimaged antes de instalar CCX unificado, complete estos pasos para restablecer:
Inicie el proceso del restore a partir del primera nodo. El Restore completará el 15% y le indicará a que agregue el segundo nodo para agrupar.
Agregue el segundo nodo a través del asistente para la configuración. Una vez que usted agrega el segundo nodo, el restore será completo y la configuración de gran disponibilidad estará lista.
Cuando usted actualiza el servidor UCCX 4.5 a 7.0, el restore de los datos UCCX 4.5 falla con este error:
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
Este problema se documenta en el Id. de bug Cisco CSCsr56145 (clientes registrados solamente). La solución alternativa es parchear 7.0(1) el sistema con la última versión del servicio (SENIOR) y ejecutar el restore otra vez.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
18-Aug-2011 |
Versión inicial |