Обзор

У нас есть DAG с двумя узлами Exchange 2016 CU12, работающими на последней версии Windows Server 2016.

Поиск не работает в любом почтовом ящике, находящемся в любой подключенной базе данных на одном из узлов . Другой узел работает правильно.

Событие 1012 неоднократно сообщается MSExchangeIS на затронутом узле со следующим содержанием (это конкретное неоднократно генерируется SearchQueryStxProbe работоспособностью monitor):

В хранилище информации сервера Exchange обнаружена ошибка при выполнении запроса полнотекстового индекса ("and (subject: string (" SearchQueryStxProbe * ", mode =" and "), folderid: string (" 3753F38349D8A943AE346EACDBD8B91300000000010C0000 ") ) "). Информация об ошибке: System.ServiceModel.EndpointNotFoundException: сообщение не может быть отправлено, потому что служба на адресе конечной точки 'net.pipe: // localhost / 3867' недоступна для протокола адреса.

Проблема, похоже, полностью не связанное с индексом контента, само событие и дальнейшая диагностика указывают на некоторую проблему, связанную с некорректной работой какой-либо части службы поиска на этом конкретном хосте.

Контрольный список

• Всего 48 баз данных. Симптомы присутствуют на всех из них одинаково, пока они смонтированы на пораженном узле.
• ContentIndexState сообщается о работоспособности во всех базах данных обоими узлами.
• Поисковые зонды SearchQueryFailureMonitor и SearchQueryStxMonitor возвращают нездоровое состояние на пораженном хосте.
• Test-ExchangeSearch практически ничего не возвращает ни на одном из хостов. Никаких объектов результата, никаких ошибок, только на некоторое время только индикатор выполнения. Никогда не использовал этот инструмент, поэтому не знаю, чего ожидать.
• База знаний Microsoft по набору работоспособности поиска - шутка (мягкими словами).
• На проблему не влияет сервис или перезапускается на уровне сервера.
• Поиск работает со всеми базами данных, когда база данных перемещается на второй узел DAG.

Google действительно возвращает множество сообщений по широкому кругу проблем, приводящих к событию 1012. К сожалению, 1012 явно покрывает широкий круг проблем. Ни одна проблема не совпадает с данными о моем событии и не представляет схожие побочные симптомы, но при этом дает какое-либо решение или ключ к тому, что тоже нужно искать.

Сравнительный анализ

Из-за отсутствия какой-либо разумной документации дальнейшие шаги были ограничены сравнительным анализом двух хосты - исправный и отказавший.

Следуя данным событий, я проверил привязку TCP 3867. На вышедшем из строя хосте порт не связан. На работоспособном хосте порт связан с экземпляром выполняемого службой процесса noderunner.exe со следующими аргументами:

"C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Runtime\1.0\NodeRunner.exe" 
--noderoot "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data\Nodes\Fsis\IndexNode1" 
--addfrom "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data\Nodes\Fsis\IndexNode1\Configuration\Local\Node.ini" 
--tracelog "C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\HostController\Data\Nodes\Fsis\IndexNode1\Logs\NodeRunner.log"

Я сравнил указанные файлы и пути на обоих хостах:

• Файл NodeRunner.log не создается ни на одном из узлов.
• Структура файла идентична, и средние размеры файлов аналогичны.
• Любые текстовые файлы содержат идентичное содержимое, за исключением ссылок на имена хостов.
• ] Права доступа к файлам идентичны.

Таким образом, явных различий нет. Кроме того, нет существенной разницы между каталогами поиска в реплицированных базах данных.

Вопрос

У кого-нибудь была подобная проблема? Кто-нибудь решил? У кого-нибудь есть подсказка, где смотреть? Какие-нибудь файлы журналов или инструменты диагностики?