We rise up for the things we believe in over and over again
На этот раз просто DFS - Distributed File System, слава вышним, без R - Replication.
В кои-то веки решил сделать все, как говорится, по фэн-шую, чтоб красиво было:
dc-01 с адресом вида x.x.x.11
dc-02 с адресом вида x.x.x.12
Проблема в том, что второй контроллер назывался не вторым, а третьим, хотя адрес у него был уже тот, что хотелось. Вечером, когда пользователи уже покинули свои рабочие места, открыл RDP сеанс, ввел все необходимые команды для переименования компьютера (контроллеры начиная с Windows 2003 Server переименовываются так же, как и обычные члены домена), перезапустил сервер. Ожидаемо получил переключение своей машины на работающий первый контроллер, подождал, увидел, что dc-02 теперь стал именно dc-02 и уже вовсю обрабатывает запросы. С чувством выполненного долга, а так же прекрасного, ушел домой...
Наутро осознал всю глубину своей неправоты. Очень много звонков, и все с одной и той же проблемой - нет сетевых дисков. Ну два, ну три, ну пять таких звонков - это в порядке вещей, старое железо, будь оно неладно. Но когда их число перевалило за два десятка...
Начинаю вспоминать, что и как. Сетевые диски цепляются через систему DFS. DFS ссылки хранятся в AD, но обращение к ним идет через так называемые DFS Name Servers, в которые входят и наши контроллеры домена. Если клиент не может подключиться к ресурсу по DFS пути, при условии, что все права у него есть, и сеть тоже в наличии, значит он попал на Name Server, который в данный момент недоступен. В обычных условиях это допустимо, DFS такого клиента просто переключит на другой сервер, хотя на это нужно время. Но ведь все серверы активны!
Открываю оснастку DFS и понимаю, что все, да не все. Среди Name Servers по-прежнему значится dc-02, но под своим старым именем, что плохо. Ведь он по нему уже недоступен. Решение простое - удалить из списка этот сервер и добавить его заново. Удалил. А дальше - ступор, потому что повторное добавление заканчивается ошибкой. DFS говорит, что этот сервер уже является частью пространства имен, и добавить его вторично нельзя. Мол, воспользуйтесь оснасткой DFS для удаления сервера или используйте другой сервер. Приехали... Радует лишь то, что поскольку из списка DFS серверов убран сбойный - у пользователей проблем больше не будет. Но ведь надо его загнать назад, надо же все по фэн-шую...
Active Directory утверждает, что dc-02 не является частью DFS, сервер говорит ровно об обратном. Кому верить? Ответ очевиден - если DFS работает исправно, значит надо верить Active Directory. А в этом случае, нас ожидает приятное времяпрепровождение с утилитой dfsutil.exe:
dfsutil root remove <\\server\share>
Как бы не так. Ошибка выполнения и невозможность удаления DFS-ссылок. Придется действовать более жестко:
dfsutil diag viewdfsdirs < drive letter > removeresparse
Команда была выполена успешно. Все 6 ссылок убиты. Но и это еще не все. Открываем regedit и удаляем разделы по следующим путям:
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\DFS_ROOT
Поскольку в этот момент мы производим "настройку" сетевых папок через реестр - для применения изменений придется перезапустить сервер. Делать нечего, перезапускаем, после чего уже спокойно делаем его полноправным сервером пространства имен в многострадальной DFS.
Фэн-шуй, говорите? Может быть оно и хорошо, но все трижды проверять никогда не помешает.
В кои-то веки решил сделать все, как говорится, по фэн-шую, чтоб красиво было:
dc-01 с адресом вида x.x.x.11
dc-02 с адресом вида x.x.x.12
Проблема в том, что второй контроллер назывался не вторым, а третьим, хотя адрес у него был уже тот, что хотелось. Вечером, когда пользователи уже покинули свои рабочие места, открыл RDP сеанс, ввел все необходимые команды для переименования компьютера (контроллеры начиная с Windows 2003 Server переименовываются так же, как и обычные члены домена), перезапустил сервер. Ожидаемо получил переключение своей машины на работающий первый контроллер, подождал, увидел, что dc-02 теперь стал именно dc-02 и уже вовсю обрабатывает запросы. С чувством выполненного долга, а так же прекрасного, ушел домой...
Наутро осознал всю глубину своей неправоты. Очень много звонков, и все с одной и той же проблемой - нет сетевых дисков. Ну два, ну три, ну пять таких звонков - это в порядке вещей, старое железо, будь оно неладно. Но когда их число перевалило за два десятка...
Начинаю вспоминать, что и как. Сетевые диски цепляются через систему DFS. DFS ссылки хранятся в AD, но обращение к ним идет через так называемые DFS Name Servers, в которые входят и наши контроллеры домена. Если клиент не может подключиться к ресурсу по DFS пути, при условии, что все права у него есть, и сеть тоже в наличии, значит он попал на Name Server, который в данный момент недоступен. В обычных условиях это допустимо, DFS такого клиента просто переключит на другой сервер, хотя на это нужно время. Но ведь все серверы активны!
Открываю оснастку DFS и понимаю, что все, да не все. Среди Name Servers по-прежнему значится dc-02, но под своим старым именем, что плохо. Ведь он по нему уже недоступен. Решение простое - удалить из списка этот сервер и добавить его заново. Удалил. А дальше - ступор, потому что повторное добавление заканчивается ошибкой. DFS говорит, что этот сервер уже является частью пространства имен, и добавить его вторично нельзя. Мол, воспользуйтесь оснасткой DFS для удаления сервера или используйте другой сервер. Приехали... Радует лишь то, что поскольку из списка DFS серверов убран сбойный - у пользователей проблем больше не будет. Но ведь надо его загнать назад, надо же все по фэн-шую...
Active Directory утверждает, что dc-02 не является частью DFS, сервер говорит ровно об обратном. Кому верить? Ответ очевиден - если DFS работает исправно, значит надо верить Active Directory. А в этом случае, нас ожидает приятное времяпрепровождение с утилитой dfsutil.exe:
dfsutil root remove <\\server\share>
Как бы не так. Ошибка выполнения и невозможность удаления DFS-ссылок. Придется действовать более жестко:
dfsutil diag viewdfsdirs < drive letter > removeresparse
Команда была выполена успешно. Все 6 ссылок убиты. Но и это еще не все. Открываем regedit и удаляем разделы по следующим путям:
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\DFS_ROOT
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\DFS_ROOT
Поскольку в этот момент мы производим "настройку" сетевых папок через реестр - для применения изменений придется перезапустить сервер. Делать нечего, перезапускаем, после чего уже спокойно делаем его полноправным сервером пространства имен в многострадальной DFS.
Фэн-шуй, говорите? Может быть оно и хорошо, но все трижды проверять никогда не помешает.