Verwendet man im ConfigMgr die MDT Tasksequenzen zur Verteilung von Betriebssystemen, so verhält man neben den anderen Verbesserungen auch zusätzliche Validierungsschritte.

Diese Schritte sorgen z.B. dafür, dass eine fehlerhaft verteilte Clientinstallation nicht auch die Server betrifft wie es z.B. an der Emory University vor kurzem passiert ist.

Gleichzeitig kann der Fehler ebenfalls auftreten, wenn man ein Server neu installieren will und dabei vergisst, das die Task Sequenz noch auf Clients eingestellt ist.

die Task Sequenz bricht dann sehr schnell mit einem Fehler 9801 ab. Im smsts.log kann man dann folgende Zeilen nachlesen:

Die Rolle PXE ist im SCCM 2012 jetzt Teil des Distribution Points. Dadurch kann man das Bootimage auch nicht mehr an den PXE verteilen. Die Option, welche Images beim PXE zu Verfügung stehen ist daher an einer anderen Stelle zu finden.

Im letzten Teil dieser Serie schauen wir uns den System Center 2012 Virtual Machine Manager (SCVMM) an. Hier gibt es wieder einige ganze Reihe von Verbesserungen. Die Verbesserungen teilen sich in zwei Hauptgebiete auf: Dienste und Cloud-Unterstützung und auf der anderen Seite Fabric Management.

Dienste und Cloud-Unterstützung:

• Service Livecycle Management:

• Dienste in SCVMM werden als Template definiert und darüber auch aktualisiert.

• mit SCVMM 2012 können Serveranwendungen jetzt auch über Server App-V abstrahiert werden

Da ich momentan eine kleine Vortragsreihe zu Neuerungen in System Center 2012 halte, nutze ich die dabei herausgekommene Informationssammlung, um diese auch hier darzustellen:

Vereinfachter Site Aufbau:

• Keine Primary Sites unter Primary Sites mehr möglich
• Central Administration Site: kann genutzt werden, um mehrere Primary Sites zu verwalten
• SCCM ist jetzt komplett Unicode basierend, d.h. Management Konsole kann in mehreren Sprachen genutzt werden, keine ICPs mehr notwendig
• Replikation innerhalb der Hierarchie wird durch SQL Database Replication durchgeführt -> standardisierte Lösung, die schneller und robuster ist, als die alte filebasierte
• Bandbreitenbegrenzung jetzt direkt mit Distribution Points möglich, d.h. keine extra Secondary Sites notwendig
• Kein Mixed oder Native Mode mehr
• Innerhalb einer Site unterschiedliche zentrale Clienteinstellungen möglich

Es gibt in 95% der Fälle keinen Grund mehr für weitere Primäre oder Sekundäre Sites in SCCM

Hier ein kurzer Abriss wie PXE und unknown Computer in SCCM 2007 R2/R3 funktioniert:

1. Client bootet per PXE
2. Client holt sich per Broadcast eine DHCP Adresse vom DHCP Server, steht dieser nicht im gleichen Subnetz, dann muss er per IP Helper Adresse bekannt gemacht worden sein (Achtung: keine Bootoptionen notwendig)
3. Client sendet ein weiteres PXE Broadcast Paket um seinen Installationsserver zu finden (auch hier: IP Helper Eintrag!)
4. Der Dienst WDSServer auf dem SCCM erhält diese Nachricht und leitet sie an den integrierten PXE Filter von SCCM weiter
5. der SCCM Thread wertet die Anfrage aus (Logs zu finden unter SMS_CCM\Logs\smspxe.log, das SMS_CCM Verzeichnis liegt parallel zum “Microsoft Configuration Manager” Verzeichnis)
6. Er überprüft, ob die MAC bzw. GUID des Rechners in der Anfrage in der SCCM Datenbank bekannt ist
7. Falls ja, überprüft er, ob eine Tasksequenze für eine Neuinstallation zugeordnet ist und kein letzte PXE-Boot eingetragen ist (Auf dem Client in der MMC Console einen Rechten Mausklick und “Clear Last PXE Advertisement” auswählen um dieses Flag zu entfernen)
8. Falls nein, überprüft er, ob “Unkown Computer Support” in den Einstellungen aktiv ist (Site Systems\Servername\ConfigMgr PXE Service Point Eigenschaften und “Enable unknown computer support”). Ist dies der Fall sucht er sich die Collections heraus, in denen das “Unknown Computer” Objekt in der entsprechenden Prozessorarchitektur (x64, x86) vorhanden ist. Liegt auf einer eine erzwungene Task Sequence, dann sendet er dem Client das darin hinterlegte Win PE Boot Image und eine normale SCCM OS Installation startet.

Im Rahmen eines aktuellen Projektes darf ich mich ein bisschen mit Enteo beschäftigen. Im Kern basiert Enteo V6 auf WebServices. Das ist leider auch die einzige Schnittstelle, die meines Wissens vom Hersteller für Automatisierungen angeboten wird.

Gerade in einem größeren Rollout Projekt ist Automatisierung überlebenswichtig (bzw. sinnvoll, damit man sich nicht zu sehr bei Drag&Drop langweilt). Zum Glück  hat NWC Services diese Lücke erkannt und als Wrapper um die WebServices ein Powershell Modul erstellt.

Meine Testerfahrungen mit diesem Tool werde ich in diesem Blogeintrag und wahrscheinlich in ein paar weiteren anhand von Beispielen beschreiben.