Alterações na conectividade intersite do Acesso para Cliente RPC

Artigo original publicado em 30 de maio de 2012, quarta-feira

Quase dois anos atrás, eu apresentei uma sessão sobre considerações de design de alta disponibilidade no evento TechEd América do Norte 2010. Durante essa sessão, descrevi as alterações que estávamos fazendo na maneira como a conectividade MAPI deveria ocorrer após transferências de caixas de correio e eventos de failover/switchover de banco de dados intersite. Infelizmente, depois da minha apresentação eliminamos o recurso devido à complexidade das alterações que precisaríamos introduzir e à falta de tempo hábil para testes antes do lançamento do Service Pack 1. E, por mais que eu tivesse priorizado o trabalho, não conseguimos disponibilizar essas alterações no Service Pack 2.

Infelizmente, nem toda eliminação de recurso pode ser feita de maneira cirúrgica, e parte das alterações de código na verdade foram mantidas no SP1. Por exemplo, talvez você tenha percebido que o cmdlet Set-DatabaseAvailabilityGroup tem uma propriedade chamada AllowCrossSiteRPCClientAccess. Você pode alternar essa propriedade booliana à vontade, mas ela não afetará nenhuma alteração comportamental no produto (Eu sei, eu sei… é por isso que acho que esta imagem é estranhamente relevante):

Comportamento da conectividade intersite do Acesso para Cliente RPC (RTM, SP1, SP2 a SP2-RU2)

Mas vamos mudar de assunto. Primeiro, vamos tratar de alguns conceitos básicos.

Com o Exchange 2010, uma alteração importante foi instituída na maneira como os clientes conectam e acessam dados relacionados à caixa de correio. Diferentemente das versões anteriores, os clientes não se conectam mais diretamente ao Armazenamento de Informações na função de servidor Caixa de Correio para acessar dados da caixa de correio. Em vez disso, os clientes se conectam a um conjunto de serviços na função CAS (Servidor de Acesso para Cliente) e de serviços nos dados da caixa de correio de acesso à função CAS que usam MAPI/RPC do servidor Caixa de Correio em nome do usuário conectado. Pense nisso como uma camada de abstração.

Basicamente, foi feita uma alteração simples de maneira que toda a conectividade MAPI relacionada à caixa de correio passa pelo serviço de Acesso para Cliente RPC na função de servidor CAS. Para facilitar essa camada de abstração, foram feitas alterações de maneira que os objetos de banco de dados não são mais objetos filho dos servidores Caixa de Correio. Uma nova propriedade foi adicionada ao banco de dados Caixa de Correio, RPCClientAccessServer, que define o legacyExchangeDN que deve ser usado para acessar o banco de dados específico. Essa propriedade assume um FQDN como valor. Para garantir que você tenha alta disponibilidade e tolerância a falhas em caso de problema no CAS, esse valor deve ser o FQDN de uma matriz CAS com balanceamento de carga. Esse FQDN com balanceamento de carga é o que chamamos de matriz de Servidor de Acesso para Cliente RPC.

Para saber mais, veja as postagens de Brian Day sobre desmitificação do Objeto de Matriz CAS, Parte 1 e Parte 2.

Típica experiência do Outlook

Todas as versões do Outlook se comportam de maneira constante no cenário de um único datacenter (ou um único site do Active Directory). O ponto de extremidade RPC do perfil do Outlook é a matriz de Servidor de Acesso para Cliente RPC (ou um CAS específico se por algum motivo você não criou uma matriz - mas deveria ter criado -, e se você não sabe por que, vou repetir, leia as postagens de Brian). Sempre que uma falha ocorre no DAG (falha de banco de dados, falha de servidor etc.), o ponto de extremidade RPC não é alterado, assim o Outlook continua se conectando à mesma matriz de Servidor de Acesso para Cliente RPC. Sempre que ocorre uma falha na matriz CAS (falha de CAS, falha do balanceador de carga etc.), o ponto de extremidade RPC não é alterado, assim o Outlook continua tentando se conectar à matriz de Servidor de Acesso para Cliente RPC.

Todas as versões do Outlook se comportam de maneira constante em um cenário de switchover de datacenter também, pressupondo que você siga nossa diretriz. Por que é assim? Bom, em um switchover de datacenter, você altera o endereço IP da entrada DNS da matriz de Servidor de Acesso para Cliente RPC no datacenter primário para apontar para a respectiva matriz no datacenter de espera. A descoberta automática continua distribuindo a matriz do datacenter primário como ponto de extremidade RPC. Os clientes do Outlook existentes não precisam de nenhuma reconfiguração; depois que o cache DNS no cliente é atualizado, o cliente simplesmente se conecta ao ponto de extremidade que agora reside no datacenter de espera. Para entender totalmente por que isso funciona, é necessário assimilar que nem o cliente, nem o CAS realmente se importa com o site em que o CAS existe; eles simplesmente aceitam que podem se conectar e que o CAS ao qual o cliente está conectado pode oferecer acesso à caixa de correio.

Comportamento de failover/switchover de banco de dados intersite

Para entender esse cenário, é importante assimilar que, ao configurar um DAG de vários sites, a propriedade RPCClientAccessServer de um determinado banco de dados normalmente é associada à matriz de Servidor de Acesso para Cliente RPC que está no mesmo site do AD da cópia do banco de dados da caixa de correio com o menor número de preferência de ativação. Por exemplo:

Figura 1: DAG (Grupo de Disponibilidade de Banco de Dados) abrangendo dois sites do Active Directory

         

No caso de uma cópia do banco de dados ser ativada no datacenter de espera, os usuários continuarão aproveitando a matriz de Servidor de Acesso para Cliente RPC do site do AD em que o banco de dados da caixa de correio com o menor valor de preferência de ativação reside como ponto de extremidade de conectividade.

Figura 2: Banco de dados MDB1 foi ativado no site de espera do Active Directory

Se você examinar os logs de Acesso para Cliente RPC na matriz de Acesso para Cliente RPC de origem, verá:

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

No caso de a matriz de Servidor de Acesso para Cliente RPC do site do AD em que o banco de dados da caixa de correio com o menor valor de preferência de ativação reside ficar inacessível a outros usuários, os clientes do Outlook não poderão se conectar à caixa de correio que reside no datacenter oposto. Em outras palavras, há um evento de falha no datacenter e o processo de switchover de datacenter precisa ser executado.

Uma maneira mais simples de analisar esse comportamento é que o Outlook sempre se conecta ao ponto de extremidade RPC configurado (pressupondo que seja alcançável) independentemente do valor da propriedade RPCClientAccessServer do banco de dados.

O sistema alguma vez pode alterar o valor RPCClientAccessServer automaticamente?

A única vez em que o sistema altera o valor RPCClientAccessServer no banco de dados é quando o administrador altera o número ActivationPreference na cópia de banco de dados ativada de maneira que agora tenha o valor menor (significando que ela se torna a cópia preferida), conforme visto na Figura 3.

Figura 3: O banco de dados MDB1 foi ativado no site de espera do Active Directory e a propriedade RPCClientAccessServer foi alterada

Entretanto, os clientes do Outlook com um perfil do Outlook existente continuavam usando o antigo ponto de extremidade RPC em vez do novo ponto de extremidade RPC (mesmo se a Descoberta Automática detectasse a alteração). Isso ocorre porque o antigo ponto de extremidade RPC não retorna uma resposta ecWrongServer ao cliente. O ponto de extremidade RPC aceita a conexão; portanto, o Outlook ignora a resposta da Descoberta Automática porque ela tem uma conexão funcional. No caso de o antigo ponto de extremidade RPC ficar inacessível, o Outlook 2007/2010 atualizava suas configurações (o Outlook 2003, em contrapartida, não aproveitava e não aproveita a Descoberta Automática). A qualque momento, era possível forçar o Outlook a usar o novo ponto de extremidade RPC com um reparo de perfil.

O que acontece se o administrador atualizar manualmente o valor RPCClientAccessServer após um evento de failover/switchover de banco de dados intersite?

Voltando à Figura 2, se o administrador atualizar manualmente o valor RPCClientAccessServer para apontar para cas-sec.contoso.com no caso de MDB1 depois que a cópia do banco de dados da caixa de correio em MBX-C é ativada (cujo valor ActivationPreference é maior do que 1), os clientes do Outlook com um perfil existente continuarão usando o antigo ponto de extremidade RPC em vez do novo ponto de extremidade RPC, desde que o antigo ponto de extremidade RPC continue disponível (os reparos de perfil corrigirão o problema). Os perfis do Outlook criados após a alteração do valor RPCClientAccessServer usariam o novo ponto de extremidade RPC.

Transferindo caixas de correio intersite do Active Directory

Antes do Exchange 2010, quando você transferia caixas de correio entre servidores, o ponto de extremidade RPC do Outlook era atualizado para que apontasse para o servidor Caixa de Correio (ou uma instância do servidor Caixa de Correio em cluster) que hospedava o banco de dados em que a caixa de correio residia. Depois que a transferência de caixas de correio era concluída, o usuário do cliente do Outlook recebia a mensagem “O administrador do Exchange fez uma alteração que exige que o Outlook seja encerrado e reiniciado”. Depois de reiniciar o Outlook, o cliente era conectado ao novo ponto de extremidade RPC.

Com o Exchange 2010, talvez você tenha percebido que, ao transferir caixas de correio intersite do AD, os usuários não viam essa caixa de diálogo. Além disso, também não tinham o ponto de extremidade RPC atualizado para refletir a matriz de Servidor de Acesso para Cliente RPC associada ao banco de dados da caixa de correio no site do AD em que a caixa de correio residia. Isso ocorre porque o antigo ponto de extremidade RPC não retorna uma resposta ecWrongServer ao cliente. O ponto de extremidade RPC aceita a conexão; portanto, o Outlook ignora a resposta de Descoberta Automática porque tem uma conexão funcional. No caso de o antigo ponto de extremidade RPC ficar inacessível, o Outlook atualizava suas configurações (o Outlook 2003, em contrapartida, não aproveitava e não aproveita a Descoberta Automática). A qualquer momento, era possível forçar o Outlook a usar o novo ponto de extremidade RPC com um reparo de perfil.

Agora sim tenho certeza de que você entende a imagem do gatinho anterior.

O futuro… SP2 RU3 e versões posteriores

Eu nunca perdi as esperanças em abordar esses problemas. Alguns de nós ficaram feridos, mas a equipe de desenvolvimento do Acesso para Cliente RPC, a Equipe de Manutenção do Exchange e eu trabalhamos incansavelmente para fazer as duas alterações necessárias no produto. A primeira foi corrigir o perfil do Outlook quando uma caixa de correio simplesmente é transferida entre bancos de dados em diferentes sites do AD, enquanto a segunda alteração foi quando um banco de dados intersite executou failover/switchover dos resultados no Outlook usando um CAS que não é a escolha mais adequada para o local do banco de dados ativado no momento.

Transferências de caixas de correio

Por padrão, depois da instalação do SP2 RU3, quando você transfere caixas de correio intersite do AD, todas as versões do Outlook precisam ser reiniciadas e o ponto de extremidade RPC do perfil do Outlook é atualizado.

Se você examinar os logs do Acesso para Cliente RPC na matriz de Acesso para Cliente RPC de origem, verá:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Observe que a ROP (Operação RPC) é WrongServer (também conhecido como ecWrongServer). Isso força o cliente do Outlook a fazer uma descoberta de perfil e atualizá-lo com base nas novas informações encontradas no diretório. O perfil é atualizado e depois que o cliente é reiniciado, o cliente estabelece suas conexões com o novo ponto de extremidade RPC.

E, como já sei que farão esta pergunta: Quais outras condições garantirão a exibição da caixa de diálogo “O administrador do Exchange fez uma alteração que exige que o Outlook seja encerrado e reiniciado”?

1. Quando você especifica a propridade DoNotPreserveMailboxSignature em New-MoveRequest.
2. Quando os bancos de dados da caixa de correio de origem e de destino têm um armazenamento de hierarquia de pastas públicas diferente.
3. Quando você transfere a caixa de correio de uma versão existente do Exchange para o Exchange 2010.

Eventos de failover/switchover do banco de dados intersite

O comportamento dos eventos de failover/switchover do banco de dados intersite dependerá da propriedade do DAG AllowCrossSiteRPCClientAccess.  Se você definir o valor da propriedade AllowCrossSiteRPCClientAccess como $true, o comportamento que descrevi na seção anterior será o padrão - no caso de esse banco de dados ser ativado no datacenter de espera, os usuários continuarão aproveitando a matriz de Acesso para Cliente RPC no site do AD em que o banco de dados da caixa de correio com o menor valor de preferência de ativação reside como ponto de extremidade de conectividade.

Se você definir o valor da propriedade AllowCrossSiteRPCClientAccess como $false (o valor padrão da propriedade é $false), o ponto de extremidade RPC do perfil Outlook será atualizado para ser a matriz de Servidor de Acesso para Cliente RPC que está no mesmo site do AD em que o banco de dados está ativo e montado. Observe que a propriedade RPCClientAccessServer não é atualizada porque isso define o site preferencial.

Figura 4: o banco de dados MDB1 foi ativado no site de espera do Active Directory e o perfil do Outlook foi atualizado automaticamente

Se você examinar os logs de Acesso para Cliente RPC na matriz de Acesso para Cliente RPC de origem, verá:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Assim como no cenário de transferência de caixas de correio, o ROP WrongServer força o cliente do Outlook a fazer uma descoberta de perfil e atualizar o perfil com base nas novas informações encontradas no diretório. O perfil é atualizado e depois que o cliente é reiniciado, o cliente estabelece suas conexões com o novo ponto de extremidade RPC.

Conclusão

E aí está – com o SP2 RU3 (ou posterior) você pode garantir que as caixas de correio entre os sites do AD terão o perfil atualizado corretamente. Além disso, no cenário de failover/switchover do banco de dados intersite, você pode controlar se permitirá conectividade RPC intersite ou forçar o cliente do Outlook a usar a matriz de Servidor de Acesso para Cliente RPC que está no mesmo site do AD do banco de dados ativado e montado (o comportamento padrão). Acho apropriado encerrar assim:

Ross Smith IV
Gerente de Programa Principal
Experiência do cliente Exchange

Esta é uma postagem de blog traduzida. Consulte o artigo original em RPC Client Access Cross-Site Connectivity Changes