Perguntas e respostas do ExchangeOutlook em Qualquer Lugar e IPv6, Remote Connectivity Analyzer e mais
Henrik Walther
P Acabamos de implantar o Exchange 2007 em servidores baseados no Windows Server 2008 na nossa organização, e as coisas estão funcionando muito bem, com uma exceção. Embora tenhamos configurado o Outlook em Qualquer Lugar (anteriormente conhecido como RPC sobre HTTP), seguindo a orientação da documentação do Exchange 2007 no Microsoft TechNet, não conseguimos nos conectar aos servidores Acesso para Cliente do Exchange 2007 de um cliente do Outlook 2007 na Internet, independentemente do que tentamos. Nós nos certificamos de que o certificado SAN é confiável pelo cliente e que a porta TCP 443 está aberta no firewall conectado aos servidores Acesso para Cliente. Você já viu esse tipo de problema?
R Na verdade, sim. Você mencionou que o Exchange 2007 estava instalado em servidores baseados no Windows Server 2008. Quando um servidor Acesso para Cliente tiver sido instalado em um servidor Windows Server 2008, é importante ter em mente que o Outlook em Qualquer Lugar não funcionará adequadamente se IPv6 estiver habilitado no servidor. Como o IPv6 é habilitado por padrão quando o Exchange 2007 SP1 está instalado no Windows Server 2008, você deve certificar-se de desabilitá-lo. Vi vários casos em que isso resolveu o problema.
Para obter mais informações sobre por que o Outlook em Qualquer Lugar e o IPv6 no Windows Server 2008 formam uma mistura ruim e sobre como você desabilita o IPv6 adequadamente em servidores Windows 2008, sem quebrar o Exchange 2007, recomendo que você consulte a postagem do blog da equipe do Exchange na Microsoft encontrado em msexchangeteam.com/archive/2008/06/20/449053.aspx. Esse problema deve ser corrigido com o Pacote Cumulativo de Atualizações 4 do Exchange 2007 SP1.
P Estou implementando no momento o Outlook em Qualquer Lugar e o Exchange ActiveSync no nosso ambiente de mensagens baseado no Exchange 2007 e estava pensando se, de alguma forma, é possível testar se o Outlook em Qualquer Lugar funcionará como esperado no outro lado de nossa rede de perímetro. Além disso, quero me certificar de que o serviço Descoberta Automática tenha sido configurado adequadamente em nosso ambiente. Você pode me dar algumas sugestões?
R Sim, é possível testar se o Outlook em Qualquer Lugar está funcionando corretamente. Dois funcionários da Microsoft (Shawn McGrath, do grupo de produtos Exchange, e Brad Hughes, dos serviços de suporte a produtos) criaram uma ferramenta baseada na Web chamada ExRCA (Exchange Server Remote Connectivity Analyzer). A ferramenta (na Figura 1) deve ainda ser considerada um protótipo, mas eu não enfrentei nenhum bug ou comportamento estranho qualquer que seja. A ferramenta pode executar a Descoberta Automática do Outlook 2007 e os testes de conectividade do RPC/HTTP; ela também pode testar se o Exchange ActiveSync e o fluxo de email SMTP de entrada funcionam como esperado. Embora o ExRCA não seja suportado no momento pela Microsoft, eu altamente o recomendo para qualquer teste de conectividade remota em relação ao Exchange 2007.
Figura 1 Página inicial do Exchange Server Remote Connectivity Analyzer (clique na imagem para ampliá-la)
P Nossa organização, que usa o Exchange Server 2007, está nos estágios de planejamento da implantação do SCR (replicação contínua em espera). Queremos ter, em outro site, um segundo conjunto de dados para cada um dos bancos de dados de caixa de correio criados em nossos servidores de Caixas de Correio Exchange 2007 SP1 não-clusterizados. Temos lido muito sobre o SCR na documentação do Exchange 2007 no Microsoft TechNet, mas ainda existe uma pergunta que não conseguimos responder: se ativarmos um destino de SCR, isso terá o mesmo efeito de Mover Caixa de Correio com o parâmetro –ConfigurationOnly especificado para as caixas de correio de todos os usuários em um banco de dados particular de caixa de correio? Em outras palavras, apenas alterar o local do servidor Exchange no Active Directory.
R Como você está usando servidores de Caixas de Correio não-clusterizados (anteriormente conhecidos como um servidor de Caixa de Correio autônomo) como servidores SCR de origem, sua interpretação está correta. Como você estará ativando a cópia de SCR em um servidor diferente, a portabilidade do banco de dados será usada. Isso significa que o local do servidor Exchange no Active Directory para as caixas de correio do usuário no respectivo banco de dados de caixa de correio será alterado.
Se os servidores SCR de origem no seu ambiente do Exchange 2007 eram baseados em CCR (replicação contínua agrupada) ou em SCC (cluster de cópia única), e você usou um nó passivo em um cluster de failover como o destino de SCR, você ativaria o destino de SCR com o mesmo nome e o local do Exchange Server no Active Directory não seria alterado.
P Acabamos de implantar o Exchange Server 2007 no nosso ambiente empresarial e gostaríamos de saber se há suporte para mover os seis grupos de segurança do Exchange 2007, que foram criados pela instalação do Exchange 2007 quando a floresta e os domínios estiverem preparados para a instalação do Exchange 2007, para outra OU (unidade organizacional) em vez da OU dos grupos de segurança do Microsoft Exchange, criada no domínio raiz.
R Diferentemente do Exchange 2000/2003, que não permitia que você movesse os grupos do Exchange para outra OU na floresta, o Exchange 2007 realmente suporta isso. Você pode ver que os seis grupos de segurança do Exchange 2007 (consulte a Figura 2), criados quando a floresta está preparada para o Exchange 2007, estão marcados com duas propriedades únicas; a primeira é uma GUID bem conhecida e a segunda é um nome distinto que pode ser alterado.
Figura 2 Grupos de segurança do Exchange Server 2007 (clique na imagem para ampliá-la)
Essas duas propriedades e o fato de que são adicionadas ao atributo OtherWellKnownObjects da respectiva floresta quando a instalação é executada, garantem se o Exchange poderá encontrar os grupos de segurança em qualquer lugar da floresta. Então, você pode ir em frente e mover os grupos para o lugar que desejar, mesmo para outro domínio da floresta! Detalhes adicionais podem ser encontrados nas excelentes Perguntas Freqüentes sobre permissões do Exchange 2007 de Ross Smith (technet.microsoft.com/bb310792), incluídas na documentação do Exchange 2007 no Microsoft TechNet.
P Devido a uma reestruturação no nosso ambiente de mensagens baseado no Exchange 2007, queremos mover a testemunha de compartilhamento de arquivos para cada um dos nossos servidores de Caixa de Correio CCR do Exchange 2007 para outro servidor de Transporte de Hub. Você pode fornecer uma orientação sobre como isso é realizado de uma forma suportada?
R Mover a testemunha de compartilhamento de arquivos de um servidor de Transporte de Hub do Exchange 2007 para outro é muito simples. Você simplesmente usa as etapas que seguiu quando configurou inicialmente a testemunha de compartilhamento de arquivos para seus servidores de Caixa de Correio clusterizados. A única diferença é o caminho que você especifica para o servidor. As etapas apropriadas podem ser encontradas na seção Como configurar a testemunha de compartilhamento de arquivos na documentação do Exchange 2007 no Microsoft TechNet (consulte technet.microsoft.com/bb124922).
A propósito, você deveria saber que se usou um registro CNAME para apontar para o seu servidor de Transporte de Hub quando configurou a testemunha de compartilhamento de arquivos, a tarefa seria simplesmente uma questão de você alterar o FQDN (nome de domínio totalmente qualificado) do host de destino ao qual o alias no registro CNAME respectivo aponta (consulte a Figura 3).
Figura 3 Registro CNAME apontando na direção de um host de destino para uma testemunha de compartilhamento de arquivos (clique na imagem para ampliá-la)
Tenha em mente, no entanto, que se você possuir nós de cluster em lugares diferentes, a orientação de resiliência local do grupo de produtos Exchange foi alterada (consulte msexchangeteam.com/archive/2008/04/03/448615.aspx). Basicamente, o grupo de produtos Exchange não recomenda mais que você use registros CNAME em ambientes Geo-Cluster do Exchange 2007.
P Estamos planejando melhorar as configurações de segurança para os servidores de mensagens do Exchange 2007 na nossa organização. Parte do nosso plano de otimização de segurança é criptografar os volumes nos quais os bancos de dados do Exchange estão localizados. Gostaríamos de saber se é recomendado ou, até mesmo, suportado armazenar arquivos do banco de dados do Exchange em um volume que tenha sido criptografado usando a criptografia EFS (Encrypting File System).
R A resposta é um claro não. Colocar bancos de dados do Exchange 2007 em um volume criptografado com base em EFS não é suportado pela Microsoft. Na verdade, isso não é suportado para arquivos .edb, .log, .stm (Exchange 2000/2003), .dat, .eml e .chk. A principal razão é que esse tipo de resultado de criptografia resulta em uma sobrecarga adicional, que afeta significativamente o desempenho.
Para ajudar a proteger mais os arquivos de dados do Exchange 2007, você deve impedir o acesso não-autorizado ao computador do Exchange e usar o formato de mensagem S/MIME para criptografar dados de mensagens. Além disso, se você instalar o Exchange 2007 no Windows Server 2008, pense em usar o BitLocker para proteger os volumes.
P Acabei de instalar o Exchange 2007 SP1 em um servidor Windows Server 2008 que também é um controlador de domínio. Como não uso o IPv6 neste ambiente, eu o desabilitei em Conexões de Rede após a instalação do Exchange 2007 SP1 e, em seguida, reinicializei o servidor. Quando ele voltou online, os serviços do Exchange 2007 não foram mais iniciados. O erro 214, conectado no log do aplicativo, contém as seguintes informações:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).
R Já vi vários relatórios sobre esse comportamento. Embora não seja uma prática recomendável instalar nenhuma das funções do servidor Exchange 2007 em um servidor Windows Server 2008 que também esteja agindo como um controlador de domínio, ter uma ou mais funções do servidor Exchange 2007 executadas em um controlador de domínio com o IPv6 desabilitado deve funcionar, especialmente porque esse é um cenário comum em laboratórios de teste e outros lugares. A solução atual é reativar o IPv6 no servidor. Corre o boato que o Pacote Cumulativo de Atualizações 4 do Exchange 2007 SP1 corrigirá esse problema.
Henrik Walther é Microsoft Certified Master: Exchange 2007 e MVP em Exchange com mais de 14 anos de experiência na atividade de TI. Ele trabalha como arquiteto de tecnologia para a Interprise Consulting (um parceiro Gold de infra-estrutura da Microsoft com base na Dinamarca) e como redator técnico para a Biblioso Corporation (uma empresa com base nos EUA especializada em documentação gerenciada e serviços de localização).