Unified Administration Scripts 1.09



Це продовження публікації «Уніфікація logon скриптів в рамках великої компанії».
Скачати дане рішення ви можете звідси.

Що перед вами?
UAS — уніфіковані адміністративні скрипти, які можна застосовувати в організаціях будь-якого розміру з метою стандартизації та отримання максимальної ефективності від використання доменних (MS Active Directory) startup / logon скриптів Microsoft Windows. При адекватному використанні — це відмінний засіб для контролю за парком ваших ПК і автоматизації адміністративних завдань, яке доповнює GP.

Причини для уніфікації адміністративних скриптів
Причин може бути декілька:
  • Великий розмір організації і наявність десятків і сотень філій по країні (країнах);
  • Великий IT відділ, який передбачає, що проектувати і застосовувати адміністративні скрипти для обслуговування робочих станцій будуть більше двох осіб. У цьому разі з часом організація обростає великою кількістю розрізнених скриптів, які обліплюють систему, в яких вже мало хто може розібратися і які вкрай важко і трудомістко обслуговувати;
  • У невеликих скриптах вкрай важко домогтися реалізації механізмів, які реально полегшують працю системних адміністраторів, тому що ці механізми вимагають комплексного підходу, великої кількості коду, досить жорсткого інфраструктурного забезпечення та контролю. Все це можливо тільки в умовах наявності спеціалізованої системи.


Необхідні умови для уніфікації скриптів на базі рішення UAS
  • Єдина WAN, об'єднує всі сайти компанії;
  • Впровадження Microsoft Active Directory в мережі компанії;
  • Всі робочі станції є членами домену AD;
  • Клієнтські операційні системи Windows XP Professional і новіше;
  • Наявність одного або декількох файлових серверів;
  • Наявність MS SQL сервера (рекомендується);
  • Наявність SMTP сервера всередині WAN (рекомендується).


Ядро системи
UAS, власне, складається з двох скріптів: завантажувача і головного. Для такої двухзвенной компонування є вагомі причини:
  • Завантажувач має невеликий розмір (10-11 Кб), розташовується на контролері домену і йому простіше стартувати по WAN (мається на увазі, що робочу станцію і контролер домену може з'єднувати не занадто швидкий канал даних);
  • Завантажувач змінюється не часто і тому вам рідко доведеться турбувати співробітників рівня Domain Admin, щоб його замінити на DC. У великих організаціях, як правило, співробітники, що відповідають за функціонування робочих станцій не мають права змінювати щось на DC;
  • Стартував легкий завантажувач може запустити важкий (основний) скрипт (128 Кб на даний момент) з файлового сервера, який знаходиться з робочою станцією в одній і тій же LAN. Для цього є відповідний механізм, вбудований завантажувач, який використовує DNS в якості бази даних для визначення імені та адреси потрібного файлового сервера;
  • завантажувач вбудований механізм кешування основного скрипта, який копіюється з сервера в стислому вигляді (стандартні утиліти compress/expand), розпаковується в папці TEMP і звідти запускається на виконання. Таким чином мінімізується звернення до файлового сервера пов'язані з читанням основного скрипта. Все це має істотну цінність, коли робоча станція не має виділеного файлового сервера у своїй LAN і змушена звертатися до такого сервера по WAN.


Завантажувач запускається через об'єкт Group Policy. Startup (виконується під обліковим записом SYSTEM) скрипт стартує з параметрами MACHINE LOGON, а logon (виконується під обліковим записом користувача) скрипт — з параметрами USER LOGON. В принципі, вони навіть можуть працювати одночасно.

Завдання завантажувача запустити основний скрипт, який, власне, і виконує надалі всю корисну роботу. Основний скрипт має наступні функції:
  • Визначення типу запуску (STARTUP або LOGON скрипт). Цю інформацію він бере зі своїх параметрів запуску, які йому передав завантажувач. В залежності від типу запуску скрипт виконує різні речі. Наприклад, в startup скрипті немає сенсу підключати мережеві диски, але є сенс запускати команди на установку пакетів програмного забезпечення;
  • Визначення всіх необхідних характеристик комп'ютера та / або користувача;
  • Запис, так званого, GLOBAL лода, який в основному містить інформацію про комп'ютері (серійний номери, основна апаратура, програмне забезпечення), порівняння попереднього лода з цього, виявлення розбіжностей та формування на цій основі лода подій (наприклад, зміна дати антивірусних сигнатур, заміна жорсткого диска тощо);
  • Формування PCSESLOG лода, фіксує факти старту ПК, або USSESLOG лода, реєструвального логіни користувачів на ПК. Всі логи зберігаються на файловому сервері;
  • LOGIN скрипт також збирає статистику по логінів користувачів в спеціальному протоколі USERLOG, щоб на основі цих даних визначити основного господаря робочої станції;
  • Нарешті, скрипт зчитує і виконує макро-сценарії з location.all і location.xxx файлів, де all — означає сценарій для всіх ПК організації, а xxx — сценарій для конкретно цієї філії (а точніше IP підмережі). Макро-сценарії — це групи, вбудованих в UAS команд, що утворюють якусь подобу мови програмування високого рівня, на якому ви можете описати те, що необхідно зробити. Наприклад, запустити програму / зовнішній скрипт на виконання, підключити принтер або мережевий диск і т.д.


Інфраструктура для роботи UAS скриптів
  • На контролері домену в NETLOGON повинен лежати uas_loader.vbs;
  • AD GP повинен бути створений об'єкт групової політики прилинкованный до всіх OU, де лежать ваші комп'ютери і користувачі, що запускає завантажувач з параметрами: MACHINE LOGON для події startup і USER LOGON для події logon;
  • На всіх файлових серверах повинен бути створений спільний ресурс ADMSCR$, має відповідну файлову структуру і права доступу. Докладніше це буде обговорюватися нижче;
  • На робочих станціях треба забезпечити роботу служб Task Scheduler і Windows Management Instrumentation (це можна запрограмувати в тому ж GPO, звідки запускаються скрипти);
  • На SQL сервері треба налаштувати БД UAS (4 таблиці та 2 збережених процедури). Врахуйте, база буде рости, якщо у вас багато комп'ютерів, то подивіться з якою швидкістю вона росте і подбайте про дисковому просторі;
  • Якщо у вашій мережі буде SMTP сервер без авторизації, то ви зможете отримувати попередження від завантажувача скрипта, якщо він зіткнувся з якими-небудь проблемами;
  • Допоміжний сервер (робоча станція), на якій будуть заплановані ряд задач по обслуговуванню скриптів, наприклад: консолідація логів на одному сервері, закачування інформації з логів EVENTS, PCSESLOG, USSESLOG в БД SQL;
  • Excel файл-довідник з вашим IP подсетям, назвам філій тощо, на основі якого будуть формуватися файл network.cfg і master.bat (подробиці нижче)
  • DNS записи типу CNAME, що вказують на файловий сервер, що обслуговує дану IP підмережі, для якої створюється запис.


Робота завантажувача (uas_loader.vbs)
Групова політика AD дозволяє запускати скрипти у відповідь на 4 події:
  • Реєстрація системної запису ПК в AD (Startup)
  • Реєстрація користувача в AD (Logon)
  • Розреєстрація користувача AD (Logoff)
  • Розреєстрація ПК в AD (Shutdown).


У UAS за всім цим подіям виповнюється один і той же скрипт, який називається UAS_LOADER.VBS. Щоб він розумів, з якого приводу він запущений йому передаються параметри відповідно:
  • MACHINE LOGON
  • USER LOGON
  • Від LOGOFF / SHUTDOWN скриптів було прийнято рішення відмовитися, так як вони уповільнювали перезавантаження комп'ютерів і процес виходу користувача


Наприклад, скрипт для події Startup запускається такою командою:
\\DOM\NETLOGON\UAS_LOADER.VBS MACHINE LOGON

Всі скрипти UAS ведуть детальні логи своєї роботи в папках, на які вказують змінні ОС TEMP. Майте на увазі, що для системної облікового запису своя змінна TEMP, а для користувача — своя. За замовчуванням це системна %SystemRoot%\TEMP, а користувацька C:\Documents and Settings\%Username%\Local Settings\Temp (це XP) або C:\Users\%Username%\AppData\Local\Temp (для W7).

Щоб переконатися, що скрипти відпрацювали, щоб зрозуміти, чому вони працюють не так, як ви очікували, — дивимося логи.

Якщо завантажувачу передали неправильні параметри, то він створить лог з назвою файлу db_loader_wrong_param.log і завершить роботу.
21.10.2014 21:28:43 - Started...
21.10.2014 21:28:43 - Loader Version = 0.30
21.10.2014 21:28:43 - Received 0 parameters. Stoped.
21.10.2014 21:28:43 - End.


Зверніть увагу, що скрізь є тимчасові мітки, скрізь є версія коду, а в кінці є ключове слово «End.», за яким можна зрозуміти штатно чи завершився скрипт або він все ще виконується, або він завершився аварійно.

Щоб логи не плуталися, їх назва включаються параметри запуску.
Відповідно вони отримують назви:
  • db_loader_MACHINE_LOGON.log
  • db_loader_USER_LOGON.log
Ось типовий лог db_loader_MACHINE_LOGON.log:
19.10.2014 19:39:51 - Started...
19.10.2014 19:39:51 - Loader Version = 0.30
19.10.2014 19:39:52 IP : 10.100.024.54 , MASK : 255.255.255.0
19.10.2014 19:39:52 - А = RU100024000
19.10.2014 19:39:52 - OS Type = 6.1
19.10.2014 19:39:52 - Start ping RU100024000 ...
19.10.2014 19:39:52 - ResponseTime=1
19.10.2014 19:39:52 - Resolved address=10.100.24.15
19.10.2014 19:39:52 - Status code is 0
19.10.2014 19:39:52 - Net type = LAN
19.10.2014 19:39:52 - Schedulling daily job...
19.10.2014 19:39:52 - Running : SCHTASKS.EXE /delete /tn UAS_LOADER /f
19.10.2014 19:39:52 - Return code : 0
19.10.2014 19:39:52 - Running : SCHTASKS.EXE /create /sc DAILY /tn UAS_LOADER /st 12:15:00 /ru SYSTEM /tr "WSCRIPT.EXE //B //NoLogo //T:14400 \\DOM.COM\NETLOGON\UAS_LOADER.VBS MACHINE SCHEDULE"
19.10.2014 19:39:52 - Return code : 0
19.10.2014 19:39:52 - Remote path :\\FILESRVMOS.dom.com\ADMSCR$\SCRIPTS\UAS_MAIN.VBS
19.10.2014 19:39:52 - Local path :C:\Windows\TEMP\UAS_MAIN.VBS
19.10.2014 19:39:52 - Local script has been found. Deleted.
19.10.2014 19:39:52 - Archive was deleted to fresh one from server.
19.10.2014 19:39:52 - Archive was not found in local. Copying...
19.10.2014 19:39:52 - File C:\Windows\TEMP\UAS_MAIN.VB_ exists
19.10.2014 19:39:53 - Script size from AD : 26318
19.10.2014 19:39:53 - Archive size is good. Decompressing...
19.10.2014 19:39:53 - Running : EXPAND.EXE C:\Windows\TEMP\UAS_MAIN.VB_ C:\Windows\TEMP\UAS_MAIN.VBS
19.10.2014 19:39:53 - Return code : 0
19.10.2014 19:39:53 - Run local script ...
19.10.2014 19:39:53 - Running : WSCRIPT.EXE //B //NoLogo //T:14400 C:\Windows\TEMP\UAS_MAIN.VBS MACHINE LOGON CONSOLE LAN \\FILESRVMOS.dom.com\ADMSCR$
19.10.2014 19:48:12 - Return code : 0
19.10.2014 19:48:12 - End.

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

Розберемо цей процес докладно.

Спочатку передбачалося, що у нас не буде доступу на контролери домену на запис в папку Scripts. Тому варіант розміщення основних скриптів там (які часто змінюються) не розглядався. Хотілося розміщувати часто-меняемые файли на серверах, які гарантовано знаходяться під нашим контролем.
Крім того, філії працюють з DC по WAN і тримати там основні скрипти було б не дуже добре, так як часто великі і середні філії мають своїм файловим сервером, а працювати по LAN завжди краще. Тому і народилося рішення мати на DC маленький завантажувач (його розмір зараз 11 Кб і навряд чи буде зростати), а основний скрипт (на даний момент 128 Кб і буде рости) тримати на локальних файлових серверах там, де вони є.
Таким чином виникає задача десь зберігати інформацію про те, якою філія на якому файловому сервері зберігає і запускає скрипти. Для цієї мети ідеально підійшла розподілена мережна база даних (сервіс) — DNS.
Завантажувач визначає IP-адресу і маску комп'ютера, з них визначає IP підмережі філії і просто пінг вийшло ім'я. Наприклад, якщо IP = 10.100.24.67 MASK=255.255.255.0, тоді IP SUBNET = 10.100.24.000. Скрипт перетворює це в ім'я RU100024000 і робить з цього імені запит до DNS (через команду PING). У відповідь він отримує ім'я сервера і його IP адреса, з якого слід запускати основний скрипт.

В DNS прописуються запису виду:
Ім'я RU100024000
Тип запису CNAME
Значення FILESRVNNV.DOM.COM

Пингуя цю запис, завантажувач крім сервера по затримці дізнається ще й тип з'єднання локального ПК і сервери: LAN або WAN.

Залишалося лише якось полегшити життя філіям, які не мають виділеним файловим сервером і змушені запускати скрипти по WAN. Для цього завантажувач викачує на локальну машину стислий скрипт, розпаковує його і запускає локально. Так стислий через стандартну утиліту MS compress.exe файл скрипта стискається зі 128 Кб 26Кб.

Ще одна обставина з'ясовує завантажувач — в якому режимі він запущений: в консольному або термінальному.

Прокоментуємо конкретний лог:
19.10.2014 19:39:52 IP : 10.100.024.54 , MASK : 255.255.255.0
Визначення IP-адреси і маски підмережі
19.10.2014 19:39:52 - А = RU10002400
Обчислення хоста, який слід пінговать
19.10.2014 19:39:52 - OS Type = 6.1
З'ясування версії ОС. Справа в тому, що можливість пінговать хости засобами WMI з'явилася тільки в ОС, починаючи з версії 5.1 (XP). Для виконання пінгу в попередніх версія ОС доводилося викликати PING.EXE. Якщо ОС гірше 5.1, то передбачається, що ми працюємо через WAN.
19.10.2014 19:39:52 - ResponseTime=1
Затримка відповіді вказує на LAN або WAN. Більше 50 мілісекунд вважаємо WAN.
19.10.2014 19:39:52 - Resolved address=10.100.24.15
DNS повернув відповідь на запит
19.10.2014 19:39:52 - Status code is 0
Код повернення запиту (0 — немає помилки)
19.10.2014 19:39:52 - Net type = LAN
Тип з'єднання
19.10.2014 19:39:52 - Schedulling daily job...
19.10.2014 19:39:52 - Running : SCHTASKS.EXE /delete /tn UAS_LOADER /f
Щоб не залежати від користувача в плані перезавантажень (startup скрипт запускається при перезавантаженні) придумано шедулить скрипт на автоматичний запуск раз в день. Ця команда видаляє попередню задачу, щоб її відновити.
19.10.2014 19:39:52 - Return code : 0
Видалення пройшло успішно
19.10.2014 19:39:52 - Running : SCHTASKS.EXE /create /sc DAILY /tn UAS_LOADER /st 12:15:00 /ru SYSTEM /tr "WSCRIPT.EXE //B //NoLogo //T:14400 \\DOM.COM\NETLOGON\UAS_LOADER.VBS MACHINE SCHEDULE"
Завдання перешедуливается. Зверніть увагу, що запускається знову ж завантажувач, але другий параметр у нього не LOGON, а SCHEDULE. Таким чином основний скрипт дізнається, що він запустився події планувальника завдань.
19.10.2014 19:39:52 - Return code : 0
Успішно
19.10.2014 19:39:52 - Remote path :\\FILESRVMOS.dom.com\ADMSCR$\SCRIPTS\UAS_MAIN.VBS
Визначається шлях до основного скрипта на сервері
19.10.2014 19:39:52 - Local path :C:\Windows\TEMP\UAS_MAIN.VBS
Путь до кешованого скрипта в папці TEMP
19.10.2014 19:39:52 - Local script has been found. Deleted.
Локальний скрипт видаляється, щоб забезпечити захист від підміни — адже його виконання відбувається з правами системи.
19.10.2014 19:39:52 - Archive was deleted to fresh one from server.
Стиснене основний скрипт видаляється з локального TEMP (це відбувається не завжди, а з імовірністю 25%)
19.10.2014 19:39:52 - Archive was not found in local. Copying...
Стиснене скрипт копіюється з сервера
19.10.2014 19:39:52 - File C:\Windows\TEMP\UAS_MAIN.VB_ exists
Перевірка, що файл з'явився
19.10.2014 19:39:53 - Script size from AD : 26318
Перевіряється AD, який розмір повинен бути у стисненого скрипта
19.10.2014 19:39:53 - Archive size is good. Decompressing...
Якщо розмір збігається, то скрипт можна розпакувати і запустити, а якщо не збігається, то скрипт запустить uas_main з сервера
19.10.2014 19:39:53 - Running : EXPAND.EXE C:\Windows\TEMP\UAS_MAIN.VB_ C:\Windows\ TEMP\UAS_MAIN.VBS
Розпакування скрипта з архіву
19.10.2014 19:39:53 - Return code : 0
Успішно
19.10.2014 19:39:53 - Run local script ...
Запуск основного скрипта
19.10.2014 19:39:53 - Running : WSCRIPT.EXE //B //NoLogo //T:14400 C:\Windows\TEMP\ UAS_MAIN.VBS MACHINE LOGON CONSOLE LAN \\FILESRVMOS.dom.com\ADMSCR$
Зверніть увагу скільки і які параметри передаються в основний скрипт з завантажувача. По-перше, це те що GP повідомила завантажувачу при запуску (MACHINE і LOGON), а по-друге, те, що завантажувач визначив під час своєї роботи (тип сесії, тип мережі та адресу сервера, куди будуть писатися логи).
19.10.2014 19:48:12 - Return code : 0
Скрипт відпрацював без помилок і повернув управління в завантажувач
19.10.2014 19:48:12 - End.
Кінець лода.

Робота основного скрипта (UAS_MAIN.VBS)
Роботу основного скрипта будемо описувати великими блоками і місцями схематично, так як він досить великий.

Робота в режимі MACHINE LOGON або MACHINE SCHEDULE

  1. Створення лода в папці TEMP з ім'ям
    • db_debug_MACHINE_LOGON.log
    • db_debug_MACHINE_SCHEDULE.log

  2. Ініціалізація змінних
  3. Розбір переданих параметрів
  4. Визначення імені філії, в якому працює робоча станція, і папки для запису логів, на основі IP підмережі і довідника у файлі networks.cfg
  5. Читання в пам'ять location файлів
  6. Висновок вмісту цих сценаріїв в лог скрипта
  7. Збір інформації про конфігурацію ПК і додатках
  8. Аналіз лода з USERLOG, визначення основного користувача ПК
  9. Формування в пам'яті GLOBAL лода, виявлення подій (лог EVENTS) при порівнянні поточного GLOBAL лода з попереднім з сервера
  10. Запис GLOBAL лода
  11. " Додавання запису в PCSESLOG на сервері
  12. Виконання дій із сценаріїв

Робота в режимі USER LOGON

  1. Створення лода в папці TEMP з ім'ям db_debug_USER_LOGON.log
  2. Ініціалізація змінних
  3. Розбір переданих параметрів
  4. Визначення імені філії, в якому працює робоча станція, і папки для запису логів, на основі IP підмережі і довідника у файлі networks.cfg
  5. Читання в пам'ять location файлів
  6. Висновок вмісту цих сценаріїв в лог скрипта
  7. Збір мінімальної інформації (ім'я користувача AD, серійний номер ПК)
  8. Оновлення лода USERLOG
  9. Додаємо запис у USSESLOG
  10. Виконання дій із сценаріїв


Більш повний варіант документації є в дистрибутиві (посилання на початку публікації). Якщо ви хочете спробувати, то у вас вже достатньо інформації, щоб починати розгортати систему і пробувати її в справі. Через деякий час я викладу тлумачні приклади використання макрокоманд.

P.S. Версія 1.09 скрипта починалася не з 1.00, а з 0.01, тобто це вже 109 версія. Не дивно з 2006 року.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.