Group policy – настройка несистемных сервисов


В некоторых случая установка ПО сопровождается установкой дополнительного сервиса, который может оказаться совершенно не нужным. Такой сервис не только потребляет ресурсы, но может активно мешать пользователям. Например, установка Acrobat Reader тащит за собой сервис AdobeARMService. Если вы устанавливаете и обновляете ПО централизованно, а пользователи лишены административных прав, то постоянные напоминания об установке обновлений, которые порождает этот процесс, будут только раздражать пользователей.

Читать далее

Реклама

О пользе перезагрузки терминальных серверов


На днях Operation Manager 2012 R2 возвестил о том, что на диске одного скромного терминального сервера закончилось место. Оказалось, что место занимают профили пользователей, которых накопилось огромное множество, несмотря на присутствие политики «Delete user profiles older than a specified number of days on system restart» (Computer Configuration/Administrative Templates/System/User Profiles).

Особенность этой политики в том, что удаление старых профилей происходит только после перезагрузки системы. Проверили Uptime сервера – более 240 дней! Перезагрузили сервер, и пошёл процесс удаления давно неиспользуемых профилей. Через несколько минут на диске освободилось несколько гигабайт свободного места.

Как нацелить политику на виртуальные машины?


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

Обычно учётные записи виртуальных машин размещают от отдельной ветке OU и назначают им специальные политики. Но это не всегда удобно, т.к. может привести к дублированию политик, усложнению структуры AD, усложнению делегирования прав. Возникает ситуация аналогичная дуальности архитектуры: вы же не разделяете скорее всего 32-х и 64-х битные компьютеры по разным веткам AD, почему это надо делать для виртуальных и физических машин?

Собственно задача в том, чтобы выполнить групповую политику исключительно на виртуальных машинах в случае, когда их учётные записи лежат в тех же контейнерах AD, что и учётные записи физических машин.

С теоретической точки зрения невозможно определить из программы, что она выполняется в виртуальной среде. На практике не всё так плохо, т.к. производители систем виртуализации (гипервизоров) эмулируют вполне определенные аппаратные устройства и присваивают им «хорошо известные» значения некоторых свойств, которые доступны виртуальной машине.

Проверить эти значения можно с помощью WMI запросов:

Get-WmiObject -Query «select * from Win32_BIOS» -ComputerName testcomp

Например для Microsoft Virtual Server 2005:

SMBIOSBIOSVersion : 080002

Manufacturer : American Megatrends Inc.

Name : BIOS Date: 02/22/06 20:54:49 Ver: 08.00.02

SerialNumber : 0197-5009-1700-0693-8099-8415-07

Version : A M I — 2000622

Ключевое значение тут «A M I».

Для VMware ESX:

SMBIOSBIOSVersion : 6.00

Manufacturer : Phoenix Technologies LTD

Name : PhoenixBIOS 4.0 Release 6.0

SerialNumber : VMware-42 32 41 66 15 d5 15 20-92 ea b4 7a 95 7e f2 17

Version : INTEL — 6040000

Ключевое значение тут «VMware».

Более полный список условий можно найти в опубликованном скрипте http://gallery.technet.microsoft.com/scriptcenter/Determine-if-a-computer-is-cdd20473

Любое условие из скрипта можно преобразовать в фильтр WMI.

Пример фильтра для VMware:

Get-WmiObject -Query «select * from Win32_BIOS where SerialNumber like ‘%VMware%'» -ComputerName testcomp

Условие может быть сложным (с использованием «or» и «and»). Но на практике вам вряд ли нужны все условия сразу. Более подробно о построении запросов можно почитать в документации WQL Operators в библиотеке MSDN.

Теперь остаётся только прописать фильтр для целой политики (Create WMI Filters for the GPO) или включить его в Group Policy Preferences (WMI Query Targeting).

Простейший путь оптимизации загрузки и входа пользователя


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

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

Можно ли отказаться от этого традиционного для многих пути и в то же время не оказывать негативное влияние на пользователей? Вполне!

Первое, что надо сделать, это мигрировать логон скрипты на Group Policy Preferences. GPP специально существует для того, чтобы заменить большую часть логон скриптов. Они имеют очень гибкую систему фильтров (Targeting), что позволяет внедрять GPP и заменять существующие логон скрипты постепенно и не спеша. Трудоёмкость процесса низкая – производительность системных администраторов возрастает значительно.

Что делать со скриптами, которые не могут быть заменены средствами GPP? Есть простой путь: запускать подобные скрипты через Планировщик заданий, а сами задания создавать с помощью GPP! На первый взгляд может показаться, что это создаёт больший беспорядок, но фактически, как только эта система заработает, вы убедитесь, что порядка становится больше, обслуживание проще, а поиск неисправностей легче.

Этим же способом можно устанавливать ПО (и удалять его), отказываясь от установки ПО с помощью групповых политик.

В конце этого процесса миграции на GPP остаётся отключить политику ожидания готовности сети и – получить благодарности от пользователей, которые удивятся, насколько быстрее стал грузиться их компьютер и профиль!