Azure AD Connect: como corrigir OUs que não sincronizam com o Microsoft Entra (inclui Display Computers, regras e PowerShell)

As OUs certas foram selecionadas no Azure AD Connect mas os objetos não aparecem no Microsoft Entra? Este guia prático mostra como diagnosticar e corrigir o problema, com checklist rápida, exemplos de regras, comandos de PowerShell e validações no Synchronization Service Manager.

Índice

Visão geral do cenário

Uma empresa configurou o Azure AD Connect para sincronizar OUs específicas com o Microsoft Entra. Ainda assim, a maioria dessas OUs — especialmente as que contêm objetos de computador, como “(Site) Display Computers” — não gera objetos visíveis no portal. Ferramentas como o IDFix e o troubleshooter do Azure AD Connect não apresentam erros. O que fazer?

A resposta quase sempre está em um destes pontos: escopo de OU/contêiner, filtros em regras de sincronização, permissões insuficientes, conectividade com DCs, staging mode, ou confusão entre “computadores do AD” e “dispositivos no Entra”.

Checklist de correção rápida

Ação recomendada	Por que é importante?	Como fazer
1. Revisar o filtro de OUs/contêineres	Se a OU/contêiner não estiver marcado, nenhum objeto será lido pelo conector.	Abra o Azure AD Connect Configuration Wizard → Customize synchronization options → Organizational Units. Confirme se todas as OUs e contêineres relevantes (ex.: `CN=Computers`) estão selecionados. OUs criadas depois da instalação não entram automaticamente no escopo.
2. Conferir as regras de sincronização	Regras personalizadas podem excluir OUs ou tipos de objeto (p.ex., `objectClass=computer` ou um filtro por caminho de OU).	Abra o Synchronization Rules Editor e revise regras Inbound/Outbound, especialmente filtros baseados em `objectClass`, `distinguishedName`, `domain` ou atributos de escopo (ex.: `extensionAttribute*`).
3. Validar permissões e conectividade	Sem leitura completa nas OUs ou sem acesso aos DCs certos, o conector não consegue importar objetos.	Verifique se a conta do Azure AD Connect tem Read nas OUs afetadas, e no domínio as permissões Replicating Directory Changes (e …All quando aplicável). Confirme comunicação com todos os DCs do site (> portas LDAP/GC) e que a replicação AD está íntegra.
4. Examinar os logs do Azure AD Connect	Os logs mostram objetos rejeitados, filtros acionados e erros de exportação.	Abra o Synchronization Service Manager (`miisclient.exe`) → guia Operations. No Event Viewer: Applications and Services Logs → Directory‑Synchronization e ADSync.
5. Forçar um ciclo de sincronização	Resolve filas presas e confirma se as mudanças de escopo realmente surtiram efeito.	No servidor do AAD Connect, execute: `Start‑ADSyncSyncCycle -PolicyType Delta` (ou `Initial` para sincronização completa, com cautela).

Notas rápidas que evitam falsas conclusões

OUs não “aparecem” no Entra: o Microsoft Entra exibe objetos (usuários, grupos, dispositivos), não a hierarquia de OUs. Para validar, procure o objeto esperado em Usuários, Grupos ou Dispositivos.
Computadores vs. Dispositivos: em cenários de Hybrid Azure AD Join, o objeto de dispositivo no Entra é criado pelo processo de registro/ingresso do Windows, não apenas por estar numa OU selecionada. Ou seja: marcar a OU de computadores no AAD Connect não basta — é preciso que o dispositivo esteja de fato registrado/ingressado.
IDFix não cobre tudo: ele só avalia objetos que já estão no escopo de sincronização. Se a OU inteira ficou fora do escopo, nada aparece no IDFix.
PowerShell ajuda: cmdlets como Get‑ADSyncConnectorRunStatus, Get‑ADSyncScheduler e Start‑ADSyncSyncCycle aceleram o diagnóstico e a correção.

Entendendo como a sincronização realmente funciona

O Azure AD Connect lê objetos do AD local segundo três fatores: escopo (OUs/contêineres e domínios selecionados), regras (filtros e junções entre conectores e metaverso) e permissões/conectividade (o conector precisa enxergar e ler o que você mandou sincronizar). A ausência de qualquer um desses pilares interrompe a cadeia: sem leitura → sem import → sem sync → sem export para o Entra.

Para “computadores”, lembre que o objeto visto no Microsoft Entra é um dispositivo. O ingresso híbrido (Hybrid Azure AD Join) cria/atualiza esse objeto a partir do Windows, com suporte do SCP e políticas. Se esse fluxo não ocorrer, os “computadores da OU” continuarão invisíveis no portal, mesmo que a OU esteja impecavelmente selecionada no AAD Connect.

Diagnóstico detalhado

Revisar OU/contêiner no escopo de sincronização

Abra o Configuration Wizard e vá em Organizational Units. Expanda o domínio e confirme:
- Se a OU onde vivem os objetos está marcada (ex.: OU=(Site) Display Computers,OU=Workstations,DC=corp,DC=exemplo,DC=com).
- Se o contêiner CN=Computers está marcado, caso você mantenha máquinas lá (o assistente também lista contêineres).
- Se a OU foi criada recentemente, lembre-se de marcá-la — o AAD Connect não inclui novas OUs de forma automática.
Se você usa Cloud Sync em paralelo ao AAD Connect, verifique se não há sobreposição de escopos. O mesmo objeto não deve ser sincronizado por dois mecanismos distintos.

Conferir regras de sincronização e filtros

No Synchronization Rules Editor:

Liste regras Inbound do conector AD. Procure por:
- Scoping filters que excluem objectClass=computer, determinados distinguishedName ou domínios/OU específicos.
- Transformações que definem provision = false para certos tipos de objeto.
Valide regras Outbound do conector Entra (Azure AD). Um filter aqui pode impedir a exportação mesmo que a importação e o join tenham ocorrido.
Se houver regras Custom, anote a precedence e compare com as regras “In from AD – …” e “Out to AAD – …”. Regras com precedência menor (número menor) vencem.

Exemplos de filtros perigosos (apenas ilustrativos):

// Inbound scoping filter (exclui computadores):
objectClass EQUALS computer

// Inbound scoping filter (exclui uma OU inteira):
distinguishedName STARTSWITH "OU=Quarentena,DC=corp,DC=exemplo,DC=com"

// Outbound scoping filter (impede export de dispositivos):
cloudFiltered EQUALS True </code></pre>

<h3>Validar permissões e conectividade</h3>
<p>Sem permissões adequadas ou sem alcançar os DCs corretos, a <em>Full/Delta Import</em> não enxerga objetos:</p>
<ul>
  <li>Conta do conector com <strong>Read</strong> nas OUs escopadas e permissões no domínio (<em>Replicating Directory Changes</em> e, se aplicável, <em>Replicating Directory Changes All</em>).</li>
  <li>Conectividade estável para todos os DCs relevantes (firewall, DNS, latência).</li>
  <li>Replicação AD saudável (evite diagnosticar numa partição desatualizada).</li>
</ul>
<table>
  <thead>
    <tr>
      <th>Porta</th>
      <th>Protocolo</th>
      <th>Uso</th>
    </tr>
  </thead>
  <tbody>
    <tr><td>389 / 636</td><td>LDAP / LDAPS</td><td>Leitura do AD</td></tr>
    <tr><td>3268 / 3269</td><td>GC / GC sobre TLS</td><td>Global Catalog (consultas abrangentes)</td></tr>
    <tr><td>88 / 464</td><td>Kerberos</td><td>Autenticação</td></tr>
    <tr><td>53</td><td>DNS</td><td>Resolução de nomes</td></tr>
  </tbody>
</table>
<p>Comandos úteis para checar rapidamente:</p>
<pre><code>repadmin /replsummary
repadmin /showrepl &lt;NomeDoDC&gt;

Ler computadores da OU esperada

Get-ADComputer -SearchBase "OU=(Site) Display Computers,OU=Workstations,DC=corp,DC=exemplo,DC=com" -Filter \* |
Select-Object Name, DistinguishedName </code></pre>

<h3>Examinar os logs do Azure&nbsp;AD&nbsp;Connect</h3>
<p>Use o <strong>Synchronization Service Manager</strong> (<code>C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe</code>):</p>
<ol>
  <li>Guia <strong>Operations</strong> → abra a última <em>Delta/Full Import</em> do conector AD. Se o contador de <em>Adds</em>/<em>Updates</em> está zerado para a OU esperada, é sinal de escopo/filtro/permissão.</li>
  <li>Abra a etapa <em>Synchronization</em> e procure por <em>Connectors</em> com <em>Disconnectors</em> inesperados (objetos sem <em>join</em>).</li>
  <li>Na <em>Export</em> para o Entra, veja erros como <code>stopped-deletion-threshold-exceeded</code> (indica muitas exclusões bloqueadas)</li>
</ol>
<p>No Event Viewer, navegue até <em>Applications and Services Logs</em> → <strong>Directory‑Synchronization</strong> e <strong>ADSync</strong> para mensagens detalhadas de erro/aviso.</p>

<h3>Forçar um ciclo de sincronização com segurança</h3>
<p>Depois de ajustar escopo/regras, rode um delta:</p>
<pre><code>Start-ADSyncSyncCycle -PolicyType Delta
</code></pre>
<p>Se você alterou profundamente filtros de OU/regras, rode uma inicial (complete):</p>
<pre><code>Start-ADSyncSyncCycle -PolicyType Initial
</code></pre>
<p><strong>Dica</strong>: consulte o agendador para confirmar que o <em>scheduler</em> está ativo e sem sobreposição de janelas:</p>
<pre><code>Get-ADSyncScheduler | Format-List *
Get-ADSyncConnectorRunStatus
</code></pre>

<h2>Quando o objetivo são “computadores”</h2>
<p>Se a sua expectativa é ver “computadores” da OU em <em>Dispositivos</em> no Entra, verifique o fluxo de <strong>Hybrid Azure AD Join</strong> (HAADJ). Marcar a OU no AAD&nbsp;Connect <em>não</em> cria dispositivos por si só.</p>
<ul>
  <li><strong>Verificar o status no Windows</strong>:
    <pre><code>dsregcmd /status
</code></pre>
    Procure <code>AzureAdJoined : YES</code> ou <code>DeviceId</code>. Se estiver <code>NO</code>, o dispositivo não se registrou.</li>
  <li><strong>Eventos de registro</strong>: Event Viewer → <em>Applications and Services Logs</em> → <strong>Microsoft</strong> → <strong>Windows</strong> → <strong>User Device Registration</strong>.</li>
  <li><strong>Service Connection Point (SCP)</strong>: confirme a existência e os <em>keywords</em> corretos:
    <pre><code># Exemplo simplificado de verificação do SCP
Get-ADObject -LDAPFilter "(serviceClassName=Device Registration)" -SearchBase "CN=Configuration,DC=corp,DC=exemplo,DC=com" -SearchScope Subtree -Properties keywords | 
  Select-Object Name, keywords

Política de registro automático: habilite a política para registrar computadores ingressados no domínio como dispositivos (GPO).

Somente depois de concluído o registro/ingresso, o dispositivo aparecerá no Entra. A seleção da OU no AAD Connect garante que atributos relevantes entrem no metaverso quando usados por regras/policies, mas não substitui o fluxo de HAADJ.

Sinais comuns e correções rápidas

Sintoma	Causa provável	Correção
IDFix e troubleshooter sem erros; nada aparece no Entra	OU fora do escopo ou regra filtrando objetos	Revise seleção de OU/contêiner e scoping filters; rode um Delta.
Import/Synchronization com 0 Adds para o conector AD	Permissões insuficientes ou DC errado	Garanta Read na OU e conectividade com os DCs certos; valide a replicação.
Computadores da OU não aparecem em Dispositivos	HAADJ não concluído ou política não aplicada	Verifique `dsregcmd /status`, eventos de registro e SCP; aplique GPO.
Objetos sumiram após ajuste de escopo	Deletion threshold bloqueou a exportação	Revise a mudança, corrija o escopo e, se intencional, ajuste o limite antes de exportar.
Servidor em staging mode	Nenhuma exportação acontece	Desative o staging mode no servidor ativo. Use apenas um exportador por tenant.
Usuários de um domínio específico não sincronizam	UPN/domain não verificado ou excluído por regra	Verifique o domínio/UPN na configuração e os filtros por `domain`.

Comandos de PowerShell prontos para uso

Execute-os no servidor do Azure AD Connect (PowerShell com privilégios):

# Ver o status do scheduler
Get-ADSyncScheduler | Format-List *

Último status de execução dos conectores

Get-ADSyncConnectorRunStatus

Iniciar ciclo delta ou inicial

Start-ADSyncSyncCycle -PolicyType Delta
Start-ADSyncSyncCycle -PolicyType Initial

Encontrar computadores na OU alvo

Get-ADComputer -SearchBase "OU=(Site) Display Computers,OU=Workstations,DC=corp,DC=exemplo,DC=com" -Filter \* |
Select Name, Enabled, whenChanged

Conferir ACL de leitura na OU (resumo)

(Get-Acl "AD:\OU=(Site) Display Computers,OU=Workstations,DC=corp,DC=exemplo,DC=com").Access |
Where-Object { $\_.IdentityReference -match "\" } |
Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

Boas práticas para evitar recorrência

Padronize a estrutura de OUs: separe OUs operacionais (trabalho diário) das OUs de scope de sincronização, minimizando mudanças acidentais.
Documente filtros e regras: mantenha um registro das regras customizadas (quem, quando, por quê) e da precedência.
Inclua novas OUs no escopo: ao criar uma OU, revise o assistente do AAD Connect e valide a seleção.
Monitore a saúde da sincronização: crie uma rotina semanal para verificar Operations no miisclient e o scheduler.
Ambiente de staging: use um servidor em staging mode para testes/controlos, mas garanta que apenas um servidor faça export.

Fluxo de decisão rápido

O objeto existe no AD? (confirme com Get-ADUser/Get-ADComputer)
A OU/contêiner está no escopo? (assistente do AAD Connect)
Há regra filtrando? (Synchronization Rules Editor)
Permissões e DCs OK? (ACL da OU, firewall, replicação)
Logs indicam rejeição? (Operations, Event Viewer)
Sync executou? (Start-ADSyncSyncCycle; verifique counters)
Se for “computador”: HAADJ validado? (dsregcmd /status, GPO, SCP)

Exemplo prático aplicado à OU “(Site) Display Computers”

Suponha que você tenha a OU OU=(Site) Display Computers,OU=Workstations,DC=corp,DC=exemplo,DC=com. Depois de marcá-la no assistente:

No miisclient, a Delta Import do conector AD deve mostrar Adds/Updates para objetos computer (ainda que não exporte como usuários).
Se a sua meta é ver esses computadores em Dispositivos, valide o ingresso híbrido nos próprios equipamentos (GPO aplicada, dsregcmd /status com AzureAdJoined: YES). Sem esse passo, nada aparecerá no portal.
Se houver regra customizada que define provision=false para objectClass=computer, avalie se isso é realmente necessário. Ajuste a regra ou crie uma exceção para a OU.

FAQ

Posso sincronizar apenas um subconjunto de computadores?
Sim, por meio de scoping filters no Synchronization Rules Editor (por caminho de OU, por atributo customizado etc.). Lembre: a aparição como dispositivo no Entra depende do fluxo de registro/ingresso.

Por que a OU não aparece no portal Entra?
Porque o Entra não mostra a árvore de OUs. Ele mostra objetos (usuários, grupos, dispositivos). Use a busca por objeto para confirmar.

“Initial” é seguro?
Sim, mas com cautela: uma sincronização completa pode gerar muitas mudanças. Revise contadores e atente ao limite de exclusões para não bloquear exportações legítimas.

Preciso alterar o IDFix?
O IDFix é útil para atributos inválidos, mas não detecta OUs fora do escopo. Corrija o escopo primeiro; só depois use o IDFix para limpar atributos.

E se eu uso Cloud Sync?
Garanta que o escopo do Cloud Sync não se sobreponha ao do AAD Connect. Evite que o mesmo objeto seja alvo de dois mecanismos.

Conclusão

Na imensa maioria dos casos, OUs “ausentes” no Microsoft Entra se explicam por escopo desatualizado, filtros de regra ou expectativas incorretas sobre computadores versus dispositivos. Siga a checklist, valide permissões e conectividade, examine os logs e, quando o objetivo for “computadores”, confirme o fluxo de Hybrid Azure AD Join. Assim, você normaliza a sincronização e ganha previsibilidade para futuras mudanças de OU.

Resumo acionável

Reabra o assistente do AAD Connect e confira OUs/contêineres.
Revise regras no Synchronization Rules Editor (filtros por objectClass e distinguishedName).
Valide permissões na OU e conectividade aos DCs.
Use miisclient e Event Viewer para ver rejeições/filtros.
Execute Start‑ADSyncSyncCycle para consolidar as mudanças.
Para “computadores”, confirme HAADJ com dsregcmd /status, GPO e SCP.