Informazioni sui criteri ADMX
Grazie alla maggiore semplicità e alla facilità con cui i dispositivi possono essere indirizzati, le aziende aziendali trovano sempre più vantaggioso spostare la gestione dei PC in una soluzione di gestione dei dispositivi basata sul cloud. Sfortunatamente, le moderne soluzioni di gestione dei dispositivi pc Windows non dispongono delle funzionalità di configurazione dei criteri e delle impostazioni dell'app critiche supportate in una soluzione di gestione dei PC tradizionale.
Supporto della configurazione dei criteri di mobile Gestione dispositivi (MDM) espanso per consentire l'accesso a un set selezionato di modelli amministrativi Criteri di gruppo (criteri ADMX) per PC Windows tramite il provider di servizi di configurazione dei criteri (CSP). Questo accesso esteso garantisce che le aziende possano mantenere i dispositivi conformi e impedire il rischio di compromettere la sicurezza dei dispositivi gestiti tramite il cloud.
Background
Oltre ai criteri MDM standard, il provider di servizi di configurazione dei criteri può gestire anche il set selezionato di criteri ADMX. In un criterio ADMX, un modello amministrativo contiene i metadati di un Criteri di gruppo Windows e può essere modificato nella Criteri di gruppo Editor locale in un PC. Ogni modello amministrativo specifica le chiavi del Registro di sistema (e i relativi valori) associate a un Criteri di gruppo e definisce le impostazioni dei criteri che possono essere gestite. I modelli amministrativi organizzano Criteri di gruppo in una gerarchia in cui ogni segmento nel percorso gerarchico è definito come categoria. Ogni impostazione in un modello amministrativo Criteri di gruppo corrisponde a un valore del Registro di sistema specifico. Queste impostazioni Criteri di gruppo sono definite in un formato di file XML basato su standard noto come file ADMX. Per altre informazioni, vedere Criteri di gruppo Guida di riferimento alla sintassi ADMX.
I file ADMX possono descrivere i criteri di gruppo del sistema operativo forniti con Windows oppure possono descrivere le impostazioni delle applicazioni, separate dal sistema operativo e in genere scaricabili e installate in un PC. A seconda della categoria specifica delle impostazioni che controllano (sistema operativo o applicazione), le impostazioni del modello amministrativo si trovano nelle due posizioni seguenti nella Criteri di gruppo Editor locale:
- Impostazioni del sistema operativo: Configurazione computer/Modelli amministrativi
- Impostazioni dell'applicazione: Configurazione utente/Modelli amministrativi
In un ecosistema di controller di dominio/Criteri di gruppo, i criteri di gruppo vengono aggiunti automaticamente al Registro di sistema del computer client o del profilo utente dall'estensione CSE (Client Side Extension) dei modelli amministrativi ogni volta che il computer client elabora un Criteri di gruppo. Al contrario, in un client gestito da MDM, i file ADMX vengono applicati per definire criteri indipendenti da Criteri di gruppo. Pertanto, in un client gestito da MDM, non è necessaria un'infrastruttura Criteri di gruppo, incluso il servizio Criteri di gruppo (gpsvc.exe).
Un file ADMX può essere fornito con Windows (disponibile in %SystemRoot%\policydefinitions) oppure può essere inserito in un dispositivo tramite l'URI CSP dei criteri (./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall). I file ADMX della posta in arrivo vengono elaborati in criteri MDM in fase di compilazione del sistema operativo. I file ADMX inseriti vengono elaborati nei criteri MDM dopo la spedizione del sistema operativo tramite il provider di servizi di configurazione dei criteri. Poiché il provider di servizi di configurazione dei criteri non si basa su alcun aspetto dello stack client Criteri di gruppo, incluso il servizio Criteri di gruppo del PC (GPSvc), i gestori dei criteri inseriti nel dispositivo sono in grado di reagire ai criteri impostati da MDM.
Windows esegue il mapping del nome e del percorso della categoria di un Criteri di gruppo a un'area dei criteri MDM e al nome dei criteri analizzando il file ADMX associato, individuando il Criteri di gruppo specificato e archiviando la definizione (metadati) nell'archivio client CSP dei criteri MDM. Quando il criterio MDM contiene un comando SyncML e l'URI CSP dei criteri, , .\[device|user]\vendor\msft\policy\[config|result]\<area>\<policy>viene fatto riferimento a questi metadati e si determina quali chiavi del Registro di sistema vengono impostate o rimosse. Per un elenco dei criteri ADMX supportati da MDM, vedere Criteri CSP - CRITERI ADMX.
File ADMX e Criteri di gruppo Editor
Per acquisire la gestione end-to-end di Criteri di gruppo ADMX, un amministratore IT deve usare un'interfaccia utente, ad esempio il Criteri di gruppo Editor (gpedit.msc), per raccogliere i dati necessari. L'interfaccia utente della console ISV MDM determina come raccogliere i dati Criteri di gruppo necessari dall'amministratore IT. I criteri di gruppo ADMX sono organizzati in una gerarchia e possono avere un ambito di computer, utente o entrambi. Nell'esempio Criteri di gruppo nella sezione successiva viene usato un Criteri di gruppo a livello di computer denominato "Impostazioni del server di pubblicazione 2". Quando questa Criteri di gruppo è selezionata, gli stati disponibili sono Non configurati, Abilitati e Disabilitati.
Il file ADMX usato da MDM ISV per determinare l'interfaccia utente da visualizzare all'amministratore IT è lo stesso file ADMX usato dal client per la definizione dei criteri. Il file ADMX viene elaborato dal sistema operativo in fase di compilazione o impostato dal client in fase di esecuzione del sistema operativo. In entrambi i casi, il client e l'ISV MDM devono essere sincronizzati con le definizioni dei criteri ADMX. Ogni file ADMX corrisponde a una categoria di Criteri di gruppo e in genere contiene diverse definizioni di criteri, ognuna delle quali rappresenta un singolo Criteri di gruppo. Ad esempio, la definizione dei criteri per "Impostazioni del server di pubblicazione 2" è contenuta nel file appv.admx, che contiene le definizioni dei criteri per la categoria Criteri di gruppo Microsoft Application Virtualization (App-V).
Criteri di gruppo impostazione del pulsante di opzione:
Se l'opzione Abilitato è selezionata, i controlli di immissione dati necessari vengono visualizzati per l'utente nell'interfaccia utente. Quando l'amministratore IT immette i dati e seleziona Applica, si verificano gli eventi seguenti:
- Il server ISV MDM configura un comando Sostituisci SyncML con un payload contenente i dati immessi dall'utente.
- Lo stack client MDM riceve questi dati, il che fa sì che il provider di servizi di configurazione dei criteri aggiorni il registro del dispositivo in base alla definizione dei criteri ADMX.
Se disabilitato è selezionato e si seleziona Applica, si verificano gli eventi seguenti:
- Il server ISV MDM configura un comando Sostituisci SyncML con un payload impostato su
<disabled\>. - Lo stack client MDM riceve questo comando, che fa sì che il provider di servizi di configurazione dei criteri elimini le impostazioni del Registro di sistema del dispositivo, imposti le chiavi del Registro di sistema o entrambe, in base alla modifica dello stato diretta dalla definizione dei criteri ADMX.
- Il server ISV MDM configura un comando Sostituisci SyncML con un payload impostato su
Se non configurato è selezionato e si seleziona Applica, si verificano gli eventi seguenti:
- Il server ISV MDM configura un comando Delete SyncML.
- Lo stack client MDM riceve questo comando, che fa sì che il provider di servizi di configurazione dei criteri elimini le impostazioni del Registro di sistema del dispositivo in base alla definizione dei criteri ADMX.
Il diagramma seguente mostra la visualizzazione principale per il Criteri di gruppo Editor.
Il diagramma seguente mostra le impostazioni per la Criteri di gruppo "Impostazioni del server di pubblicazione 2" nel Criteri di gruppo Editor.
La maggior parte dei criteri di gruppo è un tipo booleano semplice. Per un Criteri di gruppo booleano, se si seleziona Abilitato, il pannello delle opzioni non contiene campi di input dati e il payload di SyncML è semplicemente <enabled/>. Tuttavia, se nel pannello delle opzioni sono presenti campi di input di dati, il server MDM deve fornire questi dati. L'esempio di abilitazione di un Criteri di gruppo seguente illustra questa complessità. In questo esempio, 10 coppie nome-valore sono descritte dai <data /> tag nel payload, che corrispondono ai 10 campi di input di dati nel pannello delle opzioni Criteri di gruppo Editor per la Criteri di gruppo "Impostazioni del server di pubblicazione 2". Il file ADMX, che definisce i criteri di gruppo, viene utilizzato dal server MDM, in modo analogo al modo in cui il Criteri di gruppo Editor lo usa. Il Criteri di gruppo Editor visualizza un'interfaccia utente per ricevere i dati completi dell'istanza di Criteri di gruppo, operazione che deve essere terminata anche dalla console di amministrazione IT del server MDM. Per ogni <text> elemento e attributo ID nella definizione dei criteri ADMX, nel payload devono essere presenti un elemento e un attributo ID corrispondenti <data /> . Il file ADMX guida la definizione dei criteri ed è richiesto dal server MDM tramite il protocollo SyncML.
Importante
Qualsiasi campo di immissione dati visualizzato nella pagina Criteri di gruppo del Criteri di gruppo Editor deve essere specificato nel codice XML codificato del payload SyncML. Il payload dei dati SyncML equivale ai dati Criteri di gruppo forniti dall'utente tramite GPEdit.msc.
Per altre informazioni sul formato della descrizione Criteri di gruppo, vedere Formato file modello amministrativo (ADMX). Gli elementi possono essere Text, MultiText, Boolean, Enum, Decimal o List (per altre informazioni, vedere elementi dei criteri).
Ad esempio, se si cerca la stringa "Publishing_Server2_Name_Prompt" nell'esempio di abilitazione di un criterio e nella relativa definizione di criteri ADMX corrispondente nel file appv.admx, sono disponibili le occorrenze seguenti:
Abilitazione di un esempio di criteri:
`<data id="Publishing_Server2_Name_Prompt" value="name"/>`
File Appv.admx:
<elements>
<text id="Publishing_Server2_Name_Prompt" valueName="Name" required="true"/>
Esempi di criteri ADMX
Gli esempi SyncML seguenti descrivono come impostare un criterio MDM definito da un modello ADMX, in particolare la descrizione Publishing_Server2_Policy Criteri di gruppo nel file ADMX di virtualizzazione dell'applicazione, appv.admx. La funzionalità gestita da questo Criteri di gruppo non è importante, ma viene usata per illustrare solo come un ISV MDM può impostare un criterio ADMX. Questi esempi syncML illustrano le opzioni comuni e il codice SyncML corrispondente che può essere usato per testare i criteri. Il payload di SyncML deve essere codificato in XML; per questa codifica XML, è possibile usare lo strumento online preferito. Per evitare la codifica del payload, è possibile usare CData se MDM lo supporta. Per altre informazioni, vedere Sezioni di CDATA.
Abilitazione di un criterio
Payload:
<enabled/>
<data id="Publishing_Server2_Name_Prompt" value="Name"/>
<data id="Publishing_Server_URL_Prompt" value="http://someuri"/>
<data id="Global_Publishing_Refresh_Options" value="1"/>
<data id="Global_Refresh_OnLogon_Options" value="0"/>
<data id="Global_Refresh_Interval_Prompt" value="15"/>
<data id="Global_Refresh_Unit_Options" value="0"/>
<data id="User_Publishing_Refresh_Options" value="0"/>
<data id="User_Refresh_OnLogon_Options" value="0"/>
<data id="User_Refresh_Interval_Prompt" value="15"/>
<data id="User_Refresh_Unit_Options" value="1"/>
Richiedi SyncML:
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/AppVirtualization/PublishingAllowServer2</LocURI>
</Target>
<Data>
<![CDATA[<enabled/><data id="Publishing_Server2_Name_Prompt" value="name prompt"/><data
id="Publishing_Server_URL_Prompt" value="URL prompt"/><data
id="Global_Publishing_Refresh_Options" value="1"/><data
id="Global_Refresh_OnLogon_Options" value="0"/><data
id="Global_Refresh_Interval_Prompt" value="15"/><data
id="Global_Refresh_Unit_Options" value="0"/><data
id="User_Publishing_Refresh_Options" value="0"/><data
id="User_Refresh_OnLogon_Options" value="0"/><data
id="User_Refresh_Interval_Prompt" value="15"/><data
id="User_Refresh_Unit_Options" value="1"/>]]>
</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Response SyncML:
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Replace</Cmd>
<Data>200</Data>
</Status>
Disabilitazione di un criterio
Payload:
<disabled/>
Richiedi SyncML:
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/AppVirtualization/PublishingAllowServer2</LocURI>
</Target>
<Data><![CDATA[<disabled/>]]></Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Response SyncML:
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Replace</Cmd>
<Data>200</Data>
</Status>
Impostazione di un criterio su non configurato
Payload:
(Nessuna)
Richiedi SyncML:
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Delete>
<CmdID>1</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/AppVirtualization/PublishingAllowServer2</LocURI>
</Target>
</Item>
</Delete>
<Final/>
</SyncBody>
</SyncML>
Response SyncML:
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>1</CmdRef>
<Cmd>Delete</Cmd>
<Data>200</Data>
</Status>
SyncML di esempio per vari elementi ADMX
Questa sezione descrive syncML di esempio per i vari elementi ADMX, ad esempio Text, Multi-Text, Decimal, Boolean ed List.
Come viene eseguito il mapping di un percorso e di un nome di categoria di criteri Criteri di gruppo a un'area MDM e al nome dei criteri
Ecco il mapping interno del sistema operativo di un Criteri di gruppo a un'area E a un nome MDM. Questo mapping fa parte di un set di manifesto di Windows che, quando compilato analizza il file ADMX associato, trova il criterio di Criteri di gruppo specificato e archivia tale definizione (metadati) nell'archivio client CSP dei criteri MDM. I criteri supportati da ADMX sono organizzati in modo gerarchico. Il loro ambito può essere computer, utente o avere un ambito di entrambi. Quando si fa riferimento ai criteri MDM tramite un comando SyncML e l'URI CSP dei criteri, come illustrato, si fa riferimento a questi metadati e si determina a quali chiavi del Registro di sistema vengono impostate o rimosse. Viene fatto riferimento ai criteri di ambito del computer tramite .\Device e i criteri di ambito utente tramite .\User.
./[Device|User]/Vendor/MSFT/Policy/Config/[config|result]/<area>/<policy>
Il payload dei dati di SyncML deve essere codificato in modo che non sia in conflitto con i tag XML SyncML boilerplate. Usare questo strumento online per codificare e decodificare la casella degli strumenti del coder dei dati dei criteri.
Frammento di manifesto per l'area AppVirtualization:
<identity xmlns="urn:Microsoft.CompPlat/ManifestSchema.v1.00" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" owner="Microsoft" namespace="Windows-DeviceManagement-PolicyDefinition" name="AppVirtualization">
<policyDefinitions>
<area name="AppVirtualization">
<policies>
...
<stringPolicy name="PublishingAllowServer2" notSupportedOnPlatform="phone" admxbacked="appv.admx" scope="machine">
<ADMXPolicy area="appv~AT~System~CAT_AppV~CAT_Publishing" name="Publishing_Server2_Policy" scope="machine" />
<registryKeyRedirect path="SOFTWARE\Policies\Microsoft\AppV\Client\Publishing\Servers\2" />
</stringPolicy >
...
LocURI per i criteri criteri di gruppo precedenti è:
./Device/Vendor/MSFT/Policy/Config/AppVirtualization/PublishingAllowServer2
Per costruire SyncML per l'area o i criteri usando gli esempi seguenti, è necessario aggiornare l'ID dati e il valore nella <Data> sezione di SyncML. Gli elementi preceduti da un carattere "&" sono i caratteri di escape necessari e possono essere conservati come illustrato.
Elemento Text
L'elemento text corrisponde semplicemente a una stringa e corrispondentemente a una casella di modifica in un pannello dei criteri visualizzato da gpedit.msc. La stringa viene archiviata nel Registro di sistema di tipo REG_SZ.
File ADMX: inetres.admx:
<policy name="RestrictHomePage" class="User" displayName="$(string.RestrictHomePage)" explainText="$(string.IE_ExplainRestrictHomePage)" presentation="$(presentation.RestrictHomePage)" key="Software\Policies\Microsoft\Internet Explorer\Control Panel" valueName="HomePage">
<parentCategory ref="InternetExplorer" />
<supportedOn ref="SUPPORTED_IE5" />
<elements>
<text id="EnterHomePagePrompt" key="Software\Policies\Microsoft\Internet Explorer\Main" valueName="Start Page" required="true" />
</elements>
</policy>
SyncML corrispondente:
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>$CmdId$</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./User/Vendor/MSFT/Policy/Config/InternetExplorer/DisableHomePageChange</LocURI>
</Target>
<Data><![CDATA[<enabled/><data id="EnterHomePagePrompt" value="mystartpage"/>]]></Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Elemento MultiText
L'elemento multiText corrisponde semplicemente a una stringa del Registro di sistema REG_MULTISZ e corrispondente a una griglia per immettere più stringhe in un pannello dei criteri visualizzato da gpedit.msc. Si prevede che ogni stringa in SyncML sia separata dal carattere Unicode 0xF000 (versione codificata: )
<policy name="Virtualization_JITVAllowList" class="Machine" displayName="$(string.Virtualization_JITVAllowList)"
explainText="$(string.Virtualization_JITVAllowList_Help)" presentation="$(presentation.Virtualization_JITVAllowList)"
key="SOFTWARE\Policies\Microsoft\AppV\Client\Virtualization"
valueName="ProcessesUsingVirtualComponents">
<parentCategory ref="CAT_Virtualization" />
<supportedOn ref="windows:SUPPORTED_Windows7" />
<elements>
<multiText id="Virtualization_JITVAllowList_Prompt" valueName="ProcessesUsingVirtualComponents" />
</elements>
</policy>
SyncML corrispondente:
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/AppVirtualization/VirtualComponentsAllowList</LocURI>
</Target>
<Data><![CDATA[<enabled/><data id="Virtualization_JITVAllowList_Prompt" value="C:\QuickPatch\TEST\snot.exeC:\QuickPatch\TEST\foo.exeC:\QuickPatch\TEST\bar.exe"/>]]></Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Elemento List (e relative varianti)
L'elemento list corrisponde semplicemente a un hive di REG_SZ stringhe del Registro di sistema e corrispondentemente a una griglia per immettere più stringhe in un pannello dei criteri visualizzato da gpedit.msc. Il modo in cui questo elemento viene rappresentato in SyncML è come stringa contenente coppie di stringhe. Ogni coppia è una chiave nome/valore REG_SZ. È consigliabile applicare i criteri tramite gpedit.msc (eseguire come amministratore) e passare al percorso hive del Registro di sistema e vedere come vengono archiviati i valori dell'elenco. Questa posizione offre un'idea del modo in cui vengono archiviate le coppie nome/valore per esprimerle tramite SyncML.
Nota
Si prevede che ogni stringa in SyncML sia separata dal carattere Unicode 0xF000 (versione codificata: ).
Le variazioni dell'elemento list sono dettate dagli attributi. Questi attributi vengono ignorati dal runtime di Policy Manager. Si prevede che il server MDM gestirà le coppie nome/valore. Ecco alcuni esempi per l'elenco Criteri di gruppo.
File ADMX: inetres.admx:
<policy name="SecondaryHomePages" class="Both" displayName="$(string.SecondaryHomePages)" explainText="$(string.IE_ExplainSecondaryHomePages)" presentation="$(presentation.SecondaryHomePages)" key="Software\Policies\Microsoft\Internet Explorer\Main\SecondaryStartPages">
<parentCategory ref="InternetExplorer" />
<supportedOn ref="SUPPORTED_IE8" />
<elements>
<list id="SecondaryHomePagesList" additive="true" />
</elements>
</policy>
SyncML corrispondente:
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./User/Vendor/MSFT/Policy/Config/InternetExplorer/DisableSecondaryHomePageChange</LocURI>
</Target>
<Data><![CDATA[<Enabled/><Data id="SecondaryHomePagesList" value="http://name1http://name1http://name2http://name2"/>]]></Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Nessun elemento
<policy name="NoUpdateCheck" class="Machine" displayName="$(string.NoUpdateCheck)" explainText="$(string.IE_ExplainNoUpdateCheck)" key="Software\Policies\Microsoft\Internet Explorer\Infodelivery\Restrictions" valueName="NoUpdateCheck">
<parentCategory ref="InternetExplorer" />
<supportedOn ref="SUPPORTED_IE5_6" />
</policy>
SyncML corrispondente:
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/InternetExplorer/DisableUpdateCheck</LocURI>
</Target>
<Data><![CDATA[<Enabled/>]]></Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Enum
<policy name="EncryptionMethodWithXts_Name" class="Machine" displayName="$(string.EncryptionMethodWithXts_Name)" explainText="$(string.EncryptionMethodWithXts_Help)" presentation="$(presentation.EncryptionMethodWithXts_Name)" key="SOFTWARE\Policies\Microsoft\FVE">
<parentCategory ref="FVECategory" />
<!--Bug OS:4242178 -->
<supportedOn ref="windows:SUPPORTED_Windows_10_0" />
<elements>
<enum id="EncryptionMethodWithXtsOsDropDown_Name" valueName="EncryptionMethodWithXtsOs" required="true">
<item displayName="$(string.EncryptionMethodDropDown_AES128_Name2)">
<value>
<decimal value="3" />
</value>
</item>
<item displayName="$(string.EncryptionMethodDropDown_AES256_Name2)">
<value>
<decimal value="4" />
</value>
</item>
<item displayName="$(string.EncryptionMethodDropDown_XTS_AES128_Name)">
<value>
<decimal value="6" />
</value>
</item>
<item displayName="$(string.EncryptionMethodDropDown_XTS_AES256_Name)">
<value>
<decimal value="7" />
</value>
</item>
</enum>
</elements>
</policy>
SyncML corrispondente:
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/BitLocker/EncryptionMethodByDriveType</LocURI>
</Target>
<Data>
<![CDATA[<enabled/>
<data id="EncryptionMethodWithXtsOsDropDown_Name" value="4"/>]]>
</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Elemento Decimal
<policy name="Streaming_Reestablishment_Interval" class="Machine" displayName="$(string.Streaming_Reestablishment_Interval)"
explainText="$(string.Streaming_Reestablishment_Interval_Help)"
presentation="$(presentation.Streaming_Reestablishment_Interval)"
key="SOFTWARE\Policies\Microsoft\AppV\Client\Streaming">
<parentCategory ref="CAT_Streaming" />
<supportedOn ref="windows:SUPPORTED_Windows7" />
<elements>
<decimal id="Streaming_Reestablishment_Interval_Prompt" valueName="ReestablishmentInterval" minValue="0" maxValue="3600"/>
</elements>
</policy>
SyncML corrispondente:
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/AppVirtualization/StreamingAllowReestablishmentInterval</LocURI>
</Target>
<Data>
<![CDATA[<enabled/>
<data id="Streaming_Reestablishment_Interval_Prompt" value="4"/>]]>
</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Elemento Boolean
<policy name="DeviceInstall_Classes_Deny" class="Machine" displayName="$(string.DeviceInstall_Classes_Deny)" explainText="$(string.DeviceInstall_Classes_Deny_Help)" presentation="$(presentation.DeviceInstall_Classes_Deny)" key="Software\Policies\Microsoft\Windows\DeviceInstall\Restrictions" valueName="DenyDeviceClasses">
<parentCategory ref="DeviceInstall_Restrictions_Category" />
<supportedOn ref="windows:SUPPORTED_WindowsVista" />
<enabledValue>
<decimal value="1" />
</enabledValue>
<disabledValue>
<decimal value="0" />
</disabledValue>
<elements>
<list id="DeviceInstall_Classes_Deny_List" key="Software\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceClasses" valuePrefix="" />
<boolean id="DeviceInstall_Classes_Deny_Retroactive" valueName="DenyDeviceClassesRetroactive" >
<trueValue>
<decimal value="1" />
</trueValue>
<falseValue>
<decimal value="0" />
</falseValue>
</boolean>
</elements>
</policy>
SyncML corrispondente:
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.2">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/PreventInstallationOfMatchingDeviceSetupClasses</LocURI>
</Target>
<Data>
<![CDATA[<enabled/><data id="DeviceInstall_Classes_Deny_Retroactive" value="true"/>
<Data id="DeviceInstall_Classes_Deny_List" value="1deviceId12deviceId2"/>]]>
</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per