Como funcionaSolucionando problemas de RPC

Zubair Alexander

Se você trabalha com plataformas de servidor Windows há algum tempo, é provável que já tenha visto erros de RPC (chamada de procedimento remoto) uma vez ou outra. Eles dizem que o servidor RPC não está disponível ou que não há mais pontos de extremidade disponíveis ou oferecem algum outro aviso misterioso. Se essas mensagens o deixam confuso, continue a ler. Examinarei

alguns dos erros mais comuns, várias técnicas que podem ser usadas na identificação de erros de RPC exibidos e discutirei algumas soluções para problemas específicos. Mas antes de falar sobre erros e soluções específicos de RPC, vamos conhecer a sua terminologia.

O que é RPC?

O RPC é um método de IPC (comunicação entre processos) usado na comunicação entre clientes e servidores. Simplificando, o RPC é usado por programas, normalmente em um computador cliente, para executar um programa em um computador servidor. Por exemplo, os clientes Microsoft® Outlook® se comunicam com o Microsoft Exchange Server usando RPC. O computador cliente envia uma mensagem para o computador servidor com alguns argumentos. O servidor responde ao cliente com uma mensagem que contém os resultados do programa executado.

O ponto de extremidade integral neste processo — o nome, a porta ou o grupo de portas em um computador monitorado por um servidor para a entrada de solicitações de clientes. Mais especificamente, é um endereço de rede de um processo de servidor usado para RPCs.

O Mapeador de Pontos de Extremidade, parte do subsistema RPC, é o responsável por responder as solicitações dos clientes para a resolução de pontos de extremidade dinâmicos. Em algumas situações, ele também é o responsável pela atribuição dinâmica de pontos de extremidade a servidores.

Outro componente importante do RPC é o serviço localizador. Ele mantém uma lista de serviços e servidores RPC da rede. Um cliente Windows® se conecta ao controlador de domínio por meio de portas SMB (Bloco de Mensagens do Servidor) (TCP 139 e 445) e procura por serviços ou servidores RPC por meio do serviço localizador.

Quase todos os serviços internos do Windows se comunicam uns com os outros usando RPC. Por exemplo, os serviços de certificados, DCOM, FRS, MSMQ, MAPI, e o serviço de replicação do Active Directory® usam o RPC para a comunicação. Portanto, se o serviço RPC não estiver funcionando adequadamente em uma rede, você poderá ter alguns problemas de comunicação.

Erros de RPC

Agora vamos examinar alguns dos erros que você poderá encontrar quando o serviço RPC estiver com problemas (esta lista não constitui a relação completa dos problemas).

Quando o FRS (serviço de replicação de arquivos) falha, pode gerar o temível erro "RPC Indisponível" na rede. Se você tentar mapear uma unidade, obtém o erro "Acesso negado". Quando estiver usando o Usuários e Computadores do Active Directory, talvez você veja um erro que diz "O domínio especificado não existe ou não pôde ser contatado". A conexão no domínio pode gerar um erro que declara "O sistema não pode fazer logon neste domínio. A conta de computador do sistema no domínio primário não existe ou a senha da conta não está correta".

Quando o cliente Microsoft Outlook tenta se comunicar com o Exchange Server, as falhas de RPC podem confundir o cliente com erros como "As informações de logon fornecidas estavam incorretas" ou "Outlook não pode se conectar".

Além desses erros, é possível que você encontre outros problemas quando o serviço RPC não estiver disponível. Por exemplo, talvez você não consiga navegar pelo domínio em Meus locais de rede ou talvez não consiga abrir o snap-in Diretiva de Grupo.

Esses são apenas alguns dos exemplos em que talvez você não esperasse ter problemas com o RPC. Existem mais exemplos e, sempre que você estiver envolvido com processos remotos, os problemas de RPC poderão ser a principal causa das suas dificuldades. Dessa forma, como você pode ter certeza disso e, mais importante, como pode rastrear com precisão o erro? Vamos descobrir.

Solução de problemas

Se você suspeita do serviço RPC, existem diversas ferramentas que podem ser usadas no diagnóstico de problemas.

Uma opção é a ferramenta Repadmin. Esse programa é comumente usado para monitorar e solucionar problemas de replicação do Active Directory, mas também pode ser usado para solucionar problemas do Mapeador de Pontos de Extremidade RPC. Para executá-lo, no prompt de comando, digite repadmin /bind. Se houver problemas de RPC, talvez seja exibida uma mensagem como esta: "O Mapeador de Pontos de Extremidade não possui mais pontos finais disponíveis". Essa é a primeira pista que indica que o problema está relacionado ao RPC.

Outra opção é usar a ferramenta de diagnóstico do controlador de domínio (DCDiag), um programa de linha de comando para o diagnóstico de problemas com controladores de domínio. Se você encontrar o erro "Erro 1722: O servidor RPC não está disponível", saberá que há um problema de RPC que a ferramenta de diagnóstico do controlador de domínio acabou de descobrir.

Existem ocasiões em que você estará usando o Ntdsutil (uma ferramenta de linha de comando usada no gerenciamento do Active Directory e na execução de diversas tarefas de manutenção) e verá erros de RPC se tentar se conectar ao servidor. É mais provável que você veja um dos erros mais comuns, como "O Mapeador de Pontos de Extremidade não possui mais pontos finais disponíveis". Novamente, essa é uma pista que pode indicar a existência de problemas com o serviço RPC. A ferramenta Gpotool, que verifica a consistência de objetos de Diretiva de Grupo em controladores de domínio, também mostrará para você erros similares caso o RPC seja o culpado.

O Dcpromo.log gerado quando você promove um servidor Windows 2000 Server ou um Windows Server® 2003 para controlador de domínio usando a ferramenta Dcpromo também pode revelar problemas com o RPC. Por exemplo, se a promoção falhar, examine o log. Ele está localizado na pasta %windir%\debug. Os erros listados indicarão algo como o serviço de diretório tivesse falhado em replicar a partição ou falhado em criar o objeto. No final da mensagem haverá um código de erro. A seguir, um exemplo do tipo de mensagem de erro que pode ser exibida em Dcpromo.log:

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

Observe o código de erro 1722, que ocorre quatro vezes nessa mensagem e indica que o servidor RPC não está disponível. A Figura 1 lista alguns códigos de erros e suas descrições, mas você pode saber mais sobre eles no site msdn2.microsoft.com/ms681386.

Figure 1 Os códigos de erro e suas descrições

Solucionando erros de RPC

Agora que você já viu como alguns dos erros de RPC podem ser detectados, vamos examinar algumas das soluções.

Os clientes Microsoft se conectam ao Mapeador de Pontos de Extremidade RPC na porta 135. Em seguida, ele diz ao cliente em que porta o serviço solicitado está escutando. Os números de porta são atribuídos dinamicamente e podem ser qualquer número entre 1024 e 65.535. Quando erros forem exibidos, como o 1753, que dizem a você que não há mais pontos de extremidade disponíveis no Mapeador de Pontos de Extremidade, isso significa que ele foi incapaz de utilizar uma porta maior do que 1024 para um serviço. Explicarei esse tópico em mais detalhes um pouco mais adiante.

A primeira coisa que você deve fazer é verificar o status do serviço RPC no servidor. Dependendo do tipo da função de servidor, o serviço RPC e o Localizador RPC devem ter o status exibido na Figure 2. Se nenhum dos dois serviços estiver configurado como mostrado na figura, tente ajustar o status, reinicializar o seu servidor e verificar se isso resolveu o problema.

Figure 2 Status do serviço RPC

Verifique se o seu cliente pode fazer um ping bem-sucedido no servidor que estava com problemas de conectividade. Por exemplo, se você estiver tendo problemas de comunicação com um servidor chamado DC1, cujo endereço IP é 192.168.1.200, use o comando a seguir no prompt de comando para verificar se o DNS está resolvendo com sucesso o host DC1:

Ping –a 192.168.1.200

Não se esqueça de usar a opção –a com o endereço IP e não o nome do host.

Se tudo estiver funcionando, você obterá uma resposta de DC1 parecida com a resposta do ping mostrado na Figura 3. Observe que, em vez de simplesmente resolver o endereço IP 192.168.1.200, o Ping também resolveu o nome de host dc1.contoso.com. Isso confirma que a resolução de nomes DNS está funcionando corretamente e resolveu o nome do host dc1.contoso.com exatamente como esperado.

Figure 3 Resposta do ping

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms

Você também deve verificar se o registro do seu cliente Windows XP ou Windows 2000 contém pelo menos os quatro ClientProtocols listados no painel direito da Figura 4.

Figura 4** ClientProtocols do RPC listados no registro **

Se qualquer uma das entradas estiver ausente, adicione um novo valor de cadeia de caracteres com o nome e o tipo de dados mostrados na Figura 4. Por padrão, existe uma quinta entrada chamada ncacn_nb_tcp, usada para identificar NetBIOS sobre TCP como a família de protocolos para o ponto de extremidade. Dependendo da sua configuração, talvez você não tenha essa entrada listada em ClientProtocols, podendo adicioná-la manualmente para resolver os erros de RPC.

Observe as chaves listadas na pasta Rpc do painel esquerdo da figura, ClientProtocols, NameService, NetBios e SecurityService. Se houver uma chave chamada Internet sem valores, tente removê-la e reiniciar o seu computador. Isso pode ajudar a resolver o seu problema. Como sempre, tome cuidado ao modificar o registro do Windows.

Como mencionado antes, o RPC pode usar portas entre 1024 e 65.535 e, portanto, você precisa verificar se essas portas não estão bloqueadas em um firewall. A forma mais simples de verificar se uma porta está aberta é usar a ferramenta Port Query. Ela possui dois tipos: uma versão de linha de comando (PortQry) e uma versão GUI (PortQueryUI).

PortQry está disponível para download no Centro de Download da Microsoft. Para obter informações adicionais, leia o artigo "Descrição do utilitário de linha de comando Portqry.exe". Ali, você encontrará breves descrições dos relatórios de status do PortQry e exemplos de comandos a serem usados na resolução de problemas. Lembre-se de que você também pode usar a versão GUI, que é muito mais simples e pode ser baixada em go.microsoft.com/fwlink/?LinkId=73740.

Quando usar o Port Query, não se esqueça de executá-lo em um computador que não esteja tendo erros de RPC e execute-o direcionado a um computador que esteja apresentando problemas com RPC. Por exemplo, se você quiser verificar se a porta 135 — usada pelo Mapeador de Pontos de Extremidade RPC — está aberta, use o PortQry no prompt de comando como mostrado a seguir:

portqry -n [servername] -e 135

Usando o PortQuery ou o PortQueryUI, você obteria resultados semelhantes a estes:

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

A última linha mostra que a porta 135 está aberta. Caso contrário, ela teria indicado NOT LISTENING.

Para verificar um intervalo de portas, insira o intervalo de números de porta separado por vírgulas, como em "135,1024-5000".

Soluções adicionais

Se você já tentou todos os truques listados até aqui e o problema ainda não foi resolvido, ainda existem algumas opções adicionais abertas. Dependendo dos problemas específicos do seu ambiente, talvez seja melhor tentar uma das seguintes modificações no registro (Espere! Antes de fazer qualquer alteração, é importante verificar se você fez backup do sistema, especialmente do registro, para que, se algo der errado, possa restaurar o computador ao seu estado anterior).

Uma opção é ajustar MaxUserPort para especificar o número mais alto de porta que o TCP poderá atribuir quando um aplicativo solicitar uma porta de usuário disponível para o sistema. Por padrão, o Windows Server 2003 define o valor de MaxUserPort como 5000, o que significa que ele está usando 5000 como o número mais alto de porta, mesmo se a entrada não existir. Dependendo da sua configuração, talvez você não tenha essa entrada no registro, podendo adicioná-la ao local mostrado na Figura 5.

Figura 5** Configuração de MaxUserPort no registro **

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

Ao modificar o registro, você precisa estar atento a outros potenciais efeitos colaterais, o que nem sempre é fácil. A modificação dessa entrada pode causar impacto no Microsoft Exchange Server caso o valor seja definido como menor do que 50.000. Se o BPA (Best Practices Analyzer) do Exchange souber que o valor da chave do registro MaxUserPort é menor do que 50.000, exibirá um aviso. A Microsoft recomenda que você defina o valor como 60.000; caso contrário, isso poderá gerar avisos de proxy do NSPI (Interface de Provedor de Serviço de Nome), como o Evento 9040. Para obter mais informações, consulte o documento "O valor de MaxUserPort é muito baixo" da Microsoft.

Você também pode ajustar TcpMaxDataRetransmissions. Os pacotes TCP esperam uma confirmação da extremidade de recepção. Se não houver uma confirmação antes da expiração do tempo, então os pacotes serão retransmitidos, até o número de vezes estipulado em TcpMaxDataRetransmissions. O valor padrão desse parâmetro é 5, mas você pode experimentar um valor 4, ou até mesmo 3. Não utilize um valor abaixo de 3.

Se a entrada do registro TcpMaxDataRetransmissions não existir, adicione-a ao local mostrado como a seguir:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

Para obter mais informações sobre TcpMaxDataRetransmissions, leia o artigo 170359 da Base de Dados de Conhecimento Microsoft, "Como modificar o tempo de expiração de retransmissão máximo do TCP/IP".

Outro valor do registro que talvez você queira testar é TcpTimedWaitDelay. Se um cliente usar portas demais, é bem possível que ele fique sem portas antes de o TCP/IP liberar conexões encerradas. Isso acontece porque o TCP/IP não libera a conexão até que duas MSLs (vida útil máxima do segmento) tenham passado (nos referimos a isso como estado de espera de tempo). Além disso, já que cada MSL é definida como 120 segundos e o TCP/IP não libera a conexão até que duas MSLs tenham passado, o TCP/IP leva até 240 segundos (4 minutos) para liberar uma conexão encerrada. Observe que isso era um problema bem conhecido do Windows NT® e que foi corrigido em um service pack; como resultado, é bem menos provável que você tenha esse problema hoje. No entanto, a Microsoft recomenda o ajuste dessa configuração como uma das possíveis soluções de erros com o Mapeador de Pontos de Extremidade RPC, como explicado no artigo da Base de Dados de Conhecimento "Como solucionar problemas do Mapeador de Ponto de Extremidade RPC".

TcpTimedWaitDelay é adicionado ao registro no seguinte local:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

Para obter mais informações sobre TcpTimedWaitDelay, leia o artigo da Base de Dados de Conhecimento "Os clientes Windows NT ficam sem portas". Embora o artigo não recomende quaisquer números específicos, talvez seja bom tentar reduzir TcpTimedWaitDelay para 60 (segundos) em decimal, que é 3c em hexadecimal.

Conclusão

Os erros de RPC podem ser a principal causa de diversos erros de comunicação em sua rede. Felizmente, existem várias maneiras criativas de solucionar esses problemas enganosos. Algumas das ferramentas que sugeri aqui são internas, enquanto outras estão disponíveis no kit de recursos do Windows Server. Muitos estão listados na Figura 6. Você pode usar essas ferramentas para detectar a causa e o local dos erros de RPC e então usar uma das técnicas mostradas neste artigo para resolver os problemas.

Figure 6 Ferramentas de solução de problemas de RPC

Zubair Alexander, MCSE, MCT e Microsoft MVP, é o proprietário da SeattlePro Enterprises, uma empresa de treinamento e consultoria em TI. Sua experiência abrange toda a gama de educação em TI: autor, professor universitário, consultor, engenheiro de rede, orador, arquiteto de segurança, administrador de sistemas, editor técnico e instrutor. Entre em contato com ele pelo email alexander@techgalaxy.net.

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