Notas sobre a liberação

O plug-in de integração do TADDM ServiceNow foi ampliado para oferecer suporte à versão de Washington do ServiceNow. Para obter mais detalhes sobre como integrar o TADDM com ServiceNow,, consulte Integração do TADDM com ServiceNow.

A biblioteca SSH Mindterm usada no TADDM foi substituída pela biblioteca Apache Mina SSHD, pois o Mindterm foi EOL de janeiro de 2022. Apache Mina SSHD é uma biblioteca Java 100% pura para suportar os protocolos SSH. Essa mudança é abstrata para o usuário final e não requer novas configurações no final.

O TADDM Fixpack 11 suportará autenticação baseada em chave ED25519 . Anteriormente, o login baseado em chave era suportado apenas para as chaves RSA ou DSA

Autenticação baseada em chave, também conhecida como autenticação de chave pública, é um método usado para autenticar usuários com segurança em um sistema, servidor ou aplicativo sem a necessidade de senhas tradicionais. Ele depende de pares de chaves criptográficas em vez de senhas para estabelecer identidade e conceder acesso. Consulte o link, Configurando para Descoberta usando o Shell Seguro (SSH)

O TADDM Fixpack 11 suportará a Future Crypto Policy usando as chaves RSA ativadas no RHEL8 e versões superiores para descoberta e utilização da biblioteca Apache Mina SSHD

O TADDM Fixpack 11 suportará o DB2 JDBC driver V 4.25.29.

Se a propriedade for configurada como true em seguida, o driver DB2 JDBC será atualizado para a versão 4.25.29.

Se a propriedade for configurada como false, a versão do driver DB2 JDBC permanecerá igual (como a versão anterior) após a migração bem-sucedida.

O plug-in de Integração do TADDM ServiceNow foi estendido para suportar a liberação Utah do ServiceNow. Para obter mais detalhes sobre como integrar o TADDM com ServiceNow,, consulte Integração do TADDM com ServiceNow.

O TADDM removeu a dependência em 32-bit libgcc necessária para estar presente nos sistemas operacionais RHEL a serem utilizados para instalação do TADDM.

Os usuários podem agora instalar e usar o TADDM Fixpack-10 no sistema operacional RHEL-9 sem a biblioteca libgcc de 32-bit bits.

Também a biblioteca libXft.so.2 também não é necessária nos sistemas operacionais RHEL-9 para serem usados como servidor de instalação TADDM.

Para o Log4j, um aprimoramento foi introduzido para fazer upgrade dele de Log4j1 para Log4j 2.17.2 , pois ele fornece melhorias de segurança significativas.

Log4j2 permite que as expressões de Lookup nos dados que estão sendo registradas exponham a vulnerabilidade da JNDI, bem como outros problemas, sejam explorados por usuários finais cuja entrada está sendo registrada.

Quando o TADDM é atualizado para 7.3.0.10, um arquivo de backup, deploy-tomcat_7.3.0.x é deixado sobre o qual contém algumas referências não usadas para o arquivo JAR log4j versão 1. Para remover referências não utilizadas ao site log4j versão 1, consulte https://www.ibm.com/support/pages/node/6986553.

O módulo CheckDiskFailures agora foi adicionado com uma opção de filtro para ignorar os dados com base na duração, o que ajuda a ignorar os dados de um determinado ano, data e intervalo de data e ano.

Para obter mais detalhes sobre o módulo CheckDiskFailures, consulte o tópico Programa Healthcheck no Guia de Solução de Problemas.

O plug-in de integração do TADDM ServiceNow foi estendido para suportar a versão de San Diego do ServiceNow Para obter mais detalhes sobre como integrar o TADDM com ServiceNow,, consulte Integração do TADDM com ServiceNow.

• Ao se extrair o arquivo fixpack .zip no sistema baseado em RHEL, usando o comando unzip nativo pode dar o seguinte erro:

  invalid zip file with overlapped components (possible zip bomb)

  Se ocorrer o erro acima, extraia o arquivo .zip usando uma das seguintes formas:

  • Rerun o comando unzip nativo após configurar a variável de ambiente UNZIP_DISABLE_ZIPBOMB_DETECTION=TRUE
  • Se a opção acima não for suportada no unzipnativo, então use o executável jar presente no diretório de instalação do TADDM.

    <taddm_installation_directory>/dist/external/jdk-Linux-x86_64/bin/jar xf fixpack.zip

• O Windows Discovery Server e o Windows Anchor requerem que PowerShell 5.1 ou posterior esteja presente neles.

Para o Oracle Sensor descobrir o banco de dados Oracle você deve adicionar o nome do arquivo do driver JDBC compatível para oBundle-ClassPathentrada no arquivo MANIFEST.MF . Para obter mais detalhes, consulte Copiar o driver JDBC.

Em fix-packs anteriores do TADDM, o sensor Oracle usa apenas o primeiro driver JDBC , listado noBundle-ClassPathentrada, para a descoberta do banco de dados Oracle mas ele não estava usando outros drivers JDBC listados para a descoberta do banco de dados Oracle .

O TADDM 7.3.0.9 aprimora os recursos de procura do sensor Oracle e agora ele usa todos os drivers JDBC , listados noBundle-ClassPathentrada, para a descoberta do banco de dados Oracle . Se o primeiro driver JDBC , listado noBundle-ClassPathentrada, não faz uma conexão com o banco de dados Oracle , em seguida, procurar será feito usando outros drivers JDBC listados automaticamente e o banco de dados Oracle será descoberto se for compatível com qualquer driver JDBC listado noBundle-ClassPathentrada no arquivo MANIFEST.MF .

Para obter mais detalhes sobre as propriedades de agrupamento, consulte Configuração das entradas do arquivo collation.properties.

O plugin de Integração ServiceNow do TADDM foi estendido para suportar a Versão de Quebec do ServiceNow. Para obter mais detalhes sobre como integrar o TADDM com ServiceNow,, consulte Integração do TADDM com ServiceNow.

Mapeando as informações do cluster RedHat Pacemaker para o ServiceNow

O plug-in de integração ServiceNow do TADDM foi aprimorado e configurado para mapear os objetos do cluster Pacemaker com o ServiceNow.

Para obter mais detalhes sobre a lista de CIs compatíveis, consulte o Apêndice D: Lista de CIs compatíveis.

Para o Microsoft IISServerSensor, um aprimoramento foi introduzido para descobrir os detalhes do Conjunto de aplicativos dos servidores da web do Microsoft IIS.

Os conjuntos de aplicativos descobertos serão exibidos sob uma nova guia Conjunto de aplicativos na visualização do painel Detalhes do componente IIsWebService. Um relacionamento entre websites e o Conjunto de aplicativos também é mantido.

Para obter mais detalhes sobre o sensor do servidor Web Microsoft IIS e o painel Resumo do inventário, consulte Sensor do servidor Web Microsoft IIS e painel Resumo do inventário: Guia Inventário.

O TADDM 7.3.0.8 fornece a capacidade de definir a política de senha com regras de segurança de senha que são usadas para determinar se uma nova senha é válida.

Para obter mais detalhes sobre a política de senha, consulte Política de senha.

Um novo sensor "Sensor do Pacemaker Cluster" foi incluído para suportar a descoberta do RedHat Pacemaker Cluster (criado usando os pacotes High Availability-AddOn no RHEL) no Red Hat Enterprise Linux 7.8. O sensor descobre os nós do cluster, os recursos, os grupos de recursos, os clones de recursos, os recursos de vários estados, seus meta-atributos, os atributos de recursos e as propriedades do cluster no cluster. O relacionamento de nós do cluster com os sistemas de computadores Linux também é mantido.

Este sensor é um sensor baseado em script. Para obter mais detalhes, consulte Pacemaker Sensor do cluster.

A documentação sobre o sensor de modelo personalizado (CTS), o modelo de servidor personalizado (CST) e as extensões de servidor personalizado (CSX) foi aprimorada para proporcionar uma melhor compreensão desses tópicos.

Além disso, foi adicionado um tópico CTS vs CST vs CSX que demarca as diferenças (execução do sensor, uso, criação, limitações, etc.) entre os três métodos de customização no TADDM.

No DAP fase II, a janela do painel é introduzida. Nesta janela, é possível localizar um gráfico de pizza e um campo de procura. Usando esse gráfico, agora é possível visualizar todos os itens de configuração disponíveis em seu CMDB do TADDM. Os recursos interativos do gráfico permitem explorar os detalhes do CI facilmente.

Na liberação anterior, apenas dois componentes semelhantes (Tipo) eram comparados. Agora é possível comparar até cinco componentes. Mesmo na área de janela de resultado de comparação, em vez de dois componentes, agora é possível visualizar resultados de comparação de cinco componentes. O resultado da comparação pode ser transferido por download em três formatos diferentes. O formato XML foi recentemente incluído, juntamente com os formatos PDF e CSV existentes.

A fase II do DAP também oferece capacidade aprimorada para explorar os detalhes dos cinco itens de configuração. Na versão anterior, a análise de somente três CIs era possível.

Agora o plug-in do ServiceNow Integration estende o suporte para a versão Madri do ServiceNow.

No FP7, o plug-in do ServiceNow fornece suporte aprimorado para todas as versões do TLS. Antes dessa liberação, apenas o valor pré-configurado do TLS era suportado. Uma nova propriedade customizável, securityProtocol=TLSv1.2, foi introduzida no plugin.properties.

Além disso, um novo atributo, profundidade, é introduzido no arquivo mapping.xml. É possível customizar esse atributo de acordo com a profundidade desejada dos detalhes de dados que você busca. Essa customização por sua vez aumenta ou diminui o tempo de execução.

Para descoberta de balanceamento de carga, agora é possível interromper uma descoberta no nível do conjunto de escopos. Anteriormente, se você iniciasse uma interrupção de LBD, todos os conjuntos de escopos associados à descoberta seriam interrompidos.

Agora, mais flexibilidade foi introduzida no comando para que seja possível interromper no nível do conjunto usando o comando antigo ou no nível do conjunto de escopos usando o novo comando.

api.sh -u <user> -p <password> discoverloadbalanced abort --poolName <pool name> --scopeSet <scope set name>.

Anteriormente, o comando abort era restrito ao nome do conjunto, mas com essa mudança, a descoberta pode ser interrompida no nível do conjunto de escopos.

O DAP agora suporta a autenticação do usuário por meio de um servidor do diretório LDAP externo. Na versão anterior, apenas a autenticação do usuário baseada em arquivo era suportada. Após essa liberação, um usuário LDAP com a função apropriada (visualizador) pode acessar o DAP.

O TADDM 7.3 Fixpack 6 inclui o suporte de um Plug-in de integração, para migrar dados de descoberta do TADDM para o ServiceNow CMDB. Essa integração dos dados de descoberta do TADDM com o ServiceNow CMDB suporta a migração inicial em massa e quaisquer atualizações dinâmicas subsequentes do Item de configuração (IC) feitas utilizando o mecanismo de dados push. O plug-in pode ser executado no servidor de descoberta do TADDM ou em algum outro servidor e é gerenciado (iniciar, parar, status) como uma ferramenta separada por meio de sua interface de linha de comandos.

ICs suportados: o escopo do Plug-in de integração será limitado ao conjunto de itens de configuração básicos que incluem Rede, Cálculo e Armazenamento (ComputerSystem, IpAddress, IpInterface, L2Interface, AppServer, AppServerCluster, Database Server, Storage SubSystem, Storage Volume, FileSystem).

O Portal de acesso a dados do TADDM é a interface com o usuário baseada na web do IBM® Tivoli Application Dependency Discovery Manager (TADDM), usada para visualizar os dados em um banco de dados do TADDM. Essa interface com o usuário é aplicável a uma implementação do servidor de domínio, a uma implementação do servidor de sincronização e a cada servidor de armazenamento em uma implementação do servidor de fluxo.

O Portal de acesso a dados do TADDM fornece os serviços a seguir, que podem ser usados para executar análises:

Login- para acessar o Portal de acesso a dados do TADDM, o usuário pode efetuar login no Portal de acesso a dados do TADDM utilizando as credenciais de login do TADDM, tendo a função "dapuser" designada a eles.

Comparação- este recurso permite que o usuário compare atributos entre dois ICs que têm o mesmo tipo de componente. O usuário pode ver a diferença e as semelhanças entre os atributos de dois ICs.

Relacionamento- as associações de relacionamentos entre duas instâncias de recursos, mostrando como as instâncias de recursos estão relacionadas entre si. Para mostrar o relacionamento entre as classes de tipos iguais ou diferentes. Cada relacionamento possui uma definição ou um tipo.

Esses tipos de relacionamentos diferentes transportam uma determinada semântica, que diz respeito ao tipo de associação entre as instâncias de recursos.

Todos os bancos de dados Oracle anteriores ao Oracle Database 12c eram não CDBs. Ou seja, o Oracle 12C suporta a arquitetura não CDB e a arquitetura de diversos locatários com base na opção de configuração.

Pré-requisitos

Um usuário comum privilegiado deve ser usado para descobrir a arquitetura Oracle12c de diversos locatários.

Foram feitas muitas atualizações no “Sensor EMC ViPR SRM”, que é usado para descobrir recursos de armazenamento que estão relacionados à rede de área de armazenamento (SAN), obtendo os dados necessários do EMC ViPR SRM. Esse sensor descobre recursos de armazenamento, como matrizes de armazenamento (somente VMAX), hosts e comutadores (somente Brocade), ou seja, somente descobertas de malhas, zonas, conjuntos de zonas, volumes de armazenamento, comutadores, portas de comutador, hosts, HBAs etc.

O sensor de armazenamento de host utiliza o binário do mecanismo de coleção de 32 bits para descobrir os HBAs e os volumes FC que estão configurados no sistema host. Como resultado, há um pré-requisito de instalação da biblioteca glibc de 32 bits.

Esse aprimoramento foi feito para remover o pré-requisito de instalação da biblioteca glibc de 32 bits em destinos RHEL/AIX de 64 bits.

Foi fornecida uma opção de configuração (collectionEngineBuild_64_Bit) para utilizar o binário do mecanismo de coleção de 64 bits e ela é aplicável para plataformas RHEL/AIX.

InstallAnywhere é uma ferramenta de software baseada em Java para a criação de instaladores ou pacotes de software, para várias plataformas. Ele cria instalações confiáveis para plataformas locais – Windows, Linux, Apple, Solaris, AIX, HP-UX e IBM, etc.

O TADDM estava usando o InstallAnywhere 2012 para criar pacotes de compilação até o último fix pack 5. No entanto, no TADDM 7.3 Fixpack 6, os instaladores do TADDM agora foram construídos usando o InstallAnywhere 2017.

Embora, nada mude da perspectiva do usuário final.

O suporte para tags SLM (Métrica de licença de software) foi incluído no atual fix pack do TADDM para suportar o ILMT.

Agora, o uso de recurso do TADDM pode ser monitorado e capturado usando um script e baseia-se nas métricas abaixo:

As tags SLM são baseadas no rascunho padrão ISO/IEC 19770-4 para a Medida de utilização de recursos. As tags SLM fornecem um recurso padronizado para relatar o consumo das métricas de licença do produto (recursos relacionados ao uso de um ativo de software). Trata-se de um arquivo XML gerado por um produto no tempo de execução para relatar seu próprio uso sob licença. Um arquivo de tag SLM possui uma extensão de nome de arquivo .slmtag.

O IBM License Metric Tool (ILMT) é um produto que identifica quais ativos de software foram instalados e seu uso sob licença. O IBM License Metric Tool fornece uma maneira simples de rastrear o software IBM utilizado.

No TADDM 7.3.0.4, os usuários e grupos do console não eram exibidos. Como parte desse aprimoramento (RFE# 25909), o TADDM 7.3.0.5 agora pode mostrar usuários e grupos do console do WAS no Portal de Gerenciamento de Dados. Ele exibe informações relacionadas ao usuário, como nome, endereço de e-mail, grupo associado e funções designadas na guia “Usuário”. As informações relacionadas ao grupo, como nome, usuários associados e funções designadas, são exibidas na guia “Grupo”.

O WebSphereScriptSensor descobre três componentes - o WebSphere Server, o WebSphere Cell e o WebSphere Node. O WebSphere Cell é um domínio administrativo que permite atividades administrativas comuns em um ambiente distribuído do WebSphere Application Server.

Arquivos de configuração relacionados a usuários e grupos são armazenados no WebSphere Cell. Portanto, o TADDM exibe a guia de usuários e de grupos na seção de detalhes do inventário do WebSphere Cell.

No TADDM 7.3.0.4, o sensor TPC é usado para truncar o número de linhas retornadas pela consulta para 20000. Esse número pode ser aumentado, mas, para fazer isso, é necessário editar um arquivo chamado tpc.properties em um diretório profundo contido em osgi.

No TADDM 7.3.0.5 (RFE 72225), as propriedades a seguir foram incluídas no arquivo collation.properties com os valores padrão:

com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_PATH.maxrows = 20000

com.ibm.cdb.discover.app.srm.tpc.sensor.HOST_SCSI_AGENT_LESS.maxrows = 20000

No TADDM 7.3.0.4, o MSSQL não exibia o nome do cluster SQL no Portal de Gerenciamento de Dados.

Como parte desse aprimoramento (RFE 115737), o suporte de exibição do nome do cluster SQL foi incluído no TADDM 7.3.0.5 na descoberta regular, na descoberta baseada em script e na descoberta de ASD.

Também para o RFE 99129, uma nova propriedade com.collation.discover.agent.sqlserver.skipSqlAuthentication foi incluída com o valor padrão como Verdadeiro.

Se o valor dessa propriedade estiver configurado para True, ela permitirá primeiro a autenticação do Windows.

Se o valor dessa propriedade estiver configurado para False, ela permitirá primeiro a autenticação SQL.

O TADDM pode usar a arquitetura BigFix (servidor e agentes BigFix) para implementar, executar e capturar automaticamente descobertas assíncronas com script do TADDM.

Basicamente, a ASD (descoberta assíncrona com script) requer uma intervenção manual do administrador do TADDM. O recurso “Integração TADDM-BigFix” utiliza a conectividade fornecida pela infraestrutura do BigFix às máquinas de zona com firewall para a execução da descoberta através dos pacotes de scripts do TADDM e é baseado principalmente na automação da abordagem ASD padrão.

Necessidade de TADDM-BigFix Integration

- Para descobrir a infraestrutura corporativa por trás do firewall, o TADDM atualmente utiliza:

• Manual ASD (Asynchronous Script Discovery)
• Âncoras e Gateways
• As ferramentas IBM Netcool Monitoring (ITM)

- Os clientes não estão dispostos a implementar Âncoras/Gateways para zonas com firewalls

- O ASD manual é complicado e trabalhoso e não é uma opção viável/preferencial

- A integração do TADDM com o BigFix pode preencher essa lacuna

Principais

- Capacidade de descobrir zonas com firewall sem âncoras

- Capacidade de reutilizar a infraestrutura BigFix (por exemplo, portas seguras abertas) para acessar endpoints

• "economizando tempo" = significa que a equipe de segurança não precisa abrir portas em endpoints, somente configurar SSH

- Modo automatizado de descoberta baseada em ASD (denominado AutoASD) atrás de firewalls - Intervenção mínima requerida pelo administrador do TADDM

Nota: Este recurso de integração da BigFix não é igual ou semelhante ao “BigFix Inventory".

Essa integração precisa de acesso (s):

• Acesso somente leitura ao banco de dados do BigFix – para poder recuperar as chaves de criptografia
• Credenciais do servidor BigFix – para poder chamar as APIs do BigFix

Ele também suporta o modo SSL do BigFix.

Observe que a Integração TADDM-BigFix suporta um conjunto semelhante de sensores, como suportado pelo mecanismo ASD padrão.

Consulte a lista de sensores suportados por esse recurso:

Tabela 1.

Sensores
O sensor do Citrix XenServer
O sensor de servidor genérico
Sensor de sistema de computador IBM AIX
IBM DB2 sensor
IBM Lotus Domino do servidor do sensor
IBM Tivoli Sensor de Utilização
IBM WebSphere MQ Server Sensor
O sensor do IBM WebSphere
JBoss Application Server 7 sensor
Kernel-based Virtual Machine sensor
Sensor de sistema de computador Linux
O sensor Microsoft Exchange
Sensor do Servidor da Web do Microsoft IIS
O sensor do Oracle
O sensor de sistema do computador Solaris
O sensor do SSH WebLogic
O sensor do sistema de computador Windows

Todos os pré-requisitos aplicáveis a esses sensores para suportar o modo ASD de descoberta também serão aplicados aqui.

Suposição:

• O espaço em disco, a capacidade de processamento e a memória suficientes devem estar disponíveis para atender aos pacotes de solicitação e de resultado processados no servidor do TADDM, no servidor raiz do BigFix e nos destinos da descoberta
• Somente o “taddmusr” terá permissão de executar a descoberta do BigFix no servidor de descoberta do TADDM e o usuário raiz não será permitido
• Quaisquer destinos de descoberta especificados durante a descoberta e não acessíveis a partir do servidor raiz do BigFix não estarão visíveis no Histórico de Descobertas
• StartTime no Histórico de Descobertas refletirá o horário de início da disponibilização de diversos resultados de execução do pacote de scripts no servidor de descoberta do TADDM e o acionamento de seu processamento
• CompletionTime no Histórico de Descobertas refletirá o horário de término do processamento bem-sucedido de diversos resultados especificados

Limitações:

• “Servidores Customizados” A descoberta não é suportada
• Devido à natureza assíncrona da descoberta, diversas entradas do histórico de descobertas podem ser criadas para uma única descoberta TADDM-BigFix
• A redescoberta é suportada pelo mesmo servidor de descoberta usado para a descoberta original

Aqui estão os detalhes da versão suportada:

• Versão do servidor BigFix: 9.5.4
• Sistema operacional do servidor BigFix: Linux (RHEL 6.8), Windows 2008 R2
• Sistema operacional de destino do BigFix: Linux, Solaris, AIX, Windows

Um novo sensor denominado “Sensor EMC ViPR SRM” descobrirá os recursos de armazenamento relacionados à SAN (rede de área de armazenamento), obtendo os dados necessários do EMC ViPR SRM.

Esse sensor descobre recursos de armazenamento, como matrizes de armazenamento (somente VMAX), hosts e comutadores (somente Brocade), ou seja, somente descobertas de malhas, zonas, conjuntos de zonas, volumes de armazenamento, comutadores, portas de comutador, hosts, HBAs etc.

Suposição:

• A descoberta de host deve estar ativada no EMC ViPR SRM
• “Domínio” está configurado para todos os clientes de host/armazenamento

Limitações:

• O modo SSL do EMC ViPR SRM não é suportado atualmente
• Os mapeamentos de host para armazenamento não são suportados completamente
• A descoberta de relacionamentos e caminhos múltiplos não é suportada

EMC ViPR SRM versão: 4,1

O TADDM 7.3 FixPack 5 garante que todas as comunicações do TADDM sejam cobertas pelo TLS.

com.ibm.cdb.service.SecurityManager.port=9540

com.ibm.cdb.service.TopologyManager.port=9550

com.ibm.cdb.service.RegistriesURLProvider.port=9560

com.ibm.cdb.service.web.secure.port=9431

com.ibm.cdb.service.SecureClientProxyServer.secure.port=9434

com.ibm.cdb.service.SecureApiServer.secure.port=9531

com.ibm.cdb.service.registry.public.port=9433

O TADDM 7.3 FixPack 5 garante que o algoritmo AES-256 possa ser configurado e aplicado para a criptografia desses itens.

A única limitação do TADDM no Fixpack 5 é a incapacidade de descobrir dispositivos SNMP quando AES-256 é o único algoritmo de criptografia configurado no destino. Para suportar a descoberta de dispositivos SNMP com o AES-256 ativado, é necessário fazer um upgrade na versão da biblioteca SNMP do AdventNet usada pelo TADDM. Este é um trabalho planejado e deve ser disponibilizado para os usuários após a liberação do TADDM 7.3.0.5.

O “MssObjLinkCleanupAgent” foi incluído no TADDM 7.3 Fixpack 5. Esse agente de limpeza executará a limpeza adicional de dados MSS.

Por padrão, o agente excluirá diariamente um máximo de 100 K de linhas mais antigas que 365 dias. Esse número de dias pode ser configurado. O usuário pode definí-lo como um valor menor, como 30 dias, para excluir linhas mais antigas que 30 dias. Isso gerará um melhor desempenho de IU e de consultas relacionadas ao MSS.

As propriedades a seguir podem ser configuradas em collation.properties:

com.collation.topobuilder.agent.MssObjLinkCleanupAgent.previousOld.olderThanDays=365  

com.collation.topobuilder.agent.MssObjLinkCleanupAgent.previousOld.on=false

com.collation.topobuilder.agent.MssObjLinkCleanupAgent.maxBatchRows=100

• O tempo de inicialização é um atributo comum no OID padrão para um dispositivo SNMP e ajuda a descobrir o tempo de atividade de um dispositivo SNMP.
• O usuário pode coletar o tempo de inicialização e armazená-lo no banco de dados do TADDM para todos os dispositivos SNMP, ou seja, chassi blade, roteadores, comutadores, firewalls, balanceador de carga, etc.

Antes desse aprimoramento, o sensor IIS exigia que o UAC fosse desativado se estivesse usando uma conta de domínio. Foi devido a requisitos PowerShell. Agora, com esse aprimoramento, é possível descobrir o IIS sem o UAC desativado, pois o sensor IIS usará o appcmd.exe ao invés do PowerShell.

Esse aprimoramento permite a descoberta do VCSA usando interfaces da web. Há uma nova opção de configuração no sensor de Porta para permitir que a especificação de portas de recebimento do VCSA (vcsaListeningPortList) seja usada para acionar a definição do valor inicial do VirtualCenterSensor.

Por padrão, `vcsaListeningPortList` está vazio no sensor de Porta. As portas 80 e 443 são portas universais e podem ser uma má escolha para a geração do valor inicial do VirtualCenterSensor, uma vez que podem causar muitos falsos positivos para invocações do sensor. Recomenda-se a provisão de uma porta mais exclusiva ou listas dos possíveis valores dessa porta em uma implementação do cliente (por exemplo, 514, 902) devem ser usadas em `vcsaListeningPortList` de PortSensors.

Agora, é possível descobrir informações IPv6 VIP de servidores virtuais e reais para dispositivos com IP Big.

O IBM Websphere Message Broker foi renomeado para IBM Integration Bus em versões mais recentes. O TADDM poderá descobrir o IBM Information Bus (IIB) 10.0. O WebSphere MQ não é mais um pré-requisito para usar o IBM Integration Bus 10.0.

Alguns dos atributos nos objetos do modelo Citrix não são relevantes ou não são usados ​​na arquitetura do Citrix XenApp 7.6 e, portanto, não serão preenchidos e poderão ser exibidos sem valor (“Em branco”) no Portal de Gerenciamento de Dados do TADDM, pois o modelo de dados do TADDM é baseado na arquitetura do Citrix 6.

Os sensores do Docker detectam e descobrem clusters, hosts, atributos de host, contêineres e pilhas de rede de sobreposição do Docker a partir dos clusters implementados do Docker ou de hosts individuais do Docker. Um sistema do Docker consiste a seguir:

1. Contêineres contendo NICs virtuais, armazenamento e aplicativos em execução.
2. Hosts do Docker que executam diversos contêineres e um daemon do Docker para gerenciar contêineres.
3. Cluster do Docker que consiste em diversos hosts do Docker e um controlador de cluster.

Um cluster do Docker pode ser obtido através do Swarm fornecido pelo Docker. As APIs chamadas são APIs do Docker sobre HTTP de um cliente para o host ou para o Swarm Manager para descobrir os objetos dentro delas. Esses sensores descobrirão os hosts e, através dos meios existentes, poderão acessar o host.

1. DockerHostSensor – Sensor para um único host do Docker

O DockerHostSensor (DHS) usa APIs do Docker por meio de SDKs e descobre os elementos do ambiente de host do Docker, incluindo – Contêineres, Imagens, Redes, Volumes, etc.

2. SwarmClusterSensor – Sensor para um único cluster do Swarm

O sensor DockerSwarmCluster usa APIs do Docker por meio de SDKs e descobre os elementos do ambiente do Swarm Manager do Docker, incluindo - o Detect Swarm Manager, a lista de hosts do Docker (nós) no cluster, informações de rede envolvendo redes de sobreposição, o docker_gwbridge etc.

• O TADDM pode descobrir Windows 2016
• Suporte para o IBM Spectrum Control 5.2.11, 5.2.12, 5.2.13 e 5.2.14
• O sensor ApacheServer descobre o IBM HTTP Server (IHS) e o Oracle HTTP Server (OHS) no Windows 2008, no Windows 2008 R2, no Windows 2012, no Windows 2012 R2 e no RHEL 7
• O TADDM pode descobrir o IBM i5/OS das versões 7.2 e 7.3
• O TADDM pode descobrir WebSphere 9,0
• O erro 22256560 do Oracle na liberação 12.1.0.2 evita que padrões de agrupamentos sejam executados em determinados casos. O TADDM foi testado com a correção do Oracle para o erro 22256560 nas versões 12.1.0.2 e 12.2.0.1 como o banco de dados de backend. Os padrões de agrupamento funcionam corretamente com a correção aplicada.

• IBM Tivoli Storage Productivity Center sensor: descoberta de discos gerenciados para SVC (camada de virtualização de armazenamento) com suas relações com o armazenamento back-end: Configuração do perfil de descoberta.
• DataPower® sensor: descoberta de domínios e proxies: DataPower sensor.
• Sensor SNMP do IBM BladeCenter: descoberta do chassi do IBM PureFlex System:
  • IBM BladeCenter Sensor SNMP
  • Sensor SVC Storage
• Sensor SNMP do Cisco UCS: capacidade de descoberta estendida: Sensor SNMP do Cisco UCS.
• Aprimoramento de planejamento de descoberta e sincronização de escopo:
  • Incluindo um Planejamento de Descoberta
  • Janela Planejamento de Descoberta
  • Janela Detalhes do Planejamento
  • Carregando um Escopo de Descoberta de um Arquivo
• Configuração dinâmica do nome do espaço de endereço a partir do comando api.sh discover start:
  • Comando Discover
  • Gerenciamento de descobertas
  • Discovery Service
• Descoberta do horário de início dos hosts do VMWare ESX.
• Aprimoramentos de sessão do PowerShell:
  • Configuração automática
  • Configurando as entradas de arquivo collation.properties
• Novos destinos de descoberta suportados:
  • O sensor de sistema do computador FreeBSD descobre FreeBSD 9.3 e 10.2.
  • O sensor do JBoss Application Server 7 descobre WildFly 8 e 9 no Windows Server 2012 e Red Hat Enterprise Linux® 7.
  • O sensor do sistema de computador Linux descobre o SUSE Linux Enterprise Server 12, CentOS Linux 5, 6 e 7
  • O sensor de sistema do computador VMware ESXi descobre VMware ESXi 6.
  • O sensor do servidor do VMware Virtual Center descobre o VMware vCenter Server 6.0 no Windows e o VMware vCenter Server Appliance 6.0 no SUSE Linux Enterprise Server 11.
  • O sensor Microsoft Exchange suporta o Microsoft Exchange Server 2016 no Windows 2012.
  • Microsoft SQL Server suporta o Microsoft SQL Server 2014 no Windows 2012.

• Geração de topologias de aplicativos de negócios no formato SVG: Ações para exportar topologias para o formato SVG
• Agrupamento de padrão transversal com base no atributo hierarchyDomain : Configuração transversal

• Visualizações de blocos de construção
• Visualizações de dados no modelo TADDM

• Tomcat 7 como plataforma
• Descoberta de L2 compatível com FIPS
• Suporte de SSH do Tectia
• Suporte para TLSv1.2
• Auditoria de alterações da interface com o usuário

• Suporte para Red Hat Enterprise Linux 7 x86_64 e Red Hat Enterprise Linux 7 para System z ®.
• Suporte para novos bancos de dados: DB2® 10.5 e Oracle 11g Liberação 2 (11.2)
• Suporte para novos navegadores: Mozilla Firefox 24, 31

• Configuração para descoberta de não administrador no sistema operacional Windows
• Descoberta do Citrix XenServer
• Descoberta do DataPower
• Descoberta de dependências entre Cluster do WAS, Célula, Nó e Bancos de Dados
• Descoberta do ESXi
• Descoberta de HP NonStop através do SSH
• Descoberta do IIS WebDirectory
• Descoberta do JBoss 6
• Descoberta do JBoss 7
• Descoberta do Microsoft Exchange 2013
• Descoberta do MQ 7.1 e 7.5 e suporte de multiversão para Unix e Windows
• Descoberta do MySQL (script customizado para descoberta incluída no FP3)
• Para MaxDB, um novo tipo de entrada da lista de acesso foi incluído
• Descoberta do MySQL para criar módulos para cada banco de dados
• Descoberta do NetApp
• Descoberta de novos atributos para vCenter
• Agente de Dependência do NFS Aperfeiçoado para criar relacionamento com base em compartilhamento montado
• Descoberta de nível 3 em WPARs
• Novos atributos de auth nos scripts Windows e Linux .
• Remoção de pré-requisito LSOF para descoberta do AIX®
• Descoberta baseada em script e assíncrona para sistema operacional Windows
• Descoberta baseada em script para o sistema operacional AIX : paridade aumentada
• Descoberta baseada em script do Microsoft Internet Information Services (IIS)
• Descoberta segura em serviços LDAP
• Suporte do HyperV 2012
• Suporte para Virtual Center Server Appliance (vCSA)
• Unificação do formato FCPort WWN
• Conectividade do VIOS para Subsistema de Armazenamento sem agentes

• Os atributos estendidos são armazenados juntamente com as CIs no atributo XA de um novo tipo customizado ExtendedAttributesData. Os dados que são mantidos em objetos separados do tipo UserData são migrados no atributo XA.
• Os atributos estendidos agora possuem categorias. Se nenhuma categoria for selecionada, um atributo será armazenado na categoria global padrão. Todos os atributos estendidos presentes no antigo modelo de dados foram movidos para a categoria global padrão.