Noções básicas de proxy e redirecionamento

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

Em uma organização do Microsoft Exchange Server 2010, um servidor de Acesso para Cliente pode atuar como um proxy para outros servidores de Acesso para Cliente presentes na organização. Isso é útil quando vários servidores de Acesso para Cliente estão presentes em sites diferentes do Active Directory em uma organização e pelo menos um desses sites não está exposto à Internet.

Um servidor de Acesso para Cliente também pode executar redirecionamento para URLs do Microsoft Office Outlook Web App e para dispositivos do Exchange ActiveSync. O redirecionamento é útil quando o usuário se conecta a um servidor de Acesso para Cliente que não está em seu site do Active Directory local ou se uma caixa de correio tiver sido movida entre os sites do Active Directory. Também é útil se os usuários utilizarem uma URL mais eficaz. Por exemplo, os usuário devem usar uma URL mais parecida com o site Active Directory onde residem suas caixas de correio.

A resposta dos servidores de Acesso para Cliente pode variar de acordo com o protocolo. Tipicamente, um servidor de Acesso para Cliente toma a seguinte ação se receber uma solicitação de um usuário cuja caixa de correio seja um site Active Directory que não o site ao qual o Acesso para Cliente pertence: Nesse caso, o servidor procura a presença de uma propriedade ExternalURL no diretório virtual relevante em um servidor de Acesso para Cliente que esteja no mesmo site Active Directory que a caixa de correio desse usuário. Se a propriedade ExternalURL existir, e o tipo de cliente tiver suporte para redirecionamento (por exemplo, Outlook Web App ou Exchange ActiveSync), o servidor de Acesso para Cliente emitirá um redirecionamento para esse cliente. Se não houver nenhuma propriedade ExternalURL ou se o tipo de cliente não tiver suporte para redirecionamento (por exemplo, POP3 ou IMAP4), o servidor de Acesso para Cliente tentará intermediar por proxy a conexão para o site do Active Directory de destino.

Este tópico explica intermediação por proxy e redirecionamento, quando cada um deles é usado e como configurar servidores de Acesso para Cliente para cada cenário.

Conteúdo

Visão geral de intermediação por proxy

Visão geral de redirecionamento

Intermediação por proxy com Balanceamento de Carga da Rede

Resumo dos métodos de Acesso para Cliente

Desempenho e escalabilidade da intermediação por proxy

Visão geral de intermediação por proxy

No Microsoft Exchange Server 2003, o servidor front-end se comunica com o servidor back-end por HTTP. No Exchange Server 2007 e no Exchange 2010, o servidor de Acesso para Cliente se comunica com um servidor de caixa de correio do Exchange por RPC. Você deve ter um servidor de Acesso para Cliente do Exchange 2010 em cada site do Active Directory que contenha um servidor Caixa de Correio do Exchange 2010. A intermediação por proxy ocorre quando um servidor de Acesso para Cliente envia tráfego para outro. Um servidor de Acesso para Cliente do Exchange 2010 pode intermediar por proxy solicitações nestas duas situações:

• Entre servidores de Acesso para Cliente do Exchange 2010   A intermediação por proxy de solicitações entre dois servidores de Acesso para Cliente do Exchange 2010 permite que as organizações que possuem vários sites do Active Directory designem um servidor de Acesso para Cliente como um servidor voltado para a Internet e façam com que o servidor execute proxy de solicitações para servidores de Acesso para Cliente em sites que não tenham presença na Internet. O servidor de Acesso para Cliente voltado para a Internet faz a intermediação por proxy da solicitação para o servidor de Acesso para Cliente que está mais próximo da caixa de correio do usuário.

• Entre um servidor de Acesso para Cliente do Exchange 2010 e os servidores de Acesso para Cliente do Exchange 2007   As solicitações de intermediação por proxy entre um servidor de Acesso para Cliente do Exchange 2010 e um servidor de Acesso para Cliente do Exchange 2007 em um site do Active Directory ou entre sites do Active Directory permitem que o Exchange 2010 e o Exchange 2007 coexistam na mesma organização. Para obter mais informações sobre atualização e coexistência, consulte Atualização do acesso para cliente do Exchange 2003 e Atualização do acesso para cliente do Exchange 2007.

A intermediação por proxy tem suporte para clientes que usam Outlook Web App, Exchange ActiveSync, o Painel de Controle do Exchange (ECP), POP3, IMAP4 e Serviços Web do Exchange. Há suporte para proxy de um servidor de Acesso para Cliente para outro servidor de Acesso para Cliente quando o servidor de Acesso para Cliente de destino está executando a mesma versão do Microsoft Exchange ou uma versão anterior do Microsoft Exchange que o servidor de Acesso para Cliente de origem, exceto nas instâncias em que é necessária uma URL específica da versão. Para saber mais sobre URLs específicas da versão e nomes de host herdados em um ambiente misto do Exchange 2007 e do Exchange 2010, confira Atualização do acesso para cliente do Exchange 2007. Para saber mais sobre URLs específicas da versão e nomes de host herdados em um ambiente misto do Exchange 2010 e do Exchange 2013, confira Criar um nome de host do Exchange herdado.

Intermediação por proxy de Acesso para Cliente

Na figura anterior, a caixa de correio do Usuário 1 está localizada no servidor Caixa de Correio 1. A caixa de correio do Usuário 2 está localizada no servidor Caixa de Correio 2, e a caixa de correio do Usuário 3 está localizada no servidor Caixa de Correio 3. Cada servidor de Caixa de Correio está em um site do Active Directory diferente. O Usuário 1 pode acessar a caixa de correio por meio do servidor de Acesso para Cliente 1 sem usar intermediação por proxy, e o Usuário 2 pode acessar sua caixa de correio por meio do servidor de Acesso para Cliente 2. Se o Usuário 3 tentar acessar a caixa de correio por meio do servidor 1 ou 2 de Acesso para Cliente, um dos servidores fará a intermediação por proxy de sua solicitação para o servidor de Acesso para Cliente 3. O servidor de Acesso para Cliente 3 não está voltado para a Internet, mas pode receber solicitações de outros servidores dentro do firewall. A intermediação por proxy não fica visível ao usuário.

Visão geral de intermediação por proxy

Visão geral de redirecionamento

Usuários do Outlook Web App que acessam um servidor de Acesso para Cliente voltado para a Internet que esteja em um site do Active Directory diferente do site que contém suas caixas de correio podem ser redirecionados para o servidor de Acesso para Cliente que está no mesmo site que o servidor Caixa de Correio, se esse servidor de Acesso para Cliente for voltado para a Internet. Quando um usuário do Outlook Web App tentar se conectar a um servidor de Acesso para Cliente que esteja fora do site do Active Directory que contém seu servidor Caixa de Correio, ele verá uma página da Web que contém um link para o servidor de Acesso para Cliente correto de sua caixa de correio. Isso é conhecido como redirecionamento manual. No Exchange 2010 SP2, os administradores podem configurar o redirecionamento silencioso entre sites para permitir que esse processo de redirecionamento ocorra sem o conhecimento do usuário. Para obter mais informações, consulte Redirecionamento silencioso entre sites, mais adiante neste tópico.

Usuários do Exchange ActiveSync que acessam um servidor de Acesso para Cliente voltado para a Internet que esteja em um site do Active Directory diferente do site que contém suas caixas de correio podem ser redirecionados para o servidor de Acesso para Cliente que está no mesmo site que o servidor Caixa de Correio, se esse servidor de Acesso para Cliente for voltado para a Internet e se o dispositivo móvel ou o telefone celular tiver implementado corretamente a lógica de redirecionamento integrada ao protocolo usado na comunicação com o Exchange 2007 e o Exchange 2010. O redirecionamento para usuários do Exchange ActiveSync é feito pelo envio, ao dispositivo, de um código de erro HTTP 451 que contém a URL que o dispositivo deverá estar usando. Em seguida, o dispositivo realiza a sua própria reconfiguração para usar a nova URL.

A figura a seguir mostra como o redirecionamento funciona em uma organização que tenha vários servidores de Acesso para Cliente em vários sites do Active Directory.

Redirecionamento para Exchange ActiveSync e Outlook Web App no Exchange 2010

Na figura anterior, o Usuário 1 geralmente acessa sua caixa de correio no site 1 do Active Directory usando seu telefone celular. Em seguida, o administrador move sua caixa de correio para o servidor de Caixa de Correio 2 no site 2 do Active Directory. Na próxima vez em que o dispositivo tentar sincronizar, o servidor responderá com um status de erro HTTP 451. Isso contém a URL que o dispositivo deverá agora usar para esse usuário. Na etapa 3 da sequência, o dispositivo realiza a sua própria reconfiguração e se conecta à URL especificada. O usuário 2, cuja caixa de correio está no site 2 do Active Directory, tenta abrir sua caixa de correio usando o Outlook Web App, conectando o servidor de Acesso para Cliente 1 pela Internet. Com o redirecionamento manual, assim que o usuário realiza a autenticação, o servidor de Acesso para Cliente 1 apresenta uma página ao usuário, com um link para o URL do Outlook Web App para o servidor de Acesso para Cliente no site 2 do Active Directory. O usuário clica no link, é levado ao site 2 do Active Directory e entra novamente para acessar sua caixa de correio. Com o redirecionamento silencioso, quando o usuário realiza a autenticação, é redirecionado silenciosamente para o URL do Outlook Web App para o servidor de Acesso para Cliente no site 2 do Active Directory.

Redirecionamento silencioso entre sites

O Exchange 2010 SP2 permite que os administradores configurem o redirecionamento silencioso entre sites. O redirecionamento silencioso entre sites realiza um redirecionamento silencioso das solicitações de cliente destinadas a um CAS localizado em um site diferente do Active Directory na mesma organização do Exchange. Por exemplo, um usuário com uma caixa de correio no SiteA do Active Directory acessando o URL do Outlook Web App no SiteB do Active Directory será redirecionado silenciosamente para o URL do Outlook Web App para o SiteA do Active Directory.

Para configurar o redirecionamento silencioso entre sites, o administrador precisa usar o novo parâmetro CrossSiteRedirectType que foi adicionado ao cmdlet Set-OWAVirtualDirectory. O parâmetro tem duas configurações possíveis. A definição padrão é Manual.

• Silent Quando essa configuração está definida, o navegador da Web de um usuário é redirecionado automaticamente sempre que um servidor de Acesso para Cliente precisar redirecionar uma solicitação do Outlook Web App para o servidor de Acesso para Cliente ou a matriz de servidores em outro site do Active Directory. Quando a autenticação baseada em formulários estiver configurada nos diretórios virtuais do OWA do CAS de origem e destino (o SSL é necessário), o redirecionamento silencioso também será um evento de logon único. Para que o redirecionamento ocorra, o diretório virtual do Outlook Web App do servidor de Acesso para Cliente de destino precisa ter um valor de ExternalURL configurado.

• Manual Quando essa configuração está definida, os usuários recebem uma notificação de que estão acessando o URL errado e que precisam clicar em um link para acessar o URL correto do Outlook Web App para suas caixas de correio. A notificação só ocorre quando um servidor de Acesso para Cliente determina que precisa redirecionar uma solicitação do Outlook Web App para o servidor de Acesso para Cliente ou a matriz de servidores em outro site do Active Directory. Para que o redirecionamento ocorra, o diretório virtual do Outlook Web App do servidor de Acesso para Cliente de destino precisa ter um valor de ExternalURL configurado.

Por exemplo:

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Para obter mais informações sobre o cmdlet Set-OwaVirtualDirectory, consulte: Set-OwaVirtualDirectory

Intermediação por proxy e redirecionamento para Exchange ActiveSync

A série de etapas a seguir mostra como as solicitações de entrada são tratadas para um usuário que se conecta a um servidor de Acesso para Cliente do Exchange 2010 chamado CAS-01 utilizando um telefone celular.

1. O servidor de Acesso para Cliente consulta o Active Directory para determinar o local da caixa de correio do usuário e a versão do Microsoft Exchange instalada no servidor Caixa de Correio.

2. Se a caixa de correio do usuário estiver em um servidor do Exchange 2003, a solicitação de entrada será intermediada por proxy diretamente para o servidor do Exchange 2003 que hospeda a caixa de correio do usuário e o diretório virtual do Exchange ActiveSync. Por padrão, no Exchange 2003, o diretório virtual do Exchange ActiveSync é instalado em todos os servidores de caixa de correio. O site do Active Directory da caixa de correio do usuário não é aplicável nesse caso porque o Exchange 2003 não usa sites do Active Directory para determinar o local. A conexão é sempre feita diretamente do servidor de Acesso para Cliente do Exchange 2010 para o servidor de caixa de correio do Exchange 2003. 

   Dica

   Os usuários que têm caixas de correio em um servidor Exchange 2003 e tentam usar o Exchange ActiveSync por meio de um servidor de Acesso para Cliente do Exchange 2010 receberão um erro e não conseguirão sincronizar, a menos que a autenticação Integrada do Windows esteja habilitada no diretório virtual do Microsoft-Server-ActiveSync no servidor Exchange 2003. A autenticação Integrada do Windows permite que o servidor de Acesso para Cliente do Exchange 2010 e o servidor back-end do Exchange 2003 se comuniquem.

3. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2007, o CAS-01 localizará um servidor de Acesso para Cliente do Exchange 2007 no mesmo site do Active Directory que o servidor de Caixa de Correio do usuário. Este pode ser o mesmo site do Active Directory que o CAS-01. O CAS-01 intermedia por proxy as solicitações do Exchange ActiveSync para a InternalURL do servidor de Acesso para Cliente do Exchange 2007 sem considerar as configurações da ExternalURL. A solicitação vai para o diretório virtual /Proxy localizado sob o diretório virtual do Microsoft Server Exchange ActiveSync exExchangeASync no IIS que, por padrão, tem a autenticação integrada do Windows habilitada.

4. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 no mesmo site do Active Directory que o CAS-01, o CAS-01 fornecerá acesso à caixa de correio. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 em um site do Active Directory diferente, o CAS-01 localizará um servidor de Acesso para Cliente no mesmo site do Active Directory que o servidor de Caixa de Correio do usuário. O CAS-01 determina se qualquer servidor de Acesso para Cliente do Exchange 2010 nesse site do Active Directory tem a propriedade ExternalURL configurada no diretório virtual do Exchange ActiveSync. Se for esse o caso, CAS-01 emitirá para o cliente um código de erro HTTP 451 que contém o valor ExternalURL e instruirá o cliente a redirecionar para esse local. Se nenhum valor ExternalURL for definido, a conexão será intermediada por proxy para o servidor de Acesso para Cliente usando o FQDN especificado pela propriedade InternalURL, especificamente para o diretório virtual /Proxy. Esse diretório virtual está localizado abaixo do diretório virtual do Exchange ActiveSync no IIS e, por padrão, tem a autenticação Integrada do Windows habilitada nele.

   Importante

   A intermediação por proxy não é possível entre diretórios virtuais que usam autenticação Básica. Para que a comunicação entre clientes seja intermediada por proxy entre diretórios virtuais do Exchange ActiveSync em servidores diferentes, os diretórios virtuais devem usar autenticação Integrada do Windows.

Visão geral de intermediação por proxy

Intermediação por proxy e redirecionamento para Outlook Web App

A série de etapas a seguir mostra como as solicitações de entrada são tratadas para um usuário que se conecta a um servidor de Acesso para Cliente do Exchange 2010 chamado CAS-01 utilizando o Outlook Web App.

1. O servidor de Acesso para Cliente consulta o Active Directory para determinar o local da caixa de correio do usuário e a versão do Microsoft Exchange instalada no servidor Caixa de Correio.

2. Caso a caixa de correio do usuário esteja em um servidor do Exchange 2003, e o usuário tente acessar o Outlook Web App usando https://nome domínio/owa, ele receberá um erro porque um servidor de Acesso para Cliente do Exchange 2010 não pode fornecer diretamente o acesso do Outlook Web App a uma caixa de correio do Exchange 2003. Entretanto, se o administrador tiver configurado o redirecionamento do Exchange 2010 para o Exchange 2003, o que seria comum durante uma migração do Exchange 2003 para o Exchange 2010, a propriedade Exchange2003URL do diretório virtual do Outlook Web App será definida para o valor de um servidor do Exchange 2003 voltado para a Internet.

3. Se a caixa de correio do usuário estiver em um servidor de caixa de correio do Exchange 2007, o CAS-01 localizará um servidor de Acesso para Cliente no mesmo site do Active Directory que o servidor de caixa de correio do usuário. Se o servidor de Caixa de Correio do Exchange 2007 estiver no mesmo site do Active Directory que o CAS-01, ocorrerá uma de quatro ações possíveis.

   • O CAS-01 procurará uma propriedade Exchange 2007 ExternalURL que tenha uma configuração ExternalAuthenticationMethods idêntica à configuração InternalAuthenticationMethods no servidor de Acesso para Cliente do Exchange 2010. Se as configurações forem iguais, o CAS-01 redirecionará para esse URL externo. Se os CAS de origem e destino tiverem Autenticação Baseada em Formulários (FBA) habilitada, o CAS de origem envia um formulário oculto de volta para o navegador que contém as credenciais de usuário e as configurações FBA junto com o URL de redirecionamento. Isso é transparente para o usuário.

   • Se uma configuração ExternalURL correspondente não for encontrada, o CAS-01 procurará um servidor de Acesso para Cliente do Exchange 2007 que tenha a propriedade ExternalURL configurada, independentemente da correspondência. Se uma for encontrada, o CAS-01 redirecionará para essa URL externa. Isso fará com que seja solicitada a autenticação do usuário.

   • Se nenhuma configuração ExternalURL correspondente for encontrada, o CAS-01 procurará um servidor de Acesso para Cliente do Exchange 2007 com uma propriedade InternalURL que tenha uma configuração InternalAuthenticationMethods idêntica à configuração no servidor de Acesso para Cliente do Exchange 2010. Se uma for encontrada, o CAS-01 redirecionará para essa InternalURL. Se a autenticação baseada em formulários for habilitada, isso resultará em um redirecionamento de logon único.

   • Se nenhuma InternalURL correspondente for encontrada, CAS-01 procurará um servidor de Acesso para Cliente do Exchange 2007 com uma InternalURL configurada, independentemente da correspondência. Se uma for encontrada, o CAS-01 redirecionará para essa InternalURL. Isso fará com que seja solicitada a autenticação do usuário.

   Se o servidor de Caixa de Correio do Exchange 2007 estiver em um site do Active Directory diferente, o CAS-01 determinará se a propriedade ExternalURL está definida nesse site do Active Directory. Se estiver, e o redirecionamento silencioso entre sites não estiver habilitado, o valor CrossSiteRedirectType será definido como Manual e um redirecionamento manual será emitido. Nesse o caso, o usuário recebe um link que pode ser clicado e que o redireciona para o URL especificado.

   Se o redirecionamento silencioso entre sites tiver sido habilitado, o valor CrossSiteRedirectType será definido como Silent (silencioso) e o usuário será redirecionado automaticamente para o URL especificado. Se a propriedade ExternalURL não estiver presente e o método de autenticação no diretório virtual /OWA estiver definido como Autenticação integrada do Windows, o CAS-01 fará a intermediação por proxy da solicitação do usuário para o servidor de Acesso para Cliente especificado pela propriedade InternalURL.

   Importante

   Para permitir que um servidor de Acesso para Cliente do Exchange 2010 faça a intermediação por proxy das solicitações do Outlook Web App para um servidor de Acesso para Cliente do Exchange 2007 em outro site do Active Directory, você deverá copiar a pasta com a versão mais alta de um servidor de Acesso para Cliente do Exchange 2007 no site de destino do Active Directory da pasta %installpath%\ClientAccess\OWA\ para o mesmo caminho no servidor de Acesso para Cliente do Exchange 2010 que está fazendo a solicitação de proxy.

   Importante

   Um servidor de Acesso para Cliente do Exchange 2010 nunca fará a intermediação por proxy das solicitações do Outlook Web App para um servidor de Acesso para Cliente do Exchange 2007 no mesmo site do Active Directory. Todas as solicitações dentro do mesmo site do Active Directory são redirecionadas para um servidor de Acesso para Cliente do Exchange 2007, com o uso da propriedade InternalURL ou ExternalURL para o servidor de Acesso para cliente, dependendo de quais propriedades estão configuradas.

4. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 no mesmo site do Active Directory que o CAS-01, o CAS-01 fornecerá acesso à caixa de correio. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 em um site do Active Directory diferente, o CAS-01 localizará um servidor de Acesso para Cliente no mesmo site do Active Directory que o servidor de Caixa de Correio do usuário. Quando uma for encontrada, o Exchange 2010 determinará se o servidor de Acesso para Cliente tem a propriedade ExternalURL definida nesse site do Active Directory. Se for esse o caso e o redirecionamento silencioso entre sites não tiver sido habilitado, o usuário receberá um link que pode ser clicado e que o redireciona para o URL especificado. Se o redirecionamento silencioso entre sites tiver sido habilitado, o usuário será redirecionado automaticamente para o URL especificado. Se a ExternalURL não tiver sido definida, e o método de autenticação no diretório virtual estiver definido como autenticação Integrada do Windows, o CAS-01 fará a intermediação por proxy da solicitação do usuário para o servidor de Acesso para Cliente especificado pela propriedade InternalURL.

Intermediação por proxy para o Painel de Controle do Exchange

O Exchange 2010 fornece uma interface baseada na Web para que os usuários e os administradores de organização definam configurações para sua caixa de correio ou para a organização. O Painel de Controle do Exchange (ECP) é acessado pelo menu Opções no Outlook Web App ou, no Outlook 2010, escolhendo as opções de Caixa Postal, solicitando informações de acompanhamento de mensagens ou configurando notificações móveis. A seleção de qualquer uma dessas opções no Outlook inicia uma sessão de navegador da Web.

O destino da sessão depende do estado de conexão atual do cliente do Outlook. Se o cliente do Outlook for conectado com o uso de RPC sobre TCP, o cliente se conectará ao valor InternalURL do diretório virtual do ECP. Se o cliente estiver conectado com o uso do Outlook em Qualquer Lugar, o cliente do Outlook iniciará uma sessão do navegador. A sessão do navegador tentará se conectar ao valor da ExternalURL do diretório virtual do ECP. As URLs são fornecidas ao cliente do Outlook por meio do serviço Descoberta Automática.

Quando um cliente interno é conectado por meio de TCP, a sessão ECP será sempre conectada a um servidor de Acesso para Cliente no mesmo site do Active Directory que a caixa de correio do usuário. A intermediação por proxy não é usada nesse cenário. Quando um cliente fora da rede corporativa usa o Outlook em Qualquer Lugar para se conectar, o cliente abre uma sessão do navegador para a URL externa do diretório virtual do ECP ou para a URL externa de um site do Active Directory voltado para a Internet se a caixa de correio do usuário estiver localizada em um site não voltado para a Internet.

A lógica de intermediação por proxy do ECP é a mesma que a do Outlook Web App. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 no mesmo site do Active Directory que o servidor de Acesso para Cliente que recebe a solicitação, o o servidor de Acesso para Cliente fornecerá acesso à caixa de correio. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 em um site do Active Directory diferente, o servidor de Acesso para Cliente localizará um servidor de Acesso para Cliente no mesmo site do Active Directory que o servidor de Caixa de Correio do usuário. O servidor de Acesso para Cliente fará a intermediação por proxy da solicitação do usuário para esse servidor de Acesso para Cliente.

O ECP não realiza o redirecionamento, mas, a menos que o usuário explicitamente insira a URL para acessar o ECP, ele raramente será realizado. Se um usuário acessar o ECP pelo Outlook Web App, o Outlook Web App será responsável por garantir que o usuário esteja utilizando a URL correta. Se o usuário estiver utilizando o Outlook 2010, o Outlook e o serviço Descoberta Automática serão responsáveis por verificar se o usuário utiliza a URL correta para o ECP. 

Visão geral de intermediação por proxy

Intermediação por proxy para Serviços Web do Exchange

Serviços Web do Exchange fornece uma interface de mensagens XML que permite gerenciar os itens de armazenamento do Exchange e acessar a funcionalidade de servidor do Exchange pelos aplicativos de cliente. A partir da perspectiva de proxy, redirecionamento e cliente, essa funcionalidade é geralmente usada no contexto de um dos seguintes:

• Solicitações de serviço de disponibilidade

• Solicitações de Descoberta Automática

• Configuração e verificação de status de Respostas Automáticas (OOF)

Um aplicativo escrito com o uso de Serviços Web do Exchange pode usar o comportamento de proxy para essas tarefas, como configuração de uma mensagem de resposta automática (Ausência Temporária), o que será intermediado por proxy entre os sites do Active Directory, se necessário. 

As seguintes etapas mostram como as solicitações de entrada são tratadas para um usuário que faz uma solicitação de serviço de Disponibilidade para um servidor de Acesso para Cliente do Exchange 2010 denominado CAS-01. O usuário utiliza Outlook Web App para verificar a disponibilidade de outro usuário na mesma organização do Exchange.

1. O CAS-01 consulta o Active Directory para determinar o local da caixa de correio do usuário e a versão do Microsoft Exchange instalada no servidor Caixa de Correio.

2. Se a caixa de correio do usuário estiver em um servidor do Exchange 2003, o Outlook Web App fará uma conexão HTTP com o diretório virtual /Public do servidor do Exchange 2003 e recuperará as informações solicitadas da pasta do sistema Free/Busy (Disponibilidade).

3. Se a caixa de correio do usuário estiver em um servidor de caixa de Correio do Exchange 2007, um erro será retornado para o usuário. Em qualquer organização do Exchange que contenha caixas de correio em um servidor de caixa de correio do Exchange 2007, deve haver um servidor de Acesso para Cliente do Exchange 2007 acessível externamente. O serviço Descoberta Automática é responsável por retornar a URL correta dos Serviços Web do Exchange para o cliente. Essa URL deve corresponder à versão do servidor de caixa de correio no qual a caixa de correio do usuário está.

4. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 no mesmo site do Active Directory que o CAS-01, o CAS-01 acessará a própria caixa de correio para recuperar as informações solicitadas. Se a caixa de correio do usuário estiver em um servidor de Caixa de Correio do Exchange 2010 em um site do Active Directory diferente, o CAS-01 fará a intermediação por proxy para um servidor de Acesso para Cliente nesse site do Active Directory usando o FQDN especificado pela propriedade InternalURL do diretório virtual /EWS.

   Importante

   Um servidor de Acesso para Cliente do Exchange fará a intermediação por proxy das solicitações do serviço de Disponibilidade de um servidor para o outro, esteja a propriedade ExternalURL definida ou não.

   Importante

   Alguns aplicativos de Serviços Web do Exchange usam métodos Web, como GetEvents e Unsubscribe, os quais têm afinidade de servidor de Acesso para Cliente muito grande. Quando um servidor de Acesso para Cliente precisar fazer a intermediação por proxy de uma dessas solicitações para outro site do Active Directory, ele poderá usar a propriedade InternalNLBBypassURL do servidor de Acesso para Cliente, que deverá sempre ser definida para o FQDN do próprio servidor de host. Isso assegura que o servidor de Acesso para Cliente que está fazendo a solicitação possa manter a afinidade com um servidor de Acesso para Cliente específico no site do Active Directory de destino.

O próprio Serviços Web do Exchange não fornece a funcionalidade de redirecionamento porque o serviço Descoberta Automática, que é usado para fornecer URLs a um aplicativo, fornece as URLs necessárias para acessar uma caixa de correio específica. Por exemplo, quando uma caixa de correio é movida entre sites do Active Directory, o Outlook recebe as URLs específicas do site do Active Directory do serviço Descoberta Automática quando ele emite uma consulta em seguida. Isso pode às vezes resultar em um cliente fazendo solicitações de serviço de Disponibilidade a um servidor de Acesso para Cliente em um site do Active Directory que não seja o que a sua caixa de correio está. Mas, como o serviço de Disponibilidade ainda irá processar as solicitações e fazer a intermediação pelo seu proxy de acordo com a necessidade, não ocorre nenhum impacto para o usuário.

Intermediação por proxy para POP3 e IMAP4

O Exchange 2010 pode fazer a intermediação por proxy das sessões POP3 e IMAP4 entre os servidores de Acesso para Cliente e os sites do Active Directory.

As etapas a seguir mostram como as solicitações de entrada são tratadas para um usuário que faz uma solicitação para um servidor de Acesso para Cliente do Exchange 2010 chamado CAS-01 utilizando um cliente POP3.

1. O CAS-01 consulta o Active Directory para determinar o local da caixa de correio do usuário e a versão do Microsoft Exchange instalada no servidor Caixa de Correio.

2. Se a caixa de correio do usuário estiver em um servido do Exchange 2003, o CAS-01 fará a intermediação por proxy da conexão para o serviço POP3 em execução no servidor do Exchange 2003 que hospeda a caixa de correio do usuário.

3. Se a caixa de correio do usuário estiver em um servidor de Caixa de Correio do Exchange 2007, CAS-01 localizará um servidor de Acesso para Cliente do Exchange 2007 no mesmo site do Active Directory que o servidor de Caixa de Correio do usuário, que poderá estar no mesmo site do Active Directory que do CAS-01. O CAS-01 faz a intermediação por proxy da solicitação para o servidor de Acesso para Cliente.

4. Se a caixa de correio do usuário estiver em um servidor Caixa de Correio do Exchange 2010 no mesmo site do Active Directory que o CAS-01, o CAS-01 acessará a própria caixa de correio. Se a caixa de correio do usuário estiver em um servidor de Caixa de Correio do Exchange 2010 em um site do Active Directory diferente, o CAS-01 fará a intermediação por proxy para um servidor de Acesso para Cliente usando o FQDN especificado pela propriedade InternalConnectionSettings da configuração POP desse servidor.

   Importante

   Não há nenhuma configuração de InternalURL ou ExternalURL para os serviços POP3 ou IMAP4, e um servidor de Acesso para Cliente do Exchange 2010 fará a intermediação por proxy das solicitações de serviço POP3 e IMAP4 de um servidor para outro quando necessário.

   Importante

   Os servidores de Acesso para Cliente que tentam fazer a intermediação por proxy para outro site do Active Directory não verificam se o serviço POP3 ou IMAP4 está realmente em execução no servidor de Acesso para Cliente remoto. Por isso, é importante não só garantir que os serviços estejam em execução em cada servidor de Acesso para Cliente no site do Active Directory remoto, mas também considerar o uso de um balanceador de carga para o serviço. Os balanceamentos de carga serão discutidos posteriormente neste tópico.

Visão geral de intermediação por proxy

Configuração de intermediação por proxy

Se o servidor de Acesso para Cliente for voltado para a Internet, defina a propriedade ExternalURL nos diretórios virtuais /Microsoft-Server-ActiveSync, /OWA, /ECP e /EWS usando o Console de Gerenciamento do Exchange (EMC) ou o Shell de Gerenciamento do Exchange (Shell). O diretório virtual do EWS pode ser configurado apenas com o uso do Shell. A propriedade InternalURL é configurada automaticamente durante a instalação inicial do Exchange 2010 e deverá ser alterada apenas se você quiser usar uma solução de balanceamento de carga. A propriedade ExternalURL deve conter o FQDN que está registrado para a sua organização do Exchange em DNS.

A tabela a seguir contém os valores adequados para as propriedades ExternalURL e InternalURL de um servidor de Acesso para Cliente voltado para a Internet para uma organização do Exchange que acessa o Outlook Web App usando a URL https://mail.contoso.com. A segunda tabela contém os valores de propriedade ExternalURL e InternalURL apropriados para um servidor de Acesso para Cliente não voltado para a Internet em um segundo site do Active Directory para a mesma organização. Você deve garantir que o método de autenticação de todos esses diretórios virtuais seja definido como autenticação Integrada do Windows. A intermediação por proxy não tem suporte para diretórios virtuais que usam outros métodos de autenticação, exceto para POP3 e IMAP4, que usam SSL/TLS e fazem a intermediação por proxy das credenciais de autenticação Básicas.

Configurações de InternalURL e ExternalURL para um servidor de Acesso para Cliente voltado para a Internet

Serviço do Exchange 2010	Configuração de InternalURL	Configuração de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://mail.contoso.com/OWA
Exchange ActiveSync	https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync	https://mail.contoso.com/Microsoft-Server-ActiveSync
Serviços Web do Exchange	https://fullyqualifiedcomputername/EWS/Exchange.asmx	https://mail.contoso.com/EWS/Exchange.asmx
Painel de Controle do Exchange	https://fullyqualifiedcomputername/ECP	https://mail.contoso.com/ECP

Configurações de InternalURL e ExternalURL para um servidor de Acesso para Cliente que não é voltado para a Internet

Serviço do Exchange 2010	Configuração de InternalURL	Configuração de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	$Null
Exchange ActiveSync	https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync	$Null
Serviços Web do Exchange	https://fullyqualifiedcomputername/EWS/Exchange.asmx	$Null
Painel de Controle do Exchange	https://fullyqualifiedcomputername/ECP	$Null

Configurando o redirecionamento

Se mais de um de seus sites do Active Directory for voltado para a Internet, defina a propriedade ExternalURL nos diretórios virtuais /OWA e /Microsoft-Server-ActiveSync usando o EMC ou o Shell para permitir o redirecionamento entre eles. A propriedade InternalURL é configurada automaticamente durante a instalação inicial do Exchange 2010 e deverá ser alterada apenas se você quiser usar uma solução de balanceamento de carga. As duas tabelas a seguir listam as configurações de ExternalURL e InternalURL para servidores de Acesso para Clientes em dois sites do Active Directory para uma empresa chamada Contoso. Os dois sites são usa.contoso.com e europe.contoso.com.

Configurações das propriedades InternalURL e ExternalURL para um servidor de Acesso para Cliente voltado para a Internet no site usa.contoso.com

Serviço do Exchange 2010	Configuração de InternalURL	Configuração de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://usa.contoso.com/OWA
Painel de Controle do Exchange	https://fullyqualifiedcomputername/ECP	https://usa.contoso.com/ECP
Exchange ActiveSync	https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync	https://usa.contoso.com/ Microsoft-Server-ActiveSync
Serviços Web do Exchange	https://fullyqualifiedcomputername /EWS/Exchange.asmx	https://usa.contoso.com/EWS/Exchange.asmx

Configurações das propriedades InternalURL e ExternalURL para um servidor de Acesso para Cliente voltado para a Internet no site europe.contoso.com

Serviço do Exchange 2010	Configuração de InternalURL	Configuração de ExternalURL
Outlook Web App	https://fullyqualifiedcomputername/OWA	https://europe.contoso.com/OWA
Painel de Controle do Exchange	https://fullyqualifiedcomputername/ECP	https://europe.contoso.com/ECP
Exchange ActiveSync	https://fullyqualifiedcomputername /Microsoft-Server-ActiveSync	https://europe.contoso.com/ Microsoft-Server-ActiveSync
Serviços Web do Exchange	https://fullyqualifiedcomputername /EWS/Exchange.asmx	https://europe.contoso.com/EWS/Exchange.asmx

Visão geral de intermediação por proxy

Intermediação por proxy com Balanceamento de Carga da Rede

Em uma organização que tenha vários sites do Active Directory e vários servidores de Acesso para Cliente em cada site, você pode usar o Balanceamento de Carga de Rede (NLB) para balancear a carga do tráfego com intermediação por proxy entre os servidores de Acesso para Cliente em cada site e para os usuários que acessam diretamente esses servidores. Apenas implantar um balanceador de carga não é suficiente para garantir que o tráfego seja balanceado de forma eficaz. Você deve também realizar uma configuração adicional das propriedades InternalURL e ExternalURL. Recomendamos a inclusão apenas de servidores de Acesso para Cliente no mesmo site do Active Directory em uma matriz de balanceamento de carga. Você pode implantar o NLB em um site do Active Directory voltado para a Internet e em um site do Active Directory que não seja voltado para Internet.

A tabela a seguir lista as configurações que deverão ser definidas para os diretórios virtuais nos servidores de Acesso para Cliente nos sites voltados para Internet e não voltados para a Internet. O FQDN do NLB deve ser configurado no DNS para resolução para o dispositivo ou serviço de balanceamento de carga. A solução de balanceamento de carga será responsável pelo encaminhamento do tráfego para os servidores de Acesso para Cliente apropriados.

Configurações do diretório virtual para servidores de Acesso para Cliente em uma organização que usa NLB

Serviço/diretório virtual	InternalURL	ExternalURL (Site do Active Directory voltado para a Internet)	ExternalURL (Site do Active Directory não voltado para a Internet)
/OWA	FQDN NLB (consulte as diretrizes a seguir)	FQDN NLB	$null
/ECP	FQDN NLB (consulte as diretrizes a seguir)	FQDN NLB	$null
/Microsoft-Server-ActiveSync	FQDN NLB	FQDN NLB	$null
/OAB	FQDN NLB	FQDN NLB	$null
/EWS	FQDN NLB	FQDN NLB	$null
POP/IMAP	(InternalConnectionsSettings) FQDN NLB	Não se aplica	Não aplicável

É recomendável o uso das seguintes diretrizes para a definição da propriedade InternalURL:

• A propriedade InternalURL dos diretórios virtuais /OWA e /ECP de todos os servidores de Acesso para Cliente em um site do Active Directory pode ser definida como o FQDN NLB dos servidores do site se houver usuários internos do Outlook 2010.

• Se um servidor de Acesso para Cliente em um site do Active Directory for o destino de uma solicitação do Outlook Web App ou de proxy de ECP de um servidor de Acesso para Cliente em qualquer outro site do Active Directory, certifique-se de configurar seu balanceador de carga para garantir que a afinidade seja mantida. Isso acontece porque o servidor de Acesso para Cliente do site voltado para a Internet não pode selecionar um servidor para cada solicitação individual e manter sua própria afinidade

A tabela a seguir lista as várias configurações de autenticação necessárias em diretórios virtuais em uma organização que usa balanceamento de carga de rede (NLB). Em uma organização que usa NLB, a URL do NLB é usada no lugar de uma URL de servidor de Acesso para Cliente específica para conectividade de cliente.

Configurações de autenticação do diretório virtual para servidores de Acesso para Cliente em uma organização que usa URLs do NLB para tolerância a falhas e balanceamento de carga

Serviço/diretório virtual	Site do Active Directory voltado para a Internet	Site do Active Directory não voltado para a Internet
/OWA	Se o Microsoft  Threat Management Gateway 2010 (Forefront TMG) ou o Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG) estiverem sendo usados, e a autenticação baseada em formulários estiver habilitada, use a autenticação Básica ou Integrada do Windows, dependendo das configurações de delegação de regra de firewall. Se o tráfego da Internet passar para o servidor de Acesso para Cliente sem nenhuma pré-autenticação, use a autenticação baseada em formulários. O mesmo método de autenticação deverá ser habilitado nos diretórios virtuais /OWA e /ECP.	Autenticação Integrada do Windows
/ECP	Se o Forefront TMG ou o Forefront UAFG estiver sendo usado, e a autenticação baseada em formulários estiver habilitada, use a autenticação Básica ou Integrada do Windows, dependendo das configurações de delegação de regra de firewall. Se o tráfego da Internet passar para o servidor de Acesso para Cliente sem nenhuma pré-autenticação, use a autenticação baseada em formulários. O mesmo método de autenticação deverá ser habilitado nos diretórios virtuais /OWA e /ECP.	Autenticação Integrada do Windows
/Microsoft-Server-ActiveSync	Autenticação básica.	Autenticação básica (a intermediação por proxy é feita com o uso do diretório subvirtual /Proxy.)
/OAB	Autenticação Básica ou Integrada do Windows, dependendo das configurações de delegação de regra de firewall.	A autenticação Básica ou Integrada do Windows, dependendo das configurações de delegação de regra de firewall (as solicitações de OAB nunca têm a sua intermediação por proxy feita entre os sites do Active Directory, esse diretório virtual é usado apenas pelos clientes do Outlook).
/EWS	Básica (opcional - dependendo das configurações de delegação de regra de firewall). Autenticação Integrada do Windows necessária.	Autenticação Integrada do Windows
POP/IMAP	Conforme solicitado pelo método de conexão de cliente.	Conforme solicitado pelo método de conexão de cliente

Visão geral de intermediação por proxy

Lógica de balanceamento de carga usada pelos servidores de Acesso para Cliente ao fazer a intermediação por proxy entre sites do Active Directory

Quando vários servidores de Acesso para Cliente existirem no site que será o destino de uma tentativa de proxy, e o servidor em que a caixa de correio do usuário está localizada for uma combinação de servidor de Acesso para Cliente e servidor de Caixa de Correio, o servidor de Acesso para Cliente no site do Active Directory de origem irá sempre escolher essa combinação como o destino da tentativa de proxy.

O Outlook Web App, o ECP e os Serviços Web do Exchange tratam o balanceamento de carga de maneira diferente do serviço de Disponibilidade e do Exchange ActiveSync. O Outlook Web App, o ECP e os Serviços Web do Exchange implementam seu próprio balanceamento de carga quando são implantados em vários servidores de Acesso para Cliente no mesmo site do Active Directory. Se um usuário tentar acessar o Outlook Web App através de https://mail.contoso.com/owa e for intermediado por proxy para o CAS-01, ele continuará sendo intermediado por proxy para o CAS-01 na próxima vez em que tentar acessar o Outlook Web App, mesmo se o CAS-02 tiver menos conexões simultâneas. Isso é feito para assegurar que transações de longa duração possam ser concluídas sem nova autenticação ou nova solicitação de dados. Isso é conhecido como Afinidade. Se o CAS-01 não estiver disponível, o usuário será intermediado por proxy para o CAS-02, e a nova autenticação poderá ser solicitada a ele.

Os Serviços Web do Exchange podem manter a afinidade quando intermediados por proxy entre os sites do Active Directory, apesar de a propriedade do InternalURL do servidor de destino ser configurada com uma URL do NLB. Isso ocorre porque o servidor de Acesso para Cliente que faz a solicitação de proxy para um aplicativo que requer afinidade usa a propriedade InternalNLBBypassURL no servidor de destino. A propriedade InternalNLBBypassURL é configurada com o FQDN do servidor de destino e usa a autenticação Windows por padrão.

O processo é diferente para o Exchange ActiveSync. Quando um servidor de Acesso para Cliente voltado para a Internet fizer a intermediação por proxy de uma solicitação para um servidor de Acesso para Cliente voltado para a Internet, o servidor de Acesso para Cliente solicitante procurará um servidor de Acesso para Cliente no site de destino e tentará conectá-lo usando o valor configurado na propriedade InternalURL. Se o servidor não responder, a solicitação falhará, e um erro será retornado ao cliente. Recomendamos implementar o balanceamento de carga round robin em uma matriz do NLB e configurar a propriedade InternalURL para um valor de balanceamento de carga.

Recomendamos também o balanceamento de carga para o serviço de Disponibilidade. As solicitações do serviço de Disponibilidade não precisam manter o estado de conexão. Em outras palavras, duas solicitações consecutivas do serviço de Disponibilidade feitas pelo mesmo cliente podem ser intermediadas por proxy para servidores de Acesso para Cliente diferentes no site de destino do Active Directory sem afetar o desempenho, e não haverá nenhum problema de autenticação se a propriedade InternalURL for definida para um valor de balanceamento de carga. Além disso, a configuração da propriedade InternalURL para um valor balanceado por carga beneficia todos os clientes do Outlook 2007 e do Outlook 2010 internamente, porque o serviço de Descoberta Automática fornece a esses clientes o valor de balanceamento de carga definido na propriedade InternalURL para permitir que eles concluam as suas solicitações do serviço de Disponibilidade.

Para obter mais informações sobre balanceamento de carga de rede, consulte Noções Básicas do Balanceamento de Carga no Exchange 2010.

Visão geral de intermediação por proxy

Resumo dos métodos de Acesso para Cliente

A tabela a seguir resume os protocolos usados para acessar o Exchange 2010 e como eles são usados para intermediação por proxy e redirecionamento.

Protocolos de Acesso para Cliente para redirecionamento e intermediação por proxy

Protocolo/Aplicativo	Redirecionamento aceito entre servidores de Acesso para Cliente	Intermediação por proxy aceita entre servidores de Acesso para Cliente	Comments
Outlook Web App	Sim	Sim	É necessário ter um servidor de Acesso para Cliente em cada site do Active Directory para usar o Outlook Web App.
Painel de Controle do Exchange	Sim	Sim	É necessário ter um servidor de Acesso para Cliente em cada site do Active Directory para usar o ECP.
Exchange ActiveSync	Sim	Sim	É necessário ter um servidor de Acesso para Cliente em cada site do Active Directory para usar o Exchange ActiveSync.
Serviços Web do Exchange	Não (O serviço Descoberta Automática fornece ao aplicativo o valor de ExternalURL correto)	Sim	É necessário ter um servidor de Acesso para Cliente em cada site do Active Directory para usar os Serviços Web do Exchange.
Serviço de Disponibilidade	Não (O serviço Descoberta Automática fornece ao aplicativo o valor de ExternalURL correto)	Sim	É necessário ter um servidor de Acesso para Cliente em cada site do Active Directory para usar o serviço de Disponibilidade.
POP3 e IMAP4	Não	Sim	É necessário ter um servidor de Acesso para Cliente em cada site do Active Directory para usar POP3 e IMAP4..

Desempenho e escalabilidade da intermediação por proxy

Em um ambiente de intermediação por proxy do Exchange 2010, um desempenho insatisfatório em geral resulta quando os servidores de Acesso para Cliente recebem muitas solicitações simultâneas. Esse problema é frequentemente causado pela exaustão dos threads e das conexões disponíveis, devido às solicitações de serviços Web recebidas de ASP.NET. Isso pode fazer com que os servidores de Acesso para Cliente neguem solicitações ou apresentem alta latência enquanto as solicitações estão sendo processadas.

Para solucionar esses problemas, você pode configurar vários parâmetros ASP.NET, editando o arquivo Machine.config nos servidores de Acesso para Cliente. Para obter mais informações sobre como configurar esses parâmetros, consulte o artigo 821268 da Base de Dados de Conhecimento Microsoft, Contenção, mau desempenho e deadlocks ao fazer solicitações de serviço Web pelos aplicativos ASP.NET.

Dois dos parâmetros explicados no artigo da Base de Dados de Conhecimento anterior devem ser definidos de forma diferente em um ambiente de intermediação por proxy do Exchange 2010. Recomendamos que você permita 36 threads por processador e que você defina o valor maxconnections como 2.000.

Para mais informações sobre o desempenho de servidor, consulte Gerenciando o .NET Framework no Windows Server 2003.

 © 2010 Microsoft Corporation. Todos os direitos reservados.