Endlich ist es so weit! Die Beta 2 von ConfigMgr 2012 (aka “v.Next”) kann
heruntergeladen werden: http://technet.microsoft.com/en-us/evalcenter/ff657840.aspx

Heute wurde auf der TechEd 2010 in Berlin der offizielle Name von ConfigMgr v.Next eher beiläufig erwähnt bzw tauchte dieser dann auf einer Folie auf: ConfigMgr 2012.

Wer sich gerne die Beta1 von ConfigMgr v.Next anschauen möchte, aber keine Lust Zeit hat, die Installation selbst durchzuführen, der kann sich unter http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1b23c540-9b9f-4d41-a05d-d4b216061957 eine fertige vhd herunterladen.

Trace32 aus dem System Center Configuration Manager 2007 Toolkit V2 versagt bei fast allen v.Next-Logfiles. Abhilfe schafft “System Center Trace (64-bit)”, welches unter \Tools auf der v.Next-Beta1-DVD zu finden ist (aber trotzdem noch trace32.exe heisst).

Über “Client Health” (“Wie steht es um die ‘Gesundheit’ meiner SCCM-Clients?”) macht sich ja jeder ConfigMgr-Administrator Gedanken. Prinzipiell geht es dabei darum, fehlerhafte oder nicht mehr funktionsfähige Clients zu erkennen, um dann entsprechende Maßnahmen ergreifen zu können. Gründe für den Ausfall auf Client-Seite gibt es ja sehr viele. Ein Spitzenreiter dabei ist meines Erachtens z.B. eine fehlerhafte WMI. Genauso aber kann die Startart “manual” des ccmexec (“SMS Agent Host”) oder BITS-Services dafür sorgen, dass Softwareverteilung und Hardware-Inventur nicht mehr funktionieren.
Bei v.Next gibt es schon einige vordefinierte Checks, die genau diese “verwundbaren Punkte” (siehe CcmEval.xml) überprüfen und sogar ggfs. bereinigend eingreifen können.

DCM (Desired Configuration Management) spielt unter ConfigMgr ja eher einer untergeordnete Rolle. Andere Features wie Software Updates, Softwareverteilung, Inventur, Remote Control usw. werden meinen Beoabchtungen nach deutlich öfter eingesetzt.
Mit v.Next könnte sich dies eventuell ändern, denn es wird die Funktionalität “DCM-set” eingeführt. Was bedeutet das? Aktuell kann man mit DCM nur bestimmte Einstellungen (lesend) überprüfen. Beispielsweise kann man prüfen, ob ein Registry-Value einem definierten Wert entspricht – oder eben nicht. Es kann z.B. überprüft werden, ob HKLM\Software\mssccmfaq\ConfigMgrIsCool = 1 gesetzt ist. Jeder von 1 abweichende Wert könnte als Error (resp. Warning) reportet werden. Will man nun bei einem abweichenden Wert dafür sorgen, dass dieser korrigiert wird, so muss man etwas umständlich verfahren …

- Erstellung einer Collection, die alle Rechner enthält, bei denen das zu prüfende Configuration Item nicht den Vorgaben entspricht 
- Erstellung eines Skripts, welches den Wert wieder auf den gewünschten Wert setzt
- Erstellung eines Packages/Programs
- Verteilung auf die DPs
- Erstellung eines Advertisements

Durchaus ziemlich langwierig, denn das DCM-CI “weiss” ja eigentlich schon, welchen Wert der Admin erwartet. Schließlich müssen dann die Clients das Advertisement empfangen (-> Verzögerungen durch Collection Update, Policy Polling Interval), die Paketquellen ermitteln, das Skript ausführen und einen weiteren DCM-Scan durchführen, bis wieder alles im “grünen Bereich” ist. Hier können locker mehrere Stunden oder gar Tage vergehen.

Mit v.Next kann man innerhalb eines CIs (Configuration Items) bestimmen, ob man – wie bisher – den Wert nur überwachen (“Monitor only”) oder – falls eine Abweichung vorliegt – auf den zu erwarteten (“Enforce”) setzen will. Sehr praktisch.

Die Überschrift passt aktuell zur Fußball WM 2010, hat damit aber nichts zu tun. Heute kam (bereits zum insgesamt 6. Mal – wie die Zeit doch vergeht) eine Email die mit den Worten “Sehr geehrte(r) Torsten Meringer, herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2010 verleihen zu können!” begann. Ich freue mich natürlich riesig, für ein weiteres Jahr Teil der Community zu sein!

Bei ConfigMgr 2007 sind die Einstellungen der Client Agents noch etwas “verstreut” in der Admin Konsole untergebracht. Die Einstellungen sind so leider nicht auf einen Blick zu sehen:

Bei v.Next werden die Einstellungen unter den “Default Settings” zusammengefasst, was die Übersichtlichkeit deutlich erhöht:

Außerdem können neben diesen “Default Settings” auch noch “Custom Settings” erstellt und einer Collection zugeordnet werden:

Einen entfernt ähnlichen Mechanismus kennt man ja schon von ConfigMgr 2007. Hier ist es möglich, einer Collection einige wenige Einstellungen zuzuordnen (z.B. das “Policy Polling Interval” oder den “Restart Countdown”).
v.Next geht hier einen Schritt weiter und ermöglicht, dass alle Client Agent Settings unterschiedlichen Collections zugeordnet werden können. Ist es bei ConfigMgr z.B. nur schwer möglich, Software Metering nur für eine bestimmte OU zu aktivieren (während für alle anderen OUs Metering  deaktiviert bleibt), so ist diese Aufgabe mit v.Next sehr einfach umzusetzen.

Endlich! Es ist wieder möglich, Strg + Alt + Entf bei Remote Control zu verwenden.

Mit ConfigMgr 2007 war es ja teilweise etwas schwer (aber nicht unmöglich), ein Berechtigungskonzept zu erstellen, das genau an die Anforderung eines Unternehmens passte.
v.Next geht bei diesem Thema mit Einführung von “RBAC ” (role based access control) einen Schritt weiter. RBAC ist ja z.B. auch schon von Exchange 2010 bekannt.
Das dahinter stehende Prinzip ist recht einfach. Es gibt folgende 3 Objekte:
- Administrative Users
- Security Roles
- Security Scopes

Einem User (Benutzer oder auch Gruppe) kann man eine “Security Role” zuordnen. Hinter dieser Rolle steckt einfach eine Liste an Berechtigungen, ähnlich wie sie schon von ConfigMgr bekannt ist:

In Beta1 sind bereits 13 Rollen vordefiniert, wie z.B. “Application Administrator role”, “Hierarchy Administrator role” oder “Read-only role”.
Hiermit kann man also einfach definieren, wer (Administrative User) was (Security Role) darf. Das Bindeglied (“wo?”) dazwischen sind die “Security Scopes”.