Problemas conhecidos

uim203
Os problemas conhecidos a seguir se aplicam ao UIM:
2
O aplicativo está sujeito a uma vulnerabilidade na comunicação que não é segura
Sintoma:
Os dados confidenciais da autenticação específicos do usuário são transmitidos em texto não criptografado, que pode ser rastreado por um atacante para comprometer a identidade dos usuários e obter acesso não autorizado ao aplicativo.
Solução:
Use o SSL em qualquer conexão autenticada ou sempre que dados confidenciais forem transmitidos.Use o SSL para todas as conexões que forem autenticadas ou que transmitem dados confidenciais ou de valor, como credenciais, detalhes de cartão de crédito, saúde e outras informações privadas.Certifique-se de que as comunicações entre os elementos da infraestrutura, tais como entre os servidores web e sistemas de banco de dados, estejam adequadamente protegidas por meio do uso do TLS (Transport Layer Security) ou da criptografia em nível de protocolo para dados intrínsecos e de credenciais.
A instalação do CABI falha ao usar caracteres especiais no Console do operador e nos nomes de conta LDAP
Quando você usa caracteres especiais (\, |, [ ], `, ", ', ~, !, #, $, %, ^, &, [,], *, +, =, ;, * :, ?, <, >, }, {, ), (, ], [, /, @) no OC ou em nomes de conta LDAP, a sincronização da conta com o CABI falha, o que resulta em uma falha na instalação.
Não é possível coletar métricas de QoS não padrão ao usar modelos avançados
Sintoma:
Ao usar os modelos avançados, o arquivo de configuração do probe não é atualizado com as informações de métrica de QoS.
Solução:
A coleta de QoS para métricas padrão funciona conforme o esperado para modelos herdados. No entanto, para modelos avançados, o arquivo de configuração do probe não é atualizado porque não há mapeamento no modelo para a coleta de QoS não padrão.
A configuração do probe CDM pode afetar o desempenho do discovery_server quando dispositivos monitorados estão usando um sistema de arquivos compartilhados
Sintoma:
Por padrão, a configuração do probe CDM tem a opção Configuração/allow_remote_disk_info definida como Sim. Isso permite que o probe CDM gere a ID do dispositivo para todas as unidades compartilhadas de um dispositivo monitorado que usarem um sistema de arquivos compartilhado. Nessa situação, o cdm cria perspectivas duplicadas para o mesmo sistema de arquivos compartilhado. Isso pode afetar o desempenho do discovery_server.
Solução:
Para corrigir esse problema, use a configuração de dados brutos para alterar o cdm setup/allow_remote_disk_info definido como Não. Revise o banco de dados do UIM e remova as perspectivas duplicadas. Isso deve retornar o desempenho do discovery_server para um nível de operação normal.
Implantar probes no modo de pilha dual (IPv4 e IPv6) não é suportado
Sintoma:
Quando você executar o utilitário Nimsoft Loader (nimldr) e configurar o hub principal usando o endereço IPv6 e estiver executando o modo de pilha dual, ocorrerá uma destas situações:
  • Quando um endereço IPv4 for fornecido para o Hub principal, a instalação falhará.
  • Quando um endereço IPv6 for fornecido para o Hub principal, o Robô será instalado. No entanto, não será possível implantar nem configurar qualquer probe no Robô.
Solução:
O modo de pilha dual não funciona porque o hub principal do ambiente UIM está no formato IPv6 de pilha dual e o endereço IP usado no arquivo robot.cfg está no formato IPv4 de pilha dual.
A permissão de Criação de painel requer privilégios de usuário de barramento
Em Admin da conta, será possível adicionar a permissão Criação de painel a uma ACL para um usuário de contato da conta, caso o usuário deseje criar painéis personalizados. No entanto, a permissão só funciona para um usuário de barramento. A permissão Criação de painel que é aplicada a um usuário de contato da conta é ignorada.
Problema de localização no modelo de configuração do monitor do Exchange
No CA UIM 9.0.2, o nome do perfil padrão não está localizado no modelo MCS de configuração do monitor do Exchange.
Nome compatível com caracteres especiais falha ao implantar o esquema
Sintoma:
Quando você implanta um esquema que tem caracteres que não são válidos nos nomes de arquivo, o esquema falha na implantação com o seguinte erro: Error occurred while creating/deploying schema probe package, Failed to deploy the probe package for the schema, <friendly_name> ScaleIO97db5264cdf49dbadf1de5928b0d9c98 :: <friendly_name>_schema.json."
Solução:
Defina os nomes compatíveis com os caracteres que são válidos em nomes de arquivo.
Esquema Isilon falha ao fazer upload
Sintoma:
O upload do esquema Isilon falha com este erro: "There was a problem while importing. Please contact administrator." Pressione OK para continuar.
Solução:
Normalmente, esse erro ocorrerá se o tamanho do esquema tiver mais de 1 MB. É possível fazer upload do esquema Isilon com 1 MB como o tamanho máximo do arquivo.
Grupos de interfaces sem suporte ao aplicativo móvel
No momento, o aplicativo não oferece suporte a grupos de interfaces com dispositivos Android ou iOS.
Falha na instalação no RHEL 7.4
Sintoma:
A instalação do UIM falha em máquinas RHEL 7.4.
Solução:
Se você estiver usando o RHEL 7.4, certifique-se de que o arquivo de fontes local.conf esteja configurado ou que o pacote dejavu-serif-fonts esteja instalado. Para obter mais informações, consulte a documentação do RHEL.
Opção 1
: o arquivo de fontes local.conf está configurado.Crie o arquivo /etc/fonts/local.conf com o seguinte conteúdo:
<?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <alias> <family>serif</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>sans-serif</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>monospace</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>dialog</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>dialoginput</family> <prefer><family>Utopia</family></prefer> </alias> </fontconfig>
Opção 2
: execute o comando de instalação yum para instalar o pacote dejavu-serif-fonts.
yum install dejavu-serif-fonts
Probes com base em Java podem não ser iniciados na implantação do robô secundário
CA Unified Infrastructure Manager v8.51 e posterior instalados com o Java 8. Ao atualizar para o CA UIM v8.51 ou posterior, se os probes com base em Java que foram implantados anteriormente em um robô usassem uma versão mais antiga do Java (por exemplo, o Java 7), eles não eram iniciados. Para solucionar isso, reimplante a versão 1.7 do java_jre no robô e, em seguida, reinicie o robô.
Requisito de variável de ambiente do Java SDK
Se você usar o Java SDK para enviar mensagens para o UIM, defina a seguinte variável de ambiente para designar o endereço IP de loopback para entrar em contato com o robô local. Por exemplo:
NIM_ROBOT_IP=127.0.0.1
Falha na validação do esquema JSON
Sintoma: subsistemas
Ao fazer upload do esquema JSON, a validação falha, resultando no seguinte erro:
[<nome_do_esquema>.json] não apresenta sintaxe de definições de métrica do UIM.
Solução:
Esse erro normalmente ocorre quando a seção de definição de
métricas
do UIM não está presente no arquivo JSON ou contém valores incorretos nos atributos
operator
e
severity
.
Para resolver o erro, edite o arquivo de esquema e execute uma das ações:
  • Na seção
    metrics
    do esquema, defina apenas um valor para os seguintes atributos:
    operator
    e
    severity
    . Esses atributos não oferecem suporte a uma matriz de valores.
    OR
  • Remova os seguintes atributos da seção
    metrics
    no esquema:
    thresholdenabled
    ;
    operator
    ;
    severity
    ;
    custom_message
    ;
    custom_clear_message
Copiar manualmente os certificados de segurança no CABI externo (robô secundário)
Antes de implantar a versão do CABI externo e ativar o TLS v1.2, é necessário copiar manualmente os certificados de segurança do robô principal para o robô secundário.
Quando você estiver usando o Microsoft SQL Server como o banco de dados, será preciso copiar manualmente os arquivos do repositório de confiança (jks) do robô principal para o robô secundário. Os arquivos são colocados na pasta <Nimsoft>\security.
Quando você estiver usando o Oracle como o banco de dados, será preciso copiar manualmente os arquivos de carteira (SSO/PKCS12) do robô principal para o robô secundário. Os arquivos são colocados na pasta <Nimsoft>\security.
Os perfis de configuração do MCS não podem ser aplicados a todos os integrantes de grupos dinâmicos grandes
Por padrão, os grupos dinâmicos são atualizados a cada 5 minutos. Em ambientes grandes do CA UIM, os grupos dinâmicos podem ter mil integrantes ou mais. É pouco provável que o Serviço de configuração de monitoramento seja capaz de implantar ou atualizar os perfis de configuração de todos os integrantes de um grupo dinâmico grande dentro do intervalo de 5 minutos. Para resolver o problema, é possível aumentar o intervalo configurado. O intervalo é configurado com group_maintenance_interval no nis_server. Para obter detalhes sobre como modificar o group_maintenance_interval no nis_server, consulte a seção
Configurar o intervalo entre atualizações para grupos automáticos
no artigo Criar e gerenciar grupos.
As substituições dos perfis de configuração MySQL, Oracle ou SQL Server do MCS no nível do dispositivo não podem ser marcadas com um asterisco
Com o Serviço de configuração de monitoramento, você pode criar perfis de configuração MySQL, Oracle ou SQL Server no nível do grupo. Assim que o MCS aplicar o perfil de configuração do grupo a todos os integrantes de um grupo, você poderá fazer substituições no nível do dispositivo. O MCS marca com um asterisco cada campo que contém uma substituição no nível do dispositivo no perfil de configuração do dispositivo. Sob as seguintes condições, você não poderá ver um asterisco em alguns dos campos de
alarme
no nível de dispositivo que tenham substituições:
  • O perfil no nível do grupo para um ponto de verificação foi definido para publicar
    Nenhum
    ou
    QoS
    e
  • A substituição no nível do dispositivo do mesmo ponto de verificação foi definida como
    Alarme
    ou
    QoS e alarmes
mon_config_service não é ativado após a reinicialização
Sintoma:
Quando reinicio o probe mon_config_service no Console de administração/IM, o probe permanece desativado.
Solução:
Se o probe mon_config_service permanecer desativado após a reinicialização, vá para o Console de administração/IM e selecione > Ativar.
A rotação do arquivo mon_config_service.log não está funcionando corretamente
Log4j e NimLog atualmente estão gravando no arquivo mon_config_service.log e isso impede que as entradas do arquivo de log sejam roladas corretamente. Para corrigir esse problema, é necessário modificar o arquivo log4j.properties e adicionar um tamanho de arquivo apropriado ao arquivo mon_config_service.log. A solução alternativa para corrigir esse problema é:
  1. Na Área de Trabalho Remota, abra o arquivo log4j.properties em <uim>\Nimsoft\probes\service\mon_config_service em um editor de texto.
  2. Remova FILE da instrução 'log4j.rootCategory=ERROR, FILE, CONSOLE' da primeira linha do arquivo.
    A instrução torna-se 'log4j.rootCategory=ERROR, CONSOLE'.
  3. Salve o arquivo.
  4. Especifique o tamanho apropriado para o arquivo mon_config_service.log. O tamanho de arquivo padrão é 1024 KB.
    1. Acesse o Console de administração.
    2. Selecione o hub na guia
      Robôs
      e, em seguida, selecione a guia de
      Probes
      .
    3. Selecione o botão de menu embutido do arquivo mon_config_service.log e selecione
      Configuração de dados brutos
      .
    4. Selecione a seção
      Configuração
      .
    5. Selecione
      +
      no canto superior direito para criar uma chave.
    6. Digite o
      tamanho do log
      no campo Chave.
    7. No campo Valor, digite um tamanho de arquivo apropriado, em kilobytes, para o arquivo mon_config_service.log.
    8. Selecione
      Criar
      para adicionar o valor da chave de tamanho do log.
    9. Clique em Atualizar para salvar as alterações.
Nomes de campo do tipo de perfil do Serviço de configuração de monitoramento
Embora os tipos de perfis do MCS e as GUIs de configuração do probe associado (tanto no Console de administração quanto no Gerenciador de infraestrutura) para um determinado probe tenham as mesmas opções de configuração, os nomes de campo individuais nem sempre correspondem entre eles.Para obter mais informações sobre os campos disponíveis para cada GUI do probe, consulte a documentação de cada probe no site Probes.
Os monitores não estão sendo excluídos, nem mesmo após a remoção do último modelo filho (substituição) para um dispositivo
Sintoma:
Crie um grupo e adicione um dispositivo a esse grupo. Além disso, certifique-se de que nenhum outro modelo de substituição esteja definido para o dispositivo. Em seguida, substitua um modelo no grupo e certifique-se de que o modelo de substituição se aplique (os monitores são publicados). Agora, exclua o modelo de substituição. Até mesmo depois de excluir o modelo de substituição, os monitores criados a partir do modelo para o dispositivo não são excluídos.
Solução:
Quando todos os perfis de modelo filho associados a um dispositivo forem removidos, a entrada do dispositivo será excluída do arquivo de configuração do probe. O probe realiza processamentos para todos os dispositivos encontrados no arquivo de configuração. Portanto, qualquer dispositivo encontrado agora e anteriormente ausente no arquivo não será processado. Ou seja, os monitores criados anteriormente não serão ignorados.
Na implementação atual, não há uma maneira disponível para gerenciar os dispositivos removidos do arquivo de configuração. Como solução alternativa, reinicie o probe sempre que esse cenário ocorrer.
Conflitos de resolução de nome em sistemas Debian com o probe automated_deployment_engine
Por padrão, o Debian v6 usa o endereço 127.0.1.1 como o endereço de resolução de nomes. Quando um robô for implantado em um sistema Debian 7 ou 8 usando automated_deployment_engine, após a reinicialização do sistema, o robô tentará vincular-se à 127.0.1.1 como o endereço disponível. Use a seguinte solução alternativa para evitar a contenção de 127.0.1.1 no sistema Debian:
  • Ao instalar o robô manualmente ou com o automated_deployment_engine, é preciso ir até o sistema de destino após a instalação e adicionar a linha a seguir ao arquivo robot.cfg:
robotip = ip_address
sendo que
ip_address
é o endereço IP a que o robô deve se vincular no sistema de destino.
  • Ao implantar no Debian 6.0.5 usando XML, é necessário definir a opção
    <robotip>ip_address</robotip>
    , sendo que
    ip_address
    é o endereço IP ao qual o robô deve se vincular no sistema de destino.
O Oracle Instant Client 12.2 não está funcionando
Sintoma:
O CA UIM 9.0.2 não funciona com o Oracle Instant Client 12.2.
Solução:
Como solução alternativa, use o Oracle Instant Client 12.1.
A administração do probe retorna um erro desconhecido em um ambiente de agrupamento do Windows
Quando você tentar configurar um probe, a administração do probe poderá retornar uma mensagem de
erro desconhecido
em um ambiente de agrupamento do Windows. Esse problema ocorreu especificamente com o probe ems, mas pode ocorrer com outros probes. Para corrigir esse problema, siga estas etapas:
  1. Efetue logon no Gerenciador de infraestrutura como administrador.
  2. Na guia Segurança, selecione
    Administração do probe
    .
  3. Selecione
    Novo Probe
    para adicionar uma entrada para o probe ems.
    1. Selecione ems na lista suspensa
      Probe
      .
    2. Selecione Admin na lista suspensa
      Acessar
      .
    3. Digite um asterisco (*) no campo
      Máscara IP
      e selecione
      OK
      para salvar as alterações.
A função de reconciliação de perfil foi removida do Serviço de configuração de monitoramento
A função de reconciliação foi movida do probe mon_config_service para as novas Ferramentas de utilitários do MCS. A ferramenta Utilitários do MCS proporciona mais flexibilidade para programar a reconciliação, oferece relatórios mais detalhados das diferenças detectadas e melhora o desempenho do probe mon_config_service. Para corrigir as diferenças nos perfis de configuração que são gerenciados pelo Serviço de configuração de monitoramento, use a Ferramenta Utilitários do MCS.
Os probes param de funcionar depois da renomeação e reinicialização do robô
Sintoma:
Os probes não funcionam depois que o nome do robô é alterado e reiniciado.
Solução:
Você deve validar os probes depois de mudar o nome do robô. A validação pode ser feita na interface do Gerenciador de infraestrutura.
Falha na instalação do robô no UNIX
Sintoma:
A instalação do robô UNIX falha ou o robô falha ao iniciar logo após a instalação.
Solução:
As instalações de robô a partir do OC funcionam como esperado. No entanto, isso ocorre com a instalação silenciosa usando o utilitário Nimsoft Loader (nimldr). Se você visualizar a mensagem de erro a seguir, tente fazer a instalação uma segunda vez.
./niminit stop Failed to stop nimbus.service: Unit nimbus.service not loaded.
./niminit start Failed to start nimbus.service: Unit nimbus.service failed to load: No such file or directory.
Se um robô falhar ao iniciar, interrompa-o e reinicie-o.
A sublocação não é suportada pelos relatórios de disponibilidade do CABI
Sintoma:
Os relatórios de disponibilidade do CABI não oferecem suporte ao recurso de sublocação. Os dados de todas as origens ficariam visíveis ao usuário nos relatórios de disponibilidade do CABI.
Solução:
Não há solução alternativa disponível para esse problema.
A ação do comando AO (Auto Operator) do nas não é executada quando há um espaço no caminho (casos de suporte 246133 e 315782)
Uma ação de comando não pode ser analisada quando o caminho contém espaços. Não use espaços no caminho do comando AO.
Não é possível migrar os perfis existentes para os perfis aprimorados após a atualização do UIM 8.5.1 para o UIM 9.0.2.
Sintoma:
Após a atualização para do UIM 8.5.1 para o UIM 9.0.2, não vejo os perfis aprimorados no Console do operador para meus perfis existentes, mesmo depois de implantar o pacote do MCS para perfis aprimorados.
Solução:
É necessário atualizar para o pacote de modelos do MCS (não aprimorados) mais recente antes de tentar migrar os perfis existentes para perfis aprimorados.Para obter instruções detalhadas, consulte
Migrando e convertendo perfis existentes
na página Configurando limites de alarme no MCS.
Não é possível alterar a opção Need Client Authentication na UI do data_engine
Sintoma:
Esse problema ocorre quando o TLS v1.2 está ativado para o Oracle (banco de dados do UIM) e você tenta alterar a opção
Need Client Authentication
. Na interface do IM do data_engine, ao tentar alterar a opção
Need Client Authentication
, o valor apropriado para essa opção não é definido no arquivo sqlnet.ora. O arquivo sqlnet.ora está disponível na pasta
<
Nimsoft>\security
, no computador do UIM Server.
Solução:
Como solução alternativa, você deve atualizar manualmente o valor do parâmetro SSL_CLIENT_AUTHENTICATION. Para isso, siga estas etapas:
  1. No computador do UIM Server, vá para a pasta
    <
    Nimsoft>\security
    .
  2. Localize e abra o arquivo sqlnet.ora.
  3. Atualize o parâmetro
    SSL_CLIENT_AUTHENTICATION
    no arquivo sqlnet.ora considerando se a opção Need Client Authentication está selecionada ou não (na interface do IM do data_engine).
    Por exemplo, se a opção estiver selecionada na interface do IM, o parâmetro deverá ser definido da seguinte maneira:
    SSL_CLIENT_AUTHENTICATION = TRUE
    Se a opção não estiver selecionada, o parâmetro deverá ser definido da seguinte maneira:
    SSL_CLIENT_AUTHENTICATION = FALSE
  4. Reinicie o probe data_engine.
Não é possível desinstalar o robô secundário em um ambiente IPv6
Sintoma:
Em um ambiente IPv6 puro, se você tentar remover o robô secundário do hub, o botão
OK
será desativado após a inclusão do endereço IP do robô secundário.
Solução:
Primeiro, desvincule o robô do hub e, em seguida, desinstale-o para a remoção bem-sucedida do robô secundário.
Não é possível criar um perfil cdm não aprimorado (herdado)
Sintoma:
Quando tento criar o perfil cdm não aprimorado (perfil herdado), não consigo.
Solução:
O modelo de cdm não aprimorado (herdado) exige que o cdm 6.30-MC seja apresentado no Arquivo local. Por padrão, o cdm 6.30-MC não está presente no Arquivo local. Portanto, se desejar criar um perfil de modelo herdado do cdm, certifique-se de que o cdm 6.30-MC esteja disponível no Arquivo local.
Não é possível abrir a configuração do probe usando o Console de administração
Sintoma:
A janela Configuração não abre quando você seleciona a opção Configuração para qualquer probe no Console de administração.
Solução:
Esse problema ocorre quando os pop-ups são bloqueados em seu navegador. Certifique-se de que os pop-ups não estejam bloqueados para o Console de administração e selecione a opção Configuração.
Atualizar os certificados autoassinados
A versão do Java foi atualizada para o Java 8. É necessário atualizar todos os certificados autoassinados gerados por versões anteriores do CA UIM. Se você não atualizar os certificados existentes, as conexões HTTPS com o servidor do CABI não funcionarão devido a uma alteração nos níveis de criptografia de segurança no Java 1.8. Para obter mais informações, consulte Configurar HTTPS no Console de administração ou no Console do operador.
Usar variáveis para um nome de perfil é suportado (caso do Salesforce 418533)
O Serviço de configuração de monitoramento agora permite que os usuários insiram variáveis (por exemplo, {device.ip} ou {device.name}) em um nome de perfil.
(Para 9.0.2 ou posterior) Localizando e corrigindo diferenças de perfil usando mon_config_service_cli
O seguinte processo para localizar e corrigir as diferenças de perfil não se aplicará:
  1. Emita o comando Find-Profile-Diffs para encontrar os robôs com diferenças no perfil de configuração.
  2. Emita o comando Fix-Profile-Diffs para corrigir as diferenças de perfil.
  3. Emita novamente o comando Find-Profile-Diffs com um arquivo que liste os robôs que tinham diferenças de perfil para verificar se elas não existem mais.
O wasp não extrai os aplicativos web
Sintoma:
O wasp não extrai os aplicativos web e as entradas como as que seguem são encontradas no wasp.log:
Feb 24 17:18:41:028 INFO [Catalina-utility-1, org.apache.catalina.core.ContainerBase.[wasp-engine].[localhost].[/]] No Spring WebApplicationInitializer types detected on classpath Feb 24 17:18:44:050 ERROR [Catalina-utility-1, org.apache.catalina.core.ContainerBase] startInternal() A child container failed during start Feb 24 17:18:44:051 ERROR [Catalina-utility-1, org.apache.catalina.core.ContainerBase] java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [[email protected]] at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
Solução:
  1. Abra o registro
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NimbusWatcherService
    . Na chave "ImagePath", altere o valor para caminho (mesmo caso) como ele aparece no Windows Explorer. (por exemplo: "C:\Arquivos de Programas\Nimsoft\bin\nimbus.exe").
  2. Reinicie o serviço do Nimsoft Robot Watcher.
A atualização da origem no probe do hub e na origem de substituição definida pelo hub na funcionalidade do probe do controlador não está funcionando corretamente
Quando a origem for atualizada no hub ou no controlador, o nome da origem não será atualizado nos alarmes até que os alarmes sejam apagados manualmente ou que o robô seja reiniciado manualmente.
No NAS, a chave é criada incluindo a origem, que é então comparada com a chave existente para atualizar o banco de dados no qual novos campos de entrada ou campos obrigatórios são atualizados. Se a origem for atualizada, para cada alarme de entrada suprimido, outra entrada será criada a fim de evitar problemas na limpeza do alarme.
As opções Editar e Excluir não funcionam corretamente no menu do Programador de relatórios
Sintoma:
quando tento programar relatórios do CABI na UI do OC, as opções Editar e Excluir não funcionam corretamente no menu Programar.
Solução:
a solução alternativa é usar as Programações dentro do CABI com o arquivo overrides_custom.css aplicado, conforme descrito no Artigo da base de conhecimento.
[UIM 20.3.0] As colunas da exibição do dispositivo estão ausentes nas exibições Grupo e Inventário do Console do operador
No novo Console do operador, as colunas da exibição de dispositivos estão ausentes nas exibições Grupo e Inventário que estão presentes no UMP 20.1.
Colunas do dispositivo de grupo: Alias, Legenda, Descrição, Tipo de SO, Versão do SO, Descrição do SO, Origem, Endereço MAC, Marcador de usuário 1, Marcador de usuário 2, Removido, Tipo de barramento.
Colunas do dispositivo de inventário: Alias, Alterado, Origem, Credenciais de detecção.
[UIM 20.3.0] O grupo de interfaces não está redirecionando para o nível do dispositivo na exibição Grupo do Console do operador
O grupo de interfaces não está redirecionando para o nível do dispositivo na exibição Grupo do Console do operador. Ele está redirecionando para a exibição de lista do grupo quando clicamos na exibição do grupo de interfaces.
[UIM 20.3.0] A caixa de seleção Selecionar tudo na tabela Alarmes não está funcionando corretamente
Sintoma:
a caixa de seleção Selecionar tudo na tabela Alarmes não está funcionando corretamente no Console do operador. Os alarmes não estão sendo eliminados por limpeza e somente os alarmes que ficam visíveis na página são eliminados usando a opção Selecionar tudo. Além disso, quando os alarmes são eliminados, se você selecionar os alarmes existentes novamente e a caixa de seleção Selecionar tudo, nenhum alarme é selecionado.
Solução
: para que o recurso Selecionar tudo funcione corretamente, você deve ir para outra página e voltar para a página de alarme.
[UIM 20.3.0] Os PDFs gerados para os painéis não estão mostrando os gráficos
No Console do operador, os PDFs gerados para os painéis não estão mostrando os gráficos. Esse problema ocorre nos painéis existentes.
[UIM 20.3.0] Opções do MCS: "Include Device Not in Group" e "Include Device Without Probe" não estão funcionando conforme esperado
As opções "Include Device Not in Group" e "Include Device Without Probe" não estão retornando todos os dispositivos disponíveis com essas condições. Nas configurações de perfil de grupo do MCS, quando essas configurações são selecionadas, os dispositivos de referência que não estão no grupo e os dispositivos sem os probes não são mostrados.
[UIM 20.3.0] A ID da diretiva é exibida no lugar do nome da diretiva na exibição de alarmes do Console do operador
Após a criação de uma diretiva de alarme na exibição de alarmes do Console do operador, a ID da diretiva é exibida no lugar do nome da diretiva.
Esse problema foi corrigido como parte da release do patch OC 20.3.2.
[UIM 20.3.0] A programação de manutenção para o enésimo dia do mês não está funcionando quando o fuso horário do usuário ou o fuso horário da programação de destino e o fuso horário do servidor são diferentes
No UIM 20.3.0, a programação de manutenção para o enésimo dia do mês não está funcionando, a programação não inicia na data e hora programadas e permanece inativa. Isso ocorre quando o fuso horário do usuário ou o fuso horário da programação de destino e o fuso horário do servidor são diferentes. Se a data programada e a data do servidor forem diferentes devido à diferença de fuso horário, a programação de manutenção não iniciará na data e hora programadas.
Esse problema foi corrigido como parte da release UIM 20.3.3.
[UIM 20.3.0] O wasp não está mudando para o estado online ao atualizar do UMP que tem autocertificação implantada
No UIM 20.3.0, ao atualizar do UMP para o OC, o wasp não mudará para o estado online se o UMP existente tiver a autocertificação implantada.
Esse problema será aplicável apenas se você estiver atualizando de uma versão anterior para o UIM 20.3.0.
[UIM 20.3.0] Na página de alarmes, para os alarmes que são criados como resultado de uma diretiva de alarme, o link para a diretiva não é ativado quando se trata de diretivas de alarme recém-criadas
Quando os alarmes são criados como consequência de uma diretiva de alarme na página de alarmes do Console do operador, o link para a diretiva de alarme não é ativada quando se trata de diretivas de alarme recém-criadas. Após a reinicialização do wasp, as diretivas são ativadas com os links. Os novos alarmes criados como resultado das novas diretivas de alarme após a reinicialização terão o mesmo problema.
Esse problema foi corrigido como parte da release do patch OC 20.3.2.
[UIM 20.3.0]  Nenhuma métrica de QOS para o perfil Serviços do servidor do AD no modelo Ad_server do MCS
No UIM 20.3.0, não há métricas de QOS para o perfil Serviços do servidor do AD nos modelos Ad_server do MCS.
[UIM 20.3.0] Alterar senha para usuários da conta que são adicionados manualmente na Admin da conta não está disponível
No UIM 20.3.0, para os novos usuários que são adicionados manualmente em Admin da conta, a opção de alteração da senha não está disponível. Os usuários não podem alterar a senha usando o Console do operador.
Esse problema foi corrigido na release UIM 20.3.3.
[UIM 20.3.0] Os filtros de pesquisa de diretiva de alarme não fornecem resultados precisos
No UIM 20.3.0, os resultados dos filtros de pesquisa de diretiva de alarme fornecem resultados imprecisos. Os resultados da pesquisa são mostrados para a sequência de caracteres de pesquisa parcial quando há mais de duas letras na pesquisa. Os resultados da pesquisa também demoram para fornecer as diretivas de alarme nos resultados.
[UIM 20.3.0] O Console do operador não tem tempo limite
No UIM 20.3.0, o Console do operador não tem tempo limite e a sessão permanece ativa, mesmo depois de ficar ciosa por 72 horas.
Esse problema foi corrigido como parte da release do patch OC 20.3.2.
Outros problemas conhecidos
  • Para ver os novos problemas conhecidos da release UIM 20.3.1, consulte a seção Problemas conhecidos no artigo UIM 20.3.1.
  • Para ver os novos problemas conhecidos na release OC 20.3.2, consulte a seção Problemas conhecidos do artigo Patch do OC 20.3.2.
  • Para ver os novos problemas conhecidos da release UIM 20.3.3, consulte a seção Problemas conhecidos no artigo UIM 20.3.3.