Quais são as razões pelas quais os pipes nomeados do Windows local falham?

Estive trabalhando duro nisso o dia todo e estou presa. Hoje de manhã, nossos colegas asiáticos me ligaram porque um complemento do SolidWorks para o nosso sistema de gerenciamento de dados de produtos não pôde se comunicar com o aplicativo principal local. O problema afeta os computadores dos usuários finais em um domínio do Windows. Usamos os utilitários READPIPE e MAKEPIPE da caixa de ferramentas do servidor SQL para descobrir que o problema subjacente era o recurso de canal do Windows.

O utilitário MAKEPIPE cria um canal e está aguardando um cliente. O utilitário READPIPE retorna: "Falha ao abrir o tubo. Status 53." De acordo com http://support.microsoft.com/kb/110905 , significa que o nome da rede não foi encontrado. No meu computador local, os tubos enviam um "olá" de READPIPE para MAKEPIPE sem problemas.
O processo do servidor que permite pipes nomeados está em execução.
As configurações em HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Lanmanserver \ Parameters parecem bem. Nenhuma configuração de firewall de tubulações.
O problema afeta alguns usuários, mas não todos. Não fizemos alterações nos grupos de domínio, exceto em alguns grupos de compartilhamento de rede.
Entrei como administrador e os canos ainda não funcionam.

Qualquer ajuda é apreciada! Obrigado.

windows pipe windows-domain

— user152700
fonte

Os usuários afetados podem se conectar a compartilhamentos de arquivos comuns no servidor em questão?

— Harry Johnston

Atualmente, não há problemas com ações. Este não é um problema de servidor / cliente. Ambos os processos estão no mesmo computador.

— user152700

Quando você reproduz o problema, conectado ao computador afetado como administrador, com READPIPE e MAKEPIPE, quais são os comandos exatos que você está usando? (Por favor, editar a sua mensagem para incluí-los em vez de colocá-los em um comentário.)

— Harry Johnston

Obrigado por seu apoio. Foi difícil e documentarei a solução aqui.

— user152700

Foram necessários 1,5 dias para descobrir todos os casos. Aqui para documentação.

Sintomas

Arrastar e soltar nos aplicativos não funciona.
A comunicação entre processos, por exemplo, entre o aplicativo principal e os suplementos não funciona.

Causas / antecedentes

A comunicação entre processos é implementada para alguns aplicativos através de pipes nomeados do Windows (para não confundir com os pipes de estilo UNIX). Consulte a documentação do MSDN: http://msdn.microsoft.com/en-us/library/aa365590.aspx

Pode haver causas diferentes para os pipes de nome do Windows não funcionarem. Para verificar se os tubos são a causa do problema, as ferramentas MAKEPIPE e READPIPE podem ser usadas. Este artigo da KB descreve o procedimento de teste: http://support.microsoft.com/kb/68941 O explorador de processos da ferramenta Sysinternals também pode ser útil para procurar quais canais estão abertos no momento. Use a opção "Localizar -> Localizar identificador ou DLL ..." e digite o padrão "\ Device \ NamedPipe \". Ele mostrará quais processos têm quais tubos abertos. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Solucionar problemas

Causa 1: O aplicativo está bloqueado pelo firewall do Pipes

O Windows pode impedir que aplicativos usem pipes nomeados. Esse firewall normalmente não está ativado e é configurado através do registro. Consulte o artigo de suporte da Microsoft aqui: http://support.microsoft.com/kb/925890 . Verifique se o firewall de pipes não está ativado ou adicione Keytech e todos os suplementos à lista de aplicativos permitidos.

Causa 2: O serviço de compartilhamento de arquivos e impressoras não está ativado.

Os pipes nomeados são ativados pelo processo que também controla o compartilhamento de arquivos e impressoras. Verifique se esse processo está sendo executado usando a ferramenta Serviços do Windows. O nome do serviço é mostrado como "Servidor" na lista de serviços. O nome do serviço é LanmanServer e o EXE é C: \ Windows \ system32 \ svchost.exe -k netsvcs

Causa 3: O firewall do Windows está bloqueando o LanmanServer

O firewall do Windows pode bloquear pipes nomeados, mesmo quando eles são usados apenas para comunicação entre processos na mesma máquina. Especialmente, regras de domínio e firewall local podem causar um conflito. Duas entradas na lista "Programas permitidos pelo Firewall do Windows" indicam um conflito. Na maioria dos casos, esse problema pode ser resolvido usando a janela "Verificar status do firewall". Se essa janela mostrar uma opção para definir as regras recomendadas de firewall, os pipes poderão ser desbloqueados com frequência usando essa opção. Em combinação com as regras de firewall do domínio, às vezes é necessário desconectar o PC primeiro do domínio e permitir o serviço de compartilhamento de arquivos e impressoras.

— user152700
fonte

Causa 1) O firewall de pipes afeta apenas o acesso remoto aos pipes nomeados. Observe, no entanto, que a conexão a um pipe nomeado usando \\ nome da máquina \ nome do canal provavelmente conta como acesso remoto, mesmo que o nome da máquina seja a máquina local.

— Harry Johnston

Causa 2) Da mesma forma, o compartilhamento de arquivos e impressoras é necessário apenas para acesso remoto a pipes nomeados. Novamente, \\ nome da máquina \ nome do canal provavelmente conta como acesso remoto para esse fim.

— Harry Johnston,

Causa 3) O Firewall do Windows não deve conseguir bloquear conexões locais, mesmo se estiver usando \\ nome da máquina \ nome do canal. No entanto, se você estiver em um domínio e o Firewall do Windows estiver mal configurado, poderá ter problemas mais comuns, talvez relacionados à autenticação.

— Harry Johnston

@HarryJohnston Que tipo de autenticação pode ser bloqueada? Como ServiceHost.Authenticationdescrito aqui ?

— ICantSeeSharp

Se você estiver em um domínio e seu acesso de rede aos controladores de domínio estiver bloqueado pelo Firewall do Windows (ou por algum outro motivo), talvez você não consiga se autenticar. Isso realmente não deve afetar o acesso ao canal local, mas o YMMV.

— Harry Johnston