Estender o Schema - Validação da Consistência

Alguns softwares de mercado ou da própria Microsoft alteram o schema do AD, estas alterações podem levar a quebra do schema (parada total do AD) durante um processo de atualização. Por esta razão temos a necessidade de validar os possíveis problemas que podem ocorrer antes de estender o schema.

Apesar deste procedimento mitigar alguns riscos para a alteração do schema, este procedimento não tira a importância da validação do procedimento em ambiente de teste (laboratótio) antes da execução do procedimento em ambiente de produção.

1. Verificar a versão do schema do AD, para isso instale o support tools e acesse o adsiedit.msc, abra o caminho LDAP “CN=Schema,CN=Configuration,DC=contoso,DC=com”, localize o objeto “CN=Schema-Version” e clique em propriedades, localize o atributo “objectVersion” e verifique o valor deste atributo. Em nosso exemplo, o valor é 31. Outra forma de verificar este valor é através do comando:

dsquery * cn=schema,cn=configuration,dc=contoso,dc=com -scope base -attr objectVersion

2. Realizar um dump do schema que pertence a floresta que será realizado a modificação do schema, para isso, execute o comando (digite na mão, pois alguns casos copiar+colar não funciona):

ldifde –d “CN=schema,CN=configuration,DC=contoso,DC=com” –f schema.ldf

3. Sabendo o valor do atributo e tendo o dump do schema da floresta, iremos verificar a consistência desta versão com todos ldfs seguintes até a versão que irá ser implementada. Por exemplo, a floresta em modo 2003 Nativo possui o valor 31, já o valor em modo 2008 Nativo é 44, neste caso iremos comparar o dump realizado que está na versão 31 com o ldf 32, 31 com o ldf 33 e assim por diante até a versão 44.

Localize todos os ldfs que serão comparados, eles se encontram na mídia de instalação do sistema operacional. Copie estes arquivos para um diretório local no servidor onde será realizado a comparação e onde se enconta o dump do schema que foi realizado. Execute o comando: cscript schchk.vbs schema.ldf sch33.ldf Repita o procedimento para cada ldf, sch34.ldf, sch35.ldf, etc.

4. Verifique se há algum erro no log gerado pelos procedimentos realizados, normalmente erros encontrados terão a descrição “mismatch”. O log gerado será o schchk.log. Caso encontre algum erro, será necessário entrar em contato com o fornecedor da aplicação que alterou o schema. Se a atualização do schema proceder sem a resolução do problema, poderá ocorrer desde a indisponibilidade da aplicação até a quebra do schema.

O problema dos objetos "printqueue" no AD

Os objetos printqueue, são criados quando temos alguma impressora instalada com a opção para publicação no Active Directory. Para cada impressora com esta configuração ativa irá gerar um objeto no Active Directory, além disso, caso o Active Directory não consiga entrar em contato com estes objetos depois depois de 8 horas, o objeto será excluído.

Se imaginarmos um cenário onde temos um parque de 500 desktops com 2 impressoras instaladas e a opção de publicação no Active Directory ativa, teremos a publicação de 1000 objetos, quando estes desktops forem desligado e o Active Directory não conseguir comunicação com estes objetos depois de 8h todos serão deletados, indo para tombstoned, porém ainda armazenados na base do AD. No dia seguinte os desktops voltam a ser ligados, criando novamente 1000 objetos printqueue, com isso a base já teria 2000 destes objetos (1000 ativos / 1000 tombstoned). Seguindo esta lógica no terceiro dia teremos 3000 objetos (1000 ativos / 2000 tombstoned), e assim por diante. O crescimento seria de 1000 objetos diariamente até a quantidade de dias estipulado para a limpeza dos objetos em tombstoned, que limpa os objetos mais antigos a 60 ou 180 dias dependendo da versão do schema.

Em nosso exemplo, vimos que podemos chegar a um incrível número de quase 200.000 objetos printqueue, isto causaria um aumento da base do Active Directory, maior número de replicação entre os Domain Controller do Domínio, etc. Para que estes objetos não sejam criados, basta implementar uma GPO nos computadores para que não seja permitido a publicação das impressoras no Active Directory.

A linguagem VBScript não suporta a consulta de objetos tombstoned através de seus métodos de consulta no AD (ADSI ou ADO), a melhor forma de consultar estes objetos é através do uso do utilitário Adfind.exe, que em apenas um utilitário fornece as funcionalidades do ldapsearch, search.vbs, ldp, dsquery e dsget. Este utilitário pode ser baixado através do endereço http://www.joeware.net/freetools/tools/adfind/index.htm.

Comando para contar os objetos printqueue do domínio. Retire a opção “-c” para obter os detalhes de cada objeto.

AdFind.exe -default -f "objectclass=printqueue" -c 

Comando para contar os objetos printqueue que estão em tombstone do domínio. Retire a opção “-c” para obter os detalhes de cada objeto.

AdFind.exe -default -rb "CN=Deleted Objects" -f "objectclass=printqueue" -showdel -c

 
Para que este problema seja resolvido, defina quais serão os computadores que devem evitar a publicação de impressoras no Active Directory. Na GPO, habilite a opção de “Disable” do template Computer Configuration > Administrative Templates > Printers > Allow printers to be published.