Tenho 99,99% de certeza de que o perfmon apenas usa o RPC. Do ponto de vista da porta, isso precisa de acesso à porta 135 no destino (servidor RPC), mas depois ao acesso subseqüente a uma porta efêmera. O firewall do Windows lida com isso muito bem, já que ele pode acompanhar a conversa do mapeador de pontos de extremidade do RCP (TCP 135) até a porta de comunicação subseqüente.
No entanto, o problema que você está descrevendo acima não tem nada a ver com conectividade. Um servidor Windows que ainda está respondendo ao PING, mas não pode ter o RDP'd e obtém "o caminho da rede não foi encontrado" está quase certamente experimentando a privação de recursos do kernel.
Muitas vezes, essas situações vêm e vão, mas pode ser frustrante e desafiador diagnosticar.
Eu começaria com:
- Verifique se o servidor está corrigido, especialmente os drivers de dispositivo de terceira parte
- Verifique se o seu software antivírus está atualizado. Os minifiltros de kernel dos fornecedores de AV são fontes notórias de inanição de recursos do kernel.
- Se o servidor for x86, considere seriamente mudar para x64. As limitações do espaço de endereço de processo de 4GB são obviamente eliminadas com x64.
- Garanta que você tenha memória física suficiente (vovó ... ovos, eu sei!).
- Verifique se o espaço total do arquivo de paginação é suficiente. Ignore as recomendações "memory * 1.5" (e similares) na web (o espaço total de paginação deve ser igual ao custo máximo de commit menos a sua RAM física). Você só vai trabalhar o seu max. Cometer cobrança monitorando seu servidor durante o pico de carga.
- Use o poolmon.exe para obter instantâneos do seu pool paginado e (mais importante) dos valores do pool não paginado. Compare seus instantâneos durante um período de tempo.
- Se um dos pools mostrar deltas cada vez maiores (ou seja, alocações > livres), descubra qual componente possui a tag do pool ofensivo. Se for um driver de dispositivo, atualize-o.
Boa sorte!