none
Despromover AD 2008 e Promover 2016 RRS feed

  • Pergunta

  • Prezados, boa tarde!

    Tenho 02 ADs 2008 R2 replicados.

    Preciso desmpromover um AD com Windows Server 2008 R2 e promover um AD com Windows Server 2016.

    Consegui promover o Sindows Server 2016, mas quando fui despromover o Windows Server 2008 secundário, deu mensagem que algumas funcionalidades do AD estava somente nele e não foi possível fazer a despromoção.

    Pregunto:

    Como eu consigo saber quais funções estão no AD secundário e não estão no primário? Quais comandos devo usar?

    Obrigado!

    terça-feira, 14 de janeiro de 2020 16:40

Todas as Respostas

  • Olá, 

    execute o comando abaixo para verificar quais FSMOs estão presentes no servidor que está tentando despromover.

    netdom query fsmo

    terça-feira, 14 de janeiro de 2020 16:45
  • Obrigado Fernando.

    As regras de FSMO estão no AD principal, está correto.

    Acontece que eu quero remover o AD Secundário, mas quando vou despromove-lo, aparece a mensagem informando que existem funções que não estão no secundário e não deixa rebaixar.

    Quero saber quais funções são estas. É uma mensagem bem genérica.

    Eu simplesmente desliguei o Ad Secundário para observar e percebi que o logon dos usuários ficaram mais lentos, além de algumas GPOs não funcionarem.

    Alguém tem mais algum idéia do que pode estar acontecendo?

    Obrigado!

    terça-feira, 14 de janeiro de 2020 18:15
  • Augusto ,

    qual é exatamente a mensagem que é exibida? Pode postar aqui?

    terça-feira, 14 de janeiro de 2020 18:29
  • Fernando,

    Veja o erro que aparece no Event Viewer.

    Nome do Log:   Directory Service
    Fonte:         Microsoft-Windows-ActiveDirectory_DomainService
    Data:          13/01/2020 16:56:40
    Identificação do Evento:2022
    Categoria da Tarefa:Replicação
    Nível:         Erro
    Palavras-chave:Clássico
    Usuário:       LOGON ANÔNIMO
    Computador:    ADSecundario
    Descrição:
    As funções de mestre de operações mantidas por este servidor de diretório não puderam ser transferidas para o seguinte servidor de diretório remoto. 
     
    Servidor de diretório remoto: 
    \\ADPrimariol 
     
    Isso está impedindo a remoção deste servidor de diretório. 
     
    Ação do Usuário 
    Investigue o motivo pelo qual o servidor de diretório remoto talvez não possa aceitar as funções de mestre de operações ou transfira manualmente todas as funções mantidas por este servidor de diretório para o servidor de diretório remoto. Em seguida, tente remover esse servidor de diretório novamente. 
     
    Dados Adicionais 
    Valor do erro: 
    5005 Informações de configuração obrigatórias estão ausentes do serviço de diretório e não é possível determinar a posse das funções de operações principais únicas flutuantes. 
    Valor do erro estendido: 

    Identificação Interna:
    52498782
    XML de Evento:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" />
        <EventID Qualifiers="49152">2022</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>5</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8080000000000000</Keywords>
        <TimeCreated SystemTime="2020-01-13T19:56:40.532641500Z" />
        <EventRecordID>4879</EventRecordID>
        <Correlation />
        <Execution ProcessID="588" ThreadID="4084" />
        <Channel>Directory Service</Channel>
        <Computer>ADSecundario</Computer>
        <Security UserID="S-1-5-7" />
      </System>
      <EventData>
        <Data>\\ADPrimario</Data>
        <Data>Informações de configuração obrigatórias estão ausentes do serviço de diretório e não é possível determinar a posse das funções de operações principais únicas flutuantes.</Data>
        <Data>0</Data>
        <Data>5005</Data>
        <Data>52498782</Data>
      </EventData>
    </Event>


    terça-feira, 14 de janeiro de 2020 19:04
  • Então, 

    a mensagem indica que o servidor ainda hospeda alguma FSMO. Você executou o comando abaixo?

    netdom query fsmo

    Esse artigo pode ser útil:

    https://dailysysadmin.com/KB/Article/1039/active-directory-active-directory-could-not-transfer-the-remaining-data-the-operation-failed-could-not-transfer-the-remaining-zones-event-id-2091/

    terça-feira, 14 de janeiro de 2020 19:33
  • Caro @Augusto Cardoso, tudo bem!

    Para um processo de Troubleshooting, poderia segue os passos abaixo:

    1.. netdom query fsmo (com esse comando irá verificar quem são seus FSMO – mestre de operações);

    2. Em sua imagem acima, está com erro o mestre atual, caso o comando aponte para esse servidor com problema, recomando ver logs e os comandos: 

    DCDIAG

    Essa ferramenta de linha de comando analisa o estado de um ou de todos os controladores de domínio em uma floresta e relata os problemas para ajudar na solução. O DCDiag.exe consiste em vários testes que podem ser executados individualmente ou em conjunto para verificar a integridade do controlador de domínio.

    #dcdiag /s:nomedoservidor

    Um controlador de domínio normal – Neste exemplo, você deseja examinar o controlador de domínio para que possa verificar se ele está saudável e funcionando corretamente. Digite o seguinte comando no prompt de comando elevado.

    #dcdiag /test:dns

    Executa o teste DNS especificado. Se nenhum teste for especificado, o padrão para /DnsAll.

    #dcdiag /DnsRecordRegistration

    Executa os testes /DnsBasic e também verifica se o endereço (A), o nome canônico (CNAME) e registros de recurso de serviço conhecido (SRV) são registrados. Além disso, cria um relatório de inventário com base nos resultados do teste.

    #dcdiag /DnsAll

    Executa todos os testes, exceto para o teste de /DnsResolveExtName e gera um relatório.

    #dcdiag /a

    Testes de todos os servidores neste site.

    #dcdiag /e

    Testes de todos os servidores da empresa. Substitui /a.

    #dcdiag /fix

    (Afeta somente o teste MachineAccount . Esse parâmetro faz com que o teste corrigir os nomes principais de serviço (SPNs) no objeto de conta de computador do controlador de domínio.)

    #dcdiag /test:replications (relatório sobre o estado das replicações entre DCs)

    #dcdiag /test:dns /e /v (relatório sobre o estado do DNS)

    3. Caso o DC com problema está com problema, aconselho transferir as roles e features para outro servidor, assim como realizar SEIZE.

    Link:

    https://fabiofol.wordpress.com/2018/10/20/artigo-technet-wiki-metadata-cleanup-com-sucesso/

    Abcs FOL!

    • Sugerido como Resposta FÁBIOFOL terça-feira, 14 de janeiro de 2020 23:49
    terça-feira, 14 de janeiro de 2020 23:49
  • Senhores,

    Encontrei algo estranho, ou não.

    Quando eu pingo meu dominio (ping dominio.local), quem responde é o meu AD Secundário.

    Pq será o DNS está fazendo com que o Secundário responda?

    Obrigado!

    quinta-feira, 16 de janeiro de 2020 13:12
  • Augusto, boa tarde!

    O fato de executar o ping domínio.local apontar para o AD Secundário não quer dizer nada, se você tem mais controladores de domínio na rede, cada hora ele pode responder por um deles. Você pode fazer um ipconfig /flushdns na sua estação e efetuar o ping novamente e ele pode apontar para outro.

    Esse AD Secundário seu não tem nenhuma outra função? tipo AD CS.  Coloca a saída do comando netdom query fsmo aqui pra gente ver.

    O fato das estações demorarem mais pra fazer o logon pode ser devido a ordem de configuração da entrega do DNS pelo DHCP, pode estar invertido o DNS1 sendo seu AD secundário e o DNS 2 com o AD primário e daí como desligou o secundário ele vai dar o tempo de timeout e ler o DNS 2.

    quinta-feira, 16 de janeiro de 2020 15:30
  • Muito Obrigado pela ajuda até aqui.

    Eu transferia as Roles FSMO para o AD Secundário. Aparentemente não apresentou problemas.

    Somente meu Firewall (Sonicwall), não encontrou as configurações de LDAP, no novo AD, não conseguiu ler os usuários no AD.


    segunda-feira, 20 de janeiro de 2020 19:46
  • No SonicWall,  da uma olhada na parte de Users, Settings e em Authentication Methods provavelmente ali esta apontando o IP do seu outro Active directory.  Da uma olhada nesse video. https://www.youtube.com/watch?v=3eMBHkkngrk
    terça-feira, 21 de janeiro de 2020 01:52
  • Obrigado pela ajuda, mas ainda não resolveu.

    Meu Sonicwall está configurado corretamente, acredito ser alguma coisa no Servidor que não está liberando esta consulta.

    Tenho AD Primário e Secundário, configurados no Sonicwall. 

    O AD primario, consegue trazer normalmente os usuário LDAP, mas no secundário da erro de "Error: LDAP communication error".

    Alguém tem alguma ideia do que está acontecendo?

    Obrigado

    quarta-feira, 22 de janeiro de 2020 18:56