Você está na página 1de 10

Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

Administração do Windows
Criando estruturas de UO que funcionam
Ken St. Cyr
 
Visão geral:

Princípios fundamentais para um bom projeto de UO


Modelos de projetos comuns de UO
Documente seu projeto de UO

Não subestime a importância — e a complexidade — de criar uma boa estrutura de UO (unidade organizacional).
Descobri que os departamentos de TI muitas vezes andam nas duas direções — eles
colocam muita ênfase na estrutura de UO ou não pensam suficientemente nela. De qualquer maneira, isso pode levar a
problemas com seu modelo do Active Directory®.
Enfatizar demais a estrutura de UO retira o foco de outras áreas do projeto do Active Directory, como planejar a
topologia do local ou pensar no dimensionamento do controlador de domínio. Por outro lado, quando o planejamento
de UO é colocado em uma posição secundária, a Diretiva de Grupo e a delegação são afetadas.
Uma das desculpas que ouço ocasionalmente é que a estrutura da UO é flexível e pode ser alterada posteriormente se
ela não se adequar. É verdade que a estrutura de UO é flexível; no entanto, os administradores muitas vezes descobrem
que alterar a estrutura da UO mais adiante é mais difícil do que eles haviam previsto originalmente. É claro que novas
UOs podem ser adicionadas, mas as antigas não são fáceis de apagar.
Uma estrutura de UO com um planejamento ruim tende a impor uma vida própria. Se um novo objeto é criado no
diretório e o administrador não sabe em que parte da estrutura da UO colocar o objeto, ele criará uma nova UO ou
colocará o objeto em outro lugar ao qual ele não pertence. Existem perigos nesses dois cenários. Criar uma nova UO é
fácil, mas difícil de controlar ao longo do tempo. A criação desenfreada de UO contribui para uma estrutura de UO
caótica e é fácil deixar as coisas serem inseridas no diretório não-documentado. Por outro lado, se você adicionar um
objeto a uma UO existente à qual ele realmente não pertence, o novo objeto pode receber diretivas que não deveria ou
permissões para o objeto podem ser delegadas a usuários indesejados.
Ao criar estruturas de UO, você deve manter uma equação básica em mente: simplicidade + adaptabilidade =
sustentabilidade. Se seu projeto for muito simples, ele pode não ser adaptável e, portanto, terá que ser alterado com
muita freqüência. Se seu projeto for muito adaptável, tudo será compartimentalizado e isso acarreta muita
complexidade.
Existem três princípios fundamentais com relação à Diretiva de Grupo, delegação e administração de objetos que
podem ajudar a orientar a decisão do seu projeto. Esses princípios podem ser resumidos com três perguntas que você
deve se fazer e ajudarão a garantir que a estrutura de UO criada por você agüentará os testes de tempo e alteração
organizacional:

1. Essa UO precisa ser criada de forma que um GPO (Objeto de Diretiva de Grupo) único possa ser aplicado a ela?
2. Um grupo particular de administradores precisa ter permissões aos objetos nessa UO?
3. Essa nova UO facilitará a administração dos objetos encontrados nela?

Se a resposta a alguma dessas perguntas for "sim", você deverá provavelmente criar a UO. Se a resposta a todas as
perguntas for "não", você deve pensar novamente no layout e determinar se um projeto diferente pode criar um ajuste
melhor. Mas antes de me aprofundar mais nesse assunto e mostrar a você como aplicar esses princípios, devo primeiro
explicar por que eles são importantes.

Princípio 1: Diretiva de Grupo


O primeiro princípio do projeto de UO é levar em conta os objetos de diretiva de grupo que serão aplicados a uma UO.
Um GPO permite que você defina configurações para usuários e computadores de maneira aplicável. Você pode definir
vários GPOs no Active Directory e aplicá-los a um domínio inteiro, várias UOs ou até mesmo os locais do domínio. Os
GPOs são divididos em duas categorias — uma para usuários e uma para computadores.
As diretivas do computador e do usuário podem ser definidas no mesmo GPO. A seção de Configuração do Usuário do
GPO define principalmente a experiência que o usuário terá quando conectado. Esses tipos de configurações existem
também na seção de Configuração do Computador, mas essa seção também contém mais configurações relacionadas à
segurança do computador, como quem pode fazer logon no computador localmente ou como os dados são
criptografados.

1 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

Veja alguns conceitos básicos para se ter em mente ao definir UOs para suportar GPOs. Primeiro, apenas porque as
diretivas do usuário e do computador podem ser definidas no mesmo GPO, não significa que é uma boa idéia colocar
os objetos do usuário e do computador na mesma UO. Combinando-os no mesmo GPO torna os problemas do
aplicativo GPO mais difíceis de serem solucionados. Isso se torna muito evidente quando você possui uma diretiva de
loopback habilitada.
Segundo, várias pessoas esquecem que você pode aplicar GPOs no nível do local e, portanto, projetam suas estruturas
de UO para modelar a estrutura do seu local para os objetivos do aplicativo GPO. Isso é um modelo comum de projeto
de UO, conhecido como Modelo Geográfico. Falarei mais sobre esse modelo em breve. Eu seria negligente se não
reconhecesse que o Modelo Geográfico tem seu lugar na criação da UO, mas como você verá posteriormente, não
acredito que o aplicativo GPO deva ser a razão principal para implementar esse modelo.
Além disso, quando você pensa na sua estrutura de UO em termos de GPOs, o objetivo deve ser eliminar a
complexidade. Certifique-se de que a UO é adicionada ao fluxo da herança de GPO. Se sua UO contiver servidores que
exigem a mesma diretiva de outros servidores, considere colocar esses objetos do computador sob uma UO de
servidores mais ampla e criar várias UOs para diferentes tipos de servidores abaixo da UO de servidores (consulte a
Figura 1). Isso pode simplificar a aplicação da diretiva, uma vez que cada objeto de computador nas UOs inferiores irá
obter a diretiva da UO dos servidores, bem como qualquer outra diretiva específica àquele tipo próprio de servidor.

2 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

Figure 1 Creating multiple OUs for different server types (Clique na imagem para aumentar a exibição)
Outro conceito básico é garantir que você não crie desnecessariamente ou vincule vários GPOs. Com um GPO, é possível
criar uma diretiva e aplicá-la a várias UOs. Isso às vezes é útil, ms também pode ser prejudicial. Se você precisar alterar
uma configuração de GPO e possuir um sistema exageradamente complexo de GPOs vinculados, você poderia
acidentalmente aplicar uma alteração nos objetos errados. Quanto mais vínculos criar, mais difícil será compreender o
escopo de uma diretiva. Do mesmo modo, você deve evitar criar diretivas adicionais com as mesmas configurações de
outras diretivas. Se julgar que faz isso com freqüência, pense em modificar sua estrutura de UO para aplicar um novo
modelo de herança de GPO.
E, finalmente, você deve quase sempre criar uma nova UO para objetos do usuário e do computador. Por padrão,
objetos do usuário e do computador são colocados em contêineres, que não permitem a você vincular GPOs
diretamente a eles. Os GPOs podem ser aplicados aos contêineres de Usuários e Computadores a partir do domínio,
mas, a menos que você bloqueie a herança em outro lugar, essas diretivas serão aplicadas a todos os usuários e
computadores do domínio. No Windows Server® 2003, você pode usar as ferramentas rediruser.exe e redircomp.exe
para alterar o local padrão para objetos do usuário e do computador para a UO que você criou para eles.

3 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

Princípio 2: Delegação
É importante que você crie a estrutura da UO de uma maneira que seja consistente com o modo como as permissões
são delegadas no domínio. Tenha em mente que quando as permissões são delegadas no Active Directory, as alterações
de permissão são feitas apenas para o objeto. Então, se você precisasse conceder a um usuário Controle Total para um
determinado objeto do computador, essa pessoa poderia modificar os atributos do objeto, mas não teria privilégios de
administrador no computador em si.
Veja algumas práticas recomendadas com relação à delegação para quando você criar uma estrutura de UO:
Crie com a herança de permissão em mente Por exemplo, digamos que você queira que os administradores da camada
1 possam alterar a senha para a maioria das contas. Há um grupo especial de usuários para os quais os administradores
não devem ter a capacidade de redefinir senhas, mas os administradores precisam poder alterar os nomes de exibição
nessas contas.
Há duas opções reais aqui. Primeiro, você poderia criar duas UOs paralelas separadas e separar os usuários especiais dos
usuários regulares. Isso, no entanto, significa que se você desejar alterar as opções de delegação para todos os usuários,
precisará alterar essas permissões em dois locais diferentes. Isso também contradiz a prática de não desnecessariamente
fazer a vinculação múltipla de diretivas (consulte a Figura 2).

Figure 2 Maintaining two separate parallel OUs (Clique na imagem para aumentar a exibição)
A outra opção é criar uma UO aninhada e colocar uma permissão de negação explícita na UO com usuários especiais
nela. Qualquer especialista em delegação dirá a você que uma negação explícita não é preferível — mas, nesse caso,
você precisa selecionar o menos pior dos dois males (consulte a Figura 3). Você pode duplicar e manter as
configurações em duas UOs separadas ou pode colocar uma negação explícita em uma das UOs. A negação explícita é
realmente a melhor decisão a longo prazo.

4 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

Figure 3 Using an explicit deny permission (Clique na imagem para aumentar a exibição)


Cuidado com o AdminSDHolder Esse exemplo funciona bem, a menos que os usuários especiais pertençam todos a um
dos grupos de Administradores (Admins. do Domínio, Administradores do Esquema, Administradores de Empresa ou
Administradores), uma vez que as permissões para contas nesses grupos são tratadas de modo diferente. A idéia é que
você não deseja fornecer acidentalmente a alguém permissões para uma conta de administradores.
Se você criar uma UO separada para os administradores, descobrirá que as permissões que você delega a eles
continuam desaparecendo. Isso ocorre devido ao AdminSDHolder, que é um contêiner especial que aplica sua Lista de
Controle de Acesso a todas as contas de administradores a um intervalo específico. Como resultado, qualquer alteração
de delegação feita a uma conta de administrador será revertida se as alterações não forem feitas também ao contêiner
AdminSDHolder. Então, você não deve separar contas de administradores de outras contas para o objetivo da
delegação. É preferível, no entanto, separar as contas de administradores para fins da Diretiva de Grupo — isso é válido
especialmente no Windows Server 2008, onde você pode ter várias diretivas de senha.

Princípio 3: Administração de Objetos


A UO deve facilitar a administração dos objetos. Agrupar objetos na mesma UO pode muitas vezes facilitar a execução
de alterações em massa. O snap-in Usuários e Computadores do Active Directory permite que você edite certos
atributos em uma seleção de vários objetos. Então, se você precisa alterar regularmente um atributo em um grupo de
objetos, é mais fácil fazê-lo se eles estiverem todos na mesma UO.
Isso também é particularmente útil se você estiver fazendo atualizações com um script. Os idiomas de script facilitam
bastante a enumeração de todos os objetos em uma UO e o tratamento deles um por um. A outra opção é pesquisar e
modificar cada objeto individualmente. Simplesmente colocar os objetos na mesma UO para administração pode às
vezes economizar horas de trabalho desnecessário a cada semana.
Outra maneira de ajudar com a administração de objetos é separar os objetos em diferentes UOs com base no seu tipo.
Criar uma UO separada para objetos da impressora ou compartilhamentos publicados garante que esses objetos não
precisem ser eliminados quando você executar a administração em outros objetos da UO. Essa prática também se alinha
com a prática de não agrupar contas de usuário e do computador juntas na mesma UO.

Escolhendo um modelo
Agora que tratei dos princípios da criação da UO, posso examinar mais de perto alguns modelos comuns de projeto.
Observe que existem muito mais modelos do que o espaço que possuo aqui para falar deles. E você não está limitado a
trabalhar dentro das restrições de um único modelo. Você pode escolher partes de cada um e criar o seu próprio
modelo híbrido que atenda às suas necessidades específicas.
Praticamente qualquer modelo pode ser bem-sucedido em uma pequena escala, mas quando sua empresa cresce, sua
capacidade de manter o controle do ambiente diminui. Então, certifique-se de primeiro testar a fundo seu modelo em
um ambiente de laboratório adequado. E lembre-se de que, embora as estruturas de UO possam ser alteradas

5 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

facilmente de início, quanto mais tempo elas estiverem em vigor, poderá ser mais difícil alterá-las.

O modelo raso
O modelo raso obtém seu nome a partir do fato de que ele é mantido na maior parte do tempo simples. Nesse modelo,
algumas UOs de alto nível contêm a maioria dos objetos (consulte a Figura 4). Esse modelo é mais realizado em
empresas menores, onde há uma pequena compra de TI, não há muitas divisões diferentes ou as pessoas tendem a
desempenhar várias funções. Eu tipicamente recomendo não se aprofundar mais do que 10 sub-UOs, embora a
Microsoft sugira um limite de 15 sub-UOs antes que as penalidades de desempenho sejam percebidas.

Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects (Clique na imagem
para aumentar a exibição)
Se sua pessoa de Recursos Humanos é também sua pessoa de folha de pagamento, não faz sentido criar duas UOs
separadas para Recursos Humanos e Folha de Pagamento. No modelo raso, todos os objetos do usuário podem ser
agrupados em uma grande UO de Contas ou podem ser mantidos no contêiner Usuários padrão. Na pior das hipóteses,
seus objetos do usuário devem ser separados a partir dos objetos do computador.
Para esse modelo, também recomendo que você dê um passo além e separe suas estações de trabalho dos servidores.
Em seguida, você pode pelo menos aplicar diferentes Diretivas de Grupo sem ter que definir um GPO que usa uma
Consulta do WMI (Windows® Management Instrumentation) para filtrar estações de trabalho ou servidores.
Uma vantagem de manter sua estrutura da UO ampla, e não profunda, é que as pesquisas do Active Directory serão
executadas mais rapidamente. Tipicamente recomendo não se aprofundar mais que 10 sub-UOs. Seu controle sobre os
objetos não é muito refinado nesse modelo, mas se estiver gerenciando objetos em uma pequena empresa, você não
precisará desse controle refinado. Portanto, esse modelo seria difícil de usar com sucesso em uma grande empresa, mas
ele funciona muito bem em organizações menores.

O modelo geográfico
No modelo geográfico, você cria UOs separadas para diferentes regiões geográficas. Esse modelo é melhor adequado
para organizações que descentralizaram departamentos de TI, mas não desejam incorrer nos custos associados à
operação de vários domínios (consulte a Figura 5).

6 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

Figure 5 The Geographic Model separates OUs by geographical region (Clique na imagem para aumentar a
exibição)
Digamos que você tenha escritórios em Atlanta, Baltimore e Seattle. Se cada local gerencia seus próprios usuários e
computadores, isso pode ser uma opção adequada em termos de delegação. Mas o que acontece se um usuário de
Seattle voa para Baltimore para um treinamento e bloqueia sua conta? A equipe de TI de Baltimore pode não conseguir
ajudar esse usuário se não foram delegadas a ela permissões para a conta desse usuário. Se são 8 da manhã em
Baltimore, são 17 horas em Seattle, o que significa que o usuário pode ter que esperar horas até conseguir falar com
alguém no escritório de Seattle para obter ajuda.
Algumas empresas globais usam um modelo "follow the sun" (24 horas contínuas, contando com as equipes fisicamente
distantes), onde as chamadas de suporte técnico são encaminhadas para um local em um fuso horário onde é no
momento horário comercial padrão. Isso significa que a empresa não precisa operar um suporte técnico 24 horas em
cada local, mas pode ainda fornecer aos funcionários noturnos ajuda, como desbloquear suas contas, quando
necessário.
Se esse é o seu modelo, criar UOs separadas com base no local geográfico provavelmente não é a melhor opção para
suas necessidades operacionais. Você teria que delegar permissões separadas a cada suporte técnico regional para cada
UO de usuários. No entanto, se seus locais não possuem seus próprios departamentos de TI, o modelo geográfico
poderá, na verdade, ser um bom modelo para a sua organização.
O modelo geográfico também é difícil de ser executado em um único domínio devido à natureza de como um domínio
é operado. Um domínio tende a ter um modelo de segurança diferente de outros domínios. Isso é mais evidente
quando você examina um aplicativo empresarial, como o Microsoft® Exchange.
O Exchange Server em Atlanta pode ter diretivas de mensagens diferentes definidas, mas todos os Exchange Servers da
empresa provavelmente possuem os mesmos GPOs aplicados. Se for esse o caso, colocar os Exchange Servers em UOs
separadas com base na região faria com que você vinculasse desnecessariamente o mesmo GPO a várias UOs. Em
termos de delegação, você precisa perguntar se os administradores do Exchange realmente precisam de permissões
únicas para os objetos do computador para os Exchange Servers. Na maioria dos casos, os objetos do computador que
são divididos em UOs geográficas são divididos para fins da Diretiva de Grupo, e não da delegação.

O modelo baseado em tipo

7 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

O modelo baseado em tipo classifica os objetos por suas finalidades (consulte a Figura 6). Quando você criou seu
último objeto de usuário, foi para uma conta de usuário regular, uma conta administrativa ou uma conta de serviço? Em
um modelo baseado em tipo, cada um desses objetos é tratado diferentemente.

Figure 6 The Type-Based Model groups objects according to their functions (Clique na imagem para aumentar a
exibição)
Na maioria dos casos, você deve distinguir entre diferentes classificações de objetos de usuário para diretivas. Suas
diretivas provavelmente serão diferentes com base no tipo de conta de usuário. Por exemplo, permitir que as pessoas
façam logon em um computador com uma conta de serviço é geralmente uma prática de negócios ruim. As senhas da
conta de serviço são normalmente compartilhadas entre várias pessoas, então se alguém faz logon com uma conta de
serviço, sua identidade permanece anônima. Se algo fosse acontecer, você teria problemas para rastrear o usuário que
estava conectado quando o evento ocorreu. Nesse exemplo, você precisaria definir uma diretiva sobre contas de serviço
que impede o logon interativo. Isso se ajusta bem ao modelo hierárquico mostrado na Figura 3.
Você poderia usar a herança de GPO como vantagem aqui. Por exemplo, você poderia ter uma diretiva de todos os
usuários referente a diretivas em vigor para todos os objetos de usuário. Além disso, você poderia ter uma diretiva
separada e distinta para contas de serviço, baseada na diretiva de todos os usuários. Essa abordagem garante que suas
contas de serviço tenham o mesmo conjunto base de diretivas como todas as outras contas, bem como as restrições de
logon específicas.
Essa abordagem também funciona bem para a delegação, onde você está usando a herança de permissão em vez da
herança de GPO. Suponha que você queira que os administradores da camada 2 possam redefinir senhas para todas as
contas, exceto para as contas do administrador da camada 3. Com uma estrutura de UO simples, você teria que delegar
permissões a cada UO que mantém contas de usuários. No entanto, em um modelo baseado em tipo com uma
estrutura hierárquica, você pode conceder ao grupo da camada 2 permissões para "redefinir senha" na UO de Contas e,
em seguida, na UO da camada 3, você poderia simplesmente não herdar as permissões ou até mesmo definir uma
negação explícita para a camada 2 redefinir senhas.
Isso também funciona bem para objetos do computador. Servidores e estações de trabalho podem ser separados,

8 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

permitindo que diferentes diretivas sejam aplicadas a eles. Os servidores podem então ser mais subdivididos em
funções (consulte a Figura 1). Nesse projeto, você pode definir uma diretiva de alto nível na UO de Servidores que afeta
todos os servidores e ainda definir diretivas individuais em cada UO de nível inferior.
Por exemplo, digamos que você tenha uma conta de serviço do MOM (Microsoft Operations Manager). Com esse
modelo em camadas, é possível criar um GPO do MOM e aplicá-lo a UO de Servidores MOM. E dentro desse GPO, você
pode conceder ao serviço MOM direitos de conta para fazer logon como um serviço. Isso apenas se aplicaria aos
servidores MOM nessa UO. Os servidores MOM ainda obterão o GPO de servidores da UO de servidores de nível mais
alto, mas também irão obter o GPO do MOM especializado, vinculado à UO do MOM.

Documente a criação
Pode ser muito compensador criar uma estrutura de UO que resistirá às várias alterações que um ambiente do Active
Directory poderá encontrar. Mas você precisa de alguma maneira de rastrear as características dinâmicas das UOs. Se
não tiver isso, poderá rapidamente perder o controle do seu ambiente. Quando as coisas precisam de uma alteração e
uma UO precisa ser adicionada ou excluída, deve haver uma orientação clara sobre o que fazer para garantir que seu
modelo continue seguindo o projeto, respeitando os três princípios de orientação. É por isso que você precisa possuir
um projeto bem-documentado.
A Microsoft fornece guias de documentação no kit de recursos do Windows Server. Esses guias são bons se a sua
estrutura é sólida e você não espera alterá-la muito. Mas a maioria das organizações possui uma estrutura muito
dinâmica alterada com freqüência. Veja algumas dicas importantes para garantir que sua estrutura de UO seja bem
documentada e possa suportar um ambiente dinâmico.
Verifique se todas as informações são relevantes Eu altamente acredito na documentação com objetivo. Muitos
documentos operacionais possuem tantas informações irrelevantes que é difícil encontrar o que importa. Não se
envolva no processo da documentação apenas visando a documentação. Você realmente precisa incluir o número de
objetos em cada UO ou cada ACE (Entrada de Controle de Acesso) na Lista de Controle de Acesso para a UO? Para
documentação da UO, as seguintes informações normalmente serão suficientes:

Nome da UO
Breve descrição
Quem a criou — ou com quem entrar em contato para mais informações ou alterações
Quando ela foi criada

Não dificulte as atualizações Se você precisa atualizar de modo tedioso algum documento do Microsoft Word
complexo, provavelmente você irá adiar a colocação de atualizações. Não há problemas se você adiar a inserção de
pequenas alterações quando sabe que em breve terá uma quantidade maior de atualizações para inserir de uma vez.
Infelizmente, as pessoas muitas vezes esquecem dessas pequenas alterações ou simplesmente continuam adiando sua
inserção e o trabalho nunca é feito. Portanto, atualizar o documento deve ser muito fácil de forma a não desestimulá-lo.
Na maioria dos casos, uma simples planilha do Microsoft Excel® com algumas colunas funcionará bem.
Faça comentários no objeto em si Os objetos de UO têm um atributo de descrição onde você pode inserir comentários.
Em vez de escrever os comentários no documento do projeto, pense em colocá-los no atributo de descrição para que
outras pessoas possam dizer imediatamente para que serve a UO. Se precisar incluir mais detalhes, coloque uma breve
descrição no atributo de descrição e inclua mais detalhes no documento de UO.
Automatize a documentação Um script pode ser escrito para despejar o conteúdo da estrutura da UO para um arquivo
de texto, uma planilha do Excel ou até mesmo um arquivo HTML. Esse script pode ser executado em uma tarefa
programada todas as noites. Isso pode ser muito útil se você incorpora comentários no campo de descrição da UO.
Depois, é só uma questão de despejar o atributo de descrição para o arquivo e você automaticamente tem uma
estrutura de UO totalmente documentada sempre atual. Se você cria um novo arquivo todas as vezes que o script é
executado, em oposição a substituir o documento existente, você pode manter um registro histórico de como a
estrutura de UO mudou com o tempo.
Infelizmente, a maioria dos administradores não percebe a importância de uma boa documentação da estrutura de UO
até que realmente precisam disso. E, até lá, às 3 horas da manhã, é praticamente impossível descobrir que outras UOs
foram acidentalmente excluídas sem executar uma restauração.
Não aguarde até que isso ocorra com você. Eu recomendo enfaticamente que você se torne proativo nessa área e inicie
imediatamente um documento da UO e designe uma pessoa para ser responsável para atualizá-lo. E se você seguir a
regra de tornar a documentação fácil de atualizar, essa será uma tarefa muito pequena para manter em atividade.

Ken St. Cyr é um consultor da Microsoft com 10 anos de experiência na indústria de TI. Ele projeta e implementa
soluções para diretórios com base no Active Directory desde sua criação.
© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem

9 de 10 13/07/2017 18:04
Designing OU Structures that Work: Choosing the Best Model https://technet.microsoft.com/pt-br/library/2008.05.oudesign(d=printer)...

autorização é proibida..
 

© 2017 Microsoft

10 de 10 13/07/2017 18:04