locked
Pool RID esgotado no DC2 e DC3 RRS feed

  • Pergunta

  • Nosso ambiente é composto de três Domain Controllers (DC1, DC2 e DC3) com Windows 2008R2 Enterprise. Os três são GC (Global Catalog), sendo que DC1 é mestre nos 5 papéis FSMO (RID, Schema, PDC, Infrastructure e Name Master). Temos replicação de DS (Domain Services) em DC2 e DC3.

    Numa operação de adição de usuários em DC2, fizemos um script em Powershell que adicionou mais de 1000 nomes, dando erro a partir do 500º usuário. Descobrimos que há um limite de 500 números de RID atribuído a cada DC. Como a inserção foi rápida demais, não permitiu que DC2 contatasse DC1 para renovação.

    Como o DC2 esgotou seu pool, não conseguiu mais renovar com DC1. Um mês depois, o DC3 também esgotou seu pool e também não obteve renovação. Ficamos com DC2 e DC3 travados e atualmente, o único Domain Controller que permite inserir objetos é o DC1.

    Segue um resumo do comando: Dcdiag.exe /TEST:RidManager /v nos três DCs:

    DC1

          Starting test: RidManager

             * Available RID Pool for the Domain is 21105 to 1073741823
             * DC1.contoso.local is the RID Master
             * DsBind with RID Master was successful
             * rIDAllocationPool is 20605 to 21104
             * rIDPreviousAllocationPool is 20605 to 21104
             * rIDNextRID: 20689
             ......................... DC1 passed test RidManager

    DC2

          Starting test: RidManager

             * Available RID Pool for the Domain is 21105 to 1073741823
             * DC2.contoso.local is the RID Master
             * DsBind with RID Master was successful
             * rIDAllocationPool is 19605 to 20104
             * rIDPreviousAllocationPool is 19605 to 20104
             * rIDNextRID: 20104
             * Warning :Next rid pool not allocated
             * Warning :There is less than 0% available RIDs in the current pool
             ......................... DC2 passed test RidManager

    DC3

          Starting test: RidManager

             * Available RID Pool for the Domain is 21105 to 1073741823
             * DC3.contoso.local is the RID Master
             * DsBind with RID Master was successful
             * rIDAllocationPool is 18605 to 19104
             * rIDPreviousAllocationPool is 18605 to 19104
             * rIDNextRID: 19104
             * Warning :Next rid pool not allocated
             * Warning :There is less than 0% available RIDs in the current pool
             ......................... DC3 passed test RidManager

    Tentamos transferir o papel de RID do DC1, mas a operação foi negada. Não tentamos forçar a transferência do papel (Seize Role).

    Na época em que o erro ocorreu, ainda não havíamos aplicado o Service Pack 1. Instalamos então com a esperança de alguma atualização corrigisse esse erro, mas não surtiu efeito.

    Como fazemos para reverter essa situação? Qual seria a melhor prática recomendada?

    • Editado Juty Chen terça-feira, 19 de maio de 2015 18:33
    terça-feira, 19 de maio de 2015 18:25

Respostas

  • Infelizmente o problema pode não estar relacionado com DC2 e/ou DC3, mas sim com o DC1. Se você está recebendo o erro 8453 em ambos os DCs, isso provavelmente é um indicio de que há um problema com o DC de destino da replicação, neste caso, o DC1.

    Minha recomendação é que você leia com muita atenção e siga todos os passos do link abaixo para validar se o DC1 está com todos os atributos (flags) necessários definidos corretamente.

    Replication error 8453 Replication access was denied

    • Sugerido como Resposta 4HorsemenOfDaIT quinta-feira, 26 de novembro de 2015 01:44
    • Marcado como Resposta Cristopher C I_ sexta-feira, 27 de novembro de 2015 13:13
    sexta-feira, 22 de maio de 2015 16:58

Todas as Respostas

  • Boa tarde Juty,

    Muito possivelmente, tu tenhas um problema de replicação no teu ambiente, já que todos os teus DCs acreditam ser RIDMasters.

    DC1 - DC1.contoso.local is the RID Master

    DC2 - DC2.contoso.local is the RID Master

    DC3 - DC3.contoso.local is the RID Master

    Todas as máquinas devem fazer o Bind para o mesmo DC (RIDMaster), no teu caso, o DC1.

    Te aconselho a checar primeiro a replicação do dominio com DCdiag e Repadmin e se quiser, tem um update para problemas de RID, mas são problemas de RID depletion e não o problema que tu tens. Mas a atualização dos binários podem ajudar no teu problema, ainda mais considerando que tu não tinha nem o SP1 instalado.

    https://support.microsoft.com/pt-br/kb/2618669

    Att,
    Jonathan Schirmer

    • Marcado como Resposta Matheus L. M. C. Campos quarta-feira, 20 de maio de 2015 14:25
    • Não Marcado como Resposta Juty Chen quarta-feira, 10 de junho de 2015 13:29
    terça-feira, 19 de maio de 2015 19:36
  • Boa tarde, Jonathan.

    Verifiquei numa instalação padrão, que o Windows 2008 Server habilita cada DC como GC e considera todos como RID Master no teste acima de DCDIAG. Mas considera como RID Master verdadeiro o primeiro DC do domínio.

    Consultando os mestres de operação com o comando: netdom query fsmo, obtivemos
        Schema master                   DC1.contoso.local
        Domain naming master       DC1.contoso.local
        PDC                                     DC1.contoso.local
        RID pool manager               DC1.contoso.local
        Infrastructure master         DC1.contoso.local
        The command completed successfully.

    Por sorte, os objetos criados em DC1 são replicados para DC2 e DC3. Mas se o DC1 cair, não teremos redundância, uma vez, que o papel de RID Master está travado.

    Temos sim, um erro de replicação quando verificamos no Event Viewer de DC1 que recusa requisições de gravação por parte de DC2 e DC3. São gerados 2 eventos 1977 e 1699, como demonstrado a seguir:

        Event 1977
        Log Name:      Directory Service
        Source:        Microsoft-Windows-ActiveDirectory_DomainService
        Date:          5/20/2015 3:58:19 PM
        Event ID:      1977
        Task Category: Replication
        Level:         Error
        Keywords:      Classic
        User:          CONTOSO\DC2$
        Computer:      DC1.contoso.local
        Description:
        The following directory service made a replication request for a writable directory partition     that has been denied by the local directory service. The requesting directory service does not have access to a writable copy of this directory partition.
     
        Requesting directory service:
        9be6303a-bcf8-4a3b-864b-33feea5d439c (dc2.contoso.local)
        Directory partition:
        DC=contoso,DC=local
     
        User Action
        If the requesting directory service must have a writable copy of this partition, verify that the security descriptor on this directory partition has the correct configuration for the Replication Get Changes All access right.  You may also get this message during the transition period after a child partition has been removed. This message will cease when knowledge of the child partition removal has replicated throughout the forest.

        Event 1699

        Log Name:      Directory Service
        Source:        Microsoft-Windows-ActiveDirectory_DomainService
        Date:          5/20/2015 3:58:19 PM
        Event ID:      1699
        Task Category: Replication
        Level:         Error
        Keywords:      Classic
        User:          CONTOSO\DC2$
        Computer:      DC1.contoso.local
        Description:
        This directory service failed to retrieve the changes requested for the following directory partition. As a result, it was unable to send change requests to the directory service at the following network address.

        Directory partition:
        CN=RID Manager$,CN=System,DC=contoso,DC=local
        Network address:
        9be6303a-bcf8-4a3b-864b-33feea5d439c._msdcs.contoso.local
        Extended request code:
        2
     
        Additional Data
        Error value:
        8453 Replication access was denied.

    DC3 também gera os mesmos Eventos 1977 e 1699.

    Parece-nos que a permissão de atualização do pool de RID está travada no DC1. 

    A impressão que temos é que o Patch que o senhor nos indicou evitaria este erro. Mas nada garante que nos faça sair deste erro, mas aplicaremos assim mesmo. Responderemos em breve neste fórum se esta manobra resolveu este problema.

    Att.,

    • Editado Juty Chen quarta-feira, 20 de maio de 2015 19:43
    quarta-feira, 20 de maio de 2015 19:22
  • Juty,

    Outra coisa que podes verificar é a replicação inbound e outbound em todos os DCs, pra ver se tem algum que está com as opções desabilitadas.

    Basta rodar o comando repadmin /options para ver as flags ativas nos DCs.

    Para desativar a flag de Outbound e Inbound Replication, basta executar:

    repadmin /options -disable_outbound_repl
    repadmin /options -disable_inbound_repl

    Att,
    Jonathan Schirmer

    quarta-feira, 20 de maio de 2015 19:52
  • Olá Jonathan,

    Verifiquei com o comando repadmin /options e as mensagens retornaram Ok.

    Em Active Directory Sites and Services/ Sites/ Default-First-Site/ Servers/ DC1/ NTDS Settings, quando clico em Replicate Now, retorna a mensagem "Active Directory Domain Services has replicated the connections". Testei em todas as 6 conexões.

    Quando rodei o comando repadmin / showreps no DC1, mostrou o seguinte:

       Default-First-Site\DC1

       DSA Options: IS_GC

       Site Options: IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED

    De fato, o KCC estava desabilitado. Habilitando o KCC, verificamos que as conexões foram melhor balanceadas entre os DCs, mas não resolveu nosso problema. Os Eventos 1977 e 1699 persistem.

    Vamos subir um DC4 e verificar se o DC1 aloca novo RID Pool. Se o DC1 alocar, isso significa que o problema está apenas em DC2 e DC3. Então realizaríamos a manobra de despromover DC2 e DC3 e promovê-los novamente (dcpromo). Se não alocar, significa que o pool de DC1 travou mesmo, o que não acreditamos ser verdade, pois o mesmo continua alocando novos objetos.

    Att.

    • Editado Juty Chen sexta-feira, 22 de maio de 2015 14:47
    sexta-feira, 22 de maio de 2015 14:37
  • Infelizmente o problema pode não estar relacionado com DC2 e/ou DC3, mas sim com o DC1. Se você está recebendo o erro 8453 em ambos os DCs, isso provavelmente é um indicio de que há um problema com o DC de destino da replicação, neste caso, o DC1.

    Minha recomendação é que você leia com muita atenção e siga todos os passos do link abaixo para validar se o DC1 está com todos os atributos (flags) necessários definidos corretamente.

    Replication error 8453 Replication access was denied

    • Sugerido como Resposta 4HorsemenOfDaIT quinta-feira, 26 de novembro de 2015 01:44
    • Marcado como Resposta Cristopher C I_ sexta-feira, 27 de novembro de 2015 13:13
    sexta-feira, 22 de maio de 2015 16:58