DeviceLifecycle

Problema

Dispositivos Windows inativos raramente desaparecem de todos os sistemas de gerenciamento ao mesmo tempo. Um computador pode continuar existindo no Active Directory enquanto o registro correspondente no Intune já foi removido, pode ter um objeto antigo no Entra ID ou pode nunca ter sido gerenciado por uma das fontes cloud.

Isso torna perigoso tratar a limpeza como uma comparação simples de nomes ou como uma regra que exige correspondência obrigatória em todas as plataformas. Uma ausência legítima no Entra ID ou Intune não significa, por si só, que a identidade esteja inconsistente.

O DeviceLifecycle foi criado para responder a uma pergunta mais rigorosa: quais evidências realmente existem para este dispositivo e elas são suficientes para permitir uma alteração com segurança?

Solução

DeviceLifecycle é uma automação em PowerShell que usa o Active Directory como fonte local autoritativa, correlaciona registros no Entra ID e Intune quando eles existem e conduz dispositivos elegíveis por um ciclo de vida controlado.

O fluxo possui três modos:

• ReportOnly inventaria e classifica os dispositivos sem realizar alterações administrativas;
• Quarantine executa contenção reversível e preserva o contexto necessário para recuperação;
• Enforce inclui a quarentena e permite a remoção definitiva somente depois dos períodos configurados de retenção e limpeza.

O ponto central da lógica atual é distinguir registro ausente de registro inconsistente.

Correlação baseada em evidências disponíveis

A cadeia de identidade continua utilizando identificadores estáveis:

1. o SID do computador no AD é comparado ao onPremisesSecurityIdentifier no Entra ID;
2. quando existe uma correspondência única no Entra, seu deviceId permite correlacionar o registro do Intune por azureADDeviceId;
3. cada fonte que realmente existe passa a contribuir com seu timestamp de atividade.

A política de decisão ficou assim:

• AD sempre participa da avaliação;
• Entra ID participa somente quando existe uma correspondência única e válida;
• Intune participa somente quando existe uma correspondência única e válida;
• ausência de registro no Entra ou Intune significa evidência indisponível, não ManualReview;
• múltiplas correspondências, identidade inconsistente ou timestamp ausente em uma fonte existente continuam bloqueando a automação;
• uma falha de consulta ao Microsoft Graph permanece fail-closed e não é confundida com uma resposta válida contendo zero registros.

Na prática, um computador antigo no AD sem qualquer registro cloud pode seguir normalmente para quarentena. Por outro lado, se houver um registro cloud recente, esse sinal impede a classificação indevida como dispositivo inativo.

Ciclo de vida

Os limites são configuráveis. O padrão do projeto utiliza:

Quando um dispositivo se torna elegível, Quarantine ou Enforce pode desabilitar a conta do computador no AD, mover o objeto para a OU de quarentena e executar Retire no Intune quando um registro gerenciado realmente existe.

O arquivo state.json preserva o contexto entre execuções. Isso é importante porque o próprio Retire pode remover o registro do Intune antes de o restante do ciclo de vida terminar.

Duas tarefas com responsabilidades diferentes

O modelo de execução agendada foi separado em duas tarefas:

{OrganizationName} - Device Lifecycle

É a tarefa principal. Executa diariamente e utiliza o modo operacional configurado, inclusive Enforce quando ele foi aprovado para produção.

{OrganizationName} - Device Lifecycle Snapshot

É uma tarefa de observabilidade. Executa periodicamente — 30 minutos por padrão — e força sempre ReportOnly.

Essa separação permite manter DeviceLifecycle-Latest.csv atualizado para inventário, API, dashboards e auditoria sem transformar cada atualização do snapshot em uma execução administrativa.

Segurança e recuperação

O projeto foi desenvolvido para limitar o impacto de uma decisão incorreta:

• ReportOnly permanece como ponto inicial de implantação;
• MaximumActionsPerRun limita quantos dispositivos podem ser alterados em uma execução;
• -WhatIf permite simular o caminho de Enforce antes da alteração real;
• identidades ambíguas ou inconsistentes permanecem em revisão manual;
• timestamps ausentes em fontes existentes permanecem em revisão manual;
• a exclusão definitiva só acontece depois da janela de quarentena;
• a limpeza residual da nuvem só ocorre depois da remoção do objeto no AD;
• dispositivos em quarentena possuem um fluxo explícito de recuperação.

A recuperação é deliberadamente administrativa. O script de restauração pode reabilitar a conta no AD, devolver o objeto à OU de produção, limpar o estado do lifecycle e apoiar a revalidação do dispositivo.

Validação em produção

Em 28 de agosto de 2026, a alteração de correlação foi validada em ambiente real em quatro etapas:

1. execução em ReportOnly para revisar a nova classificação;
2. confirmação de que dispositivos sem registros no Entra ID/Intune não eram mais enviados artificialmente para revisão manual;
3. execução de Enforce -WhatIf para validar o conjunto de ações propostas;
4. primeira execução controlada em Enforce, respeitando o limite de alterações por execução.

O lote foi processado conforme esperado, permitindo promover o modo Enforce para a tarefa principal sem alterar o comportamento da tarefa de snapshot, que continua sempre em ReportOnly.

Contagens, hostnames e identificadores específicos do ambiente não fazem parte da versão pública do projeto.

Capacidades operacionais

• inicialização e validação de pré-requisitos;
• correlação AD/Entra/Intune com fontes cloud opcionais;
• execução agendada como SYSTEM;
• snapshot frequente e não destrutivo em ReportOnly;
• quarentena e imposição progressivas;
• limites configuráveis de atividade, retenção e ações por execução;
• relatórios CSV, logs e estado persistente em JSON;
• suporte a -WhatIf;
• procedimentos de recuperação e desinstalação;
• integração opcional e somente leitura pelo DeviceLifecycle-API.

O que o projeto demonstra

DeviceLifecycle demonstra automação de infraestrutura orientada à produção, na qual o desafio principal não é executar comandos administrativos, mas modelar corretamente a qualidade das evidências antes de agir.

A evolução da política de correlação reforçou esse princípio: ausência de informação não deve ser confundida automaticamente com inconsistência, mas toda informação existente precisa passar por validações rigorosas antes de contribuir para uma decisão destrutiva.