Domande frequenti e problemi relativi a Microsoft Information Protection (MIP) SDK

Questo articolo fornisce risposte alle domande frequenti e alle indicazioni per la risoluzione dei problemi noti e degli errori comuni.

Domande frequenti

Modifiche all'archiviazione dei metadati

È stato annunciato che stiamo apportando una modifica al percorso di archiviazione dei metadati delle etichette per i file di Office (Word, Excel, PowerPoint) per supportare nuove funzionalità in Office 365, SharePoint Online e altri servizi.

Domande frequenti sui metadati

Domanda: altri formati sono interessati, ad esempio pdf?

• No, solo i file di Office, in particolare Word, Excel e PowerPoint.

Domanda: È necessaria una versione specifica di MIP SDK?

• MIP SDK 1.7 e versioni successive sono completamente compatibili.

Domanda: Esiste una versione specifica del client di Office necessaria per usare questo percorso di archiviazione?

• Tutti i client di Microsoft 365 Apps rilasciati dopo settembre 2021 supportano questa nuova posizione dei metadati. La nuova posizione di archiviazione non viene usata finché gli amministratori tenant non abilitano la funzionalità di creazione condivisa protetta.

Domanda: I metadati esistenti vengono archiviati come proprietà personalizzata in custom.xml essere aggiornati?

• No. La prima volta che il documento viene salvato dopo l'abilitazione del nuovo percorso di archiviazione, i metadati delle etichette vengono spostati nella nuova posizione. I metadati scritti tramite LabelingOptions.ExtendedProperties rimangono in custom.xml.

Domanda: È possibile leggere i metadati dell'etichetta senza MIP SDK?

• Sì, ma è necessario implementare il proprio codice per analizzare il file ed estrarre le informazioni.

Domanda: attualmente è facile "leggere" l'etichetta estraendo le stringhe di coppia chiave/valore dal file. I metadati possono ancora essere letti in questo modo?

• Sì, i metadati sono ancora disponibili nel file XML di Office da leggere. L'applicazione deve leggere l'impostazione di creazione condivisa dal file dei criteri per sapere che il nuovo set di funzionalità è abilitato. Questa impostazione definisce dove leggere/scrivere i dati dell'etichetta (custom.xml e labelinfo.xml). Esaminare MS-OFFCRYPTO: LabelInfo e proprietà personalizzate del documento | Microsoft Docs. per informazioni dettagliate sull'implementazione.

Domanda: Ricerca per categorie determinare se la creazione condivisa è abilitata nei criteri di etichetta? Lo stato dell'impostazione di creazione condivisa viene restituito dal motore dei criteri. Un'applicazione può leggere i byte non elaborati dal motore dei criteri per determinare lo stato di creazione condivisa.

Domanda: Come viene eseguita la migrazione delle etichette alla nuova posizione?

• La logica seguente viene usata per determinare quale sezione viene letta e usata per leggere o scrivere dati etichetta.

Azione	Funzionalità non abilitata	Funzionalità abilitata
Lettura	Etichetta in custom.xml (non protetta) o Doc SummaryInfo (protetta).	Se l'etichetta esiste in labelinfo.xml, è l'etichetta effettiva. Se non è presente alcuna etichetta in labelinfo.xml, l'etichetta in custom.xml o Doc SummaryInfo è l'etichetta effettiva.
Scrittura	Tutte le nuove etichette vengono scritte in custom.xml (non protetto) o Doc SummaryInfo (protected).	Tutte le nuove etichette vengono scritte in labelinfo.xml.

Analisi dei file

Domanda: È possibile scrivere nello stesso file attualmente letto con File SDK?

MIP SDK non supporta la lettura e la scrittura simultanea dello stesso file. Tutti i file etichettati generano una copia del file di input con le azioni di etichetta applicate. L'applicazione deve sostituire l'originale con il file etichettato.

Gestione delle stringhe SDK

Domanda: In che modo l'SDK gestisce le stringhe e quale tipo di stringa deve essere usato nel codice?

L'SDK è progettato per essere usato multipiattaforma e usa UTF-8 (Formato trasformazione Unicode - 8 bit) per la gestione delle stringhe. Le indicazioni specifiche dipendono dalla piattaforma in uso:

Piattaforma	Indicazioni
Windows nativo	Per i client C++ SDK, il tipo di std::string libreria standard C++ viene usato per passare stringhe a/da funzioni API. MIP SDK gestisce internamente la conversione da e verso UTF-8. Quando un oggetto std::string viene restituito da un'API, è necessario prevedere la codifica UTF-8 e gestirla di conseguenza se si converte la stringa. In alcuni casi, una stringa viene restituita come parte di un uint8_t vettore ,ad esempio una licenza di pubblicazione (PL), ma deve essere considerata un BLOB opaco. Per altre informazioni ed esempi, vedere: Funzione WideCharToMultiByte per assistenza nella conversione di stringhe di caratteri wide in più byte, ad esempio UTF-8. I file di esempio seguenti inclusi nel download dell'SDK: Funzioni di utilità stringa di esempio in file\samples\common\string_utils.cppper la conversione da/verso stringhe UTF-8 wide. Implementazione di wmain(int argc, wchar_t *argv[]) in file\samples\file\main.cpp, che usa le funzioni di conversione di stringhe precedenti.
.NET	Per i client .NET SDK, tutte le stringhe usano la codifica UTF-16 predefinita e non è necessaria alcuna conversione speciale. MIP SDK gestisce internamente la conversione da e verso UTF-16.
Altre piattaforme	Tutte le altre piattaforme supportate da MIP SDK hanno supporto nativo per UTF-8.

Contrassegno del contenuto

Domanda: MIP SDK supporta il contrassegno del contenuto?

MIP SDK non supporta l'applicazione diretta del contrassegno del contenuto, tra cui intestazione, piè di pagina o filigrana, su qualsiasi file. Quando i metadati delle etichette vengono scritti in un file, File SDK scrive la proprietà dei metadati contentBits per indicare che la protezione è stata applicata (se configurata). Non scrive le proprietà che indicano l'applicazione di intestazione, piè di pagina o filigrana. Quando il file viene aperto in un'applicazione, la configurazione del contrassegno del contenuto deve essere valutata dall'applicazione e scritta nel file al salvataggio.

Protezione e SDK dei criteri in Android

Domanda: Quale libreria condivisa è consigliabile usare per l'integrazione di MIP SDK nell'applicazione Android?

I file binari android di MIP SDK includono libmip_core.so, libmip_protection_sdk.solibmip_upe_sdk.so e lipmip_unified.so. libmip_unified.so è la libreria consigliata che include le librerie condivise di base, protezione e criteri.

Conformità

Domanda: Microsoft Information Protection SDK Federal Information Processing Standard (FIPS) 140-2 è conforme?

Vedere Convalida FIPS 140-2.

Informazioni di riferimento su problemi ed errori

Errore: "Formato di file non supportato"

Domanda: Perché viene visualizzato l'errore seguente quando si tenta di proteggere o etichettare un file PDF?

Formato di file non supportato

Questa eccezione determina il tentativo di proteggere o etichettare un file PDF firmato digitalmente o protetto da password. Per altre informazioni sulla protezione e l'etichettatura dei file PDF, vedere Nuovo supporto per la crittografia PDF con Microsoft Information Protection .

Errore: "NoPolicyException: I criteri di etichetta non contengono dati"

Domanda: Perché viene visualizzato l'errore seguente quando si tenta di leggere un'etichetta o un elenco di etichette tramite MIP SDK?

NoPolicyException: i criteri di etichetta non contengono dati, CorrelationId=GUID, CorrelationId.Description=PolicyProfile, NoPolicyError.Category=SyncFile, NoPolicyError.Category=SyncFile

Questo errore indica che i criteri di etichetta non vengono pubblicati nel Portale di conformità di Microsoft Purview. Seguire Creare e configurare le etichette di riservatezza e i relativi criteri per configurare i criteri di etichettatura.

Se è stato pubblicato un criterio di etichettatura, assicurarsi che l'account utente sia incluso in tutti i gruppi che fanno parte della sezione pubblicata nella sezione della configurazione dei criteri di etichetta. Per altre informazioni, vedere Creare e pubblicare etichette di riservatezza.

Gli utenti esterni, inclusi gli utenti guest, non possono accedere ai criteri di etichetta di un'altra organizzazione. Per soddisfare questi utenti, implementare un meccanismo di ripetizione dei tentativi. Se viene generata un'eccezione NoPolicyException , impostare la FileEngineSettings proprietà ProtectionOnlyEngine su true e ripetere la richiesta. Le operazioni di etichettatura non saranno disponibili per tale IFileEngine istanza, ma le operazioni di protezione saranno disponibili.

Errore: "System.ComponentModel.Win32Exception: LoadLibrary failed"

Domanda: Perché viene visualizzato l'errore seguente quando si usa il wrapper .NET di MIP SDK?

System.ComponentModel.Win32Exception: LoadLibrary non è riuscito per: [sdk_wrapper_dotnet.dll] durante la chiamata a MIP. Initialize().

L'applicazione non ha il runtime necessario o non è stata compilata come Release. Per altre informazioni, vedi Verificare che l'app disponga del runtime necessario.

Errore: "Eccezione ProxyAuthError"

Domanda: Perché viene visualizzato l'errore seguente quando si usa MIP SDK?

"ProxyAuthenticatonError: l'autenticazione proxy non è supportata"

MIP SDK non supporta l'uso di proxy autenticati. Per correggere questo messaggio, gli amministratori proxy devono impostare gli endpoint del servizio Microsoft Purview Information Protection per ignorare il proxy. Un elenco di questi endpoint è disponibile nella pagina URL e intervalli di indirizzi IP di Office 365. MIP SDK richiede che *.protection.outlook.com (riga 9) e gli endpoint del servizio Azure Information Protection (riga 73) ignorino l'autenticazione proxy.

Errore: "Errore sconosciuto" quando si etichetta un file di immagine usando un output del flusso

Domanda: Perché viene visualizzato un "errore sconosciuto" quando si tenta di aggiungere o rimuovere un'etichetta o una protezione da un tipo di file di immagine usando un flusso per l'output?

Quando si usa un flusso per l'output, il flusso deve avere accesso in lettura e scrittura per modificare l'etichetta o la protezione per un file di immagine.

Domanda: Esistono limiti di limitazione basati sul servizio quando si usa MIP SDK?

Il servizio di protezione, usato dall'SDK di protezione o dalle operazioni di protezione in File SDK, ha un limite di 7.500 richieste per 10 secondi per un'intera organizzazione. Ovvero, se l'applicazione A genera 4.000 richieste per 10 secondi e l'applicazione B nella stessa organizzazione genera 4.000 richieste per 10 secondi, entrambe le applicazioni possono iniziare a ricevere HTTP 429 Too Many Requests risposte. Gli sviluppatori devono implementare un periodo di backoff quando vengono ricevute queste eccezioni.