SCCM 2012 - Migration leicht gemacht - Teil 2

In Teil 1 dieser Blogserie habe ich einen Überblick über die Anforderungen für die Vorbereitung einer Migration von Configuration Manager 2007 auf 2012 gegeben. Mit diesen Informationen sollten Sie ein allgemeines Verständnis für die Voraussetzungen haben, die für den Beginn Ihres Migrationsprozesses erforderlich sind.

Der Boundary-Migrationsprozess ermöglicht eine direkte Eins-zu-eins-Migration jeder Boundary, die innerhalb einer ConfigMgr 2007-Quellsite angegeben ist. Da ConfigMgr 2012 Begrenzungsgruppen in Verbindung mit Standardbegrenzungen verwendet, erstellt der Migrationsprozess jede Begrenzung und erstellt automatisch eine Begrenzungsgruppe (für den entsprechenden Quellstandort), zu der die migrierten Begrenzungen gehören. Abbildung 1 zeigt drei Begrenzungen, die von einem einzigen ConfigMgr 2007-Standort migriert wurden, und Abbildung 2 zeigt, dass eine einzelne Begrenzungsgruppe erstellt wurde, die drei Begrenzungen enthält.

Abbildung 1 - Migrierte ConfigMgr 2012-Grenzen

Abbildung 2 - Automatisch erstellte ConfigMgr 2012-Begrenzungsgruppe

Die Migration von Sammlungen ist bei weitem einer der nützlichsten Prozesse des Dienstprogramms, und zwar aus mehreren Gründen. In erster Linie werden die für die Migration ausgewählten Sammlungen automatisch vom Migrationsprogramm gescannt, um festzustellen, ob es software Pakete, Anzeigen, software Updates oder Aufgabensequenzen gibt, die mit der/den ausgewählten Sammlung(en) verbunden sind. Wenn eines oder alle der oben genannten Elemente identifiziert werden, bietet das Dienstprogramm die Option, diese speziell referenzierten Elemente zusammen mit der/den Sammlung(en) zu migrieren.

Wie Sie feststellen können, sind "Anzeigen" nicht in der Standardliste der Migrationsobjekte enthalten, die zuvor erwähnt wurden, aber Teil der Sammlungsmigration sind. Dies ist kein Irrtum. Die Migration einer Anzeige ist nur eine Option während der Sammlungsmigration, und auch nur dann, wenn eine Anzeige auf die zu migrierende Sammlung abzielt. Der Grund dafür ist, dass eine Anzeige nur dann migriert werden kann, wenn die Zielsammlung und das Zielpaket vorhanden sind, was meiner Meinung nach nicht der Fall ist.

Zweitens, wenn Sie eine Sammlungsstruktur haben, die leere Sammlungen für Platzhalter und Organisation verwendet, übersetzt das Migrationsprogramm diese Sammlungen in Organisationsordner. Auch ich war anfangs skeptisch, aber nachdem ich die Übersetzung der Migrationsobjekte gesehen habe, kann ich sagen, dass der Prozess sehr effizient ist. Der Screenshot in Abbildung 3 zeigt die Sammlungen, die für die Migration ausgewählt wurden, und Abbildung 4 zeigt, wie diese Sammlungen nach der Migration aussehen.

Abbildung 3 - Assistent für die Migration von Sammlungen

Abbildung 4 - Migrierte Sammlungen

Wichtiger Hinweis: Sammlungen, die sowohl Benutzer als auch Systeme enthalten, können nicht migriert werden. Es wird empfohlen, dass gemischte Sammlungen vor der Migration getrennt werden.

Software Pakete sind in Bezug auf die für die Migration verfügbaren Objekte offensichtlich ein Kinderspiel. Alle Paketoptionen und Programme bleiben während der Migration erhalten. Allerdings werden die migrierten Pakete nicht in das neue "Anwendungsmodell" übersetzt. Abbildung 5 zeigt zwei migrierte Pakete und die entsprechende Anzahl von Programmen.

Abbildung 5 - Migrierte Software Pakete

Microsoft hat einen Package Conversion Manager (PCM) entwickelt, der Sie bei der Umwandlung Ihrer migrierten Software Pakete in ConfigMgr 2012-Anwendungen unterstützt. Weitere Informationen über den PCG finden Sie unter dem folgenden Link:

https://technet.microsoft.com/en-us/library/hh531519.aspx

Ein Vorbehalt ist der Speicherort der Quellinhalte. Um eine nahtlose Migration für die Pakete von software zu ermöglichen, sollten alle Quelldateispeicherorte einen UNC-Pfad verwenden. Jedes Paket, das bei der Migration einen lokalen Laufwerkspfad als Quellspeicherort verwendet, wird nur dann verteilt, wenn sowohl der angegebene Pfad als auch der entsprechende Quellinhalt auf dem ConfigMgr 2012-Server vorhanden sind.

Wie in Teil 1 dieses Blogs erwähnt, muss die gewünschte ConfigMgr 2012-Infrastruktur installiert und konfiguriert sein, um eine Migration ordnungsgemäß durchführen zu können. Ich muss betonen, wie wichtig dies im Hinblick auf die Migration von software Updates ist. Während es wahrscheinlich offensichtlich ist, dass Software Update-Punkt(e) vor der Migration von Software Updates erforderlich sind, muss betont werden, dass der Produktkatalog und die Update-Sprachen perfekt mit der ConfigMgr 2007-Konfiguration übereinstimmen und erfolgreich synchronisiert werden müssen. Wenn ein einziges Update in einem ganzen Update-Paket fehlt, wird die Migration dieses Pakets fehlschlagen.

Wichtiger Hinweis: Alle benutzerdefinierten Updates, lokal veröffentlichte SCUP-Updates, müssen neu veröffentlicht werden, da sie nicht migriert werden können.

Software Update-Pakete sowie Update-Vorlagen sind in ConfigMgr 2012 weiterhin vorhanden. Für Update-Vorlagen müssen die Dauereinstellungen neu konfiguriert werden, da sie nicht migriert werden. Bei der Migration werden Software Update-Listen in Software Update-Gruppen umgewandelt, und eine Software Update-Bereitstellung wird in eine Bereitstellung und die entsprechende Update-Gruppe umgewandelt.

Bei der Migration von OSD-Objekten werden die Treiber, Treiberpakete, OS-Images und OS-Installationspakete (jetzt OS-Installer genannt) genauso migriert wie in ConfigMgr 2007. Die einzige Ausnahme von dieser Regel sind die Boot Images. Sie sind zwar als Objekte aufgeführt, die migriert werden können, aber es gibt einige Details, die zu beachten sind.

Der erste und wichtigste Punkt ist, dass Anpassungen, die an Boot-Images in ConfigMgr 2007 vorgenommen wurden, nicht migriert werden können. Jetzt, wo einige von Ihnen innerlich aufschreien, möchte ich Ihnen erklären, warum. Die eigentliche Boot-Image-WIM-Datei ist nicht das, was migriert wird. Die Treiber, die in die Boot-Images von ConfigMgr 2007 injiziert wurden, werden automatisch in ähnlich benannte Boot-Images injiziert, die aus den Boot-WIM-Dateien des AIK auf dem ConfigMgr 2012-Server erstellt werden. Positiv zu vermerken ist, dass über die neue grafische Benutzeroberfläche in ConfigMgr 2012 eine Vielzahl von Anpassungen an Boot-Images vorgenommen werden können, wie z. B. Pre-Execution Hooks und zugehörige Dateien.

Auch die Task-Sequenzen werden fast identisch migriert. Die einzige Änderung, die automatisch vorgenommen wird, ist die Verwendung eines Client-Installationspakets; es wird durch einen Verweis auf das vorab erstellte ConfigMgr 2012 Client-Paket ersetzt.

Es gibt zwei Punkte, die einen kurzen Überblick über die Migration von DCM-Objekten rechtfertigen. Erstens können ConfigMgr 2007 Configuration Packs in ConfigMgr 2012 importiert werden. Das Konfigurationspaket wird automatisch konvertiert, um kompatibel zu sein. Zweitens: Alle nicht interpretierten Konfigurationselemente werden NICHT migriert und können auch nicht importiert werden.

Weder bei Asset Intelligence noch bei Software Metering gibt es wesentliche Änderungen. Daher ist die Migration dieser beiden Kategorien im Grunde nahtlos und wird in ConfigMgr 2012 genauso erscheinen wie im Jahr 2007.

• SCCM-Abfragen
• Site-Sicherheit und Instanzrechte
• Objektsicherheit und Instanzrechte
• SCCM-Berichte
• Kundeninventar
• Daten zur Kundenhistorie
• AMT-Bereitstellungsdaten
• Client-Cache-Dateien
• Boot-Image-Anpassungen
• Sekundärer Standort

Schauen Sie bitte in Teil 3 wieder vorbei, der sich mit dem eigentlichen Migrationsprozess befassen wird, einschließlich der Erstellung von Migrationsaufträgen, wie die migrierten Elemente in der neuen Konsole aussehen und einige Punkte zur Bereinigung der Migration. Und wie immer hoffe ich, dass diese Informationen für alle, die sich mit Configuration Manager 2012 beschäftigen, von Nutzen sind.