• Управляем клиентами KMS с помощью GPP

    imageПри автоматической публикации серверов Key Management Service (KMS) в DNS в территориально распределённых инфраструктурах может возникнуть ситуация, когда клиенты обращаются к KMS-серверам на удалённых площадках, в то время как есть более близкий сервер. Поэтому может возникнуть необходимость направить определённые группы клиентов на конкретные KMS-сервера и сделать это можно с помощью ключей реестра…

    Читать далее...

  • Публикация приложения RemoteApp на в ферме серверов RDS (Windows Server 2012) на примере КонсультантПлюс

    imageВ Windows Server 2012 консоль Server Manager работает таким образом, что при попытке публикации приложения RemoteApp, для которого выбран исполняемый файл расположенный на общем сетевом ресурсе, возникает грозное уведомление о том, что мы можем выбирать исполняемые файлы расположенные только на каком-то конкретном сервере RD Session Host (RDSH)…

    image

    Читать далее...

  • Remote Desktop Services - Настраиваем пользовательский интерфейс на серверах RD Session Host

    imageСерверы сеансов Remote Desktop Services (RDS) - это многопользовательские среды, для которых, как правило, требуется максимально жёсткая настройка пользовательского окружения. Говоря простым языком, – чем у пользователей меньше отвлекающих "буцок", не имеющих прямого отношения к выполняемым ими задачам, – тем лучше и для администратора, и для них самих в конечном итоге. Здесь мы рассмотрим пример настройки некоторых элементов пользовательского интерфейса по следующим позициям:
    - Отключаем отображение Favorites, Libraries и Network
    - Скрываем излишние папки в профиле пользователя
    - Отключаем мастер добавления сетевых расположений
    - Скрываем локальные диски сервера
    - Сворачиваем ленту при запуске Windows Explorer
    - Включаем отображение расширений файлов
    - Ограничиваем набор апплетов в Панели управления
    - Настраиваем панель задач (TaskBar)
    - Заменяем картинку пользователя по умолчанию
    - Настраиваем стартовый экран Windows
    - Создаём групповую политику переопределений для администраторов Читать далее...

  • Развёртывание настроек безопасности клиента SAP

    imageПереводя пользовательские приложения на сервера RDS Windows Server 2012 решили использовать последнюю версию офисных приложений - Microsoft Office 2013, но тут же столкнулись с проблемой: клиентская часть SAP версии 7200.3.13.1075, конкретно Business Explorer не смог работать с Office 2013. Так как у нас использовалась не самая последняя версия клиента SAP, было решено изучить вопрос его обновления.

    Читать далее...

  • Решаем проблему запуска SAP Business Explorer Analyzer из Excel 2010 в ферме серверов RDS

    У пользователей работающих в ферме серверов RDS возникла необходимость использовать надстройку SAP Business Explorer Analyzer (BEx Analyzer) для Microsoft Office Excel 2010.

    image

    Читать далее...

  • GPP: Настраиваем ассоциацию на открытие графических типов файлов на терминальных серверах RDS

    На терминальных серверах под управлением Windows Server 2008 R2 по умолчанию отсутствует программа для просмотра графических файлов (именно для просмотра а не редактирования, типа Paint). Если используется Office 2010, то можно в качестве просмотрщика основных типов графических файлов использовать входящую в его состав программу “Диспетчер рисунков Microsoft Office”.

    Читать далее...

  • Настраиваем блокировку компьютера при простое через screen saver с помощью Group Policy Preferences

    imageВ большинстве организаций, применяющих в своей ИТ инфраструктуре локальные стандарты и регламенты информационной безопасности, уделяется отдельное внимание вопросу блокировки консолей рабочих станций пользователей при наступлении некоторого периода бездействия. Например, в качестве обязательного требования для большинства категорий пользователей может выставляться блокировка рабочего стола компьютера при отсутствии пользовательской активности более 15 минут. В управляемой среде Active Directory в доменных групповых политиках администраторам предоставляется ряд параметров, позволяющих централизованно настроить пользовательскую среду для форсированного применения механизма блокировки рабочего стола посредствам срабатывания программы - хранителя экрана (screen saver), или как её ещё называют, экранной заставки. Эти параметры расположены в разделе групповой политики:

    User Configuration > Policies > Administrative Templates > Control Panel > Personalization

    Вот типичный возможный пример таких настроек:

    Password protect the screen saver  = Enable
    Screen saver timeout = Enable (900 Seconds)
    Force specific screen saver = scrnsave.scr

    image

    В данном примере включено обязательный запуск конкретного файла экранной заставки (scrnsave.scr) при простое более 15 минут с требованием ввода пароля пользователя при попытке последующего доступа к рабочему столу.

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

    image

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

    Для обеспечения настроек экранной заставки для сменного персонала и для всех остальных пользователей мы можем создать две отдельные групповые политики – одна с обязательным срабатыванием экранной заставки, другая - без него. Но с использованием механизмов настройки реестра с помощью Group Policy Preferences (GPP) мы сможем гибко объединить эти настройки внутри одной групповой политики.

    Для того, чтобы задействовать механизмы GPP для данной задачи, мы воспользуемся параметрами реестра, которые изменяются стандартными Административными шаблонами, указанными нами ранее. Сопоставим указанные ранее параметры GPO с ключами реестра которые они изменяют в клиентской системе:

    Политика: Password protect the screen saver
    Куст реестра: HKEY_CURRENT_USER
    Ветка: SoftwarePoliciesMicrosoftWindowsControl PanelDesktop
    Ключ: ScreenSaverIsSecure REG_SZ = 1

    Политика: Screen saver timeout
    Куст реестра: HKEY_CURRENT_USER
    Ветка: SoftwarePoliciesMicrosoftWindowsControl PanelDesktop
    Ключ: ScreenSaveTimeout REG_SZ = 900

    Значение "900" означает количество секунд от момента начала бездействия до срабатывания экранной заставки (15 минут простоя)

    Политика: Force specific screen saver
    Куст реестра: HKEY_CURRENT_USER
    Ветка: SoftwarePoliciesMicrosoftWindowsControl PanelDesktop
    Ключ: ScreenSaveActive REG_SZ = 1
    Ключ: SCRNSAVE.EXE REG_SZ = scrnsave.scr

    Эксперименты с применением этой политики показали, что ключ реестра ScreenSaveActive добавляется лишь на системах Windows XP, а после отключения этой политики, он из реестра корректно не удаляется. Опытным путём удалось выяснить, что отсутствие этого ключа не вносит никаких изменений, поэтому будем рассматривать его как рудиментарный элемент и исключим из наших настроек GPP.

    Итак, в групповой политике, действующей на наших пользователей, переведём три перечисленных параметра в состояние Not configured (если они ранее были настроены), а в разделе политики User Configuration > Preferences > Windows Settings > Registry создадим логическую группу, в которой будут храниться наши настройки, например ScreenSaver.

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

    image

    В группе Enabled создадим три правила для создания/обновления ранее перечисленных ключей пользовательского реестра. Нацеливание (Item-level targeting) для этой группы использовать не будем, то есть эти параметры реестра будут применяться для всех пользователей.

    image

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

    image

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

    image

  • Ограничение доступа к внешним накопителям CD, FD, USB с помощью Group Policy Preferences

    Если по каким-то причинам возникает необходимость на некоторых компьютерах c OC Windows полностью заблокировать доступ пользователям к возможности использования съёмных носителей, – можно воспользоваться настройками доступными в стандартных Административных шаблонах групповых политик в разделе Computer Configuration > Administrative Templates > System > Removable Storage Access

    Для того чтобы применить эти параметры к какой-то отдельной группе компьютеров -можно создать отдельную групповую политику с такими настроенными параметрами и прилинковать её например к контейнеру (OU) в домене или изменить разрешения безопасности для этой политики так чтобы применяться она могла лишь к конкретной доменной группе безопасности, в которую включены соответствующие компьютеры.

    Читать далее...

  • WSUS - Управление клиентами с помощью Group Policy Preferences

    imageЕсли вы имеете разветвлённую инфраструктуру WSUS с центральным сервером и некоторым количеством подчинённых серверов то, возможно, вы используете для централизации управления клиентами WSUS групповые политики. С появлением механизмов Group Policy Preferences (GPP) у нас появилась возможность вместо множества групповых политик настраивающих разные наборы клиентских компьютеров на ближайшие к ним WSUS сервера, - использовать одну групповую политику с рядом соответствующих настроек в зависимости от тех или иных условий. Рассмотрим пример создания такой единой групповой политики с следующими исходными данными:

    • Имеется головной сервер WSUS и несколько подчинённых ему серверов;
    • Все сервера расположены в разных физических локациях и обслуживают свой набор клиентских компьютеров, находящихся в разных IP диапазонах;
    • Один сервер WSUS может обслуживать несколько разных локаций, по каждой из которых необходимо иметь раздельную статусную информацию;
    • Есть необходимость разделения всех клиентов на всех WSUS серверах на логические категории для возможности разграничения процедур одобрения тех или иных наборов обновлений.

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

    • KOM-All-Test-New-Updates - для тестирования новых обновлений
    • KOM-All-Not-Install-IE9 – для настройки запрета установки IE9

    image

    Группы создаются на головном сервере и реплицируются с механизмом синхронизации на все подчинённые сервера.

    Создание групп WSUS позволяет не только более гибко управлять одобрением/отклонением тех или иных обновлений но и получать сводную статусную информацию о результатах полноты установки обновлений в консоли WSUS

    Итак, перейдём к настройке групповой политики. Для этого откроем консоль управления групповыми политиками (gpmc.msc) и создадим новый объект групповой политики, в котором сразу можно выключить настройки конфигурации пользователя, так как мы будем использовать только раздел конфигурации компьютера - Computer Configuration

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

    image

    Все остальные настройки, которые могут меняться в зависимости от условий, которые выдвигаются клиентами WSUS, мы вносим в GPP в раздел настроек Preferences > Windows Settings > Registry

    Создадим в корне дерева этих настроек 2 параметра - 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:

    Куст реестра: HKEY_LOCAL_MACHINE

    Ветки реестра
    для x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
    для x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate

    Ключ реестра: TargetGroupEnabled REG_DWORD = 1

    Ветки реестра
    x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU
    x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdateAU

    Ключ реестра: UseWUServer REG_DWORD = 1

    image

    Эти два параметра вынесены на верхний уровень настроек специально для наглядности и будут применяться ко всем компьютерам на которые будет действовать данная политика

    Параметры сделаны отдельно для 32-битных (x86) и 64-битных (x64) систем, так как в зависимости от битности ОС используются разные ветки реестра. Для 64-битных клиентов WSUS во всех идущих далее по описанию ключах реестра добавляется дополнительное условие нацеливания Item-level targeting

    image

    Это условие построено на проверке наличия ветки реестра SOFTWAREWow6432Node в кусте HKEY_LOCAL_MACHINE, то есть, если эта ветка существует, значит обработка политики происходит на 64-битном клиенте

    image

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

    image

    Теперь заглянем внутрь любой из таких серверных групп. Внутри каждой группы сделаны настройки на конкретный сервер для того, чтобы клиенты знали куда им ходить за обновлениями и куда отправлять статусную информацию. Это 2 параметра - 4 настройки ключей реестра (2 ключа для 32-битных клиентов и 2 ключа для 64-битных клиентов) со следующими настройками:

    Куст реестра: HKEY_LOCAL_MACHINE

    Ветки реестра
    x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
    x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate

    Ключ реестра: WUServer REG_SZ = https://KOM-SRV-WSUS:8531
    Ключ реестра: WUStatusServer REG_SZ = https://KOM-SRV-WSUS:8531

    image

    Внутри каждой группы уровня настроек серверов создаём подгруппы с помощью которых будут настроены параметры реестра для работы механизма WSUS client-side targeting, то есть для автоматического распределения клиентов по группам WSUS, о которых мы говорили в самом начале. В нашем случае нацеливание GPP выполнено опять-таки на IP адрес клиента, при этом надо понимать что IP диапазон который мы указываем в подгруппе должен входить в логику диапазонов группы верхнего уровня.

    image

    Внутри подгруппы создаём параметры для WSUS client-side targeting:

    Куст реестра: HKEY_LOCAL_MACHINE

    Ветки реестра
    x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
    x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate

    Ключ реестра: TargetGroup REG_SZ = KOM-AD01
    Ключ реестра: TargetGroup REG_SZ = KOM-AD01;KOM-All-Test-New-Updates
    Ключ реестра: TargetGroup REG_SZ = KOM-AD01;KOM-All-Not-Install-IE9

    Если клиент должен входить в несколько групп, то их названия перечисляются в значении через точку с запятой. При этом если группы WSUS имеют вложенную структуру, указывается конечное имя группы (без информации об иерархии). Эту особенность необходимо учитывать в процессе планирования и создания структуры групп WSUS.
    Важно так же помнить, что порядок применения GPP (Order) тоже имеет своё определяющее значение.
    image

    На этом уровне в нашем примере мы комбинируем разные варианты значения одного и того же параметра реестра в зависимости от разных условий. Например, за дополнительное условие взято членство учетной записи компьютера в доменной группе безопасности. То есть в данном случае значение ключа TargetGroup будет установлено в “KOM-AD01;KOM-All-Test-New-Updates” при условии, если компьютер имеет 64-битную ОС и входит в соответствующую группу тестовых компьютеров в домене.  

    image

    Обратите внимание на, то что при указании доменной группы безопасности лучше не вводить её название прямо в поле Group, а пользоваться кнопкой обзора, чтобы Tardeting Editor корректно определил SID этой группы.

    На этом настройку GPP можно считать законченной и для того, чтобы параметры реестра для механизма авто-назначения в группы WSUS применившись на клиентских компьютерах начали работать, – необходимо переключить сервер WSUS в режим управления групповыми политиками. Для этого в консоли WSUS - Параметры > Компьютеры (Options > Computers) включим соответствующую настройку:

    image

    Обратите внимание, на то что эту настройку нужно изменить на всех серверах WSUS.

    Результат в консоли WSUS мы сможем увидеть далеко не сразу, так как для вступления новых параметров реестра на клиентах в силу требуется как минимум перезапуск клиентской службы Windows Update (wuauserv), что например, на рабочих станциях достигается элементарным циклом выключения/включения компьютера пользователями. Возможно также на некоторых “непослушных” клиентах потребуется сбросить авторизацию на сервере WSUS

    wuauclt /resetauthorization /detectnow

    Не забывайте так же про то, что для того чтобы созданная нами групповая политика успешно работала, – клиенты должны уметь работать с GPP, особенно это касается уже устаревших на сегодня систем типа Windows XP.

    Update 21.10.2001

    Может возникнуть ситуация, когда потребуется отдельная настройка параметра групповой политики Allow non-administrators to receive update notifications из состава Административных шаблонов (в разделе Computer Configuration > Administrative Templates > Windows Components > Windows Update). Этот параметр обозначает возможность видеть непривилегированным пользователям оповещения клиента WSUS о доступности новых обновлений и инициировать процесс установки обновлений. Для рабочих станций это нормальная ситуация, а вот на терминальных серверах это может стать настоящей головной болью и поэтому для серверов этот параметр лучше выключать. То есть можно в Административных шаблонах этот параметр оставить ненастроенным, а настраивать его ключом реестра через вышеописанный механизм GPP:

    Куст реестра: HKEY_LOCAL_MACHINE

    Ветки реестра
    x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
    x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate

    Ключ реестра: ElevateNonAdmins REG_DWORD 1 или 0

    Возможные значения ключа:

    • 1 – Включено. Пользователи получают оповещения клиента WSUS о доступности свежих обновлений и могут инициировать процесс установки обновлений
    • 0 – Выключено. Пользователи не видят оповещений и только администраторы могут управлять процессом установки обновлений.

    Таким образом можно создать соответствующие правила обработки GPP с нацеливанием например на версию ОС (серверная/не серверная) ну или например по имени компьютера если в вашей организации действуют какие-то жёсткие стандарты именования компьютеров. Тут уж всё зависит от вашей фантазии.

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


    В качестве эпилога, предвидя реплики типа “Всё гибче делается в SCCM”, отмечу сразу то, что эта заметка рассчитана на тех, кто по каким-то причинам не может использовать подобные решения. Как видите, все настройки сделаны в рамках стандартных функциональных возможностей Windows Server.

    Источники информации:

  • Windows XP SP3 - настраиваем путь к дистрибутиву через GPP

    В некоторых случаях может возникнуть необходимость пакетного добавления каких-либо системных компонент Windows XP на большом количестве клиентских компьютеров. В ходе этого процесса Windows XP может потребовать доступ к дистрибутивному носителю ОС.

    Воспользуемся механизмом Group Policy Preferences для централизованной раздачи таким клиентам сведений о месторасположении дистрибутивных файлов в сети. Информация о пути, использованном для установки ОС и её компонент, Windows XP может хранить в значениях ключей реестра SourcePath и ServicePackSourcePath в ветке HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionSetup.

    Сделаем на файловом сервере каталог общего доступа и перепишем в него содержимое дистрибутивного носителя ОС (понадобится дистрибутив с последним интегрированным пакетом обновлений)

    Откроем редактор доменной групповой политики, распространяемой на наши клиентские компьютеры, в разделе Computer Configuration > Preferences > Windows Settings > Registry и вызовем мастер создания новой записи реестра.

    image

    В мастере выберем подключение к любому клиентскому компьютеру с Windows XP для того чтобы взять с него информацию об интересующих нас ключах реестра

    image

    После нажатия кнопки Finish мастер в виде вложенных папок скопирует структуру контейнеров реестра и добавит два интересующих нас ключа. Откроем свойства этих элементов и установим тип действия (Action) – Update, а в поле значения (Value data) введём сетевой путь к общему каталогу с дистрибутивом ОС для параметра SourcePath:

    clip_image005

    Также указываем аналогичное значение для параметра ServicePackSourcePath (подразумевается, что мы имеем дистрибутив с интегрированным в него пакетом исправлений):

    clip_image006

    Небольшое замечание:
    В ходе использования мастера добавления ключей реестра, я заметил один интересный глюк. Дело в том что, по завершению работы мастер сам заполняет значения полей Hive и Key Path, однако если после создания мастером такого элемента не зайти в его свойства и в ручную не выбрать раздел реестра (Hive), оно останется фактически пустым…

    image

    Это выяснилось после того как на клиентах упорно не хотел обновляться указанный ключ реестра, зато вместо этого создавался подобный ключ в пользовательском разделе реестра, который, как мы понимаем, никакой силы не имеет. После того как я открыл свойства элемента реестра, созданного мастером в GPP и вручную выбрал раздел HKEY_LOCAL_MACHINE… политика заработала так, как мы этого от неё ждали.

    image

    Если данная групповая политика применяется к общей массе клиентских компьютеров, в составе которых есть не только Windows XP, мы можем ограничить применение данной настройки реестра по версии ОС. Для этого откроем свойства корневой папки иерархии папок, сделанной мастером добавления, и на закладке Common включим режим нацеливания Item-level targeting

    image

    По кнопке Targeting добавим новое условие, означающее то, что данная настройка реестра будет применяться только компьютерам с ОС Windows XP

    clip_image012

    Если же по каким-то причинам в вашей организации не используются механизмы Group Policy Preferences, то можно настроить данный параметр и другими способам, например импортом нужной информации в реестр через логон-скрипт из *.reg файла с содержимым примерно следующего содержания:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionSetup]

    "SourcePath"="\\server\Sources\winxp_pro_sp3_x86_ru"

    "ServicePackSourcePath"="\\server\Sources\winxp_pro_sp3_x86_ru"