Создание централизованной AD. Стандарты именования объектов. Часть 1

Перед тем как мигрировать объекты из старых доменов в новый, необходимо было придумать стандарты именований объектов Active Directory, таких как рабочие станции, серверы, группы, учетные записи пользователей и орг. юниты. Когда мы приходим к единой доменной структуре, нам нужны универсальные стандарты имен для всех площадок (филиалов). То, как именовались объекты в старых доменах нас абсолютно не устраивало. Тем более что в каждом домене именование было по предпочтениям местных администраторов и не было единого принципа. Начнем по порядку:

Рабочие станции:
Имена рабочих станций не должны быть привязаны ни к должности сотрудника, ни тем более к его имени. Рабочие станции должны быть привязаны к их физическому расположению и их принадлежности к тому или иному подразделению, филиалу, управлению, назовем это логической принадлежностью.
Начнем с привязки по физике. Можно разными способами обозначать площадку в имени рабочей станции, на которой находится компьютер. Мы выбрали кодирование площадки цифрами. Далее будет понятно, почему. Как это выглядит. Например, у Вас есть филиалы в Москве, Санкт-Петербурге и Ростове. Мы кодируем цифрами города, в которых находятся офисы.

Например:
Москва - 100
Санкт-Петербург - 200
Ростов - 300

Довольно легко запомнить. Идем дальше, Москва большая и у нас в ней не один офис, а несколько. Тогда именуем дальше:
Москва, Адрес 1, код: 101
Москва, Адрес 2, код: 102
Москва, Адрес 3, код: 103

В Санкт-Петербурге тоже пара офисов:
Санкт-Петербург, Адрес 1, код 201
Санкт-Петербург, Адрес 2, код 202

В Ростове один офис, значит просто оставляем 300.

Перейдем к логической принадлежности. Для примера рассмотрим ситуацию, когда в Москве у нас находится штаб-квартира (центральный офис, который контролирует работу всех остальных филиалов). Обозначим штаб-квартиру как HQ (Headquarters). Но так же в Москве находятся рабочие станции не относящиеся к HQ, а относящиеся к "рядовым" офисам. Обозначим такую принадлежность как MOS (Moscow). Суть в том, что по одному адресу у нас могут располагаться как компьютеры HQ, так и компьютеры MOS. Такая же ситуация может повторяться и с серверами.

Соответственно получаем следующее:
Москва, Адрес 1, Рабочая станция HQ: HQ101
Москва, Адрес 1, Рабочая станция MOS: MOS101

И так же с другими филиалами. Логическая принадлежность станции может быть к чему угодно (главные управления, штаб-квартиры, дочерние фирмы и прочее). Особенно в крупных компаниях разные сотрудники ответственны за IT-активы в разных филиалах. И так же, например, администраторы MOS не должны иметь доступа к станциям HQ. И так далее. Такое разделение добавляет немало гибкости.

Дальше надо обозначить, что это именно рабочая станция находится на данной площадке, а не сервер или, например, принтер. Значит надо придумать обозначение для рабочей станции. В данном случае все просто, рабочие станции обозначим двумя буквами WS (WorkStation). Плюс, надо различать станции между собой, поэтому вводим сквозную нумерацию внутри каждой площадки (логической и физической). Предполагаем, что на каждой площадке не более 100 компьютеров.

Итак, конечный вариант именования станции:
Москва, Адрес 1, Рабочая станция 1, HQ: HQ101WS001
Москва, Адрес 1, Рабочая станция 1, MOS: MOS101WS001
Москва, Адрес 1, Рабочая станция 2, HQ: HQ101WS002

Санкт-Петербург, Адрес 1, Рабочая станция 1, SPB: SPB201WS001
Санкт-Петербург, Адрес 2, Рабочая станция 1, SPB: SPB202WS001
Санкт-Петербург, Адрес 2, Рабочая станция 2, SPB: SPB202WS002

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

Об именованиях других объектов мы поговорим во второй части.

Фото с Московского Автосалона 2012

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

Lotus Bugs. "Невозможно поместить каталог на рабочую область"

По горячим следам напишу о новой обнаруженной проблеме в клиенте Lotus Notes 8.5.3. Пользователь обратился с проблемой, что при попытке открыть почтовую базу, Lotus выдает ошибку "невозможно поместить каталог на рабочую область". По какой-то причине клиент не мог подключиться к home серверу. При этом сервер доступен и нормально пингуется по короткому имени. Я попробовал выполнить трассировку средствами Lotus, иногда помогает, но тут он тоже не смог подключиться. Удалил cache.ndk. В результате просто перенастроил клиент с нуля. При настройке к серверу Lotus подключился без проблем. Далее скопировал desktop8.ndk и names.nsf, запустил и опять все в порядке. Значит ни локейшен, ни коннекшн документы тут не при чем. Видимо дело было в notes.ini. Разбираться с проблемой не было времени, поэтому решил инцидент перенастройкой клиента.