Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar
2 de 2 pessoas classificaram isso como útil - Avalie este tópico

Gerenciamento Estruturado de Esquemas do Active Directory na Microsoft

Criando um Fluxo de Trabalho de Mudanças Uniforme e Padronizado

Publicado em: 9 de janeiro de 2005 | Atualizado em: 12 de fevereiro de 2005

Informe oficial técnico

IT Showcase
Nesta página

Resumo Executivo
Introdução à Mudança de Esquemas
Ambiente do Microsoft Active Directory
Arquitetura do Sistema de Gestão de Mudanças
Passando Pelas Fases do Processo de Mudança
Atenuação de Riscos
Práticas Recomendadas e Normas da IdM
Conclusão
Para obter mais informações

Resumo Executivo

O Microsoft® Active Directory® (AD) é uma infra-estrutura global de gerenciamento de identidades e acesso. Além disso, o AD conta com funções gerais de diretório e extensibilidade que os desenvolvedores de aplicativos podem e devem usar quando forem necessárias funções de diretório em um aplicativo em desenvolvimento. O uso das funções do AD centraliza e simplifica a administração dos diretórios. O AD também reduz os custos de desenvolvimento e aumenta a compatibilidade dos dados. Por exemplo, o uso da interoperabilidade do serviço de autenticação e autorização do AD em um aplicativo atinge dois objetivos. Elimina a necessidade de criar mais um banco de dados de segurança e simplifica o gerenciamento da segurança corporativa.

Para usar as funções do AD para apoiar processos de negócios ou novas ferramentas, os desenvolvedores de aplicativos estendem o esquema do AD. O esquema é um componente do AD que define todos os objetos e atributos usados pelo serviço de diretório para armazenar dados. Normalmente, um administrador de esquema faz as mudanças de esquema de maneira independente ou o processo de instalação de software automatiza as mudanças. A Microsoft recomenda a institucionalização de um sistema de gestão de mudanças para que sejam obtidos resultados ideais de mudança de esquema.

Este trabalho apresenta a abordagem do departamento de TI da Microsoft para gerenciar o processo de mudanças de esquema do AD por meio de um fluxo de trabalho estruturado. O fluxo de trabalho estruturado garante o projeto, a implementação, o uso, a propriedade e a segurança adequados de cada mudança implantada em cada floresta. A experiência da TI da Microsoft mostra que um sistema robusto e cuidadosamente planejado de gestão de mudanças com base no Microsoft® Operations Framework (MOF) contribui com uma infra-estrutura de esquema extremamente fácil de gerenciar. Usando o MOF, A TI da Microsoft criou um processo em cinco fases que inclui os marcos de justificativa, avaliação, teste, preparação e implementação. Planejando e preparando cuidadosamente as mudanças de esquema, junto com a gestão das comunicações e expectativas dos clientes, eles conduzem o processo de mudança de esquema do AD com tranqüilidade, reduzindo os riscos para o AD. Com um processo uniforme e previsível, as partes podem se concentrar em atingir as metas de negócios.

As grandes empresas interessadas em assegurar um resultado ideal para cada mudança de esquema por meio de um fluxo de trabalho estruturado tirarão muito proveito deste documento. Este trabalho foi redigido para profissionais de TI, arquitetos e profissionais de serviços de diretório já familiarizados com as funções do Windows, com o AD e com questões de gerenciamento de identidades. O trabalho examina de maneira aprofundada a solução de gestão de mudanças da TI da Microsoft. Ele apresenta práticas recomendadas, recomendações e aspectos de implantação. Os que adotarem indicações deste documento poderão aplicar as recomendações, os princípios e as técnicas de projeto de gestão de mudanças à maioria dos ambientes de TI de grande porte utilizando produtos da Microsoft. Entretanto, como o ambiente de cada empresa tem suas próprias características, as empresas que adotarem estas indicações não devem usar este trabalho como guia de procedimentos. Cada empresa deve adaptar as informações deste documento às suas necessidades específicas.

Observação: por razões de segurança, os exemplos de nomes de florestas, domínios, recursos internos, organizações e nomes de arquivos de segurança desenvolvidos internamente usados neste documento não representam nomes de recursos reais usados dentro da Microsoft e são apenas para fins ilustrativos.

Introdução à Mudança de Esquemas

Os desenvolvedores experientes de aplicativos do Windows utilizam ou estendem as funções existentes do AD ao criar aplicativos que precisam de funções de diretório. Isso inclui gestão de identidades, configuração centralizada e gestão de acesso, ou funções gerais de diretório. Estender ou utilizar as funções do AD permite que o aplicativo utilize o subsistema de segurança existente e os dados compartilhados no diretório global. Como isso aumenta a eficiência dos recursos, a Microsoft recomenda o uso ou a extensão das funções existentes do AD, em vez de criar um novo banco de dados de identidades fora do AD.

Observação: extensão do esquema é o processo de modificar ou atualizar o esquema.

Devido aos possíveis impactos sobre o AD, é importante assegurar que a mudança do esquema nõa cause resultados imprevistos. As empresas podem executar alterações de esquema com tranqüilidade por meio de planejamento, de testes e da gestão das expectativas dos clientes em relação às mudanças.

Fundamentos do Esquema

O esquema é um componente do AD que define todos os objetos e atributos usados pelo serviço de diretório para armazenar dados. O serviço de diretório usa objetos como unidades de armazenamento. Sempre que o serviço de diretório lida com dados, ele consulta o esquema em busca de uma definição correta de objetos. De acordo com a definição de objetos no esquema, o serviço de diretório cria o objeto e armazena os dados. Por exemplo, quando um administrador cria um novo objeto Usuário, o AD utiliza as definições de esquema para criar e configurar o objeto Usuário padrão. A estrutura física do esquema consiste nas definições de objetos armazenadas na sua própria partição do esquema no diretório. Todos os domínios de uma floresta dividem o mesmo esquema.

As definições de objetos controlam os tipos de dados que os objetos podem armazenar, bem como a sintaxe dos dados. Como mostra a Figura 1, os objetos de subclasses herdam as características das classes acima deles. Utilizando essas informações, o esquema garante a conformidade de todos os objetos com as suas definições padrão. O resultado é que o AD pode armazenar, acessar e confirmar os dados que gerencia, independentemente do aplicativo que gera os dados. Apenas os dados que possuírem uma definição de objetos no esquema podem ser armazenados no diretório. Se um novo tipo de dados precisar ser armazenado no diretório, os administradores de esquemas devem, em primeiro lugar, criar uma nova definição de objetos de dados no esquema.

Figura 1. Classes de Objetos de Esquema com Herança

Figura 1. Classes de Objetos de Esquema com Herança

Modificações no Esquema

Normalmente, os usuários não interagem diretamente com o esquema todos os dias. O AD utiliza o esquema para ajudar a criar objetos armazenados no diretório. Os usuários interagem com esses objetos, não com o esquema. Os administradores interagem diretamente com o esquema ao efetuar modificações no esquema, com a inclusão de definições ou com a modificação das que já existem. Como listas de controle de acesso (ACLs) protegem os objetos de esquema, apenas os usuários autorizados podem alterar o esquema.

Extensões do Esquema

O esquema padrão é um conjunto básico de classes e atributos fornecidos em uma floresta do AD. Quando as definições existentes de classes e atributos no esquema não atendem às necessidades de uma empresa, ela pode acrescentar ou modificar os objetos do esquema para estendê-lo. Desenvolvedores e administradores experientes podem estender o esquema definindo novas classes e novos atributos para as classes existentes, a fim de armazenar um novo tipo de informação no diretório.

Os motivos pelos quais os administradores de esquema normalmente modificam o esquema são os seguintes:

  • Uso de Funções do AD por Pacotes de Aplicativos. A instalação de um aplicativo que utiliza funções do AD pode modificar o esquema por meio da inclusão de definições personalizadas de objetos para armazenar informações no diretório. Por exemplo, o Microsoft Office Live Communications Server 2003 acrescenta novas classes de objetos e outros atributos ao esquema para lidar com a percepção de presença.

  • Uso de Funções do AD por Aplicativos Internos. A instalação de um aplicativo personalizado que utiliza funções do AD pode exigir modificações no esquema.

Escopo das Modificações no Esquema

A extensão do esquema é uma operação avançada que exige planejamento e testes cuidadosos. O esquema é fundamental para o uso e para a operação do AD em uma floresta. Portanto, para evitar problemas, as empresas devem pensar com cuidado em qualquer extensão ou alteração do esquema básico do sistema. Mudanças no esquema podem afetar configurações importantes tais como a indexação do banco de dados do diretório, a disponibilidade global dos dados do catálogo e o tamanho e a integridade do banco de dados do AD.

Em geral, não é possível desfazer as modificações realizadas no esquema. Ao pensar em realizar alterações, há três aspectos essenciais que devem ser lembrados:

  • As extensões do esquema são globais. O esquema-mestre reproduz todas as alterações do esquema para todos os controladores de domínio (DCs) da floresta.

  • As classes de esquema referentes ao sistema não podem ser modificadas. Os administradores do sistema não podem alterar classes padrão de sistema no esquema do AD. Entretanto, os administradores podem alterar as classes opcionais de sistema que foram incluídas por eles.

  • As classes e os atributos do esquema não podem ser retirados. Após incluir uma nova classe ou um novo atributo no esquema, os administradores podem desativar a classe ou o atributo, marcando-a(o) como "morto(a)". Embora os administradores não posssam retirar completamente a classe ou o atributo, eles podem modificar algumas propriedades de atributos ou classes após a criação. Por exemplo, se um objeto existente precisar alterar um atributo inalterável, os administradores podem fazê-lo marcando o objeto original como "morto" e, em seguida, alterando o seu Nome Distinto Relativo (RDN). Isso permite a criação de uma nova instância do objeto com o valor do atributo corrigido. Para obter mais detalhes, consulte: http://msdn.microsoft.com/library/en-us/ad/ad/disabling_existing_classes_and_attributes.asp.

Com um planejamento e uma preparação cuidadosos da mudança do esquema, além do gerenciamento da comunicação e das expectativas do cliente, os administradores pdoem conduzir o processo de mudança do esquema do AD de maneira tranqüila e com muito pouco risco para o AD.

Gestão de Mudanças no Esquema

Estender o esquema é algo poderoso e fácil de realizar. Um sistema de gestão de mudanças corretamente projetado ajuda as empresas a aplicar mudanças de esquema de maneira uniforme e previsível. Isso, por sua vez, permite que as empresas se concentrem nas metas operacionais ou de negócios. É muito importante que uma empresa estabeleça um processo formal de gestão de mudanças no esquema antes de estendê-lo.

Projeto do Processo

Um processo de gestão de mudanças bem projetado proporciona um fluxo de trabalho padronizado que asssegura os resultados ideais. Com o processo implementado, as responsabilidades e expectativas ficam claras para todas as partes. O processo deve oferecer instruções detalhadas para todo o fluxo de trabalho. Isso vai da primeira solicitação de mudança à decisão sobre quem deverá comunicar a todas as partes envolvidas que o processo foi um sucesso total.

O Processo de TI da Microsoft

Tendo implantado o serviço de diretório AD como parte do Microsoft Windows 2000 Server, a Microsoft tem defendido o AD e o desenvolvimento de produtos de software que utilizem funções do AD desde então. Como a Microsoft é uma empresa de desenvolvimento de software, as mudanças no esquema do AD são mais freqüentes na Microsoft que em uma empresa comum. É comum que os produtos de software desenvolvidos pela Microsoft utilizem funções do AD. O resultado é que as instalações e os testes internos de software da TI da Microsoft freqüentemente envolvem mudanças de esquema. Além disso, como a TI da Microsoft usa o seu próprio software beta no ambiente de produção como parte do processo de desenvolvimento, ela precisa instalar várias versões provisórias antes da versão definitiva de cada programa, e cada uma delas requer a atualização do esquema.

A TI da Microsoft realizou pelo menos 25 mudanças específicas no esquema nos últimos cinco anos, implantando a maioria delas em várias florestas. Durante esse tempo, eles criaram um fluxo de trabalho que evoluiu para se tornar um processo normalizado de mudança. Com base nessa ampla experiência, a TI da Microsoft padronizou o fluxo de trabalho no sistema oficial de gestão de mudanças para todas as mudanças de esquema na Microsoft. O processo de gestão de mudanças de esquema na TI da Microsoft ajudou a padronizar as mudanças de esquema e gerar resultados ideais com grandes implementações de software, entre elas:

  • Exchange Server 2003 A TI da Microsoft instalou seis versõe provisórias pré-lançamento do Exchange para fins de teste e alterou o esquema em quatro a seis ambientes de produção por vez. Isso foi realizado sem que a rede fosse interrompida.

  • Data Protection Manager (DPM). A TI da Microsoft instalou a versão pré-lançamento do DPM em quatro ambientes de produção. A mudança do esquema ativou um recurso que permite aos usuários finais recuperar os seu próprios arquivos mantidos em diretórios compartilhados do servidor de arquivos.

  • Avaya Unified Messaging. A TI da Microsoft implantou as extensões da Avaya em três ambientes de produção sem qualquer problema.

Ambiente do Microsoft Active Directory

Para entender o process de mudanças de esquema na Microsoft, é importante compreender o ambiente do AD, a infra-estrutura de Gestão de Identidades e Acesso que ele apóia, além das equipes que prestam suporte ao AD.

Panorama da Infra-Estrutura

A Infra-Estrutura de Gestão de Identidades e Acesso da Microsoft é semelhante a outros ambientes de grandes empresas. A infra-estrutura possui um conjunto de serviços essenciais ao ambiente de informática da Microsoft. O AD é a base da infra-estrutura de identidades de cada floresta. Ele centraliza o gerenciamento de identidades para manter os recursos disponíveis e protegidos. A infra-estrutura também serve de base de testes das versões pré-lançamento dos produtos de software gestão de identidades desenvolvidos pela Microsoft.

Configuração para Várias Florestas

Como mostra a Figura 2, o gerenciamento centraliado de várias florestas caracteriza a Infra-Estrutura de Identidades da Microsoft.

Figura 2. Organização da Infra-Estrutura de Identidades da Microsoft

Figura 2. Organização da Infra-Estrutura de Identidades da Microsoft

A TI da Microsoft gerencia integralmente várias dessas florestas. Ela gerencia conjuntamente as outras florestas com a equipe de tecnologia de cada floresta. Cada floresta compartilha uma relação de confiança unidirecional ou bidirecional com a Floresta Corporativa. Setenta por cento dos aplicativos utilizados na Microsoft residem na Floresta Corporativa. Essas florestas abrigam mais de 35 repositórios de identidades. Os repositórios de identidades incluem o AD, SAP, Siebel, Group Membership Manager, Account Manager Application e um grande número de outros repositórios. A equipe de Gestão de Identidades da TI da Microsoft utiliza o Microsoft Identity Integration Server (MIIS) 2003 com o Service Pack 1 (SP1) aplicado para sincronizar os dados de identidade entre vários multiple repositórios de identidades.

São necessárias diversas florestas na Microsoft por algumas razões. Os aplicativos em desenvolvimento, tais como as versões pré-lançamento do Exchange, precisam ter a sua própria floresta para evitar interferências com a Floresta Corporativa durante as primeiras implantações e os primeiros testes antes do lançamento. As florestas também existem por razões de segurança, quando se trabalha com parceiros externos por meio de uma extranet. Além disso, devido às exigências legais associadas à joint venture MSNBC, a MSNBC mantém uma floresta separada. Finalmente, a TI da Microsoft cria especificamente algumas florestas para divisões de negócios na empresa, tais como a divisão MSN.

Configuração de Rede

A Microsoft possui 215 DCs em todo o mundo, nas cinco florestas gerenciadas pela TI da Microsoft. Isso inclui mais de 16 domínios, 138 DCs de florestas e 30 DCs de extranets. Há 184 locais com o AD, 63 com DCs, que lidam com 60 mil logins únicos na floresta a cada dia. A floresta corporativa possui nove domínios com um total superior a 1 milhão de objetos e um tamanho médio de arquivo no caálogo global de 9,0 gigabytes (GB). A rede fornece uma média de 1,5 megabyte (MB) por segundo e uma largura de banda mínima de 256 kilobits (Kbits) por segundo.

Topologia de Replicação

A TI da Microsoft configurou as florestas para realizar replicações uma vez por hora, com cinco saltos entre as localidades, proporcionando uma latência total máxima de cinco horas. Eles mantêm uma complexa topologia de localidades que corresponde à sua topologia de rede com mais de 300 localidades em todo o mundo. A maioria das mudanças de administração, inclusive todas as mudanças de esquema, ocorre em Redmond, Washington (EUA). Redmond é o ponto intermediário, com uma latência máxima de três horas em relação qualquer outra localidade.

Ambiente de Suporte às Mudanças de Esquema

A TI da Microsoft é responsável por dirigir todas as atividades relacionadas à execução e manutenção dos sistemas de informação da Microsoft em todo o mundo. Na organização de TI da Microsoft IT, a equipe de Gestão de Identidades (IdM) e a equipe de Engenharia de Infra-Estrutura (IEng) são responsáveis pelo AD. A equipe de IdM é responsável pela gestão de identidades entre as florestas e, especificamente, pela gestão dos esquemas do AD. A equipe de IEng gerencia os DCs e a replicação.

Organização de TI da Microsoft

A equipe de TI da Microsoft é responsável por orientar operações globais e fornecer serviços de TI à toda a organização da Microsoft. A TI da Microsoft dirige todas as atividades relacionadas à execução e manutenção dos sistemas de informação em todo o mundo. Eles mantêm a infra-estrutura tecnológica e os sistemas de informação corporativo e de marketing. Isso inclui produção, distribuição e outros sistemas internos essenciais. A TI da Microsoft trabalha para demonstrar altíssima competência na operação de utilitários e negócios. Isso é realizado por meio da liderança no projeto e na integração das estratégias, dos processos e da arquitetura da empresa.

A equipe de TI da Microsoft fornece uma grande variedade de serviços, incluindo suporte a servidor e usuário final, gerenciamento de telecomunicações, operações de rede e segurança de informações. Essa função inclui o gerenciamento da conectividade para mais de 300 mil computadores pessoais pelo mundo. A TI da Microsoft garante que mais de 63 mil funcionários e 35 mil contratados e fornecedores em 90 países e mais de 400 unidades da Microsoft possam ter acesso aos serviços e recursos da rede corporativa 24 horas por dia, 7 dias por semana.

Como a atividade principal da Microsoft é o desenvolvimento de softwares, a equipe de TI possui uma segunda missão única entre os provedores globais. A TI da Microsoft foi uma das primeiras a adotar as tecnologias da empresa, sendo responsável por testar e implantar os produtos da Microsoft, tais como o SharePoint™, o Windows Server 2003, o Microsoft Identity Integration Server 2003 e o Exchange Server 2003, antes que eles sejam disponibilizados para os clientes. Esse processo de implantação antes do lançamento é conhecido na Microsoft como “comer a nossa própria ração de cachorro”, ou simplesmente “dogfooding”.

Usando os produtos antes do lançamento no ambiente corporativo da Microsoft, a TI da Microsoft testa os produtos minuciosamente em situação de uso real e avalia o seu valor para os negócios. Isso ajuda a moldar as configurações finais dos produtos e identifica as práticas recomendadas para orientar as implantações dos produtos pelos clientes. O rigoroso ambiente de teste corporativo do "dogfooding" dá à Microsoft a confiança de distribuir produtos de qualidade. Das lições aprendidas durante o procsso, os grupos dos produtos podem melhorar os seus projetos e agregar valor à versão final.

Equipe de Gestão de Identidades (IdM) da TI da Microsoft

A equipe de IdM gerencia a infra-estrutura de gestão de identidades da Microsoft. A equipe gerencia todos os aplicativos/ferramentas, todas as contas e todos os grupos correlados, além do fluxo de trabalho para a realização de inclusões ou alterações.

A equipe de IdM gerencia todas as contas dos usuários: usuários normais, usuários com acesso elevado, contas de serviço e contas internas. Eles também gerenciam grupos, inclusive s grupos administrativos, e os respectivos aplicativos internos. Além disso, a equipe de IdM gerencia unidades organizacionais, objetos de políticas de grupos e relações de confiança. Eles supervisionam a sincronização entre as florestas utilizando o MIIS 2003 SP1 para sincronizar vários tipos de objetos, inclusive usuários e grupos, sites, sub-redes e filas de impressão. Isso proporciona uniformeidade às funções dos aplicativos e ao uso dos recursos à medida que os usuários navegam entre as diversas florestas.

Entre as responsabilidades da equipe de IdM está a gestão dos esquemas do AD. Como a equipe de IdM é a proprietária do conteúdo do diretório, ela gerencia os dados nos diretórios como uma única instância lógica. Para manter a uniformidade entre as florestas, quando a equipe de IdM muda o esquema em uma floresta, ela geralmente o altera em todas as outras florestas. Embora a equipe de IdM é encarregada do processo de mudança de esquemas, ela não gerencia todos os aspectos do processo. Por exemplo, ela não gerencia fisicamente os DCs, a topologia de replicação, nem os aplicativos. A equipe de IEng e os proprietários específicos dos aplicativos cuidam desses aspectos.

Equipe de Engenharia de Infra-Estrutura (IEng)

A equipe de IEng é responsável pelos principais servidores de infra-estrutura da TI da Microsoft, o que inclui os DCs em que o AD reside. A equipe gerencia o desempenho, a administração e a configuração dos servidores. Além disso, a equipe de IEng determina onde posicionar os DCs na rede, de acordo com as dependências dos aplicativos e com a conectividade de rede. A equipe de IEng gerencia a topologia de replicação de dados. Seu envolvimento no processo de mudanças de esquema provém das responsabilidades pela topologia de replicação de dados. A equipe de IEng colabora com a equipe de IdM para assegurar o êxito na replicação das mudanças de esquema em cada floresta gerenciada por ela.

Gerenciamento de Esquemas da Microsoft

O desenvolvimento de software é o que mais contribui para o volume de mudanças de esquemas na Microsoft. Sempre que uma unidade de negócios instala ou atualiza produtos de software que utilizam funções do AD e modifica o esquema, essa unidade deve conduzir o processo de gestão de mudanças de esquema. A TI da Microsoft apóia os esforços de desenvolvimento de cada equipe de produto, realizando o dogfooding do seu software beta no ambiente de produção da Microsoft. O dogfooding complica ainda mais o gerenciamento, pois, muitas vezes, a TI da Microsoft instala várias versões provisórias durante o processo de desenvolvimento, e isso pode aumentar o número de mudanças de esquema.

Sistema de Gestão de Mudanças

A equipe de IdM criou um site interno que conduz através do processo qualquer pessoa que solcite uma mudança de esquema. O site apresenta um panorama do processo, links para informações correlatas e um formulário on-line para mudança de esquema. O solicitante preenche o formulário, que é recebido pela equipe de IdM. A equipe de IdM avalia as justificativas de negócios assim que determinar que o solicitante preencheu corretamente o formulário e que todos os problemas foram resolvidos. Se a mudança for aceitável do ponto de vista dos negócios, a equipe de IdM coloca a solicitação na fila de mudanças. Após aprovar o formulário de solicitação, ela cria um documento de pacote de esquema. O apcote de esquema é um documento dinâmico que acompanha a mudança do início ao fim. A equipe de IdM insere todos os outros dados e todas as outras aprovações em cada etapa do processo. Quando a equipe de IdM faz alterações no esquema, a equipe de IEng acompanha a replicação em todas as florestas, garantindo a precisão. Finalmente, a equipe de IdM coloca o formulário, os scripts e todas as informações correlatas em uma pasta, guardando-a em um local seguro para fins de backup.

Mudanças de Esquema

O sistema do IdM para gestão de mudanças cuida de:

  • Extensões. Na Microsoft, a mudança de esquema mais comum é a extensão. Das três opções de mudança de esquema, a extensão é a mais fácil e representa um impacto potencial menor. A inclusão de novas definições em vez da alteração das definições que já existem elimina a possibilidade de impactos sobre os aplicativos existentes.

  • Modificações. As modificações de esquemas são muito menos comuns que as extensões. Se um objeto existente for alterado, isso pode afetar negativamente os aplicativos dependentes desse objeto. Portanto, a equipe de IdM examina com cuidado todas as mudanças nos objetos existentes do esquema e prossegue apenas se compreender totalmente as conseqüências. Além disso, a Microsoft não considera nenhum atributo fornecido pelo Windows Server System como não utilizado, pois todos eles têm uma finalidade. Portanto, a modificação de definições não utilizadas vale apenas para os atributos personalizados.

  • Desativações. A TI da Microsoft raramente desativa definições não utilizadas. Em vez disso, quando ela não precisa mais de dados de atributos ou objetos, os valores dos atributos ou as instâncias dos objetos são excluídos. Isso ocorre porque os objetos não utilizados do esquema não consomem recursos significativos. Na verdade, a Microsoft projetou o AD especificamente para conter dados esparsos. Além disso, os administradores de esquemas não podem desativar os objetos padrão do esquema do Windows. Eles podem desativar apenas os objetos de esquema personalizados.

Velocidade do AD

As definições não utilizadas do esquema do AD não afetam negativamente a velocidade do AD. As definições do esquema apenas aumentam o tamanho da tabela, assim como ocorre com a inclusão de colunas em um banco de dados. Além disso, as definições de esquemas não aumentam consideravelmente o tamanho do arquivo. Em casos extremos, o problema de velocidade mais perceptível é uma inicialização ligeiramente mais lenta de algumas ferramentas de gerenciamento de esquemas.

Arquitetura do Sistema de Gestão de Mudanças

Devido ao grande número de mudanças de esquema na Microsoft, a implementação de um processo sólido de gestão dessas mudanças tem sido essencial. A TI da Microsoft utiliza o Microsoft Operations Framework (MOF) como base dos seus principais processos de gerenciamento. A equipe de IdM tem adotado o processo de gestão de mudanças definido no MOF para gerenciar as solicitações de mudança de esquema, os testes e a implementação. O site do MOF possui uma ampla documentação sobre o MOF: http://www.microsoft.com/mof.

O sistema de gestão de mudanças de esquema da equipe de IdM consiste em um processo formal, um site interno e um documento de gestão de mudanças. O processo define a gestão de todas as mudanças de esquema na Microsoft. Ele detalha todas as atividades, desde o início de uma solicitação de mudança até o anúncio da conclusão bem-sucedida da mudança. A equipe de IdM fiscaliza esse processo formal, utilizando um site interno Web como ponto de partida para gerenciar todas as mudanças de esquema. O site estabelece expectativas, responde a perguntas freqüentes (FAQs) e dá acesso a um formulário on-line de solicitação de mudanças. Esse documento é a estrutura de um fluxo de trabalho padronizado e fiscaliza o processo formal.

Propriedade do Esquema

Por causa do possível impacto devido à gestão e à modificação de esquemas, a equipe de IdM controla cada mudança de esquema na Microsoft. A equipe gerencia o esquema como uma única entidade, acumulando todas as mudanças de esquema. Isso permite uma compreensão ampla de todos os elementos que o esquema contém no momento e do impacto de outras mudanças.

Essa comprensão inclui:

  • Projeto. A equipe de IdM analisa o projeto de cada elemento do esquema para verificar se ele segue as práticas de esquema definidas. A seção Práticas Recomendadas e Normas da IdM deste documento contém uma lista completa de práticas de esquema definidas.

  • Implementação e Uso. Embora estejam intimamente ligados ao projeto e à propriedade, esses aspectos incluem a maneira como os administradores realizam extensões de esquemas, bem como a metodologia de preenchimento de instâncias de elementos dentro do diretório.  

  • Propriedade. A equipe de IdM acompanha a propriedade dos elementos personalizados dos esquemas para assegurar a disponibilidade de um ponto de contato para qualquer mudança futura capaz de afetar esses elementos.

  • Segurança. A segurança dos elementos dos esquemas deve ser determinada, acompanhada e gerenciada. Cada elemento deve contemplar a propriedade, a delegação de direitos a objetos e a meta mais aimpa de segurança corporativa.

Para manter esse nível de compreensão, a TI da Microsoft restringe à equipe de IdM a autoridade de realizar mudanças de esquema. Como "porteiros", a equipe de IdM garante as boas condições do esquema do AD, gerenciando ativamente todas as mudanças de esquema.

Política de Mudanças

Para fiscalizar as restrições às mudanças de esquema, a TI da Microsoft limita a participação no grupo de administração de esquemas aos membros da equipe de IdM. Além disso, a equipe de IdM concede a participação no grupo de administração de esquemas apenas em caráter temporário, com tempo apenas suficiente para fazer as mudanças aprovadas. Do contrário, o grupo de administração de esquemas permanece vazio.

A equipe de IdM tem a autoridade de estabelecer políticas para garantir que o sistema de gestão de mudanças seja usado, que as normas corretas sejam seguidas e que as expectativas sejam estabelecidas. As mudanças de esquema exigem:

  • Aprovação da IdM. Todas as mudanças de esquema exigem a aprovação da equipe de IdM.

  • Uso do Sistema de Gestão de Mudanças de Esquema. Todas as mudanças de esquema precisam passar pelo serviço de processamento e aprovação de Esquemas do AD da equipe de IdM. 

  • Testes Anteriores. Os solicitantes de mudanças de esquema são responsáveis por testar o funcionamento das mudanças. Isso inclui o método de implementação. A equipe de IdM não levará em consideração as solicitações que não tenham sido adequadamente testadas.

  • Documentação Apropriada. O pré-requisito para envolver a equipe de IdM é documentar o funcionamento e os processos de teste do esquema, inclusive a metodologia de implementação. Os solicitantes devem documentar tudo isso e todas as outras informações necessárias no formulário de solicitação de mudança de equema antes que a equipe de IdM agende o exame inicial.

Infra-Estrutura de Mudanças

A infra-estrutura necessária para gerenciar o sistema de gestão de mudanças de esquema é muito pequena. Ela consiste em um site interno, na equipe de IdM e nos ambientes de teste apropriados.

Site Interno

A equipe de IdM criou um site interno com o Microsoft SharePoint 2003. Esse site oferece uma interface de colaboração entre a equipe de IdM e o pessoal solicitante de mudanças de esquema. Ele é o ponto de partida do sistema de gestão de mudanças. O processo começa quando um solicitante fornece as informações necessárias por meio de um formulário on-line. A equipe de IdM implementa o formulário on-line como uma pesquisa simples no SharePoint. A pesquisa armazena o histórico de solicitações, permite revisões e usa o mecanismo de alerta do SharePoint para alertar a equipe quando ocorrerem mudanças. A equipe de IdM coleta os dados do formulário para criar o documento do pacote de mudanças. Eles mantêm o documento do pacote de mudanças como um documento dinâmico e o incluem em todas as etapas do processo de mudanças de esquema. A equipe mantém os formulários e os documentos do pacote de mudanças em pastas de projeto na biblioteca de documentos do site em SharePoint.

Equipe de IdM

A equipe de IdM recebe e processa as solicitações, examina as mudanças solicitadas, realiza os seus próprios testes, faz as comunicações apropriadas e implementam as mudanças. Isso exige o acesso ao site interno da IdM e ao serviço Microsoft Terminal Server, além do acesso ao DC que hospeda a Operação Flexível de Mestre Único (FSMO) do Esquema-Mestre. Também e necessária uma conta com direitos de Administrador de Esquema e acesso a todos os ambientes de teste necessários. Os tecnólogos seniores realizam todas as mudanças de esquema.

Ambientes de Teste

O solicitante deve testar todas as solicitações de mudanças de esquema antes de enviá-las à equipe de IdM. Então, a equipe de IdM exige dois níveis de testes para cada mudança de esquema. Os testes são progressivos, passando à etapa seguinte apenas após a conclusão da etapa anterior. As fases de teste são o teste de implementação e o teste funcional.

A equipe de IdM realiza os testes de implementação. Primeiramente, eles carregam a mudança de esquema em um ambiente virtual e, em seguida, passam a um ambiente de laboratório. Os testes nesses ambientes detectam problemas de implementação e conflitos de nomenclatura. A equipe de IdM sempre configura o ambiente virtual com uma instalação nova do Windows Server 2003 para verificar se há conflitos de sistema. Esse teste inicial verifica a validade da mudança de esquema. O ambiente de laboratório contém todas as extensões de esquema realizadas na Microsoft para permitir testes de conflitos com extensões personalizadas ou de terceiros. Essa segunda etapa dos testes de implementação determina se o teste funcional deve prosseguir.

A equipe que solicita a mudança de esquema realiza testes funcionais carregando essa mudança em um ambiente piloto. Isso permite que o proprietário do aplicativo teste o seu funcionamento em relação às mudanças. Os ambientes pilotos são florestas limitadas de produção com usuários reais que dependem delas para o seu acesso principal à rede. Isso permite um teste ao vivo do aplicativo em um ambiente de produção limitado. Os proprietários do aplicativo gerenciam o piloto e avaliam o seu êxito.

Gestão de Expectativas

O processo de mudanças de esquema envolve três partes distintas na gestão de uma mudança de esqueama. a parte solicitante, a equipe de IdM e a equipe de IEng. Cada uma dessas partes tem as suas próprias necessidades e responsabilidades, além de expectativas variadas. Entre essas expectativas estão (sem limitação a estas) prazos, resultados, responsabilidades e padrões. Para obter um resultado ideal, o processo de gestão de mudanças gerencia essas diversas expectativas de maneira alinhada, para reduzir ao mínimo a confusão. A equipe de IdM consegue isso garantindo que, desde o início, cada uma das partes compreenda plenamente o projeto. A experiência mostra que uma documentação inicial mais clara e completa otimiza o processo e melhora os resultados. A Microsoft determinou que, para alinhar as expectativas e garantir um resultado ideal, o sistema de gestão de mudanças deve possuir normas e procedimentos claros, expectativas corretamente justificadas e cronogramas comunicados com clareza.

Normas e Procedimentos Claros

Para que as três equipes trabalhem bem juntas, devem ser estabelecidos normas e procedimentos claros logo no início. Essas normas ajudam a eliminar surpresas e permitem que o processo seja conduzido de maneira tranqüila. A equipe de IdM detalha no seu site interno as normas de mudança de esquema. Além de ser um ponto de partida para o processo, o site apresenta instruções, políticas e normas completas. Assim que o solicitante compreender plenamente as normas para realizar uma mudança de esquema, ele prepara um documento e envia a sua solicitação.

Expectativas Corretamente Justificadas

O solicitante deve preparar a documentação exigida e justificar suas metas de forma que sejam pertinentes e atingíveis. Além disso, ele deve detalhar e justificar qualquer desvio em relação às políticas e normas da IdM. O formulário exige uma justificativa tanto técnica quanto de negócios.

A equipe de IdM normalmente não recusa uma solicitação devido a más justificativas técnicas ou de negócios. Como assessores, eles usam essas informações para definir se a meta é atingível e se a solução é ideal. Em caso negativo, a equipe de IdM sugere modificações que melhorem os resultados. Isso elimina mudanças de esquema desnecessárias ou solicitações de mudanças erradas.

Cronogramas Comunicados com Clareza

A equipe de IdM estabelece as expectativas de que todas as mudanças dentro do padrão levarão no mínimo sete semanas desde a solicitação até a implementação, descrevendo o processo no site. As sete semanas incluem três semanas de descoberta e análise e quatro semanas de teste e implantação. A equipe de IdM pode precisar de mais tempo no caso de mudanças complexas.

Vários fatores podem afetar o cronograma padrão de sete semanas. Entretanto, nenhum desses fatores altera os elevados padrões que essas mudanças devem seguir. Esses fatores incluem:

  • Critérios de Emergência. A equipe de IdM concede automaticamente o status prioritário e acelera o cronograma no caso de solicitações que se enquadrem em critérios de emergência estabelecidos. A equipe de IdM publica esses critérios no site de mudanças de esquema.

  • Urgência. Embora a mudança de esquema não se encaixe nos critérios de emergência estabelecidos, a urgência da situação pode exigir a aceleração do cronograma. Por exemplo, o solicitante de um esquema pode precisar estabelecer certos atributos de usuários do AD como "mortos". Isso exigiria o uso de outros atributos de um novo aplicativo global de negócios. Nessa situação, o solicitante pode solicitar a aceleração do cronograma. A equipe de IdM pode aceitar a solicitação, dependendo da sua complexidade, dos recursos à disposição e de outras solicitações prioritárias.

  • Outras Mudanças de Esquema Prioritárias. Normalmente, os membros mais graduados da equipe de um ambiente de TI cuidam das mudanças de esquema. Normalmente, são pessoas muito ocupadas. À exceção de solicitações que atendam a critérios de emergência, os solicitantes devem incluir todas as novas solicitações de mudança de esquema no final da fila existente. Durante períodos de atividade anormalmente intensa, pode ser necessário mais tempo para a conclusão.

    Observação: a equipe de IdM mantém o mesmo padrão elevado em todas as mudanças de esquema, independentemente da complexidade ou da aceleração do cronograma.

Fases do Processo de Mudança

O processo de mudança de esquema tem cinco fases distintas:

  • Descoberta

  • Análise

  • Testes de Implementação

  • Teste de Funcionamento do Aplicativo

  • Implantação em Produção

A próxima seção deste documento descreve detalhadamente as atividades das fases.

Passando Pelas Fases do Processo de Mudança

O gráfico a seguir mostra o fluxo de atividades durante o processo de gestão de mudanças de esquema.

Figura 3. Fluxo de Trabalho de Mudanças de Esquema

Figura 3. Fluxo de Trabalho de Mudanças de Esquema

Em geral, um sistema de gestão de mudanças comunica e acompanha várias mudanças correlatas em diversas áreas da TI. Portanto, é essencial integrar o processo de mudanças de esquema ao sistema de gestão de mudanças da TI da Microsoft, conforme definido pelo MOF, para garantir que as mudanças de esquema não conflitem com outras áreas da TI. Isso é feito por meio do preenchimento de um aviso de controle de mudanças como parte do processo de mudanças de esquema, como mostra a Figura 3. Isso permite que o processo seja simultâneo. Após a aprovação da implantação da mudança de esquema pela equipe de IdM, ela avisa o Conselho Consultivo de Mudanças (CAB) sobre a mudança de esquema, para que este possa gerenciar qualquer conflito de TI que surja durante o restante do processo de mudança de esquema. Como intermediário, o CAB atua como uma assessoria entre os diferentes grupos.

Avaliando o Conhecimento do Solicitante

O solicitante de uma mudança de esquema normalmente representa um grupo de produtos que está desenvolvendo um novo produto, uma unidade de negócios, ou um grupo de infra-estrutura de TI que deseja uma extensão do esquema para permitir o uso de um novo aplicativo. De longe, o maior número de mudanças de esquema na Microsoft vem dos grupos de produtos Exchange e Windows. A equipe de IdM dá opiniões valiosas aos grupos de produtos sobre as suas mudanças de esquema e sobre as opções propostas de implementação.

Por exemplo, a instalação do Microsoft Exchange Server 2003 possui o forestprep.exe para atualizar automaticamente e estender o esquema, criar novos projetos e estabelecer direitos para novos objetos. A equipe de IdM queria estender o esquema separadamente antes que o arquivo de instalação acrescentasse objetos e inserisse os dados no AD. A equipe de IdM pediu ao grupo de produto que oferecesse uma opção de arquivo LDIF, que, então, passou a fazer parte do produto final.

As mudanças de esquema para aplicativos de terceiros são mais difíceis de implementar porque muitos aplicativos têm necessidades ocultas de mudança de esquema. Os aplicativos de terceiros podem estender o esquema por meio de um arquivo .EXE, dificultando a extração das mudanças. Além disso, o arquivo .EXE pode importar um arquivo LDIF apenas durante o processo de instalação. Isso torna o arquivo LDIF difícil de ser obtido para testes.

Por exemplo, a Microsoft precisava de uma extensão de esquema de terceiros para apoiar o sistema de troca unificada de mensagens da Avaya. Isso ativava a troca unificada de mensagens na Microsoft com a integração de correio de voz e do Exchange. O arquivo de instalação continha mudanças de esquema ocultas, levando à falha da instalação devido à insuficiência de direitos.

Enviando uma Solicitaçaõ de Mudança de Esquema

Todas as mudanças de esquema começam no site da IdM. O site está disponível internamente para todos os funcionários da Microsoft. As instruções levam a um formulário de solicitação on-line e a outras informações.

Instruções

As instruções estabelecem expectativas para um tempo mínimo de três semanas de descoberta e análise. Se a solicitação for aprovada pela equipe de IdM, o tempo mínimo para testes e implementação é de mais quatro semanas. Eles podem abrir uma exceção ao cronograma de sete semanas no caso de mudanças de esquema que atendam aos critérios de emergência.

Cc668421.AdSMgT04(pt-br,TechNet.10).gif

Figura 4. Formulário de Solicitação de Mudanças de Esquema

O formulário de solicitação ajuda a equipe de IdM a estabelecer com eficiência as expectativas dos usuários em relação ao nível de conhecimento necessário para implementar uma mudança de esquema. Por exemplo, o solicitante deve fornecer IDs de Objeto (OIDs) corretas e exclusivas antes dos resultados dos testes e dos planos de teste de funcionamento. Além disso, o solicitante deve enviar as solicitações de mudança de esquema na forma de um arquivo de texto LDIF. O formato LDIF mostra claramente cada mudança e inclui a sua fonte oficial.

Solicitações de Emergência

Caso seja necessária uma mudança de esquema de emergência, o diretor da unidade de negócios deve enviar a solicitação e comprovar que ela atende a determinados critérios. Entre os critérios estão a paralização do trabalho, a paralisação dos negócios ou problemas de segurança. A equipe de IdM faz uma recomendação ao diretor da IdM. O diretor da IdM deve aprovar todos os esquemas de emergência antes da implantação. O processo implica a aceleração do cronograma.

Realizando a Descoberta

Após o envio do formulário de solicitação de mudança, um membro da equipe de IdM acompanha a solicitação até a sua conclusão. A primeira tarefa é analisar as justificativas técnicas e de negócios e os detalhes da solicitação. Durante a análise possivelmente prolongada, o membro da equipe de IdM pode devolver o documento de mudança várias vezes para obter mais informações ou para corrigir erros. Quando a solicitação cumprir as normas da IdM, ela será aceita e passará à etapa seguinte.

Justificativas Técnicas e de Negócios

Para eliminar mudanças de esquema desnecessárias ou solicitações de mudanças erradas, a equipe de IdM exige que o solicitante apresente uma justificativa técnica e uma justificativa de negócios.

A justificativa de negócios descreve o valor das mudanças para a unidade de negócios. Ela dá à equipe de IdM o conhecimento dos motivos pelos quais o solicitante deseja as mudanças, além dos prazos em que as mudanças devem ocorrer. Por exemplo, um grupo de produto pode precisar implantar um aplicativo que usa funções do AD no ambiente de produção da Microsoft para receber opiniões antes da sua liberação para fabricação.

A justificativa técnica define especificamente o que as mudanças propostas no esquema devem realizar. A equipe de IdM compara as mudanças solicitadas com o objetivo técnico para ver se ele é atingível e se a solução é ideal.

Embora um grupo de produto se concentre na inclusão de recursos e em garantir um produto, ele depende da TI da Microsoft para testar como o aplicativo afeta um ambiente de trabalho. Às vezes, a equipe de IdM encontra problemas consideráveis no projeto do aplicativo. Por exemplo, a equipe de IdM pode descobrir que o grupo de produto está usando o AD para coletar dados que mudam freqüentemente. Eles podem mudar com tanta freqüência que é provável que mudem outra vez antes que sejam replicados em toda a floresta. Por isso, existe a possibilidade de que haja constantemente dados inválidos em alguns DCs da floresta, eliminando o valor da mudança de esquema.

Analisando a Solicitação de Mudança de Esquema

Assim que a equipe de IdM compreender as justificativas técnicas e de negócios e concordar com elas, o arquivo LDIF será minuciosamente analisado. Eles procuram erros, analisam o projeto e, finalmente, dão a sua opinião ao autor. Se houver problemas, esse ciclo de opinião ajudará o autor a melhorar a solução e reprojetar a solicitação para que ela seja aceita.

Ao analisar um arquivo de esquema, o analista:

  • Observará os novos atributos e as novas classes de objetos exigidas pela mudança de esquema para auxiliar nos testes.

  • Examinará as mudanças no descritor padrão de segurança em busca de excessos de direitos e delegações.

  • Procurará objetos que aumentem a carga de trabalho do sistema, tais como o atributo indexado, a recriação de um conjunto parcial de atributos (PAS), ou um SDProp.

  • Avaliará a gama de possíveis mudanças e verificará se todas elas seguem as práticas Recomendadas do Esquema do AD e as normas da IdM.

  • Verificará cada OID para assegurar-se que ele é exclusivo e está registrado. Isso pode ser feito em: http://asn1.elibel.tm.fr/oid/index.htm.

  • Verificará os elementos do esquema para verificar se existem definições corretas, valores uniformes e descrições significativas.

  • Verificará a uniformidade das convenções de nomenclatura que seguem as normas da Microsoft. Veja o site da Microsoft: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/naming_attributes_and_classes.asp.

A equipe da IdM utiliza um script que automatiza uma grande parte da coleta geral de informações. Quando estiver satisfeito com as informações enviadas, o analista aceitará a solicitação de mudança, desenvolverá um cronograma e passará ao teste de implementação.

Testes de Implementação

Assim que uma solicitação de mudança de esquema for aceita, a equipe de IdM colocará a mudança na fila dos testes de implementação. Por seu projeto, o esquema de floresta varia um pouco entre as florestas da Microsoft. Por exemplo, as florestas mantêm diferentes versões de software da Microsoft para suporte a versões antigas e para desenvolvimento. Em vez de realizar testes separadamente em cada floresta, a equipe de IdM mantém um ambiente de laboratório com um esquema cumulativo que contém todas as extensões de esquemas de todas as florestas. Portanto, com um teste de implementação bem-sucedido nesse ambiente, a equipe de IdM pode identificar conflitos em qualquer floresta antes da implantação.

Carregando o arquivo LDIF no laboratório, a equipe de IdM pode verificar se não há nenhum conflito de OID ou nomenclatura e se o arquivo LDIF é carregado sem problemas. A ativação da opção de registro durante a implementação e a verificação do log em busca de erros confirma isso. A equipe de IdM investiga todos os erros e pode devolver o arquivo LDIF ao solicitante se o arquivo precisar de ajustes. Não deve haver dúvidas de que o arquivo LDIF definitivo será instalado corretamente.

Aprovação da Implantação

Após a equipe de IdM analiasr a solicitação de mudança e testar a implementação, ela pode aprovar ou recusar a implantação. Em caso de aprovação, a equipe de IdM avisa o CAB e passa a solicitação de mudança para os teste funcionais. Em caso de recusa, a equipe de IdM devolve a solicitação de mudança ao solicitante, com uma explicação detalhada da recusa.

Aviso ao Conselho Consultivo de Mudanças

O Conselho Consultivo de Mudanças (CAB) é uma função da TI da Microsoft criada de acordo com o MOF. O CAB é separado da equipe de IdM. O CAB é um grupo multidisciplinar formado para avaliar todas as solicitações de mudança da TI da Microsoft em termos de necessidades de negócios, prioridade, custo x benefícios e impacto potencial sobre outros sistemas ou processos. Em geral, o CAB fará recomendações de implementação, conduzirá análises mais aprofundadas e solicitará adiamentos ou cancelamentos.

Quando a equipe de IdM protocola um aviso de controle de mudança junto ao CAB, este conduz o seu processo simultaneamente à equipe de IdM. O CAB é o ponto de integração com o sistema geral de ocorrências de gestão de mudanças da TI da Microsoft.

O ambiente de TI é extremamente complexo, contendo muitas interdependências, muitas vezes em âmbito global. O CAB determina os efeitos das mudanças sobre sistemas e departamentos interdependentes, e coordena as mudanças entre os departamentos. Ele coordena as mudanças utilizando o sistema de gestão de mudanças da TI da Microsoft simultaneamente com o sistema de gestão de mudanças de esquema. O CAB analisa a solicitação de mudanças para determinar:

  • Autorização. A Autoridade das partes de efetuar mudanças.

  • Interdependências. As mudanças podem afetar muitos grupos diferentes e seus contratos de nível de serviço (SLAs).

  • Conflitos. Tendo um quadro global mais amplo da TI da Microsoft, o CAB pode decidir se é necesário modificar alguma mudança, além de decidir sobre o prazo dessas mudanças, para evitar conflitos.

Após analisar a solicitação de mudança, o CAB a aprova ou a devolve com as recomendações de mudança. Em caso de aprovação, o CAB a inclui no sistema geral de gestão de mudanças com um número de ocorrência e avisa todos os grupos interdependentes por email. O aviso permite que esses grupos tomem as medidas necessárias para evitar conflitos e coordenar as mudanças.

Teste de Funcionamento do Aplicativo

Se o arquivo LDIF for carregado sem problemas no ambiente de laboratório, a etapa seguinte será iniciar o primeiro piloto. O piloto permite que o solicitante realize mais testes de funcionamento conforme o plano de testes de funcionamento. Normalmente, a equipe de IdM utiliza a floresta de desenvolvimento do Windows para iniciar o primeiro piloto. Essa floresta é uma floresta de produção limitada, completa com usuários que utilizam esse ambiente para facilitar o dogfooding. O solicitante normalmente tem uma semana para testar o funcionamento e decidir se as mudanças no esquema funcionaram conforme o esperado. Se os solicitantes tiverem mais uma floresta para realizar os testes, a equipe de IdM dará a oportunidade de um segundo piloto. Ao final de cada fase piloto, o solicitante confirma a conclusão com êxito dos testes de funcionamento. O solicitante pode tentar efetuar pequenos ajustes nas mudanças durante os testes de funcionamento para solucionar pequenos problemas. Entretanto, se o solicitante encontrar algum problema grave, o processo é interrompido e ele precisará retrabalhar as mudanças de esquema.

Implantação em Produção

Assim que os testes de implementação e de funcionamento tiverem sido concluídos com êxito, o arquivo LDIF totalmente analisado e testado estará pronto para ser implantado. Então, a equipe de IdM prossegue com a sua programação de implantação da mudança de esquema. A data e a hora de implantação das mudanças depende das exigências do cronograma, da escala das mudanças, do impacto da replicação e da carga de trabalho das equipes de IdM e IEng no momento. A equipe de IEng deve monitorar o processo de replicação. Com testes adequados, a equipe de IdM carrrgará pequenas mudanças consecutivamente no mesmo dia, mas carregará as mudanças significativas do esquema de maneira isolada, se for possível. A equipe de IdM reserva as noites de sexta-feira (hora oficial do Pacífico - EUA) para as mudanças de esquema, assegurando que a replicação será concluída e que a carga do AD voltará ao normal antes da manhã de segunda-feira na Ásia.

Com o script do processo, a equipe de IdM pode aplicar as mesmas alterações em cada floresta sem intervenção manual. Ela aplica as mudanças em cada floresta consecutivamente para todas as extensões de esquema. Para confirmar a conclusão com êxito do processo de mudança, a equipe de IdM compara o número de mudanças bem-sucedidas (apresentado na parte inferior do arquivo de log) com as mudanças subseqüentes em outras florestas. Se os números não coincidirem, a equipe de IdM analisará os registros. Se ocorrerem erros significativos que aferem a estabilidade do AD, a equipe de IdM poderá precisar trabalhar com a equipe de IEng para iniciar um plano de recuperação.

Após a conclusão com êxito da implantação, a equipe de IdM compacta o script, o arquivo LDIF e o arquivo de log de cada floresta, além do arquivo de erros, se existir. Então, eles incluem os registros no arquivo de histórico de mudanças de todas as mudanças de esquema.

Depois que a equipe de IdM implantar as mudanças nas florestas desejadas, a equipe de IEng monitorará o processo de replicação para verificar se não há nenhum problema de replicação do esquema em cada floresta. A equipe de IEng também é responsável pela recuperaçao em caso de problemas graves. Quando as mudanças de esquema forem replicadas em cada floresta e a equipe de IEng estiver satisfeita com os resultados, ela enviará um email final a todas as partes envolvidas, confirmando a replicação da mudança de esquema com êxito.

Atenuação de Riscos

Para atenuar os riscos das mudanças de esquema, a empresa deve compreender os riscos, determinar as causas e tomar medidxas para eliminá-los ou reduzi-los. Além disso, ela deve preparar um plano de contingência para os problemas que possam ocorrer.

Medição dos Riscos

A TI da Microsoft determina o risco de um evento adverso utilizando tanto o impacto como a probabilidade de uma ocorrência. Os eventos capazes de gerar os impactos mais grabes, tais como uma falha de sistema, são normalmente os primeiros eventos contra os quais a TI da Microsoft se defende com medidas de segurança e redundâncias. Isso inverte a relação entre eventos de alto risco e alto impacto, na qual os efeitos mais nocivos são, muitas vezes, os menos prováveis. Embora seja importante preparar-se para eventos de alto impacto, a gestão de qualquer evento de risco moderado de ocorrência é mais produtiva. A Microsoft recomenda levar em conta cada um dos riscos discutidos a seguir.

Impacto da Replicação: Baixo Impacto, Risco Moderado

A replicação do AD emprega um sistema de prioridades que replica as mudanças de esquema antes de qualquer mudança de dados. Isso pode aumentar o tempo necessário para a convergência dos dados dos diversos DCs. Subseqüentemente, grandes mudanças de esquema podem causar um gargalo de mudanças de dados exigidas por aplicativos que dependem do AD e afetar os que utilizarão os dados. Por exemplo, replicar uma mudança de participação em um grupo por toda a floresta pode demorar mais que a latência normal de 5 horas de uma mudança de esquema. Isso ocorre porque a participação em grupos é replicada após a conclusão da extensão do esquema.

A implementação de um aplicativo significativo que usa funções do AD, tais como o Exchange 2003, gera um grande número de mudanças de esquema, e isso pode exigir mais de um ciclo de replicação por salto para replicar as mudanças de esquema, dependendo da topologia do local da floresta. Normalmente, a equipe de IdM implementa esses tipos de mudanças na noite de sexta-feira para reduzir o impacto sobre a produtividade. Outros atributos que podem aumentar a carga de trabalho de replicação são os atributos indexados, a recriação de um conjunto parcial de atributos (PAS), ou descritores de segurança herdados (SDProp). Às vezes, essas mudanças são necessárias para obter certas funções do sistema, e os administradores não podem evitá-las, mas uma implementação bem projetada pode reduzir os efeitos negativos.

Falha de Aplicativo: Impacto Moderado, Risco Moderado

O AD possui certas funções de aplicativos na floresta, inclusive segurança e acesso ao catálogo global. Além disso, os aplicativos que estendem o esquema do AD têm outras funções personaliadas dependentes do seu acesso ao AD e às suas extensões. A extensões de esquema fornecem as definições usadas pelos aplicativos para criar os objetos de que precisam para funcionar. A perda do acesso ao AD pode fazer com que o aplicativo perca funções específicas ou pare completamente de funcionar.

Uma mudança de esquema mal-implementada pode invalidar elementos existentes necessários para o aplicativo dependente que está causando os problemas. Além disso, uma extensão de esquema mal-implementada pode realizar uma mudança apenas parcial e causar erros de aplicativo ou impedir o funcionamento total de um novo aplicativo.

Falha do sistema: Alto Impacto, Baixo Risco

O AD gerencia o acesso dos recursos à rede e as funções dos aplicativos que usam funções do AD. Portanto, se o AD ficar indisponível, os usuários na floresta perderão o acesso a esse recursos e a certas funções do aplicativo. Entretanto, para que o AD fique indisponível, todos os DCs do domínio precisam deixar de funcionar. A falha de um único DC não afeta o AD em toda a floresta. Esse é um evento de baixo risco porque as falhas de DCs não são freqüentes.

Falhas de hardware ou software podem causar falhas de DC. Para resolver uma falha de DC, é necessário resolver a falha de hardware ou reinstalar o software. Falhas de DC não implicam falhas do AD quando os administradores instalam vários DCs para proporcionar redundância. Entretanto, se o esquema-mestre falhar durante uma mudança de esquema, os administradores devem ter cuidado ao recolocar o servidor novamente on-line para garantir a uniformidade do estado

A corrupção do AD replicado causada por falhas de dados também é muito incomum. Para solucionar uma corrupção do AD replicado, é necessário implementar um plano de recuperação de desastres.

Gestão de Riscos

Compreendendo os riscos, fica claro que duas das principais causas de problemas graves de mudança de esquema são um projeto deficiente e uma implementação deficiente. Problemas de projeto podem aumentar a latência de replicação ou a carga do sistema dos DCs e causar incompatibilidades ou a paralisação de aplicativos. Problemas de implementação podem incluir implementaçoes parciais que obstruem funções ou um ritmo inadequado que leva a latência de replicação além dos limites normais. A latência de replicação pode afetar aplicativos que sentem a latência de maneira intensa. Portanto, para reduzir ou eliminar os riscos, é importante gerenciar o projeto e a implementação das mudanças de esquema. Para isso, a equipe de IdM é a única autorizada a efetuar todas as mudanças de esquema nas florestas gerenciadas pela TI da Microsoft.

Gerenciando os Riscos de Projetos

O sistema de gestão de mudanças de esquema da IdM exige que os solicitantes de mudanças de esquema sigam as instruções específicas de aprovação de mudanças. A equipe de IdM adia mudanças de esquema com projeto questionável até que possa analisar os detalhes técnicos retrabalhados. O sistema de gestão de mudanças gerencia os riscos de projeto, realizando as seguintes funções:

  • Gerenciamento de Documentação. Uma documentação deficiente pode levar a problemas de implementação. Para eliminar esse problema, os solicitantes devem enviar uma documentação padronizada antes do início da análise.

  • Análise de Projetos. A equipe de IdM analisa os projetos de esquemas de acordo com as normas da IdM e devolve solicitações de mudança mal-implementadas ao autor, com comentários e sugestões.

  • Estabelecimento de Padrões. A equipe de IdM aplica um conjunto de padrões elevados e práticas recomendadas que definem uma mudança aceitável de esquema. Esses padrões reduzem o risco de conflitos com objetos de esquema existentes. Eles se concentram no uso de atributos que causam picos de carga de trabalho de replicação. Esses padrões estão na seção Práticas Recomendadas e Normas da IdM neste documento.

  • Responsabilidade de Fornecedores Externos. Os fornecedores nem sempre enviam arquivos LDIF ou os descritores de segurança dos esquemas para a avaliação do projeto ou da segurança. Devido a problemas de compatibilidade, é importante que os administradores examinem com cuidado os descritores de segurança de esquemas de terceiros e adquiram e homologuem as mudanças de esquema documentadas.

Gerenciando Riscos de Implementação

Assim que a mudança de esquema for aceita e projetada, têm início os testes de implementação e funcionamento. Os procedimentos são os seguintes:

  • Scripting do Processo. A equipe de IdM utiliza um script padrão para implementar o arquivo LDIF em todas as florestas, assegurando o uso de parâmetros corretos e uniformes em toda a estrutura. Isso elimina falhas humanas comuns durante o processo de implementação que podem causar mudanças parciais de esquema.

  • Testes de Implementação. testando a implementação do arquivo LDIF em um ambiente de laboratório, os erros e conflitos podem ser descobertos e corrigidos antes da implantação do arquivo em um ambiente de produção.

  • Testes de Funcionamento. Com o piloto das mudanças de esquema em um ambiente limitado, o funcionamento do aplicativo pode ser determinado pelo solicitante. O resultado do piloto determina se a equipe de IdM implementará as mudanças de esquema. Isso elimina o risco de implementar um projeto de esquema defeituoso.

  • Normas de Implementação. A equipe de IdM desenvolveu normas e práticas recomendadas de implementação que reduzem os riscos. Essas normas são as seguintes:

    • Implementação Direta do Esquema-Mestre. A equipe de IdM utiliza o Terminal Server para implementar mudanças de esquema em nível local no esquema-mestre, de forma que a implementação não fique suscetível a problemas de estação de trabalho ou de conectividade de rede. Isso elimina o risco de implementar mudanças parciais de esquema geradas por esses problemas.

    • Considerações sobre o Impacto da Replicação. A equipe de IdM geralmente implementa mudanças de esquema na sexta-feira à noite para permitir que a replicação seja realizada durante o fim de semana. Isso reduz os impactos sobre outros tráfegos de replicação.

    • Confirmação de Replicação com Êxito. A equipe de IEng confirma a replicação da mudança de esquema com êxito em toda a floresta. Isso reduz as chances de que um aplicativo apresente comportamentos inesperados em um ambiente de produção quando a mudança do esquem não tiver sido totalmente replicada.

Planejamento de Recuperação de Desastres

Há vezes em que as mudanças de esquema causam problemas difíceis de resolver. O método preferido de recuperação é modificar o esquema. Entretanto, há vezes em que a modificação do esquema não é uma opção prática. Nesses casos, o administrador deve restaurar o domínio ou a floresta.

A equipe de IEng é responsável pela recuperação de desastres, contando com vários processos para desfazer as mudanças de esquema. Entre elas estão:

  • Backup e Restauração. Para que esse método funcione, a empresa deve realizar backups do estado do sistema de DC a intervalos regulares, verificar se os backups estão em boas condições e executar periodicamente o processo de restauração. A equipe de IEng executa regularmente o processo de restauração, realizando uma restauração mensal extra-oficial para testar o processo, e uma restauração oficial a cada três ou quatro meses para ajudar os usuários que perderam dados. No caso de uma mudança de esquema, é necessário restaurar a floresta. Essa é uma versão ampliada da situação de backup e restauração. A equipe de IEng realiza uma restauração anual da floresta no laboratório para testar o processo. Das duas opções, o "backup e restauração" é o método preferido pela equipe de IEng por ser o mais fácil de realizar.

  • Desconexão do Esquema-Mestre. Retirando o esquema-mestre da rede durante uma mudança de esquema realizada diretamente nele, a equipe de IdM pode verificar o êxito da implementação antes de recolocar o equema-mestre de volta na rede. Portanto, eles podem recuperar o esquema-mestre como um único DC se precisarem desfazer a mudança do esquema. Isso não permite a homologação do aplicativo. Entretanto, garante a instalação correta do esquema.

Práticas Recomendadas e Normas da IdM

A equipe de IdM aprendeu muito com a implantação de mudanças de esquema ao longo dos anos. O volume de mudanças de esquema permitiu o refinamento contínuo do processo da equipe de IdM. A partir desses refinamentos, ela desenvolveu um conjunto de práticas recomendadas e normas para fortalecer o processo e garantir resultados ideais.

Práticas recomendadas

As práticas recomendadas pela TI da Microsoft são as seguintes:

  • Padronize o Processo de Gestão de Mudanças. Um processo de gestão de mudanças bem projetado coloca à disposição da empresa um fluxo de trabalho normalizado que garante resultados ideais. Com o processo implementado, todas as responsabilidades e expectativas ficam claras. O processo deve abranger o fluxo de trabalho completo, desde a primeira solicitação de mudança em um formato aceitável até a determinação de quem comunicará a todas as partes envolvidas que o processo foi concluído com êxito.

  • Estenta o Esquema Separadamente da Instalação do Aplicativo Ao instalar um aplicativo que requer mudanças de esquema, estenda o esquema separadamente da instalação do aplicativo. Usar um arquivo LDIF para estender o esquema é o método preferido devido à quantidade de detalhes sobre as mudanças que ele oferece. A equipe de IdM exige que os grupos de produtos internos e os fornecedores externos apresentem uma opção de LDIF. A equipe de IdM permitirá que a instalação crie objetos, defina permissões e insira dados apenas depois que a extensão separada do esquema for bem-sucedida.

  • Realize Testes Minuciosos Após a Implementação. Teste minuciosamente todas as mudanças de esquema antes de implementá-las em um ambiente de produção. Isso inclui as fases de teste de implementação e teste de funcionamento. Realize os testes de funcionamento de todos os aplicativos desenvolvidos internamente. Talvez os produtos comerciais não exijam testes de funcionamento.

  • Compreenda o Impacto de Cada Mudança de Esquema Sobre o AD. O impacto de uma mudança de esquema é amplo e pode afetar a segurança de objetos, o tipo dos dados publicados no diretório, a indexação do banco de dados do diretório, o custo das atualizações para o diretório, a disponibilidade de dados no catálogo global, e o tamanho do banco de dados do AD. Portanto, antes de estender um esquema em um ambiente de produção, é importante saber como a mudança afetará aspectos do AD tais como segurança, uso dos dados, requisitos de infra-estrutura, replicação e aplicativos dependentes.

  • Faça um Script do Processo. Use um script padronizado para executar todas as mudanças de esquema. Isso permitirá uma execução uniforme. O script executa as mudanças no arquivo LDIF por meio das opções de linha de comando necessárias do ldifde.exe, cuidando de todas as variáveis do arquivo. Isso elimina esquecimentos e garante que todas as mudanças de esquema sigam procedimentos padronizados e gerem resultados uniformes. Um script padronizado oferece:

    • Automação de Nomenclatura de Florestas. Os arquivos LDIF especificam o Nome Distinto (DN) de cada objeto acrescentado ou modificado. Como esse DN precisa conter o componente de domínio da raiz da florestae, ele deve ser alterado com os elementos de DC específicos da floresta de destino. O padrão de-facto para os arquivos LDIF é o uso de DC=X como espaço reservado para os elementos de DC. Usando DC=X no arquivo LDIF, o script determina o contexto de momento do nome de domínio e o substitui por um valor significativo. Isso torna o arquivo LDIF muito portátil, permitindo que o mesmo script seja executado em cada floresta sem que seja necessário modificar manualmente o arquivo LDIF. Isso também elimina problemas de controle de versão.

    • Uso Correto dos Parâmetros de Linha de Comando. O script opera a ferramenta de linha de comando LDIFDE.exe por meio de um conjunto padronizado de parâmetros. Ele usa o parâmetro de comando J para gerar um arquivo de log em texto. O script utiliza o parâmetro de comando C para automatizar as alterações de nome da floresta por meio de localização e substituição. Usando o parâmetro de comando K, se ocorrerem erros no processo de mudança de esquema, o script prosseguirá e não criará os elementos que faltam. Isso também é importante porque, muitas vezes, os administradores acrescentam outras mudanças de esquema no final da mudança de esquema original, por motivo de simplificação. Ao executar o script, as mudanças de esquema duplicadas aparecem como um erro, em vez de causar a falha do script. Ao realizar testes de homologação, é importante ter cuidado ao analisar os logs porque o parâmetro de comando K também continua operando após algum erro de violação de restrições. Verifique se todos os erros registrados têm uma boa explicação.

    • Uniformidade da Floresta. O uso do mesmo script em todas as florestas sem modificações manuais aumenta a uniformidade do esquema entre as florestas. Mudanças manuais no arquivo LDIF podem levar a erros, causando mudanças de esquema apenas parciais.

    • Uniformidade do Processo. Se o processo não for incluído em um script, o operador deverá inserir os parâmetros corretos a cada vez. Isso gera o risco de falha humana. Por exemplo, um operadro não pode criar um arquivo de log após o processo já ter sido executado sem o parâmetro J. Além disso, se o parâmeto K for esquecido, o esquema pode ser modificado apenas parcialmente, exigindo uma investigação do log.

  • Faça as Mudanças Localmente no Esquema-Mestre. Use uma sessão do Terminal Server para realizar o login no esquema-mestre ao realizar mudanças de esquema. Como o Terminal Server executa as mudanças localmente no esquema-mestre, isso reduz a possibilidade de problemas de rede e de cliente capazes de gerar problemas de mudança parcial de esquema.

  • Mantenha um Histórico das Mudanças de Esquema. Guarde cópias de todos os registros pertencientes a cada mudança de esquema. Isso cria um histórico de mudança e um resumo dos resultados, que pode ser pesquisado, se for necessário. Além disso, guardando os arquivos, os administradores podem incluir outras mudanças ao final do arquivo LDIF, simplificando as mudanças futuras. A cada mudança de esquema, a TI da Microsoft compacta o script, o LDIF, o log, e o arquivo de erros de cada floresta.

  • Teste as Mudanças de Esquema Seqüenciais Juntas. Recomendamos enfaticamente que os administradores executem testes seqüenciais específicos antes de implantar mudanças de esquema seqüenciais. Realize as mudanças de esquema individualmente para manter os scripts exclusivos de cada uma.

  • Elimine os Dados Antigos de Objetos de Esquema Desnecessários. Se houver dados não utilizados no AD, será melhor eliminá-los e recuperar os recursos com a criação de um script simples. Isso não apenas libera o espaço dos arquivos, mas também reduz a carga do servidor durante a indexação e a replicação. Finalmente, a limpeza dos dados antigos impede a guarda involuntária e a possível exposição de dados possivelmente confidenciais ou delicados.

Normas de IdM da TI da Microsoft

A equipe de IdM exige que as seguintes normas sejam seguidas em todas as mudanças de esquema. Essas normas asseguram a uniformidade do processo de mudança e geram resultados ideais. As normas são as seguintes:

  • Projeto do Esquema

    • Todos os elementos do esquema exigem um OID válido.

    • Siga as convenções de nomenclatura recomendadas pela Microsoft.

    • Os administradores devem indexar apenas os elementos exclusivos e existentes em grande número.

    • Faça inclusões no conjunto parcial de atributos apenas quando for necessário.

    • O proprietário de um conjunto personalizado de propriedades deve aprovar qualquer mudança nesse conjunto.

    • Um único objeto no AD não deve ser maior que 1MB.

  • Propriedade do Esquema

    • Os proprietários de elementos de esquema devem ser funcionários de tempo integral.

    • No caso de aplicativos desenvolvidos internamente, defina a propriedade de cada elemento do esquema antes da implementação da extensão.

    • Os proprietários são responsáveis por notificar a equipe de IdM sobre elementos de esquema não-utilizados e por "matá-los".

  • Implementação e Uso de Esquemas.

    • Não devem existir elementos de esquema com finalidades idênticas.

    • Faça todas as modificações de esquema por meio de script de LDIF. Quando produtos de terceiros utilizarem executáveis ou um encapsulador de instalação, disponibilize um arquivo LDIF para exame, instalação manual, ou ambos.

    • Arquive todos os arquivos LDIF para consulta futura.

    • Apenas a equipe de IdM poderá implementar mudanças no esquema de qualquer floresta gerenciada da TI da Microsoft.

    • Documente o nível de teste pelo qual passou uma extensão de esquema proposta.

    • Crie um procedimento de implementação para implementar qualquer modificação de esquema que utilize um script de LDIF, executável de programa, encapsulador de instalação, entre outros.

  • Segurança de Esquemas

    • A equipe de IdM presta muita atenção ao mudar o descritor de segurança padrão de elementos de esquema, pois isso afeta a segurança da rede.

  • Preparação de Várias Florestas

    • Para serem uniformes, os esforços também devem ser práticos. A IdM prepara as mudanças de esquema em diferentes florestas para verificar métodos de implementação, identificar conflitos de compatibilidade e assegurar a uniformidade entre as florestas.

Conclusão

A TI da Microsoft recomenda a institucionalização de um processo de mudança de esquema do AD que inclui os marcos de justificativa, avaliação, teste, preparação e implementação. A TI da Microsoft também recomenda a integração do processo de mudança de esquema ao sistema existente de gestão de mudanças para atenuar conflitos e riscos.

A TI da Microsoft deu a um grupo específico a autorização para cuidar de todas as mudanças de esquema e fiscalizar as normas. As normas são explicitamente definidas e fiscalizáveis. O processo de mudança de esquema exige o uso de normas e procedimentos, cria e gerencia adequadamente as expectativas, e comunica os cronogramas de maneira clara.

As mudanças de esquema exigem gerenciamento ativo e podem exigir a cooperação entre algumas equipes interessadas. O processo de mudança de esquema da Microsoft atribui responsabilidades e prevê verificações e equilíbrios entre as partes. Seguindo um processo padronizado e passo-a-passo, elimina-se a confusão e todas as exigências são cumpridas.

Estabelecendo o processo de mudança de esquema, a TI da Microsoft normalizou as mudanças de esquema com um fluxo de trabalho estruturado que fiscaliza as normas da organização e estabelece expectativas sólidas. Agora, o fluxo de trabalho elimina problemas de mudança de esquema logo no início do processo, atribuindo responsabilidades claras a cada parte envolvida. Isso melhora a colaboração entre todas as partes envolvidas e gera resultados pontuais e otimizados.

Para obter mais informações

Para obter mais informações sobre os produtos e serviços da Microsoft nos EUA, ligue para (800) 426-9400. No Canadá, ligue para o Microsoft Canada Information Centre, telefone (800) 563-9048. No Brasil, entre em contato com a Microsoft Informática Ltda., telefone (11) 5853-2345. Para ter acesso às informações por meio da World Wide Web, visite:
http://www.microsoft.com

http://www.microsoft.com/itshowcase

http://www.microsoft.com/technet/itshowcase

Para tirar dúvidas, fazer comentários e sugestões sobre este documento ou para obter informações adicionais sobre Apresentações de TI da Microsoft, envie um email para:
showcase@microsoft.com

Para saber mais sobre a Estrutura de Operações da Microsoft Operations Framework (MOF), visite:
http://www.microsoft.com/mof

Para saber mais sobre o processo de gestão de mudanças do MOF, visite: http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx#EGAA

Para saber mais sobre o processo de gestão de mudanças implementado pela equipe de IdM, visite:
http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx.

As informações contidas neste documento representam o ponto de vista da Microsoft Corporation em relação aos assuntos abordados na data da publicação. Como a Microsoft deve responder às mudanças nas condições de mercado, este material não deve ser interpretado como um compromisso por parte da Microsoft, e a Microsoft não poderá garantir a precisão de qualquer informação apresentada após a data da publicação.

Situação

As mudanças no esquema do Active Directory são freqüentes na Microsoft. Implementar uma mudança de esquema sem planejamento e testes antecipados pode ter conseqüências inesperadas. Portanto, as mudanças requerem um fluxo de trabalho estruturado para assegurar um processo uniforme, tranqüilo e bem-sucedido.

Solução

A Microsoft institucionalizou um processo de gestão de mudança de esquemas que proporciona um fluxo de trabalho uniforme e estruturado. O processo estabelece claramente padrões, expectativas e cronogramas. O processo atenua os riscos e gera resultados ideais de mudança de esquema.

Benefícios

  • Reduz os riscos com a padronização das mudanças de esquema

  • Cria um fluxo de trabalho estruturado

  • Fiscaliza normas organizacionais

  • Estabelece expectativas sólidas

  • Padroniza as comunicações necessárias

Produtos e Tecnologias

  • Microsoft Windows Server 2003

  • Active Directory

  • Microsoft Identity Integration Server 2003 SP1

  • Microsoft SharePoint 2003

  • Microsoft Exchange Server 2003

  • Terminal Server


Download

ADSchema ManagementTWP.doc
275KB
Microsoft Word file

ADSchema ManagementTWPPPT.ppt
275KB
Microsoft PowerPoint file

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft. Todos os direitos reservados.