1. Азбука групових політик
2. Азбука групових політик
3. Азбука групових політик

Азбука групових політик

Налаштовуєте ви десять серверів Windows або настільних комп'ютерів або десять тисяч, знайте, що групова політика пропонує неоціненну допомогу у вирішенні цього завдання. Але багато, ймовірно, чули жахливі історії про складнощі групових політик, коли системний адміністратор вносив зміни, не розуміючи їх наслідків, і в результаті не спрощувала собі життя, а зовсім навпаки. Наприклад, змінивши дозволу Logon Locally в об'єкті групової політики Group Policy Object (GPO) для видалення непотрібних груп, ви можете виявити, що зробили це в GPO, який застосовується до всіх комп'ютерів в домені, і тепер ніхто не може зареєструватися. Я можу розповісти, як це сталося.

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

Розуміння роботи групової політики

Розібратися в тому, як клієнтська система працює з GPO, важливо для того, щоб гарантувати, що все відбувається згідно з планом. Давайте для початку зрозуміємо, що, незважаючи на присутність в назві функції слова «групові», політики застосовуються тільки для комп'ютера і користувача. Тому коли ви призначаєте Group Policy Object (GPO) об'єкту Active Directory (AD), комп'ютерна частина GPO застосовується тільки для об'єктів комп'ютера в AD, а призначена для користувача частина застосовується тільки для об'єктів. Можна використовувати групи безпеки, щоб виявити за допомогою фільтра, які користувачі і комп'ютери пов'язані з даними GPO, однак не можна націлити GPO на певні групи безпеки.

Слідуйте правилу: всякий раз, коли ви прив'язуєте GPO до об'єкта, домену або організаційного підрозділу (OU) в Active Directory, переконайтеся, що користувач або комп'ютер, з яким ви хочете, щоб він був пов'язаний, знаходиться в потрібному контейнері в ієрархічному дереві Active Directory .

Процес прив'язки GPO відрізняється від процесу його створення. Cоздавая GPO в оснащенні Active Directory Users and Computers консолі Microsoft Management Console в Windows 2000, ви одночасно пов'язували цей GPO з контейнером AD. Можливість створювати GPO без під'єднання виникла з появою Group Policy Management Console (GPMC). Використовуючи GPMC, можна створювати різні GPO, під'єднуючи їх пізніше.

Ви також можете повторно використовувати GPO, під'єднуючи його до кількох контейнерів AD, наприклад, можна з'єднати один накладає суворі обмеження на систему GPO з чотирма або п'ятьма OU. Сенс приєднання GPO до кількох контейнерів полягає в тому, що будь-яка зміна в GPO, яке буде внесено згодом, вплине на користувачів і комп'ютери в усіх з'єднаних з ним OU. Однак, оскільки можна під'єднати різні GPO до кількох контейнерів в AD, до конкретного користувача або комп'ютера можуть застосовуватися кілька GPO. Щоб дізнатися, яка політика реалізована в тому чи іншому випадку, потрібно відповісти на два питання:

1. Як Group Policy дізнається, який GPO слід обробляти в першу чергу?

2. Які настройки реалізуються, якщо різні GPO мають різні настройки?

Процес обробки Group Policy відбувається наступним чином. Локальний GPO на даному комп'ютері обробляється в першу чергу, потім GPO, під'єднані до сайту AD, далі GPO, під'єднані до домену AD, і, нарешті, ті, які під'єднані до OU. Оскільки GPO, під'єднані до OU, обробляються в останню чергу, вони в підсумку і визначають, які налаштування GPO застосовуються до комп'ютера або користувачеві. Наприклад, якщо призначений домену GPO видаляє команду меню Run з меню Start в Windows, а GPO, приєднаний до OU, додає цю команду назад в меню, настройки останнього будуть застосовні до комп'ютера або користувачеві, тому що система користувача обробляє цей об'єкт другим. Це призведе до того, що команда меню Run з'явиться в призначеному для користувача меню.

Group Policy обробляється як в оперативному, так і в фоновому режимі. Для комп'ютера обробка в оперативному режимі відбувається, коли система ще тільки запускається, зазвичай до того, як користувач бачить вікно реєстрації, але це не завжди так. Для користувача обробка в оперативному режимі відбувається, коли він реєструється, зазвичай до того, як користувач бачить свій робочий стіл, але це знову ж таки не завжди так. Фонова обробка відбувається періодично з метою поновлення Group Policy. На контролерах домену (DC) фонова обробка для комп'ютера і користувача виконується кожні п'ять хвилин. На автономному сервері і робочих станціях це відбувається за замовчуванням з періодичністю від 90 до 120 хвилин. Хоча Group Policy в ході фонової обробки оновлюється автоматично, не всі частини політики застосовуються в процесі фонової обробки. Так, ні установка програмного забезпечення, ні переадресація папок Folder Redirection в фоновому режимі не застосовуються.

Дозволи Group Policy і фільтрація

Як зазначалося вище, різні GPO обробляються тільки користувачами або комп'ютерами, але вони можуть бути відфільтровані по групах безпеки, які містять облікові записи користувачів і комп'ютерів. За замовчуванням, коли адміністратор створює GPO, група аутентіфіцированний користувачів отримує дозволу читати Read і застосовувати Apply це GPO, які дають всім користувачам і комп'ютерам в даному OU можливість читати і потім обробляти GPO. Але, можливо, знадобиться накласти даний GPO на частину користувачів або комп'ютерів в організаційному підрозділі. В цьому випадку ви можете використовувати групи безпеки для вибору GPO. Це легко зробити, використовуючи обов'язковий для адміністратора інструмент, Group Policy Management Console (GPMC), який поставляється з Windows Vista або може бути завантажений в розділі System Tools сайту www.microsoft.com/downloads .

Як показано на екрані 1 , Можна змінювати групи безпеки для даного GPO, просто додаючи або видаляючи групи з розділу Security Filtering в GPMC.

Припустимо, у вас є GPO, приєднаний до Marketing OU, який містить 200 облікових записів користувачів. Ви хочете додати деякі настройки в призначеній для користувача політиці частини цих користувачів, які є членами групи Marketing Special Projects. За допомогою GPMC це зробити дуже легко. Запустіть GPMC, ввівши gpmc.msc

в рядку Run меню Start. Під вузлом Group Policy Objects в панелі зліва виберіть той GPO, який хочете переглянути. Видаліть групу аутентіфіцированний користувачів з GPO, оскільки вона дозволяє всім користувачам і комп'ютерам обробляти цю політику. Щоб це зробити, виділіть групу у вікні Security Filtering і натисніть кнопку Remove. Потім додайте групу Marketing Special Projects до списку, натиснувши кнопку Add і ввівши ім'я Marketing Special Projects або відшукавши цю групу в домені AD. GPMC подбає про надання дозволів Read Group Policy і Apply Group Policy даному GPO.

Фільтрація за дозволами безпеки визначає, які комп'ютери і користувачі можуть обробляти GPO. Існують також дозволу, які вказують, хто може редагувати GPO. Ви можете побачити ці дозволи, виділяючи GPO в GPMC і вибираючи вкладку Delegation, як показано на екрані 2 .

На вкладці Delegation показані дозволу безпеки з попереднього діалогового блоку Security Filtering разом з дозволами на редагування і зміна GPO. Фактично ви тут можете забезпечити обидва види доступу: надати дозволу на обробку GPO (як і в області Security Filtering) і вказати, хто може редагувати GPO. Більш того, кнопка Advanced внизу екрану є єдиним інструментом в GPMC, за допомогою якого ви можете накласти заборону на доступ Deny до даного GPO. Пам'ятайте, що дозволу безпеки можуть або вирішувати, або забороняти доступ і обидва види записів управління доступом Access Control Entries (ACE) допустимі для дозволів GPO. Однак за замовчуванням інтерфейс GPMC дозволяє накладати тільки відкривають доступ дозволу. Так, наприклад, якщо потрібно накласти заборону на використання дозволів Read Group Policy і Apply Group Policy для групи користувачів або комп'ютерів, які потрібно виключити з обробки GPO, знадобиться натиснути кнопку Advanced. Відкриється знайомий текстовий редактор Access Control List, який використовується для установки дозволів на файли або в AD.

Ще один тип фільтра, доступний на Vista, Windows Server 2003 і Windows XP, - це фільтр Windows Management Instrumentation (WMI). WMI являє собою набір інструментів Windows, які можна задіяти для розширеної фільтрації обробки GPO. Наприклад, потрібно застосувати GPO тільки до систем XP. Використовуючи GPMC, можна створити фільтр WMI, клацнувши правою кнопкою миші на вузлі WMI Filters в дереві вікон і вибравши пункт New. Фільтр WMI повинен мати форму запиту WMI (для отримання більш докладної інформації про фільтрах WMI слід пройти по посиланню technet2.microsoft.com/WindowsServer/en/library/dfba1 dc6-6848-4 ed8-96 da-f4241 c1 acfbd1033.mspx; для отримання інформації про запити WMI див. «Sesame Script: WMI Query Language» за адресою www.microsoft.com/technet/scriptcenter/resources/begin/ss1206.mspx ).

Ви можете пов'язати тільки один фільтр WMI з даними GPO. Якщо запит, зазначений у фільтрі, видасть результат True при читанні GPO, значить, цей об'єкт застосовується. Перевірка запиту WMI відбувається на клієнтському комп'ютері, який обробляє GPO. Запит досліджує власний місцевий репозиторій WMI, щоб отримати відповідь «вірно» або «невірно». Якщо запит повертає False, то GPO до користувача або комп'ютера не застосовується. Чи можна застосовувати фільтр WMI до комп'ютера або користувачеві, залежить від запиту. Наприклад, якщо запитується інформація про те, управляється чи комп'ютер за допомогою XP, це питання специфічне для кожного комп'ютера, і якщо комп'ютер управляється за допомогою XP, GPO застосує фільтр, незалежно від того, зареєструвався користувач на комп'ютері чи ні. Однак, якщо запитується інформація про те, чи зареєструвався користувач Джо Сміт на комп'ютері на даний момент, GPO застосує фільтр тільки тоді, коли Джо Сміт дійсно зареєструється в системі.

Політики або переваги

Ймовірно, найпопулярнішою частиною Group Policy є адміністративні шаблони, Administrative Templates, або політики реєстру. Ця область групових політик дозволяє контролювати багато аспектів системи Windows. Дуже зручно, що політика реєстру більше не прописується явно в реєстрі і відповідно не застосовується, коли не потрібна, як це було в NT 4.0. Відсутність явного прописування означає наступне: припустимо, ви включаєте (або відключаєте) елемент політики реєстру в GPO і застосовуєте його до користувача або комп'ютера, а потім видаляєте цей GPO або міняєте фільтр безпеки для користувача або комп'ютера. Під час наступного циклу оперативної або фонової обробки даний елемент політики буде автоматично видалений, а не «застрягне» в реєстрі, поки ви його примусово не видалите.

Процес видалення працює описаним способом, тому що Microsoft навмисно створила чотири спеціальні розділу реєстру, де записані всі політики, і вони видаляються, коли їх більше не застосовують. Двома розділами політик реєстру для комп'ютера є:

HKEY_LOCAL_MACHINESoftwarePolicies
HKEY_LOCAL_MACHINESoftware
MicrosoftWindowsCurrentVersionPolicies
Розділами політик реєстру для користувача є:
HKEY_CURRENT_USERSoftwarePolicies
HKEY_CURRENT_USERSoftware
MicrosoftWindowsCurrentVersionPolicies

Оскільки настройки політики реєстру пишуться в один з цих чотирьох ключів, вони не будуть залишатися в реєстрі, коли GPO видаляється. Звичайно, щоб записати політики в ці чотири розділи, додатки або компоненти в Windows повинні бути написані так, щоб вони опитували дані розділи на предмет налаштувань політик. Однак ви ще можете створювати файли шаблонів ADM (або ADMX в Vista), які можуть записувати в будь-які розділи реєстру (в HKEY_ LOCAL_MACHINE або HKEY_CURRENT_ USER). Політики, які це роблять, називаються «переваги» і будуть впроваджені в реєстр, навіть якщо GPO, що містить їх, був знищений. Таким чином, якщо вам потрібно скасувати перевагу, яке реалізовано, необхідно відключити його в інтерфейсі Group Policy Editor (GPE) або вручну видалити параметр реєстру.

Явна накладення налаштувань асоціюється з політиками реєстру, а й інші політики показують таку поведінку. Наприклад, політика безпеки примусово реалізує постійні зміни в системі, коли застосовується. Так, якщо ви задаєте призначені для користувача права в конкретній системі (використовуючи політику, знайдену по Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser rights assignment), і потім видаляєте GPO, який реалізував дані настройки звідти, звідки комп'ютер обробляв їх, ці призначення прав користувача залишаються до тих пір, поки ви їх явно не зміните. Це важливо зрозуміти, тому що кожна область політик поводиться по-різному, «залишаючи сліди» в системах. У деяких випадках, наприклад у випадку з політиками для Folder Redirection або Software Installation, необхідно вказати політиці, що робити, коли GPO більше не застосовується, як показано на екрані 3.

Діагностика несправностей в Group Policy

Групові політики - інструмент складний, і іноді вони працюють не так, як очікується. Через неуважність ви можете налаштувати щось не так або політика може не працювати просто через збій. Процес обробки Group Policy вимагає, щоб деякі компоненти працювали в згоді. Інфраструктура вашої AD і робочі станції повинні бути справні, а різні настройки, які ви задаєте, повинні бути сумісні з додатками, запущеними на комп'ютерах. Коли щось з перерахованого не так, ви можете побачити, що процес обробки Group Policy не виконано.

Як визначити, в чому причина? Для початку потрібно створити звіт Resultant Set of Policy (RSoP) на несправній системі. RSoP збирається за допомогою майстра Group Policy Results Wizard зі складу GPMC. Крім того, можна використовувати з командного рядка утиліту gpresult.exe, яка поставляється з Vista, Windows 2003 і XP. Найпростіший спосіб - запустити майстер Group Policy Results з GPMC. Він дозволить вибрати локальний або віддалений комп'ютер для підключення, потім вибрати користувача, який зареєструвався на комп'ютері. Після цього майстер з'єднується з віддаленим комп'ютером і збирає інформацію про процес обробки Group Policy, який був виконаний останнім. Найкорисніша частина звіту - це вкладка Summary, яка представлена ​​на екрані 4 .

Вкладка Summary показує, які GPO були застосовані до комп'ютера і користувачеві, і, що найважливіше, які GPO були відхилені і чому. Розділ звіту Component Status може дати інформацію про те, чи всі частини процесу обробки Group Policy були виконані, і якщо ні, то чому. Елемент Group Policy Infrastructure, який ви побачите в цьому розділі, розповість про те, чи була базова частина процесу обробки Group Policy успішною. Якщо це не так, то зазвичай виявляються деякі проблеми в інфраструктурі, які заважають виконанню процесу обробки Group Policy. Якщо помилка з'являється в так званих розширеннях клієнта, які реалізують різні аспекти політики, можна усунути цю проблему, використовуючи представлені повідомлення про помилки. Якщо ви хочете подивитися, які налаштування індивідуальної політики були доставлені комп'ютера або користувачеві, ви можете відкрити вкладку Settings в підсумковому звіті по Group Policy, щоб побачити, які налаштування в результаті були застосовані. Однак повідомлення про застосування налаштувань в звіті RSoP ще не означає, що вони були виконані успішно. Краще іноді перевіряти базові настройки, щоб дізнатися, чи зроблена дана настройка в рамках застосування політики безпеки або існує значення параметра реєстру.

Крім того, можна заглянути в історію послуги системи Windows (зауважте, що Vista розміщує події Group Policy в системному журналі і в журналі Group Policy Operations), щоб переглянути інші помилки, пов'язані з процесом обробки Group Policy.

Знання сила

Group Policy складні і могутні. Зрозумівши, як вони обробляються, ви зможете в повній мірі використовувати їх силу. Пам'ятайте, що Group Policy обробляються в наступному порядку: локальний GPO, сайт AD, домен, потім OU (іноді для цієї послідовності застосовують скорочення LSDOU) і, в типовій ситуації, «що пише останнім виграє», якщо є конфліктуючі настройки. Політики і переваги можуть впливати на те, як політика «залишає сліди» в системах, коли GPO видаляється, що важливо при виборі на користь того чи іншого інструменту. Політики реєстру, поширювані Microsoft в стандартних файлах ADM і ADMX, зазвичай не змінюють реєстр, але створені самостійно файли ADMX можуть це робити. До того ж інші аспекти політики, такі як безпека, змінюють системи і повинні бути явно і примусово скасовані, тоді як деяким частинам політики потрібно вказати, що слід скасувати свої дії, коли вони більше не застосовуються. Нарешті, якщо політика все-таки працює не так, як очікувалося, зверніться до майстра Group Policy Results в GPMC.

Даррен Мар-Еліа ( [email protected] ) - редактор журналу Windows IT Pro

Відбір об'єктів в GPMC

Делегування управління GPO з використанням GPMC

Вкладка Summary в звіті RSOP

Азбука групових політик

Налаштовуєте ви десять серверів Windows або настільних комп'ютерів або десять тисяч, знайте, що групова політика пропонує неоціненну допомогу у вирішенні цього завдання. Але багато, ймовірно, чули жахливі історії про складнощі групових політик, коли системний адміністратор вносив зміни, не розуміючи їх наслідків, і в результаті не спрощувала собі життя, а зовсім навпаки. Наприклад, змінивши дозволу Logon Locally в об'єкті групової політики Group Policy Object (GPO) для видалення непотрібних груп, ви можете виявити, що зробили це в GPO, який застосовується до всіх комп'ютерів в домені, і тепер ніхто не може зареєструватися. Я можу розповісти, як це сталося.

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

Розуміння роботи групової політики

Розібратися в тому, як клієнтська система працює з GPO, важливо для того, щоб гарантувати, що все відбувається згідно з планом. Давайте для початку зрозуміємо, що, незважаючи на присутність в назві функції слова «групові», політики застосовуються тільки для комп'ютера і користувача. Тому коли ви призначаєте Group Policy Object (GPO) об'єкту Active Directory (AD), комп'ютерна частина GPO застосовується тільки для об'єктів комп'ютера в AD, а призначена для користувача частина застосовується тільки для об'єктів. Можна використовувати групи безпеки, щоб виявити за допомогою фільтра, які користувачі і комп'ютери пов'язані з даними GPO, однак не можна націлити GPO на певні групи безпеки.

Слідуйте правилу: всякий раз, коли ви прив'язуєте GPO до об'єкта, домену або організаційного підрозділу (OU) в Active Directory, переконайтеся, що користувач або комп'ютер, з яким ви хочете, щоб він був пов'язаний, знаходиться в потрібному контейнері в ієрархічному дереві Active Directory .

Процес прив'язки GPO відрізняється від процесу його створення. Cоздавая GPO в оснащенні Active Directory Users and Computers консолі Microsoft Management Console в Windows 2000, ви одночасно пов'язували цей GPO з контейнером AD. Можливість створювати GPO без під'єднання виникла з появою Group Policy Management Console (GPMC). Використовуючи GPMC, можна створювати різні GPO, під'єднуючи їх пізніше.

Ви також можете повторно використовувати GPO, під'єднуючи його до кількох контейнерів AD, наприклад, можна з'єднати один накладає суворі обмеження на систему GPO з чотирма або п'ятьма OU. Сенс приєднання GPO до кількох контейнерів полягає в тому, що будь-яка зміна в GPO, яке буде внесено згодом, вплине на користувачів і комп'ютери в усіх з'єднаних з ним OU. Однак, оскільки можна під'єднати різні GPO до кількох контейнерів в AD, до конкретного користувача або комп'ютера можуть застосовуватися кілька GPO. Щоб дізнатися, яка політика реалізована в тому чи іншому випадку, потрібно відповісти на два питання:

1. Як Group Policy дізнається, який GPO слід обробляти в першу чергу?

2. Які настройки реалізуються, якщо різні GPO мають різні настройки?

Процес обробки Group Policy відбувається наступним чином. Локальний GPO на даному комп'ютері обробляється в першу чергу, потім GPO, під'єднані до сайту AD, далі GPO, під'єднані до домену AD, і, нарешті, ті, які під'єднані до OU. Оскільки GPO, під'єднані до OU, обробляються в останню чергу, вони в підсумку і визначають, які налаштування GPO застосовуються до комп'ютера або користувачеві. Наприклад, якщо призначений домену GPO видаляє команду меню Run з меню Start в Windows, а GPO, приєднаний до OU, додає цю команду назад в меню, настройки останнього будуть застосовні до комп'ютера або користувачеві, тому що система користувача обробляє цей об'єкт другим. Це призведе до того, що команда меню Run з'явиться в призначеному для користувача меню.

Group Policy обробляється як в оперативному, так і в фоновому режимі. Для комп'ютера обробка в оперативному режимі відбувається, коли система ще тільки запускається, зазвичай до того, як користувач бачить вікно реєстрації, але це не завжди так. Для користувача обробка в оперативному режимі відбувається, коли він реєструється, зазвичай до того, як користувач бачить свій робочий стіл, але це знову ж таки не завжди так. Фонова обробка відбувається періодично з метою поновлення Group Policy. На контролерах домену (DC) фонова обробка для комп'ютера і користувача виконується кожні п'ять хвилин. На автономному сервері і робочих станціях це відбувається за замовчуванням з періодичністю від 90 до 120 хвилин. Хоча Group Policy в ході фонової обробки оновлюється автоматично, не всі частини політики застосовуються в процесі фонової обробки. Так, ні установка програмного забезпечення, ні переадресація папок Folder Redirection в фоновому режимі не застосовуються.

Дозволи Group Policy і фільтрація

Як зазначалося вище, різні GPO обробляються тільки користувачами або комп'ютерами, але вони можуть бути відфільтровані по групах безпеки, які містять облікові записи користувачів і комп'ютерів. За замовчуванням, коли адміністратор створює GPO, група аутентіфіцированний користувачів отримує дозволу читати Read і застосовувати Apply це GPO, які дають всім користувачам і комп'ютерам в даному OU можливість читати і потім обробляти GPO. Але, можливо, знадобиться накласти даний GPO на частину користувачів або комп'ютерів в організаційному підрозділі. В цьому випадку ви можете використовувати групи безпеки для вибору GPO. Це легко зробити, використовуючи обов'язковий для адміністратора інструмент, Group Policy Management Console (GPMC), який поставляється з Windows Vista або може бути завантажений в розділі System Tools сайту www.microsoft.com/downloads .

Як показано на екрані 1 , Можна змінювати групи безпеки для даного GPO, просто додаючи або видаляючи групи з розділу Security Filtering в GPMC.

Припустимо, у вас є GPO, приєднаний до Marketing OU, який містить 200 облікових записів користувачів. Ви хочете додати деякі настройки в призначеній для користувача політиці частини цих користувачів, які є членами групи Marketing Special Projects. За допомогою GPMC це зробити дуже легко. Запустіть GPMC, ввівши gpmc.msc

в рядку Run меню Start. Під вузлом Group Policy Objects в панелі зліва виберіть той GPO, який хочете переглянути. Видаліть групу аутентіфіцированний користувачів з GPO, оскільки вона дозволяє всім користувачам і комп'ютерам обробляти цю політику. Щоб це зробити, виділіть групу у вікні Security Filtering і натисніть кнопку Remove. Потім додайте групу Marketing Special Projects до списку, натиснувши кнопку Add і ввівши ім'я Marketing Special Projects або відшукавши цю групу в домені AD. GPMC подбає про надання дозволів Read Group Policy і Apply Group Policy даному GPO.

Фільтрація за дозволами безпеки визначає, які комп'ютери і користувачі можуть обробляти GPO. Існують також дозволу, які вказують, хто може редагувати GPO. Ви можете побачити ці дозволи, виділяючи GPO в GPMC і вибираючи вкладку Delegation, як показано на екрані 2 .

На вкладці Delegation показані дозволу безпеки з попереднього діалогового блоку Security Filtering разом з дозволами на редагування і зміна GPO. Фактично ви тут можете забезпечити обидва види доступу: надати дозволу на обробку GPO (як і в області Security Filtering) і вказати, хто може редагувати GPO. Більш того, кнопка Advanced внизу екрану є єдиним інструментом в GPMC, за допомогою якого ви можете накласти заборону на доступ Deny до даного GPO. Пам'ятайте, що дозволу безпеки можуть або вирішувати, або забороняти доступ і обидва види записів управління доступом Access Control Entries (ACE) допустимі для дозволів GPO. Однак за замовчуванням інтерфейс GPMC дозволяє накладати тільки відкривають доступ дозволу. Так, наприклад, якщо потрібно накласти заборону на використання дозволів Read Group Policy і Apply Group Policy для групи користувачів або комп'ютерів, які потрібно виключити з обробки GPO, знадобиться натиснути кнопку Advanced. Відкриється знайомий текстовий редактор Access Control List, який використовується для установки дозволів на файли або в AD.

Ще один тип фільтра, доступний на Vista, Windows Server 2003 і Windows XP, - це фільтр Windows Management Instrumentation (WMI). WMI являє собою набір інструментів Windows, які можна задіяти для розширеної фільтрації обробки GPO. Наприклад, потрібно застосувати GPO тільки до систем XP. Використовуючи GPMC, можна створити фільтр WMI, клацнувши правою кнопкою миші на вузлі WMI Filters в дереві вікон і вибравши пункт New. Фільтр WMI повинен мати форму запиту WMI (для отримання більш докладної інформації про фільтрах WMI слід пройти по посиланню technet2.microsoft.com/WindowsServer/en/library/dfba1 dc6-6848-4 ed8-96 da-f4241 c1 acfbd1033.mspx; для отримання інформації про запити WMI див. «Sesame Script: WMI Query Language» за адресою www.microsoft.com/technet/scriptcenter/resources/begin/ss1206.mspx ).

Ви можете пов'язати тільки один фільтр WMI з даними GPO. Якщо запит, зазначений у фільтрі, видасть результат True при читанні GPO, значить, цей об'єкт застосовується. Перевірка запиту WMI відбувається на клієнтському комп'ютері, який обробляє GPO. Запит досліджує власний місцевий репозиторій WMI, щоб отримати відповідь «вірно» або «невірно». Якщо запит повертає False, то GPO до користувача або комп'ютера не застосовується. Чи можна застосовувати фільтр WMI до комп'ютера або користувачеві, залежить від запиту. Наприклад, якщо запитується інформація про те, управляється чи комп'ютер за допомогою XP, це питання специфічне для кожного комп'ютера, і якщо комп'ютер управляється за допомогою XP, GPO застосує фільтр, незалежно від того, зареєструвався користувач на комп'ютері чи ні. Однак, якщо запитується інформація про те, чи зареєструвався користувач Джо Сміт на комп'ютері на даний момент, GPO застосує фільтр тільки тоді, коли Джо Сміт дійсно зареєструється в системі.

Політики або переваги

Ймовірно, найпопулярнішою частиною Group Policy є адміністративні шаблони, Administrative Templates, або політики реєстру. Ця область групових політик дозволяє контролювати багато аспектів системи Windows. Дуже зручно, що політика реєстру більше не прописується явно в реєстрі і відповідно не застосовується, коли не потрібна, як це було в NT 4.0. Відсутність явного прописування означає наступне: припустимо, ви включаєте (або відключаєте) елемент політики реєстру в GPO і застосовуєте його до користувача або комп'ютера, а потім видаляєте цей GPO або міняєте фільтр безпеки для користувача або комп'ютера. Під час наступного циклу оперативної або фонової обробки даний елемент політики буде автоматично видалений, а не «застрягне» в реєстрі, поки ви його примусово не видалите.

Процес видалення працює описаним способом, тому що Microsoft навмисно створила чотири спеціальні розділу реєстру, де записані всі політики, і вони видаляються, коли їх більше не застосовують. Двома розділами політик реєстру для комп'ютера є:

HKEY_LOCAL_MACHINESoftwarePolicies
HKEY_LOCAL_MACHINESoftware
MicrosoftWindowsCurrentVersionPolicies
Розділами політик реєстру для користувача є:
HKEY_CURRENT_USERSoftwarePolicies
HKEY_CURRENT_USERSoftware
MicrosoftWindowsCurrentVersionPolicies

Оскільки настройки політики реєстру пишуться в один з цих чотирьох ключів, вони не будуть залишатися в реєстрі, коли GPO видаляється. Звичайно, щоб записати політики в ці чотири розділи, додатки або компоненти в Windows повинні бути написані так, щоб вони опитували дані розділи на предмет налаштувань політик. Однак ви ще можете створювати файли шаблонів ADM (або ADMX в Vista), які можуть записувати в будь-які розділи реєстру (в HKEY_ LOCAL_MACHINE або HKEY_CURRENT_ USER). Політики, які це роблять, називаються «переваги» і будуть впроваджені в реєстр, навіть якщо GPO, що містить їх, був знищений. Таким чином, якщо вам потрібно скасувати перевагу, яке реалізовано, необхідно відключити його в інтерфейсі Group Policy Editor (GPE) або вручну видалити параметр реєстру.

Явна накладення налаштувань асоціюється з політиками реєстру, а й інші політики показують таку поведінку. Наприклад, політика безпеки примусово реалізує постійні зміни в системі, коли застосовується. Так, якщо ви задаєте призначені для користувача права в конкретній системі (використовуючи політику, знайдену по Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser rights assignment), і потім видаляєте GPO, який реалізував дані настройки звідти, звідки комп'ютер обробляв їх, ці призначення прав користувача залишаються до тих пір, поки ви їх явно не зміните. Це важливо зрозуміти, тому що кожна область політик поводиться по-різному, «залишаючи сліди» в системах. У деяких випадках, наприклад у випадку з політиками для Folder Redirection або Software Installation, необхідно вказати політиці, що робити, коли GPO більше не застосовується, як показано на екрані 3.

Діагностика несправностей в Group Policy

Групові політики - інструмент складний, і іноді вони працюють не так, як очікується. Через неуважність ви можете налаштувати щось не так або політика може не працювати просто через збій. Процес обробки Group Policy вимагає, щоб деякі компоненти працювали в згоді. Інфраструктура вашої AD і робочі станції повинні бути справні, а різні настройки, які ви задаєте, повинні бути сумісні з додатками, запущеними на комп'ютерах. Коли щось з перерахованого не так, ви можете побачити, що процес обробки Group Policy не виконано.

Як визначити, в чому причина? Для початку потрібно створити звіт Resultant Set of Policy (RSoP) на несправній системі. RSoP збирається за допомогою майстра Group Policy Results Wizard зі складу GPMC. Крім того, можна використовувати з командного рядка утиліту gpresult.exe, яка поставляється з Vista, Windows 2003 і XP. Найпростіший спосіб - запустити майстер Group Policy Results з GPMC. Він дозволить вибрати локальний або віддалений комп'ютер для підключення, потім вибрати користувача, який зареєструвався на комп'ютері. Після цього майстер з'єднується з віддаленим комп'ютером і збирає інформацію про процес обробки Group Policy, який був виконаний останнім. Найкорисніша частина звіту - це вкладка Summary, яка представлена ​​на екрані 4 .

Вкладка Summary показує, які GPO були застосовані до комп'ютера і користувачеві, і, що найважливіше, які GPO були відхилені і чому. Розділ звіту Component Status може дати інформацію про те, чи всі частини процесу обробки Group Policy були виконані, і якщо ні, то чому. Елемент Group Policy Infrastructure, який ви побачите в цьому розділі, розповість про те, чи була базова частина процесу обробки Group Policy успішною. Якщо це не так, то зазвичай виявляються деякі проблеми в інфраструктурі, які заважають виконанню процесу обробки Group Policy. Якщо помилка з'являється в так званих розширеннях клієнта, які реалізують різні аспекти політики, можна усунути цю проблему, використовуючи представлені повідомлення про помилки. Якщо ви хочете подивитися, які налаштування індивідуальної політики були доставлені комп'ютера або користувачеві, ви можете відкрити вкладку Settings в підсумковому звіті по Group Policy, щоб побачити, які налаштування в результаті були застосовані. Однак повідомлення про застосування налаштувань в звіті RSoP ще не означає, що вони були виконані успішно. Краще іноді перевіряти базові настройки, щоб дізнатися, чи зроблена дана настройка в рамках застосування політики безпеки або існує значення параметра реєстру.

Крім того, можна заглянути в історію послуги системи Windows (зауважте, що Vista розміщує події Group Policy в системному журналі і в журналі Group Policy Operations), щоб переглянути інші помилки, пов'язані з процесом обробки Group Policy.

Знання сила

Group Policy складні і могутні. Зрозумівши, як вони обробляються, ви зможете в повній мірі використовувати їх силу. Пам'ятайте, що Group Policy обробляються в наступному порядку: локальний GPO, сайт AD, домен, потім OU (іноді для цієї послідовності застосовують скорочення LSDOU) і, в типовій ситуації, «що пише останнім виграє», якщо є конфліктуючі настройки. Політики і переваги можуть впливати на те, як політика «залишає сліди» в системах, коли GPO видаляється, що важливо при виборі на користь того чи іншого інструменту. Політики реєстру, поширювані Microsoft в стандартних файлах ADM і ADMX, зазвичай не змінюють реєстр, але створені самостійно файли ADMX можуть це робити. До того ж інші аспекти політики, такі як безпека, змінюють системи і повинні бути явно і примусово скасовані, тоді як деяким частинам політики потрібно вказати, що слід скасувати свої дії, коли вони більше не застосовуються. Нарешті, якщо політика все-таки працює не так, як очікувалося, зверніться до майстра Group Policy Results в GPMC.

Даррен Мар-Еліа ( [email protected] ) - редактор журналу Windows IT Pro

Відбір об'єктів в GPMC

Делегування управління GPO з використанням GPMC

Вкладка Summary в звіті RSOP

Азбука групових політик

Налаштовуєте ви десять серверів Windows або настільних комп'ютерів або десять тисяч, знайте, що групова політика пропонує неоціненну допомогу у вирішенні цього завдання. Але багато, ймовірно, чули жахливі історії про складнощі групових політик, коли системний адміністратор вносив зміни, не розуміючи їх наслідків, і в результаті не спрощувала собі життя, а зовсім навпаки. Наприклад, змінивши дозволу Logon Locally в об'єкті групової політики Group Policy Object (GPO) для видалення непотрібних груп, ви можете виявити, що зробили це в GPO, який застосовується до всіх комп'ютерів в домені, і тепер ніхто не може зареєструватися. Я можу розповісти, як це сталося.

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

Розуміння роботи групової політики

Розібратися в тому, як клієнтська система працює з GPO, важливо для того, щоб гарантувати, що все відбувається згідно з планом. Давайте для початку зрозуміємо, що, незважаючи на присутність в назві функції слова «групові», політики застосовуються тільки для комп'ютера і користувача. Тому коли ви призначаєте Group Policy Object (GPO) об'єкту Active Directory (AD), комп'ютерна частина GPO застосовується тільки для об'єктів комп'ютера в AD, а призначена для користувача частина застосовується тільки для об'єктів. Можна використовувати групи безпеки, щоб виявити за допомогою фільтра, які користувачі і комп'ютери пов'язані з даними GPO, однак не можна націлити GPO на певні групи безпеки.

Слідуйте правилу: всякий раз, коли ви прив'язуєте GPO до об'єкта, домену або організаційного підрозділу (OU) в Active Directory, переконайтеся, що користувач або комп'ютер, з яким ви хочете, щоб він був пов'язаний, знаходиться в потрібному контейнері в ієрархічному дереві Active Directory .

Процес прив'язки GPO відрізняється від процесу його створення. Cоздавая GPO в оснащенні Active Directory Users and Computers консолі Microsoft Management Console в Windows 2000, ви одночасно пов'язували цей GPO з контейнером AD. Можливість створювати GPO без під'єднання виникла з появою Group Policy Management Console (GPMC). Використовуючи GPMC, можна створювати різні GPO, під'єднуючи їх пізніше.

Ви також можете повторно використовувати GPO, під'єднуючи його до кількох контейнерів AD, наприклад, можна з'єднати один накладає суворі обмеження на систему GPO з чотирма або п'ятьма OU. Сенс приєднання GPO до кількох контейнерів полягає в тому, що будь-яка зміна в GPO, яке буде внесено згодом, вплине на користувачів і комп'ютери в усіх з'єднаних з ним OU. Однак, оскільки можна під'єднати різні GPO до кількох контейнерів в AD, до конкретного користувача або комп'ютера можуть застосовуватися кілька GPO. Щоб дізнатися, яка політика реалізована в тому чи іншому випадку, потрібно відповісти на два питання:

1. Як Group Policy дізнається, який GPO слід обробляти в першу чергу?

2. Які настройки реалізуються, якщо різні GPO мають різні настройки?

Процес обробки Group Policy відбувається наступним чином. Локальний GPO на даному комп'ютері обробляється в першу чергу, потім GPO, під'єднані до сайту AD, далі GPO, під'єднані до домену AD, і, нарешті, ті, які під'єднані до OU. Оскільки GPO, під'єднані до OU, обробляються в останню чергу, вони в підсумку і визначають, які налаштування GPO застосовуються до комп'ютера або користувачеві. Наприклад, якщо призначений домену GPO видаляє команду меню Run з меню Start в Windows, а GPO, приєднаний до OU, додає цю команду назад в меню, настройки останнього будуть застосовні до комп'ютера або користувачеві, тому що система користувача обробляє цей об'єкт другим. Це призведе до того, що команда меню Run з'явиться в призначеному для користувача меню.

Group Policy обробляється як в оперативному, так і в фоновому режимі. Для комп'ютера обробка в оперативному режимі відбувається, коли система ще тільки запускається, зазвичай до того, як користувач бачить вікно реєстрації, але це не завжди так. Для користувача обробка в оперативному режимі відбувається, коли він реєструється, зазвичай до того, як користувач бачить свій робочий стіл, але це знову ж таки не завжди так. Фонова обробка відбувається періодично з метою поновлення Group Policy. На контролерах домену (DC) фонова обробка для комп'ютера і користувача виконується кожні п'ять хвилин. На автономному сервері і робочих станціях це відбувається за замовчуванням з періодичністю від 90 до 120 хвилин. Хоча Group Policy в ході фонової обробки оновлюється автоматично, не всі частини політики застосовуються в процесі фонової обробки. Так, ні установка програмного забезпечення, ні переадресація папок Folder Redirection в фоновому режимі не застосовуються.

Дозволи Group Policy і фільтрація

Як зазначалося вище, різні GPO обробляються тільки користувачами або комп'ютерами, але вони можуть бути відфільтровані по групах безпеки, які містять облікові записи користувачів і комп'ютерів. За замовчуванням, коли адміністратор створює GPO, група аутентіфіцированний користувачів отримує дозволу читати Read і застосовувати Apply це GPO, які дають всім користувачам і комп'ютерам в даному OU можливість читати і потім обробляти GPO. Але, можливо, знадобиться накласти даний GPO на частину користувачів або комп'ютерів в організаційному підрозділі. В цьому випадку ви можете використовувати групи безпеки для вибору GPO. Це легко зробити, використовуючи обов'язковий для адміністратора інструмент, Group Policy Management Console (GPMC), який поставляється з Windows Vista або може бути завантажений в розділі System Tools сайту www.microsoft.com/downloads .

Як показано на екрані 1 , Можна змінювати групи безпеки для даного GPO, просто додаючи або видаляючи групи з розділу Security Filtering в GPMC.

Припустимо, у вас є GPO, приєднаний до Marketing OU, який містить 200 облікових записів користувачів. Ви хочете додати деякі настройки в призначеній для користувача політиці частини цих користувачів, які є членами групи Marketing Special Projects. За допомогою GPMC це зробити дуже легко. Запустіть GPMC, ввівши gpmc.msc

в рядку Run меню Start. Під вузлом Group Policy Objects в панелі зліва виберіть той GPO, який хочете переглянути. Видаліть групу аутентіфіцированний користувачів з GPO, оскільки вона дозволяє всім користувачам і комп'ютерам обробляти цю політику. Щоб це зробити, виділіть групу у вікні Security Filtering і натисніть кнопку Remove. Потім додайте групу Marketing Special Projects до списку, натиснувши кнопку Add і ввівши ім'я Marketing Special Projects або відшукавши цю групу в домені AD. GPMC подбає про надання дозволів Read Group Policy і Apply Group Policy даному GPO.

Фільтрація за дозволами безпеки визначає, які комп'ютери і користувачі можуть обробляти GPO. Існують також дозволу, які вказують, хто може редагувати GPO. Ви можете побачити ці дозволи, виділяючи GPO в GPMC і вибираючи вкладку Delegation, як показано на екрані 2 .

На вкладці Delegation показані дозволу безпеки з попереднього діалогового блоку Security Filtering разом з дозволами на редагування і зміна GPO. Фактично ви тут можете забезпечити обидва види доступу: надати дозволу на обробку GPO (як і в області Security Filtering) і вказати, хто може редагувати GPO. Більш того, кнопка Advanced внизу екрану є єдиним інструментом в GPMC, за допомогою якого ви можете накласти заборону на доступ Deny до даного GPO. Пам'ятайте, що дозволу безпеки можуть або вирішувати, або забороняти доступ і обидва види записів управління доступом Access Control Entries (ACE) допустимі для дозволів GPO. Однак за замовчуванням інтерфейс GPMC дозволяє накладати тільки відкривають доступ дозволу. Так, наприклад, якщо потрібно накласти заборону на використання дозволів Read Group Policy і Apply Group Policy для групи користувачів або комп'ютерів, які потрібно виключити з обробки GPO, знадобиться натиснути кнопку Advanced. Відкриється знайомий текстовий редактор Access Control List, який використовується для установки дозволів на файли або в AD.

Ще один тип фільтра, доступний на Vista, Windows Server 2003 і Windows XP, - це фільтр Windows Management Instrumentation (WMI). WMI являє собою набір інструментів Windows, які можна задіяти для розширеної фільтрації обробки GPO. Наприклад, потрібно застосувати GPO тільки до систем XP. Використовуючи GPMC, можна створити фільтр WMI, клацнувши правою кнопкою миші на вузлі WMI Filters в дереві вікон і вибравши пункт New. Фільтр WMI повинен мати форму запиту WMI (для отримання більш докладної інформації про фільтрах WMI слід пройти по посиланню technet2.microsoft.com/WindowsServer/en/library/dfba1 dc6-6848-4 ed8-96 da-f4241 c1 acfbd1033.mspx; для отримання інформації про запити WMI див. «Sesame Script: WMI Query Language» за адресою www.microsoft.com/technet/scriptcenter/resources/begin/ss1206.mspx ).

Ви можете пов'язати тільки один фільтр WMI з даними GPO. Якщо запит, зазначений у фільтрі, видасть результат True при читанні GPO, значить, цей об'єкт застосовується. Перевірка запиту WMI відбувається на клієнтському комп'ютері, який обробляє GPO. Запит досліджує власний місцевий репозиторій WMI, щоб отримати відповідь «вірно» або «невірно». Якщо запит повертає False, то GPO до користувача або комп'ютера не застосовується. Чи можна застосовувати фільтр WMI до комп'ютера або користувачеві, залежить від запиту. Наприклад, якщо запитується інформація про те, управляється чи комп'ютер за допомогою XP, це питання специфічне для кожного комп'ютера, і якщо комп'ютер управляється за допомогою XP, GPO застосує фільтр, незалежно від того, зареєструвався користувач на комп'ютері чи ні. Однак, якщо запитується інформація про те, чи зареєструвався користувач Джо Сміт на комп'ютері на даний момент, GPO застосує фільтр тільки тоді, коли Джо Сміт дійсно зареєструється в системі.

Політики або переваги

Ймовірно, найпопулярнішою частиною Group Policy є адміністративні шаблони, Administrative Templates, або політики реєстру. Ця область групових політик дозволяє контролювати багато аспектів системи Windows. Дуже зручно, що політика реєстру більше не прописується явно в реєстрі і відповідно не застосовується, коли не потрібна, як це було в NT 4.0. Відсутність явного прописування означає наступне: припустимо, ви включаєте (або відключаєте) елемент політики реєстру в GPO і застосовуєте його до користувача або комп'ютера, а потім видаляєте цей GPO або міняєте фільтр безпеки для користувача або комп'ютера. Під час наступного циклу оперативної або фонової обробки даний елемент політики буде автоматично видалений, а не «застрягне» в реєстрі, поки ви його примусово не видалите.

Процес видалення працює описаним способом, тому що Microsoft навмисно створила чотири спеціальні розділу реєстру, де записані всі політики, і вони видаляються, коли їх більше не застосовують. Двома розділами політик реєстру для комп'ютера є:

HKEY_LOCAL_MACHINESoftwarePolicies
HKEY_LOCAL_MACHINESoftware
MicrosoftWindowsCurrentVersionPolicies
Розділами політик реєстру для користувача є:
HKEY_CURRENT_USERSoftwarePolicies
HKEY_CURRENT_USERSoftware
MicrosoftWindowsCurrentVersionPolicies

Оскільки настройки політики реєстру пишуться в один з цих чотирьох ключів, вони не будуть залишатися в реєстрі, коли GPO видаляється. Звичайно, щоб записати політики в ці чотири розділи, додатки або компоненти в Windows повинні бути написані так, щоб вони опитували дані розділи на предмет налаштувань політик. Однак ви ще можете створювати файли шаблонів ADM (або ADMX в Vista), які можуть записувати в будь-які розділи реєстру (в HKEY_ LOCAL_MACHINE або HKEY_CURRENT_ USER). Політики, які це роблять, називаються «переваги» і будуть впроваджені в реєстр, навіть якщо GPO, що містить їх, був знищений. Таким чином, якщо вам потрібно скасувати перевагу, яке реалізовано, необхідно відключити його в інтерфейсі Group Policy Editor (GPE) або вручну видалити параметр реєстру.

Явна накладення налаштувань асоціюється з політиками реєстру, а й інші політики показують таку поведінку. Наприклад, політика безпеки примусово реалізує постійні зміни в системі, коли застосовується. Так, якщо ви задаєте призначені для користувача права в конкретній системі (використовуючи політику, знайдену по Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser rights assignment), і потім видаляєте GPO, який реалізував дані настройки звідти, звідки комп'ютер обробляв їх, ці призначення прав користувача залишаються до тих пір, поки ви їх явно не зміните. Це важливо зрозуміти, тому що кожна область політик поводиться по-різному, «залишаючи сліди» в системах. У деяких випадках, наприклад у випадку з політиками для Folder Redirection або Software Installation, необхідно вказати політиці, що робити, коли GPO більше не застосовується, як показано на екрані 3.

Діагностика несправностей в Group Policy

Групові політики - інструмент складний, і іноді вони працюють не так, як очікується. Через неуважність ви можете налаштувати щось не так або політика може не працювати просто через збій. Процес обробки Group Policy вимагає, щоб деякі компоненти працювали в згоді. Інфраструктура вашої AD і робочі станції повинні бути справні, а різні настройки, які ви задаєте, повинні бути сумісні з додатками, запущеними на комп'ютерах. Коли щось з перерахованого не так, ви можете побачити, що процес обробки Group Policy не виконано.

Як визначити, в чому причина? Для початку потрібно створити звіт Resultant Set of Policy (RSoP) на несправній системі. RSoP збирається за допомогою майстра Group Policy Results Wizard зі складу GPMC. Крім того, можна використовувати з командного рядка утиліту gpresult.exe, яка поставляється з Vista, Windows 2003 і XP. Найпростіший спосіб - запустити майстер Group Policy Results з GPMC. Він дозволить вибрати локальний або віддалений комп'ютер для підключення, потім вибрати користувача, який зареєструвався на комп'ютері. Після цього майстер з'єднується з віддаленим комп'ютером і збирає інформацію про процес обробки Group Policy, який був виконаний останнім. Найкорисніша частина звіту - це вкладка Summary, яка представлена ​​на екрані 4 .

Вкладка Summary показує, які GPO були застосовані до комп'ютера і користувачеві, і, що найважливіше, які GPO були відхилені і чому. Розділ звіту Component Status може дати інформацію про те, чи всі частини процесу обробки Group Policy були виконані, і якщо ні, то чому. Елемент Group Policy Infrastructure, який ви побачите в цьому розділі, розповість про те, чи була базова частина процесу обробки Group Policy успішною. Якщо це не так, то зазвичай виявляються деякі проблеми в інфраструктурі, які заважають виконанню процесу обробки Group Policy. Якщо помилка з'являється в так званих розширеннях клієнта, які реалізують різні аспекти політики, можна усунути цю проблему, використовуючи представлені повідомлення про помилки. Якщо ви хочете подивитися, які налаштування індивідуальної політики були доставлені комп'ютера або користувачеві, ви можете відкрити вкладку Settings в підсумковому звіті по Group Policy, щоб побачити, які налаштування в результаті були застосовані. Однак повідомлення про застосування налаштувань в звіті RSoP ще не означає, що вони були виконані успішно. Краще іноді перевіряти базові настройки, щоб дізнатися, чи зроблена дана настройка в рамках застосування політики безпеки або існує значення параметра реєстру.

Крім того, можна заглянути в історію послуги системи Windows (зауважте, що Vista розміщує події Group Policy в системному журналі і в журналі Group Policy Operations), щоб переглянути інші помилки, пов'язані з процесом обробки Group Policy.

Знання сила

Group Policy складні і могутні. Зрозумівши, як вони обробляються, ви зможете в повній мірі використовувати їх силу. Пам'ятайте, що Group Policy обробляються в наступному порядку: локальний GPO, сайт AD, домен, потім OU (іноді для цієї послідовності застосовують скорочення LSDOU) і, в типовій ситуації, «що пише останнім виграє», якщо є конфліктуючі настройки. Політики і переваги можуть впливати на те, як політика «залишає сліди» в системах, коли GPO видаляється, що важливо при виборі на користь того чи іншого інструменту. Політики реєстру, поширювані Microsoft в стандартних файлах ADM і ADMX, зазвичай не змінюють реєстр, але створені самостійно файли ADMX можуть це робити. До того ж інші аспекти політики, такі як безпека, змінюють системи і повинні бути явно і примусово скасовані, тоді як деяким частинам політики потрібно вказати, що слід скасувати свої дії, коли вони більше не застосовуються. Нарешті, якщо політика все-таки працює не так, як очікувалося, зверніться до майстра Group Policy Results в GPMC.

Даррен Мар-Еліа ( [email protected] ) - редактор журналу Windows IT Pro

Відбір об'єктів в GPMC

Делегування управління GPO з використанням GPMC

Вкладка Summary в звіті RSOP