Использование файлов шаблонов групповая политика Фслогикс
Обзор
Фслогикс использует набор разделов реестра, которые должны быть включены и правильно настроены на виртуальных машинах пула узлов AVD.
Существует несколько способов применения этих разделов реестра в зависимости от сценария и масштаба среды.
создание разделов реестра вручную с помощью редактора реестра Windows: не рекомендуется, так как подвержены ошибки и потенциально высокий риск. Требуется ручная работа и масштабирование на многих узлах сложно. Следует использовать только для тестирования и создания прототипов на одном компьютере.
локальные политики. можно использовать механизм групповая политика объектов (GPO) в Windows, чтобы применить набор параметров конфигурации (разделов реестра), используя объект, хранящийся локально на одном компьютере. Следует использовать только для тестирования и разработки объекта GPO, который применяется к крупному масштабу с помощью центрального хранилища.
Центральное хранилище для политик. Этот подход является рекомендуемым механизмом для применения фслогикс и любым другим параметром конфигурации в масштабе на всех виртуальных машинах пула узлов Avd. Централизованный репозиторий, размещенный на контроллерах домен Active Directory, используется для репликации всего домена Active Directory.
Предварительные требования
локальные политики и центральное хранилище для политик основываются на Windows функции, называемой административными шаблонами групповой политики, также известными как шаблоны ADMX. В оставшейся части этой статьи будет описана эта функция.
Прежде чем продолжать, необходимо скачать пакет установки Фслогикс, расположенный здесь, а затем распаковать файл и проверить содержимое:
Чтобы создать шаблон ADMX, необходимо скопировать два файла: фслогикс. ADML и фслогикс. ADMX.
Шаблоны ADMX
Чтобы упростить создание объектов групповой политики, администраторы могут импортировать эти шаблоны и автоматически настроить пользовательский интерфейс редактора со всеми включенными параметрами.
После завершения разработки объекта GPO с учетом всех требуемых изменений результирующий объект объекта GPO может быть связан (связан) с подразделением (OU) в Active Directory.
Даже если объект GPO можно связать с разными областями в Active Directory (сайт, домен и подразделение), рекомендуется создать определенное подразделение для каждого пула узлов AVD и переместить все связанные учетные записи ВИРТУАЛЬНЫХ машин.
Если виртуальные машины пула узлов AVD будут созданы и присоединены к домену Active Directory, политики GPO будут автоматически применены и Фслогикс будут настроены.
Изменение локальной политики
Даже если можно создать и изменить локально объект GPO с помощью тех же файлов шаблонов, в рабочей среде рекомендуется использовать центральное хранилище. Для полноты ниже приведены шаги, необходимые для локального использования файлов шаблонов.
скопируйте файл ADMX (фслогикс. admx) в C:\ Windows \полицидефинитионс (и разблокируйте доступ к файлу в атрибуте file).
скопируйте файл ADML (фслогикс. ADML) в C:\ Windows \полицидефинитионс\ен-ус (и разблокируйте доступ к файлу в атрибуте file).
Запустите средство «редактор локальных групповых политик» (gpedit. MSC)
Просмотрите и включите нужные параметры, а затем сохраните объект.
Только что созданный объект будет сохранен и применен только на этом компьютере и не будет применен к другим виртуальным машинам в пуле узлов AVD.
Центральное хранилище
чтобы воспользоваться преимуществами файлов . admx и автоматически распространять параметры на весь парк виртуальных машин пула узлов AVD, необходимо создать центральное хранилище в папке Sysvol на Windows контроллере домена. Центральное хранилище — это расположение файлов, которое по умолчанию проверяется групповая политика инструментами.
Теперь скопируйте файл Фслогикс фслогикс. ADMX только в это расположение.
папка PolicyDefinitions _ на контроллере домена Windows хранит все файлы _ . admx и . adml для всех языков, включенных на клиентских компьютерах. Файлы ADML хранятся в папке для конкретного языка. Например, файлы на английском языке (США) хранятся в папке с именем en-US. Если он отсутствует, необходимо создать папку для конкретного языка en-US, а затем добавить фслогикс. ADML в.
Дополнительные сведения о центральном хранилище можно найти в этой статье:
Изменение шаблона
В предыдущем разделе вы завершили подготовку шаблона ADMX, относящегося к Фслогикс для домена Active Directory. Теперь вы готовы использовать этот шаблон для создания объекта групповой политики для пула узлов AVD.
средства администрирования, которые вы будете использовать, — это редактор объектов групповой политики и консоль управления групповыми политиками: эти средства уже установлены на сервере Windows, вместо этого потребуется вручную установить дополнительный пакет на клиенте Windows.
Войдите с учетной записью администратора домена на компьютер или виртуальную машину в домен Active Directory.
в Windows клиентской ос при необходимости установите средство «RSAT: групповая политика Management tools«:
Найдите подразделение (OU), где находятся учетные записи компьютера пула узлов AVD, в контекстном меню выберите «создать объект GPO в этом домене и свяжите его здесь. «. Введите имя для нового объекта групповой политики и нажмите кнопку «ОК».
Щелкните правой кнопкой мыши созданную политику и выберите «изменить«, после чего откроется приложение редактор «Управление групповыми политиками».
Разверните узел Конфигурация компьютера политики > > административные шаблоны > фслогикс и включите необходимые параметры для конфигурации. в родительской папке фслогикс есть выделенные разделы для облачного кэша, контейнера Office 365 контейнере и контейнера профиля.
Для каждого параметра дважды щелкните его, включите и в конечном итоге заполните необходимые значения. В конце щелкните «Применить«, чтобы сохранить и выйти из диалогового окна:
Создание и управление административными шаблонами центра групповой политики в Windows
Ссылки на загрузку файлов административных шаблонов на основе версии операционной системы
Чтобы просмотреть таблицы ADMX новых параметров, доступных в более поздних версиях операционной системы, см. в Параметры таблицы групповой политики для обновления Windows 10 ноября 2021 г. (21H2).
Обзор
Хранилище файлов административных шаблонов
Центральный магазин
Мы предлагаем сохранить репозиторий любых файлов ADMX/L, которые у вас есть для приложений, которые вы можете использовать. Например, расширения операционной системы, такие как Пакет оптимизации Microsoft Desktop (MDOP), Microsoft Office, а также сторонние приложения, которые предлагают поддержку групповой политики.
Если у вас уже есть такая папка, которая имеет ранее построенный Центральный магазин, используйте новую папку с описанием текущей версии, например:
Скопируйте все файлы из папки PolicyDefinitions на исходный компьютер в новую папку PolicyDefinitions на контроллере домена. Расположение источника может быть одним из следующих:
Когда коллекция операционной системы будет завершена, объединяй все файлы ADMX/ADML в новую папку PolicyDefinitions.
После этого переименуем текущую папку PolicyDefinitions, чтобы отразить, что это предыдущая версия, например PolicyDefinitions-1709. Затем переименуем новую папку (например, PolicyDefinitions-1803) в производственное имя.
Мы предлагаем такой подход, так как вы можете вернуться к старой папке в случае серьезной проблемы с новым набором файлов. Если у вас нет проблем с новым набором файлов, вы можете переместить старую папку PolicyDefinitions в расположение архива за пределами папки sysvol.
Администрирование групповой политики
Обновление файлов административных шаблонов
Доступно обновление, чтобы включить использование локальных файлов ADMX для редактора групповой политики.
Этот параметр также можно использовать для:
Известные проблемы
Пространство имен «Microsoft.Policies.Sensors.WindowsLocationProvider» уже определено как целевое пространство имен для другого файла в магазине.
Файл
\\ \SysVol \Policies\PolicyDefinitions\Microsoft-Windows-Geolocation-WLPAdm.admx, строка 5, столбец 110
В пути в этом сообщении имя домена.
Обе проблемы можно избежать путем создания нетронутой папки PolicyDefinitions из базовой папки выпуска ОС, как описано выше.
Обновление/установка административных шаблонов групповых политик (ADMX)
В этой статье мы рассмотрим особенности процесса обновления (установки) новых административных шаблонов GPO (admx) в домене Active при обновлении билда Windows 10 или Windows Server 2016/2019 на устройствах.
Обновление ADMX шаблонов GPO при апгрейде билда Windows 10 на клиентах
В связи с тем, что Microsoft постоянно обновляет свои операционные системы и добавляет в них различный функционал, одновременно с этим она выпускает новые административные шаблоны. Чтобы администратор мог централизованной управлять новыми функциями Windows через GPO, ему необходимо регулярно обновлять административные шаблоны в домене AD.
Например, у вас имеется домен на базе Windows Server 2016 и компьютеры в домене, которые обновились до билда Windows 10 2004. В этом билде, например, появилась новая опция Delivery Optimization для управления механизмом Windows Update for Business (WUfB). Теперь вы можете указать максимальную пропускную способность, которую технология Delivery Optimization может использовать для фоновой загрузки обновлений.
Но вы не сможете настроить этот параметр на всех компьютерах с помощью доменных групповых политик, т.к. в консоли редактора GPO ( gpmc.msc ) этот параметр политики отсутствует, т.к. в хранилище шаблонов на DC новых параметров нет (их можно использовать только на в локальных политиках или MLGPO на компьютере с новым билдом Windows 10).
В этом случае вам нужно обновить административные шаблоны GPO на контроллерах домена. Рассмотрим как это сделать:
Установка нового административного шаблона в домене Active Directory
Аналогичным образом устанавливаются новые административные шаблоны. Например, вы планируете использовать групповые политики для управления параметрами браузера Edge Chromium на компьютерах пользователей. Административные шаблоны для Edge Chromium отсутствуют как в Windows 10 2004, так и в 20H2. Вам придется вручную скачать файлы политик Edge Chromium и скопировать admx файлы в каталог PolicyDefinitions на контролере домена.
Если у вас в компании используется несколько версий ПО, которыми вы хотите управлять через GPO, последовательно загрузите и установите на DC все admx для всех версий, начиная с самой старой (admx шаблоны для актуальной версии софта нужно устанавливать в последнюю очередь).
Погружение в шаблоны и приручение GPO Windows
В очередной статье из цикла «конспект админа» мне хотелось бы освежить в памяти несколько нюансов использования групповых политик. Заодно поразвлекаемся с созданием своих шаблонов и с автоматизацией работы с этими самыми политиками.
Освежаем память
Я не буду рассказывать, что такое групповые политики, и остановлюсь лишь на основных моментах, которые стоит иметь в виду при работе с ними.
В системах Windows помимо доменных существуют и локальные групповые политики ― управлять ими можно при помощи оснастки gpedit.msc на системах редакции Professional и выше. Часто считается, что без домена можно настраивать локальные групповые политики только для всех пользователей на компьютере. Это не совсем верно ― с выходом Windows Vista появилась возможность использовать множественную локальную групповую политику или MLGPO. Этот механизм позволяет настраивать отдельные политики для разных пользователей.
Добраться до него можно через вызов консоли mmc: при добавлении оснастки «Управление объектами групповой политики» нажать кнопку «Обзор». Далее на вкладке «Пользователи» уже можно выбрать конкретного пользователя или группу «Администраторы» и «Не администраторы». К сожалению, управление для группы пользователей не реализовано.
Управление групповой политикой для отдельных пользователей.
Бывало и так, что на отдельностоящем терминальном сервере разворачивали Active Directory только для того, чтобы отдельному пользователю настроить поведение драйвера для EasyPrint. Не надо так.
При добавлении доменных групповых политик стоит помнить про порядок их применения ― политика, примененная последней, будет обладать наивысшим приоритетом (да и на собеседованиях часто спрашивают).
Итак, предположим, что у нас есть компьютер в домене и четыре групповые политики: локальная на этом компьютере; политика на подразделение, в котором находится компьютер; политика на домен и политика на лес. Порядок их применения будет следующим:
То есть чем ближе к объекту, тем приоритетнее, за исключением локальной групповой политики. Если надо отключить применение вышестоящих политик, то ставьте блокировку наследования.
Блокировка наследования.
Любую групповую политику можно условно разделить на две конфигурации ― пользователя и компьютера. Обычно политики с настройками компьютеров назначаются на подразделение, в котором находятся компьютеры. А политики с настройками пользователей ― на пользователей.
Если надо применить настройки компьютера к подразделению с пользователями и наоборот, используют так называемое замыкание групповой политики. Например, такая настройка пригодится, когда нужно применить специфические политики к пользователям для работы на терминальных серверах.
Работа замыкания настраивается непосредственно в политике ― «Настройка компьютера ― Административные шаблоны ― Система ― Режим обработки замыкания пользовательской групповой политики». Подробнее про механизм уже писали в статье про использование Merge\Replace в GPO. Я лишь добавлю, что режим замыкания групповой политики ― тоже частый вопрос на собеседовании.
Настройка замыкания групповой политики.
Физически доменные групповые политики находятся в папке SYSVOL на контроллерах домена. Папка реплицируется между контроллерами. Каждая групповая политика выглядит как папка с именем в виде GUID.
Групповые политики домена.
Правила фильтрации, настраиваемые через редактор групповой политики, соответствуют настройкам прав NTFS на соответствующую подпапку.
Говоря о правилах фильтрации, нельзя не упомянуть обновление MS16-072, которое «сломало» групповые политики. Теперь для того чтобы работали правила фильтрации, надо добавлять к каждому фильтру правило «на чтение», но не «на применение» группе Domain Computers.
В каждой папке с групповой политикой существуют подпапки Machine и User, соответствующие настройкам пользователя и компьютера. Если углубиться в подпапки, можно легко понять структуру групповой политики:
Подробнее про структуру можно почитать в материале Group Policy Basics, поэтому перейдем сразу к шаблонам.
Административные шаблоны
По сути своей административные шаблоны ― это специальные файлы с инструкциями по изменению клиентского реестра (ветки HKCU или HKLM) и настройками отображения изменяемых параметров через «Управление групповой политикой». В принципе, реестр можно менять и через «Предпочтения групповых политик». Но разница здесь не только в красивом интерфейсе.
| Способ изменения реестра | Как ведет себя при удалении политики со стандартными настройками | Можно ли изменить параметр вручную | Можно ли изменить параметр через приложение |
| Шаблоны | Параметр реестра восстанавливается на значение «по умолчанию», если настройки по умолчанию есть в шаблоне | — | — |
| Предпочтения политик | Параметр реестра не изменяется | + | + |
Сравнение предпочтения групповых политик и административных шаблонов.
Другими словами, настройка реестра через шаблоны групповых политик более строгая. Тогда как настройка через предпочтения групповых политик напоминает периодическое применение reg-файла. Конечно, предпочтения позволяют не только менять параметры реестра, но и довольно гибко настраиваются. Тем и ценны.
Это актуально при изменении ветки Policies, и настраиваемое приложение должно хранить свои настройки в реестре. Простое изменение параметров через Предпочтения и Шаблоны будет работать схожим образом, только шаблоны могут оказаться удобнее.
Не обошлось без ложки дегтя ― теперь содержимое файла представляет собой популярный в индустрии формат XML. И создавать новые шаблоны в блокноте стало уже не так удобно.
Под большинство параметров, которые могут понадобиться, шаблоны уже существуют. Кроме того, многие производители приложений выпускают свои административные шаблоны. Вот несколько примеров:
Создаем свой шаблон
Для начала разберем простой пример. Создадим шаблон групповой политики, который позволит нам включать и выключать отображение скрытых и системных файлов, а заодно и отображение расширений.
Сразу скажу, что это можно провернуть через «Предпочтения групповых политик» ― в параметрах панели управления ― опции папки. Но мы легких путей не ищем и заодно не хотим, чтобы параметры отображения можно было менять вручную.
За необходимые нам параметры отвечают три ключа в реестре:
Разберем подробнее синтаксис файла.
Помимо задействованных опций есть и другие, например:
Подробнее со всеми параметрами можно ознакомится в разделе MSDN ADM Format.
Установить новый шаблон не просто, а очень просто ― достаточно щелкнуть правой кнопкой мыши по пункту «Административные шаблоны», выбрать «Добавление и удаление шаблонов» и добавить наш свежесозданный шаблон.
Добавленный шаблон.
После установки шаблона он отобразится в ветке «Классические административные шаблоны».
Конвертируем шаблон.
Конечно же, можно обойтись без вот-этого-всего и разобраться самостоятельно ― оставлю это в качестве домашнего задания. Благо на портале MSDN есть подробное описание XML-схемы, и есть неплохие материалы с примерами в сети. Например, «Административные шаблоны групповой политики».
Теперь перейдем к автоматизации.
Автоматическое управление
Работать с групповыми политиками из командной строки довольно тоскливо. Основных инструментов можно выделить три.
PowerShell. Есть набор командлетов для резервного копирования, восстановления и управления групповыми политиками. Создание новых политик ограничено ― можно лишь изменять реестр. Впрочем, в большинстве случаев и этого достаточно. В качестве примера создадим групповую политику, которая отключит автоматическое обновление Adobe Reader DC.
За отключение автоматического обновления отвечает ключ реестра bUpdater в ветке [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown]. Установив параметр в 0, мы отключим опцию.
Создание групповой политики на PowerShell будет выглядеть так:
Свежесозданная групповая политика.
Полный список и описание командлетов доступны в материале Technet Group Policy Cmdlets in Windows PowerShell.
Интерфейс COM к GPMC (консоли управления групповой политикой). Способ позволяет сделать с политиками многое, на любом языке программирования, поддерживающим COM-интерфейсы. К сожалению, популярность он не приобрел и примеров в сети довольно мало, несмотря на богатое описание методов интерфейса на портале MSDN. Немногочисленные примеры использования доступны для загрузки в галерее Technet.
LGPO.exe. Не так давно Microsoft заменил набор утилит для работы с локальными групповыми политиками на единую утилиту. Скачать ее можно на официальном сайте. Утилита удобна для копирования и развертывания локальных групповых политик. Заявлена и поддержка MLGPO. Создавать свои политики тоже можно. Также программа удобна для создания и изменения файлов реестра registry.pol. Для примера изменим локальную групповую политику, добавив в нее отключение обновления несчастного Acrobat Reader DC.
Сделаем бэкап локальной групповой политики командой
В папке C:\Temp появится подпапка с GUID по структуре схожая с доменными групповыми политиками:
Теперь развернем registry.pol в текстовый файл:
Синтаксис текстового файла очевиден. Добавим в него значения реестра для отключения автоматического обновления «Акробата»:
Добавленный в файл параметр реестра.
Теперь останется завернуть наш reg.txt обратно в registry.pol и импортировать изменившийся файл обратно в локальную групповую политику:
Все эти махинации, конечно же, можно завернуть в один скрипт и использовать для массового изменения локальной групповой политики привычным инструментом для запуска команд на удаленных компьютерах. Подробнее про методы запуска команд можно почитать в нашей статье «1000++ способ запуска команд на удаленном компьютере».
Конечно же, зная структуру доменной групповой политики, ничто не мешает сделать удобный именно вам инструмент для создания и управления политиками. Поделитесь в комментариях, есть ли у вас свои способы настройки реестров пользовательских машин?
Общие сведения о политиках ADMX
Благодаря большей простоте и простоте ориентации на устройства предприятиям становится все выгоднее переместить управление компьютерами в облачное решение управления устройствами. К сожалению, Windows решения для управления устройствами для ПК не имеют возможности конфигурации критически важных политик и параметров приложений, которые поддерживаются в традиционном решении управления ПК.
Начиная с Windows 10 версии 1703 поддержка конфигурации политики управления мобильными устройствами (MDM) расширилась, чтобы разрешить доступ к выбранному набору административных шаблонов групповой политики (политики ADMX) для Windows компьютеров через поставщика служб конфигурации политики (CSP). Этот расширенный доступ гарантирует, что предприятия могут соблюдать требования к своим устройствам и предотвращать риск, связанный с угрозой безопасности своих устройств, управляемых через облако.
В дополнение к стандартным политикам MDM CSP политики также может обрабатывать выбранный набор политик ADMX. В политике ADMX административный шаблон содержит метаданные групповой политики Windows и может изменяться в редакторе локальной групповой политики на компьютере. Каждый административный шаблон указывает ключи реестра (и их значения), связанные с групповой политикой, и определяет параметры политики, которые можно управлять. Административные шаблоны организуют групповые политики в иерархии, в которой каждый сегмент иерархического пути определяется как категория. Каждый параметр в административном шаблоне групповой политики соответствует определенному значению реестра. Эти параметры групповой политики определяются в формате XML-файла на основе стандартов, известного как ADMX-файл. Дополнительные сведения см. в руководстве по групповой политике ADMX Syntax.
Файлы ADMX могут либо описывать групповые политики операционной системы (ОС), поставляемые с помощью Windows, либо они могут описывать параметры приложений, которые отделены от ОС и обычно могут быть загружены и установлены на компьютере. В зависимости от конкретной категории параметров, которые они контролируют (ОС или приложения), параметры административных шаблонов находятся в следующих двух расположениях в редакторе локальной групповой политики:
В экосистеме контроллера домена или групповой политики групповые политики автоматически добавляются в реестр клиентского компьютера или профиля пользователя с помощью расширения клиентской стороны административных шаблонов (CSE) всякий раз, когда клиентский компьютер обрабатывает групповую политику. И наоборот, в клиенте, управляемом MDM, ADMX-файлы используют для определения политик, независимых от групповой политики. Поэтому в клиенте, управляемом MDM, инфраструктура групповой политики, включая службу групповой политики (gpsvc.exe), не требуется.
Файлы ADMX и редактор групповой политики
Для захвата конечной обработки MDM групповой политики ADMX ИТ-администратор должен использовать пользовательский интерфейс, например редактор групповой политики (gpedit.msc), для сбора необходимых данных. Пользовательский интерфейс консоли MDM ISV определяет, как собирать необходимые данные групповой политики у ИТ-администратора. Групповые политики ADMX организованы в иерархии и могут иметь область действия машины, пользователя или обоих. В примере групповой политики в следующем разделе используется компьютерная группа политика с именем «Publishing Server 2 Параметры». При выборе этой групповой политики ее доступные состояния **** не настроены, включены и отключены.
ADMX-файл, который использует MDM ISV для определения пользовательского интерфейса для отображения ИТ-администратору, это тот же ADMX-файл, который клиент использует для определения политики. ADMX-файл обрабатывается осмием во время сборки или устанавливается клиентом во время запуска ОС. В любом случае клиент и isV MDM должны быть синхронизированы с определениями политики ADMX. Каждый ADMX-файл соответствует категории групповой политики и обычно содержит несколько определений политики, каждый из которых представляет одну групповую политику. Например, определение политики для «Publishing Server 2 Параметры» содержится в файле appv.admx, в котором содержатся определения политик для категории групповой политики microsoft Application Virtualization (App-V).
Параметр параметра Групповой политики:
Если включено, для пользователя в пользовательском интерфейсе отображаются необходимые элементы управления входом данных. Когда ИТ-администратор вводит данные и щелкает Apply, происходят следующие события:
Если выбрана отключенная и нажмите кнопку Применить, происходят следующие события:
Если выбрано не настроено, и вы нажмете Применить, происходят следующие события:
На следующей схеме показан основной дисплей редактора групповой политики.
На следующей схеме показаны параметры групповой политики «Publishing Server 2 Параметры» в редакторе групповой политики.
id в полезной нагрузке. ADMX-файл диски определения политики и требуется на сервере MDM с помощью протокола SyncML.
Любое поле ввода данных, отображаемого на странице групповой политики редактора групповой политики, должно быть предоставлено в закодированном XML полезной нагрузки SyncML. Нагрузка на данные SyncML эквивалентна данным групповой политики, предоставленным пользователем через GPEdit.msc.
Дополнительные сведения о формате описания групповой политики см. в формате Administrative Template File (ADMX). Элементами могут быть Text, MultiText, Boolean, Enum, Decimal или List (дополнительные сведения см. в элементах политики).
Например, при поиске строки «Publishing_Server2_Name_Prompt» в примере ** включения политики и соответствующем определении политики ADMX в файле appv.admx вы найдете следующие случаи:
Включение примера политики:
Примеры политики ADMX
В следующих примерах SyncML описывается, как установить политику MDM, определяемую шаблоном ADMX, в частности описание групповой политики Publishing_Server2_Policy в ADMX-файле Виртуализации приложений appv.admx. Обратите внимание, что функциональные возможности, управляемые этой групповой политикой, не важны; он используется для иллюстрации того, как isV MDM может установить политику ADMX. Эти примеры SyncML иллюстрируют распространенные параметры и соответствующий код SyncML, который можно использовать для тестирования политик. Обратите внимание, что полезной нагрузкой SyncML должна быть кодирована XML; Для этого кодиля XML можно использовать любимый интерактивный инструмент. Чтобы не кодить полезной нагрузки, можно использовать CData, если MDM поддерживает ее. Дополнительные сведения см. в разделах CDATA.
Включение политики
Полезной нагрузки
Запрос SyncML
Синхронизация ответов
Отключение политики
Полезной нагрузки
Запрос SyncML
Настройка политики, которая не настроена
Полезной нагрузки
Запрос SyncML
Синхронизация ответов
Пример SyncML для различных элементов ADMX
В этом разделе описан пример SyncML для различных элементов ADMX, таких как Text, Multi-Text, Decimal, Boolean и List.
Как путь и имя категории групповой политики соизме-ются с областью MDM и именем политики
Обратите внимание, что полезной нагрузки данных SyncML необходимо закодировать, чтобы она не противоречила шаблонным XML-тегам SyncML. Используйте этот интерактивный инструмент для коди-кодинга и коди-
Фрагмент манифеста для области AppVirtualization:
LocURI для вышеуказанной политики GP:
Чтобы создать SyncML для области или политики с помощью приведенных ниже примеров, необходимо обновить id данных и значение в разделе **** SyncML. Элементы с префиксом «&» являются необходимыми символами побега и могут быть сохранены, как показано.
Текстовый элемент
Элемент просто соответствует строке и соответственно окне редактирования в панели политик, отображаемой text gpedit.msc. Строка хранится в реестре типа REG_SZ.
ADMX-файл: inetres.admx
Соответствующий SyncML:
Элемент MultiText
Элемент просто соответствует строке REG_MULTISZ реестра и соответственно сетке для ввода нескольких строк в панели политик с помощью multiText gpedit.msc. Обратите внимание, что ожидается, что каждая строка в SyncML должна быть разделена символом Unicode 0xF000 (кодированная версия: )
Соответствующий SyncML:
Элемент List (и его варианты)
Элемент просто соответствует улью строк REG_SZ реестра и соответственно сетке, чтобы ввести несколько строк в панели политик, отображаемой list gpedit.msc. То, как это представлено в SyncML, представляет собой строку, содержащую пары строк. Каждая пара — это REG_SZ имя/значение. Лучше всего применить политику через gpedit.msc (выполнить в качестве администратора) и перейти к расположению улья реестра и посмотреть, как хранятся значения списка. Это даст вам представление о том, как хранятся пары имен и значений для выражения их с помощью SyncML.
Ожидается, что каждая строка в SyncML будет разделена символом Unicode 0xF000 (кодированная версия: ).
Вариации элемента list продиктованы атрибутами. Эти атрибуты игнорируются диспетчером политики. Ожидается, что MDM-сервер управляет парами имен и значений. См. ниже простую записи списка групповой политики.