Применимо к: 
да да да 
нет SharePoint Online APPLIES TO: 2013 2016 2019 SharePoint Online
Имя правила: "Адаптер прослушивателя Net.Pipe недоступен". Rule Name: The Net.Pipe Listener Adapter isn’t available.
Сводка. Адаптер прослушивателя Net.Pipe это служба Windows, которая получает запросы на активацию по протоколу net.pipe и передает их Службе активации Windows. Summary: The Net.Pipe Listener Adapter is a Windows service that receives activation requests over the net.pipe protocol and passes them to the Windows Process Activation Service.
Причина. Если служба адаптера прослушивателя Net.Pipe не установлена или не запущена, правило анализатора работоспособности SharePoint вызывает оповещение. Cause: If the Net.Pipe Listener Adapter service is not installed or started then the SharePoint Health Analyzer rule triggers an alert.
Решение. Запустите службу адаптера прослушивателя Net.Pipe на сервере Resolution: Start the Net.Pipe Listener Adapter service on the server
Убедитесь, что учетная запись пользователя, с помощью которой выполняется данная процедура, является участником группы администраторов фермы. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
В диспетчере серверов последовательно выберите элементы Средства и Службы. In Server Manager, click Tools, and then click Services.
Я использую протокол net.tcp для различных веб-сервисов. Когда я перезагружу свой MacBook Pro для Windows 7 Ultimate (64-разрядный), служба никогда не перезапускается автоматически, даже если это так, как они установлены:
Error 6/9/2011 19:47 Service Control Manager 7000 None The Net.Tcp Port Sharing Service service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion."
Error 6/9/2011 19:47 Service Control Manager 7009 None
A timeout was reached (30000 milliseconds) while waiting for the Net.Tcp Port Sharing Service service to connect.
Этот пост предполагает, что это что-то еще , блокирующее порт (в сообщении это SCCM 2007 R3 Client , которые я не использую).
Что еще может быть проблемой? Если это что-то другое, блокирующее порт, как мне понять, что? Когда я вручную запускаю службы, они запускаются правильно.
Служба обмена портами Net.Tcp
АдаптерпрослушивателяNet.Tcp
По-прежнему не повезло, но я думаю, что проблема может заключаться в том, что мое сетевое соединение занимает слишком много времени. Я ввел пользовательский вид журнала событий и нашел следующие элементы:
В моем текущем проекте мы (я имею в виду "команда проекта" ) используют службы WCF, размещенные в IIS.
Вот некоторые технические детали, которые могут быть важны:
- Мы используем NET 3.5 для служб WCF
- Мы используем протокол связи NET.TCP
- Мы используем IIS 7 и IIS 7.5 для размещения этих служб.
- Мы используем несколько рабочих процессов IIS на каждом сервере.
Итак, проблема в том, что иногда WCF-сервисы становятся недоступными. Когда мы пытаемся достичь этих WCF-сервисов, мы получаем ошибку тайм-аута. И единственным способом восстановления работы WCF-сервиса является перезапуск службы Windows NetTcpActivator (Net.Tcp Listener Adapter).
Согласно моей теории коллег, эта ошибка может быть связана с проблемами, описанными в этой статье в KB:
ИСПРАВЛЕНИЕ: Smsvchost.exe для службы WCF перестает отвечать при запуске службы WCF на основе .NET Framework 4 http://support.microsoft.com/kb/2536618 p >
В соответствии с этой статьей, SMSvcHost (контейнерная служба, в которой размещаются NetTcpActivator и служба совместного доступа к портам) зависает, если она не может перенаправить запрос на w3wp (рабочий процесс IIS) более чем за 60 секунд (неконфигурируемый таймаут). К сожалению, мы не можем найти способ воспроизвести эту ошибку. Например, мы ограничили SMSvcHost до 1 ядра процессора и 1 поток, а расширенные ожидающие подключения ограничили 1M и нажали на 100% загрузку процессора в пользовательском режиме. И это не зависало!
Иногда наши тесты нагрузки приводят к странным ошибкам, но когда мы останавливаем их, все службы автоматически восстанавливаются до нормального состояния. Но иногда невесная загрузка может повесить NetTcpActivator!
Кроме того, я хотел бы сказать, что это не новая проблема. Мои коллеги уже получили это 3 года назад (см. Эту тему для дополнительной информации http://forums.iis.net/t/1167668.aspx/1/10). И, к сожалению, они не получили ответа. Проблема исчезла после некоторых изменений конфигурации! И теперь он вернулся на новый сервер.
Я буду очень благодарен всем вам за мысли и идеи!
Хорошо, после многих исследований я выяснил причину нашей проблемы. Могут быть другие сценарии, где это происходит, но, надеюсь, это поможет некоторым людям. Microsoft находится в процессе воспроизведения в своих лабораториях и в конечном итоге нуждается в исправлении.
В нашем случае все планеты должны были выровняться. У нас был один интегрированный пул приложений .NET 4 для клиента и сервера (на машине разработчика). Служба использовала внешний файл конфигурации для привязок (), который был связан с другим проектом и скопирован во время сборки с заданием пользовательской сборки, добавленным в службу .csproj.
Чтобы воспроизвести проблему:
- Остановите все запущенные службы SMSvcHost (Net.Tcp *, Net.Pipe, Net.Msmq). Перезапуск не будет работать, поскольку процесс SMSvcHost не исчезнет.
- В Visual Studio запустите средство очистки для WcfService
- Из проводника Windows удалите serviceModel.bindings.config в WcfService
- Запустите iisreset (избавляется от w3wp и запускает службы SMSvcHost — нажмите F5 — список служб, чтобы увидеть это)
- Сборка WcfService (копирует связанный файл конфигурации)
- Перейдите на страницу WcfClient, отправьте дважды. Если вы каждый раз получаете сообщение об ошибке, у вас, вероятно, проблема. В нашем основном приложении он предоставлял тайм-аут в тестовом приложении CommunicationObjectFaultedException вместо таймаута, но все в порядке.
- Остановить службы SMSvcHost. Если возникла ошибка, в журнале событий системы регистрируется событие 8 для SMSvcHost.
Я еще не знаю, является ли виновником w3wp или SMSvcHost. Шаг №3 имеет решающее значение, хотя пока не могу объяснить, почему. Если вы не удалите файл, все будет в порядке. Если вы измените файл (дата создания остается неизменной), все в порядке. Если вы переместите XML-конфигурацию в основной файл Web.config, все будет в порядке. Когда задача сборки копирует файл, обновленная дата обновляется, поэтому я предполагаю, что он кэширован каким-то образом, и один из процессов обнаруживает изменение даты.
Если вы перезапустите службы SMSvcHost (полная остановка, полный старт) один или два раза, клиентский запрос пройдет, и с этого момента вы все равно.
Итак, теперь я предполагаю, что это может быть проблемой сразу после развертывания, но если вы убедитесь, что все работает (и при необходимости перезапустите службы), то все должно быть в порядке. Вы также не можете выполнять внешние/связанные файлы.
Как только Microsoft отменит эту проблему, я надеюсь, у вас будет больше понимания.
Окончательное обновление Я забыл вернуться к этому раньше. Microsoft по сути признала, что у них, вероятно, была ошибка, но поскольку было обходное решение и потратил достаточно времени на билет, они закрывали его, а не изучали дальше. Кажется, что какой-то тип расы, когда SMSvcHost запускается со следующей установкой (аналогично тому, что я опубликовал ранее):
- Host WCF в IIS
- Используйте привязку не к HTTP, чтобы вставлять SMSvcHost
- Используйте внешний файл конфигурации для привязок с помощью configSource
Связывание внешней конфигурации не имело к этому никакого отношения. Обходной путь состоял в том, чтобы не использовать configSource , который мы делаем сейчас.