Get-StorageGroupCopyStatus falha com erro e0434f4d

Por Alessandro Goncalves

Ao trabalhar em um incidente de Exchange 2007 SCR com um problema em truncar os logs de transação após operações de backup , ao executar o seguinte comando para ver o estado da cópia tive o seguinte erro:

Get-StorageGroupCopy Status -Identity Ex2k7\SG01 -StandbyMachine Ex2k7-01

Get-StorageGroupCopyStatus : Microsoft Exchange Replication service RPC failed
: Microsoft.Exchange.Rpc.RpcException: Error e0434f4d from cli_GetCopyStatusEx
at Microsoft.Exchange.Rpc.Cluster.ReplayRpcClient.GetCopyStatusEx(Guid[] sgG
uids, RpcStorageGroupCopyStatus[]& sgStatuses)
at Microsoft.Exchange.Cluster.Replay.ReplayRpcClientWrapper.InternalGetCopyS
tatus(String serverName, Guid[] sgGuids, RpcStorageGroupCopyStatus[]& sgStatuse
s, Int32 serverVersion)

Ao verificar o código de erro verificamos que o serviço Microsoft Exchange Replication falhou ao uma chamada de RPC !?

Como o problema que estava me concentrando era o de os logs de transação não estarem sendo deletados após um backup, e a lógica de verificar se os logs estão sincronizados e foram aplicados ao database de destino é realizado pelo serviço de replicação , se o comando Get-StorageGroupCopyStatus falha , podemos considerar que os erros estão relacionados e que a causa tem uma grande chance de ser a mesma.

Um detalhe interessante é que a cópia de logs estava sendo realizada com sucesso , assim como o replay dos logs na base de destino. O único sintoma era o de os logs de transação não sendo apagados após um backup full / incremental e agora o erro no comando. Além disso o Exchange não apresentava problema nenhum.

Para entender a lógica de como as soluções de alta disponibilidade de Exchange 2007 funcionam em relação aos logs de transação , é sempre bom verificar o seguinte white-paper: CCR Deep Dive para a parte de log truncation.

Basicamente o que acontece é o seguinte : No Exchange o serviço de Information Store é responsável por deletar os logs no database ativo , utilizando ESE.DLL ou ESEBACKUP.DLL . Dependendo se temos replicação contínua habilitada e / ou circular logging habilitado ou não. O serviço de replicação , no servidore de destino CCR / SCR , e o Information Store trocam informações utilizando RPC sobre quais logs podem ou não serem apagados na fonte (servidor com a base ativa) . Após isso ESEBACK.DLL irá fazer a deleção dos logs. Para a base de cópia (passiva) o serviço de Replicação é responsável por eliminar os logs após o backup.

A lógica utilizada para considerar que um log de transação esteja pronto para ser apagado é a seguinte:

LCR/CCR

  • log foi salvo por backup.
  • A sequência de geração de logs está abaixo do nível do checkpoint.
  • A cópia passiva aplicou os logs na base de dados.

SCR

Além dos quesitos acima , todos os targets SCR devem ter inspecionado o arquivo de log.

No SCR , se as seguintes condições forem atendidas os logs de transação serão apagados:

  • A sequência de geração de logs está abaixo do arquivo de checkpoint
  • Aquivo de log é mais antigo que ReplayLagTime+TruncationLagTime
  • Aquivo de log foi deletado na origem.

Com essa informação em mãos temos certeza que o serviço de replicação e a deleção de logs de transação estão relacionadas e mais importante utilizam RPC para se comunicar , o que agregado ao erro ao rodar o Get-StorageGroupStatus temos que o serviço de replicação não consegue estabalecer uma comunicação RPC com o Information Store no nó ativo.

Passei então, a verificar a comunicação RPC entre os servidores , tudo parecia normal Event Viewer remoto , port query , Anti-Vírus , etc... Até que me lembrei de um incidente que trabalhei em um cluster Exchange 2003 que não podíamos criar o recurso de System Attendant , onde a causa raiz está na comunicação com o serviço de registro remoto. Verifiquei se o serviço estava ativo em ambos os servidores , e estavam. Neste ponto , começei a investigar se tínhamos alguma política de domínio que está impedindo comunicação RPC ou aplicando permissões no serviço de registro remoto.

Ao rodar um GPRESULT nos servidores verifiquei uma política modificando o seguinte caminho:

ObjectName:
MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

Ao verificar a permissão nas chaves de registro \SecurePipeServers\winreg = Serviço de Registro Remoto = Remote Registry , ela não estava de acordo com o seguinte artigo de suporte que diz respeito ao caso que mencionei de criação de recurso de cluster -  "You receive an "Access is denied" error message when you try to create the System Attendant resource on an Exchange Server 2003 cluster

Adicionei as permissões que faltavam de acordo com a seguinte lista:

 

Allow

Administrator

Full Control

This key only

Allow

Administrators

Full Control

This key only

Allow

Backup Operators

Read

This key only

Allow

Domain Admins

Full Control

This key only

Allow

Enterprise Admins

Full Control

This key only

Allow

EXCHANGE$

Full Control

This key only

Allow

Exchange Domain Servers

Read

This key only

Allow

LOCAL SERVICE

Read

This key and subkeys

Após confirmar que as permissões estavam apropriadas em todos os membros do cluster , o comando Get-StorageGroupCopyStatus retornou o estado correto da replicação e após realizar um backup , verificamos que os logs de transação começaram a ser apagados corretamente.

Muito obrigado e até a próxima.