Post MortemComo migrar do Exchange 5.5

Whitney Roberts

O PROJETO

O Kentucky Department of Education precisava migrar da sua implementação existente do Microsoft® Exchange Server 5.5 para o Exchange Server 2003. O sistema fornece suporte a aproximadamente 600.000 pessoas entre corpo docente, funcionários e estudantes durante o ano escolar.

OS PARTICIPANTES

O projeto foi realizado pelo OET (Office Education Technology) do Kentucky Department of Education, auxiliado pelos consultores de tecnologia da KiZAN. Os funcionários do OET forneceu supervisão de gerenciamento da implementação do Exchange 5.5 existente. A execução diária dos servidores do Exchange era de responsabilidade dos funcionários locais nas escolas.

OS DESAFIOS

O Department of Education fornece orientação técnica para todas as 178 escolas da Comunidade de Kentucky. Essas escolas são conectadas umas às outras através de uma WAN, mas cada uma hospeda seu próprio servidor Exchange 5.5 gerenciado localmente, que precisava ser atualizado separadamente. Essa atualização daria suporte aos clientes do modo cache do Outlook® 2003 e melhoraria o desempenho do OWA (Outlook Web Access), um esquema de endereçamento de email padronizado, e muito mais.

Além de implantar uma nova infra-estrutura de cliente e servidor de email, muitas escolas adicionaram suporte de email para os alunos. A diretiva estadual e federal exigia que as informações dos alunos fossem protegidas e não ficassem visíveis fora da respectiva escola.

O PLANO

Considerando que um ADC (Active Directory® Connector) não poderia ser usado, criamos uma nova organização do Exchange e fizemos a migração para ela. Padronizar os endereços de email significava criar novos endereços, identificando os subdomínios para cada escola e mais de 400 novas diretivas de destinatário. A proteção dos endereços dos alunos exigia a construção de um sistema de GALs (Listas de Endereços Globais) e uma lista de endereços personalizada para cada uma das escolas.

A migração real envolveu preparação de novo hardware, criação e configuração de caixas de correio com base na associação da escola e no tipo de usuário e configuração dos atributos de extensão com base na associação da escola e no tipo de usuário, de forma que o usuário fosse exibido nas listas de endereços apropriadas.

Criamos um aplicativo baseado no Visual Basic® para detectar e corrigir atributos da conta ou associações de grupo mal configurados e para configurar novas caixas de correio adequadamente para verificar se os requisitos foram mantidos. O aplicativo foi implantado para todas as 178 escolas e executado regularmente a partir dos servidores da escola.

Informações gerais

À primeira vista, isso não parece um trabalho desafiador ou tecnicamente difícil. No entanto, conforme eu humildemente descobri, a regra dos requisitos de negócios e os requisitos de negócios deste projeto foram surpreendentes.

Durante anos, o gerenciamento descentralizado e uma mistura de padrões criaram vários "silos" de suporte que tinham que ser gerenciados mais freqüentemente pelo OET. Além disso, o OET também tinha que verificar se a implementação do Exchange 5.5 atendia aos requisitos das escolas e do Department of Education simultaneamente. Isso significava que, para as escolas que utilizavam emails de alunos, as informações dos alunos estavam protegidas e não ficavam visíveis fora da respectiva escola, conforme estabelecido pelas diretrizes estaduais e federais (consulte ed.gov/policy/gen/guid/fpco/ferpa/index.html (em inglês)).

No Exchange 5.5, essas diretrizes significavam que as informações dos alunos dentro da escola não poderiam ser replicadas para outras escolas ou outros órgãos estaduais que compartilhavam os dados da GAL. Especificamente, era necessário passar pelo processo de importação/exportação manual de cada um dos 178 sites do Exchange 5.5: ocultar os alunos, replicar a lista, mostrar os alunos e, finalmente, importar a lista de endereços novamente. Dessa maneira, outras escolas visualizariam apenas os dados dos funcionários e a escola proprietária visualizaria todos os seus próprios dados, mas somente os dados dos funcionários de outras escolas.

Com os pontos fortes e fracos do sistema existente, a atualização da infra-estrutura de mensagens tinha que atender a alguns critérios específicos. Primeiro, o Kentucky Department of Education queria padronizar em um esquema de nomeação SMTP comum e legível para toda a empresa. O esquema precisava fornecer espaços de endereço SMTP separados para corpo docente e alunos.

O novo sistema também precisava fornecer um serviço gerenciado centralmente, que removeria da escola o gerenciamento de mensagens e a responsabilidade pela disponibilidade. Isso significava centralizar o gerenciamento da recuperação do desastre, do fluxo de mensagens e da resolução de chamadas da assistência técnica. Assim, o novo sistema tinha que fornecer um método centralizado para padronização da configuração dos usuários por todas as escolas, independentemente do local geográfico ou da afiliação da escola de um determinado usuário.

Além disso, o novo sistema tinha que fornecer acesso seguro pela Web e por dispositivos móveis a emails através de um namespace comum e unificado para todas as escolas.

Com esses requisitos, muitos dos quais ainda não implementados no sistema Exchange 5.5 existente, a atualização para o Exchange 2003 parecia difícil.

Blocos de construção da solução

Para atender aos requisitos de negócios, várias opções específicas do Exchange foram definidas para a implantação.

Devido à falta de padronização e à amplitude do ambiente do Exchange 5.5, um ADC não poderia ser utilizado. Em vez disso, criamos uma nova organização do Exchange e fizemos a migração para ela.

A limpeza e a padronização dos endereços de email dos funcionários e dos alunos de cada escola levaram à criação de mais de 400 novas diretivas de destinatário. Os requisitos exigiam um subdomínio de identificação exclusivo para cada escola, incluindo uma designação de escola identificadora para os alunos. Por exemplo, no caso do Distrito de Shelby, o subdomínio principal seria shelby.kyschools.us. Os alunos de cada escola receberam uma designação de subdomínio stu., assim os alunos do distrito de Shelby teriam o endereço stu.shelby.kyschools.us.

Outra restrição era que os endereços dos alunos deveriam ficar visíveis somente dentro da escola dos alunos, enquanto os endereços dos funcionários poderiam ficar visíveis em todas as escolas. Isso levou à construção de um sistema elaborado de GALs e de listas de endereços personalizadas, conforme mostrado na Figura 1 e na Figura 2. Uma vantagem de mudar para o Exchange 2003 era que as listas de endereços poderiam ser protegidas com permissões e o acesso a cada lista de endereços individual poderia ser controlado pela associação em grupos. Aproveitamos bem esse recurso e criamos dois grupos de segurança em nível de escola (um para funcionários e outro para alunos). Protegemos os funcionários da escola correspondente, as GALs dos alunos e as listas de endereços, de forma que somente as contas de usuários de dentro de uma escola específica tinham acesso a determinadas listas de endereços. Com a remoção da GAL padrão e das listas de endereços e nos certificando de que os grupos Todos e Usuários autenticados não estavam listados na ACL (lista de controle de acesso) de cada lista de endereços, poderíamos selecionar antecipadamente a lista de endereços que um tipo de usuário específico, em uma escola específica, poderia visualizar.

Figura 1** Listas de endereços personalizadas com base na função **(Clique na imagem para aumentar a exibição)

As permissões, no entanto, somente resolveram uma parte do problema de visibilidade. Tivemos que descobrir uma forma de controlar quem ficava visível e em qual lista de endereços. Foi criada uma consulta de protocolo LDAP base, que permitia a consulta da visibilidade de funcionários e alunos. A consulta foi personalizada para cada lista de endereços e GAL. Por exemplo, a consulta LDAP à GAL dos funcionários de Shelby mostraria somente os funcionários e os alunos apropriados em Shelby e todos dos funcionários (mas nenhum aluno) de cada escola do estado. A GAL dos alunos de Shelby mostraria somente os funcionários e os alunos de Shelby e nenhum outro funcionário ou aluno de qualquer outra escola do estado. Repetimos essa consulta para todas escolas da organização. A Figura 3 mostra exemplos de algumas consultas LDAP usadas nesta migração complexa.

Figure 3 Consultas LDAP da lista de endereços

Consulta LDAP da GAL dos funcionários

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14))))) 

Consulta LDAP da lista de endereços da escola

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))

Consulta LDAP da lista de endereços dos alunos da escola

(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))

Consulta LDAP da lista de endereços offline dos funcionários da escola

(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))

Figura 2** Listas de endereços globais separando os funcionários e os alunos **(Clique na imagem para aumentar a exibição)

Os valores personalizados para extensionAttribute14 (Atributo personalizado 14) e extensionAttribute15 (Atributo personalizado 15) das propriedades dos usuários do Exchange foram os mecanismos de distinção das consultas LDAP. Todos os funcionários e alunos de todo o estado utilizaram um valor específico para extensionAttribute14 para designar o tipo de usuário e um valor exclusivo no extensionAttribute15 para mostrar a afiliação da escola. Com a utilização de valores exclusivos para cada escola e os mesmos valores para cada tipo de usuário, as listas de endereços foram capazes de mostrar exatamente as informações necessárias para cada tipo de usuário em cada escola.

Essas listas de endereços funcionaram um pouco melhor para os usuários que acessaram emails pelo Outlook no modo não cache ou por meio o OWA. (Direcionamos cada usuário para a lista de endereços correta no OWA, utilizando o atributo msExchQueryBaseDN.) Mas os usuários que estavam executando o Outlook no modo cache apresentaram outro problema. Como o Outlook não distingue uma GAL personalizada como OAB (Catálogo de Endereços Offline), tivemos que criar listas de endereços adicionais que foram duplicadas das GALs. Cada armazenamento de caixa de correio da escola foi configurado com a lista de endereços OAB apropriada para seus usuários do modo cache. Enfim, essa solução atingiu mais de 1.500 listas de endereços para fornecer a funcionalidade total a vários tipos de usuários por todas as 178 escolas.

Como garantir a conformidade

Para verificar se a estrutura que estava sendo utilizada funcionaria corretamente, a aderência aos padrões estabelecidos mais recentemente era fundamental. Havia várias tarefas de alto nível que tinham que ocorrer para cada usuário habilitado para Exchange na organização. O motivo para isso é que cada usuário precisava ser localizado corretamente por todos os servidores Exchange da escola, bem como ficar visível nas listas de endereços corretas.

O usuário precisava ser membro do grupo de segurança adequado dentro do domínio da escola, pois o grupo de segurança concedia permissões para abrir a lista de endereços apropriada. O usuário também precisava que o atributo msExchQuerybaseDN fosse definido corretamente, com base na associação da escola ou na OU (unidade organizacional). A OU do usuário determinava o tipo de usuário.

A próxima etapa era criar a caixa de correio do usuário no armazenamento correto do servidor apropriado, com base na associação da escola e no tipo de usuário. Isso afetou os níveis de serviço, os limites de tamanho da caixa de correio e as listas de endereços do catálogo de endereços offline, de forma que o modo armazenado em cache do Outlook funcionasse corretamente. Os atributos de extensão foram configurados com base na associação da escola e no tipo de usuário, de forma que o usuário fosse exibido nas listas de endereços apropriadas e não ficasse visível em outras.

Finalmente, precisávamos fornecer uma forma de corrigir automaticamente todos os atributos da conta ou associações em grupos, se eles estivessem mal configurados (ou alterados) com valores inadequados. Se um usuário fosse movido de uma OU para outra dentro do domínio da escola, isso significava que uma alteração da classificação do usuário, o local da caixa de correio, a seleção da GAL e a visibilidade da lista de endereços deveriam ser alteradas.

Precisávamos de um sistema de configuração que realizasse essas tarefas e garantisse a consistência e a precisão do Active Directory. Criamos um aplicativo de console baseado no Visual Basic que é executado regularmente a partir dos servidores Exchange 2003 da escola. O aplicativo, que verifica a aderência aos padrões e às diretivas e também trata da criação e da configuração de novos objetos, foi implantado em todas as 178 escolas.

Sentimos que as tarefas eram muito complexas para que uma série de scripts as executasse de forma rápida e confiável. Como resultado, o aplicativo baseado no Visual Basic foi visto como a solução mais apropriada, pois era eficiente, tinha suporte estruturado a tratamento de exceções e erros e seu código interno poderia facilmente ser adaptado ao código de extensão MIIS (Microsoft Identity Integration Server) no futuro, com o mínimo de recodificação.

Como estávamos migrando para uma nova organização, era necessário encontrar alguns métodos de coexistência. Havia mais de 178 domínios SMTP herdados para suportar no novo ambiente - algumas escolas já tinham domínios de emails de alunos e outras não tinham - mas tínhamos a vantagem de migrar as escolas uma de cada vez e trazer seus endereços e mensagens herdadas para o novo sistema, sem afetar as outras escolas. No entanto, precisávamos evitar a interrupção do fluxo de emails, pois a escola foi migrada do Exchange 5.5 para o Exchange 2003. Isso significava a implementação de algum tipo de sincronização de diretório entre o Active Directory do Exchange 2003 e o diretório herdado do Exchange 5.5. A Microsoft concedeu uso limitado de MIIS ao Kentucky Department of Education apenas durante a migração, assim, um código de extensão personalizado foi desenvolvido e usado para sincronizar as organizações do Exchange através do MIIS antes, durante e após a migração.

A mudança para uma nova organização do Exchange naturalmente afeta a configuração do cliente MAPI. O Department of Education se deparou com o fato de que havia literalmente dezenas de perfis MAPI, em nível de escola, que teriam que ser reconfigurados durante a migração. Felizmente, a Microsoft lançou o Exchange Profile Tool (ExProfRe.exe), que foi usado para migração do perfil nas escolas. Criamos um instalador empacotado que executava a ExProfRe.exe com valores pré-carregados, de forma que as migrações do perfil em nível de escola poderiam ser executadas em um modo automatizado. O programa foi chamado através da Diretiva de Grupo. Atingimos quase 100% de sucesso nas migrações de perfil automatizadas entre as organizações.

Atualizações de hardware

Considerando que os servidores Exchange 2003 substituiriam os servidores Exchange 5.5 dispersos geograficamente, o aspecto do hardware desta solução tinha que suportar o mesmo número de usuários que a implantação do Exchange 5.5, mais a carga de contas adicionais dos alunos. Os servidores teriam que ser hospedados localmente na escola, pois a topologia WAN foi projetada de forma que todo o tráfego entre as escolas (Internet e interno) fluísse por uma linha T1 privada (em algumas escolas, por várias linhas T1).

Devido às restrições orçamentárias, de hospedagem de equipamentos e de gerenciamento, os servidores Exchange não teriam armazenamento conectado do tipo SAN (rede de área de armazenamento), portanto, todo o armazenamento tinha que ser conectado interna ou diretamente. Como muitas escolas não tinham centros de dados com armazenamento em rack e resfriamento centralizado, os servidores tinham que ficar autocontidos o máximo possível. Felizmente, a maioria das escolas tinha menos de 5.000 usuários, ou seja, eram possíveis as implantações com um só servidor. Para as escolas que tinham mais usuários, foram utilizados servidores mais avançados (ou vários servidores) e sistemas de armazenamento adicionais, às vezes com servidores front-end para melhorar e separar ainda mais o tráfego dos alunos e o tráfego dos funcionários.

Na maioria das escolas conseguimos implantar servidores biprocessados e bem equipados que foram configurados com o número máximo de unidades Ultra320 SCSI de 15.000 RPM, múltiplos controladores RAID e 4GB de RAM. As escolas maiores receberam um ou mais servidores com quatro processadores, usando servidores front-end menores, quando necessário. Testes de benchmark e de desempenho antes da implantação indicaram nenhum problema de uso ou de carga. No entanto, os diversos níveis de uso local, no entanto, seriam o fator que realmente determinaria o desempenho geral do servidor.

Teste de verificação do conceito

Embora o ambiente de produção possua uma floresta de 178 domínios do Active Directory, o laboratório POC (Verificação do conceito) foi reduzido para 13 domínios da escola e um domínio-raiz vazio. Todos os domínios de teste foram populados com exportações dos domínios de produção. Servidores Exchange 5.5 virtuais foram criados e configurados com cópias dos bancos de dados das escolas selecionadas para que pudéssemos testar o processo de migração e nos basear no ambiente planejado. O laboratório de teste POC completo foi construído com máquinas virtuais para que o ambiente pudesse ser comparado, congelado e reimplantado, quando necessário.

Uma combinação diversa de scripts (usando VBScript), pacotes do instalador SMS (Systems Management Server) e aplicativos de console foi criada, codificada, testada e finalizada. No fim, tínhamos scripts que executavam a configuração inicial do Exchange 2003, incluindo diretivas de destinatário, GALs e listas de endereços personalizadas e permissões. Os scripts também tratavam da configuração do grupo administrativo, da configuração do domínio da escola (criação do grupo de segurança e delegação de permissões) e da configuração pós-implantação para migração.

A preparação dos servidores Exchange 2003 apresentou alguns desafios significativos. Precisávamos que todos os servidores Exchange fossem instalados com êxito em todos os 178 domínios e tínhamos que fazer isso sem prejudicar o restante da migração. O Exchange 2003 difere do Exchange 2000, pois o grupo dos Servidores de Domínio do Exchange específico só é adicionado à ACL da organização depois que o primeiro servidor Exchange 2003 é instalado no domínio. (No Exchange 2000, o grupo é adicionado ao executar o processo DomainPrep.) Para verificar se tínhamos todos os grupos de segurança necessários listados no objeto da organização do Active Directory, precisávamos fazer a instalação em um determinado domínio, replicar manualmente o Active Directory do domínio para o site de hub de replicação do Active Directory e passar essa replicação para a próxima escola a ser instalada. Somente depois que confirmávamos que a ACL no objeto de organização tinha o grupo Servidores de Domínio do Exchange da escola anterior, a instalação da próxima escola poderia começar de forma segura. Se esse processo fosse concluído com problemas, mesmo um só domínio, a escola teria que ser reinstalada (no mínimo) ou as outras escolas não seriam capazes de estabelecer comunicação entre as escolas, devido a uma ACL do objeto da organização que não listou todas as outras escolas corretamente.

Testamos a implantação completa, a configuração, a preparação do servidor e a migração várias vezes, até nos certificarmos de que o processo funcionava bem dentro do ambiente POC.

Problemas de migração e de crescimento

Depois que os procedimentos POC e os resultados foram aprovados pela equipe do projeto, a migração estava pronta para começar. O OET optou por fazer a migração primeiro, de forma que eles pudessem experimentar o processo e os efeitos posteriores em primeira mão. No momento da migração, todos os servidores já tinham sido preparados e o ambiente inicial tinha sido verificado. Todos os servidores do protocolo front-end e os servidores da caixa de correio estavam instalados e prontos para entrar em produção com os usuários.

A execução do plano de migração ocorreu bem e, após longas 21 horas para transferir o conteúdo de um servidor para outro, o OET estava ativo e funcionando no Exchange 2003. Felizmente, não houve problemas significativos com a migração dos perfis do Outlook do Exchange 5.5 para o Exchange 2003. Empacotamos um arquivo de lote que chamava o programa ExProfRe.exe em diferentes configurações, com base em uma lógica simples. Distribuímos o arquivo de lote e o ExProfRe.exe para o compartilhamento Netlogon de um DC (controlador de domínio) em cada escola e usamos a Diretiva de Grupo para executar o lote para todos os clientes, na conclusão de uma migração. Isso funcionou bem no OET e ficamos confiantes em relação ao avanço do processo.

Neste ponto, o plano de migração foi revisado e aprovado novamente com base em nossa experiência com a implantação do OET. Continuando com a migração, escolhemos seis escolas para serem os primeiros sites de produção. Antes de cada escola ser migrada, o MIIS lia as últimas informações sobre as caixas de correio da escola do Exchange 5.5 e atualizava os usuários correspondentes no domínio da escola. Usamos o Assistente de Migração do Exchange (Mailmig.exe) para mover realmente os dados de caixas de correio entre as organizações. À medida que o assistente movia os dados de caixas de correio, todos os endereços proxy eram copiados e atualizados a partir do que o MIIS havia originalmente exportado para o Active Directory. Durante a migração, os emails eram colocados em fila nos servidores SMTP front-end e liberados para a escola após a conclusão da migração, da configuração do servidor pós-migração e do teste de usuários. A escola foi preparada para executar a migração de clientes em grande escala usando o ExProfRe.exe.

Discutindo o RUS

Para que os clientes Outlook funcionassem corretamente, precisávamos garantir que a solução de configuração era a autoridade mais importante na configuração dos valores de atributos. Também precisávamos que o RUS (Serviço de Atualização de Destinatário) finalizasse o trabalho, por assim dizer, de configuração de contas, mas o RUS deveria ser executado somente após a conclusão da configuração. Para conseguirmos isso, as instâncias do RUS das escolas (todas as 178) foram definidas para Nunca em suas programações e a solução de configuração usou um código que disparou o RUS para ser iniciado após a configuração ser concluída.

A maioria das escolas tinham menos de 5.000 usuários e muito menos atualizações diariamente, portanto, o RUS terminou rapidamente devido ao sistema de configuração ter iniciado uma atualização, em vez de ter recriado no fim de sua execução diária. No entanto, havia muitas escolas com mais de 10.000 usuários. As atualizações nesses ambientes consumiu mais tempo e, se uma recriação de RUS completa fosse necessária nesses domínios maiores, ela poderia ser executada durante uma semana ou mais. Considerando que o RUS avalia todos os tipos de objeto quando é executado, o efeito de fazer uma recriação em um domínio tão grande era impactante.

Apesar de não termos conseguido definir uma estratégia de mitigação (e trabalhamos com membros do grupo de produtos do Exchange para tentar descobrir uma solução), aperfeiçoamos o código de configuração para tratar grande parte do que o RUS normalmente faz. Os atributos showInAddressBook e proxyAddresses dos usários eram populados durante a configuração inicial, de forma que os usuários pudessem efetuar logon imediatamente, em vez de aguardar o RUS concluir seu trabalho. Também criamos uma tarefa manual que é executada em um dos servidores de protocolo Exchange 2003 front-end. Ela faz uma importação LDIFDE temporizada e limpa o endereço gatewayProxy do RUS. Dessa forma, se a diretiva do destinatário for aplicada acidentalmente no ambiente, ela não será colocada na lista de tarefas de cada RUS na empresa.

Problemas do categorizador

Um aspecto interessante de impedir que os dados dos alunos fossem acessados fora da escola foi implementar controles para evitar que os alunos enviassem emails a usuários de fora da própria escola ou endereços da Internet fora do sistema. Em vez de trabalhar com um sistema elaborado de conectores e itens relacionados, decidimos implementar um recurso menos conhecido do Exchange 2003 e usar as restrições de conector no Conector de Grupos de Roteamento existente da escola para o hub central onde os servidores de protocolo front-end residem. Dois grupos de segurança foram criados em cada domínio – um para os funcionários e um para os alunos – e esses grupos foram adicionados às restrições do conector.

Depois que habilitamos a verificação de restrição do conector no Registro, começamos a observar alguns problemas de desempenho. As mensagens ficavam presas no categorizador e nas filas de entrega local durante horas, mesmo as mensagens destinadas aos destinatários do mesmo servidor. Esses problemas pioraram ao longo do tempo, conforme escolas adicionais foram migradas. Como uma solução de curto prazo, desativamos a verificação de restrição do conector e o desempenho de entrega de emails melhorou. Além disso, a inspeção revelou que o categorizador estava verificando não apenas as associações do grupo de dois grupos dentro de seu próprio domínio até o envio da mensagem, mas também as associações do grupo dos mesmos dois grupos em outros 177 domínios. Isso era feito para todas as mensagens que entravam ou saíam do servidor.

Posteriormente, abrimos um caso de suporte com a Microsoft. Após avaliação, a Microsoft está atualmente no processo de geração de um hotfix para minimizar o problema, permitindo que o categorizador trabalhe em um modo de complexidade de topologia reduzido. Outros detalhes sobre o hotfix não estão disponíveis, mas a meta é fornecer uma configuração que permita que o categorizador faça determinadas suposições sobre a topologia de roteamento e não verifique a associação de grupo através de todos os conectores.

Lições aprendidas

Se há uma coisa que aprendi com este projeto, é que os requisitos de negócios determinam tudo o que fazemos como consultores. Houve muitas situações em que a capacidade de o requisito de negócios ser posto em prática teve que ser avaliada de acordo com a complexidade da solução. As decisões e as escolhas que descrevi nesta coluna são as que achamos mais apropriadas, considerando nosso ambiente (incluindo elementos que não tive tempo de discutir aqui), nossos recursos e nossos requisitos de negócios. Para você, as decisões podem ser diferentes, mas espero que esta coluna tenha fornecido alguns conceitos para que você possa refletir. Felizmente, para nós, o Exchange 2003 e o Active Directory permitiram muita flexibilidade para atender a todas as necessidades nesta migração complexa. Depois que passamos pelo choque inicial da implantação do Kentucky Department of Education, a solução real é relativamente simples e nos baseamos no que achamos serem recursos subutilizados do Active Directory e do Exchange 2003.

A segunda lição valiosa foi praticar uma abordagem estável para solução de problemas e gerenciamento de risco/problema. Há situações em que a solução de problemas local é apropriada e outras em que é necessário buscar recursos avançados do Atendimento Microsoft.

Olhando para o futuro

O ambiente do Kentucky Department of Education é seguramente exclusivo. Durante esta implantação, quase todos os recursos do Exchange foram utilizados ou personalizados para satisfazer às necessidades do departamento. Agora que todo o ambiente foi implantado e migrado com sucesso, o campo está preparado para a implementação de funcionalidades adicionais. O Department of Education já percebe o interesse das escolas na plataforma Windows Mobile® e espera que a onda de dispositivos móveis continue.

Há um valor significante a ser obtido da consolidação de servidores. O Kentucky Department of Education atualmente está procurando virtualizar alguns aspectos do ambiente do Active Directory. Tendo em vista o Exchange 2007, o departamento começou a verificar as necessidades de uma atualização de seus sistemas de mensagens.

O Kentucky Department of Education também está verificando ofertas de colaboração adicionais no Live Communication Server, Live Meeting Server etc. O Microsoft Operations Manager 2005 também está em implantação para gerenciamento e monitoramento dos servidores Exchange e Active Directory.

Os resultados

Cada aluno no sistema de escolas públicas de Kentucky será afetado pela qualidade e influência dessa implementação, incluindo meus próprios filhos e os filhos de pessoas com quem trabalhei neste projeto. Esta implementação levou o Kentucky Department of Education a avançar em tecnologia e de uma forma padronizada e segura. Estou orgulhoso de fazer parte desta realização.

Whitney Roberts é o consultor principal da KiZAN Technologies (www.kizan.com (em inglês)) e está trabalhando com o Exchange desde o lançamento do Exchange 4.0.

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