Софт

шаблоны Windows

Рейтинг: 4.6/5.0 (365 проголосовавших)

Категория: Windows

Описание

Административные шаблоны в Windows 7: основы

Административные шаблоны в Windows 7: основы

Административные шаблоны ” или “Административные политики ” в Windows 7 – это специально созданный файл, в котором находятся настройки реестра. Операционная система считывает эти настройки как при запуске, так и при входе пользователя.

Параметры “Административных шаблонов ” находятся в Редакторе локальной групповой политики. и присутствую как в узле “Конфигурация компьютера “, так и в узле “Конфигурации пользователя “.

Так что же такое политика и как ими пользоваться

Рассмотри такое известное свойства рабочего стола Windows 7. как “Обои “. Вы можете поменять обои в любое время, так же и сменить заставку, тему. Все это пользовательские свойства. Политики, устанавливаемые администратором имеют более высокий приоритет, чем свойства пользователя. В системе приоритеты политик и свойств распределяются следующим образом:

  • Политика и свойства не установлены – применяются параметры по умолчанию
  • Политика не установлена, применено пользовательское свойство – система использует свойство пользователя.
  • Политика установлена, свойство не используется – система будет использовать политику.
  • Политика установлена и установлено пользовательское свойство – система будет использовать политику, а свойство нет

Вывод прост. если применена политика, установлена администратором, то все попытки пользователя изменить свойства останутся без результата.

Еще одно большое преимущество “Административных шаблонов ” – это изменение параметров конфигурации без редактора реестра (regedit). Не надо искать в реестре раздел, имя ключа или параметра. Достаточно войти в “Редактор локальной групповой политики ” и изменить состояние нужной политики, тем более, что политика управляет окружением всех пользователей. Администратору достаточно изменить состояние политики, чтобы изменения были применены для всех пользователей.

Примечание. чтобы изменять параметры в “Редакторе локальной политики “, необходимо иметь права “Администратора “.

Запуск “Редактора локальной политики”

Чтобы открыть “Редактор локальной групповой политики ” нажмите кнопку Пуск – Выполнить и введите команду gpedit.msc. и нажмите клавишу ОК. В открывшемся “Редакторе локальной групповой политики ” видим “Административные шаблоны ” присутствуют как в “Конфигурации компьютера “, так и в “Конфигурации пользователя “. Соответственно параметры “Конфигурации компьютера ” находятся в разделе HKEY_LOCAL_MACHINE\Software\Policies. а параметры “Конфигурации пользователя ” в разделе HKEY_CURRENT_USER\Software\Policies .Так же параметры могут быть и в разделе SOFTWARE\Microsoft\Windows\CurrentVersion\Policies. Доступ к этим параметрам имеют только администраторы.

Практическое применение политик

Вернемся к свойству экрана и посмотрим, как можно отключить этот параметр. Запускаем Редактор локальной групповой политики. В левой панели переходим в раздел Конфигурация пользователя – Административные шаблоны – Панель управления – Окно свойств экрана. В правой панели два раза кликаем мышкой на “Отключить окно свойств экрана в панели управления “. Как видим политика имеет три состояния:

  • Не задано – применяется свойство пользователя.
  • Включить – в этом состоянии в реестре значение параметра меняется на 1 (или 0), что соответствует активному состоянию
  • Выключить – соответствующий параметр в реестре имеет значение 0

Если выбрать состояние Включить. то при попытке открыть окно свойств экрана, появится сообщение, что выполнение этого действия запрещено.

Как видим “Административные шаблоны” достаточно мощный инструмент в управление компьютером, тем более, что в Windows 7 эти политики были значительно обновлены и расширены. Применение тех или иных политик требует определенной осторожности, достаточно посмотреть список политик, который находится в Административных шаблонах.

В этой небольшой статье мы затронули лишь малую часть возможностей Административных шаблонов. Более подробно узнать о Редакторе локальной групповой политики можно из справки, которая вызывается из меню редактора. В этой справке есть большой раздел по настройке Internet Explorer.

  • Добавление шаблонов в GPO
  • Меняем время обновления групповых политик
  • Перенаправление папок удаленными пользователями в AD
  • Как запретить доступ к программам в Windows 7
  • шаблоны windows:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Административные шаблоны

    Административные шаблоны

    Одна из наиболее мощных опций, предназначенных для управления рабочими столами пользователей с помощью групповых политик, состоит в использовании административных шаблонов. Административные шаблоны применяются для конфигурирования параметров настройки системного реестра на компьютерах с системами Windows 2000 Server, Windows 2000 Professional, Windows XP Professional или Windows Server 2003. Административные шаблоны могут использоваться для конфигурирования большого количества разнообразных параметров настройки, которых существует более 700. Их так много, что этот раздел, возможно, не сможет охватить их все. В таблице 13-7 приводится краткий обзор только нескольких административных шаблонов, чтобы вы почувствовали силу групповых политик. Административные шаблоны имеются также и в Active Directory Windows 2000, но в Windows Server 2003 добавлено около 150 новых параметров настройки. В таблице 13-7 перечисляются также некоторые новые функции, которые доступны в Active Directory Windows Server 2003 клиентам с Windows XP Professional.
    Табл. 13-7. Образец административных шаблонов


    Место расположения административного шаблона

    Computer Conf iguration\ Administrative Templates\ System\Net Logon

    Обеспечивает разнообразные параметры настройки, управляющие местом расположения клиентского компьютера и кэшированием записей DNS контроллера домена.

    Computer Configuration\ Administrative Templates\ System\Remote Assistance

    Обеспечивает параметры настройки для функции Remote Assistance (Удаленная помощь), имеющейся в системе Windows ХР Professional.

    Computer Conf iguration\ Administrative Templates\ Windows Components\ Terminal Services

    Обеспечивает параметры настройки, которые могут использоваться для конфигурирования служб терминала Terminal Services на сервере и на клиентах.

    User Conf iguration\ Administrative Templates\ Network\Network Connections

    Обеспечивает конфигурирование параметров настройки, предназначенных для управления сетевыми связями, и ограничения доступа пользователей к сетевым подключениям.

    User Conf iguration\ Admin istrative Templates\Control Panel
    User Conf iguration\ Administrative Templates\ Windows Components\ Internet Explorer

    Обеспечивает конфигурацию частей панели управления и возможности пользователей по изменению параметров настройки через панель управления.
    Обеспечивает разнообразные параметры настройки, предназначенные для управления конфигурацией приложения Internet Explorer. Требуется Internet Explorer версии 5.01 или более поздней.

    Дополнительная информация. Полный список всех параметров настройки групповых политик смотрите по адресу http://www.microsoft.com/windowsxp/prdytechinfo/administration/policy /winxpgpset.xls.
    Одно из усовершенствований Active Directory Windows Server 2003 — это улучшенная справка по административным шаблонам. Теперь Active Directory поставляется с полным набором справочных файлов, детализирующих каждую подборку административных шаблонов. Чтобы получить доступ к расширенной справке по административным шаблонам, щелкните правой кнопкой мыши на папке Administrative Templates в редакторе объектов групповой политики и выберите Help (Справка). Затем выберите подходящую категорию административного шаблона. На рисунке 13-10 показаны детали, касающиеся категории System (Система).
    Системные политики в Windows NT обеспечивают функциональные возможности, подобные функциональности административных шаблонов в Active Directory Windows Server 2003. Оба инструмента позволяют делать изменения системного реестра в системе клиентов для модификации конфигурации рабочей станции. Однако административные шаблоны обеспечивают существенные преимущества по сравнению с системными политиками. Одно из самых больших преимуществ состоит в том, что они не оставляют неудаляемых следов в системном реестре, как это делают системные политики. Когда вы делаете изменение, используя системную политику, оно записывается в системный реестр, и для того чтобы изменить эту установку снова, надо делать это вручную или использовать системную политику. Если вы удалите системную политику, изменения, сделанные к системному реестру, не будут удалены.

    В Active Directory изменения системного реестра, сделанные административными шаблонами, записываются в специальные подключи в системном реестре. Любые изменения, сделанные в разделе User Configuration, записываются в ключе HKEY_CURRENT_USER и сохраняются в папке \Software\Policies или \Software\Microsoft\Windows\CurrentVersion\Policies. Изменения, сделанные в разделе Computer Configuration, сохраняются под теми же самыми подключами в ключе НКЕY_LOCAL_MACHINE. При начальной загрузке компьютера или при входе пользователей в систему загружаются обычные параметры настройки системного реестра, а затем эти ключи исследуются на наличие дополнительных параметров настройки. Если эти параметры будут найдены, то они загрузятся в системный реестр, записываясь поверх существующих записей, если такие записи имеются. Если административный шаблон удален, или компьютер (пользователь) будет перемещен в другой контейнер, где данный шаблон не применяется, информация в ключах Policies удаляется. Это означает, что административные шаблоны больше не применяются, но обычные параметры настройки системного реестра будут применяться.


    Рис. 13-10. В Центре справки и поддержки имеется детальное описание каждой опции административного шаблона

    Административные шаблоны хранятся в нескольких текстовых файлах .adm. По умолчанию эти файлы расположены в папке %systemroot %\Inf. В таблице 13-8 перечислены файлы административных шаблонов, которые по умолчанию устанавливаются с системой Windows Server 2003.
    Табл. 13-8. Заданные по умолчанию шаблоны, загружаемые в систему Windows Server 2003

    Параметры настройки конфигурации

    Коммерческие шаблоны виртуальных машин - Документация CROC Cloud Platform

    Коммерческие шаблоны виртуальных машин¶

    Всем коммерческим заказчикам при необходимости КРОК предоставляет доступ к шаблонам виртуальных машин с удобной автоматической настройкой сервисов.

    Шаблон Windows 2008 R2 SP1 AD¶

    Шаблон Windows 2008 R2 SP1 AD — это эталонный образ ОС Windows 2008 R2 SP1, автоматизированный инженерами КРОК, который позволяет:

    • активировать ОС запускаемого виртуального сервера на серверах активации Виртуального дата-центра;
    • установить необходимые драйверы и параметры MTU для сетевых интерфейсов;
    • сменить пароль администратора;
    • развернуть корневой контроллер домена для нового леса.

    Данные возможности активируются с помощью указания специальных тегов в поле “Пользовательские данные” на втором шаге создания виртуального сервера. Данное поле является единственным интерфейсом взаимодействия с виртуальным сервером при наличии сетевого соединения на этапе создания данного сервера.

    Внимание: Минимально возможный тип экземпляра для данного шаблона m1.small .

    Список поддерживаемых тегов:

    Во время подготовки виртуальный сервер пройдет процедуру автоматической активации.

    Во время подготовки виртуальный сервер автоматически станет корневым контроллером домена domain.ru для нового леса.

    При перезагрузке виртуальный сервер сменит пароль администратора. Новый пароль будет выведен на серийную консоль сервера.

    Внимание: При создании нового виртуального сервера не следует использовать тег <changepwd>, поскольку в дальнейшем это может осложнить работу с данным виртуальным сервером.

    Процесс создания виртуального сервера занимает определенное время, которое варьируется в зависимости от количества опций, включенных во время процедуры создания данного сервера. Для получения информации об актуальном состоянии процесса подготовки, получения пароля для сервера необходимо прочитать вывод консоли (пункт меню Получить вывод консоли ). Пример подобного вывода:

    Последнее сообщение означает, что виртуальный сервер полностью готов к использованию. После этого появляется возможность подключиться к серверу по протоколу RDP в качестве администратора, используя пароль, указанный в выводе консоли.

    Внимание: Необходимо проверить:

    • наличие внешнего IP-адреса, присвоенного данному серверу, который разрешает такое подключение;
    • правила брандмауэра для виртуальной сети, к которой подключен созданный сервер. Весь входящий трафик по умолчанию блокируется.
    Шаблон Windows 2008 R2 SP1 AD MSSQL 2008¶

    Шаблон Windows 2008 R2 SP1 AD MSSQL 2008 представляет собой эталонный образ ОС Windows 2008 R2 SP1, автоматизированный инженерами КРОК, который позволяет:

    • активировать ОС запускаемого виртуального сервера на серверах активации Виртуального дата-центра;
    • установить необходимые драйверы и параметры MTU для сетевых интерфейсов;
    • сменить пароль администратора;
    • развернуть корневой контроллер домена для нового леса;
    • установить СУБД MS SQL Server 2008 на этапе подготовки сервера.

    Данные возможности активируются с помощью указания специальных тегов в поле “Пользовательские данные” на втором шаге создания виртуального сервера. Данное поле является единственным интерфейсом взаимодействия с виртуальным сервером при наличии сетевого соединения на этапе создания данного сервера.

    Внимание: Минимально возможный тип экземпляра для данного шаблона m1.2small .

    Список поддерживаемых тегов:

    Шаблоны Windows в ZABBIX

    Шаблоны Windows в ZABBIX

    Шаблоны Windows в ZABBIX отличаются главным образом использованием специфическими для этой ОС счетчиками производительности. Счетчики представляют из себя встроенное средство анализа основных показателей операционной системы, некоторого программного обеспечения, а также аппаратных ресурсов. Подавляющее большинство серьезных систем мониторинга умеют использовать эти счетчики, вот и ZABBIX не исключение. В этой статье я постараюсь рассказать об основных «подводных камнях», встретившихся мне при работе с этим инструментом.

    Вводная статья по шаблонам мониторинга ZABBIX — Шаблоны ZABBIX .

    Если вам интересна тематика ZABBIX, рекомендую обратиться к основной статье — Система мониторинга ZABBIX. в ней вы найдете дополнительную информацию.

    Шаблоны Windows — нюансы

    Прочитав документацию ZABBIX касательно настройки счетчиков (кому интересно, глава «6 Счетчики производительности Windows «), я поразился насколько все просто и был удивлен столь богатой функциональностью, но не тут то было… Поначалу я пользовался встроенными в систему шаблонами, но в итоге на некоторых узлах сети счетчики у меня работали, а на некоторых данные просто не приходили не по одному ключу. В конечном счете я решил пройти процесс создания ключа данных с использованием счетчика Windoows с самого начала и до момента пока не увижу красивые графики с необходимой мне информацией.

    В руководстве все просто:

    Вы можете эффективно мониторить счетчики производительности Windows используя ключ perf_counter[].
    Например:
    perf_counter[«\Processor(0)\Interrupts/sec»]
    или
    perf_counter[«\Processor(0)\Interrupts/sec», 10]

    Но почему счетчики работают не на каждом узле сети? Ответ тоже прост:

    В зависимости от настроек местоположения, именования счетчиков производительности могут быть разными на разных серверах Windows. Это может ввести определенные проблемы при создании шаблонов для Windows, имеющих разные настройки местоположения.
    Каждый счетчик производительности может быть переведен в цифровую форму, которая является уникальной и независимой от языковых настроек, так что вы можете использовать числовое представление, а не строковое.
    Для того чтобы найти цифровые эквиваленты, выполните regedit, а затем найдите HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009.

    Напрашивается следующий вывод: буквенное представление счетчиков работает только на системе с языком, который аналогичен языку счетчиков в вашем шаблоне. В итоге я решил использовать только цифровое представление и перевести все необходимые мне данные на эту форму.

    С переводом все элементарно: просто ищем необходимый ключ реестра (см. выше), выгружаем данные в любой текстовый файл и ищем необходимые ключи:

    Здесь вы можете найти соответствующие числа для каждой части строки счетчика производительности, как для ‘\System\% Processor Time’:
    System -> 2
    % Processor Time -> 6
    Затем используйте эти числа для преобразования пути в числа:
    \2\6

    UPD: 2016.05.19: есть некоторые неприятные нюансы, подробнее см. в Изменения счетчиков производительности CPU

    Но тут меня ждал сюрприз: на некоторых серверах с использованием большого количества ролей я находил в этом файле несколько ключей данных! Какой из них выбрать, какой будет правильным? Я определил для себя следующие правила: поскольку счетчик состоит из двух параметров, надо найти сначала первый (ваш Кэп), запомнить примерное месторасположение в файле, а потом найти второй и если он будет выше первого по месторасположению, то игнорировать его; если же сразу после месторасположения первого мы найдем ниже него несколько одинаковых вторых ключей, то нам будет нужен ближайший к первому второй ключ. Подобная логика должна вам помочь выбрать правильный ключ данных. В противном случае получаемая информация будет некорректная или в ней не будет смысла, либо вы вообще не получите никаких данных. Нигде в интернете этого я почему-то не нашел, видимо авторы статей не слишком сильно углублялись в мониторинг счетчиков.

    Далее. Следующий неприятный момент в этой системе мониторинга — это типы данных элементов мониторинга. В принципе все просто, но вы должны помнить, что тип данных автоматически не определяется и вы должны определить его самостоятельно и, что самое главное, при неправильном выборе вы останетесь без данных, они просто не будут приниматься. В случае со счетчиками производительности вам будет нужен исключительно «Числовой (с плавающей точкой)» как показано на скриншоте ниже:

    Чтобы уяснить это простое правило, несколько лет назад у меня ушла куча времени и я дошел почти до отчаяния, ведь не знал ни основные проблемы при настройке, ни методики «траблшутинга». В таких случаях есть одно проверенное средство — zabbix_get, рекомендую использовать его всякий раз. когда вы находитесь в тупике.

    В принципе это все, что я и хотел сказать. В интернете куча статей на тему «zabbix счетчики производительности» и копировать я их не намерен, я лишь хочу поделиться основным опытом в решении ранее казалось бы тупиковых проблем. Мало кто ставит целью не изобретение велосипеда, а описание рассуждений и логики мышления при решении обыденных для них задач, но ведь информации в интернете сейчас масса, а вырабатыванию подхода не учит почти никто.

    Централизованное хранение административных шаблонов групповых политик

    Централизованное хранение административных шаблонов групповых политик

    Использование централизованного хранилища для ADMX файлов административных шаблонов позволит решить проблему раздутого SYSVOL (возникающую за счет необходимости копирования в каждую политику своих файлов ADMX /ADM шаблонов), способствует уменьшению трафика репликации SYSVOL между контроллерами домена (по той же причине) и упрощает обновление административных шаблонов в домене. Централизованное хранилище административных шаблонов (Group Policy Central Store) поддерживается начиная с ОС Vista/ Server 2008.

    По умолчанию центральное хранилище для административных шаблонов не используется, а при запуске редактора групповых политик в него загружаются локальные admx файлы с машины, на которой запущена консоль gpedit.msc. Чтобы задействовать централизованное хранилище административных шаблонов в групповых политиках Active Directory, необходимо скопировать файлы административных шаблонов (имеют расширение .admx и .adml) в каталог PolicyDefinitions. который нужно создать на контроллере домена в каталоге SYSVOL (полный UNC путь \\winitpro.ru\SYSVOL\winitpro.ru\policies ).

    В созданный на контроллере домена каталог PolicyDefinitions скопируйте все содержимое (с подпапками) каталога C:\Windows\PolicyDefinitions с клиента с ОС Windows 7. При копировании нужно не забыть скопировать языковые подкаталоги с ADML-файлами для всех языков, который будут использоваться администраторами групповых политик (в локализованной версии ru_RU и en_US)

    Затем скопируйте в созданную папку содержимое каталога C:\Windows\PolicyDefinitions с клиента Windows Server 2008 R2 (с перезаписью файлов). В такой же последовательности нужно выполнить эти операции для Windows 8 и Windows Server 2012.

    Для Windows 8.1 и Windows 2012 R2 процедура аналогичная. Чтобы упростить себе работу можно скачать готовый набор ADMX файлов для этих ОС тут. распаковать их (по умолчанию в папку C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions) и скопировать в SYSVOL все ADMX файлы (в том числе каталоги с необходимыми языками).

    В этот же каталог могут быть помещены все сторонние ADMX шаблоны, например, для настройки для MS Office, браузеров Firefox, Chrome. настроек Java, Adobe Reader и пр.

    Примечание. Для шаблонов ADM. которые все еще поддерживаются, использовать централизованное хранилище нельзя.

    Чтобы административных шаблоны стали доступны на всех контроллерах домена, необходимо дождаться пока служба репликации файлов скопирует изменения на остальные DC .

    Теперь, если открыть любую доменную GPO и развернуть ветку Administrative Templates, около нее будет указано, что определения политик получены из централизованного хранилища (Policy definitions (ADMX files) retrieved from the central store ). Локальные административные шаблоны при этом игнорируются.

    Очень важно! Для предотвращения конфликтов версий групповых политик и настроек административных шаблонов всегда используйте последнюю версию редактора групповых политик (gpedit.msc). Для этого администратору следует работать с объектами GPO с компьютера, на котором установлена последняя версия ОС Microsoft (многие администраторы предпочитают редактировать групповые политики только непосредственно с контроллеров домена), либо с машины, на которой установлен свежий пакет RSAT .

    После создания центрального хранилища групповых политик (Central Store) можно из всех существующий объектов GPO удалить ненужные более ADM файлы. Каждая политика содержит как минимум 5 ADM файлов, общим размером около 4 Мб. Т.е. для 20 политик эти файлы будут занимать уже около 80 Мб. Найти все ADM файлы в можно простым поиском по маске *.adm по каталогу \\winitpro.ru\SYSVOL\winitpro.ru\policies. Полностью безопасно можно удалить 5 следующих встроенных ADM шаблонов, которые будут заменены политиками из централизованного хранилища:

    Актуальность использования остальных найденных adm-шаблонов стоит проверить индивидуально. В случае необходимости такие шаблоны можно сконвертировать из формата ADM в ADMX.

    Совет. Чтобы не заблудится во многообразии настроек, предоставляемых файлами административных шаблонов, можно пользоваться специальными фильтрами. Подробности в статье Фильтры для admx шаблонов в групповых политиках .

    • Управляем настройками Java SE с помощью групповых политик
    • Настройка групповых политик WSUS
    • Кэширование групповых политик в Windows 8.1
    • Почему не стоит задавать пароли через Group Policy Preferences
    • Сброс локальных групповых политик в Windows

    Понравилась статья? Скажи спасибо и расскажи друзьям!

    Настройка Google Chrome групповыми политиками

    Настройка Internet Explorer с помощью групповых политик в Windows 2012

    MS Local Administrator Password Solution – управление паролями локальных администраторов в домене

    Почему перестали работать некоторые GPO после установки MS16-072

    Сброс локальных групповых политик в Windows

    Настройка групповых политик WSUS

    Resolution: 1346 x 733 54 queries. 1,701 sec 23.67 MB

    © 2010-2016 Windows для системных администраторов - Статьи, инструкции, обзоры о настройке Windows и других продуктов Microsoft,VMWare и прочих ИТ решениях. Карта сайта

    Копирование и размещение материалов сайта winitpro.ru возможно с указанием обязательной активной ссылки на cайт!

    MAXCACHE: 0.24MB/0.00083 sec

    Административные шаблоны групповой политики

    Административные шаблоны групповой политики Введение

    Большинство доступных в операционных системах Windows параметров групповой политики, которые зависят от системного реестра, также называемых реестро-зависящими политиками можно найти в расширении административных шаблонов. Административными шаблонами называются параметры групповой политики, основанные на данных системного реестра, которые отображаются в узлах «Административные шаблоны» узлов конфигурации компьютера и конфигурации пользователя. К таким параметрам относятся настройки панели управления, панели задач, сетевых параметров, параметров рабочего стола и многое другое. Сами по себе административные шаблоны представляют собой текстовые файлы, указывающие на изменение определенных параметров реестра и генерирующие пользовательский интерфейс для настройки политики административного шаблона в оснастке «Редактор управления групповыми политиками». которая и позволяет изменять значение параметров реестра на целевых компьютерах. В большинстве случаев, административные шаблоны предназначены для простого способа настройки параметров пользователей и компьютеров и применения таких политик для изменения соответствующих настроек пользователей и компьютеров организации. Административные шаблоны предоставляют возможности динамического управления администраторам и разработчиками всевозможными настройками своих приложений. Политики административных шаблонов в узле конфигурации компьютера, модифицируют значения параметров в разделах HKLM\Software\Policies и HKLM\Software\Microsoft\Windows\CurrentVersion\Policies, а административные шаблоны конфигурации пользователя - HKCU\Software\Policies и HKCU\Software\Microsoft\Windows\CurrentVersion\Policies.

    Распространяются административные шаблоны групповых политик на клиентские компьютеры таким образом. Сразу после загрузки операционной системы и выполнения пользователем входа в свою учетную запись, загружаются все параметры системного реестра, установленные по умолчанию, а после этого в разделах реестра выполняется анализ некоторых дополнительных параметров и, в том случае, если разделы содержат дополнительные параметры, указаные в политиках административных шаблонов, то существующие записи в реестре будут перезаписываться. Если политики административных шаблонов изменяли параметры реестра в разделах Policies, то в случае удаления административного шаблона или перемещения пользователя в другое подразделение организации, где данный шаблон на него не будет распространяться, информация о существующих параметрах политики будет удалена и после следующей загрузки или выполнения входа, будут использоваться параметры, указанные операционной системой по умолчанию.

    В операционных системах Windows, разработанных до Windows Vista и Windows Server 2008, для административных шаблонов использовались файлы, с расширением .adm. У таких административных шаблонов был ряд недостатков. Для создания ADM-файла, который будет использоваться при развертывании конфигурации в многоязыковой организации, вам придется создавать отдельные ADM-файлы для каждого языка. А чтобы отредактировать параметры реестра в таком шаблоне, вам нужно будет вносить изменения в каждый ADM-файл, что крайне неудобно. Ко второму недостатку можно отнести то, что файлы административных шаблонов .adm расположены как компонент объекта «Шаблон групповой политики» (Group Policy Template - GPT), которые представляют собой коллекцию файлов в каталоге SYSVOL каждого контроллера домена. И если такой шаблон используется сразу в нескольких объектах GPO, то в папке SYSVOL он будет сохранен несколько раз. Также, при редактировании объекта групповой политики, который содержит ADM-файл, редактор объектов групповой политики загружает этот шаблон из контейнера групповой политики (Group Policy Container - GPC), чтобы создать пользовательский интерфейс. Административные шаблоны ADM не поддерживали такие типы данных реестра, как мультистроковые значения и параметры QWORD.

    С выходом операционных систем Windows Vista и Windows Server 2008, административные шаблоны существенно изменились. Теперь административные шаблоны представляют собой пару XML-файлов. А именно: не связанный с языком файл (ADMX ), описывающий структуру категорий и параметров политики административных шаблонов, отображаемых в оснастке редактора управления групповыми политиками, а также набор зависящих от языка файлов (ADML ), которые предоставляют локализованные фрагменты, отображаемые в оснастке редактора управления групповыми политиками. Каждый ADML-файл представляет один язык, для которого требуется поддержка. Изменения параметров реестра административных шаблонов вносятся в один ADMX-файл.

    К дополнительным преимуществам ADMX/ADML файлов административных шаблонов можно отнести то, что если используются именно эти административные шаблоны, то объект групповой политики содержит только данные, необходимые клиентам обработки групповой политики, а при редактировании объектов GPO редактор управления групповой политикой извлекает файлы ADMX и ADML на локальной машине. В том случае, если компьютеры организации входят в состав домена Active Directory, административные шаблоны располагаются в таком центральном хранилище, как папка SYSVOL, откуда они и загружаются. На компьютерах, которые входят в состав рабочей группы, ADMX файлы располагаются в папке %SystemRoot%\PolicyDefinitions, а языковые файлы ADML хранятся в папке %SystemRoot%\PolicyDefinitions\[MUIculture], где последняя папка должна соответствовать краткой форме языка определенной страны, указанной в ISO-формате. Например, файлы для русского языка локализованы в папке \RU-RU. Список сокращений языков вы можете найти в следующей таблице:

    Код в формате ISO-639-1

    На контроллерах домена, административные шаблоны располагаются в центральном хранилище, которое также называется контейнером групповых политик и содержит атрибуты, используемые для распространения GPO в домене, подразделениях и сайтах, а именно в папке %SystemRoot%\sysvol\%domainname%\policies\PolicyDefinitions. В свою очередь, языковые файлы ADML хранятся в папке %SystemRoot%\sysvol\%domainname%\policies\PolicyDefinitions\[MUIculture], соответственно. Для того чтобы создать центральное хранилище, вам нужно на контроллере домена создать корневую папку внутри %SystemRoot%\sysvol\%domainname%\policies\PolicyDefinitions, после этого создать папки для каждого языка, который необходим для распространения групповых политик. На следующем шаге следует скопировать все ADMX и ADML файлы с административной рабочей машины в папку PolicyDefinitions. Это можно сделать или вручную, или используя следующую команду:

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

    На следующей иллюстрации вы можете увидеть папку PolicyDefinitions клиентского компьютера с операционной системой Windows 7:

    Рис. 1. Папка PolicyDefinitions на клиентском компьютере

    Также, в связи с тем, что теперь административные шаблоны поддерживают мультистроковые типы данных реестра, администраторы могут выполнять такие задачи, как:

    • вывод нескольких строк текста и сортировки записей параметров политики;
    • редактирование настроенных параметров и добавление новых позиций в строки;
    • редактирование существующего параметра;
    • выполнение выборки одной или нескольких записей;
    • удаление выбранных записей.

    Поддержка типа значений реестра QWORD позволяет использовать параметры политики административных шаблонов для 64-разрядных приложений. Помимо этого, стоит обратить ваше внимание и на тот факт, что в операционных системах Windows Server 2008 R2 и Windows 7 насчитывается около 3200 административных шаблонов, что почти в два раза больше, чем было в операционной системе Windows XP с административными шаблонами ADM (их тогда было около 1400).

    Как я уже упомянул в начале этой статьи, управлять административными шаблонами вы можете при помощи оснастки «Редактор управления групповой политикой». Во время редактирования объекта групповой политики, оснастка операционной системы Windows Server 2008/2008 R2 считывает все ADMX файлы, о расположении которых я говорил немного ранее, а затем отображает, согласно ADMX-файлам категории и параметры в узле Политики\Административные шаблоны в разделах «Конфигурация компьютера» и «Конфигурация пользователя». В параметрах политик административных шаблонов всегда можно найти три следующие опции: «Включить». «Отключить» и «Не задано». которые изменяют параметр реестра для внесения изменений, отвечающих контексту параметра политики, изменение, выполняющее обратное действие, а также опция, позволяющая оставить параметры реестра без изменений. Значение по умолчанию для каждого параметра политики «Не задано». Опять же, я уже упоминал, что начиная с операционных систем Windows Vista и Windows Server 2008, для редактора объектов групповой политики больше не используются ADM-файлы. Но, несмотря на это, если вам необходимо управлять настройками предыдущих операционных систем, вы можете добавить ADM-файлы.

    Далее в этой статье вы узнаете об архитектуре и синтаксисе административных шаблонов.

    Архитектура административных шаблонов

    Если разобраться, то архитектура административных шаблонов групповых политик не такая уж и сложная. Основными компонентами в распространении административных шаблонов являются системный администратор, контроллер домена и целевой клиентский компьютер. Небольшая схема, которая позволит вам иметь четкое представление архитектуры расширения административных шаблонов, отображена ниже:

    Рис. 2. Архитектура расширения административных шаблонов

    Первое, что стоит рассматривать в архитектуре расширения административных шаблонов групповых политик, это работу, выполняемую системным администратором, которая в данной схеме отображена в самом правом блоке. Здесь под компонентом «Администратор» подразумевается компьютер, на котором системный администратор вносит изменения в административные шаблоны, используя оснастку «Редактор управления групповыми политиками». В этой оснастке, в расширении серверной стороны администратор настраивает параметры политик, основанные на административных шаблонах. Оснастка располагается в библиотеке userenv.dll, которую можно найти в папке Windows\System32\. Настройки расширения административных шаблонов передаются в Active Directory на контроллер домена по протоколам LDAP и SMB. Протокол SMB (Server Message Block) считается основным методом, предназначенным для доступа к файлам и принтерам. Именно этот протокол используют административные шаблоны для доступа к папке SYSVOL, а также для резервного копирования и извлечения файлов удаленной файловой системы.

    В средней части данной схемы расположен контроллер домена, который является связующим звеном между изменениями, внесенными в административные шаблоны системным администратором и целевым компьютером, который будет извлекать настройки параметров объектов групповой политики. Всем известно, что контроллером домена называется отдельный сервер, который играет роль доменных служб Active Directory и имеет права на запись в базу данных Active Directory, запускать службу центра распространения ключей Kerberos, контролировать доступ к сетевым ресурсам и выполнять много других задач. В этом случае, как видно на схеме, контроллер домена содержит контейнер групповой политики. который хранит информацию о настройках объектов групповых политик в Active Directory, а также шаблон групповых политик. который хранит данные объекта GPO в папке Sysvol.

    Как и компьютер системного администратора, с контроллером домена по протоколам LDAP и SMB связывается целевой компьютер, на который и распространяются параметры политики измененного системным администратором объекта GPO. Прежде всего, на каждом целевом компьютере есть модуль групповых политик, вызывающий клиентское расширение административных шаблонов с полным перечнем всех объектов групповых политик, которые будут применяться на данную машину. Модель групповых политик вызывает расширение клиентской стороны административных шаблонов, реализованное в библиотеке userenv.dll, зарегистрированной в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions, которое отвечает за внесение изменений в системный реестр операционной системы, согласно параметрам политики административных шаблонов, которые настраиваются при помощи соответствующей оснастки. Для выполнения настроек, указанных в параметрах групповой политики, расширение административных шаблонов изменяет конкретные параметры системного реестра. Изменяемые параметры указываются непосредственно в ADMX файле. Изменения, внесенные в системный реестр при помощи модуля групповых политик, записываются в журналы событий, которые можно просмотреть при помощи оснастки «Просмотр событий». Во время обработки групповой политики, расширение клиентской стороны административных шаблонов записывает информацию об обработке данных в пространстве имен RSoP инструментария управления Windows.

    Помимо выполнения объектов групповых политик, на каждом компьютере можно индивидуально настроить административные шаблоны в локальных объектах групповой политики. Эти объекты будут локально располагаться в скрытой папке %systemroot%\System32\GroupPolicy и, как всем вам известно, в среде Active Directory считаться наименее приоритетными, так как все объекты GPO, распространяемые на подразделение Active Directory, в котором расположен сам пользователь или его компьютер имеют более высокий приоритет.

    Структура ADMX-файла (Файла, не зависящего от языка)

    В ADMX-файле указано количество параметров политики и их тип данных, а также расположения в категориях, находящихся в оснастке «Редактор управления групповыми политиками». ADMX-файл состоит из семи разделов, которые вы можете увидеть на следующей иллюстрации:

    Рис. 2. Структура ADMX-файла

    • XML-объявление. XML-объявлением является заголовок файла, который не рассматривается в качестве фрагмента ADMX-документа, но является его необходимой частью и помещается в начале всего файла для того, чтобы указать на то, что это XML-документ. Синтаксис следующий:

    где доступны два параметра:

    • Version. Представляет собой версию языка XML, используемую в документе;
    • Encoding. Предоставляет сведения о кодировке, используемые средствами синтаксического анализа XML-документов (в ADMX-файлах всегда должна быть задана кодировка UTF-8).
  • Элемент policyDefinitions. Является элементом документа для ADMX-файла, который определяет набор параметров политики системного реестра. Данный элемент содержит все остальные элементы для ADMX-файла. Синтаксис этого элемента следующий:

    где присутствуют следующие основные и дополнительные параметры:

    • Xmlns:xsd и xmlns:xsi. Это основные элементы, которые обозначают элементы и типы данных, используемые в схеме из пространства имен (параметр xmlns:xsd), а также обозначают пространства имен экземпляра XML-схемы, предоставленной в самом пространстве имен. Эти оба параметра всегда должны входить в состав ADMX-файла, так как, в противном случае, он может не пройти проверку на правильность формата XML-файла, они должны вводиться следующим образом:

    xmlns:xsd ="http://www.w3.org/2001/XMLSchema" и xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  • Revision. В этом параметре указывается версия ADMX-файла, которая в большинстве случаев предназначена для отслеживания внесенных изменений. Синтаксис этого параметра имеет следующий вид:

    где MajorVersion и MinorVersion являются номерами версии, и имеют формат XXXX, где X обозначает одиночную десятичную цифру, например revision="1.1" или revision="1234.5678". Параметр является обязательным.

  • schemaVersion. Данный параметр очень похож на revision, но его основное отличие в том, что при помощи него указывается версия схемы, используемая средствами работы с групповыми политиками для определения того, поддерживается ли ими формат конкретных ADMX-файлов. Синтаксис этой команды идентичен синтаксису revision. Обычно, данный параметр указывается следующим образом: schemaVersion="1.0". Параметр является обязательным.
  • policyNamespaces. Этот элемент определяет уникальное пространство имен для данного ADMX-файла. Более подробно данный элемент будет рассмотрен ниже.
  • supersededAdm. Данный элемент ссылается на имя ADM-файла, заменяемого ADMX-файлом. В этом случае, редактор управления групповой политикой не будет считывать любые ADM-файлы, обозначенные как заменяемые. Синтаксис данного элемента довольно простой:

    где в параметре fileName должно быть указано имя ADM-файла, заменяемого ADMX-файлом. Например, <supersededAdm fileName="oldadm.adm" />.

  • Resources. Текущий элемент определяет требования для ресурсов определенного языка и минимальную необходимую версию связанного ADML-файла. Этот элемент более подробно будет рассмотрен ниже.
  • supportedOn. Элемент, определяющий сопоставление ссылки на локализированные строки текста с операционными системами или приложениями, на которые влияют конкретные параметры политики. Более подробно будет рассмотрен ниже.
  • Categories. Данный элемент содержит список категорий, в которых параметр политики текущего ADMX-файла будет отображаться в оснастке редактора управления групповыми политиками. Более подробно будет рассмотрено ниже.
  • Policies. В этом элементе размещен список определений параметров политики. Также более подробно будет рассмотрен немного ниже.
  • Элемент policyNamespaces. Как было указано выше, данный элемент определяет уникальное пространство имен для текущего ADMX-файла. Помимо этого, данный элемент обеспечивает сопоставление с пространствами имен во внешних файлах, то есть, в том случае, если ADMX-файл ссылается на элементы category. определенные в другом ADMX-файле. Синтаксис у этого элемента следующий:
    • target. Текущий параметр определяет уникальное имя пространства имен политики в ADMX-файле;
    • using. Этот параметр указывает ссылку на существующую категорию из другого элемента policyNamespaces ;
  • Элемент resources. Элемент ADMX-файла позволяет задавать минимальный уровень версии ADML-файла, а также позволяет указывать базовый язык. Текущий элемент включает в себя два вложенных атрибута, синтаксис которых можно увидеть ниже:
    • minRequiredRevision. Атрибут позволяет указать минимальный уровень версии ADML-файла;
    • fallbackCulture. При помощи текущего атрибута вы можете указать язык, который будет использоваться по умолчанию, если ни в одном расположении не будет найден соответствующий ADML-файл. Если вы не укажите текущий атрибут, то по умолчанию будет использоваться английский язык;
  • Элемент supportedOn. Данный элемент является опциональным элементом в структуре ADMX-файла, то есть включать его не обязательно. При помощи элемента supportedOn вы можете обеспечить сопоставление продуктов с их определениями, то есть, вы можете указать в каких версиях операционных систем или программных продуктов запрещается помечать параметры групповой политики как устаревшие в случае, если параметр больше не применяется к текущей версии. С этим элементом не связан ни один атрибут, но вы можете использовать дочерний элемент definitions, который является элементом, определяющим набор параметров политики реестра. Синтаксис данного элемента следующий:

    В следующей таблице указаны значения данного атрибута, определяющие операционные системы, на которые будет распространяться созданный вами параметр административного шаблона:

    Не ниже Windows 7

  • Элемент categories. Используя этот элемент, вы можете указать таблицу элементов category, позволяющих задавать имя уникальной категории, которая будет отображаться в окне редактора объектов групповой политики. Этот элемент целесообразно использовать только в том случае, если элементы category указываются в ADML-файле. Элемент categories опасен тем, что из-за него вы случайно можете указать циклические ссылки, ссылаясь на элементы category других ADMX-файлов. Элемент category включает в себя следующий синтаксис:
  • Элемент policies. Текущий элемент позволяет вам указать таблицу элементов policy, представляющих собой одиночный параметр групповой политики. Синтаксис этого элемента следующий:
  • Структура ADML-файла (файла языковых ресурсов)

    Как я уже говорил во введении этой статьи, в файлах ADML указываются языковые ресурсы, привязывающиеся к определенному языку, без которых ADMX-файл не будет корректно работать. Основная задача этого файла – обеспечение корректного отображения описания параметра политики, который можно будет найти в оснастке редактора управления групповыми политиками. Структура этого файла намного проще структуры ADMX-файла и ее вы можете увидеть на следующей иллюстрации:

    Рис. 3. Структура ADML-файла

    • XML-объявление. Так же как и в случае с файлом ADMX, в этом файле XML-объявлением является заголовок файла, который не рассматривается в качестве фрагмента ADML-документа, но является его необходимой составляющей и помещается в начале всего файла для того, чтобы указать на то, что это XML-документ. О данном элементе вы можете прочитать в предыдущем разделе данной статьи;
    • Элемент PolicyDefinitionResources. Этот элемент определяет сведения всех локализованных ресурсов с одним языком или набором региональных параметров в файле для каждого поддерживаемого языка или набора региональных параметров и содержит объявление пространства имен по умолчанию для всех элементов ADML-файла. Этот элемент включает в себя пять атрибутов: xmlns:xsd, xmlns:xsi, revision, schemaVersion и xmlns. Обо всех этих элементах уже говорилось ранее. Помимо этого, данный элемент содержит до четырех возможных дочерних элементов, которые вкратце описаны далее:
      • Элемент displayName. в котором указывается локализованное и понятное имя ADML-файла;
      • Элемент description. позволяющий указать описание параметров политики, которые включены в соответствующий файл;
      • Элемент annotation. в котором указывается локализованный комментарий;
      • Элемент resources. считающийся родительским элементом для элементов stringTable и presentationTable, о которых речь пойдет немного ниже.

      Синтаксис данного элемента следующий:


    • Элемент stringTable. Используя этот элемент ADML-файла, вы можете указать сам заголовок параметра групповой политики, текст с описанием, текст со ссылкой на поддержку, названия категорий, а также подписи для параметров. Стоит обратить внимание на то, что элемент stringTable нельзя объявлять более одного раза. Данный элемент включает в себя вложенные элементы string, позволяющие определить все указанные выше данные. Синтаксис данного элемента следующий:
    • Элемент presentationTable. Последний элемент представляет собой целую структуру дочерних элементов управления параметрами отдельных параметров групповой политики, включая в себя всевозможные флажки, переключатели, подписи, подсказки и прочее. Дочерними элементами являются элементы presentation. которые представляют собой отображаемые сведения параметров для параметров политики. Синтаксис для этого элемента имеет следующий вид:
    Создание своего административного шаблона

    На первый взгляд все эти XML файлы со множеством родительских и дочерних элементов могут показаться очень сложными при создании своего собственного административного шаблона. Чтобы соответствующий материал вам было проще усвоить, в этом разделе я покажу, как можно создать свои ADMX и ADML файлы, предназначенные для управления двумя параметрами антивирусного программного обеспечения Microsoft Security Essentials. Сразу хотелось бы обратить ваше внимание на то, что данный антивирусный продукт можно использовать в SOHO компаниях, то есть там, где развертывается не более 10 компьютеров. Мы рассмотрим только три параметра, которые позволяют вам указывать тип проверки, а также ее периодичность. Для начала, перед созданием ADMX-файла, вам нужно узнать какие именно параметры в каких разделах системного реестра должны изменяться. При помощи программы ProcessMonitor от Марка Руссиновича или программы RegMon можно быстро отследить изменения в реестре и узнать, что при изменении опций в самом Microsoft Security Essentials, меняются следующие параметра реестра:

    1. Для того чтобы выполнять запланированную проверку, только когда компьютер включен, но не используется, в системный реестр вносятся следующие изменения:
    2. Для того чтобы ограничить использование ЦПУ при проверке, в реестре изменяется значение следующего параметра:

    После того как вы узнали нужные параметры и значения реестра, можно приступать к созданию ADMX-файла.

    Первым делом в ADMX-файле вам нужно указать XML-объявление и элемент policyDefinitions. Практически во всех случаях эти строки создаваемого вами XML-файла одинаковые. У вас они должны получиться примерно следующими:

    После этого необходимо заполнить элемент policyNamespaces, где нужно будет указать уникальное имя пространства имен, а также ссылку на существующую категорию из другого элемента policyNamespaces. Так как создается ADMX-файл для Microsoft Security Essentials, укажем префикс mse и назовем пространство имен Microsoft.Policies.MicrosoftSecurityEssentials, а также элемент resources, где зададим минимальный уровень версии ADML-файла 1.0, как показано ниже:

    Так как элемент supportedOn является опциональным элементом, в нашем случае мы опустим использование этого элемента. Поскольку для нашей группы административных шаблонов нужно указать группу, в которой будут расположены административные шаблоны антивирусного программного обеспечения, нужно добавить элемент categories, как показано в следующем листинге:

    Вот мы и дошли до самого интересного момента, когда нужно добавлять разделы и параметры системного реестра, которые будут использоваться как основа параметров групповых политик. На этом шаге стоит обратить внимание на то что, так как параметры реестра для Microsoft Security Essentials расположены только в разделе HKLM, в классе политики необходимо указать Machine. Эти параметры можно увидеть в следующем листинге, причем, что самое интересное, в данном листинге вы можете найти как переключатели, так и раскрывающиеся меню:

    После того как ADMX-файл будет окончательно завершен, вам еще предстоит написать сам ADML-файл. Как вы уже знаете, структура этого файла намного проще. В этом файле следует оставить XML-объявление и элемент policyDefinitions такими же, как вы указывали в самом ADMX-файле. Обязательно обратить внимание на то, что весь текст в этом файле должен быть в кодировке UTF-8. В элементах displayName и description укажем, что данный административный шаблон создается для антивирусного программного обеспечения Microsoft Security Essentials. В элементе stringTable следует указать идентификаторы и описания для каждого уникального объекта, который был создан в ADMX-файле.

    Наверное, самой сложной частью ADML-файла считается определение структуры элементов управления отдельных параметров групповой политики в элементе presentationTable. Так как в нашем случае только в одном параметре политики есть раскрывающиеся списки, необходимо указать дочерние элементы dropdownList с идентификаторами и описанием данных элементов управления. В итоге должен получиться следующий XML-файл:

    После того как вы поместите созданные файлы в папку Policy Definitions на локальном компьютере или в папку SYSVOL на контроллере домена, данные политики будут отображаться в оснастке редактора управления групповыми политиками.

    Заключение

    Из этой статье вы узнали о параметрах групповой политики, основанных на данных системного реестра, которые называются административными шаблонами. Вкратце была рассмотрена история развития административных шаблонов, структура ADMX-файла – файла, не зависящего от языка, структура ADML-файла – файла языковых ресурсов. Также, в данной статье был написан административный шаблон для управления антивирусным программным обеспечением – Microsoft Security Essentials.