Начнём, по традиции, издалека. Заказчик решил повысить уровень своего Microsoft Active Directory леса и домена с 2008 до 2012 R2. На самом деле, необходимость была только в повышении уровня до 2008 R2, но, учитывая сложность таких проектов в большой среде (а у заказчика было больше 1000 одних только Windows серверов в десятках географически распределённых локаций), Serice Owner принял решение переходить сразу на 2012 R2. Тем более, что актуальным серверным билдом на тот момент уже был Windows Server 2012 R2.
Для того чтобы повысить функциональный уровень, нужно сначала мигрировать все контроллеры домена на новую ОС. Процесс это, достаточно простой, с точки зрения Windows. Все сложности возникают в тех локациях, где реализована интеграция чего-нибудь стороннего с Active Directory средой. То есть почти везде:)
Перечисление всех проблем той миграции — это материал для нескольких статей. Сейчас же нам интересна только одна средних размеров локация — два контроллера, тысяча пользователей, два EMC Celerra NAS устройства (еще, конечно, сотня серверов, базы данных и приложения, но про них мы говорить не будем). Помимо общих ресурсов, NASы использовались для хранения профилей пользователей. Когда есть два контроллера в одном сайте, то процесс миграции значительно упрощается — мы можем мигрировать один контроллер и, если что-то пошло не так, его всегда можно потушить — второй-то остаётся (тут важно отметить, что к этому моменту уже успешно прошла миграция нескольких локаций и никаких особых проблем никто не ждал).
Итак, день Х настал и один из контроллеров был выведен из домена. Мы переставили ОС и заново подняли на нём роль. Сразу же стало понятно, что в этот раз без проблем не обошлось. У пользователей, которые получали новый контроллер в качестве Logon Server пропал доступ к их профилям и общим папкам. Вместо этого они видели грустное сообщение:
Мы потушили проблемный контроллер, создали под него отдельный искусственный сайт и добавили туда его IP адрес c /32 маской, перевели туда один тестовый клиент и начали тестирование (да, с этого можно было начать, но для экономии времени и ввиду низких рисков Service Owner разрешил включить контроллер сразу в живом сайте после конца рабочего дня). Недавно здесь была статья о full-stack администраторах. Это, без сомнения, очень классно, если у вас есть знания и права на всех устройствах, чтобы самому решить проблему. Чаще всего же в компании существует довольно жёсткое разделение команд на зоны ответственности и вы технически не можете проверить настройки NAS работая в команде поддержки Active Directory. Понятно, что раз проблема появилась после изменения вашего компонента инфраструктуры, то и проблемы, по умолчанию, на вашей стороне. Как найти причину ваших бед и получить аргументы для запроса на какие-то действия со стороны другой команды?
Бесценным инструментом будет анализатор трафика. Здесь я немного лукавлю — одно из важных отличий Windows 2008 от Windows 2012 R2 — новая версия SMB протокола, так что я догадывался в чём будет проблема. Мой любимый инструмент в таких случаях — Wireshark (не сочтите за рекламу). Быстрая установка, запуск capture, попытка получить доступ к общей папке и что же мы видим с логах обмена пакетами?
NegotiateProtocol Request
NegotiateProtocol Response
SessionSetup Request
SessionSetup Response
TreeConnect Request Tree:
TreeConnect Response
Ioctl Request
Ioctl Response, Error: STATUS_INVALID_DEVICE_REQUEST
Ioctl Response, Error: STATUS_INVALID_DEVICE_REQUEST показывает нам, что SMB сессий между пользователем и NAS устройством не установлена. Учитывая, что со старым контроллером всё работает, я получил подтверждение своей догадки — проблема в новой версии SMB. Вообще, NAS устройства в среде заказчика должны поддерживать новую версию SMB (в других локациях-то всё было нормально), так что следующей идеей стало поискать не нужно ли для этого обновить на них прошивку. Бинго! Форум вендора подтверждает нам, что старая версия прошивки Celerra не поддерживает обновлённый SMB. Информация отсылается команде поддержки NAS вместе с логами обмена пакетов, ссылками на сайт вендора и запросом на обновление прошивки. В следующие выходные прошивка обновлена и тесты подтверждают — теперь всё работает.
В качестве послесловия. Когда я рекомендую знакомым воспользоваться анализатором трафика для изучения какой-либо проблемы, самая частая причина почему человек не хочет этого делать — он думает, что это очень сложно. Это не так! В большинстве случаев, для того чтобы понять, что происходит, достаточно посмотреть на лог обмена пакетами ну и иногда прочитать KB статью о том, как устроен интересующий вас протокол. Это очень просто. И это может сэкономить вам кучу времени.
Комментарии (0)