Comments 30
и если мне внезапно надо найти компьютер иванова ивана ивановича то я просто набираю HQ131WS543 и я там… очень удобно!
В Active Directory компьютер легко можно найти по описанию. В описании указывается ФИО сотрудника и должность. Плюс разделение рабочих станций по орг. юнитам. Выбрали нужный Вам орг. юнит, отсортировали по описанию, все довольно быстро находится. Плюс, это довольно стройно выглядит в самой AD. Привязывать имя компьютера к конкретному человеку не считаю целесообразным. В качестве примера: уволился сотрудник, за его компьютер сел другой человек. Мне никаких операций по переименованию учетной записи компьютера выполнять не надо. А смена кадров в более или менее крупных компаниях дело не такое уж и редкое. Далее, опять же проблемы с однофамильцами и с именами людей полностью совпадающими друг с другом. Их хватает и для учетных записей, а тут еще и с компьютерами разбираться придется. В общем, мы думали насчет разных вариантов и данный, для компании с разветвленной структурой, нам показался наиболее удачным.
да, но я вот в FAR-е нажимают быстрый поиск ставлю "*" и далее кусок фамилии пишу, быстрый поиск перекидывает меня к нужному хосту… но тут согласен не совсем корректно сравнивать, т.к. можно наверное было бы делать в far-e более продвинутый поиск который искал бы и в описании тоже… но тем не менее…
т.е. я как бы не против совсем HQ131, но как по мне так запись HQ131PETROVPP более читабельна, ну и понятно что при смене владельца надо будет выкинуть из домена хост.
Как вариант, но опять же не дает полную уникальность имени учетной записи компьютера в домене. Ну и каждый раз переименовывать машину тоже мне не хочется, потому что, например, у нас в компании смена персонала не такая редкость. К тому же, у меня всегда открыта оснастка, где я быстро нахожу все что мне надо по любым критериям. Еще конечно есть программный комплекс по управлению IT-активами, где все это ищется еще быстрее. В общем у меня и у коллег никаких проблем с поиском компьютеров нет и в самой структуре AD все очень неплохо выглядит. А с использованием ФИО в имени машины просто больше проблем, а лишней работы себе не хочется добавлять. Для нас такое именование оказалось самым выгодным. Именно для нас. Для других специалистов могут быть удобней совсем другие варианты.
Но надо обязательно добавлять в AD в комментариях какой пользователь работает за той или иной рабочей станцией.
В logonscript добавьте добавление имени последнего залогинившегося пользователя в поле комментария к АД-аккаунту машины. Получите стопроцентно верную и оперативную информацию.
Можно. Но тут есть нюансы. Не так редко пользователи заходят под своими учетными записями на другие компьютеры. А мне надо знать реального владельца рабочей станции, а не того, кто в данный момент работает. У нас есть ПО, у него алгоритм определения владельца следующий: владельцем считается тот, кто выполнил вход на компьютер более 5 раз подряд. Зачастую я пользуюсь им для поиска информации и для актуализации данных в AD (например, если забыли ввести описание для компьютера и мы не знаем чей он).
А мне надо знать реального владельца рабочей станции
А для чего, кстати?
Просто если речь о техническом обслуживании станции, производимом по заявке конкретного владельца, то этот владелец обязан указать имя станции в сервисной заявке. Без вариантов.
Другое дело, что чаще всего станция в момент подачи заявки еще работает, и заявка подается онлайн с автоматическим добавлением необходимой информации. Но если вдруг не онлайн — то пользователь вписывает имя руками.
Это не создает практически никакой нагрузки на пользователей, но снимает ее с IT-отдела.
Например, служба безопасности спрашивает: нам нужно имя компьютера Матвеевой Ирины Петровны, чтобы выяснить некие обстоятельства, прямо сейчас, по горячим следам. Я смотрю в AD имя машины по описанию и кидаю им. Оказывается это не компьютер Матвеевой, а другого пользователя, а она просто зашла на него по той или иной причине.
Может немного утрировано, но на самом деле имя компьютера в данную секунду может понадобиться по самым разным причинам.
Кстати, по поводу заявок и вообще сервис-менеджмента. У нас сформирована CMDB (Configuration Management Database), откуда актив (в данном случае рабочая станция) при подаче пользователем заявки через Service Desk подставляется автоматом. Но это к слову, потому что в данном случае динамическое обновление описания в AD роли не сыграет. Надо будет отдельно подискутировать на тему ITSM, очень она мне нравится.
Может немного утрировано, но на самом деле имя компьютера в данную секунду может понадобиться по самым разным причинам.
Кстати, по поводу заявок и вообще сервис-менеджмента. У нас сформирована CMDB (Configuration Management Database), откуда актив (в данном случае рабочая станция) при подаче пользователем заявки через Service Desk подставляется автоматом. Но это к слову, потому что в данном случае динамическое обновление описания в AD роли не сыграет. Надо будет отдельно подискутировать на тему ITSM, очень она мне нравится.
Получите лишний трафик репликации. Особенно, если сотрудников много и компания сильно территориально-разнесённая.
А если сотрудников много и сидят они все в одном месте, то получите лишнюю нагрузку на DC в час-пик.
А если сотрудников много и сидят они все в одном месте, то получите лишнюю нагрузку на DC в час-пик.
дополнительно можно еще добавлять должность или пренадлежнсоть к депортаменту
HQ101WSIT001
HQ101WSHR001
тем самым можно напрмер выделить всех HR или IT всех регионов, удобно для посторения групповой политики по фильтрам безопастности итд
HQ101WSIT001
HQ101WSHR001
тем самым можно напрмер выделить всех HR или IT всех регионов, удобно для посторения групповой политики по фильтрам безопастности итд
Имхо, для таких целей уже надо использовать org units, а не добавлять в имя компьютера наименование отдела, департамента и т.д.
например задача, вам нужно сделать определенную политику для всех региональных IT или HR и вы будете добалять политику к каждому OU, не легче через security filtering
В данном случае я бы воспользовался фильтрацией политики по группе безопасности. А в группу накидал бы нужных мне машин из орг. юнитов. Потому что еще больше нагромождать имя компьютера не хочется и я придерживаюсь логики, что структуру организации должны отражать орг. юниты, а физическую принадлежность имена машин. А в самой группе по описанию рабочей станции видно, к какому отделу принадлежит компьютер. Опять же мое мнение, просто мне кажется так удобней.
Замечательно! Взяли иерархическую БД, и всю иерархию закодировали в одну никому не понятную строку…
Про иерархию и ее организацию хотел написать в другой статье. Пока самое простое, что я могу ответить, это то, что мне необходима уникальность учетной записи внутри всего домена, а не внутри конкретного орг. юнита. Иначе AD не даст создать учетную запись станции. Возьмем орг. юнит MOS и орг. юнит HQ, я не могу и там и там создать просто WS001 и WS001. К тому же, в моем понимании, орг. юниты служат для отражения организационной структуры компании (отделы, департаменты и т.д.). А тут все завязано в основном на физической привязанности, а не привязанности к структурному подразделению компании.
Как только добавиться 10 город придется переименовывать все компьютеры?
Нет, почему же. Я просто принцип именования рассказал. Если у Вас 10 и более городов, можете использовать немного другую кодировку месторасположения.
Я про о что данный способ очень плох для масштабирования, даже если вроде все предусмотреть.
Я в 2000 году по своей неопытности решил раздавать 10.х.х.х.х IP адреса по локалке путем привязки второго октета к району, третьего к сегменту. Ну не предполагалось совершенной что в одном районе может быть 255 сегментов по 255 пользователей, а оно вот так и получилось.
Я в 2000 году по своей неопытности решил раздавать 10.х.х.х.х IP адреса по локалке путем привязки второго октета к району, третьего к сегменту. Ну не предполагалось совершенной что в одном районе может быть 255 сегментов по 255 пользователей, а оно вот так и получилось.
Это получается 65к пользователей в одном районе? Недурно, с такими масштабами я не сталкивался, и мне пока трудно рассуждать в данном случае. Какой способ именования компьютеров используется у Вас? Очень интересно. Просто я сужу только исходя из своего опыта и я уверен на 100%, что наша компания настолько не разрастется, но все равно мы все взяли с запасом.
Намного удобнее комбинировать данный способ с разбиением по OU.
а в подобных «шифровках» будет очень сложно разбираться, особенно если не подскажут «старожилы»
а в подобных «шифровках» будет очень сложно разбираться, особенно если не подскажут «старожилы»
«Намного удобнее комбинировать данный способ с разбиением по OU.»
Можно пример? Как у Вас именуется компьютеры и по какому принципу построены OU?
В шифровках разбираться несложно, по своему региону все быстро запоминается. Старожилам не надо подсказывать, должен быть документ описывающий маппинг кодов и площадок.
Можно пример? Как у Вас именуется компьютеры и по какому принципу построены OU?
В шифровках разбираться несложно, по своему региону все быстро запоминается. Старожилам не надо подсказывать, должен быть документ описывающий маппинг кодов и площадок.
Разбиение по OU
Workstations->SPB->Office1->Users
->Computers
А дальше уже соответственно сами компы TC101 — для Thin Client, AW101 — для раб станций, NB101 для ноутбуков
Досаточно удобно, имхо
Workstations->SPB->Office1->Users
->Computers
А дальше уже соответственно сами компы TC101 — для Thin Client, AW101 — для раб станций, NB101 для ноутбуков
Досаточно удобно, имхо
имелось в виду
Workstations->SPB->Office1->Users
Workstations->SPB->Office1->Computers
Workstations->SPB->Office1->Users
Workstations->SPB->Office1->Computers
AW101, в данном наименовании 101 что означает? Не очень понятно.
В случае, когда Вы используете OU для обозначения физического месторасположения компьютеров, а не для отображения орг. структуры компании, вам придется применять сквозную нумерацию внутри всего домена, а это очень неудобно, особенно когда компьютеров не одна тысяча в разных городах страны. Местные администраторы просто запутаются в именах и за присвоением номера машины придется обращаться к администраторам головного управления. Тем более, что делать, если, например, один отдел департамента по одному адресу работает, а другой отдел по другому? Это получится в OU так: SPB->Office1->Депертамент1->Отдел1, SPB->Office2->Департамент1->Отдел2. А если надо применить политику ко всему Департаменту1? Вполне вероятно я что-то не так понял.
P.S. Не очень понял, почему OU Workstations выносится наверх SPB и потом еще в Users добавляется Computers. Организация OUшек отдельная интересная тема :)
В случае, когда Вы используете OU для обозначения физического месторасположения компьютеров, а не для отображения орг. структуры компании, вам придется применять сквозную нумерацию внутри всего домена, а это очень неудобно, особенно когда компьютеров не одна тысяча в разных городах страны. Местные администраторы просто запутаются в именах и за присвоением номера машины придется обращаться к администраторам головного управления. Тем более, что делать, если, например, один отдел департамента по одному адресу работает, а другой отдел по другому? Это получится в OU так: SPB->Office1->Депертамент1->Отдел1, SPB->Office2->Департамент1->Отдел2. А если надо применить политику ко всему Департаменту1? Вполне вероятно я что-то не так понял.
P.S. Не очень понял, почему OU Workstations выносится наверх SPB и потом еще в Users добавляется Computers. Организация OUшек отдельная интересная тема :)
Что то я вчера под вечер совсем плох был… :)
aw001, nb001 имелось в виду, сорри
Сквозная нумерация мне проблем не доставляет, если заранее выделить пулы. т.е. 100 — 200 СПБ, 200-300 МСК, например.
Внутри офисов на департаменты никогда не делил, но задача с политикой решаема.
Верхняя OU не Workstations, а Enterprise в моем случае, опечатка (
aw001, nb001 имелось в виду, сорри
Сквозная нумерация мне проблем не доставляет, если заранее выделить пулы. т.е. 100 — 200 СПБ, 200-300 МСК, например.
Внутри офисов на департаменты никогда не делил, но задача с политикой решаема.
Верхняя OU не Workstations, а Enterprise в моем случае, опечатка (
Стараюсь привязывать сетевое имя хоста к чему-нибудь незыблемому.
Раньше делал инвентарный номер без всяких букв, кстати он же написан на бирке системника.
В крайней конторе используют связку из шифра модели и порядкового номера поступления модели в эксплуатацию, тоже годно.
почему так?
Потому что монолитно, единообразно, позволяет как угодно «тусовать» пользователей и технику между филиалами.
А для того что бы найти машину по вошедшему пользователю и существует «директория». Да неудобно, но можно. :)
кстати, незачем пользователям по чужим машинам логинетсо. В администрировании нет ничего хуже излишнего либерализма.
Раньше делал инвентарный номер без всяких букв, кстати он же написан на бирке системника.
В крайней конторе используют связку из шифра модели и порядкового номера поступления модели в эксплуатацию, тоже годно.
почему так?
Потому что монолитно, единообразно, позволяет как угодно «тусовать» пользователей и технику между филиалами.
А для того что бы найти машину по вошедшему пользователю и существует «директория». Да неудобно, но можно. :)
кстати, незачем пользователям по чужим машинам логинетсо. В администрировании нет ничего хуже излишнего либерализма.
указанное в топике — неудобно, кмк
повторю свой старый коммент:
например:
первая буква
w — рабочая станция
s — сервер
далее, трёхбуквенное обозначение города:
msk
далее, обозначение офиса:
например, center
далее, для рабочих станций, номер в формате 01, 02 и так далее
для серверов — роль сервера с номером, т.е. файловый
w-msk-center-53
s-msk-center-f01 файловый сервер
s-msk-center-d03 контроллер домена
s-msk-center-t02 терминальный сервер
повторю свой старый коммент:
например:
первая буква
w — рабочая станция
s — сервер
далее, трёхбуквенное обозначение города:
msk
далее, обозначение офиса:
например, center
далее, для рабочих станций, номер в формате 01, 02 и так далее
для серверов — роль сервера с номером, т.е. файловый
w-msk-center-53
s-msk-center-f01 файловый сервер
s-msk-center-d03 контроллер домена
s-msk-center-t02 терминальный сервер
Согласен, можно полностью в буквенном варианте (кроме нумерации машин). Только, имхо, можно было w в конец поместить: msk-center-w01, как конечная точка иерархии. Мне немного компактней кажется обозначение адреса размещения машины коротким кодом. И для каждой площадки придумывать еще свое сокращение, хотя это много времени не займет конечно. А может просто дело привычки. Но зато с Вашим вариантом мы не упремся ни в какие лимиты по количеству городов/адресов. Это удобно. Спасибо за совет.
Это как раз тот вариант, когда одного универсального решения быть не может.
Я, например, устал переименовывать машины. И просто пишу принадлежность к компании (не одна в домене), что автоматом обозначает один из офисов, плюс регион, и инвентарный номер, что облегчает работу со складом и бухгалтерией.
Да и то, со временем убедился, что можно было регион и не указывать.
В итоге NAME-##### или NAME-DN-#####. Если нужно информация о владельце — она у склада, открыл и посмотрел. А если по логону надо — скрипты.
Как-то со временем всё больше приходит ко мне осознание, что просто сделать сложно, а вот сделать просто сложно. Чё там про родственные связи краткости говорят?
Я, например, устал переименовывать машины. И просто пишу принадлежность к компании (не одна в домене), что автоматом обозначает один из офисов, плюс регион, и инвентарный номер, что облегчает работу со складом и бухгалтерией.
Да и то, со временем убедился, что можно было регион и не указывать.
В итоге NAME-##### или NAME-DN-#####. Если нужно информация о владельце — она у склада, открыл и посмотрел. А если по логону надо — скрипты.
Как-то со временем всё больше приходит ко мне осознание, что просто сделать сложно, а вот сделать просто сложно. Чё там про родственные связи краткости говорят?
Sign up to leave a comment.
Создание централизованной AD: Стандарты именования объектов, часть 1