Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit des réponses aux questions fréquentes (FAQ) et des conseils de résolution des problèmes connus et des erreurs courantes.
Forum Aux Questions
question : combien d’étiquettes sont prises en charge par le SDK MIP ?
- Le SDK MIP peut gérer jusqu’à 500 étiquettes de protection et il n’existe aucune limite pour les étiquettes sans protection.
Question : Le SDK MIP prend-il en charge le réétiquetage des types .pfile avec des étiquettes de classification ?
- Non, c’est par conception, car les fichiers pfile sont des types de fichiers protégés. Déchiffrer avec l’étiquette de fichier MPIP avant la classification.
Question : Pourquoi les fichiers protégés téléchargés à partir de Microsoft Teams ne parviennent-ils pas à déchiffrer ?
- Il s’agit d’un problème connu dans les versions non prises en charge du Kit de développement logiciel (SDK) MIP. Effectuez une mise à niveau vers la dernière version du Kit de développement logiciel (SDK) MIP.
Question : Comment vérifier quelles étiquettes sont appliquées lorsque plusieurs étiquettes provenant de différents locataires sont appliquées à un fichier ?
- Interroger le GetLabel dans le contexte de l'utilisateur pour chaque locataire.
Question : Pourquoi mon application web ne parvient-elle pas à initialiser avec « InternalError : « KeyStoreWin32 ::OpenKey failure : NCryptOpenKey :-2147024894 » ?
- Le Kit de développement logiciel (SDK) de stratégie peut ne pas charger un profil pendant l’initialisation de l’application. Définissez WEBSITE_LOAD_USER_PROFILE=1 dans le paramètre de variable d’environnement de votre application web et redémarrez l’application.
- Nom : WEBSITE_LOAD_USER_PROFILE
- Valeur : 1
Question : Pourquoi mon application échoue-t-elle avec « KeyStoreWin32 ::OpenKey failure : NCryptOpenKey :-2146893788 » lorsque la mise en cache OnDiskEncrypted est configurée ?
- Windows peut créer des profils temporaires lorsque votre profil de connexion n’est pas disponible. La lecture du registre Windows pour la mise en cache OnDiskEncrypted Link avec ce profil temporaire provoque l'échec d'OpenKey dans le journal du SDK MIP et est capturé par les journaux d'événements du système d'exploitation Windows avec l'ID d'événement 1511 & 1515. Pour résoudre ce problème, contactez votre administrateur pour résoudre le problème de création de profils temporaires.
Modifications du stockage des métadonnées
Nous avons annoncé que nous apportons une modification à l’emplacement de stockage des métadonnées d’étiquette pour les fichiers Office (Word, Excel, PowerPoint) pour prendre en charge de nouvelles fonctionnalités dans Office 365, SharePoint Online et d’autres services.
FAQ de métadonnées
Question : D’autres formats sont-ils affectés, tels que PDF ?
- Non, seulement les fichiers Office, en particulier les fichiers Word, Excel et PowerPoint.
Question : Existe-t-il une version spécifique du SDK MIP requise ?
- Le SDK MIP 1.7 et les versions ultérieures sont entièrement compatibles.
Question : Existe-t-il une version spécifique du client Office requise pour utiliser cet emplacement de stockage ?
- Tous les clients Microsoft 365 Apps publiés après septembre 2021 prennent en charge ce nouvel emplacement de métadonnées. Le nouvel emplacement de stockage n’est pas utilisé tant que les administrateurs du locataire n’activent pas la fonctionnalité de co-création protégée.
Question : Les métadonnées existantes stockées en tant que propriété personnalisée dans custom.xml sont-elles maintenues à jour ?
- Non. La première fois que le document est enregistré une fois que le nouvel emplacement de stockage est activé, les métadonnées d’étiquette sont déplacées vers le nouvel emplacement. Les métadonnées écrites via
LabelingOptions.ExtendedPropertiesrestent dans custom.xml.
Question : Est-il possible de lire les métadonnées d’étiquette sans le SDK MIP ?
- Oui, mais vous devez implémenter votre propre code pour analyser le fichier et extraire les informations.
Question : Actuellement, il est facile de « lire » l’étiquette en extrayant les chaînes de paire clé-valeur du fichier. Les métadonnées peuvent-elles toujours être lues de cette façon ?
- Oui, les métadonnées sont toujours disponibles dans le fichier XML du fichier Office à lire. Votre application doit lire le paramètre de co-création à partir du fichier de stratégie pour savoir que le nouvel ensemble de fonctionnalités est activé. Ce paramètre définit l’emplacement où lire/écrire les données d’étiquette (custom.xml et labelinfo.xml). Consultez MS-OFFCRYPTO : LabelInfo et propriétés personnalisées du document | Microsoft Docs. pour plus d’informations sur l’implémentation.
Question : Comment faire déterminer si la co-création est activée dans la stratégie d’étiquette ? L’état du paramètre de co-création est retourné par le moteur de stratégie. Une application peut lire les octets bruts depuis le moteur de stratégie pour déterminer l’état de co-création.
Question : Comment les étiquettes sont-elles migrées vers le nouvel emplacement ?
- La logique suivante permet de déterminer quelle section est lue et utilisée pour lire ou écrire des données d’étiquette.
| Action | Fonctionnalité non activée | Fonctionnalité activée |
|---|---|---|
| Lire | Étiquette dans custom.xml (non protégé) ou Doc SummaryInfo (protégé). | Si l’étiquette existe dans labelinfo.xml, il s’agit de l’étiquette effective. S’il n’existe aucune étiquette dans labelinfo.xml, l’étiquette dans custom.xml ou Doc SummaryInfo est l’étiquette effective. |
| Écrire | Toutes les nouvelles étiquettes sont écrites dans custom.xml (non protégé) ou Doc SummaryInfo (protégé). | Toutes les nouvelles étiquettes sont écrites dans labelinfo.xml. |
Analyse des fichiers
Question : Puis-je écrire dans le même fichier que celui que je lis actuellement avec le SDK File ?
Le SDK MIP ne prend pas en charge simultanément la lecture et l’écriture du même fichier. Tous les fichiers étiquetés créent une copie du fichier d’entrée avec les actions d’étiquette appliquées. Votre application doit remplacer l’original par le fichier étiqueté.
Gestion des chaînes par le SDK
Question : Comment le SDK gère-t-il les chaînes, et quel type de chaîne faut-il utiliser dans mon code ?
Le SDK est destiné à être utilisé sur plusieurs plateformes et utilise UTF-8 (Unicode Transformation Format - 8 bits) pour la gestion des chaînes. Les consignes précises dépendent de la plateforme que vous utilisez :
| Plateforme | Assistance |
|---|---|
| Windows natif | Pour les clients SDK C++, le type de bibliothèque standard C++ std::string est utilisé pour passer des chaînes vers/depuis des fonctions d’API. Le SDK MIP gère en interne la conversion vers/depuis UTF-8. Lorsqu’un std::string est retourné depuis une API, vous devez vous attendre à un encodage UTF-8 et gérer en conséquence l’éventuelle conversion de la chaîne. Dans certains cas, une chaîne est retournée dans le cadre d’un vecteur uint8_t (par exemple, une licence de publication (PL)), mais doit être traitée comme un objet blob opaque.Pour plus d’informations et d’exemples, consultez :
|
| .NET | Pour les clients SDK .NET, toutes les chaînes utilisent l’encodage UTF-16 par défaut et aucune conversion spéciale n’est nécessaire. Le SDK MIP gère en interne la conversion vers/depuis UTF-16. |
| autres plateformes | Toutes les autres plateformes prises en charge par le SDK MIP prennent en charge nativement UTF-8. |
Marquage du contenu
Question : Le SDK MIP prend-il en charge le marquage de contenu ?
Le SDK MIP ne prend pas en charge l’application directe du marquage de contenu, y compris l’en-tête, le pied de page ou le filigrane, sur aucun fichier. Lorsque les métadonnées d’étiquette sont écrites dans un fichier, le SDK File écrit la propriété de métadonnées contentBits pour indiquer que la protection a été appliquée (si configurée). Il n’écrit pas les propriétés qui indiquent que l’en-tête, le pied de page ou le filigrane ont été appliquées. Lorsque le fichier est ouvert dans une application, la configuration du marquage du contenu doit être évaluée par l’application et écrite dans le fichier lors de l’enregistrement.
SDK Protection and Policy sur Android
Question : Quelle bibliothèque partagée dois-je utiliser pour intégrer le SDK MIP dans mon application Android ?
Les fichiers binaires Android du SDK MIP incluent libmip_core.so, libmip_protection_sdk.so, libmip_upe_sdk.so et libmip_unified.so.
libmip_unified.so est la bibliothèque recommandée qui inclut les bibliothèques partagées de base, de protection et de stratégie.
Compatibilité
Question : Le SDL Microsoft Information Protection est-il conforme Federal Information Processing Standard (FIPS) 140-2 ?
Consultez Validation FIPS 140-2.
Informations de référence sur les problèmes et les erreurs
Erreur : « Format de fichier non pris en charge »
Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de la tentative de protection ou d’étiquetage d’un fichier PDF ?
Ce format de fichier n’est pas pris en charge
Cette exception résulte de la tentative de protection ou d’étiquetage d’un fichier PDF signé numériquement ou protégé par mot de passe. Consultez Nouvelle prise en charge du chiffrement PDF avec Microsoft Information Protection pour plus d’informations sur la protection et l’étiquetage des fichiers PDF.
Erreur : « NoPolicyException : la stratégie d’étiquette ne contenait pas de données »
Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de la tentative de lecture d’une étiquette ou d’une liste d’étiquettes via le SDK MIP ?
NoPolicyException : La stratégie des étiquettes ne contenait pas de données, CorrelationId=GUID, CorrelationId.Description=PolicyProfile, NoPolicyError.Category=SyncFile, NoPolicyError.Category=SyncFile
Cette erreur indique qu’une stratégie d’étiquette n’est pas publiée dans le portail Microsoft Purview. Suivez Créer et configurer des étiquettes de confidentialité et leurs stratégies pour configurer la stratégie des étiquettes.
Si une stratégie des étiquettes a été publiée, assurez-vous que le compte d’utilisateur est inclus dans tous les groupes qui font partie de la section published to de la configuration de la stratégie des étiquettes. Pour plus d’informations, consultez Créer et publier des étiquettes de confidentialité.
Les utilisateurs externes, y compris les utilisateurs invités, ne peuvent pas accéder aux stratégies d’étiquette d’une autre organisation. Pour prendre en charge ces utilisateurs, implémentez un mécanisme de nouvelle tentative. Si une exception NoPolicyException est levée, définissez la propriété FileEngineSettingsProtectionOnlyEngine sur true et réessayez la requête. Les opérations d’étiquetage ne seront pas disponibles pour cette instance IFileEngine, mais les opérations de protection seront disponibles.
Erreur : « System.ComponentModel.Win32Exception : Échec de LoadLibrary »
Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de l’utilisation du wrapper .NET du SDK MIP ?
System.ComponentModel.Win32Exception : Échec de LoadLibrary pour : [sdk_wrapper_dotnet.dll] lors de l’appel de MIP.Initialize().
Votre application ne dispose pas de l’environnement d'exécution requis ou n’a pas été générée en mode Release. Pour plus d’informations, consultez Vérifier que votre application a les dépendances requises .
Erreur : « ProxyAuthError exception »
Question : Pourquoi est-ce que j’obtiens l’erreur suivante lors de l’utilisation du SDK MIP ?
« ProxyAuthenticatonError : l’authentification proxy n’est pas prise en charge »
Le SDK MIP ne prend pas en charge l’utilisation de proxys authentifiés. Pour résoudre ce problème, les administrateurs du proxy doivent définir les points de terminaison de service Information Protection Microsoft Purview pour contourner le proxy. Une liste de ces points de terminaison est disponible sur la page URL et plages d’adresses IP Office 365. Le SDK MIP nécessite que *.protection.outlook.com (ligne 9) et les points de terminaison de service Microsoft Purview Information Protection (ligne 73) contournent l’authentification proxy.
Erreur : « Erreur inconnue » lors de l’étiquetage d’un fichier image avec une sortie de flux
Question : Pourquoi est-ce que j’obtiens une « erreur inconnue » quand j’essaie d’ajouter ou de supprimer une étiquette ou une protection d’un type de fichier image avec un flux de sortie ?
Lorsque vous utilisez un flux de sortie, le flux doit avoir à la fois un accès en lecture et en écriture pour modifier l’étiquette ou la protection d’un fichier image.
Limitations
Question : Existe-t-il des limitations basées sur le service lors de l’utilisation du SDK MIP ?
Le service Rights Management, utilisé par le SDK de protection ou les opérations de protection dans le Kit de développement logiciel (SDK) Fichier, a une limite de 7 500 requêtes par 10 secondes pour toute une organisation. Autrement dit, si l’application A génère 4 000 requêtes en 10 secondes et que l’application B dans la même organisation génère 4 000 requêtes en 10 secondes, les deux applications peuvent commencer à recevoir des réponses HTTP 429 Too Many Requests. Les développeurs doivent implémenter une période d’interruption lorsque ces exceptions sont reçues. Les futures versions du SDK MIP implémentent en interne cette période d’interruption.