Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Неведомый БАГ DC Windows 2016.

На минувшей неделе, столкнулись с интересным багом, по факту которого, всем отделом, так и не смогли понять, что именно произошло…

У нас 2 контроллера домена на Windows 2016 и почтовый сервак, пока на Windows 2008R2:

-GODC2 (виртуальный) SDC, DNS, GC.

-GODC3 (железный) PDC, DNS, GC.

-MAIL (виртуальный) EXCH2010.

В целом все работает достаточно стабильно и вроде без проблем. Но на минувшей неделе, при попытке зайти на GODC2 по RDP он вдруг повис и не пустил, далее впал в гидростопор и перестал отвечать.

Впал и впал, бывает… В этот момент обратили внимание, что система мониторинга  показала ошибку транспорта SMTP на «Чанге». Начали копать, и вдруг обнаружили интересную вещь: когда второй контроллер впадает в анабиоз, то «Чанга», тоже «втыкает», хотя основной контроллер GODC3 работает. Первичная диагностика показала, что  «Чанга» не видит GC основного контроллера GODC3.

Похожая проблема обсуждается здесь:

https://social.technet.microsoft.com/Forums/ru-RU/9a390d3b-4fac-4fcc-8191-34e5196622e0/-exchange-2010-could-not-find-any-global-catalog-in-forest?forum=exchange2010ru

Пытаемся провести первичную диагностику на GODC3, на контроллере все с виду в порядке: доступен и DNS и GC. Но интересный момент в том, что это все доступно только самому контроллеру, но недоступно другим серверам, в том числе «Чанге», из-за чего она и «воткнула».

В нормальной ситуации должно быть во так (если один, контроллер не доступен, то должен быть доступен второй и все равно светиться при запуске команды):

В нашей аварийной ситуации, это выглядело так: unknown query type: srv_gc.tcp.comp.loc. Как я уже выше писал, делаешь тоже самое на GODC3, и GC доступен, с других серверов соответственно нет.

Но на этом проблемы не закончились. GODC2 перезагрузился, вернулся в строй, прошла репликация, а Exchange так и не поднимался. Дальше, ровно так же, как несколько минут назад «воткнул» GODC2, «воткнул» и GODC3, при том на железке. Пришла мысль, что вероятно какое-то, вновь прилетевшее обновление, «кладет» контроллеры, при том, что все остальные сервера благополучно работали без проблем. Самое интересное, что так продолжалось часа полтора, мы несколько раз поочередно перезагружали контроллеры и пытались диагностировать, что именно их заставляет безответно подвисать (при том подвисать не сразу после загрузки, а в течении 10-15 минут после), но ничего подозрительного не было, репликация благополучно выполнялась, и все вроде как работало… Спустя пару-тройку перезагрузок обоих контроллеров, проблема исчезла также незаметно, как и появилась. Почта снова пошла и оба контроллера снова стали доступны почтовику.

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

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

Если кто-то сталкивался, или у кого-то есть предположения, прошу написать в комментариях? Прецедент не очень хороший.

В рамках проблемы еще раз погрузился в архитектуру (было интересно вспомнить), в случае необходимости, все это будет крайне полезно при траблешутинге:

https://blog.bissquit.com/windows/global-catalog/

https://dimanb.wordpress.com/2010/12/20/%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D1%8B-%D0%B3%D0%BB%D0%BE%D0%B1%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85-%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3%D0%BE%D0%B2/

Всем хорошей работы!!!

 

04.02.2020 Posted by | ms windows 2016 | Комментарии к записи Неведомый БАГ DC Windows 2016. отключены

Terminal Server на Windows 2016 (часть 3).

РОЛЬ УДАЛЕННЫХ РАБОЧИХ СТОЛОВ настроена, необходимо разрешить ПОДКЛЮЧЕНИЕ К ТЕРМИНАЛЬНЫМ СЕССИЯМ ПОЛЬЗОВАТЕЛЕЙ БЕЗ ИХ РАЗРЕШЕНИЯ НА ЭТО.

Задача: Настроить удаленное подключение на терминальном сервере к RDP сеансу пользователя.

Это можно сделать и руками, например, у каждого пользователя, имеющего доступ на терминальный сервер, можем снять вот эту галку: Запрашивать разрешение пользователя.

Если таких пользователей много, то это утомительно и долго…

Поэтому снова обращаемся в GPO.

Создаем отдельную политику TerminalUsers.

Связываем ее с необходимой OU, добавляем тех, кому это необходимо.

Далее правим:

Конфигурация пользователя-Административные шаблоны-Компоненты Windows-Службы удаленных рабочих столов-Узел сеансов удаленных рабочих столов-Подключения

 

gpupdate /force

Далее пробуем на сервере подключиться к RDP сессии пользователя:

Диспетчер серверов-Службы удаленных рабочих столов-Коллекции-1C-RDP

 

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

Всем хорошей работы!!!

 

19.09.2019 Posted by | ms windows 2016 | Комментарии к записи Terminal Server на Windows 2016 (часть 3). отключены

Active Directory траблешутинг. Зачищаем данные от нашего старого «битого» dc1 (часть 5).

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

В предыдущей части понизили контроллер домена до обычного сервера, теперь зачищаем базу AD.

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

https://www.gotoadm.ru/removal-of-the-failed-domain-controller-from-active-directory/

В этом нам поможет NTDSutil:

  • необходимо выполнить вход на работающий контролер домена под учетной записью администратора
  • запустить командную строку (cmd) и запустить утилиту ntdsutil
  • в командной строке ntdsutil необходимо ввести metadata cleanup и нажмите enter (появится приглашение на очистку метаданных)
  • далее вводим connections , в результате отработки этой команды будет выведено приглашение на подключение к серверу
  • теперь нужно подключиться к нашему исправному контролеру домена командой connect to server dc2, где dc2 — наш исправный DC
  • набираем quit и нажимаем ввод — появляется приглашение на очистку данных
  • введите select operation target
  • далее — list domains. Здесь необходимо запомнить число, которым обозначается вышедший из строя контролер домена, данное значение нужно будет ввести в следующей команде
  • select domain 0 (или ваше число)
  • list site и нажмите enter, здесь также необходимо запомнить число, под которым представлен сайт
  • select site 0 (или ваше число)
  • следующая команда — list servers in site. Необходимо запомнить каким числом представлен неисправный DC и ввести эту цифру в следующей операции
  • select server 1 или 0 (т.е. ваше число).
  • quit — появится приглашение на очистку метаданных
  • remove selected server и нажмите Появится сообщение. Тщательно прочитайте его и примите обдуманное решение («ДА»).
  • введите quit и дважды нажмите ввод — после очистки метаданных вы выйдите из утилиты ntdsutil

Описанным выше образом, мы удалили объект параметров NTDS. Теперь стоит перейти к последующей очистке базы данных — удалим записи из DNS и ADSIEdit.

Откройте консоль DNS. Последовательно раскрывая элементы иерархической структуры, найдите объект вашего домена и щелкните на нем. В правой секции окна найдите запись хоста (А; она должна совпадать с родительской папкой) с IP-адресом сервера DC1.test.loc (вышедшего из строя DC). Щелкнув на ней правой кнопкой мыши, выберите пункт «Удалить». При появлении окна подтверждения  щелкните кнопку «ДА». В той же секции окна щелкните левой кнопкой на записи хоста DC1 (вышедший из строя DC) и выберите пункт «Удалить». Нажатием кнопки «ДА» подтвердите  намерение удалить запись. Теперь запись DNS, соответствующая серверу DC1, удалена. Закройте консоль DNS.

Теперь перейдем к консоли ADSIEdit, запустив ее из командной строки (cmd) командой adsiedit.msc:

  • Раскройте структуру Domain\DC=ваш_домен,DC=__\OU=Domain Controllers. Щелкнув на записи объекта CN=DC1 (вышедший из строя DC), нажмите клавишу Delete. В окне подтверждения щелкните «ДА». Таким образом, объекта dc1 в контексте именования домена на Active Directory больше нет.

  • Раскройте структуру Configuration\CN=Configuration,DC=ваш_домен, DC=__\CN=Sites\CN=Default-First-Site-Name\CN=Servers. Щелкнув на записи объекта  CN=DC1, нажмите Delete. В окне подтверждение нажмите «ДА». Теперь в контексте именования для конфигураций нет объекта DC1. Закройте консоль ADSIEdit.

Процедура по правильному и полному удалению вышедшего из строя контролера домена (или одного из контролеров домена вашей компании) выполнена. В ходе проделанных операций мы удалили все ссылки в Active Directiry об устаревшем/неисправному контролеру.

*Только после проделанных операций стоит продолжать настройку нового, в моем случае, Primary DC (хотя сейчас роль PDC у меня теперь выполняет DC2)! (обратите на это внимание, так как без этих манипуляций, новый контроллер с таким же именем, вместо старого, поднять не удастся, на определенном этапе при развертке, он просто покажет ошибку и благополучно уйдет в гидростопор). 

Продолжение следует…

Всем хорошей работы!!!

14.05.2019 Posted by | ms windows 2016 | 1 комментарий