Voz e comunicações unificadas : Cisco Unified Communications Manager Version 7.1

Gerente 7.x/8.x das comunicações unificadas de Cisco: Pesquise defeitos a edição alternativa

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Os backups do Cisco Unified Communications Manager não estão executando como programados. Todos os serviços da Estrutura de Recuperação de Desastres (DRF) estão para inativos e nenhum dispositivo, programação ou estado novo pode ser visualizado do console da DRF. Este documento discute como resolver este problema.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

A informação neste documento é baseada no gerente 7.1(3)/8.x das comunicações unificadas de Cisco.

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.

Problema

Os backups do Cisco Unified Communications Manager não estão executando como programados. Todos os serviços da Estrutura de Recuperação de Desastres (DRF) estão para inativos e nenhum dispositivo, programação ou estado novo pode ser visualizado do console da DRF. Também, quando você alcança as páginas de admin DRF, este Mensagem de Erro é recebido:

Status:  Local Agent is not responding. 
This may be due to Master or Local Agent being down.

http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unified-communications-manager-version-71/111796-cucm-drf-01.gif

Este alerta RTMT é recebido durante a falha alternativa:

CiscoDRFFailure Reason : Master Agent was unable to send a 
backup/restore request to the local agent. 
Node [ELS-PUB1] is not connected. 
AppID : Cisco DRF Master 
ClusterID : NodeID: ELS-pub1 .
The alarm is generated on Tue Nov 24 02:00:04 PST 2009

Solução

Primeiramente, verifique se o número de série do certificado no keystore do editor esta presente no Truststore de todos os assinantes. Conclua estes passos:

  1. Entre à página de administração do OS CUCM do servidor do publicador da instalação do conjunto. Escolha o > gerenciamento de certificado da Segurança. Os indicadores do indicador da lista do certificado.

  2. Você pode usar o achado controla a fim filtrar o certificado.

  3. Clique sobre o arquivo ipsec.pem e verifique o número de série do certificado.

  4. Entre à página de administração do OS CUCM de cada nó do conjunto. Escolha o > gerenciamento de certificado da Segurança. Os indicadores do indicador da lista do certificado.

  5. Você pode usar o achado controla a fim filtrar o certificado.

  6. Clique sobre o arquivo ipsec-trust.pem com o nome de arquivo do hostname do editor e verifique o número de série do certificado.

  7. O número de série do certificado deve ser mesmo em todos os Nós do conjunto. Se o número de série de qualquer nó é combinado mal, termine estas etapas.

    1. Entre à página de admin do OS CUCM de nó afetado.

    2. Escolha o > gerenciamento de certificado da Segurança. Os indicadores do indicador da lista do certificado.

    3. Você pode usar o achado controla a fim filtrar o certificado.

    4. Clique sobre o arquivo ipsec.pem e transfira esse certificado.

    5. Encontre a IPsec-confiança existente com o nome de arquivo do hostname do editor, clique sobre o nome de arquivo e suprima-o.

    6. Transfira arquivos pela rede o arquivo transferido ipsec.pem com a IPsec-confiança do subtítulo.

    7. Reinicie o agente local do mestre Agent(MA)/DRF DRF (LA).

Erro: Não pode escrever: Tubulação quebrada

Backup DRF falhado com este Mensagem de Erro:

/bin/tar: -: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now
CCMDB Backup failed, unable to tar data to master agent
Restoring CAR services ...

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

Como uma tentativa uma da ação alternativa destas etapas:

  1. Mensagens ativa do cliente do desabilitação no servidor de SSH aberto

  2. Ajuste o ClientAliveCountMax e o ClientAliveInterval altamente bastante a uma contagem/intervalo assim que o server não faz intervalo a conexão a CUCM durante o backup.

  3. Reinicie o agente local do mestre Agent(MA)/DRF DRF (LA).

Os DR penduram durante o backup CCMDB

Problema

Os DR penduram durante o backup CCMDB se há número grande de arquivos CDR/CMR acumulados no dobrador da conserva. Esta edição é documentada na identificação de bug Cisco CSCsl16967 (clientes registrados somente).

Nota: Se você para o serviço CAR, não para a acumulação de arquivos lisos CDR.

Solução

Siga estes passos para resolver esse problema:

  1. Termine estas etapas a fim limpar temporariamente os arquivos CDR de modo que os DR possam continuar:

    1. Pare o serviço do agente CDR em todos os server no conjunto, de modo que nenhum arquivo novo CDR seja empurrado para o editor.

    2. Execute este comando a fim verificar que todos os arquivos estiveram empurrados para os server do faturamento:

      file list activelog /cm/cdr_repository/destination/*
      
  2. Termine estas etapas a fim verificar que não há nenhum link simbólico em algumas das subpastas:

    1. Pare o gerenciador de repositório CDR, o agendador CAR, e de Web CAR serviço no editor.

    2. Use este comando a fim remover todos os arquivos sob o <date de /var/log/active/cm/cdr_repository/preserve/ > que foram acumulados:

      file delete activelog /cm/cdr_repository/preserve/* noconfirm
      
    3. Use este comando a fim remover todos os links simbólicos sob o <date de /var/log/active/cm/cdr_repository/car/ >:

      file delete activelog /cm/cdr_repository/car/* noconfirm
      
    4. Reinicie o gerenciador de repositório CDR, o agendador CAR, e de Web CAR serviços no editor.

  3. Termine estas etapas a fim parar uma acumulação mais adicional de arquivos CDR:

    Nota: A fim parar uma acumulação mais adicional de arquivos CDR, você deve começar o serviço do agendador CAR, ajusta o carregador para programar a carga contínua, e a carga CDR somente.

    1. Se não é criado ainda, crie uma conta do ccmadmin no Gerenciamento do grupo de usuário na página do ccmadmin.

    2. Entre ao CAR, e vá ao sistema > ao planificador > à carga CDR.

    3. Verifique a carga contínua 24/7 e as caixas de seleção da carga CDR somente, e clique a atualização.

    4. Escolha o sistema > o banco de dados > configuram a remoção automática do banco de dados.

    5. Incorpore 1 para a idade mínima dos registos dos destalhes da chamada e do max age dos registos dos destalhes da chamada, e clique a atualização.

    6. Escolha a configuração > a Geração automática/alerta do relatório.

    7. Para cada relatório, escolha deficiente, e clique a atualização.

  4. Reinicie o serviço do agente CDR em todos os server.

Erro: O sistema é travado atualmente por um outro processo. Tente por favor outra vez mais tarde

Os backup DR param para executar automaticamente e quando você tenta um backup manual, você obtém a operação de backup atualmente em andamento. Por favor espere e tente após algum dia o Mensagem de Erro. Quando você tenta instalar uma nova versão ou um arquivo da BOBINA, você obtém o o sistema está travado atualmente por um outro processo. Tente por favor outra vez um Mensagem de Erro mais atrasado. Esta edição ocorre se DRF é backup programado o server CUCM automaticamente. Isto é documentado pela identificação de bug Cisco CSCsr87199 (clientes registrados somente).

Solução

Restaure o agente principal DRF a fim resolver a edição.

O backup falha com erro de winsock

Com CUCM 8.x, o backup falhou com o Mensagem de Erro do erro de winsock 10054/10035/10053.

Solução

Certifique-se de que o Firewall está desabilitado no dispositivo de backup remoto e execute-se o backup outra vez.

O backup DRF faz não Certificados alternativos

Com CUCM 8.x, em um server restaurado elevação da ponte, o arquivo ITL não tem um signatário válido. Os telefones não têm serviços dos https se o editor é o servidor TFTP. Em uma migração ao UCS, ou em nenhum hardware novo onde um alternativo e uma restauração são executados, os telefones não aceitam arquivos de configuração e mudanças do conjunto novo sem a exclusão manual da ITL existente dos telefones.

Quando você restaura de uma hipótese de recuperação de desastres, os telefones já não reconhecem sua configuração ou arquivos ITL após a restauração DR se o server restaurado era o servidor TFTP. Os telefones não podem reconhecer alterações de configuração ou elevações até que sua ITL existente esteja suprimida e substituída com a ITL recentemente gerada.

Também, quando você emite o comando CLI ITL da mostra nos server, este Mensagem de Erro aparece:

This etoken was not used to sign the ITL file.
Verification of the ITL file failed.
Error parsing the ITL file

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

Solução

Após uma situação da migração da Recuperação de desastres ou do hardware, termine estas etapas.

  1. Regenere o arquivo CallManager.pem (somente no server restaurado) à sincronização o arquivo CallManager.pem no sistema de arquivos a esse no banco de dados.

  2. Reinicie TV e TFTP.

  3. Para um conjunto do nó único, ou somente um servidor TFTP, suprima do arquivo ITL manualmente de todos os telefones no conjunto.

  4. Para um multi conjunto do nó, os telefones devem automaticamente usar TV de server alternativos do grupo do CallManager a fim autenticar o arquivo novo ITL. Alternativamente os telefones podem ser apontados a um outro servidor TFTP no conjunto.

Depois que uma elevação da ponte, termina estas etapas.

  1. Regenere o arquivo CallManager.pem (somente no server restaurado) à sincronização o arquivo CallManager.pem no sistema de arquivos a esse no banco de dados.

  2. Reinicie TV e TFTP.

  3. Os telefones precisam de ser restaurados a fim transferir o arquivo novo ITL, mas não devem precisar de ter o arquivo ITL suprimido porque nunca teriam um arquivo válido ITL a transferir até agora.

Mensagem de Erro: decrypt ruim 16404:error

Com CUCM 8.x, a restauração DR falha para os componentes TFTP com este Mensagem de Erro

error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Solução

Este Mensagem de Erro é uma indicação da má combinação do endereço IP ou nome do host. Certifique-se de que o server CUCM tem o mesmos endereço IP de Um ou Mais Servidores Cisco ICM NT e hostname que nos servidores de MCS de onde o backup é encontrado. Se o hostname não é o mesmo que o servidor de backup, você precisa de alterar o hostname a fim ser o mesmo que o servidor de backup e executar outra vez a restauração.

Erro na página alternativa em CUCM

Problema

Quando você navega à página alternativa, o agente local não está respondendo. Isto pode ser devido dominar ou o agente local que é abaixo do Mensagem de Erro aparece. Isto igualmente acontece quando você tentar adicionar um dispositivo alternativo.

Solução

Siga estes passos para resolver esse problema:

  1. Entre à página de admin do OS CUCM.

  2. Escolha o > gerenciamento de certificado da Segurança.

  3. Verifique o número de série para ver se há o arquivo ipsec.pem.

  4. Assegure-se de que o número de série combine o arquivo ipsec-trust.pem para os assinantes.

  5. Reinicie o mestre de Cisco DRF e o serviço local DRF no editor.

  6. Ative o serviço TFTP.

Incapaz de adicionar o dispositivo de backup

Problema

Você é incapaz de adicionar o dispositivo de backup na página CUCM DR.

Solução

A fim resolver esta edição, você precisa de adicionar o servidor SFTP Cisco-recomendado como o dispositivo de backup. Você pode usar qualquer destes servidores SFTP:

  • Abra o SSH — para sistemas Unix

  • Cygwin leavingcisco.com

  • Titã leavingcisco.com

  • Server de GlobalSCAPE EFT — conhecido anteriormente como GlobalSCAPE fixe o servidor FTP

Cisco recomenda o Produtos SFTP que é certificado com Cisco com o programa parceiro do colaborador da tecnologia de Cisco (CTDP).

Consulte para configurar o servidor de backup para o gerente das comunicações unificadas de Cisco para mais informação.

Incapaz de restaurar o server CUCM 8.x

Problema

Este Mensagem de Erro aparece quando você tenta restaurar CUCM 8.5:

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Solução

Este erro ocorre se o DNS foi configurado quando o backup foi tomado, mas não foi configurado quando a restauração está sendo feita. A fim resolver esta edição, termine as etapas:

  1. Configurar o DNS antes que você execute a restauração.

  2. Assegure-se de que o FQDN do server esteja solucionável pelo DNS.

    Nota: Isto é documentado na identificação de bug Cisco CSCtk05743 (o clientes registrados somente)

Incapaz de restaurar CUCM 8.5

Problema

Incapaz de restaurar um server 8.5, dando o seguinte erro:

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Solução

Esta edição pode ocorrer se há qualquer má combinação do IP/hostname/senha de segurança. Contudo, todos são combinados neste caso.

A edição é com relação ao DNS/informação de domínio que não está sendo configurado no server para combinar. Isto ocorrerá se o DNS foi configurado quando o backup foi tomado, mas não foi configurado quando a restauração está sendo feita.

Para resolver esta edição configurar o DNS antes de executar a restauração. Assegure-se de que o FQDN do server esteja solucionável pelo DNS.

Nota: Isto é documentado na identificação de bug Cisco: CSCtk05743 (clientes registrados somente)

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 111796