XML-Elementbibliothek

Übersicht

In diesem Thema werden die XML-Elemente und -Hilfsfunktionen beschrieben, die Sie zum Erstellen von XML-Dateien für die Migration mit Windows-EasyTransfer verwenden können. Es wird vorausgesetzt, dass Sie mit den Grundlagen von XML vertraut sind. .

Inhalt dieses Themas

Neben XML-Elementen und -Hilfsfunktionen wird in diesem Thema beschrieben, wie Sie codierte Speicherorte und Speicherortmuster, interne USMT-Funktionen und die für Hilfsfunktionen verfügbaren Versionsmarkierungen angeben.

• Elemente und Hilfsfunktionen

• Anhang

  • Angeben von Speicherorten

  • Interne USMT-Funktionen

  • Gültige Versionsmarkierungen

Elemente und Hilfsfunktionen

In der folgenden Tabelle werden die XML-Elemente und -Hilfsfunktionen beschrieben, die Sie mit USMT verwenden können.

Elemente A-K	Elemente L-Z	Hilfsfunktionen
<addObjects> <attributes> <bytes> <commandLine> <component> <condition> <conditions> <content> <contentModify> <description> <destinationCleanup> <detect> <detects> <detection> <displayName> <environment> <exclude> <excludeAttributes> <extensions> <extension> <externalProcess> <icon> <include> <includeAttributes>	<library> <location> <locationModify> <_locDefinition> <manufacturer> <merge> <migration> <namedElements> <object> <objectSet> <path> <paths> <pattern> <processing> <plugin> <role> <rules> <script> <text> <unconditionalExclude> <variable> <version> <windowsObjects>	<condition>-Funktionen <content>-Funktionen <contentModify>-Funktionen <include>- und <exclude>-Filterfunktionen <locationModify>-Funktionen <merge>-Funktionen <script>-Funktionen Interne USMT-Funktionen

<addObjects>

Das <addObjects>-Element emuliert das Vorhandensein von Objekten auf dem Quell-PC. Die untergeordneten <object>-Elemente stellen die Details der emulierten Objekte bereit. Wenn es sich beim Inhalt um ein <script>-Element handelt, ist das Ergebnis des Aufrufs ein Array von Objekten.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliche untergeordnete Elemente: <object>, außerdem müssen Sie <location> und <attributes> als untergeordnete Elemente dieses <object>-Elements angeben.

• Optionale untergeordnete Elemente: <conditions>, <condition>, <script>

Syntax:

<addObjects>

</addObjects>

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<attributes>

Das <attributes>-Element definiert die Attribute für einen Registrierungsschlüssel oder eine Registrierungsdatei.

• Anzahl von Vorkommen: eins für jedes <object>

• Übergeordnete Elemente: <object>

• Untergeordnete Elemente: keine

Syntax:

<attributes>Content</attributes>

Einstellung	Erforderlich?	Wert
Content	Ja	Der Inhalt (Content) hängt vom angegebenen Objekttyp ab. Bei Dateien kann der Inhalt eine Zeichenfolge mit den folgenden, durch Kommas getrennten Attributen sein: Archive Read-only System Hidden Bei Registrierungsschlüsseln kann der Inhalt einer der folgenden Typen sein: None Zeichenfolge ExpandString Binary Dword REG_SZ

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<bytes>

Sie müssen das <bytes>-Element nur für Dateien angeben, da es ignoriert wird, wenn mit <location> ein Registrierungsschlüssel oder Verzeichnis angegeben wird.

• Anzahl von Vorkommen: keine oder eins

• Übergeordnete Elemente: <object>

• Untergeordnete Elemente: keine

Syntax:

<bytes string="Yes|No" expand="Yes|No">Content</bytes>

Einstellung	Erforderlich?	Wert
zeichenfolge	Nein, der Standardwert ist „No“	Bestimmt, ob Content als Zeichenfolge oder als Bytes interpretiert werden soll.
expand	Nein, der Standardwert ist „Yes“	Wenn der expand-Parameter auf „Yes“ festgelegt ist, wird der Inhalt des <bytes>-Elements zuerst im Kontext des Quell-PC erweitert und dann interpretiert.
Content	Ja	Hängt vom Wert der Zeichenfolge ab. Wenn die Zeichenfolge „Yes“ ist, wird der Inhalt des <bytes>-Elements als Zeichenfolge interpretiert. Wenn die Zeichenfolge „No“ ist, wird der Inhalt des <bytes>-Elements als Bytes interpretiert. Zwei Zeichen stellen jeweils den Hexadezimalwert eines Bytes dar. So ist 616263 z. B. die Darstellung für die ANSI-Zeichenfolge „abc“. Eine vollständige Darstellung der UNICODE-Zeichenfolge „abc“ einschließlich Zeichenfolgen-Abschlusszeichen wäre 6100620063000000.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<commandLine>

Sie können das <commandLine>-Element verwenden, wenn Sie einen Dienst oder eine App vor oder nach dem Ausführen von ScanState und LoadState starten oder beenden möchten.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <externalProcess>

• Untergeordnete Elemente:: keine

Syntax:

<commandLine>CommandLineString</commandLine>

Einstellung	Erforderlich?	Wert
CommandLineString	Ja	Eine gültige Befehlszeile.

<component>

Das <component>-Element ist in einer benutzerdefinierten XML-Datei erforderlich. Dieses Element definiert das einfachste Konstrukt einer XML-Migrationsdatei. In der Datei „MigApp.xml“ ist „Microsoft(R) Office 2003“ z. B. eine Komponente, die eine andere Komponente („Microsoft Office Access(R) 2003“) enthält. Sie können die untergeordneten Elemente verwenden, um die Komponente zu definieren.

Eine Komponente kann in einer anderen Komponente geschachtelt werden. In zwei Fällen kann das <component>-Element also ein untergeordnetes Element des <role>-Elements im <component>-Element sein: 1) Wenn das übergeordnete <component>-Element ein Container ist oder 2) wenn das untergeordnete <component>-Element die gleiche Rolle hat wie das übergeordnete <component>-Element.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <migration>, <role>

• Erforderliche untergeordnete Elemente: <role>, <displayName>

• Optionale untergeordnete Elemente: <manufacturer>, <version>, <description>, <paths>, <icon>, <environment>, <extensions>

Syntax:

<component type="System|Application|Device|Documents" context="User|System|UserAndSystem" defaultSupported="TRUE|FALSE|YES|NO"

hidden="Yes|No">

</component>

Einstellung	Erforderlich?	Wert
type	Ja	Sie können die folgenden Werte verwenden, um Einstellungen zu gruppieren und den Typ der Komponente zu definieren. System: Betriebssystemeinstellungen. Alle Windows®-Komponenten werden mit diesem Typ definiert. Wenn type="System" und defaultSupported="FALSE" festgelegt sind, werden die Einstellungen nur migriert, wenn eine entsprechende Komponente in den in der LoadState-Befehlszeile angegebenen XML-Dateien vorhanden ist. Die standardmäßige Datei "MigSys.xml" enthält z. B. Komponenten mit type="System" und defaultSupported="FALSE". Wenn Sie diese Datei in der ScanState-Befehlszeile angeben, müssen Sie sie auch in der LoadState-Befehlszeile angeben, damit die Einstellungen migriert werden. Dies ist darauf zurückzuführen, dass LoadState eine entsprechende Komponente ermitteln muss. Die Komponente muss also die gleiche Migrations-UrlId der XML-Datei und den gleichen Anzeigenamen haben. Andernfalls migriert LoadState diese Einstellungen nicht aus dem Speicher. Dies ist hilfreich, wenn auf dem Quellcomputer Windows XP ausgeführt wird und Sie sowohl zu Windows Vista® als auch zu Windows XP migrieren, da der gleiche Speicher für beide Zielcomputer verwendet werden kann. Application: Einstellungen für eine App. Device: Einstellungen für ein Gerät. Documents: Gibt Dateien an.
context	Nein Standardwert = UserAndSystem	Definiert den Gültigkeitsbereich dieses Parameters, d. h. ob die Komponente im Kontext des jeweiligen Benutzers und/oder für das gesamte Betriebssystem verarbeitet werden soll. Der größtmögliche Bereich wird mit dem <component>-Element festgelegt. Wenn für ein <component>-Element z. B. der Kontext „User“ festgelegt ist und für ein <rules>-Element der Kontext „UserAndSystem“, verhält sich das <rules>-Element als wäre sein Kontext „User“. Wenn für ein <rules>-Element der Kontext „System“ festgelegt ist, verhält es sich als wäre das <rules>-Element nicht vorhanden. User. Wertet die Komponente für jeden Benutzer aus. System. Wertet die Komponente nur einmal für das System aus. UserAndSystem. Wertet die Komponente für das gesamte Betriebssystem und jeden Benutzer aus.
defaultSupported	Nein (Standardwert = TRUE)	Kann TRUE, FALSE, YES oder NO sein. Wenn dieser Parameter auf FALSE (oder NO) festgelegt ist, wird die Komponente nur migriert, wenn eine entsprechende Komponente auf dem Ziel-PC vorhanden ist. Wenn type="System" und defaultSupported="FALSE" festgelegt sind, werden die Einstellungen nur migriert, wenn eine entsprechende Komponente in den in der LoadState-Befehlszeile angegebenen XML-Dateien vorhanden ist. Die standardmäßige Datei "MigSys.xml" enthält z. B. Komponenten mit type="System" und defaultSupported="FALSE". Wenn Sie diese Datei in der ScanState-Befehlszeile angeben, müssen Sie sie auch in der LoadState-Befehlszeile angeben, damit die Einstellungen migriert werden. Dies ist darauf zurückzuführen, dass LoadState eine entsprechende Komponente ermitteln muss. Die Komponente muss also die gleiche Migrations-UrlId der XML-Datei und den gleichen Anzeigenamen haben. Andernfalls werden diese Einstellungen nicht aus dem Speicher migriert. Dies ist hilfreich, wenn auf dem Quellcomputer Windows XP ausgeführt wird und Sie sowohl zu Windows Vista als auch zu Windows XP migrieren, da der gleiche Speicher für beide Zielcomputer verwendet werden kann.
hidden		Dieser Parameter dient nur zur internen Verwendung in USMT.

Ein Beispiel finden Sie in den standardmäßigen XML-Migrationsdateien.

<condition>

Das <condition>-Element unter den Elementen <detect>, <objectSet> und <addObjects> wird zwar unterstützt, von seiner Verwendung wird aber abgeraten. Dieses Element wird in zukünftigen Versionen von USMT möglicherweise nicht mehr unterstützt, sodass Sie Ihre Skripts neu schreiben müssten. Wir empfehlen, das leistungsstärkere <conditions>-Element zu verwenden, wenn Sie eine Bedingung in den <objectSet>- und <addObjects>-Elementen benötigen. Mit diesem Element können Sie komplexe boolesche Anweisungen formulieren.

Das <condition>-Element hat ein boolesches Ergebnis. Sie können mit diesem Element die Bedingungen angeben, unter denen das übergeordnete Element ausgewertet wird. Wenn eine der vorhandenen Bedingungen FALSE zurückgibt, wird das übergeordnete Element nicht ausgewertet.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <conditions>, <detect>, <objectSet>, <addObjects>

• Untergeordnete Elemente: keine

• Hilfsfunktionen: Sie können die folgenden <condition>-Funktionen mit diesem Element verwenden: DoesOSMatch, IsNative64Bit(), IsOSLaterThan, IsOSEarlierThan, DoesObjectExist, DoesFileVersionMatch, IsFileVersionAbove, IsFileVersionBelow, IsSystemContext, DoesStringContentEqual, DoesStringContentContain, IsSameObject, IsSameContent und IsSameStringContent.

Syntax:

<condition negation="Yes|No">ScriptName</condition>

Einstellung	Erforderlich?	Wert
negation	No Standardwert = No	„Yes“ kehrt den True/False-Wert der Bedingung um.
ScriptName	Ja	Ein Skript, das in diesem Migrationsabschnitt definiert wurde.

Beispiel

Im folgenden Codebeispiel werden die <condition>-Elemente A und B durch den AND-Operator verbunden, da sie in separaten <conditions>-Abschnitten enthalten sind. Beispiel:

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

Im folgenden Codebeispiel werden die <condition>-Elemente A und B dagegen durch den OR-Operator verbunden, da sie in demselben <conditions>-Abschnitt enthalten sind.

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

<condition>-Funktionen

Die <condition>-Funktionen geben einen booleschen Wert zurück. Sie können diese Elemente in <addObjects>-Bedingungen verwenden.

• Funktionen für die Betriebssystemversion

• Objektinhaltsfunktionen

Funktionen für die Betriebssystemversion

• DoesOSMatch

  Bei allen Vergleichen wird die Groß-/Kleinschreibung nicht beachtet.

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

  Einstellung	Erforderlich?	Wert
  OSType	Ja	Der einzige gültige Wert für diese Einstellung ist NT. Beachten Sie aber, dass Sie diese Einstellung festlegen müssen, damit die <condition>-Funktionen richtig funktionieren.
  OSVersion	Ja	Die Hauptversion, Nebenversion, Buildnummer und korrigierte Wartungsdiskettenversion getrennt durch Punkte. Beispielsweise 5.0.2600.Service Pack 1. Sie können auch nur einen Teil der Version mit einem Muster angeben. Beispielsweise 5.0.*.

  Beispiel:

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

• IsNative64Bit

  Die IsNative64Bit-Funktion gibt TRUE zurück, wenn der Migrationsprozess als systemeigener 64-Bit-Prozess ausgeführt wird, d. h. als Prozess, der auf einem 64-Bit-System ohne Windows on Windows (WOW) ausgeführt wird. Andernfalls gibt sie FALSE zurück.

• IsOSLaterThan

  Bei allen Vergleichen wird die Groß-/Kleinschreibung nicht beachtet.

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

  Einstellung	Erforderlich?	Wert
  OSType	Ja	Kann 9x oder NT sein. Wenn OSType nicht dem Typ des aktuellen Betriebssystems entspricht, wird FALSE zurückgegeben. Ist das aktuelle Betriebssystem z. B. Windows NT-basiert und OSType auf "9x" festgelegt, ist das Ergebnis FALSE.
  OSVersion	Ja	Die Hauptversion, Nebenversion, Buildnummer und korrigierte Wartungsdiskettenversion getrennt durch Punkte. Beispielsweise 5.0.2600.Service Pack 1. Sie können auch nur einen Teil der Version angeben, ein Muster ist aber nicht zulässig. Beispielsweise 5.0. Die IsOSLaterThan-Funktion gibt TRUE zurück, wenn das aktuelle Betriebssystem neuer als OSVersion ist oder dieser Version entspricht.

  Beispiel:

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

• IsOSEarlierThan

  Bei allen Vergleichen wird die Groß-/Kleinschreibung nicht beachtet.

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

  Einstellung	Erforderlich?	Wert
  OSType	Ja	Kann 9x oder NT sein. Wenn OSType nicht dem Typ des aktuellen Betriebssystems entspricht, wird FALSE zurückgegeben. Ist das aktuelle Betriebssystem z. B. Windows NT-basiert und OSType auf "9x" festgelegt, ist das Ergebnis FALSE.
  OSVersion	Ja	Die Hauptversion, Nebenversion, Buildnummer und korrigierte Wartungsdiskettenversion getrennt durch Punkte. Beispielsweise 5.0.2600.Service Pack 1. Sie können auch nur einen Teil der Version angeben, ein Muster ist aber nicht zulässig. Beispielsweise 5.0. Die IsOSEarlierThan-Funktion gibt TRUE zurück, wenn das aktuelle Betriebssystem neuer als OSVersion ist.

Objektinhaltsfunktionen

• DoesObjectExist

  Die DoesObjectExist-Funktion gibt TRUE zurück, wenn Objekte vorhanden sind, die dem Speicherortmuster entsprechen. Andernfalls gibt sie FALSE zurück. Das Speicherortmuster wird vor dem Erstellen der Enumeration erweitert.

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

  Einstellung	Erforderlich?	Wert
  ObjectType	Ja	Definiert den Objekttyp. Kann „File“ oder „Registry“ sein.
  EncodedLocationPattern	Ja	Das Angeben von Speicherorten. Umgebungsvariablen sind zulässig.

  Ein Beispiel für dieses Element finden Sie in der Datei „MigApp.xml“.

• DoesFileVersionMatch

  Die Groß-/Kleinschreibung wird bei der Musterüberprüfung nicht beachtet.

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

  Einstellung	Erforderlich?	Wert
  EncodedFileLocation	Ja	Das Angeben von Speicherorten für die zu überprüfende Datei. Umgebungsvariablen sind zulässig.
  VersionTag	Ja	Der zu überprüfende Gültige Versionsmarkierungen.
  VersionValue	Ja	Ein Zeichenfolgenmuster, z. B. „Microsoft“.

  Beispiel:

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

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

• IsFileVersionAbove

  Die IsFileVersionAbove-Funktion gibt TRUE zurück, wenn die Version der Datei höher ist als VersionValue.

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

  Einstellung	Erforderlich?	Wert
  EncodedFileLocation	Ja	Das Angeben von Speicherorten für die zu überprüfende Datei. Umgebungsvariablen sind zulässig.
  VersionTag	Ja	Der zu überprüfende Gültige Versionsmarkierungen.
  VersionValue	Ja	Der zu vergleichende Wert. Sie können kein Muster angeben.

• IsFileVersionBelow

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

  Einstellung	Erforderlich?	Wert
  EncodedFileLocation	Ja	Das Angeben von Speicherorten für die zu überprüfende Datei. Umgebungsvariablen sind zulässig.
  VersionTag	Ja	Der zu überprüfende Gültige Versionsmarkierungen.
  VersionValue	Ja	Der zu vergleichende Wert. Sie können kein Muster angeben.

• IsSystemContext

  Die IsSystemContext-Funktion gibt TRUE zurück, wenn der aktuelle Kontext „System“ ist. Andernfalls gibt sie FALSE zurück.

  Syntax: IsSystemContext()

• DoesStringContentEqual

  Die DoesStringContentEqual-Funktion gibt TRUE zurück, wenn die Zeichenfolgendarstellung der angegebenen Objekte StringContent entspricht.

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

  Einstellung	Erforderlich?	Wert
  ObjectType	Ja	Definiert den Typ des Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocationPattern	Ja	Der Angeben von Speicherorten für das zu untersuchende Objekt. Sie können Umgebungsvariablen angeben.
  StringContent	Ja	Die Zeichenfolge, mit der verglichen wird.

  Beispiel:

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

• DoesStringContentContain

  Die DoesStringContentContain-Funktion gibt TRUE zurück, wenn mindestens ein Vorkommen von StrToFind in der Zeichenfolgendarstellung des Objekts vorhanden ist.

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

  Einstellung	Erforderlich?	Wert
  ObjectType	Ja	Definiert den Typ des Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocationPattern	Ja	Der Angeben von Speicherorten für das zu untersuchende Objekt. Sie können Umgebungsvariablen angeben.
  StrToFind	Ja	Eine Zeichenfolge, nach der im Inhalt des angegebenen Objekts gesucht wird.

• IsSameObject

  Die IsSameObject-Funktion gibt TRUE zurück, wenn die angegebenen codierten Speicherorte zu demselben physischen Objekt aufgelöst werden. Andernfalls gibt sie FALSE zurück.

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

  Einstellung	Erforderlich?	Wert
  ObjectType	Ja	Definiert den Typ des Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocation1	Ja	Der Angeben von Speicherorten für das erste Objekt. Sie können Umgebungsvariablen angeben.
  EncodedLocation2	Ja	Der Angeben von Speicherorten für das zweite Objekt. Sie können Umgebungsvariablen angeben.

  Beispiel:

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

• IsSameContent

  Die IsSameContent-Funktion gibt TRUE zurück, wenn die angegebenen Objekte den gleichen Inhalt haben. Andernfalls gibt sie FALSE zurück. Der Inhalt wird Byte für Byte verglichen.

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

  Einstellung	Erforderlich?	Wert
  ObjectType1	Ja	Definiert den Typ des ersten Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocation1	Ja	Der Angeben von Speicherorten für das erste Objekt. Sie können Umgebungsvariablen angeben.
  ObjectType2	Ja	Definiert den Typ des zweiten Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocation2	Ja	Der Angeben von Speicherorten für das zweite Objekt. Sie können Umgebungsvariablen angeben.

• IsSameStringContent

  Die IsSameStringContent-Funktion gibt TRUE zurück, wenn die angegebenen Objekte den gleichen Inhalt haben. Andernfalls gibt sie FALSE zurück. Der Inhalt wird als Zeichenfolge interpretiert.

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

  Einstellung	Erforderlich?	Wert
  ObjectType1	Ja	Definiert den Typ des ersten Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocation1	Ja	Der Angeben von Speicherorten für das erste Objekt. Sie können Umgebungsvariablen angeben.
  ObjectType2	Ja	Definiert den Typ des zweiten Objekts. Kann „File“ oder „Registry“ sein.
  EncodedLocation2	Ja	Der Angeben von Speicherorten für das zweite Objekt. Sie können Umgebungsvariablen angeben.

<conditions>

Das <conditions>-Element gibt ein boolesches Ergebnis zurück, mit dem die Bedingungen angegeben werden, unter denen das übergeordnete Element ausgewertet wird. USMT wertet die untergeordneten Elemente aus und verbindet ihre Ergebnisse anschließend entsprechend dem operation-Parameter mit den AND- oder OR-Operatoren.

• Anzahl von Vorkommen: unbegrenzt innerhalb eines anderen <conditions>-Elements, begrenzt auf ein Vorkommen in <detection>, <rules>, <addObjects> und <objectSet>

• Übergeordnete Elemente: <conditions>, <detection>, <environment>, <rules>, <addObjects> und <objectSet>

• Untergeordnete Elemente: <conditions>, <condition>

Syntax:

<conditions operation="AND|OR">

</conditions>

Einstellung	Erforderlich?	Wert
operation	Nein, Standardwert = AND	Definiert den booleschen Vorgang, der für die Ergebnisse der untergeordneten Elemente ausgeführt wird.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<content>

Sie können mit dem <content>-Element eine Liste von Objektmustern angeben, um einen Objektsatz vom Quell-PC abzurufen. Jedes <objectSet> in einem <content>-Element wird ausgewertet. Für jede resultierende Objektmusterliste werden die übereinstimmenden Objekte aufgelistet, und ihr Inhalt wird mit dem Filterparameter gefiltert. Das resultierende Zeichenfolgenarray ist die Ausgabe für das <content>-Element. Das Filterskript gibt ein Array von Speicherorten zurück. Das übergeordnete <objectSet>-Element kann mehrere untergeordnete <content>-Elemente enthalten.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <objectSet>

• Untergeordnete Elemente: <objectSet>

• Hilfsfunktionen: Sie können die folgenden <content>-Funktionen mit diesem Element verwenden: ExtractSingleFile, ExtractMultipleFiles und ExtractDirectory.

Syntax:

<content filter="ScriptInvocation">

</content>

Einstellung	Erforderlich?	Wert
filter	Ja	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der <include>-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

<content>-Funktionen

Die folgenden Funktionen generieren Muster aus dem Inhalt eines Objekts. Diese Funktionen werden für jedes vom übergeordneten <ObjectSet>-Element aufgelistete Objekt aufgerufen.

• ExtractSingleFile

  Wenn der Registrierungswert ein MULTI-SZ-Wert ist, wird nur das erste Segment verarbeitet. Das zurückgegebene Muster ist der codierte Speicherort für eine Datei, die auf dem System vorhanden sein muss. Wenn die Angabe im Registrierungswert richtig, die Datei aber nicht vorhanden ist, gibt die Funktion NULL zurück.

  Syntax: ExtractSingleFile(Separators,PathHints)

  Einstellung	Erforderlich?	Wert
  Separators	Ja	Eine Liste möglicher Trennzeichen, die im Namen des Registrierungswerts nach der Datei stehen können. Bei „C:\Windows\Notepad.exe,-2“ ist das Trennzeichen z. B. ein Komma. Sie können NULL angeben.
  PathHints	Ja	Eine durch Semikolons getrennte Liste zusätzlicher Pfade, an denen die Funktion nach einer Datei sucht, die dem aktuellen Inhalt entspricht. Wenn der Inhalt z. B. "Notepad.exe" ist und für den Pfad die %Path%-Umgebungsvariable angegeben wurde, sucht die Funktion in "%windir%" nach "Notepad.exe" und gibt "c:\Windows [Notepad.exe]" zurück. Sie können NULL angeben.

  Beispiel:

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

  und

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

• ExtractMultipleFiles

  Die ExtractMultipleFiles-Funktion gibt mehrere Muster zurück – eins für jede Datei, die im Inhalt des angegebenen Registrierungswerts gefunden wird. Wenn der Registrierungswert ein MULTI-SZ-Wert ist, wird das MULTI-SZ-Trennzeichen standardmäßig als Trennzeichen verwendet. Für MULTI-SZ-Werte muss das <Separators>-Argument daher NULL sein.

  Die zurückgegebenen Muster sind die codierten Speicherorte für Dateien, die auf dem Quell-PC vorhanden sein müssen. Wenn die Angabe im Registrierungswert richtig, die Datei aber nicht vorhanden ist, wird sie nicht in der resultierenden Liste aufgeführt.

  Syntax: ExtractMultipleFiles(Separators,PathHints)

  Einstellung	Erforderlich?	Wert
  Separators	Ja	Eine Liste möglicher Trennzeichen, die im Namen des Registrierungswerts nach der Datei stehen können. Bei „C:\Windows\Notepad.exe,-2“ ist das Trennzeichen z. B. ein Komma. Dieser Parameter muss NULL sein, wenn Sie MULTI-SZ-Registrierungswerte verarbeiten.
  PathHints	Ja	Eine durch Semikolons getrennte Liste zusätzlicher Pfade, an denen die Funktion nach einer Datei sucht, die dem aktuellen Inhalt entspricht. Wenn der Inhalt z. B. "Notepad.exe" ist und für den Pfad die %Path%-Umgebungsvariable angegeben wurde, sucht die Funktion in "%windir%" nach "Notepad.exe" und gibt "c:\Windows [Notepad.exe]" zurück. Sie können NULL angeben.

• ExtractDirectory

  Die ExtractDirectory-Funktion gibt ein Muster zurück, bei dem es sich um den codierten Speicherort für ein Verzeichnis handelt, das auf dem System vorhanden sein muss. Wenn die Angabe im Registrierungswert richtig, das Verzeichnis aber nicht vorhanden ist, gibt die Funktion NULL zurück. Im Fall eines MULTI-SZ-Registrierungswerts wird nur das erste Segment verarbeitet.

  Syntax: ExtractDirectory(Separators,LevelsToTrim,PatternSuffix)

  Einstellung	Erforderlich?	Wert
  Separators	Nein	Eine Liste möglicher Trennzeichen, die im Namen des Registrierungswerts nach der Datei stehen können. Bei „C:\Windows\Notepad.exe,-2“ ist das Trennzeichen z. B. ein Komma. Sie müssen NULL angeben, wenn Sie MULTI-SZ-Registrierungswerte verarbeiten.
  LevelsToTrim	Ja	Die Anzahl von Ebenen, die am Ende der Verzeichnisangabe gelöscht werden soll. Verwenden Sie diese Funktion, um ein Stammverzeichnis zu extrahieren, wenn ein Registrierungswert an einem bekannten Speicherort in das Stammverzeichnis verweist.
  PatternSuffix	Ja	Das Muster, das der Verzeichnisangabe hinzugefügt werden soll. Beispielsweise * [*].

  Beispiel:

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

<contentModify>

Das <contentModify>-Element ändert den Inhalt eines Objekts, bevor es auf den Ziel-PC geschrieben wird. Für jedes <contentModify>-Element können mehrere <objectSet>-Elemente vorhanden sein. Dieses Element gibt den neuen Inhalt des verarbeiteten Objekts zurück.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliche untergeordnete Elemente: <objectSet>

• Hilfsfunktionen: Sie können die folgenden <contentModify>-Funktionen mit diesem Element verwenden: ConvertToDWORD, ConvertToString, ConvertToBinary, KeepExisting, OffsetValue, SetValueByTable, MergeMultiSzContent und MergeDelimitedContent.

Syntax:

<contentModify script="ScriptInvocation">

</contentModify>

Einstellung	Erforderlich?	Value
script	Ja	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der Include-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

<contentModify>-Funktionen

Die folgenden Funktionen ändern den Inhalt von Objekten, während sie migriert werden. Diese Funktionen werden für jedes vom übergeordneten <ObjectSet>-Element aufgelistete Objekt aufgerufen.

• ConvertToDWORD

  Die ConvertToDWORD-Funktion konvertiert den Inhalt von Registrierungswerten, die vom übergeordneten <ObjectSet>-Element aufgelistet werden, in einen DWORD-Wert. ConvertToDWORD konvertiert die Zeichenfolge 1 z. B. in den DWORD-Wert 0x00000001. Falls die Konvertierung fehlschlägt, wird der Wert von „DefaultValueOnError“ angewendet.

  Syntax: ConvertToDWORD(DefaultValueOnError)

  Einstellung	Erforderlich?	Wert
  DefaultValueOnError	Nein	Der Wert, der in den Wertnamen geschrieben wird, wenn die Konvertierung fehlschlägt. Sie können NULL angeben. 0 wird ausgegeben, wenn die Konvertierung fehlschlägt.

• ConvertToString

  Die ConvertToString-Funktion konvertiert den Inhalt von Registrierungswerten, die dem übergeordneten <ObjectSet>-Element entsprechen, in eine Zeichenfolge. Sie konvertiert z. B. den DWORD-Wert 0x00000001 in die Zeichenfolge 1. Falls die Konvertierung fehlschlägt, wird der Wert von „DefaultValueOnError“ angewendet.

  Syntax: ConvertToString(DefaultValueOnError)

  Einstellung	Erforderlich?	Wert
  DefaultValueOnError	Nein	Der Wert, der in den Wertnamen geschrieben wird, wenn die Konvertierung fehlschlägt. Sie können NULL angeben. 0 wird ausgegeben, wenn die Konvertierung fehlschlägt.

  Beispiel:

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

• ConvertToBinary

  Die ConvertToBinary-Funktion konvertiert den Inhalt von Registrierungswerten, die dem übergeordneten <ObjectSet>-Element entsprechen, in einen Binärtyp.

  Syntax: ConvertToBinary ()

• OffsetValue

  Die OffsetValue-Funktion addiert oder subtrahiert Value zum bzw. vom Wert des migrierten Objekts und schreibt das Ergebnis dann zurück in den Registrierungswert auf dem Zielcomputer. Wenn das migrierte Objekt z. B. der DWORD-Wert 14 ist und für Value "-2" angegeben wurde, ist der Registrierungswert auf dem Zielcomputer 12.

  Syntax: OffsetValue(Value)

  Einstellung	Erforderlich?	Wert
  Wert	Ja	Die Zeichenfolgendarstellung eines numerischen Werts. Der Wert kann positiv oder negativ sein. Beispielsweise OffsetValue(2).

• SetValueByTable

  Die SetValueByTable-Funktion vergleicht den Wert vom Quellcomputer mit der Quelltabelle. Ist der Wert in der Tabelle vorhanden, wird der entsprechende Wert in der Zieltabelle angewendet. Falls der Wert nicht vorhanden ist oder die Zieltabelle keinen entsprechenden Wert enthält, wird der DefaultValueOnError angewendet.

  Syntax: SetValueByTable(SourceTable,DestinationTable,DefaultValueOnError)

  Einstellung	Erforderlich?	Wert
  SourceTable	Ja	Eine durch Kommas getrennte Liste möglicher Werte für die Quellregistrierungswerte.
  DestinationTable	Nein	Eine durch Kommas getrennte Liste übersetzter Werte.
  DefaultValueOnError	Nein	Der Wert, der auf den Zielcomputer angewendet wird, wenn 1) der Wert für den Quellcomputer nicht mit SourceTable übereinstimmt oder 2) DestinationTable keinen entsprechenden Wert enthält. Wenn DefaultValueOnError NULL ist, wird der Wert auf dem Ziel-PC nicht geändert.

• KeepExisting

  Sie können die KeepExisting-Funktion verwenden, wenn auf dem Ziel-PC Konflikte vorliegen. Diese Funktion behält die angegebenen Attribute für das Objekt auf Ziel-PC bei (d. h. sie werden nicht überschrieben).

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

  Einstellung	Erforderlich?	Wert
  OptionString	Ja	OptionString kann Security, TimeFields oder FileAttrib:Letter sein. Sie können von jedem dieser OptionString-Typen einen angeben. Geben Sie nicht mehrere OptionStrings mit demselben Wert an. Andernfalls wird nur die rechts stehende Option dieses Typs beibehalten. Geben Sie z. B. nicht ("FileAttrib:H", "FileAttrib:R") an, da sonst nur "Read-only" (R) ausgewertet wird. Geben Sie stattdessen ("FileAttrib:HR") an, damit beide Attribute – "Hidden" (H) und "Read-only" (R) – auf dem Zielcomputer beibehalten werden. Security. Behält die Sicherheitsbeschreibung des Zielobjekts bei (sofern vorhanden). TimeFields. Behält die Zeitstempel des Zielobjekts bei. Dieser Parameter gilt nur für Dateien. FileAttrib:Letter. Behält den Attributwert des Zielobjekts (On oder OFF) für die angegebenen Dateiattribute bei. Dieser Parameter gilt nur für Dateien. Bei den folgenden Attributen muss die Groß-/Kleinschreibung nicht beachtet werden, USMT ignoriert aber alle Werte, die ungültig sind, mehrmals angegeben werden oder ein Leerzeichen nach "FileAttrib:" enthalten. Sie können eine beliebige Kombination der folgenden Attribute angeben: A = Archive (archivieren) C = Compressed (komprimiert) E = Encrypted (verschlüsselt) H = Hidden (ausgeblendet) I = Not Content Indexed (Inhalt nicht indiziert) O = Offline R = Read-Only (Schreibgeschützt) S = System T = Temporary (temporär)

• MergeMultiSzContent

  Die MergeMultiSzContent-Funktion führt den MULTI-SZ-Inhalt der vom übergeordneten <ObjectSet>-Element aufgelisteten Registrierungswerte mit dem Inhalt der entsprechenden Registrierungswerte zusammen, die auf dem Zielcomputer bereits vorhanden sind. Instruction und String fügen dem resultierenden MULTI-SZ-Wert Inhalt hinzu oder entfernen Inhalt. Doppelte Elemente werden entfernt.

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

  Einstellung	Erforderlich?	Wert
  Instruction	Ja	Folgende Werte sind möglich: Add. Fügt die entsprechende Zeichenfolge dem resultierenden MULTI-SZ-Wert hinzu, wenn sie noch nicht vorhanden ist. Remove. Entfernt die entsprechende Zeichenfolge aus dem resultierenden MULTI-SZ-Wert.
  Zeichenfolge	Ja	Die Zeichenfolge, die hinzugefügt oder entfernt werden soll.

• MergeDelimitedContent

  Die MergeDelimitedContent-Funktion führt den Inhalt der vom übergeordneten <ObjectSet>-Element aufgelisteten Registrierungswerte mit dem Inhalt der entsprechenden Registrierungswerte zusammen, die auf dem Ziel-PC bereits vorhanden sind. Der Inhalt ist eine Liste von Elementen, die durch eines der im Delimeters-Parameter angegebenen Zeichen getrennt sind. Doppelte Elemente werden entfernt.

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

  Einstellung	Erforderlich?	Wert
  Delimiters	Ja	Ein Zeichen, mit dem der Inhalt des verarbeiteten Objekts getrennt wird. Der Inhalt ist eine Liste von Elementen, die durch Delimiters getrennt sind. Im Fall von „.“ wird die Zeichenfolge z. B. durch Punkte getrennt.
  Instruction	Ja	Folgende Werte sind möglich: Add. Fügt String dem resultierenden MULTI-SZ-Wert hinzu, wenn die Zeichenfolge noch nicht vorhanden ist. Remove. Entfernt String aus dem resultierenden MULTI-SZ-Wert.
  Zeichenfolge	Ja	Die Zeichenfolge, die hinzugefügt oder entfernt werden soll.

<description>

Das <description>-Element legt eine Beschreibung für die Komponente fest, hat aber keinen Einfluss auf die Migration.

• Anzahl von Vorkommen: keine oder eins

• Übergeordnete Elemente: <component>

• Untergeordnete Elemente: keine

Syntax:

<description>ComponentDescription</description>

Einstellung	Erforderlich?	Wert
ComponentDescription	Ja	Die Beschreibung der Komponente.

Das folgende Codebeispiel zeigt ein <description>-Element, das die Beschreibung „My custom component“ definiert:

<description>My custom component<description>

<destinationCleanup>

Das <destinationCleanup>-Element löscht Objekte (z. B. Dateien und Registrierungsschlüssel) vom Ziel-PC, bevor die Objekte vom Quell-PC angewendet werden. Dieses Element wird nur ausgewertet, wenn LoadState auf dem Ziel-PC ausgeführt wird. Von ScanState wird es ignoriert.

Wichtig

Da diese Option Objekte vom Ziel-PC löscht, ist bei ihrer Verwendung äußerste Vorsicht angebracht.

Für jedes <destinationCleanup>-Element können mehrere <objectSet>-Elemente vorhanden sein. Sie können dieses Element z. B. verwenden, wenn auf dem Quell-PC ein Registrierungsschlüssel fehlt und Sie sicherstellen möchten, dass eine Komponente migriert wird. In diesem Fall können Sie alle Registrierungsschlüssel der Komponente löschen, bevor Sie die Quellregistrierungsschlüssel migrieren. Falls auf dem Quell-PC ein Schlüssel fehlt, wird so sichergestellt, dass er auch auf dem Ziel-PC fehlt.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Untergeordnete Elemente: <objectSet> (Alle untergeordneten Elemente werden auf dem Zielcomputer gelöscht.)

Syntax:

<destinationCleanup filter=ScriptInvocation>

</destinationCleanup>

Einstellung	Erforderlich?	Wert
filter	Ja	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der Include-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

Beispiel:

<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>

<detect>

Das <detect>-Element wird zwar noch unterstützt, sollte aber nicht verwendet werden, da es in zukünftigen Versionen von USMT möglicherweise nicht mehr verfügbar sein wird. In diesem Fall müssten Sie Ihre Skripts neu schreiben. Stattdessen empfehlen wir, das <detection>-Element zu verwenden.

Mit dem <detect>-Element können Sie feststellen, ob die Komponente auf einem System vorhanden ist. Wenn alle untergeordneten <detect>-Elemente in einem <detect>-Element zu TRUE ausgewertet werden, ist das Ergebnis des <detect>-Elements TRUE. Werden untergeordnete <detect>-Elemente zu FALSE ausgewertet, ist das Ergebnis des übergeordnetem <detect>-Elements FALSE. Wenn kein <detect>-Elementabschnitt angegeben wird, geht USMT davon aus, dass die Komponente vorhanden ist.

Für jedes <detect>-Element können mehrere untergeordnete <condition>- oder <objectSet>-Elemente vorhanden sein, die durch einen OR-Operator logisch verknüpft sind. Wenn mindestens ein <condition>- oder <objectSet>-Element zu TRUE ausgewertet wird, ist das Ergebnis des <detect>-Elements TRUE.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <detects>, <namedElements>

• Erforderliche untergeordnete Elemente: <condition>

• Optionale untergeordnete Elemente: <objectSet>

Syntax:

<detect name="ID" context="User|System|UserAndSystem">

</detect>

Einstellung	Erforderlich?	Wert
name	Ja, wenn <detect> ein untergeordnetes Element von <namedElements> ist Nein, wenn <detect> ein untergeordnetes Element von <detects> ist	Wenn ID angegeben wird, werden keine untergeordneten Elemente verarbeitet. Stattdessen werden alle anderen im <namedElements>-Element deklarierten <detect>-Elemente verarbeitet, die den gleichen Namen haben.
context	Nein (Standardwert = UserAndSystem)	Definiert den Gültigkeitsbereich dieses Parameters, d. h. ob die Komponente im Kontext des jeweiligen Benutzers und/oder für das gesamte Betriebssystem verarbeitet werden soll. Der größtmögliche Bereich wird mit dem <component>-Element festgelegt. Wenn für ein <component>-Element z. B. der Kontext „User“ festgelegt ist und für ein <rules>-Element der Kontext „UserAndSystem“, verhält sich das <rules>-Element als wäre sein Kontext „User“. Wenn für das <rules>-Element der Kontext „System“ festgelegt ist, verhält es sich als wäre das <rules>-Element nicht vorhanden. User. Wertet die Variablen für jeden Benutzer aus. System. Wertet die Variablen nur einmal für das System aus. UserAndSystem. Wertet die Variablen für das gesamte Betriebssystem und jeden Benutzer aus.

Beispiele finden Sie im Abschnitt zum <detection>-Element.

<detects>

Das <detects>-Element wird zwar noch unterstützt, sollte aber nicht verwendet werden, da es in zukünftigen Versionen von USMT möglicherweise nicht mehr verfügbar sein wird und Sie dann Ihre Skripts neu schreiben müssten. Verwenden Sie stattdessen das <detection>-Element, wenn das übergeordnete Element <role> oder <namedElements> ist, und das <conditions>-Element, wenn das übergeordnete Element <rules> ist. Mit dem <detection>-Element können komplexe boolesche Anweisungen genauer formuliert werden.

Das <detects>-Element ist ein Container für ein oder mehrere <detect>-Elemente. Wenn alle untergeordneten <detect>-Elemente in einem <detects>-Element zu TRUE ausgewertet werden, ist das Ergebnis des <detects>-Elements TRUE. Werden untergeordnete <detect>-Elemente zu FALSE ausgewertet, ist das Ergebnis des <detects>-Elements FALSE. Falls Sie die <detects>-Elemente nicht innerhalb einer Komponente schreiben möchten, können Sie das <detects>-Element unter dem <namedElements>-Element erstellen und dann darauf verweisen. Wenn kein <detects>-Elementabschnitt angegeben wird, geht USMT davon aus, dass die Komponente vorhanden ist. Die Ergebnisse der einzelnen <detects>-Elemente werden durch den OR-Operator verknüpft, um die Regel zum Erkennen des übergeordneten Elements zu bilden.

Syntax:

<detects name="ID" context="User|System|UserAndSystem">

</detects>

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <role>, <rules>, <namedElements>

• Erforderliche untergeordnete Elemente: <detect>

Einstellung	Erforderlich?	Wert
name	Ja, wenn <detects> ein untergeordnetes Element von <namedElements> ist Nein, wenn <detects> ein untergeordnetes Element von <role> oder <rules> ist	Wenn ID angegeben wird, werden keine untergeordneten <detect>-Elemente verarbeitet. Stattdessen werden alle anderen im <namedElements>-Element deklarierten <detects>-Elemente verarbeitet, die den gleichen Namen haben.
context	Nein (Standardwert = UserAndSystem)	Definiert den Gültigkeitsbereich dieses Parameters, d. h. ob die Komponente im Kontext des jeweiligen Benutzers und/oder für das gesamte Betriebssystem verarbeitet werden soll. Der größtmögliche Bereich wird mit dem <component>-Element festgelegt. Wenn für ein <component>-Element z. B. der Kontext „User“ festgelegt ist und für ein <rules>-Element der Kontext „UserAndSystem“, verhält sich das <rules>-Element als wäre sein Kontext „User“. Wenn für das <rules>-Element der Kontext „System“ festgelegt ist, verhält es sich als wäre das <rules>-Element nicht vorhanden. User. Wertet die Variablen für jeden Benutzer aus. System. Wertet die Variablen nur einmal für das System aus. UserAndSystem. Wertet die Variablen für das gesamte Betriebssystem und jeden Benutzer aus. Für <detects>-Elemente in <rules>-Elementen wird der context-Parameter ignoriert.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“.

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

<detection>

Das <detection>-Element ist ein Container für ein <conditions>-Element. Das Ergebnis der untergeordneten <condition>-Elemente unter dem <conditions>-Element bestimmt dessen Ergebnis. Wenn z. B. alle untergeordneten <conditions>-Elemente im <detection>-Element zu TRUE ausgewertet werden, ist das Ergebnis des <detection>-Elements TRUE. Werden untergeordnete <conditions>-Elemente zu FALSE ausgewertet, ist das Ergebnis des <detection>-Elements FALSE.

Außerdem werden die Ergebnisse der einzelnen <detection>-Abschnitte im <role>-Element durch den OR-Operator verknüpft, um die Erkennungsregel des übergeordneten Elements zu bilden. Dies bedeutet, dass das <role>-Element verarbeitet wird, wenn einer der <detection>-Abschnitte zu TRUE ausgewertet wird. Andernfalls wird das <role>-Element nicht verarbeitet.

Verwenden Sie das <detection>-Element unter dem <namedElements>-Element, wenn Sie es nicht innerhalb einer Komponente erstellen möchten. Fügen Sie dann einen entsprechenden <detection>-Abschnitt unter dem <role>-Element hinzu, um zu steuern, ob die Komponente migriert wird. Wenn kein <detection>-Abschnitt für eine Komponente angegeben wird, geht USMT davon aus, dass die Komponente vorhanden ist.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <role>, <namedElements>

• Untergeordnete Elemente: <conditions>

Syntax:

<detection name="ID" context="User|System|UserAndSystem">

</detection>

Einstellung	Erforderlich?	Wert
name	Ja, wenn <detection> unter <namedElements> deklariert wird Optional, wenn <detection> unter <role> deklariert wird	Wenn es deklariert wird, wird der Inhalt des <detection>-Elements ignoriert und der Inhalt des im <namedElements>-Element deklarierten <detection>-Elements mit dem gleichen Namen ausgewertet.
context	Nein, Standardwert = UserAndSystem	Definiert den Gültigkeitsbereich dieses Parameters, d. h. ob die Komponente im Kontext des jeweiligen Benutzers und/oder für das gesamte Betriebssystem verarbeitet werden soll. User. Wertet die Komponente für jeden Benutzer aus. System. Wertet die Komponente nur einmal für das System aus. UserAndSystem. Wertet die Komponente für das gesamte Betriebssystem und jeden Benutzer aus.

Beispiel:

<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>

und

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

<displayName>

Das <displayName>-Element ist ein Pflichtfeld in jedem <component>-Element.

• Anzahl von Vorkommen: eins für jede Komponente

• Übergeordnete Elemente: <component>

• Untergeordnete Elemente: keine

Syntax:

<displayName _locID="ID">ComponentName</displayName>

Einstellung	Erforderlich?	Wert
locID	Nein	Dieser Parameter dient zur internen Verwendung in USMT. Verwenden Sie diesen Parameter nicht.
ComponentName	Ja	Der Name der Komponente.

Beispiel:

<displayName>Command Prompt settings</displayName>

<environment>

Das <environment>-Element ist ein Container für <variable>-Elemente, in denen Sie Variablen für die XML-Datei definieren können. Alle auf diese Weise definierten Umgebungsvariablen sind privat. Sie sind also nur für ihre untergeordneten Komponenten und die Komponente, in der sie definiert wurden, verfügbar. Zwei Beispielszenarien finden Sie unter Beispiele.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <role>, <component>, <namedElements>

• Erforderliche untergeordnete Elemente: <variable>

• Optionale untergeordnete Elemente: <conditions>

Syntax:

<environment name="ID" context="User|System|UserAndSystem">

</environment>

Einstellung	Erforderlich?	Wert
name	Ja, wenn <environment> ein untergeordnetes Element von <namedElements> ist Nein, wenn <environment> ein untergeordnetes Element von <role> oder <component> ist	Wenn das Element als untergeordnetes Element von <role> oder <component> deklariert und ID angegeben wird, ignoriert USMT den Inhalt des <environment>-Elements, und der Inhalt des im <namedElements>-Element deklarierten <environment>-Elements mit dem gleichen Namen wird verarbeitet.
context	Nein (Standardwert = UserAndSystem)	Definiert den Gültigkeitsbereich dieses Parameters, d. h. ob die Komponente im Kontext des jeweiligen Benutzers und/oder für das gesamte Betriebssystem verarbeitet werden soll. Der größtmögliche Bereich wird mit dem <component>-Element festgelegt. Wenn für ein <component>-Element z. B. der Kontext „User“ festgelegt ist und für ein <rules>-Element der Kontext „UserAndSystem“, verhält sich das <rules>-Element als wäre sein Kontext „User“. Wenn für das <rules>-Element der Kontext „System“ festgelegt ist, verhält es sich als wäre das <rules>-Element nicht vorhanden. User. Wertet die Variablen für jeden Benutzer aus. System. Wertet die Variablen nur einmal für das System aus. UserAndSystem. Wertet die Variablen für das gesamte Betriebssystem und jeden Benutzer aus.

Beispielszenario 1

In diesem Szenario möchten Sie den Speicherort von Objekten zur Laufzeit abhängig von der Konfiguration des Ziel-PC generieren. Dies ist z. B. notwendig, wenn eine App Daten in ihr Installationsverzeichnis schreibt und Benutzer die App an einem anderen Speicherort auf dem PC installieren können. Wenn die App einen Registrierungswert „hklm\software\companyname\install [Path]“ erstellt und diesen Wert dann mit dem Speicherort aktualisiert, an dem die App installiert wird, müssen Sie eine Umgebungsvariable definieren, um die erforderlichen Daten korrekt zu migrieren. Beispiel:

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

Anschließend können Sie wie folgt eine Include-Regel verwenden. Mit den <script>-Funktionen können Sie ähnliche Aufgaben ausführen.

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

Sie können auch Registrierungswerte filtern, die benötigte Daten enthalten. Im folgenden Beispiel wird die erste Zeichenfolge (vor dem Trennzeichen „,“) im Registrierungswert „Hklm\software\companyname\application\ [Path]“ extrahiert.

<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>

Beispielszenario 2

In diesem Szenario möchten Sie fünf Dateien namens „File1.txt“, „File2.txt“ usw. aus „%SYSTEMDRIVE%\data\userdata\dir1\dir2\“ migrieren. Dazu müssen Sie die folgende <include>-Regel in einer XML-Datei angeben:

<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>

Anstatt den Pfad fünfmal einzugeben, können Sie wie folgt eine Variable für den Speicherort erstellen:

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

Anschließend können Sie die Variable wie folgt in einer <include>-Regel angeben:

<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>

Das <exclude>-Element bestimmt, welche Objekte nicht migriert werden, sofern kein spezifischeres <include>-Element vorhanden ist, durch das ein Objekt migriert wird. Wenn für ein Objekt sowohl ein <include>-Element als auch ein <exclude>-Element vorhanden sind, wird das Objekt eingeschlossen. Für jedes <exclude>-Element können mehrere untergeordnete <objectSet>-Elemente vorhanden sein.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Untergeordnete Elemente: <objectSet>

• Hilfsfunktionen: Sie können die folgenden <include>- und <exclude>-Filterfunktionen mit diesem Element verwenden: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, NeverRestore und SameRegContent.

Syntax:

<exclude filter="ScriptInvocation">

</exclude>

Einstellung	Erforderlich?	Wert
filter	Nein (Standardwert = No)	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der Include-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

Das folgende Beispiel stammt aus der Datei „MigUser.xml“:

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

<excludeAttributes>

Mit dem <excludeAttributes>-Element können Sie festlegen, welche der zugeordneten Parameter eines Objekts nicht migriert werden. Falls Konflikte zwischen den <includeAttributes>- und <excludeAttributes>-Elementen bestehen, bestimmt das spezifischste Muster, welche Muster nicht migriert werden. Wenn für ein Objekt kein <includeAttributes>- oder <excludeAttributes>-Element angegeben ist, werden alle Parameter des Objekts migriert.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Untergeordnete Elemente: <objectSet>

Syntax:

<excludeAttributes attributes="Security|TimeFields|Security,TimeFields">

</excludeAttributes>

Parameter	Erforderlich?	Wert
attributes	Ja	Gibt die Attribute an, die ausgeschlossen werden sollen. Sie können einen der folgenden Werte oder beide Werte durch Anführungszeichen getrennt angeben, z. B. "Security","TimeFields": „Security“ kann „Owner“, „Group“, „DACL“ oder „SACL“ sein. „TimeFields“ kann „CreationTime“, „LastAccessTime“ und „LastWrittenTime“ sein.

Beispiel:

<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/miguser">
<!-- This component migrates My Video files -->
   <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>

Das <extensions>-Element ist ein Container für ein oder mehrere <extension>-Elemente.

• Anzahl von Vorkommen: keine oder eins

• Übergeordnete Elemente: <component>

• Erforderliche untergeordnete Elemente: <extension>

Syntax:

<extensions>

</extensions>

<extension>

Mit dem <extension>-Element können Sie Dokumente mit einer bestimmten Dateinamenerweiterung angeben.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <extensions>

• Untergeordnete Elemente: keine

Syntax:

<extension>FilenameExtension</extension>

Einstellung	Erforderlich?	Wert
FilenameExtension	Ja	Eine Dateinamenerweiterung.

Wenn Sie z. B. alle *.DOC-Dateien vom Quell-PC migrieren möchten, geben Sie den folgenden Code unter dem<component>-Element an:

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

Dieser Code hat die gleiche Wirkung wie der folgende Code unter dem <rules>-Element:

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

Ein weiteres Beispiel zur Verwendung des <extension>-Elements finden Sie im Abschnitt zum <excludeAttributes>-Element.

<externalProcess>

Mit dem <externalProcess>-Element können Sie während des Migrationsvorgangs eine Befehlszeile ausführen. Sie können z. B. nach Abschluss des LoadState-Vorgangs einen Befehl ausführen.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliche untergeordnete Elemente: <commandLine>

Syntax:

<externalProcess when="pre-scan|scan-success|post-scan|pre-apply|apply-success|post-apply">

</externalProcess>

Einstellung	Erforderlich?	Wert
when	Ja	Gibt an, wann die Befehlszeile ausgeführt werden soll. Folgende Werte sind möglich: pre-scan – vor dem Start des Scanvorgangs scan-success – nach dem erfolgreichen Abschluss des Scanvorgangs post-scan – nach dem Abschluss des Scanvorgangs, unabhängig davon, ob er erfolgreich war oder nicht pre-apply – vor dem Start des Anwendungsvorgangs apply-success – nach dem erfolgreichen Abschluss des Anwendungsvorgangs post-apply – nach dem Abschluss des Anwendungsvorgangs, unabhängig davon, ob er erfolgreich war oder nicht

Ein Beispiel zur Verwendung des <externalProcess>-Elements finden Sie im Abschnitt zum <excludeAttributes>-Element.

<icon>

Dies ist ein internes USMT-Element. Verwenden Sie dieses Element nicht.

<include>

Das <include>-Element bestimmt, welche Objekte migriert werden, sofern keine spezifischere <exclude>-Regel vorhanden ist. Sie können ein spezifischeres Skript angeben, um die Definition der zu sammelnden Objekte zu erweitern. Für jedes <include>-Element können mehrere <objectSet>-Elemente vorhanden sein.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliches untergeordnetes Element: <objectSet>

• Hilfsfunktionen: Sie können die folgenden <include>- und <exclude>-Filterfunktionen mit diesem Element verwenden: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo und NeverRestore.

Syntax:

<include filter="ScriptInvocation">

</include>

Einstellung	Erforderlich?	Wert
filter	Nein Wenn dieser Parameter nicht angegeben wird, werden alle Muster im untergeordneten <ObjectSet>-Element verarbeitet.	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der <include>-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

Das folgende Beispiel stammt aus der Datei „MigUser.xml“:

<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>

<include>- und <exclude>-Filterfunktionen

Die folgenden Funktionen geben einen booleschen Wert zurück. Sie können sie verwenden, um bestimmte Objekte nur dann zu migrieren, wenn bestimmte Bedingungen erfüllt sind.

• AnswerNo

  Dieser Filter gibt im FALSE zurück.

  Syntax: AnswerNo ()

• CompareStringContent

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

  Einstellung	Erforderlich?	Wert
  StringContent	Ja	Die zu vergleichende Zeichenfolge.
  CompareType	Ja	Eine Zeichenfolge. Verwenden Sie einen der folgenden Werte: Equal (ohne Berücksichtigung der Groß-/Kleinschreibung). Die Funktion gibt TRUE zurück, wenn die Zeichenfolgendarstellung des aktuellen, vom Migrationsmodul verarbeiteten Objekts mit StringContent identisch ist. NULLoder ein beliebiger anderer Wert. Die Funktion gibt TRUE zurück, wenn die Zeichenfolgendarstellung des aktuellen, vom Migrationsmodul verarbeiteten Objekts StringContent nicht entspricht.

• IgnoreIrrelevantLinks

  Dieser Filter sondert INK-Dateien aus, die auf ein Objekt verweisen, das auf dem Ziel-PC nicht gültig ist. Die Filterung findet auf dem Ziel-PC statt. Während der Ausführung von ScanState werden daher alle INK-Dateien im Speicher gespeichert. Sie werden anschließend herausgefiltert, wenn Sie LoadState ausführen.

  Syntax: IgnoreIrrelevantLinks ()

  Beispiel:

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

• NeverRestore

  Mit dieser Funktion können Sie die angegebenen Objekte vom Quellcomputer sammeln, anschließend aber nicht zum Zielcomputer migrieren. Diese Funktion wird zu TRUE ausgewertet, wenn sie mit ScanState ausgeführt wird. Wenn sie mit LoadState ausgeführt wird, ist das Ergebnis FALSE. Sie können diese Funktion verwenden, wenn Sie den Wert eines Objekts auf dem Zielcomputer überprüfen, das Objekt aber nicht zum Zielcomputer migrieren möchten.

  Syntax: NeverRestore()

  Im folgenden Beispiel wird „HKCU\Control Panel\International [Locale]“ dem Speicher hinzugefügt, aber nicht zum Ziel-PC migriert:

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

<includeAttributes>

Mit dem <includeAttributes>-Element können Sie festlegen, ob bestimmte mit einem Objekt verknüpfte Parameter zusammen mit dem Objekt migriert werden. Falls Konflikte zwischen den <includeAttributes>- und <excludeAttributes>-Elementen bestehen, bestimmt das spezifischste Muster, welche Parameter migriert werden. Wenn für ein Objekt kein <includeAttributes>- oder <excludeAttributes>-Element angegeben ist, werden alle Parameter des Objekts migriert.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Untergeordnete Elemente: <objectSet>

Syntax:

<includeAttributes attributes="Security|TimeFields|Security,TimeFields">

</includeAttributes>

Einstellung	Erforderlich?	Wert
attributes	Ja	Gibt die Attribute an, die mit einem Objekt migriert werden sollen. Sie können einen der folgenden Werte oder beide Werte durch Anführungszeichen getrennt angeben, z. B. "Security","TimeFields": „Security“ kann einen der folgenden Werte haben: Owner. Der Besitzer des Objekts (SID). Group. Die primäre Gruppe für das Objekt (SID). DACL (besitzverwaltete Zugriffssteuerungsliste). Eine Zugriffssteuerungsliste, die vom Besitzer eines Objekts gesteuert wird und die Zugriffsrechte bestimmter Benutzer oder Gruppen für das Objekt festlegt. SACL (Systemzugriff-Steuerungsliste). Eine Zugriffssteuerungsliste, die die Generierung von Überwachungsmeldungen für Zugriffsversuche auf ein sicherungsfähiges Objekt steuert. Die Möglichkeit, die SACL eines Objekts abzurufen oder festzulegen, wird durch ein Recht gesteuert, das in der Regel nur Systemadministratoren besitzen. „TimeFields“ kann einen der folgenden Werte haben: CreationTime. Gibt an, wann die Datei oder das Verzeichnis erstellt wurde. LastAccessTime. Gibt an, wann der letzte Zugriff (Lesen, Schreiben oder – im Fall von ausführbaren Dateien – Ausführen) auf die Datei stattgefunden hat. LastWrittenTime. Gibt an, wann der letzte Schreibzugriff (Schreiben, Abschneiden oder Überschreiben) auf die Datei stattgefunden hat.

Ein Beispiel zur Verwendung des <includeAttributes>-Elements finden Sie im Abschnitt zum <excludeAttributes>-Element.

<library>

Dies ist ein internes USMT-Element. Verwenden Sie dieses Element nicht.

<location>

Das <location>-Element definiert den Speicherort des <object>-Elements.

• Anzahl von Vorkommen: eins für jedes <object>

• Übergeordnete Elemente: <object>

• Untergeordnete Elemente: <script>

Syntax:

<location type="typeID">ObjectLocation</location>

Einstellung	Erforderlich?	Wert
type	Ja	typeID kann "Registry" oder "File" sein.
ObjectLocation	Ja	Der Speicherort des Objekts.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<locationModify>

Mit dem <locationModify>-Element können Sie den Speicherort und Namen eines Objekts ändern, bevor es zum Ziel-PC migriert wird. Das <locationModify>-Element wird nur verarbeitet, wenn LoadState auf dem Ziel-PC ausgeführt wird. Von ScanState wird dieses Element ignoriert. Das <locationModify>-Element erstellt den entsprechenden Ordner auf dem Ziel-PC, wenn er noch nicht vorhanden ist.

Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliches untergeordnetes Element: <objectSet>

• Hilfsfunktionen: Sie können die folgenden <locationModify>-Funktionen mit diesem Element verwenden: ExactMove, RelativeMove und Move.

Syntax:

<locationModify script="ScriptInvocation">

</locationModify>

Einstellung	Erforderlich?	Wert
script	Ja	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der Include-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<locationModify>-Funktionen

Die folgenden Funktionen ändern den Speicherort von Objekten, wenn diese mit dem <locationModify>-Element migriert werden. Diese Funktionen werden für jedes vom übergeordneten <ObjectSet>-Element aufgelistete Objekt aufgerufen. Das <locationModify>-Element erstellt den entsprechenden Ordner auf dem Ziel-PC, wenn er noch nicht vorhanden ist.

• ExactMove

  Die ExactMove-Funktion verschiebt alle Objekte, die dem übergeordneten <ObjectSet>-Element entsprechen, an den ObjectEncodedLocation. Sie können diese Funktion verwenden, wenn Sie eine einzelne Datei an einen anderen Speicherort auf dem Zielcomputer verschieben möchten. Wenn der Zielspeicherort ein Knoten ist, werden alle übereinstimmenden Quellobjekte in den Knoten geschrieben (ohne Unterverzeichnisse). Ist der Zielspeicherort ein Blatt, migriert das Migrationsmodul alle übereinstimmenden Quellobjekte zum selben Speicherort. Falls ein Konflikt auftritt, werden die normalen Konfliktalgorithmen angewendet.

  Syntax: ExactMove(ObjectEncodedLocation)

  Einstellung	Erforderlich?	Wert
  ObjectEncodedLocation	Ja	Der Angeben von Speicherorten für alle Quellobjekte.

  Beispiel:

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

• Move

  Die Move-Funktion verschiebt Objekte an einen anderen Speicherort auf dem Ziel-PC. Außerdem erstellt diese Funktion Unterverzeichnisse über dem längsten CSIDL-Wert im Quellobjektnamen.

  Syntax: Move(DestinationRoot)

  Einstellung	Erforderlich?	Wert
  DestinationRoot	Ja	Der Speicherort, an den Quellobjekte verschoben werden. Außerdem erstellt diese Funktion bei Bedarf alle Unterverzeichnisse über dem längsten CSIDL-Wert im Quellobjektnamen.

• RelativeMove

  Mit der RelativeMove-Funktion können Sie Daten sammeln und verschieben. Sie können Umgebungsvariablen im Quell- und Zielstamm verwenden. Beachten Sie dabei aber, dass diese möglicherweise auf dem Quell- und Ziel-PC unterschiedlich definiert sind.

  Syntax: RelativeMove(SourceRoot,DestinationRoot)

  Einstellung	Erforderlich?	Wert
  SourceRoot	Ja	Der Speicherort, von dem Objekte verschoben werden. Alle vom übergeordneten <ObjectSet>-Element aufgelisteten Quellobjekte, die nicht an diesem Speicherort vorhanden sind, werden verschoben.
  DestinationRoot	Ja	Der Speicherort, an den die Quellobjekte auf dem Zielcomputer verschoben werden. Diese Funktion erstellt bei Bedarf alle Unterverzeichnisse über dem Quellstamm.

  Beispiel:

  <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>

Dies ist ein internes USMT-Element. Verwenden Sie dieses Element nicht.

<manufacturer>

Das <manufacturer>-Element gibt den Hersteller für die Komponente an, hat aber keinen Einfluss auf die Migration.

• Anzahl von Vorkommen: keine oder eins

• Übergeordnete Elemente: <component>

• Untergeordnete Elemente: keine

Syntax:

<manufacturer>Name</manufacturer>

Einstellung	Erforderlich?	Wert
Name	Ja	Der Name des Herstellers der Komponente.

<merge>

Das <merge>-Element bestimmt, was im Fall eines Konflikts passiert. Ein Konflikt liegt vor, wenn ein migriertes Objekt bereits auf dem Ziel-PC vorhanden ist. Wenn Sie dieses Element nicht angeben, wird bei Registrierungswerten standardmäßig das Zielobjekt durch das Quellobjekt überschrieben. Bei Dateien wird die Quelldatei standardmäßig in „UrsprünglicherDateiname(1).UrsprünglicheDateierweiterung“ umbenannt. Dieses Element gibt nur an, was bei einem Konflikt passieren soll. Es schließt keine Objekte ein. Damit die Objekte migriert werden, müssen Sie daher zusammen mit dem <merge>-Element <include>-Regeln angeben. Wird beim Verarbeiten eines Objekts ein Konflikt erkannt, wird die spezifischste Merge-Regel von USMT ausgewählt und zum Beheben des Konflikts angewendet. Wenn Sie z. B. eine <merge>-Regel für „C:\* [*]“ auf <sourcePriority> und eine <merge>-Regel für „C:\subfolder\* [*]“ auf <destinationPriority> festgelegt haben, verwendet USMT die <destinationPriority>-Regel, weil sie spezifischer ist.

Ein Beispiel für dieses Element finden Sie unter Wie funktioniert <merge> bei Konflikten auf dem Zielcomputer?.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliches untergeordnetes Element: <objectSet>

• Hilfsfunktionen: Sie können die folgenden <merge>-Funktionen mit diesem Element verwenden: SourcePriority, DestinationPriority, FindFilePlaceByPattern, LeafPattern, NewestVersion, HigherValue() und LowerValue().

Syntax:

<merge script="ScriptInvocation">

</merge>

Einstellung	Erforderlich?	Wert
script	Ja	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der <include>-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert.

Das folgende Beispiel stammt aus der Datei „MigUser.xml“:

<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>

<merge>-Funktionen

Diese Funktionen steuern, wie Konflikte behoben werden.

• DestinationPriority

  Gibt an, dass das Objekt auf dem Ziel-PC beibehalten und das Objekt vom Quell-PC nicht migriert wird.

  Beispiel:

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

• FindFilePlaceByPattern

  Die FindFilePlaceByPattern-Funktion speichert Dateien mit einem inkrementellen Zähler, wenn ein Konflikt auftritt. Für die Funktion wird eine Zeichenfolge angegeben, die je eins der Konstrukte <F>, <E>, <N> in beliebiger Reihenfolge enthält.

  Syntax: FindFilePlaceByPattern(FilePattern)

  Einstellung	Erforderlich?	Wert
  FilePattern	Ja	<F> wird durch den ursprünglichen Dateinamen ersetzt. <N> wird durch einen inkrementellen Zähler ersetzt, bis auf dem Zielcomputer kein Konflikt mit den Objekten vorliegt. <E> wird durch die ursprüngliche Dateinamenerweiterung ersetzt. <F> (<N>).<E> ändert z. B. die Quelldatei "MyDocument.doc" auf dem Zielcomputer in "MyDocument(1).doc".

• NewestVersion

  Die NewestVersion-Funktion behebt Konflikte auf dem Ziel-PC auf Grundlage der Dateiversion.

  Syntax: NewestVersion(VersionTag)

  Einstellung	Erforderlich?	Wert
  VersionTag	Ja	Das zu überprüfende Versionsfeld. Hierbei kann es sich um "FileVersion" oder "ProductVersion" handeln. Die Datei mit der höchsten VersionTag-Version bestimmt, welche Konflikte auf Grundlage der Dateiversion behoben werden. Wenn "Myfile.txt" z. B. FileVersion 1 enthält und die gleiche Datei auf dem Zielcomputer FileVersion 2, bleibt die Datei auf dem Zielcomputer erhalten.

• HigherValue()

  Mit dieser Funktion können Sie Registrierungswerte zusammenführen. Die Registrierungswerte werden als numerische Werte ausgewertet, und der höhere Wert bestimmt, welche Registrierungswerte zusammengeführt werden.

• LowerValue()

  Mit dieser Funktion können Sie Registrierungswerte zusammenführen. Die Registrierungswerte werden als numerische Werte ausgewertet, und der niedrigere Wert bestimmt, welche Registrierungswerte zusammengeführt werden.

• SourcePriority

  Gibt an, dass das Objekt vom Quell-PC migriert und das Objekt auf dem Ziel-PC gelöscht wird.

  Beispiel:

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

<migration>

Das <migration>-Element ist das einzige Stammelement einer XML-Migrationsdatei und muss angegeben werden. Jede XML-Datei muss eine eindeutige Migrations-UrlId besitzen. Die UrlId jeder Datei, die Sie in der Befehlszeile angeben, muss eindeutig sein. Dies liegt daran, dass USMT die UrlId zum Definieren der Komponenten in der Datei verwendet. Sie müssen z. B. Folgendes am Anfang jeder Datei angeben: <CustomFileName> ist der Name der Datei, z. B. „CustomApp“.

• Anzahl von Vorkommen: eins

• Übergeordnete Elemente: keine

• Erforderliche untergeordnete Elemente: <component>

• Optionale untergeordnete Elemente: <library>, <namedElements>

Syntax:

<migration urlid="*UrlID/*Name">

</migration>

Einstellung	Erforderlich?	Wert
urlid	Ja	UrlID ist ein Zeichenfolgenbezeichner, der die XML-Datei eindeutig identifiziert. Bei diesem Parameter muss es sich – wie in der XML-Namespacespezifikation definiert – um einen Namen ohne Doppelpunkt handeln. Jede XML-Migrationsdatei muss eine eindeutige UrlId besitzen. Falls zwei XML-Migrationsdateien die gleiche UrlId haben, wird die zweite in der Befehlszeile angegebene XML-Datei nicht verarbeitet. Weitere Informationen zu XML-Namespaces finden Sie unter Verwenden von XML-Namespaces.
Name	Nein	Obwohl dieser Wert nicht erforderlich ist, empfiehlt es sich, den Namen der XML-Datei anzugeben.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

MigXMLHelper.FileProperties

Mit dieser Filterhilfsfunktion können Sie die migrierten Dateien nach Dateigrößen- und Datumsattributen filtern.

Hilfsfunktion	MigXMLHelper.FileProperties (property, operator, valueToCompare)
Property	filesize, dateCreated, dateModified, dateAccessed
Operator	range, neq, lte, lt, eq, gte, gt
valueToCompare	Der Wert, der verglichen wird. Beispiel: Datum: „2008/05/15-2005/05/17“, „2008/05/15“ Größe: Eine Zahl mit B, KB, MB oder GB am Ende, z. B. „5GB“, „1KB-1MB“

<component context="System"  type="Application">
<displayName>File_size</displayName>
<role role="Data">

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

<namedElements>

Mit dem <namedElements>-Element können Sie benannte Elemente festlegen. Sie können diese Elemente in allen Komponenten in der XML-Datei verwenden. Ein Beispiel für die Verwendung dieses Elements finden Sie in der Datei "MigApp.xml".

Syntax:

<namedElements>

</namedElements>

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <migration>

• Untergeordnete Elemente: <environment>, <rules>, <conditions>, <detection>, <detects>, <detect>

Ein Beispiel für dieses Element finden Sie in der Datei „MigApp.xml“.

<object>

Das <object>-Element stellt eine Datei oder einen Registrierungsschlüssel dar.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <addObjects>

• Erforderliche untergeordnete Elemente: <location>, <attributes>

• Optionale untergeordnete Elemente: <bytes>

Syntax:

<object>

</object>

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

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

<objectSet>

Das <objectSet>-Element enthält eine Liste von Objektmustern, z. B. Dateipfade, Registrierungspfade usw. Alle untergeordneten <conditions>-Elemente werden zuerst ausgewertet. Wenn alle untergeordneten <conditions>-Elemente FALSE zurückgeben, ist das Ergebnis des <objectSet>-Elements ein leerer Satz. Für jedes übergeordnete Element können mehrere <objectSet>-Elemente vorhanden sein.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <variable>, <content>, <include>, <exclude>, <merge>, <contentModify>, <locationModify>, <destinationCleanup>, <includeAttributes>, <excludeAttributes>, <unconditionalExclude>, <detect>

• Erforderliche untergeordnete Elemente: <script> oder <pattern>

• Optionale untergeordnete Elemente: <content>, <conditions>, <condition>

Syntax:

<objectSet>

</objectSet>

Das folgende Beispiel stammt aus der Datei „MigUser.xml“:

<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>

Dies ist ein internes USMT-Element. Verwenden Sie dieses Element nicht.

<paths>

Dies ist ein internes USMT-Element. Verwenden Sie dieses Element nicht.

<pattern>

Mit diesem Element können Sie mehrere Objekte angeben. Sie können mehrere <pattern>-Elemente für jedes <objectSet>-Element angeben, die dann kombiniert werden. Falls Sie Dateien angeben, können Sie stattdessen ggf. GenerateDrivePatterns mit <script> verwenden. GenerateDrivePatterns ist im Grunde das Gleiche wie eine <pattern>-Regel, aber ohne Angabe des Laufwerkbuchstaben. Die folgenden zwei Codezeilen ähneln sich z. B.:

<pattern type="File">C:\Folder\* [Sample.doc]</pattern>
<script>MigXmlHelper.GenerateDrivePatterns("\Folder\* [Sample.doc]","Fixed"</script>

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <objectSet>

• Untergeordnete Elemente: keine, Path [Object] muss allerdings gültig sein

Syntax:

<pattern type="typeID">Path [object]</pattern>

Einstellung	Erforderlich?	Wert
type	Ja	typeID kann "Registry", "File" oder "Ini" sein. Wenn typeID "Ini" ist, darf kein Leerzeichen zwischen Path und Object angegeben werden. Die folgende Syntax ist für type="Ini" z. B. richtig: <pattern type="Ini">%WinAmp5InstPath%\Winamp.ini|WinAmp[keeponscreen]</pattern>
Path [object]	Ja	Ein gültiges Registrierungs- oder Dateipfadmuster gefolgt von mindestens einem Leerzeichen und eckigen Klammern [], die das zu migrierende Objekt enthalten. Path kann ein Sternchen (*) als Platzhalterzeichen enthalten oder eine Umgebungsvariable sein. Das Fragezeichen (?) kann nicht als Platzhalterzeichen verwendet werden. Sie können HKCU und HKLM verwenden, um auf HKEY_CURRENT_USER bzw. HKEY_LOCAL_MACHINE zu verweisen. Object kann ein Sternchen (*) als Platzhalterzeichen enthalten. Das Fragezeichen (?) kann dagegen nicht als Platzhalterzeichen verwendet werden. Beispiel: C:\Folder\ [*] listet alle Dateien in "C:\Path" auf, aber keine Unterordner von "C:\Folder". C:\Folder\* [*] listet alle Dateien und Unterordner in "C:\Folder" auf. C:\Folder\ [*.mp3] listet alle MP3-Dateien in "C:\Folder" auf. C:\Folder\ [Sample.doc] listet nur die Datei "Sample.doc" in "C:\Folder" auf. > [!NOTE] > Wenn Sie eine Datei migrieren, deren Dateiname eine eckige Klammer ([ oder ]) enthält, müssen Sie das Caretzeichen (^) direkt vor der eckigen Klammer einfügen, damit der Name gültig ist. Für eine Datei mit dem Namen "file].txt" müssen Sie z. B. <pattern type="File">c:\documents\mydocs [file^].txt]</pattern> anstelle von <pattern type="File">c:\documents\mydocs [file].txt]</pattern> angeben. >

Beispiel:

• Um einen einzelnen Registrierungsschlüssel zu migrieren:

  <pattern type="Registry">HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache [Persistent]</pattern>
  

• Um den Ordner „EngineeringDrafts“ und alle zugehörigen Unterordner vom Laufwerk „C:“ zu migrieren:

  <pattern type="File">C:\EngineeringDrafts\* [*]</pattern>
  

• Um nur den Ordner „EngineeringDrafts“ ohne Unterordner vom Laufwerk „C:“ zu migrieren:

  <pattern type="File"> C:\EngineeringDrafts\ [*]</pattern>
  

• Um die Datei „Sample.doc“ aus „C:\EngineeringDrafts“ zu migrieren:

  <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>
  

• Um die Datei „Sample.doc“ von einem beliebigen Speicherort auf dem Laufwerk „C:“ zu migrieren, verwenden Sie <pattern> wie folgt. Falls mehrere Dateien mit demselben Namen auf dem Laufwerk „C:“ vorhanden sind, werden sie alle migriert.

  <pattern type="File"> C:\* [Sample.doc] </pattern>
  

• Weitere Beispiele zur Verwendung dieses Elements finden Sie unter Ausschließen von Dateien und Einstellungen, Umleiten von Dateien und Einstellungen, Einschließen von Dateien und Einstellungen und Beispiele für benutzerdefinierte XML-Dateien.

<processing>

Mit diesem Element können Sie an einem bestimmten Punkt im Migrationsvorgang ein Skript ausführen. Rückgabewerte werden von den angegebenen Skripts nicht erwartet. Falls Werte zurückgegeben werden, werden sie ignoriert.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Erforderliches untergeordnetes Element: <script>

Syntax:

<processing when="pre-scan|scan-success|post-scan|pre-apply|apply-success|post-apply">

</processing>

Einstellung	Erforderlich?	Wert
when	Ja	Gibt an, wann das Skript ausgeführt werden soll. Folgende Werte sind möglich: pre-scan – vor dem Start des Scanvorgangs scan-success – nach dem erfolgreichen Abschluss des Scanvorgangs post-scan – nach dem Abschluss des Scanvorgangs, unabhängig davon, ob er erfolgreich war oder nicht pre-apply – vor dem Start des Anwendungsvorgangs apply-success – nach dem erfolgreichen Abschluss des Anwendungsvorgangs post-apply – nach dem Abschluss des Anwendungsvorgangs, unabhängig davon, ob er erfolgreich war oder nicht

<plugin>

Dies ist ein internes USMT-Element. Verwenden Sie dieses Element nicht.

<role>

Das <role>-Element ist in einer benutzerdefinierten XML-Datei erforderlich. Mit dem <role>-Element können Sie eine konkrete Komponente erstellen. Die Komponente wird durch die auf der <component>-Ebene angegebenen Parameter und mit der hier festgelegten Rolle definiert.

• Anzahl von Vorkommen: Jedes <component>-Element kann ein, zwei oder drei untergeordnete <role>-Elemente haben.

• Übergeordnete Elemente: <component>, <role>

• Erforderliche untergeordnete Elemente: <rules>

• Optionale untergeordnete Elemente: <environment>, <detection>, <component>, <role>, <detects>, <plugin>,

Syntax:

<role role="Container|Binaries|Settings|Data">

</role>

Einstellung	Erforderlich?	Wert
role	Ja	Definiert die Rolle für die Komponente. Folgende Werte sind möglich: Container Binaries Settings Data Sie haben folgende Möglichkeiten: Sie können bis zu drei <role>-Elemente in einem <component>-Element angeben – ein <role>-Element „Binaries“, ein <role>-Element „Settings“ und ein <role>-Element „Data“. Diese Parameter haben keinen Einfluss auf das Migrationsverhalten. Sie dienen nur zum Kategorisieren der migrierten Einstellungen. Sie können die <role>-Elemente schachteln, jedes geschachtelte Element muss dann aber den gleichen role-Parameter aufweisen. Sie können ein <role>-Element „Container“ in einem <component>-Element angeben. In diesem Fall können Sie keine untergeordneten <rules>-Elemente, sondern nur andere <component>-Elemente angeben. Außerdem muss jedes untergeordnete <component>-Element vom gleichen Typ sein wie das übergeordnete <component>-Element. Beispiel: <component context="UserAndSystem" type="Application"> <displayName _locID="migapp.msoffice2003">Microsoft Office 2003</displayName> <environment name="GlobalEnv" /> <role role="Container"> <detection name="AnyOffice2003Version" /> <detection name="FrontPage2003" /> <!-- Office 2003 Common Settings   --> <component context="UserAndSystem" type="Application">

Das folgende Beispiel stammt aus der Datei „MigUser.xml“. Weitere Beispiele finden Sie in der Datei „MigApp.xml“:

<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>

<rules>

Das <rules>-Element ist in einer benutzerdefinierten XML-Datei erforderlich. Es enthält Regeln, die während der Migration ausgeführt werden, wenn das übergeordnete <component>-Element ausgewählt und das untergeordnete <conditions>-Element (sofern vorhanden) nicht zu FALSE ausgewertet wird. Für jedes <rules>-Element können mehrere untergeordnete <rules>-Elemente vorhanden sein.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <role>, <rules>, <namedElements>

• Erforderliche untergeordnete Elemente: <include>

• Optionale untergeordnete Elemente: <rules>, <exclude>, <unconditionalExclude>,<merge>, <contentModify>, <locationModify>, <destinationCleanup>, <addObjects>, <externalProcess>, <processing>, <includeAttributes>, <excludeAttributes>, <conditions>, <detects>

Syntax:

<rules name="ID" context="User|System|UserAndSystem">

</rules>

Einstellung	Erforderlich?	Wert
name	Ja, wenn <rules> ein untergeordnetes Element von <namedElements> ist Nein, wenn <rules> einem anderen Element untergeordnet ist	Wenn ID angegeben wird, werden keine untergeordneten Elemente verarbeitet. Stattdessen werden alle anderen im <namedElements>-Element deklarierten <rules>-Elemente verarbeitet, die den gleichen Namen haben.
context	Nein (Standardwert = UserAndSystem)	Definiert den Gültigkeitsbereich dieses Parameters, d. h. ob die Komponente im Kontext des jeweiligen Benutzers und/oder für das gesamte Betriebssystem verarbeitet werden soll. Der größtmögliche Bereich wird mit dem <component>-Element festgelegt. Wenn für ein <component>-Element z. B. der Kontext „User“ festgelegt ist und für ein <rules>-Element der Kontext „UserAndSystem“, verhält sich das <rules>-Element als wäre sein Kontext „User“. Wenn für das <rules>-Element der Kontext „System“ festgelegt ist, verhält es sich als wäre das <rules>-Element nicht vorhanden. User. Wertet die Variablen für jeden Benutzer aus. System. Wertet die Variablen nur einmal für das System aus. UserAndSystem. Wertet die Variablen für das gesamte Betriebssystem und jeden Benutzer aus.

Das folgende Beispiel stammt aus der Datei „MigUser.xml“:

<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>

Der für <script> erforderliche Rückgabewert hängt vom übergeordneten Element ab.

Anzahl von Vorkommen: eins für <variable>, unbegrenzt für <objectSet> und <processing>

Übergeordnete Elemente: <objectSet>, <variable>, <processing>

Untergeordnete Elemente: keine

Syntax und Hilfsfunktionen

• Allgemeine Syntax: <script>ScriptWithArguments</script>

• Sie können <script>-Funktionen verwenden, wenn <script> in <variable> enthalten ist.

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

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

• Sie können <script>-Funktionen verwenden, wenn <script> in <objectSet> enthalten ist.

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

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

• Sie können <script>-Funktionen verwenden, wenn <script> in <objectSet> enthalten ist.

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

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

• Sie können die <script>-Funktionen mit <script>-Elementen verwenden, die in <processing>-Elementen enthalten sind: AskForLogoff, ConvertToShortFileName, KillExplorer, RemoveEmptyDirectories, RestartExplorer, RegisterFonts, StartService, StopService, SyncSCM.

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

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

Einstellung	Erforderlich?	Wert
ScriptWithArguments	Ja	Ein Skript gefolgt von einer beliebigen Anzahl von Zeichenfolgenargumenten, die durch Kommas getrennt und in Klammern eingeschlossen sind. Beispielsweise, MyScripts.AScript ("Arg1","Arg2"). Das Skript wird für jedes Objekt aufgerufen, das in den Objektsätzen in der <include>-Regel aufgelistet ist. Das Filterskript gibt einen booleschen Wert zurück. Wenn der Rückgabewert TRUE ist, wird das Objekt migriert. Ist der Rückgabewert FALSE, wird es nicht migriert. Der für <script> erforderliche Rückgabewert hängt vom übergeordneten Element ab. Bei Verwendung in <variable> muss der Rückgabewert eine Zeichenfolge sein. Bei Verwendung in <objectSet> muss der Rückgabewert ein zweidimensionales Array von Zeichenfolgen sein. Bei Verwendung in <location> muss der Rückgabewert ein gültiger Speicherort sein, der dem type-Attribut von <location> entspricht. Für <location type="File"> muss das untergeordnete <script>-Element (sofern vorhanden) z. B. ein gültiger Dateispeicherort sein. > [!NOTE] > Wenn Sie eine Datei migrieren, deren Dateiname eine eckige Klammer ([ oder ]) enthält, fügen Sie das Caretzeichen (^) direkt vor der eckigen Klammer ein, damit der Name gültig ist. Für eine Datei mit dem Namen "file].txt" geben Sie z. B. <pattern type="File">c:\documents\mydocs [file^].txt]</pattern> anstelle von <pattern type="File">c:\documents\mydocs [file].txt]</pattern> an. >

Beispiel:

Um die Datei „Sample.doc“ von einem beliebigen Laufwerk des Quell-PC zu migrieren, verwenden Sie <script> wie folgt. Falls mehrere Dateien mit demselben Namen vorhanden sind, werden sie alle migriert.

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

Weitere Beispiele zur Verwendung dieses Elements finden Sie unter Ausschließen von Dateien und Einstellungen, Umleiten von Dateien und Einstellungen, Umleiten von Dateien und Einstellungen und Beispiele für benutzerdefinierte XML-Dateien.

<script>-Funktionen

Sie können die folgenden Funktionen mit dem <script>-Element verwenden:

• Funktionen, die Zeichenfolgen und Muster generieren

• Einfache Ausführungsskripts

Funktionen, die Zeichenfolgen und Muster generieren

Diese Funktionen geben eine Zeichenfolge oder ein Muster zurück.

• GetStringContent

  Sie können GetStringContent mit <script>-Elementen verwenden, die in <variable>-Elementen enthalten sind. Wenn möglich, gibt diese Funktion die Zeichenfolgendarstellung des angegebenen Objekts zurück. Andernfalls gibt sie NULL zurück. Bei Dateiobjekten gibt die Funktion immer NULL zurück.

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

  Einstellung	Erforderlich?	Wert
  ObjectType	Ja	Der Typ des Objekts. Kann „Registry“ oder „Ini“ (bei INI-Datei) sein.
  EncodedLocationPattern	Ja	Wenn der Objekttyp „Registry“ ist muss „EncodedLocationPattern“ ein gültiger Registrierungspfad sein, z. B. „HKLM\SOFTWARE\MyKey[]“. Wenn der Objekttyp „Ini“ ist muss „EncodedLocationPattern“ im folgenden Format angegeben werden: IniFilePath|SectionName[SettingName]
  ExpandContent	Nein (Standardwert = TRUE)	Kann TRUE oder FALSE sein. Wenn der Wert FALSE ist, wird der angegebene Speicherort nicht erweitert, bevor er zurückgegeben wird.

  Beispiel:

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

• GenerateDrivePatterns

  Die GenerateDrivePatterns-Funktion durchläuft die verfügbaren Laufwerke und wählt diejenigen aus, die dem angeforderten Laufwerktyp entsprechen. Anschließend verkettet sie die ausgewählten Laufwerke mit dem Endteil von PatternSegment, um ein vollständiges codiertes Dateimuster zu bilden. Wenn PatternSegment z. B. Path [file.txt] ist und der Laufwerktyp Fixed, generiert die Funktion C:\Path [file.txt] und weitere Muster, wenn andere lokale Festplattenlaufwerke als "C:" vorhanden sind. Mit dieser Funktion können Sie keine Umgebungsvariablen angeben. Sie können GenerateDrivePatterns mit <script>-Elementen verwenden, die in <objectSet> innerhalb von <include>/<exclude> enthalten sind.

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

  Einstellung	Erforderlich?	Wert
  PatternSegment	Ja	Das Suffix eines codierten Musters. Es wird mit der Laufwerkangabe (z. B. "c:\") verkettet, um ein vollständiges Angeben von Speicherorten zu bilden, z. B. "* [*.doc]". PatternSegment kann keine Umgebungsvariable sein.
  DriveType	Ja	Der Laufwerktyp, für den die Muster generiert werden sollen. Folgende Werte sind möglich: Fixed CDROM Removable Remote

  Ein Beispiel für dieses Element finden Sie in der letzten Komponente in der Datei „MigUser.xml“.

• GenerateUserPatterns

  Die Funktion durchläuft alle migrierten Benutzer – mit Ausnahme des momentan verarbeiteten Benutzers, wenn <ProcessCurrentUser> FALSE ist – und erweitert das angegebene Muster im Kontext jedes Benutzers. Wenn z. B. die Benutzer A, B und C Profile in "C:\Documents and Settings" haben, generiert die Hilfsfunktion durch Aufrufen von GenerateUserPattens('File','%userprofile% [*.doc]','TRUE') die folgenden drei Muster:

  • C:\Documents and Settings\A\* [*.doc]

  • C:\Documents and Settings\B\* [*.doc]

  • C:\Documents and Settings\C\* [*.doc]

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

  Einstellung	Erforderlich?	Wert
  ObjectType	Ja	Definiert den Objekttyp. Kann „File“ oder „Registry“ sein.
  EncodedLocationPattern	Ja	Das Angeben von Speicherorten. Umgebungsvariablen sind zulässig.
  ProcessCurrentUser	Ja	Kann TRUE oder FALSE sein. Gibt an, ob die Muster für den aktuellen Benutzer generiert werden sollen.

  Beispiel:

  Wenn GenerateUserPattens('File','%userprofile% [*.doc]','FALSE') aufgerufen wird, während USMT Benutzer A verarbeitet, generiert diese Funktion nur Muster für die Benutzer B und C. Sie können diese Hilfsfunktion verwenden, um komplexe Regeln zu erstellen. Um z. B. alle DOC-Dateien vom Quell-PC zu migrieren, wenn Benutzer X aber nicht migriert wird, migrieren Sie keine der DOC-Dateien aus dem Profil von Benutzer X.

  Unten sehen Sie den Beispielcode für dieses Szenario. Das erste <rules>-Element migriert alle DOC-Dateien auf dem Quell-PC mit Ausnahme der DOC-Dateien in „C:\Documents and Settings“. Das zweite <rules>-Element migriert alle DOC-Dateien aus „C:\Documents and Settings“ mit Ausnahme der DOC-Dateien in den Profilen der anderen Benutzer. Da das zweite <rules>-Element in jedem migrierten Benutzerkontext verarbeitet wird, führt dies letztlich zum gewünschten Verhalten. Das Endergebnis ist wie erwartet.

  <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

Diese Hilfsfunktion ruft die Dokumentsuche auf, um das System nach allen Dateien zu durchsuchen, die migriert werden können. Sie wird im Kontext „System“ oder „User“ aufgerufen, um den Scanvorgang einzugrenzen.

Einstellung	Erforderlich?	Wert
ScanProgramFiles	Nein (Standardwert = FALSE)	Kann TRUE oder FALSE sein. Der ScanProgramFiles-Parameter bestimmt, ob die Dokumentsuche das Verzeichnis Programme durchsucht, um registrierte Dateinamenerweiterungen für bekannte Apps zu sammeln. Wenn Sie ihn z. B. auf TRUE festlegen, werden JPG-Dateien im Photoshop-Verzeichnis erkannt und migriert, wenn JPG als Dateinamenerweiterung für Photoshop registriert ist.
IncludePatterns	Nein (Standardwert = TRUE)	Kann TRUE oder FALSE sein. TRUE generiert Include-Muster und kann unter dem <include>-Element hinzugefügt werden. FALSE generiert Exclude-Muster und kann unter dem <exclude>-Element hinzugefügt werden.
SystemDrive	Nein (Standardwert = FALSE)	Kann TRUE oder FALSE sein. Ist der Parameter auf TRUE festgelegt, sind alle Muster auf das Systemlaufwerk begrenzt.

 <!-- 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>

Einfache Ausführungsskripts

Die folgenden Skripts haben keinen Rückgabewert. Sie können die folgenden Fehler mit <script>-Elementen in <processing>-Elementen verwenden:

• AskForLogoff(). Fordert den Benutzer am Ende der Migration auf, sich abzumelden. Beispiel:

       <processing when="apply-success">
            <script>MigXmlHelper.AskForLogoff()</script>
       </processing>
  

• ConvertToShortFileName(RegistryEncodedLocation). Wenn RegistryEncodedLocation der vollständige Pfad einer vorhandenen Datei ist, konvertiert diese Funktion die Datei in ihren kurzen Dateinamen und aktualisiert dann den Registrierungswert.

• KillExplorer(). Beendet "Explorer.exe" für den aktuellen Benutzerkontext. So kann auf bestimmte Schlüssel und Dateien zugegriffen werden, die während der Ausführung von "Explorer.exe" geöffnet sind. Beispiel:

       <processing when="pre-apply">
            <script>MigXmlHelper.KillExplorer()</script>
       </processing>
  

• RegisterFonts(FileEncodedLocation). Registriert die angegebene Schriftart im angegebenen Verzeichnis. Beispiel:

  <processing when="apply-success">
  <script>MigXmlHelper.RegisterFonts("%CSIDL_COMMON_FONTS%")</script>
  </processing>
  

• **RemoveEmptyDirectories (DirectoryEncodedPattern).**Löscht alle leeren Verzeichnisse, die DirectoryEncodedPattern auf dem Zielcomputer entsprechen.

• RestartExplorer(). Startet "Explorer.exe" am Ende der Migration neu. Beispiel:

       <processing when="post-apply">
            <script>MigXmlHelper.RestartExplorer()</script>
       </processing>
  

• StartService (ServiceName, OptionalParam1, OptionalParam2,…). Startet den angegebenen Dienst in ServiceName. ServiceName ist der Unterschlüssel in "HKLM\System\CurrentControlSet\Services", der die Daten für den angegebenen Dienst enthält. Die optionalen Parameter werden (sofern vorhanden) an die StartService-API übergeben. Weitere Informationen finden Sie auf dieser Microsoft-Website.

• StopService (ServiceName). Beendet den angegebenen Dienst in ServiceName. ServiceName ist der Unterschlüssel in "HKLM\System\CurrentControlSet\Services", der die Daten für den angegebenen Dienst enthält.

• SyncSCM(ServiceShortName). Liest den Start-Typwert aus der Registrierung (HKLM\System\CurrentControlSet\Services\ServiceShortName [Start]), nachdem er vom Migrationsmodul geändert wurde, und synchronisiert dann den Dienststeuerungs-Manager (SCM) mit dem neuen Wert.

<text>

Mit dem <text>-Element können Sie einen Wert für beliebige Umgebungsvariablen in den XML-Migrationsdateien festlegen.

• Anzahl von Vorkommen: eins in jedem <variable>-Element

• Übergeordnete Elemente: <variable>

• Untergeordnete Elemente: keine

Syntax:

<text>NormalText</text>

Einstellung	Wert
NormalText	Wird als normaler Text interpretiert.

Beispiel:

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

<unconditionalExclude>

Das <unconditionalExclude>-Element schließt die angegebenen Dateien und Registrierungswerte unabhängig von den anderen Include-Regeln in anderen XML-Migrationsdateien oder der Datei „Config.xml“ von der Migration aus. Die hier deklarierten Objekte werden nicht migriert, weil dieses Element Vorrang vor allen anderen Regeln hat. Wenn Sie MP3-Dateien mit dieser Option ausschließen, werden sie z. B. auch dann nicht migriert, wenn explizite <include>-Regeln zum Einschließen von MP3-Dateien vorhanden sind.

Verwenden Sie dieses Element, wenn Sie alle MP3-Dateien vom Quell-PC ausschließen möchten. Wenn Sie „C:\UserData“ mit einer anderen Methode sichern, können Sie den gesamten Ordner von der Migration ausschließen. Dieses Element ist mit Vorsicht zu verwenden. Falls eine Datei, die Sie ausschließen, für eine App benötigt wird, funktioniert die App auf dem Ziel-PC möglicherweise nicht richtig.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <rules>

• Untergeordnete Elemente: <objectSet>

Syntax:

<unconditionalExclude></unconditionalExclude>

Die folgende XML-Datei schließt alle MP3-Dateien von der Migration aus. Weitere Beispiele zur Verwendung dieses Elements finden Sie unter Ausschließen von Dateien und Einstellungen.

<migration urlid="https://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>

Das <variable>-Element ist in einem <environment>-Element erforderlich. Für jedes <variable>-Element muss ein <objectSet>-, <script>- oder <text>-Element vorhanden sein. Der Inhalt des <variable>-Elements weist der Umgebungsvariable einen Textwert zu. Für dieses Element sind die folgenden drei Optionen verfügbar:

1. Wenn das <variable>-Element ein <text>-Element enthält, ist der Wert des <variable>-Elements der Wert des <text>-Elements.

2. Wenn das <variable>-Element ein <script>-Element enthält und der Aufruf des Skripts zu einer Zeichenfolge ungleich Null führt, ist der Wert des <variable>-Elements das Ergebnis des Skriptaufrufs.

3. Wenn das <variable>-Element ein <objectSet>-Element enthält und die Auswertung des <objectSet>-Elements mindestens ein Objektmuster ergibt, ist der Wert des ersten Objekts, das dem resultierenden Objektmuster entspricht, der Wert des <variable>-Elements.

• Anzahl von Vorkommen: unbegrenzt

• Übergeordnete Elemente: <environment>

• Erforderliche untergeordnete Elemente: <text>, <script> oder <objectSet>

Syntax:

<variable name="ID" remap=TRUE|FALSE>

</variable>

Einstellung	Erforderlich?	Wert
name	Ja	ID ist ein Zeichenfolgenwert, bei dem es sich um den Namen handelt, mit dem auf die Umgebungsvariable verwiesen wird. Wir empfehlen, die ID mit dem Namen der Komponente zu beginnen, um Namespacekonflikte zu vermeiden. Wenn der Name der Komponente z. B. "MyComponent" ist und die Variable den Installationspfad der Komponente angeben soll, geben Sie MyComponent.InstallPath an.
remap	Nein, Standardwert = FALSE	Gibt an, ob diese Umgebungsvariable als Umgebungsvariable mit erneuter Zuordnung ausgewertet werden soll. Objekte, die sich in einem Pfad unter dem Wert der Umgebungsvariable befinden, werden automatisch an den Speicherort auf dem Ziel-PC verschoben, auf den die Umgebungsvariable verweist.

Das folgende Beispiel stammt aus der Datei „MigApp.xml“:

<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>

Das <version>-Element gibt die Version der Komponente an, hat aber keinen Einfluss auf die Migration.

• Anzahl von Vorkommen: keine oder eins

• Übergeordnete Elemente: <component>

• Untergeordnete Elemente: keine

Syntax:

<version>ComponentVersion</version>

Einstellung	Erforderlich?	Wert
ComponentVersion	Ja	Die Version der Komponente, die Muster enthalten kann.

Beispiel:

<version>4.*</version>

<windowsObjects>

Das <windowsObjects>-Element dient nur zur internen Verwendung in USMT. Verwenden Sie dieses Element nicht.

Anhang

Angeben von Speicherorten

• Angeben codierter Speicherorte. Der in allen Hilfsfunktionen verwendete codierte Speicherort ist eine eindeutige Zeichenfolgendarstellung für den Namen eines Objekts. Er besteht aus dem Knotenteil, nach dem optional das Blatt in eckigen Klammern steht. Dies vereinfacht die Unterscheidung zwischen Knoten und Blättern.

  Die Datei "C:\Windows\Notepad.exe" geben Sie z. B. wie folgt an: c:\Windows[Notepad.exe]. Das Verzeichnis "C:\Windows\System32" wird ähnlich angegeben: c:\Windows\System32. (Beachten Sie, dass hier das []-Konstrukt fehlt.)

  Die Darstellung der Registrierung ist sehr ähnlich. Der Standardwert eines Registrierungsschlüssels wird als leeres []-Konstrukt dargestellt. Der Standardwert für den Registrierungsschlüssel "HKLM\SOFTWARE\MyKey" ist z. B. HKLM\SOFTWARE\MyKey[].

• Angeben von Speicherortmustern. Ein Speicherortmuster wird in ähnlicher Weise angegeben wie ein tatsächlicher Speicherort. Der Unterschied besteht darin, dass sowohl für den Knotenteil als auch den Blattteil Muster verwendet werden können. Ein Muster aus dem Knoten gilt aber nicht auch für das Blatt.

  Dem Muster c:\Windows\* entsprechen z. B. das Verzeichnis "Windows" und all zugehörigen Unterverzeichnisse. Dateien in diesen Verzeichnissen entsprechen dem Muster dagegen nicht. Um auch die Dateien zuzuordnen, müssen Sie c:\Windows\*[*] angeben.

Interne USMT-Funktionen

Die folgenden Funktionen dienen nur zur internen Verwendung in USMT. Verwenden Sie sie nicht in einer XML-Datei.

• AntiAlias

• ConvertScreenSaver

• ConvertShowIEOnDesktop

• ConvertToOfficeLangID

• MigrateActiveDesktop

• MigrateAppearanceUPM

• MigrateDisplayCS

• MigrateDisplaySS

• MigrateIEAutoSearch

• MigrateMouseUPM

• MigrateSoundSysTray

• MigrateTaskBarSS

• SetPstPathInMapiStruc

Gültige Versionsmarkierungen

Sie können folgende Versionsmarkierungen mit verschiedenen Hilfsfunktionen verwenden:

• CompanyName

• FileDescription

• FileVersion

• InternalName

• LegalCopyright

• OriginalFilename

• ProductName

• ProductVersion

Die folgenden Versionsmarkierungen enthalten Werte, die verglichen werden können:

• FileVersion

• ProductVersion

Siehe auch

Weitere Ressourcen

USMT-XML-Referenz