Групові політики Windows Vista і Windows Server 2008

C виходом Windows Vista і наближенням дати випуску Windows Server 2008 настав час уважно розглянути вдосконалені групові політики в нових версіях операційної системи. Групова політика - ключовий механізм управління настройками всередині Windows. Це не так просто, оскільки розширення політик призводить до збільшення числа параметрів, зі збільшенням числа параметрів розширюється вибір, а з розширенням вибору зростає складність. На щастя, поліпшення в консолі керування груповою політикою (Group Policy Management Console, GPMC) Windows Server 2008 частково компенсують зростання складності.

Служба Group Policy Client

Відбулися важливі зміни в деяких прихованих від користувача компонентах групової політики. Найголовніше, що механізм групової політики виведений з системного процесу Winlogon, в якому він функціонував починаючи з Windows 2000, в свою службу Group Policy Client. Group Policy Client - неперезапускаемая служба в Vista і Windows Server 2008, яка виконує обробку групових політик. Вона функціонує поза Winlogon і забезпечує ізольоване середовище для запуску розширень групової політики на клієнтській стороні (Client-Side Extensions, CSE). Клієнтські розширення Microsoft навіть ізольовані від сторонніх CSE, і збій такого CSE не впливає на розширення Microsoft в ході обробки групової політики.

Виявлення повільних ліній

Змінився процес виявлення повільних ліній. У попередніх версіях Windows на початку кожного циклу обробки групової політики клієнт використовує протокол ICMP для опитування контролера домену (DC) Active Directory (AD), щоб визначити доступність і пропускну здатність каналу зв'язку між клієнтом і DC. Якщо з якоїсь причини процес завершується невдачею (наприклад, ICMP заблокований або обмежений мережею або не вдається отримати доступ до DC через протокол ICMP), то обробити групову політику не можна. Крім того, метод виявлення повільних ліній зв'язку досить примітивний; в результаті лінії нерідко безпідставно зараховуються до повільним.

Щоб удосконалити цей процес, в груповій політиці використовується нова версія провайдера Network Location Awareness (NLA), яку поставляють з Vista і Server 2008. NLA перевіряє доступність DC і в разі успіху визначає швидкість мережевого каналу між клієнтом і DC. При цьому використовуються надійні протоколи, такі як віддалений виклик процедур (RPC), замість порівняно простого і часто блокується ICMP. Це дозволяє точніше визначати повільні лінії і швидко встановлювати доступність DC. Доступність DC - дуже важливий фактор в інший нової функції, а саме в оновленні групової політики на основі NLA.

Фонове оновлення з використанням NLA

Поряд з більш точним виявленням повільних ліній, служба NLA використовується в механізмі групової політики для вдосконалення процесу оновлення групової політики в фоновому режимі. У версіях Windows до Vista і Server 2008 включно фонове оновлення на робочих станціях і серверах, членах домену, виконується через кожні 90 хвилин. Крім того, щоб оновлення всіх комп'ютерів не відбувалося відразу, виконується додаткове оновлення через проміжки зі випадково обраним значенням до 30 хвилин. Наприклад, фонове оновлення ноутбука сталося, поки власник їхав додому з роботи в електричці. Оскільки DC недоступний, спроба поновлення завершилася невдачею. Через десять хвилин користувач приходить додому і підключається до корпоративної VPN, DC стає доступним, але в залежності від моменту останнього оновлення може пройти багато часу, перш ніж буде виконано наступне фонове оновлення групової політики.

Служба NLA забезпечує новий тип фонового поновлення групової політики в Vista і Server 2008. Якщо комп'ютер з однією з нових версій операційної системи намагається оновити групову політику в фоновому режимі і не може цього зробити через недоступність DC, то після відновлення зв'язку з DC клієнт запускає фонове оновлення групової політики відразу ж після того, як служба NLA виявляє DC. Оновлення NLA записується в новий журнал Vista Group Policy Operational, як показано на екрані 1.

Оновлення NLA записується в новий журнал Vista Group Policy Operational, як показано на екрані 1

Оновлення NLA корисно, коли потрібно поширити політику, яка впливає на поведінку клієнтських комп'ютерів, і очікування змін після повторного підключення користувачів до мережі не повинно перевищувати години. Однак важливо відзначити, що ця функція працює тільки у випадку невдалої попередньої спроби фонового оновлення.

Множинні локальні об'єкти GPO

Нерідко буває корисно встановити на комп'ютері Windows XP локальний об'єкт GPO, який не впливає на адміністраторів або застосовується тільки до конкретного користувача локального комп'ютера. В якості вирішення можна запропонувати використання декількох локальних об'єктів GPO в Vista і Server 2008. Як видно з назви, множинні локальні об'єкти GPO забезпечують спосіб розмістити більше одного локального GPO на конкретному комп'ютері Windows. До Vista локальний GPO зберігався в файлової системі в каталозі C: windows system32grouppolicy. У комп'ютерах Vista і Server 2008 локальний GPO за замовчуванням як і раніше знаходиться в цьому каталозі, але можна підготувати три нових типи локальних об'єктів GPO.

Неадміністративного локальний GPO можна визначити установки політики для конкретного користувача, що застосовуються тільки до будь-яких неадміністративного користувачам (які не входять в локальну групу Administrators) при реєстрації на комп'ютері.
Локальний GPO адміністратора дозволяє задати політики для конкретних користувачів, що застосовуються тільки до членів локальної групи Administrators при реєстрації на комп'ютері.
Локальний GPO користувача можна визначити установки політики для конкретного користувача, які застосовуються тільки до певного облікового запису користувача, зазначеної на робочій станції або сервері, члені домену. До облікових записів домену ця політика не застосовується.

Нові локальні об'єкти GPO зберігаються в папках на основі ідентифікатора SID групи або користувача, до якого вони застосовуються, в C: windowssystem32group policy users. В операційних системах Windows, що передують Vista, порядок обробки групової політики починався з локального GPO, після цього оброблялися об'єкти GPO, пов'язані з сайтами, а потім об'єкти GPO, пов'язані з доменами, і, нарешті, пов'язані з організаційними одиницями (OU). При реєстрації користувача Windows застосовує частину групової політики, яка відноситься до налаштувань користувача. Порядок обробки декількох локальних об'єктів GPO в Vista і Server 2008:

Локальний об'єкт GPO за замовчуванням.
Неадміністративного або адміністративний локальний об'єкт (якщо є).
Локальний об'єкт GPO користувача (якщо є).
Об'єкти GPO на основі домену (пов'язані з сайтом, доменом або OU)

Як звернутися до множинним локальним об'єктам GPO на комп'ютері Vista або Server 2008? Нижче описані кроки, необхідні для редагування інших локальних об'єктів GPO.

З меню Start виберіть пункт Run, а потім введіть mmc, щоб запустити порожню консоль Microsoft Management Console (MMC). Для запуску консолі MMC потрібні розширені повноваження, тому при активізації контролю облікових записів - UAC - видається запит для введення облікових даних.
В консолі MMC виберіть File, Add / Remove Snap-in і перейдіть до пуску Group Policy.
Виберіть пункт Add, щоб додати цю оснастку в консоль, і перейдіть до об'єкта GPO, який належить редагувати. Вибір за замовчуванням - Local Computer, що відноситься до локального об'єкту GPO за замовчуванням. Але на даному етапі клацніть на кнопці Browse, щоб побачити інші варіанти.
У діалоговому вікні Browse for a Group Policy Object виберіть вкладку Users. На даному етапі можна вибрати конкретну обліковий запис локального користувача, адміністратора або неадміністратора і клацнути на кнопці OK, щоб завантажити пов'язаний локальний об'єкт GPO в оснащення Group Policy editor (GPE) консолі MMC для редагування.

На екрані 2 наведено моментальний знімок з мого комп'ютера; перераховано кілька локальних користувачів, а також Administrator, Administrators і Non-Administrators. Жоден з цих локальних GPO поки не існує. Але якщо застосувати наведені вище інструкції, щоб додати один з них в GPE і внести в нього зміни, то він буде існувати в локальній файловій в папці C: windowssystem32 GroupPolicyUsers.

шаблони ADMX

У Vista і Server 2008 змінився формат адміністративних шаблонів, або ADM-файлів. ADM-файли створюють параметри політики, які відображаються в вузлах Administrative Templates в редакторі GPE. ADMX-файли в Vista грають ту ж роль, але з ними не можна працювати в попередній спосіб. Наприклад, спеціальні ADM-файли можна створити в Notepad або іншому текстовому редакторі, але зробити це з новими ADMX-файлами важко. Причина в тому, що компанія Microsoft впровадила новий формат XML-даних для ADMX-файлів і супутніх ADML-файлів. Кожен ADMX-файл вставляє залежні від мови рядкові посилання в ADML-файл для конкретної мови.

Найпростіше зрозуміти ADMX, порівнявши його з ADM. Порівняння двох технологій приведено в таблиці .

Як видно з таблиці, між ADM і ADMX існує багато відмінностей. Головне з них - зберігання; ADMX-файли знаходяться в центральному сховищі, а такі ж ADM-файли розміщуються в кожному об'єкті GPO на кожному DC (що викликає проблему «роздування SYSVOL»). Центральне сховище (центральний або доменний репозиторій) являє собою просто папку з ім'ям PolicyDefinitions, створювану вручну в папці SYSVOLPolicies на DC. Потім вміст C: WindowsPolicyDefinitions копіюється з одного з комп'ютерів Vista або Server 2008 до новоствореної папку, і центральне сховище побудоване.

Я підготував безкоштовну утиліту, яка опублікована за адресою www.gpoguy.com/cssu.htm , За допомогою якої можна автоматизувати створення і заповнення центрального сховища. Після того як центральне сховище створено і заповнено, GPE і GPMC, що запускаються з Vista або Server 2008, виявлять його і будуть посилатися на ADMX-файли з цього місця, а не локально.

Інша перевага нового формату ADMX, згадуване раніше, - відділення мовних рядків в нових ADML-файлах від частини шаблону, в якому визначені параметри політики. В результаті можна використовувати один набір ADMX-файлів для кожного підтримуваного мови і при кожному запуску редактора використовувати ADML-файл для локального мови. Тому замість підготовки багатьох мовних ADM-файлів, як в минулому, завдяки новому формату не складає труднощів редагувати політику Administrative Template на багатьох мовах.

Спеціалізовані ADM-файли можна перетворити в ADMX-файли з використанням безкоштовного перетворювача ADM-ADMX, випущеного компанією Microsoft. Цей інструмент, іменований ADMX Migrator, також значно спрощує створення нових ADMX-файлів. Відомості про завантаження в розділі ADMX Migrator наведені в урізанні «Література».

взаємодія

Перш ніж розглянути проблеми, що виникають в змішаному середовищі Vista з ADMX і Windows XP або Windows Server 2003 з ADM, слід підкреслити, що це завдання адміністраторів. Для застосування об'єкта GPO на клієнтах (будь-якого типу) шаблони ADM або ADMX не потрібні. Шаблони використовуються тільки для адміністративного уявлення об'єктів GPO і адміністративних завдань, таких як робота з конкретними параметрами. Власне параметри, що застосовуються через GPO, як і раніше зберігаються в registry.pol і пов'язаних з ним файлах, які не змінилися в Vista і Server 2008. Це означає, що об'єкт GPO, створений і керований через Vista або Server 2008, повністю сумісний з клієнтами нижнього рівня по підтримуваним ними параметрами.

Адміністраторам слід пам'ятати, що XP, Server 2003 і Windows 2000 «не бачать» ADMX-файлів. Таким чином, якщо створити об'єкт GPO і встановити орієнтовані на Vista політики Administrative Template з GPE на комп'ютері Vista, а потім спробувати відредагувати цей GPO в редакторі GPE на комп'ютері XP, то параметри Vista будуть не видно, так як вони знаходяться в ADMX-файлах Vista , які не читаються в XP. Положення ускладнюється, тому що XP і Vista зберігають файли шаблонів по-різному.

Розглянемо змішану середу. Нехай створюється новий об'єкт GPO на робочої станції Vista. Припустимо також, що створено центральне сховище, і все керовані з Vista об'єкти GPO посилаються на ADMX-файли з центрального сховища. Пам'ятайте, що Vista більш не зберігає файли шаблонів в розділі SYSVOL кожного об'єкта GPO. Потім адміністратор редагує новий GPO Vista на комп'ютері XP. XP звертається до розділу SYSVOL цього об'єкта GPO і не виявляє в ньому ADM, тому власні ADM-файли XP копіюються в SYSVOL і «забруднюють» новий об'єкт GPO Vista.

Як уникнути такої ситуації? Існує принаймні три способи. По-перше, після введення Vista в інформаційне середовище можна скласти план редагування об'єктів GPO тільки з комп'ютерів Vista. Це дозволить гарантувати, що тепер всі об'єкти GPO будуть розпізнавати всі параметри. По-друге, можна розділити середовища. Якщо є кілька комп'ютерів XP і кілька комп'ютерів Vista, то можна управляти об'єктами GPO, застосовуваними до XP з комп'ютерів XP, а об'єктами GPO, застосовуваними до Vista, - з пристроїв з Vista. Однак, якщо існує необхідність управляти об'єктами GPO Vista з комп'ютерів нижнього рівня, розгляньте третій варіант: активувати наступну політику для користувачів, що редагують об'єкти GPO з комп'ютерів XP, Windows 2000 і Server 2003. Ця політика запобігатиме автоматичне оновлення з платформ нижнього рівня розділу SYSVOL «чистих »об'єктів GPO Vista ADM-файлами при кожній спробі редагування: User ConfigurationAdministrative Templates SystemGroup PolicyTurn off automatic update of ADM files

протоколювання

Актуальна проблема діагностики групової політики в середовищах XP і Server 2003 полягає в зборі корисної інформації з журналів, підготовлених в циклі обробки групової політики. Це особливо важливо, якщо потрібно проаналізувати файл userenv.log, розміщений в папці% WINDIR% DebugUsermode, важкий для розуміння текстовий журнал, в якому записуються подробиці операцій як для користувача профілів, так і групових політик. У зв'язку з цим треба відзначити, що в Vista і Server 2008 компанія Microsoft відмовилася від файлу userenv.log. Обробка GPO тепер відбувається поза файлу userenv.log при використанні власної служби. Тому замість файлу userenv.log докладні відомості про обробку групових політик знаходяться в журналі Group Policy Operational. Цей журнал, показаний на екрані 3, містить подробиці про кроки обробки групових політик на даному комп'ютері.