ERRO 1058 o Confronto Final. E GANHEI!!

CONSEGUI! Depois de 02 semanas arrancado os pentelhos do.... digo, da cabeça, consegui arrumar o DC que estava com problemas.

Galera, DC não é DC Comics, é DOMAIN CONTROLLER. Já esqueceram?? Aquele lá que tava com problema, no antigo post que eu fiz.

Já Lembrou? Ótimo..

Pois é, no post do link acima eu redireciono para as KB's da Microsoft que ensinam a refazer as shares SYSVOL e NETLOGON e também acabar com um erro que dá quando você volta um backup do system state.

Porém o problema da replicação não havia funcionado.

Eu resolvi mais uma vez rebaixar o DC com defeito para Member Server para depois voltá-lo como controlador de domínio, porém desta vez, fiz algumas coisinhas diferentes.

Primeiro de tudo, rebaixei o domain controller, utilizando o comando dcpromo /forceremoval. depois que ele reiniciou corretamente, no DC principal eu fiz a limpeza dos arquivos de metadata (metadata files), para garantir que o DC com defeito fosse totalmente apagado de tudo que poderia identificá-lo como controlador de domínio.

Acessei a KB 216498 da Microsoft que ensina passo-a-passo a utilizar o utilitário ntdsutil que precisa ser instalado à parte através do SUPPORT TOOLS do CD do seu Windows Server 2003 R2.

Siga os passos Abaixo conforme a KB (Em inglês)

EM SEU CONTROLADOR DE DOMÍNIO PRINCIPAL:

Procedimento 1: Windows Server 2003 SP1 ou posterior SOMENTE

1. Click Start, point to Programs, point to Accessories, and then click Command Prompt.
2. At the command prompt, type ntdsutil, and then press ENTER.
3. Type metadata cleanup, and then press ENTER. Based on the options given, the administrator can perform the removal, but additional configuration parameters must be specified before the removal can occur.
4. Type connections and press ENTER. This menu is used to connect to the specific server where the changes occur. If the currently logged on user does not have administrative permissions, different credentials can be supplied by specifying the credentials to use before making the connection. To do this, type set credsDomainNameUserNamePassword, and then press ENTER. For a null password, type null for the password parameter.
5. Type connect to server servername, and then press ENTER. You should receive confirmation that the connection is successfully established. If an error occurs, verify that the domain controller being used in the connection is available and the credentials you supplied have administrative permissions on the server.
   
   Note If you try to connect to the same server that you want to delete, when you try to delete the server that step 15 refers to, you may receive the following error message:
   Error 2094. The DSA Object cannot be deleted0x2094
6. Type quit, and then press ENTER. The Metadata Cleanup menu appears.
7. Type select operation target and press ENTER.
8. Type list domains and press ENTER. A list of domains in the forest is displayed, each with an associated number.
9. Type select domain number and press ENTER, where number is the number associated with the domain the server you are removing is a member of. The domain you select is used to determine whether the server being removed is the last domain controller of that domain.
10. Type list sites and press ENTER. A list of sites, each with an associated number, appears.
11. Type select site number and press ENTER, where number is the number associated with the site the server you are removing is a member of. You should receive a confirmation listing the site and domain you chose.
12. Type list servers in site and press ENTER. A list of servers in the site, each with an associated number, is displayed.
13. Type select server number, where number is the number associated with the server you want to remove. You receive a confirmation listing the selected server, its Domain Name System (DNS) host name, and the location of the server's computer account you want to remove.
14. Type quit and press ENTER. The Metadata Cleanup menu appears.
15. Type remove selected server and press ENTER. You should receive confirmation that the removal completed successfully. If you receive the following error message, the NTDS Settings object may already be removed from Active Directory as the result of another administrator removing the NTDS Settings object or replication of the successful removal of the object after running the DCPROMO utility.
    Error 8419 (0x20E3)
    The DSA object could not be found

    
    

1. Note You may also see this error when you try to bind to the domain controller that will be removed. Ntdsutil has to bind to a domain controller other than the one that will be removed with metadata cleanup.
2. Type quit, and then press ENTER at each menu quit the Ntdsutil utility. You should receive confirmation that the connection disconnected successfully.

Como "melhores práticas" (best practices), em seu servidor de DNS, apague TUDO o que refere-se ao DC que voce excluiu do domínio do seu DNS, principalmente da zona _msdcs.dominio_raiz_da_floresta.com. De preferência, se possível exclua também o serviço de DNS do seu DC com problemas, que você acabou de rebaixar.

Veja em um post mais antigo meu, algumas dicas sobre limpar o DNS.

DAQUI PRA FRENTE, EM SEU DC DOENTE QUE VOCÊ ACABOU DE REBAIXAR:

Depois de fazer os passos acima, vá para seu DC com problemas e na pasta %systemroot% (Geralmente C:\Windows) apague totalmente a pasta SYSVOL, e renomeie a pasta NTFRS para old_NTFRS.

Antes de torná-lo novamente controlador de domínio, inclua-o no seu domínio como Member Server, caso ainda não o tenha feito, para que assim o seu DC principal reconheça-o como membro do domínio.

Procure quaisquer vestígios de que este servidor foi uma vez um Domain Controller. Se puder ou quiser, execute ferramentas de limpeza de registro tipo Marcos Velasco Security, ou CCleaner. No meu caso, utilizei os dois.

Após reiniciar o computador, eu finalmente utilizei o DCPROMO para torná-lo novamente controlador de domínio. Fiz todas as passagens normalmente.

Antes de reiniciar chequei na pasta %systemroot% e verifiquei que havia sido criada nova pasta NTFRS e também uma nova SYSVOL, com toda a estrutura correta.

Ao reiniciar o computador, vejo que lá estão os compartilhamentos e tudo voltou a ser replicado normalmente!!

Mais uma peripécia do Tibúrcio resolvida e com o passo a passo pra você!!

Erro 1058: A revanche. Do erro, não a minha. :P

EDITADO EM 27/09/2010 - ATENÇÃO!! ESTE ERRO PODE SER CAUSADO POR PROBELMAS DE REPLICAÇÃO ENTRE CONTROLADORES DE DOMÍNIO!!

LEIA NA INTEGRA ESTE ARTIGO E OS OUTROS DOIS QUE SÃO RELACIONADOS A ESTE PROBLEMA. O LINK PARA O SEGUINTE ENCONTRA-SE NO FINAL DESTE POST. O LINK PARA O PRIMEIRO POST ENCONTRA-SE NO INÍCIO DESTE, DESTACADO.

NO MEU POST ANTERIOR,procurando a solução para o Event 1058, me deparei com problemas cabeludos que sequer sonhava que existia. Perdeu as Shares NETLOGON e SYSVOL, voltei system state de fevereiro pra ver se resolvia e nada.

Cara, eu usei tanta KB que até perdi a pista de quais foram! Rsrs

Mas hoje consegui uma pequena proeza que foi recriar automaticamente as shares SYSVOL e NETLOGON, mas ainda não consigo replicar.

Veja as KBs que usei, que realmente foram úteis:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;288167 – quando eu voltei um backup do system state que era certeza que funcionava na esperança de que as coisas voltassem ao normal. Ele dava o erro "Target Principal Name is Incorrect", depois que fiz o que a KB mandou funcionou.

http://support.microsoft.com/kb/315457 - esta aqui foi a que me guiou a fazer novamente as shares SYSVOL e NETLOGON hoje de manha.

Ok o que ainda está errado:

Fuçando, descobri que o a pasta C:\windows\sysvol\sysvol\domain_name é uma cópia da pasta c:\windows\sysvol\. Tudo o que você fizer em uma, faz na outra automaticamente.

No meu DC com problema isto não está acontecendo. Acho que perdeu o junction point ou algo assim. Na KB 315457 diz pra usar um tal de LINKD que não tem no support tools. E na solução diz que se aplica a Win2K3 Enterprise, mas não diz se é o R2.

Talvez, assim que eu reparar estes junction points ele voltará a replicar. Caso não, eu vou fazer um DFS entre as pastas c:\windows\sysvol\, dos dois servidores com replicação.

Tá vendo? A rede é pequena mas com problemas de gente grande! Hahaha

Espero que se voce chegou aqui procurando solução para problema semelhante, consiga tê-los resolvido usando as KBs que postei aqui. Eu ainda vou resolver o erro que está dando na minha rede e tenho certeza que vou conseguir replicar.

Antes de mais nada NÃO VOLTE O SYSTEM STATE NEM DE DEMOTE DO SEU DC COM PROBLEMAS!! Se eu não tivesse feito isso, talvez agora, já estaria com o problema resolvido.

Caso voce precise de mais ajuda, deixe um coment, vou verificar com meus instrutores, TechNet, etc etc. Pois ninguem merece essa bucha.

ERRO RESOLVIDO! VEJA A SOLUÇÃO FINAL AQUI!

Erro na Aplicação de GPO Event 1058

Olá Pessoal! Faz um tempinho que não posto... estava com saudades.. Mas já mudamos, e as coisas estão começando a entrar nos eixos, e eu estou conseguindo dar uma manutenção na nossa rede.

EDITADO EM 27/09/2010 - ATENÇÃO!! ESTE ERRO PODE SER CAUSADO POR PROBELMAS DE REPLICAÇÃO ENTRE CONTROLADORES DE DOMÍNIO!!


LEIA NA INTEGRA ESTE ARTIGO E OS OUTROS DOIS QUE SÃO RELACIONADOS A ESTE PROBLEMA. O LINK PARA O SEGUINTE ENCONTRA-SE NO FINAL DESTE POST.

Hoje me deparei com alguns computadores que estão com o seguinte erro:

Tipo de evento: Erro
Fonte do evento: Userenv
Categoria do evento: Nenhuma
Identificação do evento: 1058
Descrição: O Windows não pode acessar o arquivo gpt.ini para GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domínio,DC=com. O arquivo deverá estar em <\\domínio\sysvol\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (Acesso negado. ). Processamento da diretiva de grupo cancelado. Para obter mais informações, consulte o Centro de Ajuda e Suporte em http://support.microsoft.com.
ou
Descrição: O Windows não pode acessar o arquivo gpt.ini para GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domínio,DC=com. O arquivo deverá estar em <\\domínio\sysvol\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (Caminho da rede não encontrado. ).

A Microsoft tem a seguinte KB com as possíveis soluções: KB 842804.

Porém, para mim, nenhuma das soluções apresentadas funcionou. Após muito procurar, verifiquei nesta KB uma frase que me guiou para a solução: Esse problema pode ocorrer se o processo do winlogon tenta processar as diretivas de grupo antes da execução dos outros componentes.

Legal! Então eu apliquei a solução de acrescentar a chave de registro:

1. Clique em Iniciar, em Executar na caixa Abrir, digite regedit e clique em OK.
2. No Editor do Registro, encontre a seguinte subchave do registro:
   
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
3. Se a entrada WaitForNetwork estiver faltando, é necessário adicioná-la. Para fazer isto, execute as seguintes etapas:
   
   1. Clique com o botão direito do mouse na subchave Winlogon, clique em Novo e em Valor DWORD.
   2. Na caixa Nome do valor, digite WaitForNetwork.
4. Clique com o botão direito do mouse em WaitForNetwork e clique em Modificar.
5. Na caixa de diálogo Editar valor DWORD, na caixa Dados do valor, digite 1 e clique em OK.
6. Encerre o Editor do Registro

Em seguida, eu abri o controlador de conexões de rede. Vá em INICIAR>EXECUTAR>Ncpa.cpl

Sabia Dessa? Mais rápido que Painel de controle, Conexões de Rede.

Na própria Janela, vá em AVANÇADO, OPÇÕES AVANÇADAS. Ao abrir vá na aba ORDEM DOS PROVEDORES, e mova REDE MICROSOFT WINDOWS para cima até ser o primeiro provedor da lista. Clique OK.

Depois abra o prompt de comando (prefiro assim para ver possiveis mensagens de erro) e digite GPUPDATE /sync /force /boot

FUNCIONOU!!!

Depois, este erro voltou a acontecer. A Microsoft, na KB que eu comento neste post, dá um hotfix que não resolve algum dos casos.

Já a ponto de chutar o balde, resolvo fazer um teste. Vá no caminho: \\domínio\sysvol\domain\Policies E abra a guia da segurança desta pasta. Tá bom, aos com preguiça de pensar: Abra o windows explorer e digite \\dominio\sysvol\domain, depois clique com o botão direito do mouse, selecione Properties (propriedades) e na guia segurança, adicione os seguintes grupos:

DOMAIN USERS

DOMAIN COMPUTERS

Com as seguintes permissões:

Red & Execute

Read

List Folder Content

(Que geralmente são as padrão).

Rodei vários testes no GPMC e parou de dar o erro, mas estão dando outros que irei pesquisar e postar aqui assim que resolvido.

Espero que essa solução também lhe ajude em partes.

Na minha rede acho que é algo mais sério. Ao dar um "demote" no meu DC secundário, ao recriar ele nao fez as shares NETLOGON e SYSVOL e não replica estes arquivos.

Já fiz várias recomendações de KB's da microsoft, porém sem sucesso. Antes de formatar vou aguardar meus instrutores me darem alguma dica, ou vou formatar e instalar novamente.

Neste DC secundário a única coisa que terei que reconfigurar é o Print Server, Wsus (instalação) e WDS. Acho que vai demorar menos do que achar esta solução, mas vou fazer de tudo para encontrá-la pois me recuso a formatar qualquer computador antes de achar uma solução mais lógica para o problema.

Neste LINK você verá a continuação da solução deste problema, e ao final terá o link para a solução final. Vale a pena dar uma olhada.