Migration von SCCM 2007 zu SCCM 2012 \ 1511

Lange habe ich "geträumt", um zu diesem Thema zu schreiben, die ganze Faulheit war ... Machen Sie sich mit Keksen zu schaffen, das ist eine lange Zeit. Möglicherweise sind einige Fehler aufgetreten. Lassen Sie mich wissen, wenn Sie sie finden. Es ist schwierig, ~ 35.000 Zeichen zu subtrahieren. Ich möchte den Post absichtlich nicht in mehrere Teile aufteilen, damit sich alle von mir gesammelten Informationen an einem Ort befinden.

Upd. Sie können ohne 2012 direkt von 2007 nach 1511 migrieren. Im Allgemeinen gilt alles, was in diesem Artikel beschrieben wird, auch für die Migration nach 1511.


1. Architektur
Die SCCM 2012-Hierarchie besteht aus drei Servertypen: Zentraladministrationsstandort, Primärstandort und Sekundärstandort. Das Erstellen einer Hierarchie mit vier Ebenen wie der vorhandenen SCCM 2007-Hierarchie mit SCCM 2012 ist nicht möglich, da die SCCM 2012-Hierarchie aus drei Ebenen besteht. Die Beziehung zwischen den Servern in der Parent-Child-Hierarchie, der CAS-Server steht an der Spitze der Hierarchie, die primären Standortserver sind ihr untergeordnet, und die sekundären Standortserver sind ihnen untergeordnet. Ab Version 2012 SP1 kann Standalone-Primärserver in die SCCM-Hierarchie „konvertiert“ werden. Wenn also weniger als 90.000 bis 95.000 Clients in der Hierarchie vorhanden sind, hat die SCCM 2012-Hierarchie mit einem CAS-Server keinen Sinn.

Die Quell- und Ziel-SCCM-Hierarchien dürfen nicht dieselben Standortcodes enthalten. Daher müssen alle Standortcodes während der Migration geändert werden.

Nur SCCM 2007-Server mit installiertem SP2 oder höher können an der Migration teilnehmen.
Das Erweitern des Active Directory-Verzeichnisdienstschemas zur Installation der SCCM 2012-Hierarchie parallel zu SCCM 2007 ist nicht erforderlich (wenn die Schemaerweiterung zur Installation von SCCM 2007 durchgeführt wurde).

1.1. Website für die Zentraladministration Der
CAS-Server ist der Haupt-SCCM-Hierarchie-Server. Die SCCM 2012-Hierarchie kann nicht mehr als einen CAS-Server enthalten. Außerdem muss sie zuerst in der Hierarchie installiert werden (nicht relevant nach 2012 SP1). Der CAS-Server unterstützt nicht alle Rollen, da er nicht zur Interaktion mit Clients verwendet wird.

Der CAS-Server wird zum Verwalten der gesamten SCCM-Infrastruktur verwendet und ist der einzige Server, auf dem Informationen zur gesamten Infrastruktur verfügbar sind, z. B. zum Zuweisen von Ermittlungsmethoden für primäre Standortserver oder zum Verwalten von Administratorzugriffsrollen für die SCCM-Hierarchie.

Der CAS-Server unterstützt bis zu 100.000 Clients in der SCCM-Infrastruktur, wenn der SQL-Server über eine Enterprise- oder Datencenter-Edition verfügt, und bis zu 50.000 Clients, wenn der SQL-Server über eine Standard-Edition verfügt.

1.2. Primärer Standort
Es können nicht mehr als 25 primäre Standortserver mit dem CAS-Server verbunden werden. Der primäre Standortserver ist für die Interaktion mit Clients und sekundären Standortservern verantwortlich, konsolidiert die empfangenen Daten und sendet sie an den CAS-Server.

Der primäre Standortserver unterstützt bis zu 10 Clientverwaltungspunkte, von denen jeder bis zu 25.000 Clients unterstützt.
Ein primärer Standortserver kann nur Clients verwalten, die direkt mit diesem Server verbunden sind, oder Clients, die mit seinen untergeordneten Servern verbunden sind.
Der primäre Standortserver unterstützt bis zu 250 sekundäre Standortserver und 250 Verteilungspunkte. Der primäre Standortserver kann Daten nach einem Zeitplan an den sekundären Standortserver und an Verteilungspunkte übertragen und / oder die von ihm verwendete Kanalbandbreite begrenzen.

Der primäre Standortserver unterstützt bis zu 50.000 Clients, wenn er zusammen mit dem SQL-Server vorhanden ist, und bis zu 100.000 Clients, wenn der SQL-Server separat vom primären Standortserver vorhanden ist. Die Edition des SQL-Servers ist im Gegensatz zum CAS-Server nicht wichtig. Darüber hinaus erhöhen Secondary Site-Server nicht die Anzahl der Clients, die mit dem Primary Site-Server verbunden sind. Wenn auf dem CAS-Server eine Datenbank auf dem SQL-Server der Standardversion installiert ist, ist die Anzahl der Clients, die mit dem primären Standortserver und seinen untergeordneten Servern verbunden sind, auf 50000 begrenzt. Der
primäre Standortserver darf keine untergeordneten primären Standortserver enthalten.

1.3. Sekundärstandort und Verteilungspunkt
Die Migration der Secondary Site-Server erfolgt wie folgt: Beim Entfernen des ursprünglichen Secondary Site-Servers wird auf den nächsten Zyklus der Informationserfassung gewartet. Wenn das erfolgreiche Entfernen des Secondary Site-Servers nach dem Sammeln der Informationen bestätigt wird, wird der Verteilungspunkt installiert und alle Daten, die sich auf dem ursprünglichen Secondary Site-Server befanden, werden in diesen Server importiert.

Für die Migration von Distribution Point ist es erforderlich, dass das von SCCM 2012 unterstützte Betriebssystem auf dem Server installiert ist und der freie Speicherplatz doppelt so groß ist wie alle Pakete auf dem Distribution Point.

Wenn Sie den Verteilungspunkt und den sekundären Standortserver verwenden, können Sie die SCCM-Infrastruktur nicht verwalten. Alle Verwaltungsaktionen müssen auf dem CAS- und dem primären Standortserver ausgeführt werden. Die Hauptaufgabe von Verteilungspunkten und sekundären Standortservern besteht darin, den Datenverkehr im Netzwerk zu reduzieren und Daten von Clients für die Übertragung an den übergeordneten primären Standortserver zu konsolidieren.
Der sekundäre Standortserver kann nicht zum Zuweisen von SCCM-Standortcode an Clients verwendet werden. Wenn zum Zuweisen von Standorten zu Clients Grenzgruppen verwendet werden und dem Client ein sekundärer Standortcode zugewiesen wird, wird dem Client der Code des übergeordneten Standorts dieses sekundären Standortservers zugewiesen.

Der sekundäre Standortserver unterstützt bis zu 250 Verteilungspunkte. Der Verteilungspunkt unterstützt bis zu 4000 Kunden.
Der sekundäre Standortserver unterstützt bis zu 5000 Clients.

2. Die Möglichkeit, verschiedene Arten von Objekten zu migrieren
Bild

Leider habe ich nicht verstanden, wie man eine Platte einfügt, also das Bild.
Sammlungsmigration - Beim Durchführen einer Sammlungsmigration werden alle Objekte automatisch migriert (diese Funktion kann beim Erstellen eines „Migrationsjobs“ deaktiviert werden), die dieser Sammlung zugeordnet sind (mit Ausnahme der Objekte, die nicht migriert werden können). Die Umlagerung von Sammlungen ist identisch mit dem Original.
Migration von Objekten - Bei der Migration von Objekten müssen Sie alle Objekte auswählen, die an der Migration teilnehmen sollen.

Es gibt jedoch einige Einschränkungen. Sammlungen sollten nur Benutzer oder nur Computer enthalten. Leere Sammlungen können nicht migriert werden und stattdessen wird ein Ordner erstellt. Wenn Bereitstellungen vorhanden sind, die alle Untersammlungen enthalten, die auf eine leere Sammlung während der Migration abzielen, wird eine neue Sammlung erstellt, die alle Untersammlungen und Bereitstellungen enthält, die auf sie abzielen. Sammlungen, die ein unbekanntes Computerobjekt enthalten, werden migriert, dieses Element wird jedoch aus der Sammlung entfernt. Die Migration verknüpfter Sammlungen wird nicht unterstützt (verknüpfte Sammlungen - Sammlungen, die Benutzer und Computer enthalten).
Die folgenden Objekte und Daten können nicht migriert werden: Abfragen, Berichte, Kundeninventardaten, Intel AMT-Daten, geänderte Startabbilder, SCCM 2007-Agent-Cache-Daten, Client-Verlauf, Sicherheitseinstellungen, mof-Dateien.

Die Berichtsmigration ist mit SCCM nicht möglich. Sie können jedoch das Dienstprogramm SQL Server Reporting Services-Berichts-Generator verwenden, um Berichte zu migrieren. Dazu müssen Sie alle Berichte in der Quellinfrastruktur so konvertieren, dass sie SQL-Mechanismen verwenden. Dazu müssen Sie die SQL Server Reporting Services-Rolle in den Datenbanken installieren und dann den Zugriff der ursprünglichen SCCM-Hierarchie auf diesen Dienst konfigurieren (über die SCCM-Konsole, Serververwaltung, Rollenverwaltung), alle Berichte in SQL-Berichte konvertieren (über die SCCM-Konsole, die erforderlichen Berichte auswählen und Klicken Sie auf "Berichte in Reporting Services kopieren". Darüber hinaus werden Berichte mit dem SQL Server Reporting Services-Berichts-Generator oder dem ReportSync-Dienstprogramm migriert.

Миграция запросов невозможна средствами SCCM. Необходимо пересоздавать запросы или экспортировать запросы в виде «mof» файлов из иерархии SCCM 2007и импортировать их в SCCM 2012, это осуществляется средствами консоли SCCM исходной и целевой иерархий.

Миграция mof файлов невозможна средствами SCCM. Необходимо заново настраивать их в новой иерархии. Механизм взаимодействия с mof файлами не изменился, однако могут потребоваться изменения в существующих mof файлах для полной cовместимости с SCCM 2012.

3. Требования к SQL серверу
Для всех ролей серверов должны использоваться 64 битные редакции SQL сервера и аутентификация windows для доступа к базе данных.

Die SQL Server-Replikationskomponente wird nicht zum Replizieren von Daten zwischen SCCM-Servern verwendet. Dieser Vorgang erfolgt durch den SMS-Provider. Wenn Sie Berichte generieren und anzeigen müssen, müssen Sie die SQL Server Reporting Services-Komponente auf dem SQL Server installieren.

Für jeden SCCM-Server muss eine separate Instanz des SQL-Servers verwendet werden, und der Collation-Parameter des SQL-Servers muss auf allen Servern in der SCCM-Hierarchie identisch sein. Die einzige unterstützte Sortierung ist SQL_Latin1_general_CP1_CI_AS.

Für den ordnungsgemäßen Betrieb des SCCM 2012-Hierarchie-Servers muss der SQL Server die Windows-Authentifizierung unterstützen. Da der gemischte Modus die Windows-Authentifizierung unterstützt, ist die Verwendung auf SQL-Servern der SCCM-Hierarchie möglich. So ist es möglich, gemischte oder Windows-Authentifizierung, "Best Practice" - Windows-Modus zu verwenden.

Sie müssen die folgenden SQL Server-Speicherverbrauchseinstellungen verwenden:
- Wenn die SQL-Installation und der SCCM-Server gleichzeitig vorhanden sind, begrenzen Sie den SQL Server-Speicherverbrauch auf 50-80% des Server-RAM.
- Begrenzen Sie bei einer getrennten Installation von SQL und SCCM-Server den Speicherverbrauch des SQL-Servers auf 80-90% des Arbeitsspeichers des Servers.
- Für den primären Standortserver und den CAS-Server ist eine Sicherung von 8 GB RAM auf dem SQL-Server und für den sekundären Standortserver eine Sicherung von 4 GB SQL-Server-RAM erforderlich.

4.
Anforderungen an die Netzwerkinfrastruktur gallery.technet.microsoft.com/SCCM-2012-R2-Network-scheme-b01fd985 Bei
diesem Schema ohne CAS-Rolle wurde kein anderes Schema gefunden. Aber ich denke, 99% derjenigen, die dies lesen, werden es tun.

5. Vorbereiten der Migration
Da sich die SCCM 2012-Hierarchie von der SCCM 2007-Hierarchie unterscheidet, muss die vorhandene SCCM 2007-Struktur neu organisiert und flacher gestaltet werden. Für die Migration benötigen Sie ein Konto mit Lesezugriff auf alle Objekte der SCCM 2007-Hierarchie und ein Konto mit Lese- und Schreibrechten für die Datenbank. Außerdem müssen Sie die folgenden Ports öffnen: 135, 445, 1433 (alle TCP).

Um SCCM 2007 auf SCCM 2012 zu migrieren, müssen Sie den Quellserver in der 2007-Infrastruktur auswählen. Dieser muss der „höchste“ Server der vorhandenen Hierarchie sein, da Sie nach Auswahl des Quellservers nicht alle Objekte, Server und Clients migrieren können, die sich „über“ dem ausgewählten Server befinden.

Da SCCM 2012 die Erstellung von untergeordneten primären Standortservern aus primären Standortservern nicht unterstützt, ist es unmöglich, eine solche Hierarchie zu migrieren. Daher müssen alle Clients aller untergeordneten primären Standortserver in der vorhandenen Hierarchie in den entsprechenden übergeordneten primären Standortservern in der neuen Hierarchie konsolidiert werden. Die Konsolidierung von Clients erfolgt während der "Migration" des Clients. Vor der direkten Migration werden Clients von der SCCM 2007-Hierarchie verwaltet. Bei der Migration eines Clients sollte dieser bei der Installation des Clients den Code seines übergeordneten Standorts SCCM 2012 erhalten (über die Befehlszeilentaste). Wenn Sie Clients die entsprechenden Standortcodes ihrer übergeordneten primären Standortserver zuweisen, erfolgt die Konsolidierung.

Alle Server in der Hierarchie, die an der Migration teilnehmen, müssen auf SCCM 2007 SP2 oder höher aktualisiert werden.
Sekundärserver können nicht migriert werden. Sie müssen den Server aus der SCCM 2012-Infrastruktur entfernen und den Sekundärserver darauf installieren (möglicherweise zusammen mit dem Speichern von Daten auf dem Verteilungspunkt).

Für eine unterbrechungsfreie Dienstbereitstellung können SCCM-Infrastrukturen vorhandene Verteilungspunkte gemeinsam nutzen. Die gemeinsame Nutzung vorhandener Verteilungspunkte wird in der Anfangsphase der Migration eingerichtet. Hierzu ist ein Konto mit den Rechten zum Ändern des SCCM-Objekts erforderlich.
Um SCCM-Objekte zu migrieren, müssen Sie Öffentliche Ordner für die Migration vorbereiten. Diese Ordner ermöglichen den Zugriff auf Öffentliche Ordner für Konten, die in der neuen Hierarchie für den Zugriff auf Öffentliche Ordner verantwortlich sind. Außerdem müssen Sie SCCM-Objekte neu konfigurieren, damit sie den UNC-Pfad zum freigegebenen Ordner verwenden. Auf diese Weise können Sie die Objekte nach der Migration nicht neu konfigurieren.

Sammlungen können nicht gemischt werden, sie können nicht gleichzeitig Computer und Benutzer enthalten. Alle gemischten Sammlungen müssen in Sammlungen reorganisiert werden, die nur Benutzer und nur Geräte enthalten. Darüber hinaus können Sammlungen mit gemischten Sammlungen und Sammlungen mit unbekannten Computern nicht migriert werden. Leere Sammlungen werden als Ordner migriert.

Um Berichte zu migrieren, müssen Sie die SQL Server Reporting Services-Rolle (SRS) installieren und alle Berichte in das SRS-Format konvertieren. Eine Berichtsmigration mit SCCM ist nicht möglich, jedoch mit SQL.
Durch die Clientmigration wird die Neuverteilung von Paketen vermieden. Dies liegt daran, dass SCCM 2012 beim Migrieren von Paketen Informationen zur Paketnummer von SCCM 2007 in der Datenbank speichert und der Client wiederum Daten zu installierten Paketen während der Migration speichert.
Um Clients zu migrieren, müssen Sie Pakete für die Installation von SCCM 2012-Clients in der SCCM 2007-Hierarchie erstellen und verteilen. Außerdem können Sie SCCM 2012-Clients auf jede mögliche Weise verteilen, da eine Clientmigration bei einem direkten Upgrade nicht möglich ist.

6. Vorbereiten des Zielsystems für die Migration
Die Zielhierarchie sollte von oben nach unten bereitgestellt werden: Der zentrale Standort sollte zuerst bereitgestellt werden, nachdem die untergeordneten Standorte bereitgestellt wurden, und anschließend sollten die Server und Verteilungspunkte der unteren Ebene bereitgestellt werden. Wenn es an einigen Standorten nicht möglich ist, den Server über eine neue Hierarchie bereitzustellen, müssen Sie die Gelegenheit nutzen, einen Verteilungspunkt für Inhalte auf dem Clientsystem zu erstellen.

Es ist möglich, Inhalte nach einem benutzerdefinierten Zeitplan zu übertragen, das heißt, ohne den Kanal während der Geschäftszeiten zu laden oder die „Prestage-Inhaltsdatei“ zu verwenden und sie offline auf die Site zu übertragen. Die „Prestage-Inhaltsdatei“ wird an der zentralen Stelle der Hierarchie erstellt und enthält alle erforderlichen Pakete.

Nach dem Erweitern der Hierarchie ist ein Test erforderlich. Überprüfen Sie die Datenreplikation zwischen Standorten in der Hierarchie und den Zustand der Clientverwaltungspunkte und Inhaltsverteilungspunkte. Überprüfen Sie die Fähigkeit, Clients mit jedem Clientverwaltungspunkt in der Hierarchie zu verbinden, und die Fähigkeit, Kundendaten zu senden und zu empfangen. Überprüfen Sie den Zustand der Bereitstellungen und aller Datenverteilungspunkte in der Hierarchie.

Der nächste Schritt bei der Vorbereitung der Zielinfrastruktur sollten die Einstellungen "Standardclienteinstellungen", "Grenze", "Grenzgruppe", "Sicherheitsbereich" und "Administratorkonten" sein. Darüber hinaus müssen Sie zwei Konten erstellen, um auf die alte Hierarchie und auf die Datenbank der alten Hierarchie zuzugreifen (möglicherweise müssen Sie weitere Konten erstellen, wenn Sie keine Verbindung mit denselben Anmeldeinformationen herstellen können, um auf verschiedene Hierarchie-Sites und verschiedene Datenbankserver zuzugreifen). "Sicherheitsbereich" und "Grenzgruppe" werden benötigt, um die Rechte zum Verwalten von Inhalten neu zuzuweisen und den Speicherort von Inhalten in der neuen Hierarchie anzugeben.

Zu Beginn des Prozesses gibt das neue System die Adressen der SCCM 2007-Server und die Anmeldeinformationen für den Zugriff auf diese Server an. Dabei wird vom höchsten zum niedrigsten Server in der Hierarchie gerechnet. Alle Server, die an der Migration teilnehmen, werden angegeben. Anschließend wird ausgewählt, welche Daten vom alten zum neuen System übertragen werden sollen.
Tatsächlich ist die Migration eine Kopie von Objekten von der Quellhierarchie zum Ziel. Objekte werden mithilfe von „Migrationsjobs“ migriert. Jeder „Migrationsjob“ kann beliebig viele SCCM-Objekte migrieren. Sie können SCCM-Objekte bei Bedarf erneut migrieren (z. B. wurde das Objekt geändert). Die Reihenfolge, in der Objekte migriert werden, ist nicht wichtig. Rollen oder primäre SCMM-Standortserver können nicht migriert werden (Inhaltsverteilungspunkte und sekundäre Standortserver können migriert werden).

Um Objekte aus der Quellhierarchie in das Ziel zu kopieren, müssen Daten zur Quellhierarchie erfasst werden. Beim Sammeln von Daten wird eine Beziehung zwischen Hierarchien hergestellt. Daten werden erfasst, indem Informationen zu Objekten und ihren Abhängigkeiten, Sammlungen, Standorten und Clients aus der Datenbank der Zielhierarchie gelesen werden.

Zum Migrieren von Clients müssen Sie die Quellhierarchiekonsole oder eine andere Methode verwenden, da Clients durch direkte Clientaktualisierungen migriert werden. Die Mechanismen für die Installation des Agenten auf dem Clientcomputer wurden in SCCM 2012 nicht geändert. Die Aktualisierung kann durch ein Startskript, eine Gruppenrichtlinie oder als Paket vom Server in der Quellhierarchie initiiert werden. Bevor der Client migriert wird, wird er von der ursprünglichen Hierarchie verwaltet.

Der SCCM 2007-Client kann nicht von der SCCM 2012-Hierarchie gesteuert werden, und umgekehrt, der SCCM 2012-Client kann nicht von der SCCM 2007-Hierarchie gesteuert werden bis sie den richtigen Standortcode zugewiesen bekommen. Vor Beginn der Migration werden alle Clients von der SCCM 2007-Hierarchie verwaltet und bei der Migration an SCCM 2012 übertragen.

Nachdem die Migration von Clients und Objekten abgeschlossen ist, können Sie mit der Migration von Inhaltsverteilungspunkten fortfahren. Dies geschieht über die CAS-Konsole des Zielhierarchieservers (Task "Verteilungspunkt migrieren"). Wenn Sie einen Inhaltsverteilungspunkt migrieren, werden Binärdateien aktualisiert und der Dateispeicher wird migriert. Für die Migration des Speichers ist es erforderlich, dass der Server über den 2 bis 2,5-fachen freien Speicherplatz verfügt, der von allen SCCM 2007-Paketen auf diesem Server belegt wird, da der SCCM-Paketspeicher neu erstellt wird.
Die Migration von Secondary Site-Servern ist nicht möglich. Stattdessen erfolgt ein "In-Place" -Upgrade des Secondary Site-Servers nur bis zur Verteilung des Inhalts der Zielhierarchie (dies ist eine technische Einschränkung des von Microsoft eingeführten Systems in Verbindung mit Änderungen der Mechanismen der Paketreplikation in der Hierarchie und Verbesserungen der Mechanismen zur Steuerung des Paketreplikationsverkehrs), wobei alle erhalten bleiben Pakete. Für die Migration des Speichers ist es erforderlich, dass der Server über den 2 bis 2,5-fachen freien Speicherplatz verfügt, der von allen SCCM 2007-Paketen auf diesem Server belegt wird, da der SCCM-Paketspeicher neu erstellt wird.

Die Migration von primären Standortservern ist nicht möglich. Statt der Migration von primären Standortservern werden Objekte vom primären Standortserver der alten Hierarchie auf den CAS (oder den entsprechenden primären Standortserver) der neuen Hierarchie migriert. Daher müssen Sie für die "Migration" des primären Standortservers über die Ziel-SCCM-2012-Infrastruktur und einen Speicherort für Pakete verfügen, der dem auf dem Quellenserver belegten Speicherplatz entspricht. Obwohl der CAS-Server keine Clients bedienen und kein Verteilungspunkt für Inhalte sein kann, muss er darauf verfügbar sein, um alle Hierarchiepakete zu speichern.

Nützliche Dienstprogramme:

ReportSync - Dienstprogramm zum Migrieren von Berichten von der SCCM 2007-Hierarchie in die SCCM 2012-Hierarchie, das im Internet heruntergeladen werden kann.
RegKeytoMof - Dienstprogramm zum Erstellen von Mof-Dateien für das Inventar von nicht standardmäßigen Registrierungseinstellungen. Im Internet zum Download verfügbar.
ExtractContent - Dienstprogramm zum Entpacken des Inhalts der "Prestage Content" -Datei. Es ist im
Lieferumfang von SCCM 2012 enthalten und befindet sich im Ordner „BIN“ des SCCM CMTrace- Distributionskits - einem Dienstprogramm zum Anzeigen von Protokollen. Es ist im Lieferumfang von SCCM 2012 enthalten und befindet sich im Ordner Tools der SCCM-Distribution.
Notepad - ein Dienstprogramm zum Anzeigen von Protokollen.

7. Ungefähre Migration
Die Migration erfolgt stufenweise. Sie können erst mit der nächsten Migrationsstufe fortfahren, nachdem die vorherige Stufe vollständig abgeschlossen wurde. Bei einem Ausfall der Zielhierarchie ist eine problemlose Rückkehr der IT-Infrastruktur zur ursprünglichen Hierarchie möglich, da die Migration keine Änderungen mit sich bringt, die das Funktionieren der ursprünglichen Hierarchie beeinträchtigen (vor der Clientmigrationsphase).

Der erste Schritt bei der Migration besteht darin, die SCCM-Zielhierarchie parallel zur vorhandenen Hierarchie zu erstellen.
Der zweite Schritt besteht darin, die Hierarchien vorzubereiten und Informationen über die ursprüngliche Hierarchie zu sammeln.
In der dritten Stufe werden die SCCM-Objekte migriert.
Der vierte Schritt ist die Migration von SCCM-Clients.
Der fünfte Schritt ist das Testen der Zielhierarchie und das Außerbetriebsetzen der ursprünglichen Hierarchie.

7.1. Bereitstellen von SCCM 2012-Hierarchien
1. Vorbereiten einer Hardwareplattform für die Installation von Hierarchie-Servern.
2. Installieren Sie das Betriebssystem und die Updates oder stellen Sie sie bereit.
3. Installieren des Datenbankservers.
4. Installieren Sie die Software, die für die volle Funktionsfähigkeit des CAS-Servers erforderlich ist.
5. Installieren des CAS-Servers.
Während des Installationsvorgangs müssen Sie die Sprachen angeben, die von der SCCM-Hierarchie unterstützt werden sollen. Der Datenbankserver (das Konto, in dessen Namen der CAS-Server installiert wird, muss über die entsprechenden Zugriffsrechte für den Datenbankserver verfügen. Außerdem muss der Zugriff auf dem Datenbankserver aktiviert sein TCI \ IP) müssen Sie den Standortcode des CAS-Servers angeben. Sie können eine beliebige Distribution verwenden, da die Möglichkeit besteht, nach der Installation des Servers eine Lizenz einzugeben.
6. Überprüfen des Zustands des CAS-Servers: Überprüfen Sie den Zustand der CAS-Serverkomponenten (Bereich Überwachung, Registerkarten Standortstatus und Komponentenstatus) und den Zustand der Konsole.
7. Vorbereiten des zweiten Servers für die Installation des ersten primären Standortservers (Wiederholen der Schritte 2 bis 4).
8. Installieren des primären Standortservers.
Während des Installationsvorgangs müssen Sie den Datenbankserver (das Konto, in dessen Namen der Server installiert wird, muss über die entsprechenden Zugriffsrechte für den Datenbankserver verfügen, außerdem muss der TCI \ IP-Zugriff auf dem Datenbankserver aktiviert sein), den Standortcode und den Server angeben. Dies ist der übergeordnete Server dieses primären Standorts, dh der CAS-Server der neuen Hierarchie. Für die Installation des primären Standortservers wird dasselbe Distributionskit verwendet wie für die Installation des CAS-Servers.
9. Überprüfen des Zustands des primären Standortservers: Überprüfen Sie den Zustand der primären Standortserverkomponenten (Überwachungsbereich, Registerkarten "Standortstatus" und "Komponentenstatus"), überprüfen Sie den Zustand der Konsole und überprüfen Sie die Datenreplikation zwischen diesem Server und dem CAS-Server (replmgr.log, rcmctrl). Überprüfen Sie im Bereich "Protokoll" oder "Überwachung" auf der Registerkarte "Standortstatus" und "Komponentenstatus" den Zustand der Client-Verwaltungspunkte und Inhaltsverteilungspunkte ("mpmsi.log", "mpsetup.log", "smsdpmon.log", "Standortstatus" und "Komponentenstatus") »), Überprüfen Sie die Fähigkeit, Clients mit jedem Client-Verwaltungspunkt in der Hierarchie zu verbinden , die Fähigkeit, Kundendaten zu senden und zu empfangen.
10. Installation aller anderen primären Standortserver in der Hierarchie (Wiederholen der Schritte 8 und 9).
11. Überprüfen des Zustands der SCCM 2012-Hierarchie: Überprüfen Sie zusätzlich den Zustand der Komponenten aller Server in der Hierarchie (Bereich Überwachung, Registerkarten Standortstatus und Komponentenstatus) und die Datenreplikation in der Hierarchie (Bereich Überwachung, Registerkarte Standorthierarchie) Überprüfung durch Anzeigen der Protokolldateien auf den einzelnen Servern.
12. Installieren der erforderlichen zusätzlichen Rollen auf dem Hierarchieserver und den Einstellungen (Clienterkennungsmethoden, Clientrichtlinien, Push-Installation von Clients usw.).
13. Einrichten von Benutzerzugriffsrechten für die Hierarchie und Einrichten von "Sicherheitsbereichen".

7.2. Hierarchien vorbereiten und Daten sammeln
1. Vorbereiten der Quellhierarchie für die Migration. Die Sammlungen und Objekte werden mithilfe der SCCM 2007-Konsole für die Migration vorbereitet. Die Objekte, die zu den Standorten in der Quellhierarchie gehören, spielen keine Rolle, da sie bei der Migration von Objekten einen beliebigen Standort in der Zielhierarchie als übergeordneten Standort angeben können. Daher können Objekte von jeder Site zu jeder migriert werden. Es ist jedoch erforderlich, alle Sites mit eindeutigem Inhalt zu verbinden.
2. Um Daten aus der Quellhierarchie in das Ziel zu migrieren, müssen Sie die Beziehung zwischen Hierarchien konfigurieren. Sie müssen an der obersten Stelle der Hierarchie beginnen.
3. Anschließend müssen Sie den primären Standort mit eindeutigem Inhalt mit der SCCM 2012-Hierarchie verbinden Beide Aktionen werden über die SCCM 2012-Konsole ausgeführt (Registerkarte Migration, Registerkarten Verwaltung). Wählen Sie dazu den Punkt „Quellhierarchie festlegen“ und geben Sie die notwendigen Daten für die Verbindung ein. SCCM 2007-Hierarchiestandorte sind mit einem zentralen Standort verbunden.
4. Die Freigabe von Inhaltsverteilungspunkten wird über das Element "Verteilungspunkte freigeben" (Registerkarte "Migration", Registerkarten "Verwaltung") aktiviert. Das Teilen von Inhaltsverteilungspunkten ist nur möglich, nachdem Informationen über sie gesammelt wurden. Dieser Modus ist für die kontinuierliche Wartung von Clients von Standorten erforderlich, an denen kein sekundärer Standortserver oder Verteilungspunkt für Clients der Zielhierarchie installiert werden kann. Vor der Bereitstellung dieser Rollen verwenden Clients der alten und der neuen Hierarchie die Verteilungspunkte des Inhalts der alten Hierarchie (einschließlich der Verteilungspunkte des Inhalts auf den Servern des primären Standorts).

7.3. SCCM-Objektmigration
1. Nach Abschluss der ersten Datenerfassung können Sie mit der Migration der Daten von der Quellhierarchie zum Ziel beginnen. Wählen Sie dazu den Punkt „Create Migration Job“ (Registerkarte Migration, Registerkarten Administration). Als Nächstes müssen Sie eine von zwei möglichen Arten von Arbeiten auswählen: "Sammlungsmigration" oder "Objektmigration". Wählen Sie anschließend die erforderlichen Objekte aus, wählen Sie die Uhrzeit aus, weisen Sie den Sicherheitsbereich zu, und wählen Sie die Site aus, auf die der Inhalt migriert werden soll. Sie können SCCM-Objekte erneut migrieren. Wenn das Objekt während der Migration geändert wurde, kann es erneut migriert werden. Die Remigration von Kollektionen erfolgt über den Punkt "Kollektionsmigration".
Werke "Sammlungsmigration" sind für die Migration von Sammlungen (zusammen mit allen Objekten, von denen sie abhängen) vorgesehen, während Werke "Objektmigration" Objekte (zusammen mit allen Objekten, von denen sie abhängen) migrieren. Rollen oder primäre SCMM-Standortserver können nicht migriert werden (Inhaltsverteilungspunkte und sekundäre Standortserver können migriert werden). Somit wird die Auswahl der Objekte für die Migration und die Bereitschaft der Zielhierarchie für den Kundenservice von den Anforderungen der Organisation bestimmt.
2. Für die Migration aller Objekte müssen Migrationsjobs (Punkt 1) konsistent erstellt werden, wenn die vorherigen Migrationsjobs abgeschlossen sind. Sie können den Erfolg von Migrationsvorgängen auf verschiedene Arten überprüfen: Erstellen von Migrationsberichten auf der Registerkarte Berichterstellung im Bereich Überwachung, Registerkarte Migrationsaufträge im Bereich Verwaltung, Anzeigen migrierter Objekte auf der entsprechenden Registerkarte der SCCM-Konsole und Anzeigen der Protokolldatei - migmctrl.log im Protokollordner.
Sie können SQL Server Reporting Services zum Migrieren von Berichten verwenden. Dazu müssen Sie alle Berichte in der Quellinfrastruktur so konvertieren, dass sie SQL-Mechanismen verwenden. Dazu müssen Sie die SQL Server Reporting Services-Rolle in den Datenbanken installieren und dann den Zugriff der ursprünglichen SCCM-Hierarchie auf diesen Dienst konfigurieren (über die SCCM-Konsole, Serververwaltung, Rollenverwaltung), alle Berichte in SQL-Berichte konvertieren (über die SCCM-Konsole, die erforderlichen Berichte auswählen und Klicken Sie auf "Berichte in Reporting Services kopieren". Darüber hinaus werden Berichte mit dem SQL Server Reporting Services-Berichts-Generator oder dem ReportSync-Dienstprogramm migriert.
Um sms_def.mof-Dateien zu "migrieren", müssen Sie sie erneut in SCCM 2012 importieren oder einfach die WMI eines beliebigen Clientcomputers mit den erforderlichen Klassen abfragen und über die SCCM 2012-Konsole zum Inventar hinzufügen Richtlinie für Client-Computer (keine Benutzer), Abschnitt „Hardwareinventur“, Punkt „Klassen festlegen“. Die Schaltfläche Importieren oder Abrufen des Clientcomputers und Hinzufügen von WMI-Klassen.
3. Nach Abschluss der Migration aller Objekte müssen der Erfolg der Replikation und das Vorhandensein aller SCCM-Objekte auf allen Servern in der Hierarchie mithilfe der SCCM 2012-Konsole überprüft werden.
4. Sie müssen die Grenzgruppe für die Verteilung von Inhalten konfigurieren. Nach der Migration aller Grenzgruppen müssen Sie das Element Grenzgruppen verwenden (Registerkarte Hierarchiekonfiguration, Registerkarten Verwaltung).
5. Erstellen einer "Prestage Content" -Datei zur weiteren Verteilung durch Mechanismen von Drittanbietern (nicht SCCM-Mechanismen). Um diese Datei zu erstellen, gehen Sie zur Registerkarte "Software Library" und wählen Sie die erforderlichen Pakete aus. Verwenden Sie dann den Befehl "Create Prestage Content File".
6. Stellen Sie die Datei "Prestage Content" mithilfe des Dienstprogramms "extractcontent" mit dem Schalter "/ p" auf den Inhaltsverteilungszielpunkten bereit.

7.4. SCCM-Client-Migration
1. Es wird empfohlen, vor der Installation der SCCM 2012-Agenten die Software zu installieren, die erforderlich ist, damit der SCCM 2012-Client auf den Clientcomputern ausgeführt werden kann. Dieser Schritt ist optional, aber wünschenswert, da er die Installationszeit des SCCM 2012-Clients und die Anzahl der Installationsfehler verringert. Vor der Clientmigration werden sie von den Servern in der Quellhierarchie bereitgestellt.
2. Da bei der Client-Migration der Agent tatsächlich neu installiert wird, kann der SCCM-Agent auf jede Art und Weise installiert werden. Die Client-Installationsmethoden wurden in der neuen Version von SCCM nicht geändert.
Die Migration von Clients muss in Schritten von jeweils 500 bis 1000 Clients durchgeführt werden, um die Netzwerkinfrastruktur und den Datenbankserver zu entlasten. Bei der Migration müssen Sie Kunden konsolidieren. Zielhierarchieclients können zu einem der primären Standortserver gehören. Alle Clients vom entsprechenden Primärstandortserver der Hierarchie der zweiten Ebene der Quellhierarchie und von allen zugehörigen Tochterstandorten werden auf jeden Primärstandortserver migriert.
Um ein Agenteninstallationspaket für eine neue Hierarchie in der Quellhierarchie zu erstellen, müssen Sie den Inhalt des Agenteninstallationspakets aus der neuen Hierarchie kopieren. Die Installation des Agenten muss mit dem Schlüssel SMSSITECODE = XXX durchgeführt werden, wobei XXX der Code des übergeordneten primären Standortservers für diesen Client ist. Dies ist erforderlich, um den Client an die Hierarchie zu binden.
Wenn die Installation des SCCM 2012-Agenten nicht abgeschlossen wurde, müssen Sie das Protokoll ccmsetup.log auf dem Clientcomputer auf Fehler überprüfen. Wenn dieses Protokoll nicht auf dem Computer gefunden wird, müssen Sie versuchen, den Agenten erneut zu installieren, da der erste Versuch, den Agenten zu installieren, nicht durchgeführt wurde (der Computer wurde möglicherweise ausgeschaltet).

7.5. Testen der Zielhierarchie und Außerbetriebnahme der ursprünglichen Hierarchie
1. Inhaltsverteilungspunkte werden nach Abschluss der Clientmigration migriert. Verwenden Sie zum Migrieren von Inhaltsverteilungspunkten das Element "Upgrade Distribution Point" (Registerkarte "Migration", Registerkarten "Administration").
Wenn keine Migration möglich ist (z. B. kein Platz auf dem Server), müssen Sie die vorhandene SCCM-Rolle der Quellhierarchie löschen und die SCCM-Rolle der Zielhierarchie festlegen. Um die Netzwerklast zu verringern, können Sie die Datei "Prestage Content" verwenden.
Sie müssen den SCCM 2007-Agenten vor der Migration von diesem Verteilungspunkt entfernen.
2. Entfernen Sie die vorhandenen SCCM 2007-Hierarchie-Primärstandort-Server und installieren Sie die entsprechenden Rollen (Verteilungspunkt, Sekundärstandort-Server) der neuen Hierarchie. Dies erfolgt mithilfe des Elements "Standortsystemserver erstellen" für Inhaltsverteilungspunkte und "Sekundären Standort erstellen" für sekundäre Standortserver.
3. Testen der Zielhierarchie: Überprüfen Sie die Datenreplikation zwischen Standorten in der Hierarchie, den Zustand von Clientverwaltungspunkten und Inhaltsverteilungspunkten, die Fähigkeit von Clients, eine Verbindung zu jedem Clientverwaltungspunkt in der Hierarchie herzustellen, und die Fähigkeit, Kundendaten zu senden und zu empfangen. Überprüfen Sie den Zustand der Bereitstellungen und aller Datenverteilungspunkte in der Hierarchie.
4. Außerbetriebnahme der ursprünglichen Hierarchie.

Links :
Administratorchecklisten für die Migrationsplanung in System Center 2012 Configuration Manager
Einführung in die Migration in System Center 2012 Configuration Manager
Installieren von Standorten und Erstellen einer Hierarchie für Configuration Manager
Planen von Configuration Manager-Standorten und -Hierarchie
Supported Configurations for Configuration Manager
System Center 2012 – Configuration Manager Component Add-ons and Extensions (Tools)
Migrating from Configuration Manager 2007 to Microsoft System Center 2012 R2 Configuration Manager (Лаба)
ConfigMgr client automatic site assignment behavior in a multi site environment
Performing a side-by-side Migration from Configuration Manager 2007 (WindowsNoob)
System Center 2012 Configuration Manager Migration — Deep(ish) Dive Part 1 (troubleshooting)
System Center 2012 Configuration Manager Survival Guide

Дельные посты:
www.css-security.com/blog/sccm-2012-migration-made-easy-part-1
www.css-security.com/blog/sccm-2012-migration-made-easy-part-2
www.css-security.com/blog/sccm-2012-migration-made-easy-part-3
anoopcnair.com/2015/08/20/upgrade-from-sccm-2007-to-sccm-2012-with-adaptiva -onesite
activedirectory.ncsu.edu/services/sccm

Jetzt auch beliebt: