Сразу после развёртывания SharePoint Server 2016 и первого входа на веб-узел Central Administration мы можем увидеть критическое предупреждение встроенного механизма самодиагностики SharePoint Health Analyser о том, что учётная запись фермы (Farm account), используемая для работы ключевой службы SharePoint Timer Service (SPTimerV4), используется также и для запуска других служб, для которых рекомендуется настройка исполнения в контексте выделенной учётной записи.
-
SharePoint 2016 Health Analyser - The server farm account should not be used for other services - Сервисная учётная запись для служб SPTimerService (SPTimerV4) и Distributed Cache Service
-
Ошибка запуска службы MSDTC EventID 4691 "The run-time environment was unable to initialize for transactions required to support transactional components. Make sure that MS-DTC is running. (DtcGetTransactionManagerEx(): hr = 0x80004005)"
Это вторая история, ноги у которой, судя по всему, растут из первой. Дело случилось на одном из ранее описанных виртуальных серверов на базе Windows Server 2012 R2, имевших проблему первичной инициализации в механизме OOBE (Out-of-Box Experience) после клонирования диска ВМ, предварительно подготовленного с помощью sysprep. После развёртывания оба сервера были успешно введены в домен Active Directory и без каких-либо сложностей сделаны участниками нового кластера Windows Failover Cluster. И всё с виду было хорошо до тех пор, пока не настало время установки агента System Center DPM на оба этих сервера. -
Снова про SCOM Alert "DNS Service Stopped" и остановки службы DNS Client (Dnscache)
Продолжая тему, ранее затронутую в заметке Windows Server 2012 - The DNS service on server has stopped running, отметим, что описанная проблема с периодическими самопроизвольными остановками и повторными запусками службы "DNS Client" (Dnscache) актуальна и для Windows Server 2012 R2. И описанное в предыдущей заметке решение с включением в брандмауэре Windows Firewall разрешающего правила сетевого обнаружения "Network Discovery (LLMNR-UDP-In)" подтверждается статьёй Local IP address cannot be registered on DNS server after DNS Client service is restarted in Windows. Однако, если мы по каким-то причинам не желаем включать данное правило брандмауэра, можно воспользоваться ещё парой вариантов решения проблемы, которые мы обозначим в данной заметке. -
Windows Server 2012 - The DNS service on server has stopped running
Заметил на паре серверов с Windows Server 2012 одну особенность – периодически останавливающуюся службу DNS Client, о чем назойливо сообщал SCOM:
Alert: DNS Service Stopped Source: Microsoft Windows Server 2012 Standard Path: KOM-AD01-NPS01.holding.com Description: The DNS service on server KOM-AD01-NPS01.holding.com has stopped running
В эвент-логе на этих серверах можно было видеть события - сначала об остановке службы…
EventID 7036 The DNS Client service entered the stopped state.
и через некоторое время – о её повторном запуске..
EventID 7036 The DNS Client service entered the running state.
Судя по соседним событиям лога, никакого криминала в это время в системе не происходило и поэтому понять природу такого поведения клиента с наскоку не удалось. Интересно то, что на других серверах с Windows Server 2012 такого поведения службы DNS не наблюдалось и по сути эти два сервера отличались от других разве что только пониженной сетевой активностью. В ходе экспериментов удалось заметить то, что отключение Windows Firewall приводило к тому, что служба работала постоянно без остановок. Где-то на форумах в интернете (ссылку к сожалению не сохранил) наткнулся на информацию про то, что на новых системах DNS клиент может останавливаться в случае отсутствия активности. Как я понял, в Windows Server 2012 тип запуска службы DNS Client отображается как Automatic (Trigger Start), в отличие, например, от Windows Server 2008 R2, где он был Automatic, а служба при этом работала постоянно. Там же дали совет о том, что дабы заставить службу DNS Client работать без остановок, надо включить в правилах Windows Firewall разрешающее правило сетевого обнаружения - Network Discovery (LLMNR-UDP-In)
Так как в нашей сети работает DNS сервер, LLMNR нам на самом деле не нужен, но для "успокоения" SCOM этот метод оказался вполне работоспособным и вот уже более двух недель наблюдения на двух исходных серверах служба DNS Client работает без остановок.
Последние комментарии