Architecture for Voice, Video and Integrated Data

Cisco Unified Communications

Archive for the ‘Bugs’ Category

Silent monitor falha ao iniciar UCCX 10.x

Posted by gvillarinho em 06/05/2014

Pessoal,

Para quem interessar, após instalar e configurar o UCCX 10.x e Finesse, quando realizamos o silent monitor ocorre erro “CTIError= Invalid Input”.

Isso ocorre porque o máximo de dígitos que a string para formar a chamada CTI no Finesse pode receber do ramal do agente é até 11, ou seja, caso utilizem padrão E.164 (Exemplo +551141966633) no ambiente em que possua UCCX 10.x com Finesse, vai ocorrer esse erro, pois quando utilizamos o E.164 no Brasil temos 13 dígitos (contando com o +).

O workaround da Cisco é diminuir os dígitos dos agentes para 11 ou menos, assim funcionaria normalmente.

Link do Bug (requer CCO): https://tools.cisco.com/bugsearch/bug/CSCuo34368

OBS: Lembrando que isso ocorre apenas com  o Finesse, caso utilize CAD com mais de 11 dígitos acredito que não terá problemas porque utiliza outro mecanismo de monitoria silenciosa.

OBS2: O CAD não suporta o + na frente dos dígitos caracterizando formato E.164.

Anúncios

Posted in Bugs, UCCX | 2 Comments »

BLF Speed Dial Unmapped Exception

Posted by Leonardo Degobi em 08/04/2013

Olá pessoal. Boa tarde.

Estava fazendo uma simples configuração de BLF (Busy Lamp Field) quando apareceu o seguinte erro:

erro

Este erro apareceu após fazer a pesquisa e adicionar o ramal escolhido para a tecla BLF. Cliquei para salvar e surgiu o erro.
Contudo, esse é um bug relatado pela Cisco: CSCtn65309 e pode ser visto no Bug Toolkit (http://tools.cisco.com/Support/BugToolKit)

O Victor também teve este problema e relatou no fórum:
https://supportforums.cisco.com/message/3876434#3876434

Segue as informações do bug:
BLF Speed Dial Unmapped Exception
Symptom:
Unmapped Exception Null received when editing/saving BLF Speed Dials.

Conditions:
Select any devices BLF Speed Dial extension on the phone configuration page. Then highlight an
extension, right click with the mouse to Cut it, then right click to paste it into a different field
when being saved we get a “Unmapped Exception null”

Workaround:
Use Control-X and Control-V

Espero que ajude.

abs,

Degobi

Posted in Bugs, Callmanager | Leave a Comment »

Error SQL em consulta do BAT

Posted by gvillarinho em 11/01/2013

Após atualizar seu Cisco Unified Communications Manager da versão 8.6(2a) para 8.6(2a)SU2, toda vez que você acessa o BAT(conhecido como Bulk Administration Tool para realizar pesquisa ou atualização em massa no sistema) e selecione a opção Phones > Update phones > Query e utiliza um filtro de pesquisa “bem genérico” você se depara com a seguinte mensagem de erro:

“Error occurred while retrieving information from database. java.sql.SQLException:A syntax error has occurred.”

clip_image002

Este é um problema já conhecido pela Cisco nesta nova versão do CUCM com o bug ID #CSCub67519.

Sua solução definitiva seria atualizar para 9.0(1) ou 9.1(1) ou mesmo aquelas versões 8.6.2 “Engineering Special” da Cisco que corrigi especificamente alguns bugs críticos, porém é feito em caráter emergencial então pode trazer mais dor de cabeça do que tranquilidade. Todas as vezes que usei atualizações ES da Cisco não tive experiências muito boa, então fica por conta e risco, se optar por fazer atualização para ES é necessário abrir um TAC solicitando a versão(esse era o procedimento que fiz na versão 4.x e 5.x a muito tempo atrás, acredito que esteja na mesma ainda hoje, se não está me desculpem pela informação errada).

Mas, por outro lado, a solução de contorno para esse problema é muito simples, basta quando acessar a parte de update dos phones ( Bulk Administration Tool > Phones > Update Phones > Query ) selecione ao menos 2 filtros, um com a sua informação desejada e outro pode ser, por exemplo, um search em description em branco, essa description em branco não alterará o valor final pois por padrão a consulta já vem com um AND(e) lógico. Exemplo:

clip_image004

Mais informações ? Acesse o link do bug aqui (necessário acesso CCO com permissão)

Posted in Bugs, Callmanager | Leave a Comment »

Bug na firmware do HD de servidores MCS IBM – 7816-I4 e MCS-782x-I4

Posted by loliveira em 10/12/2012

Fala Galera, peguei 3 problemas no ultimo mês relacionado a isso, parece brincadeira ! Devido a uma falha em firmwares anteriores a 3B06 do HD nos servidores mencionados no titulo, você poderá enfrentar o bug CSCti52867. Que faz com que o HD fique em estado de Read-Only permitindo apenas leitura.

Para certificar-se que o problema é este:

Ao tentar acessar o servidor via console será exibido a seguinte mensagem:

EXT3-fs error (device sda6) in start_transaction: Jornal has aborted

via SSH aparecerá a seguinte mensagem:

java.io.FileNotFoundException: /var/log/active/platform/log/cli.bin (Read-only file system)

at java.io.RandomAccessFile.open(Native Method) 
at java.io.RandomAccessFile.(RandomAccessFile.java:212)



at org.apache.log4j.Category.info(Category.java:674) 
at sdMain.main(sdMain.java:611) 
log4j:ERROR No output stream or file set for the appender named [CLI_LOG]

 

Para corrigir isto o Fabricante já reconheceu a falha e forneceu a correção definitiva = Upgrade da Firmware do HD destes servidores.

Para isso você deverá aplicar um patch para “preparar” o sistema antes de fazer o upgrade do HD. Trata-se de um arquivo minusculo e você pode fazer a atualização via OS Administration do CUCM.
ciscocm.ibm-diskex-1.0.cop.sgn

Depois você deverá baixar uma mídia inicializável para realizar o upgrade.
Cisco-HDD-FWUpdate-3.0.1-I.ISO

Com a mídia em mãos, reinicie o servidor com o CD inserido no leitor e siga os passos. Que por sinal é bem didático. Feito isso é só correr pro abraço e ficar tranquilo pois seu servidor não será mais interrompido.
Lembrando que como a solução definitiva existe, não se deve solicitar o RMA do HD. Pois trata-se de uma falha no software.

Documento oficial do fabricante: http://www.cisco.com/en/US/ts/fn/633/fn63374.html

Atenção: Este problema pode ocasionar em uma “bagunça” na estrutura de arquivos do HD o que pode impedir o servidor de inicializar. Se isto acontecer será necessário inserir um CD de recovery para rodar um tipo de check disk e corrigir as eventuais falhas. Mais informações: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080b1f305.shtml

Posted in Bugs, Callmanager | Etiquetado: , | 1 Comment »

SIP Trunk – VCS para CUCM – SIP Cancel message

Posted by Paulo Souza em 30/10/2012

Olá Pessoal,

Está é a minha primeira postagem no AVVID e gostaria de compartilhar com vocês um problema que encontrei recentemente quando estava estabelecendo um SIP Trunk entre CallManager (versão 8.6) e VCS (Video Communication Server).

Cenário

Antes de começar a falar do problema, deixe-me explicar a necessidade da criação do Trunk entre CallManager e VCS. No mundo de Telepresence da Cisco, a palavra do momento é “interoperabilidade”. Isto significa permitir dispositivos diferentes, que utilizam protocolos diferentes, normalmente de fabricantes diferentes – se comunicarem dentro da mesma estrutura de Telepresença e Vídeo Conferência. A Cisco atualmente ampliou a capacidade de interoperabilidade entre os equipamentos de Telepresença e Video conferência de seu portfólio. Atualmente já é possível integração direta entre VCs e TPs sem a necessidade de qualquer MCU para intermediar o tráfego. Esta nova capacidade foi inserida a partir da versão 8.5.1 do CUCM e foi bastante aprimorada na versão 8.6.2. Falaremos desta compatibilidade em outro tópico.

Considerando este fator de interoperabilidade direta entre Telepresença e Video conferência, é muito comum termos o seguinte deployment:

  • VCS – Vários endpoints de Vídeo Conferência registrados como SIP, tais como c20, c40, MXP 1700, Ex90, MCU Codian, Telepresence Server e etc.
  • CallManager – Várias Telepresences Cisco registradas como SIP, tais como CTS 1300, 3000, 3200, TX 1300, 9000 e etc.
  • SIP Trunk – Neste caso temos um SIP Trunk estabelecido entre VCS e CallManager para permitir o mundo de VC conversar com o mundo de TP.

Bom, dado o cenário, vamos ao problema:     =)

O Problema

Uma Telepresence (registrada no CallManager) efetua uma ligação para o Telepresence Server ou qualquer outra VC (Registrada no VCS). A chamada não funciona. No Log do VCS vemos que o CallManager inesperadamente envia uma mensagen Cancel para o VCS e a chamada encerra antes de ser estabelecida. Vejam a sinalização:

SIP Trunk CUCM to VCS problem. CallManager Sends a cancel message

Olhando no Log do CallManager, notei que o CallManager, após receber as mensagens SIP, estava tentando fazer uma resolução de nome SRV no DNS.  =O

  • 22:18:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: Received
  • SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^*
  • 22:18:54.838 |//SIP/SIPDns(1,72,1)/copyRecordRspToRecordReq: Retry SRV
  • query as an 1 query|0,0,0,0.0^*^*
  • 22:18:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A or
  • AAAA query called as SRV query Fail):hostname=videoconf.int,
  • ReqType=1,serversused=0
  • 22:18:54.839 |//SIP/Stack/Transport/0xf1860b0/Sending CANCEL to the
  • transport layer|0,0,0,0.0^*^*

Este domínio videoconf.int é o domínio SIP que estava sendo usado no VCS. Todas as VCs registravam no VCS a SIP URI no formato ramal@videoconf.int. Então nas mensagens SIP das VCs, o campo de contato sempre contém ramal@videoconf.int. O que o CallManager estava fazendo era pegar a porção de domínio da URI do endpoint que recebeu a ligação, no caso, videoconf.int, e fazer uma consulta SRV no DNS para desocobrir quem é o servidor SIP que atende por este domínio. Como a consulta DNS falha, então o CallManager envia uma mensagem de Cancel e encerra a chamada.

Bom, o CallManager não deveria fazer uma consulta SRV no DNS para tentar descobrir qual é o servidor SIP, pois a message SIP recebida continha o campo “Record-route” no cabeçalho, indicando o endereço IP do Servidor SIP para o qual a chamada deve ser roteada, neste caso, o IP do VCS. O CallManager só deveria consultar o DNS via SRV se não houvesse “Record-route” na mensagem SIP.

Este comportamento bizarro do CallManager refere-se ao Bug CSCty07061 encontrado nas versões mais novas do CUCM, são elas:

  • 9.0(1)
  • 8.6(2.21020.1)
  • 8.6(2.21900) – Meu caso
  • 9.0(0.99081.4)
  • 9.0(0.98000.64)

Também é possível encontrar este problema na versão 8.5.1.

Workaround

Há duas formas de resolver temporariamente este problema. As duas formas podem ser bastante trabalhosas dependendo da estrutura do ambiente.

Workaround 1:

Alterar a SIP URI dos endpoints de Video conferência. Ao invés de utilizar o ramal@dominio_sip, pode-se usar ramal@endereço_IP_VCS. Deste modo o campo de contato na mensagem SIP não terá nenhum domínio, assim o CUCM não tentará fazer qualquer resolução. Mas imagine reconfigurar algumas dezenas de endpoints… trabalhoso, não é? Se você tiver o TMS pode facilitar. Mas o principal trabalho vai ser mudar a estrutura de roteamento no VCS, pois o comum é criar as search rules e transforms sempre se baseando na URI com domínio SIP.

Workaround 2:

Configurar o servidor DNS para resolver entradas de serviço (SRV Records) para o protocolo SIP, apontando o endereço IP do VCS e porta de SIP utilizada. Vejam abaixo um exemplo:

Crie um entrada tipo A no servidor DNS com os seguintes parametros:

  • Host: <Hostname VCS>.<dominio>. Exemplo: vcs-control.empresa.local
  • TTL: 86400
  • Type: A
  • Data: Endereço IP do VCS. Exemplo: 10.10.10.10

Agora crie uma entrada tipo SRV para o serviço SIP e associe-a com a entrada tipo criada acima:

  • Service: sip
  • protocol: udp (Pode-se usar tcp, udp ou tls, escolha o mesmo que esta sendo usado no SIP Trunk entre VCS e CUCM. Caso seja TLS ou TCP, então o parâmetro Service acima deve ser “sips”)
  • Host: <_sip._udp>.<Domínio Externo> (troque o udp por tcp ou tls, deve ser o mesmo configurado no parametro protocol. Note que o domínio deve ser o mesmo dominio SIP utilizado no VCS). Exemplo: _sip._udp.videoconf.int
  • Port: 5060 (Coloque 5060 se o protocolo for tcp ou udp, coloque 5061 caso seja tls)
  • Name: <dominio> (Deve ser o mesmo dominio SIP configurado no VCS). Exemplo: videoconf.int
  • TTL: 86400
  • Type: SRV
  • Priority: 10
  • Weight: 10
  • Target: Coloque o FQDN criado anteriormente para o VCS. Por exemplo: vcs-control.empresa.local

Com estas configurações, quando o CallManager consultar uma entrada SRV no DNS procurando o servidor SIP e a porta que devem ser utilizados para o domínio videoconf.int, o resultado da resolução será o endereço IP do VCS Control e a porta 5060. Assim a chamada não será cancelada.

Recomendo ter um especialista em DNS para realizar estas configurações. Pois o procedimento muda de acordo com o servidor DNS que está sendo utilizado.

Workaround 3

A Cisco sugere habilitar o parâmetro Rel1XX dentro do SIP Profile que está sendo usado no SIP Trunk que aponta para VCS Control, no CallManager. Este Workaround pode ou não funcionar. No meu caso, não funcionou.

Resolução definitiva

Não tem jeito. Para resolver o problema definitivamente é necessário fazer o upgrade do CallManager. Este bug foi corrigido nas seguintes versões do CUCM:

  • 9.0(0.98000.15)
  • 9.0(0.98000.19)
  • 9.0(0.99999.2242)
  • 9.0(0.98000.52)
  • 1.9(9.98000.7)
  • 9.0(0.98000.65)
  • 9.0(0.99081.7)
  • 8.6(2.22025.1)
  • 9.0(1.10000.15)
  • 9.0(1.10000.37)
  • 8.6(2.22900.9) – Meu caso

 

Bom pessoal, escolham o que é mais fácil para o ambiente de vocês: Mudar a URI dos endpoints (exige mudar rotas do VCS), criar entrada no DNS ou atualizar o CallManager.

Embora este tópico seja referente à SIP Trunk entre CUCM e VCS envolvendo equipamentos de Telepresence, é possível que o mesmo problema ocorra quando você tiver a mesma versão de CallManager apontando um SIP Trunk para um outro device cujas mensagens SIP também contenham domínio na URI do campo de contato.

 

Espero que seja útil. Até a próxima!

 

Paulo Souza

Posted in Bugs, Callmanager, Telepresence | Etiquetado: , | 1 Comment »

CUCM – Problema de Horario de Verão – Daylight Saving Time (DST) Issue

Posted by elvismarques em 18/01/2012

Olá UC Brothers,

Todos os anos sofremos psicologicamente e fisicamente com a mudança do horário de verão. Por que seria diferente com outras Entidades?

Sim… quem se aventura nesse mundo de UC sabe que a entidade MAIOR (Cisco Unified Communications Manager) também sofre com tal mudança.

É comum problemas no início e fim do horário de verão, onde o CUCM costuma mudar o horário 1 ou 2 semanas antes  (às vezes depois).

A fim de aliviar o sofrimento dos meus amigos na busca de uma explicação, relato abaixo um troubleshooting básico para descobrir e se precaver destes eventos catastróficos (pelo menos é o que os usuários dizem quando seus IP Phones estão com o horário errado “hehe”).

Execute o seguinte comando:

admin: run sql select * from typetimezone where enum = 17

Você verá um output parecido com este:

enum name              description          moniker                    bias                                      stddat       stdbias           dstdate        dstbias                   abbreviation            legacyname

==== ================= ==================== ========================== ==== =======  ============    =======    ==================== ======= ============ =======================================

17   America/Sao_Paulo (GMT-03:00) Brasilia TIMEZONE_AMERICA_SAO_PAULO 180  0/2/0/3,  00:00:00:00 0       0/10/0/3,   00:00:00:00 -60                  BST          E. South America Standard/Daylight Time

As informações importantes são:

Bias = 180
Stddate = 0/2/0/3,00:00:00:00
Stdbias = 0
Dstdate = 0/10/0/3,00:00:00:00

Dstbias = -60

O dstdate siginifica que o Callmanager ativará o horário de verão no 3º fim de semana do mês 10 (outubro) 0/10/0/3 e

O stddate significa que o Callmanager irá voltar para o horário “Standart” (std) no 3º fim de semana do mês 2 (fevereiro) 0/2/0/3 .

Como no Brasil temos um sério problema em relação a uma data fixa para o horário de verão, vemos mudanças ocorrerem automaticamente em dia errado.

Por exemplo, o horário de verão de 2011 para 2012 iniciou no 3º fim de semana de outubro (16/10/2011) porém irá acabar no 4º fim de semana de fevereiro (26/02/2012) (ver: http://pt.wikipedia.org/wiki/Anexo:Lista_de_per%C3%ADodos_em_que_vigorou_o_hor%C3%A1rio_de_ver%C3%A3o_no_Brasil). Sendo assim o CallManager que apresentar o output acima na teoria irá atualizar o horario uma semana antes do esperado.

Além do troubleshooting básico acima demonstrado há o detalhe de que este comportamento também se trata de um BUG:

BUG ID: CSCtc85618

Link para quem tem um CCO válido: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtc85618

Ele faz menção á Argentina porém também se aplica ao Brasil.

Você precisa estar em uma destas versões para evitar o problema

8.0(0.98000.91)

7.1(3.21900.4)

7.1(3.21006.1)

8.0(1.10000.40)

7.1(5.10000.12)

Para versões  7.1.3 você pode aplicar o seguinte patch:

http://www.cisco.com/cisco/software/release.html?mdfid=282421166&flowid=5328&softwareid=282074298&release=7.1%283-2010i-2%29&rellifecycle=&relind=AVAILABLE&reltype=all

Não há atualmente correção para versões anteriores à 7.1.3

Caso… mesmo estando numa versão “teoricamente” corrigida mas o output do comando apresentar os dados conforme inicio do post, fique de prontidão e atento à Mudança pois há uma grande possibilidade do horário alterar no 3º fim de semana!!!! J

Bem… Essas informações são um resumo de vários anos de troubleshooting na mudança do horário e inúmeras tentativas de conseguir algum parecer mais aceitável do TAC.

OBS: de qualquer forma sempre fique atento à mudança… SEMPRE…

Um forte abraço e espero ter ajudado um pouco mais na jornada de todos…

Sucesso!

Elvis Marques

Posted in Bugs, Callmanager | 11 Comments »

Cisco Notification Service

Posted by loliveira em 26/08/2011

Ai vai uma dica do colega José Paulo que me mandou por email.

Acompanhamento de bugs e e securities advisory: http://www.cisco.com/cisco/support/notifications.html

Pra receber por email notificações de bugs e problemas de segurança, como por exemplo:
http://www.cisco.com/warp/public/707/cisco-sa-20110824-cucm-cups.shtml
http://www.cisco.com/warp/public/707/cisco-sa-20110824-cucm.shtml

E complementando:
Pra quem gosta de Feed´s , basta selecionar a tecnologia e usar em seu leitor de RSS preferido.
http://www.cisco.com/en/US/support/tsd_rss_field_notice.html

Abços

Posted in Bugs | Leave a Comment »

CUCM 6.1.4 – BUG CSCtd03811

Posted by leonardotns em 23/08/2011

É isso ai senhores, resolvi compartilhar um bug que encontrei neste ultimo mês. Neste cliente os telefones perdiam o registro constantemente e mostravam no visor dos telefones IPs a mensagem Configuring IP,  quando registrado no menu do telefone dentro de estatísticas de rede aparecia a mensagem UCM-close-TCP. Para validarmos isso abri um caso na Cisco após varias analises o engenheiro confirmou o bug, foi feito o update para uma das versões em que o mesmo foi corrigido.

O CUCM não consegue manter todas as suas portas TCPs abertas e acaba fechando a comunicação enviando a mensagem CLOSE_WAIT ou FIN_WAIT1, isso você consegue visualizar pela CLI do CUCM com o comando sh network status.

Segue abaixo os detalhes deste bug, lembrando que é necessário CCO para acessa-lo.

CSCtd03811 Bug Details

Callmanager Service unable to send packets on all of its TCP Ports
Symptom:
CallManager service stops sending packets on all of its TCP ports.This leads to
i) Phones fail-over from the node they are registered to the fail-over node.
ii) MGCP Gateways unregister
iii) Unable to setup calls to H323 devices and ICT Trunks
iv) SIP devices with TCP ConnectionsConditions:

Workaround:
To restart call manager service.

Additional Informatin:
‘show network status’ shows lots of TCP connections in ‘Close_wait’ state.

1st Found-In  – Primeiras Versões em que o bug foi achado
6.1(4)
7.0(2)
7.1(2.31900.1)

Fixed-In – Versões em que o bug foi corrigido
7.1(4.98000.82)
8.0(0.98000.109)
7.1(3.21008.1)
7.1(2.32022.1)
6.1(4.39000.201)
6.1(4.2223.1)
7.0(2.23037.1)
6.1(5.10000.10)
8.0(1.10000.40)
7.1(5.10000.12) Parte inferior do formulário

Abraço

Posted in Bugs | Leave a Comment »

CUCM 8.x em Vmware – Falha de comunicação

Posted by Aderno em 17/08/2011

Olá amigos, de acordo com algumas dicas já publicadas aqui antes, é possível criar um CD inicializável para instalar o CUCM a partir das imagens disponibilizadas pela Cisco, vide post.

Como citei no meu ultimo post, usei uma VM do CUCM 8.5 para estudar pro CIPT1 v8.0, então segue algumas dicas, que podem ser usadas após a instalação do CUCM sobre uma falha que encontrei.

Depois de ter instalado o CUCM 8.5, tive problemas para acessar a interface GUI ou mesmo a CLI via telnet. Percebi que não tinha conectividade com a maquina virtual e portanto, só conseguia acessar pela console do VMware. O sintoma básico era que conseguia pingar por algum tempo, mas depois de iniciado todos os serviços, perdia a conectividade com o CUCM.

Depois de muito quebrar a cabeça,  depois de pedir ajuda aos colegas do blog e revisar os serviços do CUCM, e depois de muitas pesquisas na net, descobri que a solução para o problema era algo que qualquer ex técnico de computador saberia se não estivesse tão enferrujado como eu:  problema de driver.

Isto mesmo, o Vmware, que era o software de virtualização que eu estava usando, também tem drivers para funcionar com determinados tipos de sistemas, que é conhecido com VMTools. E não é diferente para o CUCM, mas precisamente para o RedHat 4.0. A vmware disponibiliza o VmTools com os drivers para o RedHat, que sem eles, não permitem que a rede funcione corretamente no CUCM8.5. O legal é que o Vmtools trás um monte de melhorias para a VM como desempenho do vídeo, velocidade e sincronismo do mouse, funções de copiar e colar entre a VM e o host e etc.

A instalaçao do VmTools depende do cliente Vmware que vocÊ estiver usando, eu estava usando o VMware Server que não mostrava nenhuma atualização, depois mudei pro VMware Player que automaticamente mostrava que existia uma atualização pro sistema que eu estava usando (Linux), então tive que fazer o download da atualização. Você pode encontrar mais detalhes para o seu cliente Vmware neste link.

Resumido o procedimento:

  1. Inicie a maquina virtual do CUCM  e depois de carregado o sistema, acesse a console e conecte na CLI do CUCM com a senha de administrador;
  2. Inicie a instalação do VmTools primeiro no cliente VMware. Este passo vai depender da versão do VMware que você está usando, aqui vou mostrar um exemplo com o Vmware Player:
    Na janela de console da maquina virtual, clique no menu “Virtual Machine” e depois em “Update Vmware Tools…”:
    – Clique em “Yes” para continuar o processo:
  3. Baseado no sistema operacional usado na VM  é montado a imagem do VMTools específico no CD-ROM, neste caso para Linux.
  4. Você poder ver a versão do VMtools rodando, usando o comando: utils vmtools statusdentro CUCM:
  5. Depois disso, inicie a instalação do VMtools dentro do CUCM com o comando: utils vmtools upgrade, você receberá um alerta,  então confime digitando Yes e depois enter:
  6. Pode levar vários minutos e o sistema vai reiniciar no mínimo 2 vezes. Depois disso, confirme a atualização com o comando utils vmtools status:

Pronto, agora é só se “divertir” com seus labs. Boa sorte.

Posted in Bugs, Callmanager, CCNP-V | 1 Comment »

RECOVERY DISC pode não restaurar os arquivos corrompidos do CUCM

Posted by elvismarques em 28/01/2011

Olá UC Brothers,

Neste post apresento uma triste realidade . O RECOVERY DISC pode não restaurar os arquivos corrompidos do CUCM.

DESCRIÇÂO

Após interrupção do fornecimento de energia do Cisco Unified Communication Manager (CUCM) pode haver a corrupção dos arquivos da base gerando um erro ao tentar realizar o boot.

É necessário a utilização do RECOVERY DISC (CD fornecido juntamente com os CDs de Instalação do CUCM) para restabelecer o sistema.

Após a utilização do RECOVERY DISC o CUCM é restaurado porém não há garantia de que não haja arquivos corrompidos não denunciados durante a restauração com o CD.

O BUG abaixo descrito relata o problema:

CSCth53322 Bug Details

Document the need for system rebuild after file system repair
Symptom:
Symptom is in a running state but part of the file system is corrupt causing certain features to fail.
Conditions:
This can occur if a server goes down and needs to be recovered using the recovery disc.
Workaround:
Rebuild the server if the file system becomes corrupt.
 

 A Cisco recomenda que seja feito a REINSTALAÇÂO do CUCM mesmo após a utilização do RECOVERY DISC.

REFERÊNCIAS

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCth53322

Necessário Login (CCO válido para acesso à ferramenta de Bugs da Cisco)

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/drs/7_1_2/drsag712.html#wp72254

O interessante é que se o sistema não denunciar durante a utilização do RECOVERY DISC, como  saber se ainda  há arquivos corrompidos na base? A verdade é que você irá descobrir… No caso que vivenciei, o diretório de CDR corrompeu e simplesmente deixou de existir. Após a abertura de um TAC, o engenheiro da Cisco necessitou refazer o diretório via ‘root’ para que os bilhetes voltassem a ser gerados. Tudo isso aconteceu após uma queda de energia no site e posterior uso do RECOVERY DISC para restabelecer o CUCM.

Espero que não aconteça com voces porém é bom saber que isso já aconteceu e está documentado.

Um forte abraços a todos e até o próximo post.

Elvis Marques

Posted in Bugs, Callmanager | 1 Comment »

 
%d blogueiros gostam disto: