Diretiva de Grupo

Otimizando o desempenho da Diretiva de Grupo

Darren Mar-Elia

Visão geral:

• GPOs monolíticos vs. funcionais
• Como processar entradas de diretiva de grupo
• O que acontece quando ocorrem alterações de GP (Diretiva de Grupo)

Costumam me perguntar: "Do ponto de vista de desempenho, é melhor ter menos GPOs maiores ou um monte de pequenos?" Essa e outras perguntas relacionadas ao design e ao desempenho da Diretiva de Grupo são o foco deste artigo. E, como a maioria das perguntas abrangentes,

posso responder de antemão: "Depende". Embora possa parecer evasivo, meu objetivo é esclarecer os mecanismos que fundamentam o processamento de Diretiva de Grupo para que você possa tomar decisões informadas sobre o design da Diretiva de Grupo, não importa se está apenas iniciando ou procurando otimizar um ambiente com centenas de GPOs existentes.

GPOs monolíticos vs. funcionais

Vamos começar descrevendo as diferentes maneiras de implementar GPOs. Os termos "monolítico" e "funcional" se referem à forma como você os projeta. GPOs monolíticos contêm configurações de muitas áreas diferentes. Por exemplo, um GPO monolítico pode conter configurações das diretivas Modelos Administrativos, Manutenção do Internet Explorer e Instalação de Software – tudo dentro de um único GPO. Por outro lado, GPOs funcionais normalmente fazem uma coisa. Por exemplo, um GPO funcional pode fazer apenas Instalação de Software ou aplicar configurações de Segurança. Já vi GPOs funcionais que contêm somente uma configuração de diretiva! Mas isso provavelmente é o extremo. A Figura 1 mostra algumas das vantagens e desvantagens de cada abordagem.

Figure 1 Comparando GPOs monolíticos e funcionais

Como você pode ver, não há uma resposta simples sobre qual abordagem – monolítica ou funcional – é a melhor em todos os casos. No seu ambiente, é provável que você precise de ambas. Por exemplo, você pode achar a abordagem funcional preferível quando estiver criando diretiva de segurança para o domínio inteiro. Ter um único GPO que contenha somente configurações de segurança torna fácil delegar o controle desse GPO aos seus administradores de segurança onde ninguém mais pode tocá-lo. Pelo mesmo token, se você delegar a administração de GP a administradores de OU, o estabelecimento de um GPO monolítico para cada OU dará a esses administradores um local onde eles poderão gerenciar todas as configurações de diretiva. Isso pode reduzir a complexidade para eles e permitir que você modere o número de GPOs criados para os usuários e computadores de uma determinada OU.

Como essas decisões de design de alto nível afetam o desempenho do processamento de Diretiva de Grupo e como tomar decisões inteligentes sobre o design de GP que miminizem os impactos no desempenho? A primeira etapa no aumento do desempenho da sua infra-estrutura de Diretiva de Grupo é entender como o processamento de Diretiva de Grupo funciona nos bastidores.

Noções básicas sobre o processamento de Diretiva de Grupo

O processamento de Diretiva de Grupo é um conjunto complexo de interações envolvendo muitas peças da sua infra-estrutura do Windows® e do Active Directory®. Em um alto nível, existem duas partes no processamento de Diretiva de Grupo. A primeira é chamada Principal ou processamento da Infra-estrutura de Diretiva de Grupo. Nesta fase, um cliente de Diretiva de Grupo do Windows consulta seu controlador de domínio mais próximo para determinar qual é a velocidade de conexão com o DC, onde ele reside na hierarquia do Active Directory (ou seja, de qual site, domínio e OU o cliente é membro) e quais GPOs se aplicam ao computador ou ao usuário conectado no momento. (É importante observar que, neste contexto, um cliente poderia ser um servidor ou uma estação de trabalho que participe de um domínio do Active Directory.) Uma vez criada a lista de GPOs, a próxima fase é acionada – o processamento da Extensão do Cliente (CSE). Durante a fase de CSE, cada CSE registrado processa a lista de GPOs que implantaram configurações na respectiva área. Por exemplo, o CSE Modelo Administrativo ou Registro é executado primeiro em todos os casos e processa todos os GPOs que se aplicam ao usuário ou computador e que tenham implementado diretiva do Registro dentro deles.

A lista a seguir detalha as etapas percorridas pelo ciclo do processamento de Diretiva de Grupo, incluindo interações de rede entre o cliente e o controlador de domínio. É importante lembrar que a Diretiva de Grupo se aplica tanto a usuários como a computadores. Portanto, cada diretiva de tempo é processada (por exemplo, durante a atualização em segundo plano da Diretiva de Grupo). O ciclo que enumero abaixo será repetido tanto para o computador como para a conta de usuário conectada no momento em um determinado sistema, já que cada um pode ter um conjunto diferente de diretivas aplicadas a eles. Quando isso ocorre, o Windows, na verdade, executa o ciclo de processamento ao mesmo tempo tanto para o usuário como para o computador, com cada ciclo sendo executado em um thread diferente dentro do processo de mecanismo da Diretiva de Grupo. (O processo Winlogon para Windows 2000, Windows XP e Windows Server® 2003, e o serviço Cliente de Diretiva de Grupo no Windows Vista® e no Windows Server 2008.)

Processar uma GP é um procedimento em seis etapas:

1. O cliente executa detecção de vínculo lento do protocolo ICMP em um controlador de domínio no respectivo site para determinar a velocidade de conexão. No Windows Vista, o uso de ICMP para detecção de vínculo lento é substituído pelo serviço Reconhecimento de Locais de Rede (NLA).
2. O cliente lê as informações de status do CSE a partir do Registro local para determinar quais GPOs foram processados por último.
3. O cliente usa LDAP para procurar o atributo gpLink no Active Directory em cada objeto de contêiner em seu respectivo local na hierarquia do Active Directory – primeiro no nível de OU (incluindo todas as OUs aninhadas), depois no domínio e, por último, no nível de site do Active Directory. A partir dos resultados dessa pesquisa, ele cria uma lista de GPOs que devem ser avaliados para processamento.
4. Cada GPO é então pesquisado no Active Directory para determinar se o cliente (usuário ou computador) tem as permissões necessárias para processá-lo. Seu número de versão, o caminho para a parte Modelo de Diretiva de Grupo (GPT) do GPO no SYSVOL e quais CSEs foram implementados nesse GPO também são avaliados.
5. O cliente então usa o protocolo SMB para ler o conteúdo do GPT e obter o número de versão do GPO do arquivo gpt.ini. Os números de versão no Contêiner de Diretiva de Grupo (GPC) e no GPT são um fator usado para determinar se um GPO foi alterado desde o último ciclo de processamento.
6. Cada CSE é executado na ordem em que é registrado em HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions e processa os GPOs que implementam esse CSE caso o GPO tenha sido alterado desde o último ciclo de processamento (conforme determinado durante o processamento principal). Cada CSE também registra em log os dados RSOP (Conjunto de Diretivas de Usuário Resultante) na Instrumentação de Gerenciamento do Windows (WMI) durante cada atualização, se disponível.

Vamos dissecar esse processo e ver como o desempenho pode ser afetado. A primeira coisa a observar é que há uma diferença entre processamento em primeiro e em segundo plano. O processamento em primeiro plano ocorre para computadores durante uma reinicialização do sistema e, para usuários, durante um logon do usuário. Atualizações em segundo plano ocorrem em estações de trabalho e em servidores membros, por padrão, a cada 90 minutos, acrescidos de até 30 minutos em um valor aleatório. Em controladores de domínio, elas ocorrem a cada 5 minutos, por padrão. No Windows Vista, também é possível ter atualizações baseadas no NLA, que são essencialmente eventos de atualização em segundo plano acionados por uma falha anterior do processamento de Diretiva de Grupo decorrente da falta de acesso a um controlador de domínio (como quando o cliente estava offline e um intervalo em segundo plano ocorreu). Por que essas distinções são importantes? Principalmente porque certos CSEs (por exemplo, os CSEs Redirecionamento de Pasta e Instalação de Software) não serão executados durante uma atualização em segundo plano, o mesmo ocorrendo para scripts de logon/logoff ou de inicialização/desligamento.

De modo semelhante, na Etapa 1 desse processo, mencionei o processo de detecção de vínculo lento. Em sistemas anteriores ao Windows Vista, esse processo se baseia em clientes que usam o ICMP para executar ping no controlador de domínio a fim de determinar sua disponibilidade e velocidade de conexão. Se a velocidade de conexão calculada cair abaixo de um determinado valor limite (o padrão é 500 Kb/s), o vínculo será considerado lento e, mais uma vez, certos CSEs, como Redirecionamento de Pasta, Instalação de Software e Manutenção do Internet Explorer, não serão executados. Todas essas condições podem ter impacto no desempenho e no fornecimento de diretiva esperado.

Provavelmente, o aspecto do ciclo de processamento de diretiva com maior impacto no desempenho é a lógica que determina se os GPOs aplicados a um computador ou usuário foram alterados. O mecanismo da Diretiva de Grupo tem uma otimização interna que diz que, se nada fora alterado para um computador ou usuário desde a última vez em que a GP foi processada, nenhum processamento ocorrerá. Obviamente, isso pode ter um tremendo impacto no tempo que os clientes levam para processar a diretiva, em especial se o seu ambiente de GP for razoavelmente estático. Vejamos mais detalhadamente no que constitui uma alteração.

Quando ocorre alteração na Diretiva de Grupo

Então, o que constitui uma alteração em termos de processamento de Diretiva de Grupo? Existem muitos fatores, mas o mais óbvio é que, se você fizer uma alteração em um GPO, os clientes que estejam processando esse GPO detectarão a alteração e o reprocessarão. Como um cliente sabe que um GPO foi alterado? Ele se baseia em números de versão no GPO e dentro do cliente para descobrir.

Um GPO é composto por duas partes: o GPC armazenado no Active Directory no contêiner CN=Policies, CN=System dentro de cada domínio, e o GPT armazenado no SYSVOL na pasta "Policies". Cada parte do GPO contém um número de versão. Para o GPC, esse número de versão é armazenado no atributo versionNumber no objeto do GPC. Para o GPT, ele é armazenado dentro do arquivo gpt.ini na raiz de um determinado GPT. O cliente também mantém um registro dos números de versão dos GPOs que ele processou (por computador e por usuário) dentro do seu Registro. Essas informações de versão são armazenadas em HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History para o computador e em HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID do Usuário> para o usuário, em cada cliente.

Quando ocorre o processamento de Diretiva de Grupo, uma das partes é para examinar os números de versão de todos os GPOs aos quais o computador ou usuário está sujeito e compará-los aos processados durante o último ciclo, como encontrado no Registro. Se algum dos números de versão dos GPOs atuais for diferente (observe que eles só precisam ser diferentes; podem ser maiores ou menores!), esses GPOs serão processados durante o ciclo de processamento atual. Caso contrário, eles não serão processados, a menos que uma destas outras condições de alteração seja atendida:

• Uma alteração na lista de GPOs que se aplicam a um usuário ou computador (um GPO foi adicionado ou removido)
• Uma alteração na associação do grupo de segurança de um usuário ou computador
• Uma alteração em um filtro WMI vinculado a um GPO (um filtro WMI foi adicionado ou removido)

Se nenhuma dessas condições de alteração forem atendidas, o cliente reprocessará a diretiva durante esse ciclo. Mas há sutilezas nesse processo que você precisa saber, já que podem ter um impacto significativo no desempenho. Para um determinado CSE, se houver 1 GPO de 10 alterações, então todos os GPOs deverão ser processados para esse CSE. Lembre-se de que o processamento ocorre por CSE. No entanto, os CSEs devem processar a diretiva na ordem de precedência que controla o processamento (primeiro GPOs locais, depois GPOs vinculados a sites e GPOs vinculados a domínios e, por último, GPOs vinculados a OUs). Dado esse requisito, digamos que um usuário tem 10 GPOs que se aplicam, cada um vinculado a diferentes níveis da hierarquia do Active Directory. E digamos que cada um desses 10 GPOs implementam algumas configurações da diretiva Modelo Administrativo. Agora, um administrador acompanha e altera um GPO vinculado ao domínio, adicionando uma nova configuração da diretiva Modelo Administrativo. Em seguida, o computador ou usuário vai processar a diretiva e observa que o número de versão desse GPO alterado está maior que no último processamento e, por isso, ele precisa ser processado novamente. Mas, a fim de manter a ordem de precedência do processamento de GP, ele deve processar todas as configurações de Modelo Administrativo que se aplicam a todos os GPOs. Assim, uma alteração simples em um GPO pode ter um impacto no desempenho potencialmente significativo para esse cliente.

Comparando o desempenho de GPOs monolíticos e funcionais

Agora que examinamos o ciclo de processamento e como as alterações no ambiente da Diretiva de Grupo afetam o processamento, vamos voltar à nossa discussão sobre GPOs monolíticos versus funcionais e como cada abordagem afeta o desempenho.

Os GPOs monolíticos podem ter uma penalidade de desempenho oculta devido ao modo como funciona o controle de versão da Diretiva de Grupo. Os motivos para isso não são todos óbvios, mas têm a ver com o fato de que não há nenhum conceito de controle de versão por CSE dentro do processamento de Diretiva de Grupo. Digamos que um usuário tem três GPOs que se aplicam a ele. Cada GPO é monolítico no sentido de que implementa várias áreas de diretiva. Por exemplo, vamos supor que cada GPO implemente a diretiva Modelo Administrativo, a diretiva Instalação de Software e a diretiva Redirecionamento de Pasta. Agora, digamos que um administrador faça um alteração na diretiva Modelo Administrativo em um desses GPOs. Seu número de versão é aumentado devido a essa alteração. Em seguida, o usuário acompanha e processa a Diretiva de Grupo. O CSE Modelo Administrativo é iniciado e vê que um dos GPOs foi alterado, por isso processa esses três GPOs novamente.

Quando os CSEs Instalação de Software e Redirecionamento de Pasta são executados, eles também examinam os números de versão do GPO e observam o novo número de versão em um dos GPOs. Porém, como esse número de versão não informa qual área de diretiva foi alterada nesse GPO, eles seguem em frente e processam todos os três GPOs novamente, só para garantir. O resultado é que, em uma implementação de GPO monolítico, fazer alterações em uma área de diretiva pode causar atividade de processamento em outra área.

A verdade é que, no caso da diretiva de instalação de software ou de redirecionamento de pasta, esses CSEs podem não executar de verdade nenhum trabalho porque, por exemplo, se um aplicativo já tiver sido instalado, não o será novamente. Mas o ponto é que esse comportamento pode ocorrer com qualquer CSE e deve ser levado em consideração durante o design de GPOs monolíticos. Se você tiver uma área de diretiva que seja alterada com freqüência, convém considerar a possibilidade de manter GPOs que a implementam separados de outras áreas de diretiva.

Do ponto de vista de um GPO funcional, as considerações sobre desempenho são mais óbvias. Se você tiver mais GPOs por usuário ou computador (já que a abordagem funcional geralmente envolve mais GPOs para um determinado conjunto de configurações de diretiva), isso significa que o mecanismo de Diretiva de Grupo precisará passar mais tempo enumerando esses GPOs durante a fase principal do processamento de Diretiva de Grupo. No entanto, como veremos na próxima seção, não necessariamente isso afeta o desempenho de forma significativa.

Mensurando o desempenho da Diretiva de Grupo

No final das contas, a fim de tomar decisões acertadas sobre o desempenho da sua infra-estrutura de Diretiva de Grupo, você precisa ser capaz de mensurar como a Diretiva de Grupo está sendo executada em seu ambiente da vida real. Modelar ou prever o desempenho da Diretiva de Grupo é praticamente impossível, dado o grande número de fatores que podem afetar um determinado ciclo de processamento. Por esse motivo, a mensuração empírica é sua melhor chance de descobrir se o desempenho do processamento de GP é um problema. O que significa desempenho ruim? Bem, é qualquer situação em que o processamento de Diretiva de Grupo afete negativamente a experiência dos usuários nos sistemas. Isso pode ser diferente para cada organização, mas a chave é saber que você tem um problema.

Então, como medir a duração de um determinado ciclo de processamento de Diretiva de Grupo? Mais uma vez, a resposta não é simples. Se você estiver executando o Windows Vista ou o Windows Server 2008, poderá aproveitar os novos Logs Operacionais de Visualizar Eventos. O log operacional de Diretiva de Grupo dentro de Visualizar Eventos, localizado em Applications and Services Logs\Microsoft\Windows\Group Policy\Operational, fornece uma instrumentação excelente de cada etapa do ciclo de processamento de Diretiva de Grupo, inclusive o tempo gasto durante cada fase de processamento (consulte a Figura 2).

Figura 2** Evento de Log Operacional de Diretiva de Grupo mostrando o tempo de processamento da diretiva **(Clique na imagem para aumentar a exibição)

No entanto, se você não estiver trabalhando em um ambiente do Windows Vista ou do Windows Server 2008, os mecanismos para mensurar os tempos de processamento da diretiva são menos diretos. Nesse caso, suas opções são habilitar o registro detalhado de userenv em log (consulte o artigo de suporte da Microsoft em support.microsoft.com/kb/221833) e exibir os carimbos de data/hora dentro desse arquivo para um determinado ciclo de processamento, ou usar os valores guardados no Registro do cliente que indicam os horários de início e de conclusão do processamento de diretiva. Para o computador, esses valores são armazenados neste local:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

e aqui para o usuário:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

Os valores são armazenados no formato FILETIME e precisam ser convertidos para uma hora e data normal. Você também pode usar o utilitário gratuito GPTime.exe que escrevi (disponível em gpoguy.com/tools.htm#GP_Time_Utility) para obter as mesmas informações.

Se você não tem um ambiente do Windows Vista ou do Windows Server 2008, mas tem acesso a um log userenv, ainda assim poderá obter informações valiosas sobre o tempo gasto em cada ciclo de processamento de diretiva. Por exemplo, a Figura 3 exibe um trecho do log userenv mostrando parte da fase principal do processamento de Diretiva de Grupo.

Figura 3** Uma parte do log userenv **(Clique na imagem para aumentar a exibição)

Observe que cada linha do arquivo de log contém um carimbo de data/hora. A parte principal do ciclo de processamento de Diretiva de Grupo começa quando você vê um evento que diz algo como "ProcessGPOs: Iniciando processamento (em segundo plano) de Diretiva de Grupo de usuário..." A parte CSE do ciclo de processamento de Diretiva de Grupo começa quando você vê a linha "ProcessGPOs: Processando Registro da extensão." Você pode usar esse log e os carimbos de data/hora dentro dele para determinar o tempo que leva cada parte de um ciclo de diretiva.

Observações gerais sobre desempenho

Quando você passa tempo suficiente examinando arquivos de log userenv, começa a ver os padrões surgirem e, embora não possa prever quanto tempo levará o processamento de diretiva, pode começar a fazer algumas observações gerais sobre onde o tempo é gasto em um determinado ciclo de processamento. Por exemplo, durante um evento de processamento de diretiva, quando alterações na diretiva estão sendo processadas e os CSEs têm trabalho a fazer por causa de uma alteração, o tempo gasto na parte principal do processamento de GP normalmente é muito menor se comparado à parte CSE.

Isso ocorre para a maior parte das áreas de diretiva porque a maioria dos CSEs precisa realizar tarefas que sejam executadas por mais tempo que a parte principal do processamento deles, cujas operações mais caras são consultar o Active Directory e o SYSVOL. Por exemplo, não há comparação entre o tempo gasto no processamento principal e o CSE Instalação de Software que executa uma instalação do Microsoft® Office. No entanto, para uma atualização de diretiva em segundo plano normal, na qual nada foi alterado desde o último ciclo, a parte principal do ciclo de processamento leva praticamente o mesmo tempo que a parte CSE. A exceção é o processamento da diretiva Registro, que, na verdade, é razoavelmente rápido, a menos que você tenha dezenas ou centenas de configurações da diretiva Registro no local para um determinado usuário ou computador.

Além disso, a desabilitação do lado do computador ou do usuário de um GPO por não estar sendo utilizado tem pouco efeito no desempenho do processamento de diretiva. Se um lado de diretiva não estiver sendo utilizado, a única sobrecarga será na consulta ao Active Directory para determinar isso, e a mesma consulta deve ser executada para exibir a opção de desabilitação como aquela que ocorre para determinar se algum CSE foi implantado para esse lado do GPO. O efeito de desabilitar um lado é irrisório.

Recomendações de design para desempenho ideal de GP

Agora que examinamos muitos aspectos do desempenho do processamento de Diretiva de Grupo, existem algumas recomendações de design que podem ter impacto direto no desempenho. Elas estão resumidas em quatro pontos-chave.

1. Se você estiver fazendo alterações freqüentes em seus GPOs, tenha em mente o efeito mencionado anteriormente, no qual uma alteração em um CSE pode afetar o processamento de todos os CSEs. Para essa finalidade, se você planeja fazer alterações freqüentes na diretiva do Registro, por exemplo, faz mais sentido colocar sua diretiva de Registro em GPOs funcionais (GPOs que só fazem diretiva do Registro) já que isso impedirá o processamento de outros CSEs quando as alterações ocorrerem.
2. Ao pensar sobre quantos GPOs poderia ser um número excessivo, tenha em mente que o processamento de diretiva só ocorre durante alterações e que CSEs "caros" (como Instalação de Software, Redirecionamento de Pasta), controlar um grande número de diretivas do Registro ou definir permissões em árvores do Registro ou arquivos grandes é que leva a maior parte do tempo. O tempo gasto consultando o Active Directory em relação à lista de GPOs durante o processamento principal geralmente é a menor parte do ciclo de processamento. Assim, 30 GPOs que se aplicam a um determinado usuário, mas fazem alterações mínimas e raramente na diretiva do Registro podem levar menos tempo para serem processados do que 5 GPOs que estejam executando CSEs caros regularmente, porque esses GPOs estão sendo alterados com freqüência.
3. Evite comportamentos que forcem retardamentos óbvios no desempenho do processamento de diretiva. Por exemplo, você pode definir a diretiva para forçar os CSEs a serem processados mesmo que um GPO não tenha sido alterado (em Configuração do Computador\Modelos Administrativos\Sistema\Diretiva de Grupo). No entanto, se você fizer isso, é quase certo que o processamento de diretiva levará mais tempo durante cada ciclo.
4. Tenha em mente as compensações de desabilitar a Otimização de Logon Rápido no Windows XP e no Windows Vista (isso é feito por meio da habilitação da diretiva em Configuração do Computador\Modelos Administrativos\Sistema\Logon\Sempre esperar pela rede na inicialização do computador e no logon do usuário). Quando essa diretiva for habilitada, o processamento em primeiro plano alternará de assíncrono para síncrono. Isso significa que a diretiva do computador e do usuário deve ser executada até o final para que o usuário assuma o controle do computador e do desktop. No entanto, isso também pode ser benéfico, pois contorna o problema de requerer duas ou mais reinicializações ou logons para que as diretivas Instalação de Software e Redirecionamento de Pasta entrem em vigor.

Conclusão

Embora o desempenho do processamento de Diretiva de Grupo não seja uma ciência exata, existe uma visão aprofundada que pode ser trazida para o processo de design e talvez reduza os problemas de desempenho.

Saber como funciona o ciclo de processamento e onde o tempo é gasto pode poupar um bom tempo no rastreamento de problemas de desempenho. Use os logs operacionais do Windows Vista ou do Windows Server 2008 (ou logs userenv em versões anteriores do Windows) para obter informações instrumentadas sobre o ciclo de processamento. Tenha em mente os caprichos do processamento de CSE e o que constitui uma alteração na diretiva do ponto de vista de um CSE. E lembre-se que, em ambientes dinâmicos com muitas alterações, GPOs funcionais podem fazer mais sentido que os monolíticos. Mas o ponto principal é que a Diretiva de Grupo é uma tecnologia criada para ajudar você a gerenciar melhor o ambiente Windows. É muito importante que as suas necessidades de negócios orientem o design de Diretiva de Grupo, e não ao contrário. Ter em mente alguns dos comportamentos de desempenho discutidos aqui pode ajudá-lo a atingir esse objetivo.

Darren Mar-Eliaé MVP de Diretiva de Grupo na Microsoft, criador do site popular de Diretiva de Grupo www.gpoguy.com e co-autor do Microsoft Windows Group Policy Guide (Guia de Diretivas de Grupo do Microsoft Windows; Microsoft Press, 2005). Ele também é CTO e fundador da SDM Software, Inc. Você pode contatá-lo pelo email Darren@gpoguy.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..