Como migrar do OCS Inventory para o GLPI: agente, dados e a validação que fecha o projeto

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

Quem procura hoje como levar o inventário do OCS Inventory para o GLPI encontra o mesmo material de dez anos atrás. O primeiro resultado em português, por exemplo, ensina a instalar o GLPI 0.85.4 ao lado do OCS. Ele saiu em 2015. De lá para cá, portanto, a plataforma passou por dez versões maiores.

O problema não é a idade do texto. É que a pergunta mudou. Em 2015 o assunto era plugar as duas ferramentas, porque o GLPI não coletava nada sozinho. Desde o GLPI 10, no entanto, ele coleta: o inventário nasceu dentro da plataforma. O GLPI Agent assumiu o lugar do FusionInventory como coletor mantido pelo fabricante.

Este guia trata da travessia que a operação faz de verdade. Você vai ver quando ainda vale manter o OCS como ponte. Em seguida, como trocar o agente no parque inteiro. Por fim, que dado o scan nunca recupera sozinho e como provar que nada se perdeu antes de desligar o OCS.

Por que o caminho de 2015 deixou de ser o caminho

Até o GLPI 9.x, coletar hardware e software exigia ferramenta externa. O OCS Inventory fazia a coleta. O GLPI recebia os computadores por importação. Cada lado, então, mantinha o próprio banco. Ou seja, era uma arquitetura de dois servidores para uma tarefa só.

No GLPI 10 isso mudou de lugar. A Teclib levou o código do FusionInventory para o núcleo da plataforma e batizou o coletor de GLPI Agent. Detalhamos essa mudança no guia de inventário no GLPI com Discovery e CMDB. Assim, o inventário virou módulo nativo, com endpoint próprio para receber os dados.

Assim, a consequência prática aparece na hora de decidir. Manter o OCS hoje significa sustentar dois servidores, dois bancos e dois ciclos de atualização. Em suma, dois ambientes inteiros para alimentar um único CMDB. Portanto, confirme antes em que versão a sua instância está: se ela ainda roda um ramo antigo, atualizar o GLPI vem primeiro.

Ponte ou saída: os dois caminhos que existem hoje

Existem dois caminhos legítimos, com custos diferentes. O primeiro mantém o OCS coletando e usa o plugin ocsinventoryng para trazer os computadores para dentro do GLPI. Já o segundo troca o agente no parque e encerra o OCS.

O plugin continua vivo, ao contrário do que a idade dos tutoriais sugere. Inclusive, a lista de versões publicadas traz entregas declaradas para o ramo 11.0. Além disso, ele entra pelo marketplace, como qualquer outro item do catálogo de plugins do GLPI.

O critério de decisão é o prazo, não a preferência. Tem centenas de máquinas espalhadas por unidades sem GPO? Então use a ponte para ganhar o CMDB agora e troque o agente por ondas. Se o parque cabe em três ou quatro ondas de GPO, vá direto para a saída. Dessa forma, você poupa meses de operação dupla.

O que o scan não recupera sozinho

Antes de tocar no agente, separe o que a máquina informa do que só uma pessoa sabe. Essa distinção decide quanto trabalho manual sobra no fim.

O agente devolve processador, memória, disco, endereço MAC, número de série e sistema operacional. Além disso, devolve a lista de software instalado. Ou seja, tudo isso se recupera sozinho na primeira coleta. Por isso, não vale a pena exportar planilha do OCS para esses campos.

Contrato, nota fiscal, centro de custo, localização física, responsável e data de garantia não aparecem em scan nenhum. Esses campos alimentam o CMDB e sustentam a gestão de licenças e contratos. Exporte-os do OCS antes, mesmo quando a migração de hardware for automática.

O campo de responsável merece atenção à parte. Ou seja, ele só faz sentido depois que a base de usuários existe no GLPI. Resolva primeiro, portanto, a autenticação no Active Directory. Do contrário, o ativo chega sem dono e alguém preenche isso na mão, máquina por máquina.

Passo 1: preparar o GLPI antes de tocar no agente

O primeiro passo acontece inteiro no servidor, sem risco para a ponta. Ative o inventário nativo em Administração > Inventário e confirme que a plataforma aceita dados de agente. Sem isso, o agente instalado envia coleta para um endpoint que responde com erro.

No GLPI 11.0.8 recém-instalado a opção vem desmarcada. É ela que abre o endpoint de coleta:

Aproveite a mesma janela para definir a política de importação. Nesse sentido, duas opções mudam o resultado do projeto inteiro. A primeira decide se um equipamento desconhecido entra automaticamente. A segunda define o tempo de retenção do agente sem contato. Deixe a entrada automática ligada durante a migração e reavalie depois.

Feche o passo com backup do banco, porque a carga de inventário escreve em massa. Ao contrário de um erro de cadastro, ela não desfaz com um clique.

Passo 2: trocar o agente OCS pelo GLPI Agent

No Windows, a instalação silenciosa resolve o parque em uma linha por máquina. O parâmetro SERVER aponta o servidor e RUNNOW força a primeira coleta. Já TAG carimba a origem, o que permite separar depois quem migrou de quem ainda não.

# instalacao silenciosa, apontando o agente para o servidor
msiexec /quiet /i GLPI-Agent-1.17_x64.msi SERVER="http://glpi.suaempresa.com.br/" RUNNOW=1 TAG="onda-1"

# remover o agente antigo do OCS pelo nome do produto
wmic product where "name like 'OCS Inventory NG Agent%'" call uninstall

A relação de opções está na documentação oficial dos parâmetros de instalação. Da mesma forma, em ambiente com Active Directory, a mesma linha vira pacote de GPO. Assim, o parque migra por unidade organizacional, sem visita técnica.

Depois da primeira coleta, a ficha do computador passa a declarar a origem de cada componente:

Na operação da Velonet, provedor de fibra com atuação no Brasil e em Angola, montamos o inventário do GLPI de duas frentes. Agente nas estações e descoberta por SNMP nos equipamentos de rede.

O ganho, porém, não foi o número de ativos. Foi eliminar o cadastro manual que antes vivia em planilha, num ambiente de MSP onde cada cliente tem o próprio parque.

O desenho está no case da Velonet com GLPI e MetaBase. A dupla que conduziu o projeto conta a operação no OpCast #07, com Raul Mota e Alves Zulo.

Passo 3: as regras de vínculo, antes da primeira carga

Aqui mora a armadilha que transforma migração em retrabalho. Quando a coleta nova chega, o GLPI precisa decidir se aquele computador já existe. Quem responde isso são as regras de vínculo de equipamentos, em Administração > Regras.

A tela que decide entre atualizar o ativo existente e criar um novo avisa logo no topo como o motor se comporta:

O critério padrão combina número de série, UUID e endereço MAC. Contudo, o parque real quebra esse critério com frequência. Máquina virtual clonada repete UUID. Notebook trocado por garantia repete nome com série nova. Placa de rede USB muda o MAC a cada dock diferente.

Por isso, ajuste a ordem das regras antes da onda 1, nunca depois. Uma carga de 300 máquinas com regra frouxa duplica ativo em silêncio. Depois disso, a limpeza custa mais que a migração. Rode a primeira onda com 10 ou 20 máquinas. Em seguida, confira o resultado antes de liberar o resto.

Passo 4: provar que o parque bate antes de desligar o OCS

Migração termina com prova, não com sensação. A comparação mais simples roda direto nos dois bancos. De um lado, quantas máquinas reportaram ao OCS nos últimos 30 dias. De outro, quantas têm inventário recente no GLPI.

-- no banco do OCS: quem reportou no ultimo mes
SELECT COUNT(*) FROM hardware
WHERE LASTDATE > DATE_SUB(NOW(), INTERVAL 30 DAY);

-- no banco do GLPI: quem ja tem inventario recente
SELECT COUNT(*) FROM glpi_computers
WHERE is_deleted = 0
  AND last_inventory_update > DATE_SUB(NOW(), INTERVAL 30 DAY);

Os dois números não vão bater na primeira semana. Está certo que não batam. Máquina desligada, notebook em férias e equipamento já descartado explicam a diferença. O que importa é a curva: a cada onda, a contagem do GLPI sobe e a lacuna encolhe.

Na lista de computadores, a máquina que já passou pelo agente se separa das outras pela data e pelas colunas preenchidas:

Feche com uma amostra manual. Escolha dez ativos de perfis diferentes: um servidor, um notebook, uma estação de loja. Depois disso, confira campo a campo contra o OCS. Contagem igual com dado errado é o pior desfecho possível, porque ninguém desconfia dele.

O que fazer com o servidor antigo

Não desligue o OCS no dia em que a última onda termina. Mantenha o servidor no ar, em modo somente leitura, por pelo menos um ciclo inteiro de inventário. Ele deixa de receber coleta. Ainda assim, continua respondendo a qualquer dúvida de histórico durante a estabilização.

Depois disso, guarde um dump do banco junto da documentação do projeto e desative o serviço. Vale destacar que a mesma pergunta segue aberta no repositório oficial do agente, sem resposta desde 2024. Quem documenta o próprio caminho não depende de achar essa resposta pronta.

Às vezes a migração faz parte de um movimento maior, com chamados e SLAs mudando de ferramenta junto. Nesse caso, o roteiro geral está no guia de migração para o GLPI. Este artigo cobre o inventário, que é só uma das frentes do projeto.

O que muda na semana seguinte

Uma migração de inventário bem feita some do radar depois de pronta. É assim que se reconhece que deu certo. O parque passa a se atualizar sozinho a cada coleta. Além disso, o CMDB deixa de depender de planilha. Assim, a equipe para de manter dois servidores para a mesma pergunta.

O caminho tem quatro decisões. Nenhuma delas, porém, é sobre comando de terminal. Escolher entre ponte e saída define o prazo. Exportar contrato e localização antes define quanto trabalho manual sobra. Ajustar a regra de vínculo antes da onda 1 define se você limpa ativo duplicado no mês seguinte. Por fim, comparar contagem e amostra define quando o servidor antigo sai do ar com segurança.

Talvez o seu parque esteja espalhado por unidades, com anos de histórico no OCS e ninguém com folga para conduzir a troca. Essa é exatamente a conversa que temos todo mês. Fale com um especialista da OpServices e monte o plano com quem sustenta GLPI em produção.