Supporto del protocollo OMA DM

• Si applica a:

  ✅ Windows 11, ✅ Windows 10

Il client OMA DM comunica con il server tramite HTTPS e usa Dm Sync (OMA DM v1.2) come payload del messaggio. Questo articolo descrive la funzionalità dm OMA supportata in generale dal client dm. La descrizione completa del protocollo OMA DM v1.2 è disponibile nel sito Web OMA.

Standard OMA DM

La tabella seguente illustra gli standard OMA DM usati da Windows.

Area generale	Standard OMA DM supportato
Trasporto dati e sessione	Sessione remota DI GESTIONE INDIRIZZI HTTPS avviata dal client su TLS/SSL. Sessione remota del servizio Migrazione del database HTTPS tramite TLS/SSL. Notifica di avvio del server Dm remoto tramite WAP Push over Short Message Service (SMS). Non usato dalla gestione aziendale. Bootstrap remoto tramite WAP Push over SMS. Non usato dalla gestione aziendale.
Bootstrap XML	Xml di provisioning client OMA.
Comandi del protocollo DM	L'elenco seguente mostra i comandi usati dal dispositivo. Per altre informazioni sugli elementi del comando OMA DM, vedere "sito Web OMA" disponibile nel sito Web OMA. Aggiungi (aggiunta implicita supportata) Avviso (avviso DM): l'avviso generico (1226) viene usato dal client di gestione aziendale quando l'utente attiva un'azione di annullamento della registrazione MDM dal dispositivo o quando un CSP termina alcune azioni asincrone. L'avviso del dispositivo (1224) viene usato per notificare al server un evento attivato dal dispositivo. Atomic: l'esecuzione di un comando Add seguito da Replace nello stesso nodo all'interno di un elemento atomico non è supportata. I comandi Atomic e Get annidati non sono consentiti e generano il codice di errore 500. Elimina: rimuove un nodo dall'albero dm e l'intero sottoalbero sotto tale nodo, se esistente Exec: richiama un eseguibile nel dispositivo client Get: recupera i dati dal dispositivo client; Per i nodi interni, i nomi dei nodi figlio nell'elemento Data vengono restituiti in formato con codifica URI Sostituisci: sovrascrive i dati nel dispositivo client Risultato: restituisce i risultati dei dati di un comando Get al server Dm Sequenza: specifica l'ordine in cui deve essere elaborato un gruppo di comandi Stato: indica lo stato di completamento (esito positivo o negativo) di un'operazione Se un elemento XML che non è un comando OMA DM valido si trova in uno degli elementi seguenti, viene restituito il codice di stato 400 per tale elemento: SyncBody Atomica Sequenza Se nel comando DM non viene specificato alcun CmdID, il client restituisce vuoto nell'elemento status e nel codice di stato 400. Se gli elementi Atomic sono annidati, vengono restituiti i codici di stato seguenti: Il comando Atomic annidato restituisce 500. Il comando atomico padre restituisce 507. Per altre informazioni sul comando Atomic, vedere Elementi comuni del protocollo OMA DM. L'esecuzione di un comando Add seguito da Replace nello stesso nodo all'interno di un elemento Atomic non è supportata. LocURI non può iniziare con /. Il tag Meta XML in SyncHdr viene ignorato dal dispositivo.
Oggetti standard OMA DM	DevInfo DevDetail Oggetti account DMS OMA DM (OMA DM versione 1.2)
Sicurezza	Autenticare il messaggio SMS di notifica di avvio del server DM (non usato dalla gestione aziendale) Autenticazione client BASIC e MD5 a livello di applicazione Autenticare il server con le credenziali MD5 a livello di applicazione Integrità e autenticazione dei dati con HMAC a livello di applicazione Controllo dell'integrità dei dati, della crittografia e dell'autenticazione client basata su certificato a livello TLS/SSL
Nodi	Nell'albero OMA DM si applicano le regole seguenti per il nome del nodo: "." può far parte del nome del nodo. Il nome del nodo non può essere vuoto. Il nome del nodo non può essere solo il carattere asterisco (*).
File di provisioning	Il formato XML di provisioning deve essere corretto e seguire la definizione in SyncML Representation Protocol. Se un elemento XML che non è un comando OMA DM valido si trova in SyncBody, viene restituito il codice di stato 400 per tale elemento. Nota Per rappresentare una stringa Unicode come URI, codificare prima la stringa come UTF-8. Codificare quindi ognuno dei byte UTF-8 usando la codifica URI.
Supporto WBXML	Windows supporta l'invio e la ricezione di SyncML sia in formato XML che in formato WBXML codificato. Questo supporto a doppio formato è configurabile usando il nodo DEFAULTENCODING con la caratteristica w7 APPLICATION durante la registrazione. Per altre informazioni sulla codifica WBXML, vedere la sezione 8 della specifica SyncML Representation Protocol .
Gestione di oggetti di grandi dimensioni	In Windows 10 è stato aggiunto il supporto client per il caricamento di oggetti di grandi dimensioni nel server.

Elementi comuni del protocollo OMA DM

Gli elementi comuni vengono usati da altri tipi di elemento OMA DM. Nella tabella seguente sono elencati gli elementi comuni di OMA DM usati per configurare i dispositivi. Per altre informazioni sugli elementi comuni di OMA DM, vedere "SyncML Representation Protocol Gestione dispositivi Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) disponibile nel sito Web OMA.

Elemento	Descrizione
Chal	Specifica una richiesta di autenticazione. Il server o il client può inviare una richiesta all'altro se nel messaggio di richiesta originale non sono state fornite credenziali o credenziali insufficienti.
Cmd	Specifica il nome di un comando OMA DM a cui viene fatto riferimento in un elemento Status.
CmdID	Specifica l'identificatore univoco per un comando OMA DM.
CmdRef	Specifica l'ID del comando per cui vengono restituite informazioni sullo stato o sui risultati. Questo elemento accetta il valore dell'elemento CmdID del messaggio di richiesta corrispondente.
Cred	Specifica le credenziali di autenticazione per l'originatore del messaggio.
Finale	Indica che il messaggio corrente è l'ultimo messaggio nel pacchetto.
LocName	Specifica il nome visualizzato negli elementi Destinazione e Origine, usato per inviare un ID utente per l'autenticazione MD5.
LocURI	Specifica l'indirizzo della destinazione o del percorso di origine. Se l'indirizzo contiene un carattere non alfanumerico, deve essere sottoposto a escape correttamente in base allo standard di codifica URL.
Msgid	Specifica un identificatore univoco per un messaggio di sessione OMA DM.
MsgRef	Specifica l'ID del messaggio di richiesta corrispondente. Questo elemento accetta il valore dell'elemento MsgID del messaggio di richiesta.
RespURI	Specifica l'URI che il destinatario deve usare quando invia una risposta a questo messaggio.
Sessionid	Specifica l'identificatore della sessione dm OMA associata al messaggio contenitore. Se il server non notifica al dispositivo che supporta una nuova versione (tramite il nodo SyncApplicationVersion nel CSP DMClient), il client restituisce l'ID sessione in formato integer in formato decimale. Se il server supporta la sincronizzazione sessione DM versione 2.0, usata in Windows, il client del dispositivo restituisce 2 byte.
Source	Specifica l'indirizzo di origine del messaggio.
SourceRef	Specifica l'origine del messaggio di richiesta corrispondente. Questo elemento accetta il valore dell'elemento Source del messaggio di richiesta e viene restituito nell'elemento Status o Results.
Target	Specifica l'indirizzo del nodo nell'albero del database che è la destinazione del comando OMA DM.
TargetRef	Specifica l'indirizzo di destinazione nel messaggio di richiesta corrispondente. Questo elemento accetta il valore dell'elemento Target del messaggio di richiesta e viene restituito nell'elemento Status o Results.
VerDTD	Specifica l'identificatore della versione principale e secondaria della specifica del protocollo di rappresentazione OMA DM usata per rappresentare il messaggio.
VerProto	Specifica l'identificatore di versione principale e secondaria della specifica del protocollo OMA DM usata con il messaggio.

Sessione di gestione dei dispositivi

Una sessione di Gestione dispositivi (DM) è costituita da una serie di comandi scambiati tra un server Dm e un dispositivo client. Il server invia comandi che indicano le operazioni che devono essere eseguite nell'albero di gestione del dispositivo client. Il client risponde inviando comandi contenenti i risultati e le informazioni sullo stato richieste.

Una breve sessione dm può essere riepilogata come segue:

Un server invia un comando Get a un dispositivo client per recuperare il contenuto di uno dei nodi dell'albero di gestione. Il dispositivo esegue l'operazione e risponde con un comando Result che contiene il contenuto richiesto.

Una sessione dm può essere suddivisa in due fasi:

1. Fase di installazione: in risposta a un evento trigger, un dispositivo client invia un messaggio di avvio a un server dm. Lo scambio di dispositivi e server richiedeva l'autenticazione e le informazioni sul dispositivo. Questa fase è rappresentata dai passaggi 1, 2 e 3.
2. Fase di gestione: il server dm è in controllo. Invia comandi di gestione al dispositivo e il dispositivo risponde. La fase 2 termina quando il server dm interrompe l'invio dei comandi e termina la sessione. Questa fase è rappresentata dai passaggi 3, 4 e 5.

Le informazioni seguenti mostrano la sequenza di eventi durante una tipica sessione dm.

1. Il client dm viene richiamato per richiamare il server di gestione
   
   Scenario aziendale: la pianificazione delle attività del dispositivo richiama il client dm.

   Il server MO invia un messaggio di trigger del server per richiamare il client dm.

   Il messaggio del trigger include l'ID server e indica al dispositivo client di avviare una sessione con il server. Il dispositivo client autentica il messaggio del trigger e verifica che il server sia autorizzato a comunicare con esso.
   
   Scenario aziendale: all'ora pianificata, il client dm viene richiamato periodicamente per richiamare il server di gestione aziendale tramite HTTPS.

2. Il dispositivo invia un messaggio, tramite una connessione IP, per avviare la sessione.

   Questo messaggio include le informazioni e le credenziali del dispositivo. Il client e il server esenziano l'autenticazione reciproca tramite un canale TLS/SSL o a livello di applicazione dm.

3. Il server dm risponde tramite una connessione IP (HTTPS). Il server invia i comandi di gestione dei dispositivi iniziali, se presenti.

4. Il dispositivo risponde ai comandi di gestione del server. Questo messaggio include i risultati dell'esecuzione delle operazioni di gestione dei dispositivi specificate.

5. Il server Dm termina la sessione o invia un altro comando. La sessione dm termina o il passaggio 4 viene ripetuto.

I numeri di passaggio non rappresentano i numeri di identificazione dei messaggi (MsgID). Tutti i messaggi dal server devono avere un MsgID univoco all'interno della sessione, a partire da 1 per il primo messaggio e aumentando di un incremento di 1 per ogni messaggio aggiuntivo. Per altre informazioni sul protocollo MsgID e OMA SyncML, vedere OMA Gestione dispositivi Representation Protocol (DM_RepPro-V1_2-20070209-A).

Durante l'autenticazione reciproca a livello di applicazione OMA DM, se il codice di risposta del dispositivo all'elemento Cred nella richiesta del server è 212, non è necessaria alcuna ulteriore autenticazione per la parte restante della sessione dm. Se si verifica l'autenticazione MD5, è possibile restituire l'elemento Chal . Il successivo nonce in Chal deve quindi essere usato per il digest MD5 all'avvio della sessione dm successiva.

Se una richiesta include credenziali e il codice di risposta alla richiesta è 200, le stesse credenziali devono essere inviate all'interno della richiesta successiva. Se l'elemento Chal è incluso e l'autenticazione MD5 è necessaria, viene creato un nuovo digest usando il nonce successivo tramite l'elemento per la Chal richiesta successiva.

Per altre informazioni sull'autenticazione client Basic o MD5, Autenticazione server MD5, hash MD5 e nonce MD5, vedere la specifica OMA Gestione dispositivi Security (OMA-TS-DM_Security-V1_2_1-20080617-A), la gestione del codice di risposta per l'autenticazione e gli esempi passo passo nella specifica del protocollo OMA Gestione dispositivi (OMA-TS-DM_Protocol-V1_2_1-20080617-A), disponibile da sito Web OMA.

Configurazione destinata all'utente e configurazione di destinazione del dispositivo

Per i CSP e i criteri che supportano la configurazione per utente, il server MDM può inviare valori di impostazione di destinazione utente al dispositivo a cui un utente registrato tramite MDM è attivamente connesso. Il dispositivo notifica al server lo stato di accesso tramite un avviso del dispositivo (1224) con tipo di avviso = in DM pkg#1.

La parte dei dati di questo avviso potrebbe essere una delle stringhe seguenti:

• Utente: l'utente che ha registrato il dispositivo è attivamente connesso. Il server MDM può inviare la configurazione specifica dell'utente per i CSP/criteri che supportano la configurazione per utente
• Altri: un altro utente esegue l'accesso, ma tale utente non ha un account MDM. Il server può applicare solo la configurazione a livello di dispositivo, ad esempio la configurazione si applica a tutti gli utenti del dispositivo.
• Nessuno: nessun accesso utente attivo. Il server può applicare solo la configurazione a livello di dispositivo e la configurazione disponibile è limitata all'ambiente del dispositivo (nessun accesso utente attivo).

Ecco un esempio di avviso:

<Alert>
    <CmdID>1</CmdID>
    <Data>1224</Data>
    <Item>
        <Meta>
            <Type xmlns="syncml:metinf">com.microsoft/MDM/LoginStatus</Type>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Data>user</Data>
    </Item>
</Alert>

Il server notifica al dispositivo se si tratta di una configurazione di destinazione utente o di destinazione del dispositivo con un prefisso per locURL del nodo di gestione, con ./user per la configurazione di destinazione dell'utente o ./device per la configurazione di destinazione del dispositivo. Per impostazione predefinita, se non è disponibile alcun prefisso con ./device o ./user, si tratta di una configurazione di destinazione del dispositivo.

Il locURL seguente mostra una configurazione del nodo CSP per utente: ./user/vendor/MSFT/EnterpriseModernAppManagement/AppInstallation/<PackageFamilyName>/StoreInstall

Il locURL seguente mostra una configurazione del nodo CSP per dispositivo: ./device/vendor/MSFT/RemoteWipe/DoWipe

Codici di stato della risposta SyncML

Quando si usa SyncML in OMA DM, vengono restituiti i codici di stato della risposta standard. Nella tabella seguente sono elencati i codici di stato comuni della risposta SyncML che probabilmente verranno visualizzati. Per altre informazioni sui codici di stato della risposta SyncML, vedere la sezione 10 della specifica SyncML Representation Protocol .

Codice di stato	Descrizione
200	Il comando SyncML è stato completato correttamente.
202	Accettato per l'elaborazione. Questo codice indica un'operazione asincrona, ad esempio una richiesta di esecuzione remota di un'applicazione.
212	Autenticazione accettata. In genere questo codice viene visualizzato solo in risposta all'elemento SyncHdr (usato per l'autenticazione nello standard OMA-DM). È possibile che questo codice venga visualizzato se si esaminano i log di OMA DM, ma i CSP in genere non generano questo codice.
214	Operazione annullata. Il comando SyncML è stato completato correttamente, ma non vengono elaborati altri comandi all'interno della sessione.
215	Non eseguito. Un comando non è stato eseguito a causa dell'interazione dell'utente per annullare il comando.
216	Atomic rollback OK. Un comando si trovava all'interno di un Atomic elemento e Atomic non è riuscito. Il rollback di questo comando è stato eseguito correttamente.
400	Richiesta non valida. Impossibile eseguire il comando richiesto a causa di una sintassi non valida. I CSP in genere non generano questo errore, ma è possibile che venga visualizzato se syncML non è valido.
401	Credenziali non valide. Il comando richiesto non è riuscito perché il richiedente deve fornire l'autenticazione corretta. I CSP in genere non generano questo errore.
403	Proibito. Il comando richiesto non è riuscito, ma il destinatario ha compreso il comando richiesto.
404	Non trovato. La destinazione richiesta non è stata trovata. Questo codice viene generato se si esegue una query su un nodo che non esiste.
405	Comando non consentito. Questo codice di risposta viene generato se si tenta di scrivere in un nodo di sola lettura.
406	Funzionalità facoltativa non supportata. Questo codice di risposta viene generato se si tenta di accedere a una proprietà non supportata dal CSP.
415	Tipo o formato non supportato. Questo codice di risposta può risultare da errori di analisi o formattazione XML.
418	Esiste già. Questo codice di risposta si verifica se si tenta di aggiungere un nodo già esistente.
425	Autorizzazione negata. Il comando richiesto non è riuscito perché il mittente non dispone di autorizzazioni di controllo di accesso (ACL) adeguate per il destinatario. Gli errori di accesso negato vengono in genere convertiti in questo codice di risposta.
500	Comando non riuscito. Errore generico. Il destinatario ha rilevato una condizione imprevista, che ha impedito di soddisfare la richiesta. Questo codice di risposta si verifica quando la DPU SyncML non è in grado di eseguire il mapping del codice di errore di origine.
507	Atomic Fallito. Una delle operazioni in un Atomic blocco non è riuscita.
516	Atomic rollback non riuscito. Un'operazione Atomic non è riuscita e non è stato eseguito il rollback del comando.

Articoli correlati

Riferimento del provider di servizi di configurazione