Partager via


Fichiers manifeste XML

L’API de migration s’appuie sur les fichiers manifeste XML pour traiter correctement l’importation de contenu. Create les fichiers manifeste dans un format bien défini. L’API AMR exporte également les métadonnées dans ce format.

XML Validation

La structure de package pour les fichiers manifeste est basée sur une version contrainte des schémas de migration de contenu SharePoint.

Encodage de caractères XML non valides

L’API AMR encode des caractères XML non valides dans les champs. Décodez les attributs répertoriés dans EncodedAttributes.

L’API de migration ne prend pas en charge l’encodage de caractères XML non valide.

Exemple

Dans cet exemple, ces attributs sont encodés : URL, ParentWebURL, Name et Version.

<File Url="testlib_x002F_File_0905-1653-31240"
      Id="e72e2015-91a4-4d07-ae9a-7b6c76918d2a"
      ParentWebId="7206fc09-e4af-48b3-8730-ed7321396d7a"
      ParentWebUrl="_x002F_"
      Name="File_0905-1653-31240"
      ListItemIntId="3"
      ListId="48ea9454-9538-47ae-926d-917df80bc93e"
      ParentId="33ff2f12-c818-4c8d-8578-c6d057172fd8"
      ScopeId="385cd4d5-86da-4183-bdac-2e83da1b05fc"
      TimeCreated="2021-11-08T03:57:05"
      TimeLastModified="2021-01-17T16:01:48"
      Version="_x0031_.0"
      FileSize="1"
      Level="1"
      EncodedAttributes="Url,ParentWebUrl,Name,Version">

Emplacement

Placez tous les fichiers manifeste au niveau racine du conteneur Stockage Blob Azure pour les fichiers manifestes.

ArchivedFiles.xml

Optional.

Utilisé pour traiter les petits fichiers archivés par lots.

exemple ArchivedFiles.xml

<?xml version="1.0" encoding="utf-8"?>
<ArchivedFiles>
  <ArchivedFile Name="pack0.zip" Checksum="xxxxxx=">
    <File FileValue="01.dat" />
    <File FileValue="02.dat" />
    <File FileValue="03.dat" />
    <File FileValue="04.dat" />
    <File FileValue="05.dat" />
    <File FileValue="06.dat" />
 </ArchivedFile>
  <ArchivedFile Name="pack1.zip" Checksum="xxxxxx=">
    <File FileValue="07.dat" />
    <File FileValue="08.dat" />
    <File FileValue="09.dat" />
    <File FileValue="10.dat" />
    <File FileValue="11.dat" />
    <File FileValue="12.dat" />
  </ArchivedFile>
</ArchivedFiles>

ExportSettings.xml

Obligatoire.

Un fichier XML contient les paramètres d’exportation spécifiés avec les SPExportSettings classes et . Il spécifie également les paramètres d’exportation, utilisés dans le processus d’importation suivant sur le site cible de migration. Il gère également un catalogue de tous les objets exportés vers le package de migration.

Ignorer les composants WebPart

L’API de migration vérifie et traite les composants WebPart SharePoint dans certains types de fichiers. Pour les sources autres que SharePoint Server et SharePoint Online, ignorez ces vérifications en définissant sur IgnoreWebPartstrue. Cette pratique améliore les performances des tâches de migration lorsqu’il n’y a pas de migration de composants WebPart.

Spécifier la source de contenu

L’API de migration nécessite une SourceType valeur contenant la source du contenu. Il doit contenir une valeur de la liste suivante :

Valeurs acceptées SourceType

  • AmazonS3
  • AzureStorage
  • Box
  • Dropbox
  • Egnyte
  • FileShare
  • GoogleCloudStorage
  • GoogleDrive
  • MicrosoftStream
  • OneDrive
  • SharePointOnline
  • SharePointOnPremServer
  • Other

Lors de la déclaration à Other, incluez une valeur supplémentaire DetailedSource pour fournir plus de détails sur les informations de source de contenu.

exemple ExportSettings.xml

<ExportSettings xmlns="urn:deployment-exportsettings-schema" SiteUrl="https://url" FileLocation="some paths" IncludeSecurity="All" SourceType="Other" DetailedSource="My special source type not in the list">
  <ExportObjects>
    <DeploymentObject Id="GUID for list" Type="List" ParentId="GUID for web" />
  </ExportObjects>
</ExportSettings>

LookupListMap.xml

Optional.

Fichier manifeste XML qui gère une liste de choix simple, qui enregistre toutes les références d’élément de liste SharePoint. Placez-le à la racine du conteneur de magasin d’objets blob Azure défini par le CreateMigrationJobparamètre de azureContainerManifestUri .

Non obligatoire si le package d’importation ne contient pas définition de champs ou de vues sur une liste ou une bibliothèque de documents. L’omission de ce fichier génère un message d’avertissement dans le journal. Incluez un fichier avec un nœud sans root enfant pour éviter ce message d’avertissement.

Manifest.xml

Obligatoire.

Fichier manifeste XML qui contient la liste complète du contenu et de la structure du package de contenu. L’API de migration utilise ce fichier manifeste pour reconstituer la source et ses composants.

Placez toutes les instances du fichier Manifest.xml pour un package à la racine du conteneur de magasin d’objets blob Azure.

Ce fichier manifeste est également le descripteur principal pour les métadonnées dans le package et fournit la hiérarchie List, Folder et Item, ainsi que les métadonnées pour les éléments, y compris les références aux utilisateurs et aux groupes définis dans UserGroupMap.xml fichier.

Utilisez plusieurs Manifest.xml si nécessaire. Les manifestes sont identifiés par des noms de fichiers différents. L’API de migration localise tous les manifestes via des références dans SystemData.xml entrées du ManifestFile fichier.

Cohérence de la bibliothèque de documents/id de liste

Utilisez l’ID web et l’ID de la bibliothèque de documents/id de liste cohérents au niveau de la source et de l’emplacement cible. Les ID web incohérents génèrent des erreurs, car l’API de migration ne peut pas trouver le site web parent pour l’opération d’importation.

De même, l’API de migration ne peut pas importer des éléments avec des ID de bibliothèque de documents et des ID de liste incorrects dans la bibliothèque de documents ou la liste cible. Ne réutilisez pas les ID au sein de la même collection de sites pour éviter que l’API de migration n’importe des packages dans la même collection de sites cible, quel que soit le site web de destination.

Cohérence GUID

Pour éviter les conflits GUID et les erreurs d’importation, utilisez le même package pour la même cible. L’importation d’un nouveau package avec le même contenu entraîne des problèmes. Le package d’un partage de fichiers affecte des GUID aux fichiers, dossiers et éléments de liste. Conservez le package du partage de fichiers en tant qu’enregistrement des GUID d’origine. Utilisez les mêmes GUID pour les packages ultérieurs afin d’éviter les conflits et de suivre les modifications.

Conserver les identificateurs de contenu

Les identificateurs dans les packages d’importation sont explicitement utilisés lors de l’importation pour identifier le contenu. Cette pratique conserve les identificateurs existants pour le contenu de la bibliothèque de documents.

Référencez explicitement les identificateurs Web et List cibles.

L’API de migration conserve les identificateurs de type de contenu, les GUID d’élément de fichier/dossier et les identificateurs d’entiers d’éléments de liste lors de l’importation. L’importation échoue lorsque l’API de migration rencontre des identificateurs incorrects dans le package.

Cette conservation permet des itérations d’importation successives avec différents packages, ce qui permet aux éléments de déplacer des emplacements.

Rôles d’autorisation

Manifest.xml contient les objets liés aux rôles suivants :

Objet Roles

Contient la liste de tous les rôles définis sur le web.

Objet Role

Définit un rôle avec UN ID, des indicateurs de masque de droits d’autorisation internes et des informations d’affichage.

Valeur RoleId

Définit les identificateurs de l’objet Role.

Valeur PermMask

Contient les indicateurs de masque de droits.

Objet RoleAssignments

Contient la liste de toutes les autorisations uniques (objets RoleAssignment).

Objet RoleAssignment

Inclut la liste des objets Assignment distincts (le cas échéant).

Objet Assignment

Contient l’appartenance réelle d’un utilisateur ou d’un groupe distinct et son rôle réel, où

  • Les valeurs RoleId mappent aux valeurs RoleId des objets de rôle.
  • Les valeurs PrincipalId sont mappées aux valeurs d’ID des objets User ou Group respectivement dans UserGroups.xml.

Exemple d’autorisations

<SPObjects xmlns="urn:deployment-manifest-schema">
  …
  <SPObject Id="0b3c1b13-b260-453c-ac8d-8053a537d610" ObjectType="DeploymentRoles" ParentId="203e30e2-1139-4adf-b545-e74235f105c2" ParentWebId="203e30a2-1139-4acf-b535-e74235f105c2" ParentWebUrl="/teams/temp">
    <Roles>
      <Role RoleId="1073751825" Title="Test Role" Description="This is a test role" PermMask="206292717568" Hidden="true" RoleOrder="160" Type="1" />
      <Role RoleId="1073751826" Title="Test Role 2" Description="This is another test role" PermMask="756052856929" Hidden="false" RoleOrder="128" Type="2" />
      …
    </Roles>
  </SPObject>
  <SPObject Id="373ea0ba-107a-4a78-9563-bc642f9ab14d" ObjectType="DeploymentRoleAssignments" ParentId="203e30e2-1139-4adf-b545-e74235f105c2" ParentWebId="203e30a2-1139-4acf-b535-e74235f105c2" ParentWebUrl="/teams/temp">
    <RoleAssignments>
      <RoleAssignment ScopeId="ffcab9b9-94ef-4701-e6d9-19a370760e1e" RoleDefWebId="203e11c2-1139-4abe-b534-e74235f106c2" RoleDefWebUrl="teams/temp" ObjectId="9f743aaf-65f9-473e-0c37-37f147960560" ObjectType="1" ObjectUrl="teams/temp/IWConvertedForms" AnonymousPermMask="0" />
      <RoleAssignment ScopeId="c3f564f3-62cd-4b25-8da4-2da7722402ab" RoleDefWebId="203e30a2-1139-4acf-b535-e74255e105c2" RoleDefWebUrl="teams/temp" ObjectId="2b9b0a32-51fb-4af8-a218-c90f63fd1de4" ObjectType="1" ObjectUrl="teams/temp/Relationships List" AnonymousPermMask="0">
        <Assignment RoleId="1073751825" PrincipalId="5" />
        <Assignment RoleId="1073751825" PrincipalId="6" />
        <Assignment RoleId="1073751826" PrincipalId="4" />
        <Assignment RoleId="1073751828" PrincipalId="1" />
      </RoleAssignment>
      …
    </RoleAssignments>
  </SPObject>
  …
</SPObjects>

Requirements.xml

Optional.

SharePoint Server génère généralement ce fichier manifeste XML. Il contient une liste des exigences de déploiement sous la forme d’exigences d’installation sur la cible de migration, telles que

  • définitions de caractéristiques
  • versions de modèle
  • Assemblys de composants WebPart
  • modules linguistiques
  • et ainsi de suite.

N’incluez aucun nœud enfant sous la racine pour les partages de fichiers. L’omission de ce fichier génère un message d’avertissement dans le journal.

RootObjectMap.xml

Optional.

Gère une liste de mappages d’objets secondaires (dépendants). L’API de migration utilise ce fichier manifeste pour placer correctement les objets dépendants.

Le plus courant RootObject inclus est un objet unique de type List. Le ID de cet élément doit être la liste ID de la liste cible, et le ParentWebID doit correspondre au ID du site web cible parent contenant cette liste pour que la migration réussisse. Les IDvaleurs , WebUrlet Url de cet objet doivent également correspondre à la structure associée disposée dans le fichier Manifest.xml .

SystemData.xml

Obligatoire.

Contient diverses données système de bas niveau. Il enregistre également le nombre et les chemins d’accès des fichiersManifest.xmldans le package de manifeste, lorsqu’il existe plusieurs manifestes.

Versions

SchemaVersion références au actuel Build et DatabaseVersion à la batterie de serveurs cible, actuellement « 15.0.0.0 ».

SiteVersion doit correspondre à la collection de UIVersionsites cible , actuellement 15.

Manifestes multiples

Répertoriez tous les fichiers Manifest.xml du package dans SystemData.xml, en tant qu’entrées ManifestFile .

SystemObjects immuables

Répertorie tous les SystemObjects objets dépendants définissant qui restent immuables par l’API de migration.

SystemData.xml exemple

Cet exemple SystemData.xml fichier montre les objets communs d’une importation de partage de fichiers. Utilisez des s différents IDpour chaque package, et les URLs peuvent être différents.

<?xml version="1.0" encoding="utf-8"?>
<SystemData xmlns="urn:deployment-systemdata-schema">
  <SchemaVersion Version="15.0.0.0" Build="16.0.3111.1200" DatabaseVersion="11552" SiteVersion="15" />
  <ManifestFiles>
    <ManifestFile Name="Manifest.xml" />
  </ManifestFiles>
  <SystemObjects>
    <SystemObject Id="34321c39-3254-4bd1-b749-c99e16d1f4ab" Type="Folder" Url="/personal/username" />
    <SystemObject Id="9efb9686-baab-432d-a192-858ac34c073f" Type="Web" Url="/personal/username" />
    <SystemObject Id="e8ec714f-91a0-4c6f-9926-08328c8b3e05" Type="List" Url="/personal/username/Documents/deleteme2" />
    <SystemObject Id="a05e1f95-5712-4cc2-958c-31cf0a2cfb62" Type="List" Url="/personal/username/_catalog/users" />
  </SystemObjects>
  <RootWebOnlyLists />
</SystemData>

UserGroupMap.XML

Obligatoire.

Enregistre les utilisateurs et les groupes de sécurité d’utilisateurs pour la gestion des autorisations. L’API de migration utilise le manifeste pour vérifier l’appartenance des utilisateurs et des groupes, ainsi que leurs rôles et affectations spécifiques. Ces affectations incluent des autorisations uniques définies au niveau de l’objet et de sa descendance, sauf si un objet enfant plus profond les remplace.

Les entrées utilisateur ou groupe ne sont pas obligatoires, mais l’omission empêche l’auteur ou les informations de sécurité de la population lors de l’importation. L’API de migration génère des avertissements dans de tels cas.

Identificateurs d’utilisateur

Identifiez un utilisateur une seule fois dans un seul package.

Manifestez tous les utilisateurs et groupes dans le ou les sites Web exportés.

User, objet

Inclut les informations sur des utilisateurs spécifiques, notamment l’identification d’un principe de sécurité spécifique en tant que groupe de domaines ou non, la connexion et le SiD (SystemId) codé en base64 du principe de sécurité.

Group, objet

Inclut les informations sur des groupes spécifiques et la liste d’appartenances directes de ce groupe.

Les valeurs de propriétaire sur les objets Group et les valeurs UserId sur les objets membres dans les objets groupe sont mappées à d’autres valeurs d’ID d’autres objets User ou Group, respectivement.

L’exemple suivant montre comment manifester des utilisateurs et des groupes.

<UserGroupMap xmlns="urn:deployment-usergroupmap-schema">
  <Users>
    <User Id="1" Name="John Doe" Login="DOMAIN\JDoe" Email="DJoe@contoso.com"
    IsDomainGroup="false" IsSiteAdmin="true" SystemId="AQUAAAAAAAUVAAAAXSj1f9U62DVDVOAqToYSAA==" IsDeleted="false" Flags="0" />
    <User Id="2" Name="Jane Smith" Login="DOMAIN\JSmith" Email="jsmith@contoso.com"
    IsDomainGroup="false" IsSiteAdmin="true" SystemId="AQUAAAAAAAUVAAAAXSj1f9U62DVDVOAqdUwNAA==" IsDeleted="false" Flags="0" />
    …
  </Users>
  <Groups>
    <Group Id="3" Name="Temp Group" Description="A Temp Group" Owner="2" OwnerIsUser="true" OnlyAllowMembersViewMembership="true">
      <Member UserId="2" />
    </Group>
    <Group Id="4" Name="Temp Group 2" Description="Another Temp Group" Owner="2" OwnerIsUser="false" RequestToJoinLeaveEmailSetting="JSmith@contoso.com" OnlyAllowMembersViewMembership="true">
      <Member UserId="1" />
      <Member UserId="2" />
    </Group>
    …
  </Groups>
</UserGroupMap>

Assurez-vous que les valeurs Sign-in et SystemId des utilisateurs correspondent aux valeurs de SharePoint.

Utilisateurs supprimés

Incluez une IsDeleted valeur comme true pour les comptes supprimés. Cette pratique empêche les échecs de recherche dans le processus d’importation, ce qui a un impact négatif sur les performances.

Identificateurs d’utilisateur non résolus

Si l’API de migration ne parvient pas à résoudre un utilisateur avec les informations de connexion et que SystemId n’est pas fourni, l’API de migration remplace cet utilisateur par System Account dans les métadonnées associées (telles que Author ou Rédacteur) dans le package et génère un avertissement dans les journaux d’importation :

Failed to ensure user 'user@contoso.com'

Si l’API de migration ne parvient pas à résoudre un utilisateur avec la connexion alors que SystemId est fourni, l’API de migration crée un utilisateur supprimé avec la connexion et l’id système fournis. L’API de migration utilise cet utilisateur avec les métadonnées associées dans le package. L’API de migration génère un avertissement dans les journaux d’importation :

Failed to retrieve user 'user@contoso.com' attributes from the SiteUsers; falling back to passed in values

Éviter les adresses e-mail non UPN dans les identificateurs d’utilisateur

L’attribut Login de l’identificateur d’utilisateur nécessite un UPN. N’utilisez pas d’adresses e-mail non UPN. L’utilisation d’adresses e-mail non UPN entraîne un comportement inattendu dans SharePoint Online.

Exemples

Les exemples suivants montrent les méthodes correctes et incorrectes d’utilisation des identificateurs d’utilisateur.

Dans ce cas, l’utilisateur a les identificateurs suivants :

Exemple correct

Cet exemple montre comment manifester l’utilisateur une seule fois, avec une adresse e-mail UPN.

<User Id="1" Login="i:0#.f|membership|robert@contoso.com" …/>

Exemple incorrect

Cet exemple utilise incorrectement une adresse e-mail non UPN et inclut de manière incorrecte plusieurs identificateurs pour un seul utilisateur.

<User Id="1" Login="i:0#.f|membership|robert@contoso.com" …/>
<User Id="2" Login="i:0#.f|membership|robert.downey@contoso.com" …/>

Cet exemple utilise incorrectement une adresse e-mail non UPN.

<User Id="2" Login="i:0#.f|membership|robert.downey@contoso.com" …/>

ViewformsList.xml

Optional.

Ce fichier manifeste XML gère une liste de composants WebPart et indique si chacun est un affichage ou un formulaire.

Ce fichier est facultatif si le package d’importation ne contient pas de composants WebPart. L’omission de ce fichier génère un message d’avertissement dans le journal. Vous pouvez également inclure un fichier manifeste avec un nœud sans root enfant pour éviter le message d’avertissement.