Azure AD Connect: Stagingserver und Notfallwiederherstellung

Mit einem Server im Stagingmodus können Sie Änderungen an der Konfiguration vornehmen und eine Vorschau der Änderungen anzeigen, bevor Sie den Server aktiv schalten. Ein Server im Stagingmodus ermöglicht es Ihnen außerdem, einen vollständigen Import und eine vollständige Synchronisierung durchzuführen und so sicherzustellen, dass alle Änderungen wie erwartet durchgeführt werden, bevor Sie die Änderungen in Ihrer Produktionsumgebung implementieren.

Stagingmodus

Der Stagingmodus kann für verschiedene Szenarien genutzt werden, darunter:

  • Hochverfügbarkeit.
  • Testen und Bereitstellen neuer Konfigurationsänderungen.
  • Einführen eines neuen Servers und Außerbetriebnahme des alten Servers.

Bei der Installation können Sie auswählen, dass der Server in den Stagingmodusversetzt werden soll. Dadurch wird der Server für Import und Synchronisierung aktiviert, es werden jedoch keine Exportvorgänge ausgeführt. Ein Server im Stagingmodus führt keine Kennwortsynchronisierung und kein Kennwortrückschreiben durch – selbst dann nicht, wenn Sie diese Features bei der Installation ausgewählt haben. Wenn Sie den Stagingmodus deaktivieren, beginnt der Server mit dem Exportieren und aktiviert die Kennwortsynchronisierung und das Kennwortrückschreiben.

Hinweis

Angenommen Sie, Sie haben eine Azure AD Connect-Instanz, für die Kennworthashsynchronisierung aktiviert ist. Wenn Sie den Stagingmodus aktivieren, beendet der Server das Synchronisieren von Kennwortänderungen aus lokalem AD. Wenn Sie den Stagingmodus deaktivieren, setzt der Server das Synchronisieren von Kennwortänderungen an der Stelle fort, an der das Synchronisieren zuletzt beendet wurde. War der Stagingsmodus längere Zeit für den Server aktiviert, kann es etwas länger dauern, bis der Server alle Kennwortänderungen synchronisiert hat, die es in diesem Zeitraum gegeben hat.

Sie können einen Export weiterhin mithilfe des Synchronisierungsdienst-Managers erzwingen.

Ein Server im Stagingmodus empfängt weiterhin Änderungen von Active Directory und Azure AD und kann bei einem Ausfall schnell die Zuständigkeiten eines anderen Servers übernehmen. Wenn Sie Konfigurationsänderungen an Ihrem primären Server vornehmen, müssen Sie die gleichen Änderungen auch für den Server im Stagingmodus durchführen.

Wenn Sie sich bisher nur mit älteren Synchronisierungstechnologien auskennen, müssen Sie wissen, dass Änderungen für den Stagingmodus gelten, seit dieser über eine eigene SQL-Datenbank verfügt. Dank dieser Architektur kann sich der Server im Stagingmodus in einem anderen Datencenter befinden.

Überprüfen der Konfiguration eines Servers

Führen Sie zum Anwenden dieser Methode die folgenden Schritte aus:

  1. Vorbereiten
  2. Configuration
  3. Importieren und Synchronisieren
  4. Überprüfen
  5. Wechseln des aktiven Servers

Vorbereiten

  1. Installieren Sie Azure AD Connect, wählen Sie Stagingmodus aus, und deaktivieren Sie auf der letzten Seite des Installations-Assistenten die Option Synchronisierung starten. In diesem Modus kann das Synchronisierungsmodul manuell ausgeführt werden. Screenshot zeigt die Seite “Bereit zum Konfigurieren“ im Dialogfeld Azure AD Connect.
  2. Melden Sie sich ab und wieder an, und wählen Sie im Startmenü die Option Synchronisierungsdienstaus.

Konfiguration

Wenn Sie benutzerdefinierte Änderungen an den primären Server vorgenommen haben und die Konfiguration mit dem Stagingserver vergleichen möchten, verwenden Sie Azure AD Connect configuration documenter (Azure AD Connect-Konfigurationsdokumentierer).

Importieren und Synchronisieren

  1. Wählen Sie Connectors aus, und wählen Sie dann den ersten Connector mit dem Typ Active Directory Domain Services aus. Klicken Sie auf Ausführen, wählen Sie Vollständiger Import aus, und klicken Sie auf OK. Führen Sie diese Schritte für alle Connectors dieses Typs aus.
  2. Wählen Sie den Connector mit dem Typ Azure Active Directory (Microsoft) aus. Klicken Sie auf Ausführen, wählen Sie Vollständiger Import aus, und klicken Sie auf OK.
  3. Stellen Sie sicher, dass die Registerkarte „Connectors“ noch ausgewählt ist. Klicken Sie für jeden Connector mit dem Typ Active Directory Domain Services auf Ausführen, wählen Sie Deltasynchronisierung aus, und klicken Sie auf OK.
  4. Wählen Sie den Connector mit dem Typ Azure Active Directory (Microsoft) aus. Klicken Sie auf Ausführen, wählen Sie Deltasynchronisierung aus, und klicken Sie auf OK.

Sie haben einen Stagingexport der Änderungen an Azure AD und der lokalen Active Directory-Umgebung durchgeführt (wenn Sie eine Exchange-Hybridbereitstellung verwenden). In den nächsten Schritten können Sie überprüfen, was geändert wird, bevor Sie mit dem Export in die Verzeichnisse beginnen.

Überprüfen

  1. Starten Sie eine Eingabeaufforderung, und wechseln Sie zu: %ProgramFiles%\Microsoft Azure AD Sync\bin
  2. Führen Sie folgenden Befehl aus: csexport "Name of Connector" %temp%\export.xml /f:x Den Namen des Connectors finden Sie im Synchronisierungsdienst. Für Azure AD sieht der Name in etwa wie folgt aus: contoso.com – Azure AD.
  3. Führen Sie folgenden Befehl aus: CSExportAnalyzer %temp%\export.xml > %temp%\export.csv Im Ordner „%temp%“ befindet sich nun eine Datei namens „export.csv“, die Sie sich in Microsoft Excel ansehen können. Diese Datei enthält alle Änderungen, die exportiert werden sollen.
  4. Nehmen Sie erforderliche Änderungen an den Daten oder der Konfiguration vor, und führen Sie die oben genannten Schritte (Importieren, Synchronisieren, Überprüfen) erneut aus, bis Sie die Änderungen erhalten, die Sie exportieren möchten.

Grundlegendes zur Datei "export.csv"

Die meisten Bestandteile der Datei sind selbsterklärend. Nachfolgend werden zum Verständnis des Inhalts einige Abkürzungen erläutert:

  • OMODT: Object Modification Type. Gibt an, ob es sich bei dem Vorgang auf Objektebene um einen Hinzufüge-, Aktualisierungs- oder Löschvorgang handelt.
  • AMODT: Attribute Modification Type. Gibt an, ob es sich bei dem Vorgang auf Attributebene um einen Hinzufüge-, Aktualisierungs- oder Löschvorgang handelt.

Abrufen allgemeiner Bezeichner

Die export.csv-Datei enthält alle Änderungen, die exportiert werden sollen. Jede Zeile entspricht einer Änderung für ein Objekt im Connectorbereich, und das Objekt wird durch das DN-Attribut identifiziert. Das DN-Attribut ist ein eindeutiger Bezeichner, der einem Objekt im Connectorbereich zugewiesen ist. Wenn Sie viele Zeilen/Änderungen in „export.csv“ analysieren müssen, ist es allein anhand des DN-Attributs möglicherweise schwierig, zu ermitteln, auf welche Objekte sich die Änderungen beziehen. Um das Analysieren der Änderungen zu vereinfachen, verwenden Sie das PowerShell-Skript csanalyzer.ps1. Das Skript ruft allgemeine Bezeichner der Objekte ab (z.B. „displayName“, „userPrincipalName“). So verwenden Sie das Skript

  1. Kopieren Sie das PowerShell-Skript aus dem Abschnitt CSAnalyzer in eine Datei mit dem Namen csanalyzer.ps1.
  2. Öffnen Sie ein PowerShell-Fenster, und navigieren Sie zu dem Ordner, in dem Sie das PowerShell-Skript erstellt haben.
  3. Führen Sie .\csanalyzer.ps1 -xmltoimport %temp%\export.xml aus.
  4. Sie verfügen jetzt über eine Datei namens processedusers1.csv, die in Microsoft Excel untersucht werden kann. Beachten Sie, dass die Datei eine Zuordnung des DN-Attributs zum allgemeinen Bezeichner (z.B. „displayName“ und „userPrincipalName“) enthält. Sie enthält derzeit nicht die tatsächlichen Attributänderungen, die exportiert werden sollen.

Wechseln des aktiven Servers

Azure AD Connect kann in einer Aktiv-Passiv-Einrichtung für hohe Verfügbarkeit eingerichtet werden, bei der ein Server Änderungen an synchronisierten AD-Objekte aktiv an Azure AD sendet, und der passive Server diese Änderungen bereitstellt, falls es diese Aufgabe übernehmen muss.

Hinweis

Sie können Azure AD Connect nicht in einem Aktiv-Aktiv-Einrichtung einrichten. Es muss Aktiv-Passiv verwendet werden. Stellen Sie sicher, dass nur 1 Azure AD Connect-Server aktiv Änderungen synchronisiert.

Weitere Informationen zum Einrichten eines Azure AD Connect-Synchronisierungsservers im Stagingmodus finden Sie unter Stagingmodus.

Möglicherweise müssen Sie aus mehreren Gründen ein Failover der Synchronisierungsserver ausführen, z. B. Upgrade der Version von Azure AD Connect oder Empfang einer Warnung, dass der Integritätsdienst des Synchronisierungsdiensts keine aktuellen Informationen empfängt. In diesen Fällen können Sie ein Failover der Synchronisierungsserver versuchen, indem Sie die folgenden Schritte ausführen.

Voraussetzungen

  • Ein derzeit aktiver Azure AD Connect-Synchronisierungsserver
  • Ein Azure AD Connect-Synchronisierungsserver im Stagingmodus

Versetzen des derzeit aktiven Synchronisierungsservers in den Stagingmodus

Es muss sichergestellt sein, dass während dieses Prozesses immer jeweils nur ein Synchronisierungsserver Änderungen synchronisiert. Wenn der derzeit aktive Synchronisierungsserver erreichbar ist, können Sie die folgenden Schritte ausführen, um ihn in den Stagingmodus zu versetzen. Wenn er nicht erreichbar ist, müssen Sie sicherstellen, dass der Server oder die VM den Zugriff nicht unerwartet wiedererlangt, indem der Server heruntergefahren oder von ausgehenden Verbindungen isoliert wird. Fahren Sie anschließend mit den Schritten zum Wechseln des derzeitigen Synchronisierungsserver im Stagingmodus in den aktiven Modus fort.

  1. Öffnen Sie für den derzeit aktiven Azure AD Connect-Server die Azure AD Connect-Konsole, und klicken Sie dann auf „Stagingmodus konfigurieren“ und dann auf „Weiter“:

    Screenshot: Hervorhebung des Stagingmodus im Azure AD Connect-Dialogfeld des aktiven Servers.

  2. Sie müssen sich bei Azure AD mit den Anmeldeinformationen eines globalen Administrators oder eines Administrators für hybride Identitäten anmelden:

    Screenshot: Anmeldeaufforderung im Azure AD Connect-Dialogfeld des aktiven Servers.

  3. Aktivieren Sie das Kontrollkästchen für den Stagingmodus, und klicken Sie auf „Weiter“:

    Screenshot: Konfiguration des Stagingmodus im Azure AD Connect-Dialogfeld des aktiven Servers.

  4. Der Azure AD Connect-Server sucht nach installierten Komponenten und fragt Sie dann, ob Sie den Synchronisierungsprozess starten möchten:

    Screenshot: Bildschirm „Bereit für die Konfiguration“ im Azure AD Connect-Dialogfeld des aktiven Servers.

Da sich der Server im Stagingmodus befindet, werden keine Änderungen in Azure AD geschrieben, aber alle AD-Änderungen im Connectorbereich beibehalten, damit sie später geschrieben werden können.
Es wird empfohlen, den Synchronisierungsprozess für den Server im Stagingmodus weiterhin ausführen zu lassen, sodass er bei Aktivierung schnell die Synchronisierung übernehmen kann und keine umfangreiche Synchronisierung durchführen muss, um den aktuellen Zustand der AD/Azure AD-Synchronisierung zu erfassen.

  1. Nachdem Sie ausgewählt haben, ob der Synchronisierungsprozess gestartet oder beendet werden soll, wird der Azure AD Connect-Server nach Klicken auf „Konfigurieren“ automatisch im Stagingmodus konfiguriert.
    Danach wird ein Bildschirm mit der Bestätigung angezeigt, dass der Stagingmodus aktiviert wurde.
    Sie können auf „Beenden“ klicken, um den Vorgang zu beenden.

  2. Sie können bestätigen, dass der Server erfolgreich in den Stagingmodus versetzt wurde, indem Sie die Synchronisierungsdienstkonsole öffnen.
    Dort sollte es keine weiteren Exportaufträge geben, da die Änderung sowie Voll- und Delta-Importe das Suffix „(Stage Only)“ aufweisen (siehe folgende Abbildung):

    Screenshot: Synchronisierungsdienstkonsole im Azure AD Connect-Dialogfeld des aktiven Servers.

Versetzen des aktuellen Synchronisierungsservers im Stagingmodus in den aktiven Modus

An dieser Stelle sollten sich alle Azure AD Connect-Synchronisierungsserver im Stagingmodus befinden und keine Änderungen exportieren. Wir können jetzt unseren Synchronisierungsserver im Stagingmodus in den aktiven Modus versetzen und Änderungen aktiv synchronisieren.

  1. Wechseln Sie nun zum Azure AD Connect-Server, der ursprünglich im Stagingmodus war, und öffnen Sie die Azure AD Connect-Konsole.

    Klicken Sie auf „Stagingmodus konfigurieren“ und dann auf „Weiter“:

    Screenshot: Hervorhebung des Stagingmodus im Azure AD Connect-Dialogfeld des Stagingservers.

    Die Meldung am unteren Rand der Konsole weist darauf hin, dass sich dieser Server im Stagingmodus befindet.

  2. Melden Sie sich bei Azure AD an, und navigieren Sie dann zum Bildschirm „Stagingmodus“.

    Deaktivieren Sie das Kontrollkästchen für den Stagingmodus, und klicken Sie auf „Weiter“.

    Screenshot: Konfiguration des Stagingmodus im Azure AD Connect-Dialogfeld des Stagingservers.

    Laut Warnung auf dieser Seite muss unbedingt sichergestellt sein, dass kein anderer Azure AD Connect-Server aktiv eine Synchronisierung durchführt.

    Es sollte jederzeit nur einen aktiven Azure AD Connect-Synchronisierungsserver geben.

  3. Aktivieren Sie dieses Kontrollkästchen, wenn Sie aufgefordert werden, den Synchronisierungsprozess zu starten, und klicken Sie auf „Konfigurieren“:

    Screenshot: Bildschirm „Bereit für die Konfiguration“ im Azure AD Connect-Dialogfeld des Stagingservers.

  4. Nach Abschluss des Vorgangs sollte der folgende Bestätigungsbildschirm angezeigt werden, in dem Sie auf „Beenden“ klicken können:

    Screenshot: Bestätigungsbildschirm im Azure AD Connect-Dialogfeld des Stagingservers.

  5. Sie können erneut bestätigen, ob dies funktioniert, indem Sie die Synchronisierungsdienstkonsole öffnen und überprüfen, ob Exportaufträge ausgeführt werden:

    Screenshot: Synchronisierungsdienstkonsole im Azure AD Connect-Dialogfeld des Stagingservers.

Notfallwiederherstellung

Teil des Implementierungsentwurfs ist die Planung für einen notfallbedingten Ausfall des Synchronisierungsservers. Es stehen mehrere Modelle zur Verfügung, und die Wahl des Modells ist von verschiedenen Faktoren abhängig:

  • Wie hoch ist die Toleranz, wenn während der Ausfallzeit keine Objektänderungen in Azure AD durchgeführt werden können?
  • Bei Verwendung der Kennwortsynchronisierung: Ist es für die Benutzer akzeptabel, dass sie in Azure AD ihr altes Kennwort verwenden müssen, wenn sie ihr lokales Kennwort ändern?
  • Besteht eine Abhängigkeit von Echtzeitvorgängen, beispielsweise dem Kennwortrückschreiben?

Abhängig von Ihren Antworten auf diese Fragen und Ihrer Organisationsrichtlinie kann eine der folgenden Strategien implementiert werden:

  • Führen Sie ggf. eine Neuerstellung durch.
  • Richten Sie einen Reserveserver im Standbymodus ein, auch bezeichnet als Stagingmodus.
  • Verwenden Sie virtuelle Computer.

Wenn Sie nicht die integrierte SQL Express-Datenbank verwenden, lesen Sie sich auch den Abschnitt Hochverfügbarkeit von SQL durch.

Neuerstellung, falls erforderlich

Eine sinnvolle Strategie besteht darin, eine ggf. erforderliche Neuerstellung des Servers zu planen. In der Regel sind die Installation des Synchronisierungsmoduls und der anfängliche Import sowie die Synchronisierung innerhalb weniger Stunden abgeschlossen. Wenn kein Ersatzserver verfügbar ist, kann vorübergehend ein Domänencontroller zum Hosten des Synchronisierungsmoduls eingesetzt werden.

Das Synchronisierungsmodul speichert keine Statusinformationen zu den Objekten, deshalb kann die Datenbank mithilfe der Daten in Active Directory und Azure AD neu erstellt werden. Das Attribut sourceAnchor wird verwendet, um die lokalen Objekte und die Cloudobjekte miteinander zu verknüpfen. Wenn Sie den Server mit vorhandenen lokalen Objekten und Cloudobjekten neu erstellen, werden diese Objekte bei der Neuinstallation vom Synchronisierungsmodul erneut abgeglichen. Dokumentieren und speichern Sie die am Server vorgenommenen Änderungen, beispielsweise die Filter- und Synchronisierungsregeln. Diese benutzerdefinierten Konfigurationen müssen erneut angewendet werden, bevor Sie die Synchronisierung starten.

Stellen Sie einen Reservestandbyserver bereit (Stagingmodus)

Wenn Sie über eine komplexere Umgebung verfügen, wird empfohlen, mindestens einen Standbyserver einzurichten. Bei der Installation können Sie festlegen, dass der Server in den Stagingmodusversetzt werden soll.

Weitere Informationen finden Sie unter Stagingmodus.

Einsatz virtueller Computer

Eine gängige und unterstützte Methode ist die Ausführung des Synchronisierungsmoduls auf einem virtuellen Computer. Wenn ein Problem mit dem Host vorliegt, kann das Image mit dem Synchronisierungsmodulserver zu einem anderen Server migriert werden.

Hochverfügbarkeit von SQL

Falls Sie nicht SQL Server Express (in Azure AD Connect enthalten) verwenden, sollten Sie auch Hochverfügbarkeit für SQL Server in Erwägung ziehen. Zu den unterstützten Hochverfügbarkeitslösungen gehören SQL-Clustering und SQL AOA (Always On Availability Groups, Always On-Verfügbarkeitsgruppen). Nicht unterstützt wird z.B. die Spiegelung.

Unterstützung für SQL AOA wurde in Version 1.1.524.0 zu Azure AD Connect hinzugefügt. Vor der Installation von Azure AD Connect müssen Sie SQL AOA aktivieren. Während der Installation erkennt Azure AD Connect, ob die bereitgestellte SQL-Instanz für SQL AOA aktiviert ist. Wenn SQL AOA aktiviert ist, prüft Azure AD Connect darüber hinaus, ob SQL AOA für die Verwendung synchroner oder asynchroner Replikationen konfiguriert ist. Bei der Einrichtung des Verfügbarkeitsgruppenlisteners wird empfohlen, die Eigenschaft „RegisterAllProvidersIP“ auf 0 festzulegen. Dies liegt daran, weil Azure AD Connect Verbindungen zu SQL derzeit über den SQL Native Client herstellt und der SQL Native Client die Verwendung der Eigenschaft „MultiSubNetFailover“ nicht unterstützt.

Anhang CSAnalyzer

Finden Sie im Abschnitt Überprüfen Anleitungen zum Verwenden dieses Skripts.

Param(
	[Parameter(Mandatory=$true, HelpMessage="Must be a file generated using csexport 'Name of Connector' export.xml /f:x)")]
	[string]$xmltoimport="%temp%\exportedStage1a.xml",
	[Parameter(Mandatory=$false, HelpMessage="Maximum number of users per output file")][int]$batchsize=1000,
	[Parameter(Mandatory=$false, HelpMessage="Show console output")][bool]$showOutput=$false
)

#LINQ isn't loaded automatically, so force it
[Reflection.Assembly]::Load("System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089") | Out-Null

[int]$count=1
[int]$outputfilecount=1
[array]$objOutputUsers=@()

#XML must be generated using "csexport "Name of Connector" export.xml /f:x"
write-host "Importing XML" -ForegroundColor Yellow

#XmlReader.Create won't properly resolve the file location,
#so expand and then resolve it
$resolvedXMLtoimport=Resolve-Path -Path ([Environment]::ExpandEnvironmentVariables($xmltoimport))

#use an XmlReader to deal with even large files
$result=$reader = [System.Xml.XmlReader]::Create($resolvedXMLtoimport) 
$result=$reader.ReadToDescendant('cs-object')
if($result)
{
	do 
	{
		#create the object placeholder
		#adding them up here means we can enforce consistency
		$objOutputUser=New-Object psobject
		Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name ID -Value ""
		Add-Member -InputObject $objOutputUser -MemberType NoteProperty -Name Type -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name DN -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name operation -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name UPN -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name displayName -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name sourceAnchor -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name alias -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name primarySMTP -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name onPremisesSamAccountName -Value ""
		Add-Member -inputobject $objOutputUser -MemberType NoteProperty -Name mail -Value ""

		$user = [System.Xml.Linq.XElement]::ReadFrom($reader)
		if ($showOutput) {Write-Host Found an exported object... -ForegroundColor Green}

		#object id
		$outID=$user.Attribute('id').Value
		if ($showOutput) {Write-Host ID: $outID}
		$objOutputUser.ID=$outID

		#object type
		$outType=$user.Attribute('object-type').Value
		if ($showOutput) {Write-Host Type: $outType}
		$objOutputUser.Type=$outType

		#dn
		$outDN= $user.Element('unapplied-export').Element('delta').Attribute('dn').Value
		if ($showOutput) {Write-Host DN: $outDN}
		$objOutputUser.DN=$outDN

		#operation
		$outOperation= $user.Element('unapplied-export').Element('delta').Attribute('operation').Value
		if ($showOutput) {Write-Host Operation: $outOperation}
		$objOutputUser.operation=$outOperation

		#now that we have the basics, go get the details

		foreach ($attr in $user.Element('unapplied-export-hologram').Element('entry').Elements("attr"))
		{
			$attrvalue=$attr.Attribute('name').Value
			$internalvalue= $attr.Element('value').Value

			switch ($attrvalue)
			{
				"userPrincipalName"
				{
					if ($showOutput) {Write-Host UPN: $internalvalue}
					$objOutputUser.UPN=$internalvalue
				}
				"displayName"
				{
					if ($showOutput) {Write-Host displayName: $internalvalue}
					$objOutputUser.displayName=$internalvalue
				}
				"sourceAnchor"
				{
					if ($showOutput) {Write-Host sourceAnchor: $internalvalue}
					$objOutputUser.sourceAnchor=$internalvalue
				}
				"alias"
				{
					if ($showOutput) {Write-Host alias: $internalvalue}
					$objOutputUser.alias=$internalvalue
				}
				"proxyAddresses"
				{
					if ($showOutput) {Write-Host primarySMTP: ($internalvalue -replace "SMTP:","")}
					$objOutputUser.primarySMTP=$internalvalue -replace "SMTP:",""
				}
			}
		}

		$objOutputUsers += $objOutputUser

		Write-Progress -activity "Processing ${xmltoimport} in batches of ${batchsize}" -status "Batch ${outputfilecount}: " -percentComplete (($objOutputUsers.Count / $batchsize) * 100)

		#every so often, dump the processed users in case we blow up somewhere
		if ($count % $batchsize -eq 0)
		{
			Write-Host Hit the maximum users processed without completion... -ForegroundColor Yellow

			#export the collection of users as a CSV
			Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
			$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation

			#increment the output file counter
			$outputfilecount+=1

			#reset the collection and the user counter
			$objOutputUsers = $null
			$count=0
		}

		$count+=1

		#need to bail out of the loop if no more users to process
		if ($reader.NodeType -eq [System.Xml.XmlNodeType]::EndElement)
		{
			break
		}

	} while ($reader.Read)

	#need to write out any users that didn't get picked up in a batch of 1000
	#export the collection of users as CSV
	Write-Host Writing processedusers${outputfilecount}.csv -ForegroundColor Yellow
	$objOutputUsers | Export-Csv -path processedusers${outputfilecount}.csv -NoTypeInformation
}
else
{
    Write-Host "Imported XML file is empty. No work to do." -ForegroundColor Red
}

Nächste Schritte

Übersichtsthemen