Bibliothèque d’éléments XML

Cet article décrit les éléments XML et les fonctions d’assistance qui peuvent être utilisés pour créer des fichiers de migration.xml à utiliser avec l’outil de migration d’état utilisateur (USMT). Cet article suppose une connaissance de base du code XML.

En plus des éléments XML et des fonctions d’assistance, cet article :

  • Décrit comment spécifier des emplacements et des modèles d’emplacements encodés.
  • Fonctions destinées à une utilisation usMT interne uniquement.
  • Balises de version qui peuvent être utilisées avec les fonctions d’assistance.

Éléments et fonctions d’assistance

Le tableau suivant décrit les éléments XML et les fonctions d’assistance qui peuvent être utilisés avec USMT.

Éléments A-K Éléments L-Z Fonctions d’assistance
<addObjects>
<Attributs>
<Octets>
<commandLine>
<composant>
<condition>
<conditions>
<contenu>
<contentModify>
<description>
<destinationCleanup>
<détecter>
<Détecte>
<détection>
<displayName>
<environnement>
<exclure>
<excludeAttributes>
<Extensions>
<extension>
<externalProcess>
<icon>
<include>
<includeAttribute>
<bibliothèque>
<emplacement>
<locationModify>
<_locDefinition>
<fabricant>
<fusionner>
<migration>
<namedElements>
<object>
<objectSet>
<chemin>
<Chemins>
<motif>
<traitement>
<plug-in>
<rôle>
<règlement>
<script>
<SMS>
<unconditionalExclude>
<variable>
<Version>
<windowsObjects>
<fonctions de condition>
<fonctions de contenu>
<fonctions contentModify>
<inclure> et <exclure> des fonctions de filtre
<locationModify> , fonctions
<fonctions de fusion>
<fonctions de script>
Fonctions USMT internes

<addObjects>

L’élément< addObjects> émule l’existence d’un ou plusieurs objets sur l’ordinateur source. Les éléments d’objet> enfant< fournissent les détails des objets émulés. Si le contenu est un <élément de script> , le résultat de l’appel est un tableau d’objets.

Syntaxe:

<addObjects>
</addObjects>

L’exemple suivant provient du MigApp.xml fichier :

<addObjects>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [UpgradeVersion]</location>
      <attributes>DWORD</attributes>
      <bytes>0B000000</bytes>
   </object>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [Lang]</location>
      <attributes>DWORD</attributes>
      <bytes>00000000</bytes>
   </object>
</addObjects>

<Attributs>

L’élément <attributes> définit les attributs d’une clé ou d’un fichier de Registre.

  • Nombre d’occurrences : une fois pour chaque <objet>

  • Éléments parents :<object>

  • Éléments enfants : aucun

Syntaxe:

<attributes>Content</attributes>
Paramètre Obligatoire ? Valeur
Contenu Oui Le contenu dépend du type d’objet spécifié.
  • Pour les fichiers, le contenu peut être une chaîne contenant l’un des attributs suivants séparés par des virgules :
    • Archive
    • Lecture seule
    • Système
    • Hidden
  • Pour les clés de Registre, le contenu peut être de l’un des types suivants :
    • Aucun(e)
    • Chaîne
    • ExpandString
    • Binaire
    • Dword
    • REG_SZ

L’exemple suivant provient du MigApp.xml fichier :

<object>
   <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [Lang]</location>
   <attributes>DWORD</attributes>
   <bytes>00000000</bytes>
</object> 

<Octets>

L’élément <bytes> ne peut être spécifié que pour les fichiers, car, si <l’emplacement> correspond à une clé de Registre ou à un répertoire, <les octets sont ignorés> .

  • Nombre d’occurrences : zéro ou une

  • Éléments parents :<object>

  • Éléments enfants : aucun

Syntaxe:

<bytes string="Yes|No" expand="Yes|No">Content</bytes>
Paramètre Obligatoire ? Valeur
chaîne Non, la valeur par défaut est Non Détermine si le contenu doit être interprété comme une chaîne ou comme des octets.
expand Non (valeur par défaut = Oui Lorsque le paramètre expand a la valeur Oui, le contenu de l’élément <bytes> est d’abord développé dans le contexte de l’ordinateur source, puis interprété.
Contenu Oui Dépend de la valeur de la chaîne.
  • Lorsque la chaîne a la valeur Oui : le contenu de l’élément <bytes> est interprété comme une chaîne.
  • Lorsque la chaîne a la valeur Non : le contenu de l’élément <bytes> est interprété comme des octets. Tous les deux caractères représentent la valeur hexadécimale d’un octet. Par exemple, 616263 est la représentation de la abc chaîne ANSI. Une représentation complète de la chaîne abc UNICODE, y compris la marque de fin de chaîne serait : 6100620063000000.

L’exemple suivant provient du MigApp.xml fichier :

<object>
   <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [Lang]</location>
   <attributes>DWORD</attributes>
   <bytes>00000000</bytes>
</object> 

<commandLine>

L’élément< commandLine> peut être utilisé pour démarrer ou arrêter un service ou une application avant ou après l’exécution des outils ScanState et LoadState.

  • Nombre d’occurrences : illimité

  • Éléments parents :<externalProcess>

  • Éléments enfants : aucun

Syntaxe:

<commandLine>CommandLineString</commandLine>
Paramètre Obligatoire ? Valeur
CommandLineString Oui Ligne de commande valide.

<composant>

L’élément <component> est requis dans un fichier .xml personnalisé. Cet élément définit la construction la plus simple d’un fichier de.xml de migration. Par exemple, dans le MigApp.xml fichier, Microsoft Office 2016 est un composant qui contient un autre composant, Microsoft Office Access 2016. Les éléments enfants peuvent être utilisés pour définir le composant.

Un composant peut être imbriqué à l’intérieur d’un autre composant ; autrement dit, l’élément <component> peut être un enfant de l’élément <role> dans l’élément <component> dans deux cas :

  1. Lorsque l’élément de composant> parent< est un conteneur
  2. Si l’élément de composant> enfant< a le même rôle que l’élément de composant> parent<.

Syntaxe:

<component type="System|Application|Device|Documents" context="User|System|UserAndSystem" defaultSupported="TRUE|FALSE|YES|NO"
hidden="Yes|No">
</component>
Paramètre Obligatoire ? Valeur
type Oui Les éléments suivants peuvent être utilisés pour regrouper les paramètres et définir le type du composant.
  • Système: Paramètres du système d’exploitation. Tous les composants Windows sont définis par ce type.
    Lorsque type="System » et defaultSupported="FALSE », les paramètres ne migrent pas, sauf s’il existe un composant équivalent dans les fichiers .xml spécifié sur la LoadState.exe ligne de commande. Par exemple, le fichier par défaut MigSys.xml contient des composants avec type="System » et defaultSupported="FALSE ». Si ce fichier est spécifié sur la ScanState.exe ligne de commande, le fichier doit également être spécifié sur la LoadState.exe ligne de commande pour que les paramètres soient migrés. Le fichier doit être spécifié, car l’outil LoadState.exe doit détecter un composant équivalent. Autrement dit, le composant doit avoir le même URLID de migration que le fichier .xml et un nom d’affichage identique. Sinon, l’outil LoadState ne migre pas ces paramètres à partir du magasin. Ce paramètre est utile, car un magasin peut être utilisé pour les ordinateurs de destination qui sont la même ou une version différente de Windows que l’ordinateur source.
  • Application: Paramètres d’une application.
  • Appareil: Paramètres d’un appareil.
  • Documents: Spécifie les fichiers.
contexte Non
Valeur par défaut = UserAndSystem
Définit l’étendue de ce paramètre ; autrement dit, s’il faut traiter ce composant dans le contexte de l’utilisateur spécifique, sur l’ensemble du système d’exploitation, ou les deux.
La plus grande étendue possible est définie par l’élément component<>. Par exemple, si un <élément de composant> a un contexte Utilisateur et qu’un <élément rules> a un contexte UserAndSystem, l’élément <rules> agit comme s’il avait un contexte Utilisateur. Si un <élément rules> a un contexte de System, il agirait comme si l’élément <rules> n’y était pas.
  • Utilisateur : évalue le composant pour chaque utilisateur.
  • Système : évalue le composant une seule fois pour le système.
  • UserAndSystem : évalue le composant pour l’ensemble du système d’exploitation et pour chaque utilisateur.
defaultSupported Non
(valeur par défaut = TRUE)
Il peut s’agir de l’une des valeurs TRUE, FALSE, YES ou NON. Si ce paramètre a la valeur FALSE (ou NO), le composant n’est pas migré, sauf s’il existe un composant équivalent sur l’ordinateur de destination.
Lorsque type="System » et defaultSupported="FALSE », les paramètres ne sont pas migrés, sauf s’il existe un composant équivalent dans les fichiers .xml spécifiés sur la LoadState.exe ligne de commande. Par exemple, le fichier par défaut MigSys.xml contient des composants avec type="System » et defaultSupported="FALSE ». Si ce fichier est spécifié sur la ScanState.exe ligne de commande, le fichier doit également être spécifié sur la LoadState.exe ligne de commande pour que les paramètres soient migrés. Le fichier doit être spécifié dans les deux lignes de commande, car l’outil LoadState doit détecter un composant équivalent. Autrement dit, le composant doit avoir le même URLID de migration que le fichier .xml et un nom d’affichage identique, sinon l’outil LoadState ne migre pas ces paramètres à partir du magasin. Ce paramètre est utile, car un magasin peut être utilisé pour les ordinateurs de destination qui sont la même ou une version différente de Windows que l’ordinateur source.
caché Ce paramètre est destiné à une utilisation usMT interne uniquement.

Pour obtenir un exemple, consultez les fichiers de migration.xml par défaut.

<condition>

Bien que l’élément <condition> sous les <éléments detect>, <objectSet> et <addObjects> soit toujours pris en charge, Microsoft recommande de ne plus utiliser l’élément <condition> , car il peut être déprécié dans les versions futures d’USMT. Si l’élément <condition> est déconseillé, il nécessite une réécriture de tous les scripts qui utilisent l’élément <condition> . Au lieu de cela, si une condition doit être utilisée dans les <éléments objectSet> et <addObjects>, Microsoft recommande d’utiliser l’élément conditions> plus puissant<. L’élément< conditions> permet la formulation d’instructions booléennes complexes.

L’élément< condition> a un résultat booléen. Cet élément peut être utilisé pour spécifier les conditions dans lesquelles l’élément parent est évalué. Si l’une des conditions actuelles retourne FALSE, l’élément parent n’est pas évalué.

  • Nombre d’occurrences : illimité.

  • Éléments parents :<conditions>, <detect>, <objectSet>, <addObjects>

  • Éléments enfants : aucun

  • Fonctions d’assistance : Les fonctions de condition> suivantes< peuvent être utilisées avec cet élément : DoesOSMatch, IsNative64Bit(), IsOSEarlierThanIsOSLaterThan, , DoesObjectExist, IsFileVersionAboveIsFileVersionBelowDoesFileVersionMatchIsSystemContext, DoesStringContentEqual, DoesStringContentContain, IsSameObject, IsSameContent, et .IsSameStringContent

Syntaxe:

<condition negation="Yes|No">ScriptName</condition>
Paramètre Obligatoire ? Valeur
négation Non
Valeur par défaut = Non
« Oui » inverse la valeur True/False de la condition.
ScriptName Oui Script défini dans cette section de migration.

Par exemple, dans l’exemple de code suivant, les <éléments de condition>, A et B, sont joints par l’opérateur AND, car ils se trouvent dans des sections de conditions> distinctes< :

<detection>
   <conditions>
      <condition>A</condition>
   </conditions>
   <conditions operation="AND">
      <condition>B</condition>
   </conditions>
</detection>

Toutefois, dans l’exemple de code suivant, les <éléments de condition>, A et B, sont joints par l’opérateur OR, car ils se trouvent dans la même <section conditions>.

<detection>
   <conditions>
      <condition>A</condition>
      <condition>B</condition>
   </conditions>
</detection>

<fonctions de condition>

Les <fonctions de condition> retournent une valeur booléenne. Ces éléments peuvent être utilisés dans <des conditions addObjects> .

Fonctions de version du système d’exploitation

  • DoesOSMatch

    Toutes les correspondances ne respectent pas la casse.

    Syntaxe: DoesOSMatch("OSType","OSVersion")

    Paramètre Obligatoire ? Valeur
    OSType Oui La seule valeur valide pour ce paramètre est NT. Toutefois, ce paramètre doit être défini pour que les fonctions de <condition> fonctionnent correctement.
    OSVersion Oui La version principale, la version mineure, le numéro de build et la version de la disquette de service corrigée, séparés par des points. Exemple : 5.0.2600.Service Pack 1. La spécification partielle de la version peut également être spécifiée avec un modèle tel que 5.0.*.

    Exemple :

    <condition>MigXmlHelper.DoesOSMatch("NT","\*")</condition>
    
  • IsNative64Bit

    La fonction IsNative64Bit retourne TRUE si le processus de migration s’exécute en tant que processus natif 64 bits ; autrement dit, un processus s’exécutant sur un système 64 bits sans Windows sur Windows (WOW). Sinon, elle retourne FALSE.

  • IsOSLaterThan

    Toutes les comparaisons ne respectent pas la casse.

    Syntaxe: IsOSLaterThan("OSType","OSVersion")

    Paramètre Obligatoire ? Valeur
    OSType Oui Peut être 9x ou NT. Si OSType ne correspond pas au type du système d’exploitation actuel, il retourne FALSE. Par exemple, si le système d’exploitation actuel est basé sur Windows NT et que OSType a la valeur « 9x », le résultat est FALSE.
    OSVersion Oui La version principale, la version mineure, le numéro de build et la version de la disquette de service corrigée, séparées par des points. Exemple : 5.0.2600.Service Pack 1. La spécification partielle de la version peut également être spécifiée, mais aucun modèle n’est autorisé comme 5.0.

    La fonction IsOSLaterThan retourne TRUE si le système d’exploitation actuel est supérieur ou égal à OSVersion.

    Par exemple :

    <condition negation="Yes">MigXmlHelper.IsOSLaterThan("NT","6.0")</condition>
    
  • IsOSEarlierThan

    Toutes les comparaisons ne respectent pas la casse.

    Syntaxe: IsOSEarlierThan("OSType","OSVersion")

    Paramètre Obligatoire ? Valeur
    OSType Oui Peut être 9x ou NT. Si OSType ne correspond pas au type du système d’exploitation actuel, il retourne FALSE. Par exemple, si le système d’exploitation actuel est basé sur Windows NT et que OSType a la valeur « 9x », le résultat est FALSE.
    OSVersion Oui La version principale, la version mineure, le numéro de build et la version de la disquette de service corrigée, séparées par des points. Exemple : 5.0.2600.Service Pack 1. La spécification partielle de la version peut également être spécifiée, mais aucun modèle n’est autorisé comme 5.0.

    La fonction IsOSEarlierThan retourne TRUE si le système d’exploitation actuel est antérieur à OSVersion.

Fonctions de contenu d’objet

  • DoesObjectExist

    La fonction DoesObjectExist retourne TRUE s’il existe un objet qui correspond au modèle d’emplacement. Sinon, elle retourne FALSE. Le modèle d’emplacement est développé avant de tenter l’énumération.

    Syntaxe: DoesObjectExist("ObjectType","EncodedLocationPattern")

    Paramètre Obligatoire ? Valeur
    ObjectType Oui Définit le type d’objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocationPattern Oui Modèle d’emplacement. Les variables d’environnement sont autorisées.

    Pour obtenir un exemple de cet élément, consultez le MigApp.xml fichier .

  • DoesFileVersionMatch

    La vérification du modèle ne respecte pas la casse.

    Syntaxe: DoesFileVersionMatch("EncodedFileLocation","VersionTag","VersionValue")

    Paramètre Obligatoire ? Valeur
    EncodedFileLocation Oui Modèle d’emplacement pour le fichier qui est vérifié. Les variables d’environnement sont autorisées.
    VersionTag Oui Valeur de la balise de version cochée.
    VersionValue Oui Modèle de chaîne. Par exemple, « Microsoft* ».

    Par exemple :

    <condition>MigXmlHelper.DoesFileVersionMatch("%MSNMessengerInstPath%\\msnmsgr.exe","ProductVersion","6.\*")</condition>   <condition>MigXmlHelper.DoesFileVersionMatch("%MSNMessengerInstPath%\\msnmsgr.exe","ProductVersion","7.\*")</condition>
    
  • IsFileVersionAbove

    La fonction IsFileVersionAbove retourne TRUE si la version du fichier est supérieure à VersionValue.

    Syntaxe: IsFileVersionAbove("EncodedFileLocation","VersionTag","VersionValue")

    Paramètre Obligatoire ? Valeur
    EncodedFileLocation Oui Modèle d’emplacement pour le fichier qui est vérifié. Les variables d’environnement sont autorisées.
    VersionTag Oui Valeur de la balise de version cochée.
    VersionValue Oui Valeur à laquelle comparer. Un modèle ne peut pas être spécifié.
  • IsFileVersionBelow

    Syntaxe: IsFileVersionBelow("EncodedFileLocation","VersionTag","VersionValue")

    Paramètre Obligatoire ? Valeur
    EncodedFileLocation Oui Modèle d’emplacement pour le fichier qui est vérifié. Les variables d’environnement sont autorisées.
    VersionTag Oui Valeur de la balise de version cochée.
    VersionValue Oui Valeur à laquelle comparer. Un modèle ne peut pas être spécifié.
  • IsSystemContext

    La fonction IsSystemContext retourne TRUE si le contexte actuel est « System ». Sinon, elle retourne FALSE.

    Syntaxe: IsSystemContext()

  • DoesStringContentEqual

    La fonction DoesStringContentEqual retourne TRUE si la représentation sous forme de chaîne de l’objet donné est identique à StringContent.

    Syntaxe: DoesStringContentEqual("ObjectType","EncodedLocation","StringContent")

    Paramètre Obligatoire ? Valeur
    ObjectType Oui Définit le type d’objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocationPattern Oui Emplacement encodé de l’objet examiné. Des variables d’environnement peuvent être spécifiées.
    StringContent Oui Chaîne par rapport à laquelle est cochée.

    Exemple :

    <condition negation="Yes">MigXmlHelper.DoesStringContentEqual("File","%USERNAME%","")</condition>
    
  • DoesStringContentContain

    La fonction DoesStringContentContain retourne TRUE s’il existe au moins une occurrence de StrToFind dans la représentation sous forme de chaîne de l’objet.

    Syntaxe: DoesStringContentContain("ObjectType","EncodedLocation","StrToFind")

    Paramètre Obligatoire ? Valeur
    ObjectType Oui Définit le type d’objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocationPattern Oui Emplacement encodé de l’objet examiné. Des variables d’environnement peuvent être spécifiées.
    StrToFind Oui Chaîne qui fait l’objet d’une recherche dans le contenu de l’objet donné.
  • IsSameObject

    La fonction IsSameObject retourne TRUE si les emplacements encodés donnés sont résolus en un même objet physique. Sinon, elle retourne FALSE.

    Syntaxe: IsSameObject("ObjectType","EncodedLocation1","EncodedLocation2")

    Paramètre Obligatoire ? Valeur
    ObjectType Oui Définit le type d’objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocation1 Oui Emplacement encodé pour le premier objet. Des variables d’environnement peuvent être spécifiées.
    EncodedLocation2 Oui Emplacement encodé pour le deuxième objet. Des variables d’environnement peuvent être spécifiées.

    Par exemple :

    <objectSet>
       <condition negation="Yes">MigXmlHelper.IsSameObject("File","%CSIDL_FAVORITES%","%CSIDL_COMMON_FAVORITES%")</condition>
       <pattern type="File">%CSIDL_FAVORITES%\* [*]</pattern>
    </objectSet>
    
  • IsSameContent

    La fonction IsSameContent retourne TRUE si les objets donnés ont le même contenu. Sinon, elle retourne FALSE. Le contenu est comparé octet par octet.

    Syntaxe: IsSameContent("ObjectType1","EncodedLocation1","ObjectType2","EncodedLocation2")

    Paramètre Obligatoire ? Valeur
    ObjectType1 Oui Définit le type du premier objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocation1 Oui Emplacement encodé pour le premier objet. Des variables d’environnement peuvent être spécifiées.
    ObjectType2 Oui Définit le type du deuxième objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocation2 Oui Emplacement encodé pour le deuxième objet. Des variables d’environnement peuvent être spécifiées.
  • IsSameStringContent

    La fonction IsSameStringContent retourne TRUE si les objets donnés ont le même contenu. Sinon, elle retourne FALSE. Le contenu est interprété comme une chaîne.

    Syntaxe: IsSameStringContent("ObjectType1","EncodedLocation1","ObjectType2","EncodedLocation2")

    Paramètre Obligatoire ? Valeur
    ObjectType1 Oui Définit le type du premier objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocation1 Oui Emplacement encodé pour le premier objet. Des variables d’environnement peuvent être spécifiées.
    ObjectType2 Oui Définit le type du deuxième objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocation2 Oui Emplacement encodé pour le deuxième objet. Des variables d’environnement peuvent être spécifiées.

<conditions>

L’élément <conditions> retourne un résultat booléen utilisé pour spécifier les conditions dans lesquelles l’élément parent est évalué. USMT évalue les éléments enfants, puis joint leurs résultats à l’aide des opérateurs AND ou OR en fonction du paramètre operation.

Syntaxe:

<conditions operation="AND|OR">
</conditions>
Paramètre Obligatoire ? Valeur
opération Non, valeur par défaut = AND Définit l’opération booléenne qui est effectuée sur les résultats obtenus à partir des éléments enfants.

L’exemple suivant provient du MigApp.xml fichier :

<environment name="GlobalEnv">
   <conditions>
      <condition negation="Yes">MigXmlHelper.IsNative64Bit()</condition>
   </conditions>
   <variable name="HklmWowSoftware">
   <text>HKLM\Software</text>
   </variable>
</environment>

<contenu>

L’élément< content> peut être utilisé pour spécifier une liste de modèles d’objets afin d’obtenir un jeu d’objets à partir de l’ordinateur source. Chaque <objectSet> dans un <élément de contenu> est évalué. Pour chaque liste de modèles d’objets résultante, les objets qui lui correspondent sont énumérés et leur contenu est filtré par le paramètre de filtre. Le tableau de chaînes obtenu est la sortie de l’élément <content> . Le script de filtre retourne un tableau d’emplacements. L’élément parent< objectSet> peut contenir plusieurs éléments de contenu> enfants<.

  • Nombre d’occurrences : illimité

  • Éléments parents :<objectSet>

  • Éléments enfants :<objectSet>

  • Fonctions d’assistance : Les fonctions de contenu> suivantes< peuvent être utilisées avec cet élément : ExtractSingleFile, ExtractMultipleFileset ExtractDirectory.

Syntaxe:

<content filter="ScriptInvocation">
</content>
Paramètre Obligatoire ? Valeur
filter Oui Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").
Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la <règle include> . Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

<fonctions de contenu>

Les fonctions suivantes génèrent des modèles à partir du contenu d’un objet . Ces fonctions sont appelées pour chaque objet que l’élément ObjectSet> parent< énumére.

  • ExtractSingleFile

    Si la valeur de Registre est multi-SZ, seul le premier segment est traité. Le modèle retourné est l’emplacement encodé d’un fichier qui doit exister sur le système. Si la spécification est correcte dans la valeur de Registre, mais que le fichier n’existe pas, cette fonction retourne NULL.

    Syntaxe: ExtractSingleFile(Separators,PathHints)

    Paramètre Obligatoire ? Valeur
    Séparateurs Oui Liste des séparateurs possibles qui peuvent suivre la spécification du fichier dans ce nom de valeur de Registre. Par exemple, si le contenu est « C:\Windows\Notepad.exe,-2 », le séparateur est une virgule. Null peut être spécifié.
    PathHints Oui Liste de chemins d’accès supplémentaires, séparés par deux-points (;), où la fonction recherche un fichier correspondant au contenu actuel. Par exemple, si le contenu est « Notepad.exe » et que le chemin est la variable d’environnement %Path%, la fonction recherche Notepad.exe dans %windir% et retourne « c :\Windows [Notepad.exe] ». Null peut être spécifié.

    Exemple :

    <content filter="MigXmlHelper.ExtractSingleFile(',','%system%')">
    

    et

    <content filter="MigXmlHelper.ExtractSingleFile(NULL,'%CSIDL_COMMON_FONTS%')">
    
  • ExtractMultipleFiles

    La fonction ExtractMultipleFiles retourne plusieurs modèles, un pour chaque fichier qui se trouve dans le contenu de la valeur de Registre donnée. Si la valeur de Registre est multi-SZ, le séparateur MULTI-SZ est considéré comme un séparateur par défaut. par conséquent, pour MULTI-SZ, l’argument <Separators> doit être NULL.

    Les modèles retournés sont les emplacements encodés pour les fichiers qui doivent exister sur l’ordinateur source. Si la spécification est correcte dans la valeur de Registre, mais que le fichier n’existe pas, elle n’est pas incluse dans la liste résultante.

    Syntaxe: ExtractMultipleFiles(Separators,PathHints)

    Paramètre Obligatoire ? Valeur
    Séparateurs Oui Liste des séparateurs possibles qui peuvent suivre la spécification du fichier dans ce nom de valeur de Registre. Par exemple, si le contenu est « C:\Windows\Notepad.exe,-2 », le séparateur est une virgule. Ce paramètre doit avoir la valeur NULL lors du traitement des valeurs de Registre MULTI-SZ .
    PathHints Oui Liste de chemins d’accès supplémentaires, séparés par deux-points (;), où la fonction recherche un fichier correspondant au contenu actuel. Par exemple, si le contenu est « Notepad.exe » et que le chemin est la variable d’environnement %Path%, la fonction recherche Notepad.exe dans %windir% et retourne « c :\Windows [Notepad.exe] ». Null peut être spécifié.
  • ExtractDirectory

    La fonction ExtractDirectory retourne un modèle qui est l’emplacement encodé d’un répertoire qui doit exister sur l’ordinateur source. Si la spécification est correcte dans la valeur de Registre, mais que le répertoire n’existe pas, cette fonction retourne NULL. S’il traite une valeur de Registre qui est une zone MULTI-SZ, seul le premier segment est traité.

    Syntaxe: ExtractDirectory(Separators,LevelsToTrim,PatternSuffix)

    Paramètre Obligatoire ? Valeur
    Séparateurs Non Liste des séparateurs possibles qui peuvent suivre la spécification du fichier dans ce nom de valeur de Registre. Par exemple, si le contenu est « C:\Windows\Notepad.exe,-2 », le séparateur est une virgule. Null doit être spécifié lors du traitement des valeurs de Registre MULTI-SZ .
    LevelsToTrim Oui Nombre de niveaux à supprimer à partir de la fin de la spécification du répertoire. Utilisez cette fonction pour extraire un répertoire racine lorsqu’une valeur de Registre pointe à l’intérieur de ce répertoire racine à un emplacement connu.
    PatternSuffix Oui Modèle à ajouter à la spécification du répertoire. Exemple : * [*].

    Par exemple :

    <objectSet>
       <content filter='MigXmlHelper.ExtractDirectory (NULL, "1")'>
            <objectSet>
                 <pattern type="Registry">%HklmWowSoftware%\Classes\Software\RealNetworks\Preferences\DT_Common []</pattern>
            </objectSet>
       </content>
    </objectSet>
    

<contentModify>

L’élément< contentModify> modifie le contenu d’un objet avant que l’objet ne soit écrit sur l’ordinateur de destination. Pour chaque <élément contentModify> , il peut y avoir plusieurs <éléments objectSet> . Cet élément retourne le nouveau contenu de l’objet en cours de traitement.

  • Nombre d’occurrences : Illimité

  • Éléments parents :<rules>

  • Éléments enfants requis :<objectSet>

  • Fonctions d’assistance : les fonctions contentModify> suivantes< peuvent être utilisées avec cet élément : ConvertToDWORD, ConvertToString, ConvertToBinary, KeepExisting, OffsetValue, SetValueByTable, MergeMultiSzContent et MergeDelimitedContent.

Syntaxe:

<contentModify script="ScriptInvocation">
</contentModify>
Paramètre Obligatoire ? Valeur
script Oui Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Par exemple MyScripts.AScript ("Arg1","Arg2").

Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la règle include. Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

<fonctions contentModify>

Les fonctions suivantes modifient le contenu des objets à mesure qu’ils sont migrés. Ces fonctions sont appelées pour chaque objet que l’élément ObjectSet> parent< énumére.

  • ConvertToDWORD

    La fonction ConvertToDWORD convertit le contenu des valeurs de Registre énumérées par l’élément ObjectSet> parent< en DWORD. Par exemple, ConvertToDWORD convertit la chaîne "1" en DWORD 0x00000001. Si la conversion échoue, la valeur de DefaultValueOnError est appliquée.

    Syntaxe: ConvertToDWORD(DefaultValueOnError)

    Paramètre Obligatoire ? Valeur
    DefaultValueOnError Non Valeur écrite dans le nom de la valeur si la conversion échoue. NULL peut être spécifié et 0 est écrit en cas d’échec de la conversion.
  • ConvertToString

    La fonction ConvertToString convertit le contenu des valeurs de Registre qui correspondent à l’élément ObjectSet> parent< en chaîne. Par exemple, il convertit le DWORD 0x00000001 en chaîne « 1 ». Si la conversion échoue, la valeur de DefaultValueOnError est appliquée.

    Syntaxe: ConvertToString(DefaultValueOnError)

    Paramètre Obligatoire ? Valeur
    DefaultValueOnError Non Valeur écrite dans le nom de la valeur si la conversion échoue. NULL peut être spécifié et 0 est écrit en cas d’échec de la conversion.

    Par exemple :

    <contentModify script="MigXmlHelper.ConvertToString('1')">
       <objectSet>
            <pattern type="Registry">HKCU\Control Panel\Desktop [ScreenSaveUsePassword]</pattern>
       </objectSet>
    </contentModify>
    
  • ConvertToBinary

    La fonction ConvertToBinary convertit le contenu des valeurs de Registre qui correspondent à l’élément ObjectSet> parent< en type binaire.

    Syntaxe: ConvertToBinary ()

  • OffsetValue

    La fonction OffsetValue ajoute ou soustrait Value de la valeur de l’objet migré, puis réécrit le résultat dans la valeur de Registre sur l’ordinateur de destination. Par exemple, si l’objet migré est un DWORD avec la valeur 14et que la valeur est « -2 », la valeur de Registre se trouve 12 sur l’ordinateur de destination.

    Syntaxe: OffsetValue(Value)

    Paramètre Obligatoire ? Valeur
    Valeur Oui Représentation sous forme de chaîne d’une valeur numérique. Il peut être positif ou négatif. Exemple : OffsetValue(2).
  • SetValueByTable

    La fonction SetValueByTable fait correspondre la valeur de l’ordinateur source à la table source. Si la valeur est là, la valeur équivalente dans la table de destination est appliquée. Si la valeur n’y figure pas, ou si la table de destination n’a pas de valeur équivalente, la valeur DefaultValueOnError est appliquée.

    Syntaxe: SetValueByTable(SourceTable,DestinationTable,DefaultValueOnError)

    Paramètre Obligatoire ? Valeur
    SourceTable Oui Liste de valeurs séparées par des virgules qui sont possibles pour les valeurs de Registre source.
    DestinationTable Non Liste de valeurs traduites séparées par des virgules.
    DefaultValueOnError Non Valeur appliquée à l’ordinateur de destination si
    1. La valeur de l’ordinateur source ne correspond pas à SourceTable
    2. DestinationTable n’a pas de valeur équivalente.

    Si DefaultValueOnError a la valeur NULL, la valeur n’est pas modifiée sur l’ordinateur de destination.
  • KeepExisting

    La fonction KeepExisting peut être utilisée en cas de conflits sur l’ordinateur de destination. Cette fonction conserve (sans remplacer) les attributs spécifiés pour l’objet qui se trouve sur l’ordinateur de destination.

    Syntaxe: KeepExisting("OptionString","OptionString","OptionString",…)

    Paramètre Obligatoire ? Valeur
    OptionString Oui OptionString peut être Security, TimeFields ou FileAttrib :Letter. Un de chaque type d’OptionStrings peut être spécifié. Ne spécifiez pas plusieurs OptionsStrings avec la même valeur. Si plusieurs OptionsStrings avec la même valeur sont spécifiées, l’option la plus à droite de ce type est conservée. Par exemple, ne spécifiez pas (« FileAttrib :H », « FileAttrib :R »), car seule la lecture seule est évaluée. Au lieu de cela, spécifiez (« FileAttrib :HR ») et les attributs Hidden et Read-only sont conservés sur l’ordinateur de destination.
    • Sécurité : conserve le descripteur de sécurité de l’objet de destination s’il existe.
    • TimeFields : conserve les horodatages de l’objet de destination. Ce paramètre concerne uniquement les fichiers.
    • FileAttrib :<Letter> : conserve la valeur d’attribut de l’objet de destination, ON ou OFF, pour le jeu d’attributs de fichier spécifié. Ce paramètre concerne uniquement les fichiers. Les éléments suivants ne respectent pas la casse, mais l’outil USMT ignore toutes les valeurs non valides, répétées ou s’il existe un espace après FileAttrib :. Toute combinaison des attributs suivants peut être spécifiée :
      • A = Archive
      • C = Compressé
      • E = Chiffré
      • H = Masqué
      • I = Non indexé de contenu
      • O = hors connexion
      • R = Read-Only
      • S = Système
      • T = Temporaire
  • MergeMultiSzContent

    La fonction MergeMultiSzContent fusionne le contenu MULTI-SZ des valeurs de Registre énumérées par l’élément ObjectSet> parent< avec le contenu des valeurs de Registre équivalentes qui existent déjà sur l’ordinateur de destination. Instruction et String supprimez ou ajoutez du contenu à la zone MULTI-SZ obtenue. Les éléments en double sont supprimés.

    Syntaxe: MergeMultiSzContent (Instruction,String,Instruction,String,…)

    Paramètre Obligatoire ? Valeur
    Instruction Oui Il peut s’agir de l’une des valeurs suivantes :
    • Ajouter. Ajoute la chaîne correspondante à la zone MULTI-SZ obtenue si elle n’est pas déjà présente.
    • Supprimer. Supprime la chaîne correspondante de la zone MULTI-SZ résultante.
    Chaîne Oui Chaîne à ajouter ou à supprimer.
  • MergeDelimitedContent

    La fonction MergeDelimitedContent fusionne le contenu des valeurs de Registre énumérées par l’élément ObjectSet> parent< avec le contenu des valeurs de Registre équivalentes qui existent déjà sur l’ordinateur de destination. Le contenu est considéré comme une liste d’éléments séparés par l’un des caractères du paramètre Delimiters. Les éléments en double sont supprimés.

    Syntaxe: MergeDelimitedContent(Delimiters,Instruction,String,…)

    Paramètre Obligatoire ? Valeur
    Délimiteurs Oui Caractère unique utilisé pour séparer le contenu de l’objet en cours de traitement. Le contenu est considéré comme une liste d’éléments séparés par les délimiteurs.
    Par exemple, "." sépare la chaîne en fonction d’un point.
    Instruction Oui Il peut s’agir de l’une des valeurs suivantes :
    • Ajouter : ajoute string à la zone MULTI-SZ obtenue si elle n’est pas déjà présente.
    • Supprimer : supprime String de la zone MULTI-SZ résultante.
    Chaîne Oui Chaîne à ajouter ou à supprimer.

<description>

L’élément< description> définit une description du composant, mais n’affecte pas la migration.

  • Nombre d’occurrences : zéro ou une

  • Éléments parents :<component>

  • Éléments enfants : aucun

Syntaxe:

<description>ComponentDescription</description>
Paramètre Obligatoire ? Valeur
ComponentDescription Oui Description du composant.

L’exemple de code suivant montre comment l’élément <description> définit la description « Mon composant personnalisé » :

<description>My custom component<description>

<destinationCleanup>

L’élément< destinationCleanup> supprime les objets, tels que les fichiers et les clés de Registre, de l’ordinateur de destination avant d’appliquer les objets de l’ordinateur source. Cet élément est évalué uniquement lorsque l’outil LoadState est exécuté sur l’ordinateur de destination. Autrement dit, cet élément est ignoré par l’outil ScanState .

Important

Utilisez cette option avec une extrême prudence, car elle supprime des objets de l’ordinateur de destination.

Pour chaque <élément destinationCleanup> , il peut y avoir plusieurs <éléments objectSet> . Une utilisation courante de cet élément est si une clé de Registre est manquante sur l’ordinateur source, mais que le composant doit encore être migré. Dans ce cas, toutes les clés de Registre du composant peuvent être supprimées avant la migration des clés de Registre source. La suppression de toutes les clés de Registre du composant garantit que s’il manque une clé sur l’ordinateur source, elle sera également manquante sur l’ordinateur de destination.

  • Nombre d’occurrences : Illimité

  • Éléments parents :<rules>

  • Éléments enfants :<objectSet> (l’ordinateur de destination supprime tous les éléments enfants.)

Syntaxe:

<destinationCleanup filter=ScriptInvocation>
</destinationCleanup>
Paramètre Obligatoire ? Valeur
filter Oui Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").

Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la règle include. Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

Par exemple :

<destinationCleanup>
   <objectSet>
      <pattern type="Registry">HKCU\Software\Lotus\123\99.0\DDE Preferences\* [*]</pattern>
      <pattern type="Registry">HKCU\Software\Lotus\123\99.0\Find Preferences\* [*]</pattern>
   </objectSet>
</destinationCleanup>

<détecter>

Bien que l’élément <detect> soit toujours pris en charge, Microsoft recommande de ne plus utiliser l’élément <detect> , car il peut être déconseillé dans les futures versions d’USMT. Si l’élément <detect> est déconseillé, il nécessite une réécriture de tous les scripts qui utilisent l’élément <detect> . Au lieu de cela, Microsoft recommande d’utiliser l’élément <de détection> . L’élément< de détection> permet des instructions booléennes complexes plus clairement formulées

L’élément< detect> peut être utilisé pour déterminer si le composant est présent sur un système. Si tous les éléments de détection> enfants< au sein d’un <élément detect> sont résolus en TRUE, l’élément <detect> se résout en TRUE. Si des éléments de détection> enfants< sont résolus en FALSE, leur élément de détection> parent< se résout en FALSE. S’il n’existe aucune <section d’élément detect> , USMT suppose que le composant est présent.

Pour chaque <élément detect> , il peut y avoir plusieurs éléments de <condition> enfant ou <objectSet> , qui sont joints logiquement par un opérateur OR . Si au moins un <élément condition> ou <objectSet> prend la valeur TRUE, l’élément detect> prend la< valeur TRUE.

Syntaxe:

<detect name="ID" context="User|System|UserAndSystem">
</detect>
Paramètre Obligatoire ? Valeur
name Oui, quand <détecter> est un enfant à <nomméElements>
Non, quand <détecter> est un enfant à <détecter>
Lorsque l’ID est spécifié, les éléments enfants ne sont pas traités. Au lieu de cela, tous les autres <éléments de détection> portant le même nom qui sont déclarés dans l’élément <namedElements> sont traités.
contexte Non
(valeur par défaut = UserAndSystem)
Définit l’étendue de ce paramètre, qui indique s’il faut traiter ce composant dans le contexte de l’utilisateur spécifique, sur l’ensemble du système d’exploitation, ou les deux.
La plus grande étendue possible est définie par l’élément component. Par exemple, si un <élément de composant> a un contexte Utilisateur et qu’un <élément rules> a un contexte UserAndSystem, l’élément <rules> agit comme s’il avait un contexte Utilisateur. Si l’élément <rules> avait un contexte de System, il agirait comme si l’élément <rules> n’y était pas.
  • Utilisateur : évalue les variables pour chaque utilisateur.
  • Système : évalue les variables une seule fois pour le système.
  • UserAndSystem : évalue les variables de l’ensemble du système d’exploitation et de chaque utilisateur.

Pour obtenir des exemples, consultez les exemples de <détection>.

<Détecte>

Bien que l’élément <detects> soit toujours pris en charge, Microsoft recommande de ne plus utiliser l’élément <detects> , car il peut être déprécié dans les versions ultérieures d’USMT. Si l’élément <detects> est déconseillé, il nécessite une réécriture de tous les scripts qui utilisent l’élément <detects> . Au lieu de cela, Microsoft recommande d’utiliser l’élément <de détection> si l’élément parent est <role> ou <namedElements>, ou d’utiliser l’élément <conditions> si l’élément parent est <des règles>. L’élément< de détection> permet des instructions booléennes complexes plus clairement formulées et l’élément <conditions> permet la formulation d’instructions booléennes complexes.

L’élément< detects> est un conteneur pour un ou plusieurs <éléments de détection>. Si tous les éléments enfants <détectent> au sein d’un <élément détecte se> résolvent à TRUE, la <détection> se résout à TRUE. Si l’un des éléments de détection> enfant< est résolu en FALSE, <détecte> qu’il se résout en FALSE. Pour empêcher l’écriture de l’élément <detects> dans un composant, créez l’élément <detects> sous l’élément <namedElements> , puis faites-y référence. S’il n’existe aucune <section d’élément detects> , USMT suppose que le composant est présent. Les résultats de chaque <élément detects> sont joints par l’opérateur OR pour former la règle utilisée pour détecter l’élément parent.

Syntaxe:

<detects name="ID" context="User|System|UserAndSystem">
</detects>
Paramètre Obligatoire ? Valeur
name Oui, quand <détecte> est un enfant à <nomméElements>
Non, quand <détecte est> un rôle enfant à ou><<des règles>
Lorsque l’ID est spécifié, aucun élément de détection> enfant< n’est traité. Au lieu de cela, tout autre <élément détecte que les> éléments portant le même nom qui sont déclarés dans l’élément <namedElements> sont traités.
contexte Non
(valeur par défaut = UserAndSystem)
Définit l’étendue de ce paramètre : s’il faut traiter ce composant dans le contexte de l’utilisateur spécifique, sur l’ensemble du système d’exploitation, ou les deux.
La plus grande étendue possible est définie par l’élément> component<. Par exemple, si un <élément de composant> a un contexte Utilisateur et qu’un <élément de règles> a un contexte UserAndSystem, l’élément <rules> agit comme s’il avait un contexte Utilisateur. Si l’élément <rules> avait un contexte de System, il agirait comme si l’élément <rules> n’y était pas.
  • Utilisateur : évalue les variables pour chaque utilisateur.
  • Système : évalue les variables une seule fois pour le système.
  • UserAndSystem : évalue les variables de l’ensemble du système d’exploitation et de chaque utilisateur.

Le paramètre de contexte est ignoré pour <détecte les> éléments qui se trouvent à l’intérieur <des éléments de règles> .

L’exemple suivant provient du MigApp.xml fichier .

<detects>
   <detect>
      <condition>MigXmlHelper.DoesFileVersionMatch("%Lotus123InstPath%\123w.exe","ProductVersion","9.*")</condition>
   </detect>
   <detect>
      <condition>MigXmlHelper.DoesFileVersionMatch("%SmartSuiteInstPath%\smartctr.exe","ProductVersion","99.*")</condition>
   </detect>
</detects>

<détection>

L’élément< de détection> est un conteneur pour un <élément de conditions>. Le résultat des éléments de condition> enfants<, situés sous l’élément <conditions>, détermine le résultat de cet élément. Par exemple, si tous les éléments de conditions> enfants< dans l’élément <de détection> sont résolus en TRUE, l’élément <de détection> est résolu en TRUE. Si l’un des éléments de conditions> enfants< est résolu en FALSE, l’élément <de détection> est résolu en FALSE.

En outre, les résultats de chaque <section de détection> dans l’élément <role> sont joints par l’opérateur OR pour former la règle de détection de l’élément parent. Autrement dit, si l’une <des sections de détection> est résolue à TRUE, l’élément <role> est traité. Sinon, l’élément <role> n’est pas traité.

Utilisez l’élément <de détection> sous l’élément <namedElements> pour ne pas écrire dans un composant. Incluez ensuite une section de détection> correspondante< sous l’élément <de rôle> pour contrôler si le composant est migré. S’il n’existe pas <de section de détection> pour un composant, l’outil USMT suppose que le composant est présent.

Syntaxe:

<detection name="ID" context="User|System|UserAndSystem">
</detection>
Paramètre Obligatoire ? Valeur
name
  • Oui, lorsque <la détection> est déclarée sous <namedElements>
  • Facultatif, lorsqu’il est déclaré sous <le rôle>
S’il est déclaré, le contenu de l’élément <de détection> est ignoré et le contenu de l’élément <de détection> portant le même nom que celui déclaré dans l’élément <namedElements> est évalué.
contexte Non, default = UserAndSystem Définit l’étendue de ce paramètre : s’il faut traiter ce composant dans le contexte de l’utilisateur spécifique, sur l’ensemble du système d’exploitation, ou les deux.
  • Utilisateur : évalue le composant pour chaque utilisateur.
  • Système : évalue le composant une seule fois pour le système.
  • UserAndSystem : évalue le composant pour l’ensemble du système d’exploitation et pour chaque utilisateur.

Exemple :

<detection name="AdobePhotoshopCS">
   <conditions>
      <condition>MigXmlHelper.DoesObjectExist("Registry","HKCU\Software\Adobe\Photoshop\8.0")</condition>
      <condition>MigXmlHelper.DoesFileVersionMatch("%PhotoshopSuite8Path%\Photoshop.exe","FileVersion","8.*")</condition>
   </conditions>
</detection>

et

<role role="Settings">
   <detection>
      <conditions>
         <condition>MigXmlHelper.DoesFileVersionMatch("%QuickTime5Exe%","ProductVersion","QuickTime 5.*")</condition>
         <condition>MigXmlHelper.DoesFileVersionMatch("%QuickTime5Exe%","ProductVersion","QuickTime 6.*")</condition>
      </conditions>
   </detection>

<displayName>

L’élément< displayName> est un champ obligatoire dans chaque <élément de composant>.

  • Nombre d’occurrences : une fois pour chaque composant

  • Éléments parents :<component>

  • Éléments enfants : aucun

Syntaxe:

<displayName _locID="ID">ComponentName</displayName>
Paramètre Obligatoire ? Valeur
locID Non Ce paramètre est destiné à une utilisation usMT interne. N’utilisez pas ce paramètre.
ComponentName Oui Nom du composant.

Exemple :

<displayName>Command Prompt settings</displayName>

<environnement>

L’élément <d’environnement> est un conteneur pour <les éléments variables> dans lequel des variables peuvent être définies pour être utilisées dans un fichier .xml . Toutes les variables d’environnement définies de cette façon sont privées. Autrement dit, ils sont disponibles uniquement pour leurs composants enfants et le composant dans lequel ils ont été définis. Pour obtenir deux exemples de scénarios, consultez Exemples.

Syntaxe:

<environment name="ID" context="User|System|UserAndSystem">
</environment>
Paramètre Obligatoire ? Valeur
name Oui, lorsque <l’environnement> est un enfant de <namedElements>
Non, lorsque <l’environnement> est un enfant de rôle> ou<<de composant>
Lorsqu’il est déclaré comme enfant des éléments de <rôle> ou <de composant> , si l’ID est déclaré, USMT ignore le contenu de l’élément <d’environnement> et le contenu de l’élément <d’environnement> portant le même nom déclaré dans l’élément <namedElements> est traité.
contexte Non
(valeur par défaut = UserAndSystem)
Définit l’étendue de ce paramètre : s’il faut traiter ce composant dans le contexte de l’utilisateur spécifique, sur l’ensemble du système d’exploitation, ou les deux.
La plus grande étendue possible est définie par l’élément component<>. Par exemple, si un <élément de composant> a un contexte Utilisateur et qu’un <élément de règles> a un contexte UserAndSystem, l’élément <rules> agit comme s’il avait un contexte Utilisateur. Si l’élément <rules> avait un contexte de System, il agirait comme si <les règles> n’étaient pas là.
  • Utilisateur : évalue les variables pour chaque utilisateur.
  • Système : évalue les variables une seule fois pour le système.
  • UserAndSystem : évalue les variables de l’ensemble du système d’exploitation et de chaque utilisateur.

Exemples

Exemple de scénario 1

Dans ce scénario, générez l’emplacement des objets au moment de l’exécution en fonction de la configuration de l’ordinateur de destination. Par exemple, si une application écrit des données dans le répertoire où l’application est installée et que les utilisateurs peuvent installer l’application n’importe où sur l’ordinateur. Si l’application écrit une valeur hklm\software\companyname\install [path\] de Registre, puis met à jour cette valeur avec l’emplacement où l’application est installée, la seule façon de migrer correctement les données requises consiste à définir une variable d’environnement. Par exemple :

<environment>
   <variable name="INSTALLPATH">
      <script>MigXmlHelper.GetStringContent("Registry","\software\companyname\install [path]")</script>
   </variable>
</environment>

Une règle include peut ensuite être utilisée comme suit. N’importe quelle fonction de <script> peut être utilisée pour effectuer des tâches similaires.

<include>
   <objectSet>
      <pattern type="File">%INSTALLPATH%\ [*.xyz]</pattern>
   </objectSet>
</include>

Deuxièmement, les valeurs de Registre peuvent être filtrées pour contenir les données nécessaires. L’exemple suivant extrait la première chaîne (avant le séparateur «, ») dans la valeur du Registre Hklm\software\companyname\application\ [Path\].

<environment>
   <variable name="APPPATH">
        <objectSet>
           <content filter='MigXmlHelper.ExtractDirectory (",", "1")'>
             <objectSet>
                <pattern type="Registry">Hklm\software\companyname\application\ [Path]</pattern>
              </objectSet>
            </content>
        </objectSet>
    </variable>
</environment>

Exemple de scénario 2

Dans ce scénario, cinq fichiers nommés File1.txt, File2.txt, et ainsi de suite, doivent être migrés à partir de %SYSTEMDRIVE%\data\userdata\dir1\dir2\. Pour migrer ces fichiers, la règle include> suivante< doit se trouver dans un fichier .xml :

<include>
   <objectSet>
      <pattern type="File">%SYSTEMDRIVE%\data\userdata\dir1\dir2 [File1.txt]</pattern>
      <pattern type="File">%SYSTEMDRIVE%\data\userdata\dir1\dir2 [File2.txt]</pattern>
      <pattern type="File">%SYSTEMDRIVE%\data\userdata\dir1\dir2 [File3.txt]</pattern>
      <pattern type="File">%SYSTEMDRIVE%\data\userdata\dir1\dir2 [File4.txt]</pattern>
      <pattern type="File">%SYSTEMDRIVE%\data\userdata\dir1\dir2 [File5.txt]</pattern>
   </objectSet>
</include>

Au lieu de taper le chemin d’accès cinq fois, créez une variable pour l’emplacement comme suit :

<environment>
   <variable name="DATAPATH">
      <text>%SYSTEMDRIVE%\data\userdata\dir1\dir2 </text>
      </variable>
</environment>

Ensuite, spécifiez la variable dans une règle include<> comme suit :

<include>
   <objectSet>
      <pattern type="File">%DATAPATH% [File1.txt]</pattern>
      <pattern type="File">%DATAPATH% [File2.txt]</pattern>
      <pattern type="File">%DATAPATH% [File3.txt]</pattern>
      <pattern type="File">%DATAPATH% [File4.txt]</pattern>
      <pattern type="File">%DATAPATH% [File5.txt]</pattern>
   </objectSet>
</include>

<exclude>

L’élément <exclude> détermine quels objets ne sont pas migrés, sauf s’il existe un élément include> plus spécifique< qui migre un objet. S’il existe un <élément include> et <exclude> pour le même objet, l’objet est inclus. Pour chaque <élément exclude>, il peut y avoir plusieurs éléments objectSet> enfants<.

Syntaxe:

<exclude filter="ScriptInvocation">
</exclude>
Paramètre Obligatoire ? Valeur
filter Non
(valeur par défaut = Non)
Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").

Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la règle include. Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

Par exemple, à partir du MigUser.xml fichier :

<exclude>
   <objectSet>
      <pattern type="File">%CSIDL_MYMUSIC%\* [*]</pattern>
      <pattern type="File">%CSIDL_MYPICTURES%\* [*]</pattern>
      <pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>
   </objectSet>
</exclude>

<excludeAttributes>

L’élément< excludeAttributes> peut être utilisé pour déterminer les paramètres associés à un objet qui ne sont pas migrés. S’il existe des conflits entre les <éléments includeAttributes> et <excludeAttributes> , le modèle le plus spécifique détermine les modèles qui ne sont pas migrés. Si un objet n’a pas d’élément <includeAttributes> ou <excludeAttributes> , tous ses paramètres sont migrés.

  • Nombre d’occurrences : Illimité

  • Éléments parents :<rules>

  • Éléments enfants :<objectSet>

Syntaxe:

<excludeAttributes attributes="Security|TimeFields|Security,TimeFields">
</excludeAttributes>
Paramètre Obligatoire ? Valeur
Attributs Oui Spécifie les attributs à exclure. L’un des éléments suivants ou les deux peuvent être spécifiés. Si vous spécifiez les deux, ils doivent être séparés par des guillemets. Par exemple, "Security","TimeFields":
  • La sécurité peut être propriétaire, groupe, DACL ou SACL.
  • TimeFields peut être un de CreationTime, LastAccessTime et LastWrittenTime

Exemple :

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser">
<!-- This component migrates the files in the Video folder -->
   <component type="System" context="System">
      <displayName>System Data</displayName>
         <role role="Data">
            <rules>
<!-- Include all of the text files, which are immediately in the drive where the operating system is installed -->
               <include>
                  <objectSet>
                     <pattern type="File">%SYSTEMDRIVE%\ [*.txt]</pattern>
                  </objectSet>
               </include>
<!-- Exclude the time stamps from the text file starting with the letter a -->
               <excludeAttributes attributes="TimeFields">
                  <objectSet>
                     <pattern type="File">%SYSTEMDRIVE%\ [a*.txt]</pattern>
                  </objectSet>
               </excludeAttributes>
<!-- include the time stamps from the text file aa.txt -->
               <includeAttributes attributes="TimeFields">
                  <objectSet>
                     <pattern type="File">%SYSTEMDRIVE%\ [aa.txt]</pattern>
                  </objectSet>
               </includeAttributes>
<!-- Logoff the user after LoadState successfully completed. -->
               <externalProcess when="post-apply">
                  <commandLine>
                     logoff
                  </commandLine>
               </externalProcess>
         </rules>
   </role>
<!-- Migrate 
   all doc files from the system
   all power point files
   all visio design files 
   all my c++ program files -->
   <extensions>
      <extension>DOC</extension>
      <extension>PPT</extension>
      <extension>VXD</extension>
      <extension>PST</extension>
      <extension>CPP</extension>
   </extensions>
</component>
</migration>

<Extensions>

L’élément <extensions> est un conteneur pour un ou plusieurs <éléments d’extension> .

  • Nombre d’occurrences : zéro ou une

  • Éléments parents :<component>

  • Éléments enfants requis :<extension>

Syntaxe:

<extensions>
</extensions>

<extension>

L’élément <d’extension> peut être utilisé pour spécifier les documents d’une extension spécifique.

  • Nombre d’occurrences : illimité

  • Éléments parents :<extensions>

  • Éléments enfants : aucun

Syntaxe:

<extension>FilenameExtension</extension>
Paramètre Obligatoire ? Valeur
FilenameExtension Oui Extension de nom de fichier.

Par exemple, pour migrer tous les fichiers *.doc à partir de l’ordinateur source, en spécifiant le code suivant sous l’élément component<> :

<extensions> 
        <extension>doc</extension> 
<extensions> 

est identique à la spécification du code suivant sous l’élément <rules> :

<include> 
        <objectSet> 
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script> 
        </objectSet> 
</include>

Pour obtenir un autre exemple d’utilisation de l’élément d’extension<>, consultez l’exemple de< excludeAttributes>.

<externalProcess>

L’élément <externalProcess> peut être utilisé pour exécuter une ligne de commande pendant le processus de migration. Par exemple, une commande d’exécution peut avoir besoin de s’exécuter une fois le processus LoadState terminé.

  • Nombre d’occurrences : Illimité

  • Éléments parents :<rules>

  • Éléments enfants requis :<commandLine>

Syntaxe:

<externalProcess when="pre-scan|scan-success|post-scan|pre-apply|apply-success|post-apply">
</externalProcess>
Paramètre Obligatoire ? Valeur
quand Oui Indique quand la ligne de commande doit être exécutée. Cette valeur peut être l’une des valeurs suivantes :
  • analyse préalable avant le début du processus d’analyse.
  • réussite de l’analyse une fois le processus d’analyse terminé avec succès.
  • post-analyse une fois le processus d’analyse terminé, qu’il ait réussi ou non.
  • pré-appliquer avant le début du processus d’application.
  • apply-success une fois le processus d’application terminé avec succès.
  • post-application une fois le processus d’application terminé, qu’il ait réussi ou non.

Pour obtenir un exemple d’utilisation de l’élément <externalProcess>, consultez l’exemple de< excludeAttributes>.

<icon>

Cet élément est un élément USMT interne. N’utilisez pas cet élément.

<include>

L’élément <include> détermine ce qu’il faut migrer, sauf s’il existe une règle d’exclusion> plus spécifique<. Un script peut être spécifié pour être plus spécifique afin d’étendre la définition de ce qui doit être collecté. Pour chaque <élément include> , il peut y avoir plusieurs <éléments objectSet> .

  • Nombre d’occurrences : Illimité

  • Éléments parents :<rules>

  • Élément enfant obligatoire :<objectSet>

  • Fonctions d’assistance : Les fonctions de filtre include> suivantes< peuvent être utilisées avec cet élément : CompareStringContent, IgnoreIrrelevantLinks, AnswerNoet NeverRestore.

Syntaxe:

<include filter="ScriptInvocation">
</include>
Paramètre Obligatoire ? Valeur
filter Non.
Si ce paramètre n’est pas spécifié, tous les modèles qui se trouvent à l’intérieur de l’élément objectSet> enfant< sont traités.
Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").
Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la <règle include> . Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

L’exemple suivant provient du MigUser.xml fichier :

<component type="Documents" context="User">
   <displayName _locID="miguser.myvideo">My Video</displayName>
      <paths>
         <path type="File">%CSIDL_MYVIDEO%</path>
      </paths>
      <role role="Data">
         <detects>           
            <detect>
               <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>
            </detect>
         </detects>
         <rules>
               <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
                  <objectSet>
                     <pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>
                  </objectSet>
               </include>
               <merge script="MigXmlHelper.DestinationPriority()">
                  <objectSet>
                     <pattern type="File">%CSIDL_MYVIDEO% [desktop.ini]</pattern>
                  </objectSet>
            </merge>
         </rules>
      </role>
    </component>

<inclure> et <exclure> des fonctions de filtre

Les fonctions suivantes retournent une valeur booléenne. Ils peuvent être utilisés pour migrer certains objets en fonction du moment où certaines conditions sont remplies.

  • AnswerNo

    Ce filtre retourne toujours FALSE.

    Syntaxe: AnswerNo ()

  • CompareStringContent

    Syntaxe: CompareStringContent("StringContent","CompareType")

    Paramètre Obligatoire ? Valeur
    StringContent Oui Chaîne à vérifier.
    CompareType Oui Chaîne. Utilisez l’une des valeurs suivantes :
    • Égal (ne respectant pas la casse). La fonction retourne TRUE si la représentation sous forme de chaîne de l’objet actuel qui est traité par le moteur de migration est identique à StringContent.
    • NULLou toute autre valeur. La fonction retourne TRUE si la représentation sous forme de chaîne de l’objet actuel qui est traité par le moteur de migration ne correspond StringContentpas à .
  • IgnoreIrrelevantLinks

    Ce filtre filtre les fichiers .lnk qui pointent vers un objet qui n’est pas valide sur l’ordinateur de destination. La sélection a lieu sur l’ordinateur de destination, de sorte que tous les fichiers .lnk sont enregistrés dans le magasin pendant ScanState. Ensuite, ils sont filtrés lorsque l’outil LoadState s’exécute.

    Syntaxe: IgnoreIrrelevantLinks ()

    Par exemple :

    <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>
              <pattern type="File">%CSIDL_COMMON_VIDEO%\* [*]</pattern>
         </objectSet>
    </include>
    
  • NeverRestore

    Cette fonction peut être utilisée pour collecter les objets spécifiés à partir de l’ordinateur source, mais pas migrer les objets vers l’ordinateur de destination. Lorsqu’elle est exécutée avec l’outil ScanState , cette fonction prend la valeur TRUE. Lorsqu’elle est exécutée avec l’outil LoadState , cette fonction prend la valeur FALSE. Cette fonction peut être utilisée pour vérifier la valeur d’un objet sur l’ordinateur de destination, mais il n’y a aucune intention de migrer l’objet vers la destination.

    Syntaxe: NeverRestore()

    Dans l’exemple suivant, HKCU\Panneau de configuration\International [Paramètres régionaux] est inclus dans le magasin, mais il n’est pas migré vers l’ordinateur de destination :

    <include filter="MigXmlHelper.NeverRestore()">
       <objectSet>
          <pattern type="Registry">HKCU\Control Panel\International [Locale]</pattern>
       </objectSet>
    </include>
    

<includeAttributes>

L’élément< includeAttributes> peut être utilisé pour déterminer si certains paramètres associés à un objet sont migrés avec l’objet lui-même. S’il existe des conflits entre les <éléments includeAttributes> et <excludeAttributes> , le modèle le plus spécifique détermine quels paramètres sont migrés. Si un objet n’a pas d’élément <includeAttributes> ou <excludeAttributes> , tous ses paramètres sont migrés.

  • Nombre d’occurrences : illimité

  • Éléments parents :<rules>

  • Éléments enfants :<objectSet>

Syntaxe:

<includeAttributes attributes="Security|TimeFields|Security,TimeFields">
</includeAttributes>
Paramètre Obligatoire ? Valeur
Attributs Oui Spécifie les attributs à inclure dans un objet migré. L’un des éléments suivants ou les deux peuvent être spécifiés. Si vous spécifiez les deux, ils doivent être séparés par des guillemets. Par exemple, "Security","TimeFields":
  • La sécurité peut être l’une des valeurs suivantes :
    • Propriétaire : propriétaire de l’objet (SID).
    • Groupe : groupe principal de l’objet (SID).
    • DACL (liste de contrôle d’accès discrétionnaire) : liste de contrôle d’accès contrôlée par le propriétaire d’un objet et qui spécifie l’accès d’utilisateurs ou de groupes particuliers à l’objet.
    • SACL (liste de contrôle d’accès système) : ACL qui contrôle la génération de messages d’audit pour les tentatives d’accès à un objet sécurisable. La possibilité d’obtenir ou de définir la SACL d’un objet est contrôlée par un privilège généralement détenu uniquement par les administrateurs système.
  • TimeFields peut être l’une des valeurs suivantes :
    • CreationTime : spécifie quand le fichier ou le répertoire a été créé.
    • LastAccessTime : spécifie le moment où le fichier est lu, écrit dans ou pour les fichiers exécutables, exécuté pour la dernière fois.
    • LastWrittenTime : spécifie le moment où le fichier est écrit, tronqué ou remplacé pour la dernière fois.

Pour obtenir un exemple d’utilisation de l’élément <includeAttributes>, consultez l’exemple de< excludeAttributes>.

<bibliothèque>

Cet élément est un élément USMT interne. N’utilisez pas cet élément.

<emplacement>

L’élément< location> définit l’emplacement de l’élément <object>.

  • Nombre d’occurrences : une fois pour chaque <objet>

  • Éléments parents :<object>

  • Éléments enfants :<script>

Syntaxe:

<location type="typeID">ObjectLocation</location>
Paramètre Obligatoire ? Valeur
type Oui typeID peut être Registre ou Fichier.
ObjectLocation Oui Emplacement de l’objet.

L’exemple suivant provient du MigApp.xml fichier :

<addObjects>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [UpgradeVersion]</location>
      <attributes>DWORD</attributes>
      <bytes>0B000000</bytes>
   </object>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [Lang]</location>
      <attributes>DWORD</attributes>
      <bytes>00000000</bytes>
   </object>
</addObjects>

<locationModify>

L’élément< locationModify> peut être utilisé pour modifier l’emplacement et le nom d’un objet avant la migration de l’objet vers l’ordinateur de destination. L’élément< locationModify> est traité uniquement lorsque l’outil LoadState est exécuté sur l’ordinateur de destination. En d’autres termes, cet élément est ignoré par l’outil ScanState . L’élément< locationModify> crée le dossier approprié sur l’ordinateur de destination s’il n’existe pas déjà.

Nombre d’occurrences : Illimité

Syntaxe:

<locationModify script="ScriptInvocation">
</locationModify>
Paramètre Obligatoire ? Valeur
script Oui Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").

Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la règle include. Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

L’exemple suivant provient du MigApp.xml fichier :

<locationModify script="MigXmlHelper.RelativeMove('%CSIDL_APPDATA%\Microsoft\Office','%CSIDL_APPDATA%')">
   <objectSet>
      <pattern type="File">%CSIDL_APPDATA%\Microsoft\Office\ [Access10.pip]</pattern>
   </objectSet>
</locationModify>

<locationModify> , fonctions

Les fonctions suivantes modifient l’emplacement des objets à mesure qu’ils sont migrés lors de l’utilisation de l’élément <locationModify> . Ces fonctions sont appelées pour chaque objet que l’élément parent< objectSet> énumére. L’élément< locationModify> crée le dossier approprié sur l’ordinateur de destination s’il n’existe pas déjà.

  • ExactMove

    La fonction ExactMove déplace tous les objets mis en correspondance par l’élément parent< objectSet> dans l’objet ObjectEncodedLocation donné. Cette fonction peut être utilisée pour déplacer un fichier unique vers un autre emplacement sur l’ordinateur de destination. Si l’emplacement de destination est un nœud, tous les objets sources correspondants sont écrits dans le nœud sans aucun sous-répertoire. Si l’emplacement de destination est une feuille, le moteur de migration migre tous les objets sources correspondants vers le même emplacement. Si une collision se produit, les algorithmes de collision normaux s’appliquent.

    Syntaxe: ExactMove(ObjectEncodedLocation)

    Paramètre Obligatoire ? Valeur
    ObjectEncodedLocation Oui Emplacement de destination de tous les objets sources.

    Exemple :

    <locationModify script="MigXmlHelper.ExactMove('HKCU\Keyboard Layout\Toggle [HotKey]')">
       <objectSet>
            <pattern type="Registry">HKCU\Keyboard Layout\Toggle []</pattern>
       </objectSet>
    </locationModify>
    
  • Bouger

    La fonction Move déplace les objets vers un autre emplacement sur l’ordinateur de destination. En outre, cette fonction crée des sous-répertoires qui étaient au-dessus du CSIDL le plus long dans le nom de l’objet source.

    Syntaxe: Move(DestinationRoot)

    Paramètre Obligatoire ? Valeur
    DestinationRoot Oui Emplacement où les objets sources sont déplacés. Si nécessaire, cette fonction crée tous les sous-répertoires qui se trouvaient au-dessus du CSIDL le plus long dans le nom de l’objet source.
  • RelativeMove

    La fonction RelativeMove peut être utilisée pour collecter et déplacer des données. Les variables d’environnement peuvent être utilisées dans les racines source et de destination, mais elles peuvent être définies différemment sur les ordinateurs source et de destination.

    Syntaxe: RelativeMove(SourceRoot,DestinationRoot)

    Paramètre Obligatoire ? Valeur
    SourceRoot Oui Emplacement à partir duquel les objets sont déplacés. Les objets sources énumérés par l’élément parent< objectSet> qui ne se trouvent pas à cet emplacement ne sont pas déplacés.
    DestinationRoot Oui Emplacement où les objets sources sont déplacés sur l’ordinateur de destination. Si nécessaire, cette fonction crée tous les sous-répertoires qui se trouvaient au-dessus de SourceRoot.

Exemple :

<include>
   <objectSet>
      <pattern type="File">%CSIDL_COMMON_FAVORITES%\* [*]</pattern>
   <objectSet>
</include>
<locationModify script="MigXmlHelper.RelativeMove('%CSIDL_COMMON_FAVORITES%','%CSIDL_COMMON_FAVORITES%')">
     <objectSet>
          <pattern type="File">%CSIDL_COMMON_FAVORITES%\* [*]</pattern>
     </objectSet>
</locationModify>

<_locDefinition>

Cet élément est un élément USMT interne. N’utilisez pas cet élément.

<fabricant>

L’élément< manufacturer> définit le fabricant du composant, mais n’affecte pas la migration.

  • Nombre d’occurrences : zéro ou une

  • Éléments parents :<component>

  • Éléments enfants : aucun

Syntaxe:

<manufacturer>Name</manufacturer>
Paramètre Obligatoire ? Valeur
Nom Oui Nom du fabricant du composant.

<fusionner>

L’élément< merge> détermine ce qui se passe lorsqu’une collision se produit. Une collision se produit lorsqu’un objet migré est déjà présent sur l’ordinateur de destination. Si cet élément n’est pas spécifié, le comportement par défaut du registre est que l’objet source remplace l’objet de destination. Le comportement par défaut pour les fichiers consiste à renommer le fichier source en OriginalFileName(1).OriginalExtension. Cet élément spécifie uniquement ce qui doit être fait en cas de collision. Il n’inclut pas d’objets. Par conséquent, pour les objets à migrer, <les règles include> doivent être spécifiées avec l’élément de< fusion>. Lorsqu’un objet est traité et qu’une collision est détectée, USMT sélectionne la règle de fusion la plus spécifique. Il applique ensuite la règle pour résoudre le conflit. Par exemple, si une <règle de fusion> est définie sur <sourcePriority> et qu’une <règle de fusion> est définie sur <destinationPriority>, USMT utilise la <règle destinationPriority>, car elle est la plus spécifique.C:\subfolder\* [*]C:\* [*]

Pour obtenir un exemple de cet élément, consultez Conflits et priorité.

  • Nombre d’occurrences : Illimité

  • Éléments parents :<rules>

  • Élément enfant obligatoire :<objectSet>

  • Fonctions d’assistance : Les fonctions de fusion> suivantes< peuvent être utilisées avec cet élément : SourcePriority, DestinationPriority, FindFilePlaceByPattern, LeafPattern, NewestVersion, HigherValue()et LowerValue().

Syntaxe:

<merge script="ScriptInvocation">
</merge>
Paramètre Obligatoire ? Valeur
script Oui Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").

Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la <règle include> . Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.

L’exemple suivant provient du MigUser.xml fichier :

<rules>
   <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
      <objectSet>
         <pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>
      </objectSet>
   </include>
   <merge script="MigXmlHelper.DestinationPriority()">
      <objectSet>
         <pattern type="File">%CSIDL_MYVIDEO% [desktop.ini]</pattern>
      </objectSet>
   </merge>
</rules>

<fonctions de fusion>

Ces fonctions contrôlent la façon dont les collisions sont résolues.

  • DestinationPriority

    Spécifie de conserver l’objet qui se trouve sur l’ordinateur de destination et de ne pas migrer l’objet à partir de l’ordinateur source.

    Exemple :

    <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>
              <pattern type="Registry">HKCU\Software\Microsoft\Office\16.0\PhotoDraw\ [MyPictures]</pattern>
              <pattern type="Registry">HKCU\Software\Microsoft\Office\16.0\PhotoDraw\Settings\ [PicturesPath]</pattern>
              <pattern type="Registry">HKCU\Software\Microsoft\Office\16.0\PhotoDraw\Settings\ [AdditionalPlugInPath]</pattern>
         </objectSet>
    </merge>
    
  • FindFilePlaceByPattern

    La fonction FindFilePlaceByPattern enregistre les fichiers avec un compteur incrémentiel en cas de collision. Il s’agit d’une chaîne qui contient une de chaque construction : <F>, <E>, <N> dans n’importe quel ordre.

    Syntaxe: FindFilePlaceByPattern(FilePattern)

    Paramètre Obligatoire ? Valeur
    FilePattern Oui
    • <F> est remplacé par le nom de fichier d’origine.
    • <N> est remplacé par un compteur incrémentiel jusqu’à ce qu’il n’y ait pas de collision avec les objets sur l’ordinateur de destination.
    • <E> est remplacé par l’extension de nom de fichier d’origine.

    Par exemple, <F> (<N>).<E> modifie le fichier MyDocument.doc source dans MyDocument (1).doc sur l’ordinateur de destination.
  • NewestVersion

    La fonction NewestVersion résout les conflits sur l’ordinateur de destination en fonction de la version du fichier.

    Syntaxe: NewestVersion(VersionTag)

    Paramètre Obligatoire ? Valeur
    VersionTag Oui Champ de version coché. Ce champ peut être FileVersion ou ProductVersion. Le fichier avec la version la plus élevée de VersionTag détermine les conflits qui sont résolus en fonction de la version du fichier. Par exemple, si Myfile.txt contient FileVersion 1 et que le même fichier sur l’ordinateur de destination contient FileVersion 2, le fichier sur la destination reste.
  • HigherValue()

    Cette fonction peut être utilisée pour fusionner des valeurs de Registre. Les valeurs de Registre sont évaluées en tant que valeurs numériques, et celle avec la valeur la plus élevée détermine les valeurs de Registre qui sont fusionnées.

  • LowerValue()

    Cette fonction peut être utilisée pour fusionner des valeurs de Registre. Les valeurs de Registre sont évaluées en tant que valeurs numériques et celle qui a la valeur la plus faible détermine les valeurs de Registre qui sont fusionnées.

  • SourcePriority

    Spécifie de migrer l’objet à partir de l’ordinateur source et de supprimer l’objet qui se trouve sur l’ordinateur de destination.

    Par exemple :

    <merge script="MigXmlHelper.SourcePriority()">
     <objectSet>
       <pattern type="Registry">%HklmWowSoftware%\Microsoft\Office\14.0\Common\Migration\Publisher [UpgradeVersion]</pattern>
       <pattern type="Registry">%HklmWowSoftware%\Microsoft\Office\15.0\Common\Migration\Publisher [UpgradeVersion]</pattern>
       <pattern type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Publisher [UpgradeVersion]</pattern>
     </objectSet>
    </merge>
    

<migration>

L’élément< de migration> est l’élément racine unique d’un fichier de.xml de migration et est obligatoire. Chaque fichier.xml doit avoir un URLid de migration unique. L’urlid de chaque fichier spécifié sur la ligne de commande doit être unique. Les urlids doivent être uniques, car USMT utilise l’urlid pour définir les composants dans le fichier.

Syntaxe:

<migration urlid="*UrlID/*Name">
</migration>
Paramètre Obligatoire ? Valeur
urlid Oui UrlID est un identificateur de chaîne qui identifie de façon unique ce fichier .xml . Ce paramètre doit être un nom sans signe deux-points tel que défini par la spécification espaces de noms XML. Chaque fichier de.xml de migration doit avoir un URLID unique. Si deux fichiers de.xml de migration ont le même urlid, le deuxième fichier .xml spécifié sur la ligne de commande n’est pas traité. Pour plus d’informations sur les espaces de noms XML, consultez Utiliser des espaces de noms XML.
Nom Non Bien que ce ne soit pas obligatoire, il est recommandé d’utiliser le nom du fichier .xml .

L’exemple suivant provient du MigApp.xml fichier :

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp">
</migration>

MigXMLHelper.FileProperties

Cette fonction d’assistance de filtre peut être utilisée pour filtrer la migration de fichiers en fonction des attributs de taille de fichier et de date.

Fonction d’assistance MigXMLHelper.FileProperties (property, operator, valueToCompare)
Propriété filesize, dateCreated, dateModified, dateAccessed
Opérateur range, neq, lte, lt, eq, gte, gte
valueToCompare Valeur en cours de comparaison. Exemple :
Date : « 2023/05/15-2020/05/17 », « 2023/05/15 »
Taille : chiffre avec B, Ko, Mo ou Go à la fin. « 5 Go », « 1 Ko-1 Mo »
<component context="System"  type="Application">
<displayName>File_size</displayName>
<role role="Data">

   <rules>
        <include filter='MigXmlHelper.FileProperties("dateAccessed","range","2023/05/15-2020/05/17")'>
         <objectSet>
         <pattern type="File">%SYSTEMDRIVE%\DOCS\* [*]</pattern>
         </objectSet>
      </include>
   </rules>
</role>
</component>

<namedElements>

L’élément <namedElements> peut être utilisé pour définir des éléments nommés. Ces éléments peuvent être utilisés dans n’importe quel composant du fichier .xml . Pour obtenir un exemple d’utilisation de cet élément, consultez le MigApp.xml fichier .

Syntaxe:

<namedElements>
</namedElements>

Pour obtenir un exemple de cet élément, consultez le MigApp.xml fichier .

<object>

L’élément< object> représente un fichier ou une clé de Registre.

Syntaxe:

<object>
</object>

L’exemple suivant provient du MigApp.xml fichier :

<addObjects>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [UpgradeVersion]</location>
      <attributes>DWORD</attributes>
      <bytes>0B000000</bytes>
   </object>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\16.0\Common\Migration\Office [Lang]</location>
      <attributes>DWORD</attributes>
      <bytes>00000000</bytes>
      </object>
</addObjects>

<objectSet>

L’élément< objectSet> contient une liste de modèles d’objet , par exemple, les chemins d’accès aux fichiers, les emplacements du Registre, etc. Tous les éléments de conditions> enfants< sont évalués en premier. Si tous les éléments de conditions> enfants< retournent FALSE, l’élément <objectSet> prend la valeur d’un jeu vide. Pour chaque élément parent, il ne peut y avoir que plusieurs <éléments objectSet> .

Syntaxe:

<objectSet>
</objectSet>

L’exemple suivant provient du MigUser.xml fichier :

<component type="Documents" context="User">
   <displayName _locID="miguser.mymusic">My Music</displayName>
      <paths>
         <path type="File">%CSIDL_MYMUSIC%</path>
      </paths>
   <role role="Data">
      <detects>           
      <detect>
         <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYMUSIC%")</condition>
      </detect>
   </detects>           
   <rules>
      <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>
            <pattern type="File">%CSIDL_MYMUSIC%\* [*]</pattern>
         </objectSet>
      </include>
      <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>
            <pattern type="File">%CSIDL_MYMUSIC%\ [desktop.ini]</pattern>
         </objectSet>
      </merge>
   </rules>
   </role>
</component>

<path>

Cet élément est un élément USMT interne. N’utilisez pas cet élément.

<Chemins>

Cet élément est un élément USMT interne. N’utilisez pas cet élément.

<motif>

Cet élément peut être utilisé pour spécifier plusieurs objets. Plusieurs <éléments de modèle> peuvent être utilisés pour chaque <élément objectSet> et ils sont combinés. Si vous spécifiez des fichiers, Microsoft recommande d’utiliser GenerateDrivePatterns avec <un script> à la place. GenerateDrivePatterns est fondamentalement identique à une <règle de modèle> , sans la spécification de la lettre de lecteur. Par exemple, les deux lignes de code suivantes sont similaires :

<pattern type="File">C:\Folder\* [Sample.doc]</pattern>
<script>MigXmlHelper.GenerateDrivePatterns("\Folder\* [Sample.doc]","Fixed"</script>
  • Nombre d’occurrences : Illimité

  • Éléments parents :<objectSet>

  • Éléments enfants : aucun élément sauf Path [object] doit être valide.

Syntaxe:

<pattern type="typeID">Path [object]</pattern>
Paramètre Obligatoire ? Valeur
type Oui typeID peut être Registry, File ou Ini. Si typeId est Ini, un espace entre Path et object n’est pas autorisé. Par exemple, le format suivant est correct lorsque type="Ini » :
<pattern type="Ini">%WinAmp5InstPath%\Winamp.ini|WinAmp[keeponscreen]</pattern>
Path [object] Oui Modèle de registre ou de chemin d’accès de fichier valide, suivi d’au moins un espace, suivi d’crochets [] qui contiennent l’objet à migrer.
  • Le chemin d’accès peut contenir le caractère générique astérisque (*) ou peut être une variable d’environnement reconnue. Le point d’interrogation ne peut pas être utilisé comme caractère générique. HKCU et HKLM peuvent être utilisés pour faire référence à HKEY_CURRENT_USER et HKEY_LOCAL_MACHINE respectivement.
  • L’objet peut contenir le caractère générique astérisque (*). Toutefois, le point d’interrogation ne peut pas être utilisé comme caractère générique. Exemple :
    C:\Folder\ [*] énumère tous les fichiers dans C:\Folder , mais aucun sous-dossier de C:\Folder.
    C:\Folder* [*] énumère tous les fichiers et sous-dossiers de C:\Folder.
    C:\Folder\ [*.mp3] énumère tous les .mp3 fichiers dans C:\Folder.
    C:\Folder\ [Sample.doc] énumère uniquement le Sample.doc fichier situé dans C :\Folder.
    Remarque
    Si vous migrez un fichier qui a un caractère entre crochets ([ ou ]) dans le nom de fichier, un caractère carotte (^) doit être inséré directement avant le crochet pour qu’il soit valide. Par exemple, s’il existe un fichier nommé « file].txt », <pattern type="File">c:\documents\mydocs [file^].txt]</pattern> doit être spécifié au lieu de <pattern type="File">c:\documents\mydocs [file].txt]</pattern>.

Par exemple :

  • Pour migrer une clé de Registre unique :

    <pattern type="Registry">HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache [Persistent]</pattern>
    
  • Pour migrer le C:\EngineeringDrafts dossier et les sous-dossiers à partir du lecteur C : :

    <pattern type="File">C:\EngineeringDrafts\* [*]</pattern>
    
  • Pour migrer uniquement le C:\EngineeringDrafts dossier, à l’exclusion des sous-dossiers, à partir du lecteur C : :

    Rediriger les fichiers et les paramètres

  • Pour migrer le Sample.doc fichier à partir de C:\EngineeringDrafts:

    <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>
    
  • Pour migrer le Sample.doc fichier à partir de là où il existe sur le lecteur C :, utilisez le modèle de la manière suivante. S’il existe plusieurs fichiers portant le même nom sur le lecteur C :, tous ces fichiers sont migrés.

    <pattern type="File"> C:\* [Sample.doc] </pattern>
    
  • Pour obtenir d’autres exemples d’utilisation de cet élément, consultez Exclure des fichiers et des paramètres, Réacheminer des fichiers et des paramètres, Inclure des fichiers et des paramètres et Exemples XML personnalisés.

<traitement>

Cet élément peut être utilisé pour exécuter un script pendant un point spécifique du processus de migration. Les valeurs de retour ne sont pas attendues des scripts spécifiés. S’il existe des valeurs de retour, elles sont ignorées.

  • Nombre d’occurrences : illimité

  • Éléments parents :<rules>

  • Élément enfant requis :<script>

Syntaxe:

<processing when="pre-scan|scan-success|post-scan|pre-apply|apply-success|post-apply">
</processing>
Paramètre Obligatoire ? Valeur
quand Oui Indique quand le script doit être exécuté. Cette valeur peut être l’une des valeurs suivantes :
  • pré-analyse signifie avant le début du processus d’analyse.
  • scan-success signifie une fois le processus d’analyse terminé avec succès.
  • post-analyse signifie une fois le processus d’analyse terminé, qu’il ait réussi ou non.
  • pré-appliquer signifie avant le début du processus d’application.
  • apply-success signifie que le processus d’application se termine correctement.
  • post-application signifie une fois le processus d’application terminé, qu’il ait réussi ou non.

<plug-in>

Cet élément est un élément USMT interne. N’utilisez pas cet élément.

<rôle>

L’élément <role> est requis dans un fichier .xml personnalisé. Lorsque l’élément <role> est spécifié, un composant concret peut être créé. Le composant est défini par les paramètres spécifiés au niveau du <composant> et avec le rôle spécifié ici.

Syntaxe:

<role role="Container|Binaries|Settings|Data">
</role>
Paramètre Obligatoire ? Valeur
rôle Oui Définit le rôle du composant. Le rôle peut être l’un des éléments suivants :
  • Conteneur
  • Binaires
  • Paramètres
  • Données
L’un des éléments suivants peut être spécifié :
  1. Jusqu’à trois <éléments de rôle> au sein d’un <composant> : un élément de rôle « Binaires », un élément de rôle « Paramètres » et un élément de rôle « Données ». Ces paramètres ne modifient pas le comportement de migration . Leur seul objectif est d’aider à catégoriser les paramètres qui migrent. Ces <éléments de rôle> peuvent être imbriqués, mais chaque élément imbriqué doit être du même paramètre de rôle.
  2. Un élément de rôle> « Container »< au sein d’un <élément de composant>. Dans ce cas, les éléments de règles> enfants< ne peuvent pas être spécifiés, mais uniquement les autres <éléments de composant>. Et chaque élément de composant> enfant< doit avoir le même type que celui de l’élément de composant> parent<. Exemple :
              
              
              <component context="UserAndSystem » type="Application »>
<displayName _locID="migapp.msoffice2016">Microsoft Office 2016</displayName>
<environment name="GlobalEnv » />
<role role="Container »>
<detection name="AnyOffice2016Version » />
<detection name="Word2016 » />
<!--
Paramètres communs d’Office 2016
-->
<component context="UserAndSystem" type="Application">

L’exemple suivant provient du MigUser.xml fichier . Pour plus d’exemples, consultez le MigApp.xml fichier :

<component type="System" context="User">
   <displayName _locID="miguser.startmenu">Start Menu</displayName>
   <paths>
      <path type="File">%CSIDL_STARTMENU%</path>
   </paths>
   <role role="Settings">
      <detects>           
         <detect>
            <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_STARTMENU%")</condition>
         </detect>
      </detects>           
   <rules>
      <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>
            <pattern type="File">%CSIDL_STARTMENU%\* [*]</pattern>
         </objectSet>
      </include>
      <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>
            <pattern type="File">%CSIDL_STARTMENU% [desktop.ini]</pattern>
            <pattern type="File">%CSIDL_STARTMENU%\* [*]</pattern>
         </objectSet>
      </merge>
   </rules>
   </role>
</component>

<règles>

L’élément <rules> est requis dans un fichier .xml personnalisé. Cet élément contient des règles qui s’exécutent pendant la migration si l’élément de composant> parent< est sélectionné, sauf si l’élément de conditions> enfant<, s’il est présent, prend la valeur FALSE. Pour chaque <élément rules>, il peut y avoir plusieurs éléments de règles> enfants<.

Syntaxe:

<rules name="ID" context="User|System|UserAndSystem">
</rules>
Paramètre Obligatoire ? Valeur
name Oui, quand <rules> est un enfant pour <namedElements>
Non, lorsque <les règles> sont un enfant de tout autre élément
Lorsque l’ID est spécifié, les éléments enfants ne sont pas traités. Au lieu de cela, tous les autres <éléments de règles> portant le même nom qui sont déclarés dans <namedElements> sont traités.
contexte Non
(valeur par défaut = UserAndSystem)
Définit l’étendue de ce paramètre : s’il faut traiter ce composant dans le contexte de l’utilisateur spécifique, sur l’ensemble du système d’exploitation, ou les deux.
La plus grande étendue possible est définie par l’élément component. Par exemple, si un <élément de composant> a un contexte Utilisateur et qu’un <élément rules> a un contexte UserAndSystem, l’élément <rules> agit comme s’il avait un contexte Utilisateur. Si <les règles> avaient un contexte de Système, elles agiraient comme si <les règles> n’étaient pas là.
  • Utilisateur : évalue les variables pour chaque utilisateur.
  • Système : évalue les variables une seule fois pour le système.
  • UserAndSystem : évalue les variables de l’ensemble du système d’exploitation et de chaque utilisateur.

L’exemple suivant provient du MigUser.xml fichier :

<component type="Documents" context="User">
   <displayName _locID="miguser.mymusic">My Music</displayName>
      <paths>
         <path type="File">%CSIDL_MYMUSIC%</path>
      </paths>
   <role role="Data">
      <detects>           
      <detect>
         <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYMUSIC%")</condition>
      </detect>
   </detects>           
   <rules>
      <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>
            <pattern type="File">%CSIDL_MYMUSIC%\* [*]</pattern>
         </objectSet>
      </include>
      <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>
            <pattern type="File">%CSIDL_MYMUSIC%\ [desktop.ini]</pattern>
         </objectSet>
      </merge>
   </rules>
   </role>
</component>

<script>

La valeur de retour requise par <le script> dépend de l’élément parent.

Nombre d’occurrences : Une fois pour <la variable>, illimitée pour <objectSet> et <le traitement>

Éléments parents :<objectSet>, <variable>, <traitement>

Éléments enfants : aucun

Syntaxe et fonctions d’assistance :

  • Syntaxe générale : <script>ScriptWithArguments</script>

  • GetStringContent peut être utilisé lorsque <le script> se trouve dans une< variable>.

    Syntaxe: <script>MigXmlHelper.GetStringContent("ObjectType","EncodedLocationPattern", "ExpandContent")</script>

    Exemple: <script>MigXMLHelper.GetStringContent("Registry","HKLM\Software\MyApp\Installer [EXEPATH]")</script>

  • GenerateUserPatterns peut être utilisé lorsque <le script> se trouve dans <objectSet>.

    Syntaxe: <script>MigXmlHelper.GenerateUserPatterns("ObjectType","EncodedLocationPattern","ProcessCurrentUser")</script>

    Exemple: <script>MigXmlHelper.GenerateUserPatterns ("File","%USERPROFILE%\* [*.doc]", "FALSE")</script>

  • GenerateDrivePatterns peut être utilisé lorsque <le script> se trouve dans <objectSet>.

    Syntaxe: <script>MigXmlHelper.GenerateDrivePatterns("PatternSegment","DriveType")</script>

    Exemple: <script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script>

  • Les scripts d’exécution simple peuvent être utilisés avec <les éléments de script> qui se trouvent dans <les éléments de traitement> : AskForLogoff, ConvertToShortFileName, KillExplorer, RemoveEmptyDirectories, RestartExplorer, RegisterFonts, StartService, StopService, SyncSCM.

    Syntaxe: <script>MigXmlHelper.ExecutingScript</script>

    Exemple: <script>MigXmlHelper.KillExplorer()</script>

Paramètre Obligatoire ? Valeur
ScriptWithArguments Oui Script suivi d’un nombre quelconque d’arguments de chaîne séparés par une virgule et placés entre parenthèses. Exemple : MyScripts.AScript ("Arg1","Arg2").
Le script est appelé pour chaque objet énuméré par les jeux d’objets dans la <règle include> . Le script de filtre retourne une valeur booléenne. Si la valeur de retour est TRUE, l’objet est migré. Si la valeur est FALSE, elle n’est pas migrée.
La valeur de retour requise par <le script> dépend de l’élément parent.
  • Lorsqu’elle est utilisée dans <la variable>, la valeur de retour doit être une chaîne.
  • Lorsqu’elle est utilisée dans <objectSet>, la valeur de retour doit être un tableau à deux dimensions de chaînes.
  • Lorsqu’elle est utilisée dans <l’emplacement>, la valeur de retour doit être un emplacement valide qui s’aligne sur l’attribut type de <location>. Par exemple, si <location type="File »>, l’élément de script enfant, s’il est spécifié, doit être un emplacement de fichier valide.
    Remarque
    Si vous migrez un fichier qui a un caractère entre crochets ([ ou ]) dans le nom de fichier, insérez le caractère carotte (^) directement avant le crochet pour qu’il soit valide. Par exemple, s’il existe un fichier nommé « file].txt », spécifiez <pattern type="File">c:\documents\mydocs [file^].txt]</pattern> au lieu de <pattern type="File">c:\documents\mydocs [file].txt]</pattern>.

Exemples :

Pour migrer le fichier Sample.doc à partir de n’importe quel lecteur sur l’ordinateur source, utilisez <le script> comme suit. S’il existe plusieurs fichiers portant le même nom, tous ces fichiers sont migrés.

<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script> 

Pour obtenir d’autres exemples d’utilisation de cet élément, consultez Exclure des fichiers et des paramètres, Réacheminer des fichiers et des paramètres et Exemples XML personnalisés.

<fonctions de script>

Les fonctions suivantes peuvent être utilisées avec l’élément <script>

Fonctions de génération de chaînes et de modèles

Ces fonctions retournent une chaîne ou un modèle.

  • GetStringContent

    GetStringContent peut être utilisé avec <des éléments de script> qui se trouvent dans <des éléments variables> . Si possible, cette fonction retourne la représentation sous forme de chaîne de l’objet donné. Sinon, elle retourne NULL. Pour les objets de fichier, cette fonction retourne toujours NULL.

    Syntaxe: GetStringContent("ObjectType","EncodedLocationPattern", "ExpandContent")

    Paramètre Obligatoire ? Valeur
    ObjectType Oui Type d’objet. Peut être Registry ou Ini (pour un fichier .ini ).
    EncodedLocationPattern Oui
    • Si le type d’objet est Registry, EncodedLocationPattern doit être un chemin d’accès de Registre valide. Exemple : HKLM\SOFTWARE\MyKey[].
    • Si le type d’objet est Ini, EncodedLocationPattern doit être au format suivant :
      IniFilePath|SectionName[SettingName]
    ExpandContent Non (default=TRUE) Peut avoir la valeur TRUE ou FALSE. Si la valeur est FALSE, l’emplacement donné n’est pas développé avant le retour.

    Par exemple :

    <variable name="MSNMessengerInstPath">
    <script>MigXmlHelper.GetStringContent("Registry","%HklmWowSoftware%\Microsoft\MSNMessenger [InstallationDirectory]")</script>
    </variable>
    
  • GenerateDrivePatterns

    La GenerateDrivePatterns fonction itère tous les lecteurs disponibles et sélectionne ceux qui correspondent au type de lecteur demandé. Il concatène ensuite les lecteurs sélectionnés avec la partie finale de PatternSegment pour former un modèle de fichier encodé complet. Par exemple, si PatternSegment est Path [file.txt] et DriveType est Fixed, la fonction génère C:\Path [file.txt], et d’autres modèles s’il existe des lecteurs fixes autres que C :. Les variables d’environnement ne peuvent pas être spécifiées avec cette fonction. GenerateDrivePatterns peut être utilisé avec <des éléments de script> qui se trouvent dans <objectSet> et qui se trouvent dans <include>/<exclude>.

    Syntaxe: GenerateDrivePatterns("PatternSegment","DriveType")

    Paramètre Obligatoire ? Valeur
    PatternSegment Oui Suffixe d’un modèle encodé. La valeur est concaténée avec une spécification de lecteur, telle que « c : », pour former un modèle de fichier encodé complet. Par exemple, « * [*.doc] ». PatternSegment ne peut pas être une variable d’environnement.
    Type de lecteur Oui Type de lecteur pour lequel les modèles doivent être générés. L’un des éléments suivants peut être spécifié :
    • Fixe
    • CDROM
    • Amovible
    • Distant

    Consultez le dernier composant du MigUser.xml fichier pour obtenir un exemple de cet élément.

  • GenerateUserPatterns

    La GenerateUserPatterns fonction itère dans tous les utilisateurs en cours de migration, à l’exception de l’utilisateur actuellement traité si <ProcessCurrentUser> a la valeur FALSE, et développe le modèle spécifié dans le contexte de chaque utilisateur. Par exemple, si les utilisateurs A, B et C ont des profils dans , en C:\Usersappelant GenerateUserPattens('File','%userprofile% [*.doc]','TRUE'), la fonction d’assistance génère les trois modèles suivants :

    • « C :\Users\A\* [*.doc] »

    • « C :\Users\B\* [*.doc] »

    • « C :\Users\C\* [*.doc] »

    Syntaxe: GenerateUserPatterns("ObjectType","EncodedLocationPattern","ProcessCurrentUser")

    Paramètre Obligatoire ? Valeur
    ObjectType Oui Définit le type d’objet. Il peut s’agir d’un fichier ou d’un registre.
    EncodedLocationPattern Oui Modèle d’emplacement. Les variables d’environnement sont autorisées.
    ProcessCurrentUser Oui Peut avoir la valeur TRUE ou FALSE. Indique si les modèles doivent être générés pour l’utilisateur actuel.

Exemple :

Si GenerateUserPattens('File','%userprofile% [*.doc]','FALSE') est appelé pendant que l’outil USMT traite l’utilisateur A, cette fonction génère uniquement des modèles pour les utilisateurs B et C. Cette fonction d’assistance peut être utilisée pour créer des règles complexes. Par exemple, pour migrer tous les .doc fichiers à partir de l’ordinateur source, mais si l’utilisateur X n’est pas migré, ne migrez aucun des .doc fichiers du profil de l’utilisateur X.

L’exemple suivant est un exemple de code pour ce scénario. Le premier <élément de règles> migre tous les .doc fichiers sur l’ordinateur source, à l’exception de ceux à l’intérieur de C:\Users. Les deuxièmes <éléments de règles> migrent tous les .doc fichiers à partir de C:\Users l’exception .doc des fichiers dans les profils des autres utilisateurs. Étant donné que le deuxième <élément de règles> est traité dans chaque contexte utilisateur migré, le résultat final est le comportement souhaité. Le résultat final est celui que nous attendions.

<rules context="System">
  <include>
    <objectSet>
      <script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script>
    </objectSet>
  </include>
  <exclude>
    <objectSet>
      <pattern type="File">%ProfilesFolder%\* [*.doc]</pattern>
    </objectSet>
  </exclude>
</rules>
<rules context="User">
  <include>
    <objectSet>
      <pattern type="File">%ProfilesFolder%\* [*.doc]</pattern>
    </objectSet>
  </include>
  <exclude>
    <objectSet>
      <script>MigXmlHelper.GenerateUserPatterns ("File","%userprofile%\* [*.doc]", "FALSE")</script>
    </objectSet>
  </exclude>
</rules>

MigXmlHelper.GenerateDocPatterns

La MigXmlHelper.GenerateDocPatterns fonction d’assistance appelle la recherche de documents pour analyser le système à la recherche de tous les fichiers pouvant être migrés. Il peut être appelé dans le contexte Système ou Utilisateur pour concentrer l’analyse.

Paramètre Obligatoire ? Valeur
ScanProgramFiles Non (valeur par défaut = FALSE) Peut avoir la valeur TRUE ou FALSE. Le paramètre ScanProgramFiles détermine si le recherche de documents analyse ou non le répertoire Program Files pour collecter les extensions de fichiers inscrites pour les applications connues. Par exemple, lorsqu’il est défini sur TRUE , il découvre et migre .jpg fichiers sous le répertoire Photoshop, si .jpg est une extension de fichier inscrite auprès de Photoshop.
IncludePatterns Non (valeur par défaut = TRUE) Peut avoir la valeur TRUE ou FALSE. TRUE génère des modèles include et peut être ajouté sous l’élément <include> . FALSE génère des modèles d’exclusion et peut être ajouté sous l’élément <exclude> .
SystemDrive Non (valeur par défaut = FALSE) Peut avoir la valeur TRUE ou FALSE. Si la valeur est TRUE, limite tous les modèles au lecteur système.
 <!-- This component migrates data in user context -->
  <component type="Documents" context="User">
    <displayName>MigDocUser</displayName>
    <role role="Data">
      <rules>
        <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
          <objectSet>
            <script>MigXmlHelper.GenerateDocPatterns ("false")</script>
          </objectSet>
        </include>
        <exclude>
          <objectSet>
           <script>MigXmlHelper.GenerateDocPatterns ("false", "false", "false")</script>
          </objectSet>
        </exclude>
      </rules>
    </role>
  </component>

Exécution simple de scripts

Les scripts suivants n’ont aucune valeur de retour. Les erreurs suivantes peuvent être utilisées avec <les éléments de script> qui se trouvent dans <les éléments de traitement>

  • AskForLogoff(). Invite l’utilisateur à se déconnecter à la fin de la migration. Par exemple :

    <processing when="apply-success">
      <script>MigXmlHelper.AskForLogoff()</script>
    </processing>
    
  • ConvertToShortFileName(RegistryEncodedLocation). Si RegistryEncodedLocation est le chemin complet d’un fichier existant, cette fonction convertit le fichier en son nom de fichier court, puis met à jour la valeur du Registre.

  • KillExplorer(). Arrête Explorer.exe pour le contexte utilisateur actuel. L’arrêt Explorer.exe permet d’accéder à certaines clés et fichiers qui restent ouverts quand Explorer.exe est en cours d’exécution. Par exemple :

    <processing when="pre-apply">
      <script>MigXmlHelper.KillExplorer()</script>
    </processing>
    
  • RegisterFonts(FileEncodedLocation). Inscrit la police donnée ou toutes les polices du répertoire donné. Exemple :

 <processing when="apply-success">
   <script>MigXmlHelper.RegisterFonts("%CSIDL_COMMON_FONTS%")</script>
 </processing>
  • RemoveEmptyDirectories (DirectoryEncodedPattern). Supprime tous les répertoires vides qui correspondent à DirectoryEncodedPattern sur l’ordinateur de destination.

  • RestartExplorer(). Redémarre Explorer.exe à la fin de la migration. Exemple :

    <processing when="post-apply">
      <script>MigXmlHelper.RestartExplorer()</script>
    </processing>
    
  • StartService (ServiceName, OptionalParam1, OptionalParam2,...). Démarre le service identifié par ServiceName. ServiceName est la sous-clé dans HKLM\System\CurrentControlSet\Services qui contient les données du service donné. Les paramètres facultatifs, le cas échéant, sont passés à l’API StartService. Pour plus d’informations, consultez l’article Fonction StartServiceA (winsvc.h).

  • StopService (ServiceName). Arrête le service identifié par ServiceName. ServiceName est la sous-clé dans HKLM\System\CurrentControlSet\Services qui contient les données du service donné.

  • SyncSCM(ServiceShortName). Lit la valeur du type de démarrage dans le Registre (HKLM\System\CurrentControlSet\Services\ServiceShortName [Start]) une fois que la valeur a été modifiée par le moteur de migration, puis synchronise Service Control Manager (SCM) avec la nouvelle valeur.

<SMS>

L’élément <text> peut être utilisé pour définir une valeur pour toutes les variables d’environnement qui se trouvent dans l’un des fichiers .xml de migration.

Syntaxe:

<text>NormalText</text>
Paramètre Valeur
NormalText Ce texte est interprété comme du texte normal.

Exemple :

<variable name="QuickTime5or6DataSys">
  <text>%CSIDL_COMMON_APPDATA%\QuickTime</text> 
</variable>

<unconditionalExclude>

L’élément <unconditionalExclude> exclut les fichiers et les valeurs de Registre spécifiés de la migration, quelles que soient les autres règles d’inclusion dans les fichiers .xml de migration ou dans le Config.xml fichier. Les objets déclarés ici ne sont pas migrés, car cet élément est prioritaire sur toutes les autres règles. Par exemple, même s’il existe des règles include> explicites< pour inclure des .mp3 fichiers, s’ils sont exclus avec cette option, ils ne sont pas migrés.

Utilisez cet élément pour exclure tous les .mp3 fichiers de l’ordinateur source. Ou, si vous sauvegardez à l’aide C:\UserData d’une autre méthode, le dossier entier peut être exclu de la migration. Utilisez cet élément avec précaution. Si une application a besoin d’un fichier exclu, l’application risque de ne pas fonctionner correctement sur l’ordinateur de destination.

  • Nombre d’occurrences : Illimité.

  • Éléments parents :<rules>

  • Éléments enfants :<objectSet>

Syntaxe:

<unconditionalExclude></unconditionalExclude>

Le fichier .xml suivant exclut tous les .mp3 fichiers de la migration. Pour obtenir d’autres exemples d’utilisation de cet élément, consultez Exclure des fichiers et des paramètres.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/excludefiles">
  <component context="System" type="Documents">
        <displayName>Test</displayName>
        <role role="Data">
            <rules>
             <unconditionalExclude>
                        <objectSet>
    <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>
                        </objectSet> 
             </unconditionalExclude>
            </rules>
        </role>
    </component>
</migration>

<variable>

L’élément <variable> est requis dans un élément d’environnement<>. Pour chaque <élément variable> , il doit y avoir un <élément objectSet>, <script> ou <text> . Le contenu de l’élément <variable> affecte une valeur de texte à la variable d’environnement. Cet élément a les trois options suivantes :

  1. Si l’élément <variable> contient un <élément de texte> , la valeur de l’élément variable est la valeur de l’élément <text> .

  2. Si l’élément <variable> contient un <élément script> et que l’appel du script produit une chaîne non null, la valeur de l’élément <variable> est le résultat de l’appel du script.

  3. Si l’élément <variable> contient un <élément objectSet> et que l’évaluation de l’élément <objectSet> produit au moins un modèle d’objet, la valeur du premier objet correspondant au modèle d’objet obtenu est la valeur de l’élément variable.

Syntaxe:

<variable name="ID" remap=TRUE|FALSE>
</variable>
Paramètre Obligatoire ? Valeur
name Oui ID est une valeur de chaîne qui est le nom utilisé pour référencer la variable d’environnement. Microsoft recommande que l’ID commence par le nom du composant pour éviter les collisions d’espaces de noms. Par exemple, si le nom du composant est MyComponent et qu’une variable souhaitée qui est le chemin d’installation du composant, MyComponent.InstallPathpeut être spécifiée.
Remapper Non, valeur par défaut = FALSE Spécifie s’il faut évaluer cette variable d’environnement en tant que variable d’environnement de remappage. Les objets situés dans un chemin situé sous la valeur de cette variable d’environnement sont automatiquement déplacés vers l’emplacement où la variable d’environnement pointe sur l’ordinateur de destination.

L’exemple suivant provient du MigApp.xml fichier :

<environment>
   <variable name="HklmWowSoftware">
      <text>HKLM\Software</text>
   </variable>
   <variable name="WinZip8or9or10Exe">
      <script>MigXmlHelper.GetStringContent("Registry","%HklmWowSoftware%\Microsoft\Windows\CurrentVersion\App Paths\winzip32.exe []")</script>
   </variable>
</environment>

<version>

L’élément< version> définit la version du composant, mais n’affecte pas la migration.

  • Nombre d’occurrences : zéro ou une

  • Éléments parents :<component>

  • Éléments enfants : aucun

Syntaxe:

<version>ComponentVersion</version>
Paramètre Obligatoire ? Valeur
ComponentVersion Oui Version du composant, qui peut contenir des modèles.

Exemple :

<version>4.*</version>

<windowsObjects>

L’élément <windowsObjects> est destiné à un usage interne USMT uniquement. N’utilisez pas cet élément.

Annexe

Spécification des emplacements

  • Spécification des emplacements encodés. L’emplacement encodé utilisé dans toutes les fonctions d’assistance est une représentation sous forme de chaîne non ambiguë pour le nom d’un objet. L’emplacement encodé est composé de la partie de nœud, éventuellement suivie de la feuille entre crochets. Ce format fait une distinction claire entre les nœuds et les feuilles.

    Par exemple, spécifiez le fichier C:\Windows\Notepad.exe comme suit : c:\Windows[Notepad.exe]. De même, spécifiez le répertoire C:\Windows\System32 comme suit : c:\Windows\System32. (Notez l’absence de la [] construction.)

    La représentation du registre est similaire. La valeur par défaut d’une clé de Registre est représentée sous la forme d’une construction vide [] . Par exemple, la valeur par défaut de la clé de HKLM\SOFTWARE\MyKey Registre est HKLM\SOFTWARE\MyKey[].

  • Spécification de modèles d’emplacement. La spécification d’un modèle d’emplacement est similaire à la spécification d’un emplacement réel. L’exception est que le nœud et la partie feuille acceptent des modèles. Toutefois, un modèle du nœud ne s’étend pas à la feuille.

    Par exemple, le modèle c:\Windows\* correspond au répertoire Windows et à tous les sous-répertoires, mais il ne correspond à aucun des fichiers de ces répertoires. Pour correspondre également aux fichiers, c:\Windows\*[*] doit être spécifié.

Fonctions USMT internes

Les fonctions suivantes sont destinées à une utilisation usMT interne uniquement. Ne les utilisez pas dans un fichier .xml .

  • AntiAlias

  • ConvertScreenSaver

  • ConvertShowIEOnDesktop

  • ConvertToOfficeLangID

  • MigrateActiveDesktop

  • MigrateAppearanceUPM

  • MigrateDisplayCS

  • MigrateDisplaySS

  • MigrateIEAutoSearch

  • MigrateMouseUPM

  • MigrateSoundSysTray

  • MigrateTaskBarss

  • SetPstPathInMapiStruc

Balises de version valides

Les balises de version suivantes peuvent être utilisées avec différentes fonctions d’assistance :

  • « CompanyName »

  • « FileDescription »

  • « FileVersion »

  • « InternalName »

  • « LegalCopyright »

  • « OriginalFilename »

  • « ProductName »

  • « ProductVersion »

Les balises de version suivantes contiennent des valeurs qui peuvent être comparées :

  • « FileVersion »

  • « ProductVersion »