Пошук старих робочих станцій у Acitve Directory, нотатки системного адміністратора

нотатки з IT технологій: просто про складне

Головне меню

Навігація за записами

пошук старих робочих станцій у Acitve Directory

Проблема старих робочих станцій в AD

Як відбувається типовий процес забезпечення нового працівника робочою станцією:

  1. Зі складу дістається робоча станція
  2. На робочу станцію встановлюється операційна система та все необхідне ПЗ
  3. Робоча станція заводиться в домен за якимось ім'ям, підозріло схожим на прізвище користувача
  4. Запис про робочу станцію у структурі AD переміщається у необхідний OU
  5. Робоча станція встановлюється на робоче місце нового співробітника

Які типові сценарії зазвичай виконуються під час звільнення співробітника:

  1. Робоча станція звільненого співробітника передається на склад, а вміст жорсткого диска чекає на одну з наступних доль:
  2. Усі необхідні документи переносяться на загальновідомий загальний мережевий ресурс, доступ до папки, що містить перенесені документи, дається для співробітника, який приймає справи
  3. Усі необхідні документи переносяться безпосередньо на робочу станцію співробітника, котрий приймає справи колеги, що звільняється.
  4. Робоча станція звільненого співробітника не передається на склад, а натомість:
  5. Перейменовується відповідно до чогось, підозріло схожого на прізвище вже нового користувача
  6. Не перейменовується через недбале ставлення до роботи або за простою забудькуватістю

Таким чином, при солідному парку ПК та ненульовій плинності кадрів, з часом у Active Directory накопичується маса записів про робочі станції, в точному статусі яких уже не впевнений ніхто.

  • dsquery — виводить список об'єктів AD, які відповідають заданому критерію
  • dsmod – змінює задані атрибути об'єкта
  • dsmove — переміщує об'єкт у межах AD
  • dsrm – видаляє поточний об'єкт або повністю дерево дочірніх об'єктів
  • dsadd та dsget нам зараз не знадобляться

Припустимо, що ми адмініструємо домен libertine.su. Отже, виконавши у командному рядку просту команду

ми отримаємо список робочих станцій домену, які не оновлювали свій пароль протягом останнього 61 дня. Точніше, сказати, список із перших 100 записів, що підпадають під цю умову. Якщо кількість робочих станцій може перевищувати це значення, плюс ми хочемо вивести список тільки для комп'ютерів з OU marketing, то немає нічого простішого:

Ми також можемо вивести список з комп'ютерів, які не входили до домену протягом заданого числа тижнів. Так, саметиждень і про це необхідно пам'ятати, щоб уникнути нерозуміння того, що відбувається Description: ;). Як і про те, що, на жаль, команда працює тільки, якщо домен знаходиться в 2003 році нативному режимі.

Отже, з'ясуємо, які комп'ютери із OU Sales не реєструвалися в домені за останні 7 тижнів:

Ок, ми з'ясували. А що ж із цим робити далі? Логіка нагадує, що можна просто видалити. В принципі без проблем. Але їх можна спочатку зробити неактивними. Для цього ми використовуємо відповідні утиліти командного рядка. Знайдені комп'ютери з dsquery передамо туди за допомогою механізму тунелювання команд (символ конвеєра в командному рядку).

Наступною командою ми виключимо облікові записи знайдених комп'ютерів на попередньому етапі:

Що, в нас не вийшло? Все правильно! Параметри у вигляді повних шляхів до знайдених комп'ютерів, у другій частині необхіднопередавати по одній, а чи не відразу весь список.

Можна, звичайно, написати дурний cmd файл приблизно такого змісту:

Таким чином ми в нескінченному циклі послідовно змінимо атрибут кожної з робочих станцій, що знаходяться.

Але це якось нескінченно негарно. Тому ми краще напишемо в цьому файлі таку конструкцію:

Перший і третій рядок на смак. Особисто мені така поведінка подобається більше.

Тепер пропоную перемістити всі вимкнені записи комп'ютерів домену в одну OU під ім'ям disabled old computers. Створюємо цю OU за допомогою командного рядка або оснастки Active Directory Users and Computers.

А тепер створюємо ще один cmd файл:

Принагідно можна задуматися про те, наскільки нескінченним виглядатиме результат, якщо у зазначеній OU вже містяться вимкнені записи робочих станцій домену. Хоча, зрозуміло, справжні індіанці можуть спробувати створити спеціального користувача, який, маючи повні права на модифікацію та запис, не матиме права на читання однієї конкретної OU в домені. І запускати надалі всі скрипти від імені користувача.

Так, оскільки я обіцяв згадати утиліту dsrm у контексті управління записами робочих станцій, я її згадую: якщо створити наступний cmd файл: