Dicas de Troubleshooting expressos IPCC para a elevação, o backup, e as edições da restauração

Introdução

Este documento descreve como solucionar problemas da atualização, backup e restauração do CRS.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Unified Contact Center Express

• Sistema de restauração e backup de telefonia IP da Cisco (BARS)

Componentes Utilizados

A informação neste documento é baseada em versões 3.x do Cisco Unified Contact Center Express, 4.x,6.x, e 7.x.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

CRS 3.x e 4.x: Erros comuns recebidos durante o backup, a restauração e a atualização

TCP Socket closed unexpectedly

Quando um backup/restauração/atualização (B/R/A) falharem, você poderá receber uma mensagem (indicada no texto vermelho) na tela do BARS que afirma TCP Socket closed unexpectedly. Restore/Backup/Upgrade failed.

Esta mensagem é genérica e indicada em caso de toda a falha na operação alternativa/restauração/elevação. Não é uma indicação da interrupção da conexão de TCP ou do nenhuma edições da conexão de rede entre os CR e as máquinas das BARRAS.

Applet Communication Error

Problema

O backup/restauração/correção de programa/elevação CR falham nas BARRAS devido a uma comunicação de espera do applet do intervalo (o Java applet CR não carrega ao navegador em que BARRA corridas admin dentro dos minutos 5). A administração do BARS mostra que extraiu os arquivos arquivados na janela de status e aparenta ter desligado por 5 minutos antes de relatar a falha. O arquivo de registro MCVD/MARC mostra a razão da falha como “uma comunicação do applet fora do timeout.” Esta edição é documentada na identificação de bug Cisco CSCef91551 (clientes registrados somente).

Esta edição pode ocorrer se o navegador que está usado para executar as BARRAS admin não inclui os ajustes exigidos.

• O plug-in do Java não está instalado ainda ou não tem a versão correta do JRE ou do plug-in do Java instalado.

  1. Na caixa de diálogo Opções da Internet do Internet Explorer, clique na guia Avançadas e role para baixo até o título Java (Sun).

  2. Verifique se a caixa de seleção Usar Java 2 v.14.2_xx para <applet> está marcada.

• A configuração de segurança padrão foi alterada.

  1. Na caixa de diálogo Opções da Internet, clique na guia Segurança.

  2. Para a zona Intranet Local, clique em Nível Padrão e verifique se o nível de segurança está definido para o nível padrão (Médio-Baixo) ou mais baixo.

  3. Se você personalizou suas configurações de segurança, clique em Nível Personalizado e verifique se as permissões de Java não estão definidas para Desabilitar Java. Em vez disso, escolha um dos três níveis da segurança.

  4. Na caixa de diálogo Nível Personalizado, verifique se Script de miniaplicativos Java está definido para Habilitar ou Prompt.

• A configuração de privacidade padrão foi alterada.

  1. Na caixa de diálogo Opções da Internet, clique na guia Privacidade.

  2. Verifique se a configuração Privacidade está definida para o nível padrão (Médio) ou mais baixo.

• O servidor proxy que está configurado no navegador não pode ser acessado.

  1. Na caixa de diálogo Opções da Internet, clique na guia Conexões e, depois, clique em Configurações da LAN.

  2. Se um servidor proxy estiver configurado, verifique se ele pode ser acessado ou desmarque essa opção para usar o servidor proxy.

• O aviso de segurança está ativado.

  1. Na caixa de diálogo Opções da Internet, clique na guia Avançadas e role para baixo até o título Segurança.

  2. Certifique-se de que a caixa de seleção Avisar ao alterar o modo de segurança esteja desmarcada.

Solução

• Verifique se a ligação NIC na caixa CRS é apropriada e se NIC 1 é seguido por NIC 2.

• Verifique se a caixa CRS pode ser acessada a partir do servidor BARS.

• Verifique se o Bloqueador de pop-up está desativado.

• Verifique se as diretrizes mencionadas na seção anterior foram seguidas.

• Quando solicitado pelo navegador para fazer o download e executar o instalador do plug-in do Java, responda sim no momento correto. A restauração ainda poderá falhar se a instalação levar mais de 5 minutos ou se a instalação exigir uma reinicialização do navegador. Nesses casos, simplesmente reinicialize o navegador e execute a restauração novamente com o mesmo arquivo. Também, responda no momento correto a qualquer caixa de diálogo de pop-up no navegador Internet Explorer, já que o CRS irá expirar se o applet não for carregado dentro de cinco minutos no navegador. Se ele já tiver expirado, simplesmente reinicialize a restauração novamente.

Se o problema persistir, verifique se as configurações estão corretas e, depois, conclua estas etapas:

1. No Internet Explorer, acesse Ferramentas > Console do Sun Java para exibir o Console do Java.

   Nota: Se a versão de Internet Explorer que você usa não indica esta na barra de menus, encontra o logotipo das Javas na barra de tarefas do Windows, clica com o botão direito o logotipo, e escolhe o console aberto.

2. Quando o Console do Java estiver aberto, pressione a tecla 5 para habilitar a depuração.

3. Use BARRAS deste navegador do internet Explorer a fim executar outra vez a restauração.

4. Se a restauração falhar outra vez, retorne à janela do console do Java, copie todo o texto e cole-o em um arquivo de texto para salvá-lo para fins de solução de problemas.

LDAPProviderUnavailable Exception

Se o backup falhar com a mensagem de erro, conclua estas etapas:

1. Verifique os logs para ver se há os seguintes valores: LDAP_CON_WARNING e LDAP_CON_ERROR. Se ambos os valores existem, o alternativo/restauração/processo de upgrade falharam porque o LDAP não aceita conexões de Cisco CR.

2. Certifique-se de que os servidores ldap (CallManagers) são alcançáveis da caixa de Cisco CR. Traga acima o servidor ldap se não está sendo executado.

3. Reinicie o servidor CRS.

Nota: Esta edição é documentada na identificação de bug Cisco CSCse15624 (clientes registrados somente).

Erro: GET_FROM_ARCHIVE_REQUEST failed with error:-2147417842

Problema

O backup \ restauração CR falham quando o server das BARRAS tenta o alvo das BARRAS do backup. O arquivo de rastreamento das BARRAS (situado no dobrador de C:\Program Files\Cisco\Trace\BARS no server das BARRAS) indica este erro:

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

Indicadores do log das 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.

Solução

Conclua estas etapas para desligar o BARS no servidor BARS:

1. Feche todos os exemplos do internet explorer.

2. No server das BARRAS, vá ao iniciar > programas > ferramentas administrativas > aos serviços de componente.

3. Expanda serviços de componente > computadores > aplicativos do Meu Computador > COM+.

4. No painel direito, clique com o botão direito do mouse em BARS e escolha Shut down.

5. Reinicie o serviço Admin do Servidor de informações da Internet (IIS), no painel de controle de serviço.

6. Execute outra vez a restauração/backup que falharam.

Problemas específicos encontrados durante o backup/restauração/atualização

Problema 1

Se você alcançou o processo da RESTAURAÇÃO, encontre que pisam e a porcentagem exata do processo da RESTAURAÇÃO em que o processo de upgrade falhou. Há 2 fases para o processo de restauração: fase 1 e fase 2.

• A fase 1 é de 0 - 19% para a restauração e de 0 - 33% para correção. Durante a fase 1, até que o BARS seja suspenso, todas as informações serão registradas no CiscoMARC.log. Se o processo de atualização falhar durante esse período, examine o CiscoMARC.log. As informações no nível de cluster são atualizadas somente durante a fase 1 (CCNApps > clusters > profilename > clusterdependent ou). As informações no nível de nó (CCNApps > clusters > profilename > Nodes > nodeid > clusterdependent ou) são atualizadas durante a fase 2. Quando o BARS é suspendido, ele fornece uma lista dos servidores CRS que precisam ser reinicializados. Siga o processo depois disso.

• A fase 2 começa após 19%, quando o servidor Cisco CRS é reinicializado indicando que o BARS seja retomado. Todas as informações são registradas no MCVD.log . Procure _FAILED no MCVD.log em caso de falhas. No CRS 4.x/6.x, nós usamos os CRS com o BARS para fazer um backup/restauração/atualização das versões anteriores como CRS 3.x/4.x.

Problema 2

Próximo ao final da RESTAURAÇÃO, o BARS é suspenso e aguarda a ativação do CRS. Assim que ele é suspenso, ele fecha o soquete. O BARS aguarda o sinal do servidor CRS assim que o CRS 4.x for instalado. É normal ver esta mensagem em 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

Problema 3

Para atualizações do Cisco CRS 4.0(4), você deve clicar no botão de seleção No, I will restart my computer later etapa 27 do procedimento Atualização do software CRS da Cisco na janela Maintenance Complete para excluir a versão 3.x da chave de registro. Se você clicar em Yes, I want to restart, o processo de atualização falhará com erros, tais como uma versão mais antiga do 3.x ainda existe na etapa 28 entre os marcadores e e f. As informações acima são aplicáveis para atualizações do servidor único 4.0.5 (corresidente) na etapa 31 do procedimento Atualização do software CRS da Cisco.

Problema 4

Quando você atualiza do Cisco CRS 3.5 para o Cisco CRS 4.0(5)/4.1(1)/6.0(1), o processo falhará na fase da restauração de Spanlink se os nomes da equipe configurados no administrador do Cisco Desktop contiverem uma barra. Esta edição é documentada na identificação de bug Cisco CSCsj23469 (clientes registrados somente).

Solução:

Os nomes da equipe configurados no administrador do Cisco Desktop não podem conter uma barra. Se uma barra existir em qualquer nome de equipe, conclua estas etapas antes de iniciar a atualização.

1. Abra o administrador do Cisco Desktop e exclua o nome da equipe que contém a barra.

2. Crie um nome de equipe alternativo sem a barra e configure o mesmo mapeamento para o novo nome de equipe.

   Nota: A falha recrear nomes da equipe sem cortes pôde conduzir à falha durante a elevação.

Problema 5

Ao solucionar problemas de correção, verifique se o caminho para o arquivo de arquivamento da correção na caixa CRS não contém espaços. Esta edição é documentada na identificação de bug Cisco CSCsa98554 (clientes registrados somente).

Problema 6

Durante a atualização do 3.x para o 4.0.4, depois da restauração bem sucedida, o subsistema de dados da empresa e o subsistema de monitoramento VOIP ficam fora de serviço. Verifique os registros de CDBRTool em C:\Arquivos de Programas\Cisco\Desktop\logs no servidor CRS. Procure o erro CDBRAPI:: RestoreAllLCCs RestoreLCCData failed. Aqui está o trecho relevante do registro:

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 uma solução alternativa, retorne à versão CRS anterior e remova a entrada em branco da agenda telefônica no administrador do Cisco Desktop. Agora, selecione o backup da versão antiga do CRS, atualize-o para 4.0 e, depois, execute a operação de restauração.

Este problema é documentado pela identificação de bug Cisco CSCse63244 ( somente clientes registrados) .

Nota: Se o código de retorno for 19 em vez de 2, verifique se a agenda telefônica não contém uma vírgula ou qualquer caractere que não seja um dígito numérico no campo Phone Number.

Emita 7

Problema

Quando você tenta manualmente ao backup o aplicativo UCCX 7.X, este erro está retornado: * 1326 - Falha do fazer logon: nome ou senha ruim de usuário desconhecido.

Solução

A fim resolver a edição, primeira verificação que o MCVD registra (veja o procedimento analisando a seção dos logs para verificar os logs).

Se a senha usada está incorreta, o UCCX usa as credenciais velhas a fim alcançar o dobrador da parte. Estão aqui as ações alternativas para esta edição:

• Mantenha as credenciais velhas no local de servidor de backup.

• Se você muda a senha do usuário no servidor de backup, atualize a senha no UCCX, e então a repartição do server UCCX.

Se não, termine estas etapas:

1. Configurar uma conta em seu servidor de backup de Windows.

2. Crie uma pasta de backup nova.

3. Atribua o controle total do novo usuário do dobrador, e compartilhe do dobrador.

4. Do lugar do backup de servidor UCCX, ajuste a do nome de caminho \ \ server> do <backup \ folder> <shared, o nome de usuário ao server> \ < ao usuário do <backup - identificação >, e a senha

Esta edição é documentada na identificação de bug Cisco CSCth19279 (clientes registrados somente).

Registros exigidos para backup/restauração/atualização do servidor BARS

• Os registros de backup/restauração do BARS são armazenados nestes locais:

  • C:\Arquivos de Programas\Arquivos Comuns\Cisco\Logs\BARS\Backup*.*

  • C:\Arquivos de Programas\Arquivos Comuns\Cisco\Logs\BARS\Restauração*.*

• Os registros de rastreamento são armazenados em C:\Arquivos de Programas\Cisco\Trace\BARS *.*

• O registro Barbi do BARS é armazenado em C:\WINNT\system32\barbi.log

Procedimento para analisar registros

1. Examine os registros de backup (ou restauração) localizados em C:\Arquivos de Programas\Arquivos Comuns\Cisco\Logs\BARS\Backup (ou restauração) no servidor BARS.

2. Com base no registro de hora, examine os registros de rastreamento. Eles estão disponíveis no C:\Arquivos de Programas\Cisco\Trace\BARS no servidor BARS.

3. Os registros de rastreamento fornecem informações breves sobre a exceção. Para exibir os detalhes, acesse o respectivo servidor CRS e verifique os registros de MCVD do período. Procure os mnemônicos backup_failed, restore_failed e upgrade_failed nesses registros para a falha de (B/R/A) da respectiva operação. Se a falha ocorreu antes do BARS ser suspendido em 19%, verifique os registros de MARC.

4. Quando você acessar o mnemônico especificado na etapa acima, você poderá exibir a descrição exata do erro. Por exemplo, você poderá ver as seguintes mensagens:

   • Applet Communication Error

   • Data base Archive component exception

   • Spanlink Archive Component exception

   • CDBR tool failed

   Essas mensagens são informativas e indicam o erro encontrado devido a uma falha de B/R/A. Baseado no componente, os registros adicionais são necessários da seguinte forma (exceto os que foram mencionados acima):

   Componente do arquivo SL: c:\program files\cisco\desktop\log\CDBRTool. * Componente do arquivo DB:

Problemas comuns enfrentados durante o teste de restauração e o backup do CRS 6.0

Problema de timeout do applet

Problema

O applet expira e o processo de restauração falha quando o botão OK não é clicado durante os alertas de segurança e os alertas de privacidade. Esses alertas de segurança são geralmente exibidos atrás da janela filho na janela pai da página do BARS. Nos registros de rastreamento, você pode localizar esse problema porque existe um intervalo de exatamente 5 minutos. Por exemplo:

[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

Soluções possíveis

1. Arraste manualmente a janela filho em direção ao canto da tela e reduza o tamanho da janela, de forma que o centro fique visível para qualquer alerta de segurança.

2. Mantenha o foco na página principal do BARS e minimize a janela filho. Mantenha controle de qualquer caixa de diálogo de pop-up.

3. Em Opções da Internet, reduza as configurações de segurança e as configurações de privacidade para Baixo antes de começar o processo de restauração. Reverta as configurações novamente após o processo de restauração. (Isso não é recomendado, pois as implicações dessa ação do ponto de vista da segurança do navegador não foram verificadas).

Atualização do CRS 3.5 para 6.0 na instalação autônoma

A atualização do CRS 3.5 para 6.0 deve ser seguida de acordo com a descrição no Cisco Customer Response Solutions Installation Guide somente. Selecionar um backup do CRS 3.5, criar uma nova imagem e tentar restaurá-lo na instalação do CRS 6.0 não é um cenário válido.

Como esse não é um cenário suportado, a única alternativa é revertê-lo para o CRS 3.5.

Atualização do CRS 4.0(x) para 6.0

Durante a atualização do CRS 4.0 para o 6.0, se você carregou um pacote de licença diferente (não o mesmo pacote que foi carregado no CRS 4.0) após a atualização, o tipo do pacote de licença exibirá None na página License Information no AppAdmin e alguns menus do AppAdmin ficarão faltando.

Por exemplo, se o cliente tiver um CRS 4.1 com uma licença padrão e atualizações para o CRS 6.0 com uma licença superior, após a atualização para o CRS 6.0 alguns menus ficarão faltando no AppAdmin. No AppAdmin > Control Center > License Information Page, o License Package Type exibirá None.

Solução: Mude o valor do filtro da licença CRS no LDAP para o tipo de licença novo.

Entrada do filtro da licença no 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

Após efetuar as mudanças no LDAP, reinicie o CRS Node Manager no servidor CRS.

Processo de instalação/atualização deixado como autônomo

Os processos de instalação, atualização e restauração são bastante críticos e devem ser seguidos cuidadosamente de acordo com o guia. Às vezes, o BARS pode mudar para o estado Not Responding. A Cisco recomenda que você presencie o processo inteiro de atualização, instalação e restauração.

Uso da ferramenta de pré-atualização

Como descrito no Guia de Instalação, você deve executar a ferramenta de pré-atualização (PUT) antes de executar o processo de restauração. A sua utilização é incluir a licença do CRS 6.0 no LDAP, para que o arquivo de backup contenha as licenças do 6.0.

Página do BARS esmaece

A página de exibição do BARS esmaece intermitentemente durante o processo de restauração. Este problema é documentado pela identificação de bug Cisco CSCsa82969 ( somente clientes registrados) Isso é considerado um problema de aparência. Para resolver esse problema, atualize a janela filho (pressione F5). Isso deve ser feito apenas na janela de status do BARS e não na janela principal de restauração do BARS.

Coleção de registros BARS

Antes de você criar uma nova imagem do servidor CallManager da Cisco, os registros do BARS precisarão ser salvos. Consulte Registros exigidos para backup/restauração/atualização para obter mais informações. Os detalhes do arquivo são mencionados no Guia de Administração do Sistema de restauração e backup de telefonia IP da Cisco (BARS).

Os backup falham com este erro: * 86 - O erro desconhecido ocorreu ao conectar ao host

Problema

Os backup programados e manuais estão falhando com erro * 86 - erro desconhecido ocorreram ao conectar para hospedar. O sistema de backup aceita o caminho de rede e a informação de conta, mas o backup falha.

Solução

Siga estes passos para resolver esse problema:

1. Alcance o server UCCX e navegue ao Iniciar > Executar, e datilografe o CET.

2. Quando o mensagem de advertência aparece, clique NÃO.

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

4. No lado direito, fazer duplo clique o registro ID.

5. Clique a aba com.cisco.crs.cluster.config.ArchiveAdminConfig, e cancele a senha sob o armazenamento alternativo.

6. Clique em Apply.

7. Navegue a Appadmin > a ferramentas > alternativo e restauração.

8. Sob o local de armazenamento alternativo, datilografe a senha nova, e clique a atualização.

Depois que você termina estas etapas, você pode executar o backup. Se o backup falha, reinicie o server, e tente o backup outra vez. Se o backup ainda falha, você pode navegar ao CET, cancela todos os campos, e datilografa então a informação nova para o local de armazenamento.

UCCX 7.x: Falha do backup das BARRAS

Problema

O backup das BARRAS falha com este Mensagem de Erro:

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

Esta edição é documentada na identificação de bug Cisco CSCsy04635 (clientes registrados somente).

Solução

A fim resolver esta edição, reinicie Node Manager.

UCCX 8.x: O backup das BARRAS falha em 87%

Problema

O backup pendura em 87% com o CCXCOMPONENT que dá o erro em 30%.

Solução

A fim resolver esta edição, execute este comando da interface de linha de comando:

utils service restart Cisco DRF Master

A restauração UCCX 7.x do backup pendura em 15%

Problema

Quando você tenta restaurar um backup de UCCX 7.x, pendura em 15% e você recebe este Mensagem de Erro:

Desde que o backup foi tomado quando HA e desde que este outro nó não existe atualmente no conjunto não pode continuar.

Solução

Desde que o backup foi recolhido um ambiente de alta disponibilidade ambos os Nós devem estar no conjunto para que você restaure a informação. Você pode restaurar os arquivos de backup em um requisito de alta disponibilidade do desenvolvimento usando uma destas opções:

• Se o requisito de alta disponibilidade da instalação é já no lugar e ambos os Nós estão adicionados como parte do mesmo conjunto, o processo da restauração é similar ao desenvolvimento do nó único; pode ser feito de todo o nó e restaurará dados em ambos os Nós.

• Se o requisito de alta disponibilidade da instalação não é no lugar e ambos os Nós são frescos instalado ou reimaged antes de instalar o CCX unificado, termine estas etapas a fim restaurar:

  1. Inicie o processo da restauração do primeiro nó. A restauração terminará 15% e alertá-lo-á adicionar o segundo nó para aglomerar-se.

  2. Adicionar o segundo nó através do assistente de configuração. Uma vez que você adiciona o segundo nó, a restauração estará completa e o requisito de alta disponibilidade da instalação estará pronto.

A restauração falha em 69%

Problema

Quando você promove o server UCCX 4.5 a 7.0, a restauração de dados UCCX 4.5 falha com este erro:

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

Solução

Esta edição é documentada na identificação de bug Cisco CSCsr56145 (clientes registrados somente). A ação alternativa é remendar 7.0(1) o sistema com a liberação a mais atrasada do serviço (SÊNIOR) e executar outra vez a restauração.

Informações Relacionadas

• A restauração dos dados UCCX com falha do Mensagem de Erro “não atualiza o estado preliminar de Datastore da configuração CR no nó 1"
• Suporte Técnico e Documentação - Cisco Systems