In Microsoft System Center 2012 Configuration Manager kann die Bereitstellung der gesamten Software überwacht werden, z. B. Softwareupdates, Kompatibilitätseinstellungen, Anwendungen, Tasksequenzen sowie Pakete und Programme. Bereitstellungen können dabei standardmäßig über den Arbeitsbereich Überwachung in der Configuration Manager-Konsole oder über Berichte überwacht werden (basierend auf SQL Reporting Services).

Für Anwendungen in Configuration Manager wird eine zustandsbasierte Überwachung unterstützt, sodass Sie den letzten Anwendungsbereitstellungszustand für Benutzer und Geräte nachverfolgen können.

In diesen Zustandsmeldungen werden Informationen über einzelne Geräte angegeben. Wenn beispielsweise eine Anwendung für eine Sammlung von Benutzern bereitgestellt wird, kann der Kompatibilitätszustand und der Zweck – verfügbar oder erforderlich - der Bereitstellung z.B. in der Configuration Manager-Konsole angezeigt werden.

Für einen Anwendungsbereitstellungszustand wird einer der folgenden Kompatibilitätszustände angezeigt:

• Erfolg: Die Anwendung wurde erfolgreich bereitgestellt oder war bereits installiert.

• In Bearbeitung: Die Anwendungsbereitstellung wird ausgeführt.

• Unbekannt: Der Zustand der Anwendungsbereitstellung konnte nicht ermittelt werden. Dieser Zustand gilt nicht für Bereitstellungen mit dem Zweck Verfügbar. Dieser Zustand wird in der Regel angezeigt, wenn noch keine Zustandsmeldungen vom Client eingegangen sind.

• Anforderungen nicht erfüllt: Die Anwendung wurde nicht bereitgestellt, weil sie mit einer Abhängigkeit oder einer Anforderungsregel nicht kompatibel war oder weil das Zielbetriebssystem für die Bereitstellung ungültig war.

• Fehler: Bei der Bereitstellung der Anwendung ist ein Fehler aufgetreten.

Sofern die Software durch Configuration Manager installiert wird, also insbesondere noch nicht installiert war, kann der Status der eigentlichen Installation noch detaillierter bestimmt werden.

Der Configuration Manager Client schickt den jeweiligen Status dabei über sogenannte Zustandsmeldungen (englisch: State Messages), die standardmäßig gesammelt und alle 15 Minuten verschickt werden (konfigurierbar). Dabei wir jeweils nur der aktuellste Status weitergeleitet, und damit nicht unbedingt jede einzelne Statusmeldungen, und Zustandsmeldungen werden auch nur dann an die Configuration Manager Datenbank weitergegeben, sofern sich der Zustand verändert hat. Der Datenbank ist damit jeweils nur der aktuell gemeldete Zustand und der Zeitpunkt, zu dem dieser gemeldet wurde, zu entnehmen.

Der Configuration Manager Client überprüft den Status von ihm aktuell zugewiesenen (!) Anwendungen

• vor und nach der eigentlichen Installation bzw. Deinstallation der Anwendung

• zeitgesteuert entsprechend den Einstellungen für die erneute Auswertung für Bereitstellungen (standardmäßig alle 7 Tage)

• bei Ausführung des Evaluationszyklus für die Anwendungsbereitstellung

Die Überwachung von Anwendungen in Configuration Manager 2012 basiert auf der Anwendung an sich und nicht auf der jeweiligen Zuweisung. Solltest beispielsweise ein Anwendung durch mehrere Zuweisungen einem Client zugewiesen sein, so berichtet der Client insbesondere nicht, aufgrund welcher speziellen Zuweisung die Anwendung letztlich installiert wurde, da dies für die Installation keine Relevanz hat.

Ferner werden Anwendungen nur solange überwacht, wie es mindestens eine entsprechende aktive Zuweisung gibt. Dies kann dazu führen, dass die Statusinformationen in der Configuration Manager Datenbank nicht mehr aktuell sind. Wenn z.B. eine Anwendung von einem Client deinstalliert wird, nachdem die Zuweisung gelöscht wurde, wird der Status für diese Anwendung nicht mehr aktualisiert, solange es keine neue Zuweisung an den Client gibt. Daher ist darauf zu achten, entsprechende Zuweisungen bestehen zu lassen, solange der Status der Anwendungen überwacht werden soll.

Der Configuration Manager Client protokolliert dabei seine Aktionen in den folgenden Logdateien:

• AppDiscovery.log

• AppEnforce.log

• AppIntentEval.log

• StateMessage.log

Der Anwendungsbereitstellungszustand wird vom Client über zwei Zustandsmeldungen (engl.: State Messages) berichtet, und zwar über Meldungen mit der TopicType 1702 (Enforcement State) und über die Meldung mit der TopicType 1701 (Compliance State) (s. StateMessage.log).

Ferner speichert der Client alle Statusmeldungen in WMI, und zwar unter root\ccm\statemsg in der Klasse CCM_StateMsg.

Die folgenden Tabellen zeigen die jeweiligen möglichen Statusinformationen, die mit Hilfe der Zustandsmeldungen an den Configuration Manager Standort übermittelt werden und damit grundsätzlich zur Auswertung zur Verfügung werden:

In der Configuration Manager Datenbank können diese Statusinformationen über diverse SQL Views abgerufen werden, insbesondere über die SQL View v_CICurrentComplianceStatus. Der eigentliche Status ist dabei den folgenden Feldern zu entnehmen (jedoch als IDs, und nicht als beschreibender Text):

Microsoft System Center 2012 R2 Configuration Manager beinhaltet einige Standardreports bzgl. der Überwachung des Status von Softwareverteilungen, die direkt genutzt oder bei Bedarf angepasst bzw. als Vorlagen für eigene Reports verwendet werden können. Die auf Microsoft SQL Server Reporting Services aufsetzenden Standardreports verwenden dabei Funktionen aus SRSResources.dll (z.B. Localization.GetStateMessage), um die o.g. IDs in den beschreibenden Text zu übersetzen.  

nachdem ich einige Tage mit dem PowerShell Deployment Toolkit zugebracht habe bin ich total begeistert von den Möglichkeiten, die dieses Framework bietet.

Erste Versuche haben mich jedoch in diverse Fehler geführt und was ich bisher in den Blogs vermisse will ich hier kurz niederschreiben.

Ich teste das PDT 2.6 auf Windows Server 2012 R2 voll gepatcht.

1. Generation 2 VMs

Bei der Erstellung von Generation 2 VMs gibt es ein Problem mit der Reihenfolge, wie Resourcen an die VMs hinzugefügt werden. Zuerst kommt der Netzwerkadapter, danach CDROM und die Virtual Disks. Das sorgt im UEFI Boot Mode für die Bootreihenfolge NIC - HDD 1 - HDD".

Da das für einen Timeout mit Stop in Hyper-V sorgt, muss bei allen VMs die Boot Reihenfolge geändert werden.

Ich habe dazu im Script VMCreator.ps1 folgende Zeilen bei Zeile 1162 ergänzt:

# Set Boot Order

if($VMGen -eq "2"){

$primaryHD = Get-VMHardDiskDrive $VMName -ControllerLocation 0 -ControllerNumber 0

Set-VMFirmware -VMName $VMName -FirstBootDevice $primaryHD

Write-Host " Changing Boot Order: " $primaryHD.name.ToString()

}

Das sorgt dafür, dass die erste HD (dev 0 an Controller 0) als primäres Boot Device eingestellt wird.

2. Ich bekam immer diverse Fehler beim ausführen der Scripts. Fehlermeldungen wie "OM Server Setup contains invalid characters" haben mich dazu getrieben, die Servernamen zu ändern auf die originalen Einstellungen. Trotzdem verbleiben Fehler in den Scripts.

Nach einigen Versuchen habe ich festgestellt, dass die Regional Settings dafür verantwortlich sind. Um PDT 2.6 fehlerfrei zu bekommen ist es das Einfachste, das Basis Image für Windows Server 2012 R2 auf den Standard Einstellungen in en-us zu belassen. Tastatur, Datum und Anzeigesprache. Man kann danach die Server recht einfach mit folgendem Script in der VM auf die deutschen Einstellungen korrigieren:

set-culture de-de

set-winsystemlocale de-de

Set-WinHomeLocation 0x5E

Set-WinUserLanguageList de-de -force

Ich hoffe, die Informationen sind hilfreich.

Nach der Abschaltung bzw. Deinstallation eines Standortes verbleiben diese Informationen im Active Directory, sofern das Active Directory nicht entsprechend - manuell oder automatisiert - bereinigt wird.

Objekte von nicht mehr existierenden SMS 2003 bzw. ConfigMgr 2007 Standorten im Active Directory können allerdings diverse Probleme verursachen: es kann z.B. vorkommen, dass Clients keine Software erhalten, da sie versuchen, den noch im Active Directory hinterlegten, aber nicht mehr existierenden Management Point zu kontaktieren.

Daher ist es sinnvoll, verwaiste Objekte, d.h. Objekte, die zu nicht mehr existierenden SMS 2003 bzw. ConfigMgr 2007 Standorten gehören, aus dem „System Management“ Container zu löschen.

Das Skript CleanSMSObjectsFromAD.vbs zeigt beispielhaft, wie so eine Löschung anhand der Angabe eines Sitecodes in der lokalen Active Directory Domäne vorgenommen werden kann und kann als Beispiel dienen, die Bereinigung des Active Directory bzgl. SMS 2003 und ConfigMgr 2007 zu automatisieren. 

CleanSMSObjectsFromAD.vbs

Das konnte ich mir nicht erklären, da ich sicher war, die Lizenz korrekt eingegeben zu haben. Also gut, dann eben nochmal: Key eingegeben und schon die nächste Fehlermeldung: “Cannot complete this action at this time. Please make sure you can access the SQL server” – und Orchestrator lief weiter im Eval-Modus.

Eine Anfrage bei den Kollegen vom SQL Support brachte Klarheit: Die Orchestrator Datenbank läuft in einer SQL Server 2012 AlwaysOn Availability Group, was mit dem Service Pack 1 auch offiziell von Microsoft unterstützt ist. In der Nacht ist der SQL Knoten gestorben, auf dem die Orchestrator Datenbank ursprünglich erzeugt wurde. Nun muss man wissen, dass System Center 2012 Orchestrator Daten in der Datenbank verschlüsselt. Dafür verwendet Orchestrator sowohl den Database Key, der während der Installation erzeugt wird. als auch den Service Master Key des SQL Servers. Dieser wird automatisch erzeugt, sobald er das erste Mal benötigt wird. Schwenkt nun die Datenbank von einem SQL Knoten auf einen anderen, kann Orchestrator nicht mehr auf die Lizenzinformation zugreifen, die verschlüsselt in der Tabelle PRODUCTINFO gespeichert wird, weil auf dem Zielknoten der Service Master Key ein anderer ist (jedenfalls, wenn der SQL Admin nicht daran gedacht hat… – naja, SQL AlwaysOn ist ja noch ziemlich neu). Das Ergebnis ist oben genannte Lizenzwarnung.

Gottseidank ist das Problem relativ einfach in den Griff zu bekommen. Der Service Master Key des SQL Servers, auf dem die Orchestrator Datenbank erzeugt wurde, muss auf alle SQL Server übertragen werden, die an der AlwaysOn Availability Group beteiligt sind. Das macht man folgendermaßen (VORSICHT: Erst bis zu Ende lesen, dann ausführen):

Zuerst brauchen wir ein Backup des Service Master Keys des ersten SQL Servers:

   BACKUP SERVICE MASTER KEY TO FILE = 'c:\temp\ServiceMasterKey'
       ENCRYPTION BY PASSWORD = 'MyPx55w0Rd'

Die Datei wird auf die Zielknoten übertragen und dort als neuer Service Master Key eingespielt:

   RESTORE SERVICE MASTER KEY FROM FILE = 'c:\temp\ServiceMasterKey'
       DECRYPTION BY PASSWORD = 'MyPx55w0Rd'

Jetzt zum “VORSICHT”-Teil: Voraussichtlich wird beim Versuch, den Service Master Key neu zu setzen, eine Fehlermeldung kommen, die darauf hinweist, dass es da eine Orchestrator Datenbank gibt, die auf diesen Schlüssel angewiesen ist. Die korrekte Vorgehensweise wäre nun, die Datenbank aus der Availability Group herauszunehmen, die nicht mehr synchronisierte Kopie auf den Zielknoten zu löschen, dann den Key einzuspielen und dann die Datenbank wieder in die Availability Group aufzunehmen. Das kann man sich sparen, indem man das Restore-Kommando mit der zusätzlichen Option FORCE aufruft (ganz am Ende hinter dem Passwort). Dabei sollte man aber ganz sicher sein, dass der Befehl auf den richtigen SQL Knoten und Instanzen ausgeführt wird, und dass es keine anderen Datenbanken auf dem jeweiligen Knoten gibt, die SQL Verschlüsselung nutzen und evtl. auf den alten Wert des Service Master Keys angewiesen sind.

Vielleicht vorher erst mal prüfen, ob das Recovery eines SQL Servers sauber funktioniert

Übrigens ergibt sich aus dieser Erkenntnis natürlich auch die Frage, wie die Orchestrator Datenbank auf einen anderen SQL Server verschoben werden kann. Sobald ich das mal ausprobiert habe, werde ich meine Erkenntnisse hier veröffentlichen.

Viele Grüße,
Friedrich

ab dem 29.05.2012 könnt ihr die technische Dokumentation für Configuration Manager 2012 herunterladen.

Download Links:

Weitere Informationen und Downloads finden Sie unter System Center 2012 Trial Downloads

Viele Grüße

Christian Hilber

Oft ergibt es sich innerhalb eines Workflows, dass man auf das Parent Ticket - z.B. Incident, Change oder Service Request zugreifen muss um an Informationen zu gelangen.

Wie das geht ist schon wohlbekannt - z.B.

$objSR = (Get-SCSMRelationshipObject -ByTarget $objActivity | ?{$_.RelationshipID -eq "2DA498BE-0485-B2B2-D520-6EBD1698E61B"}).SourceObject

Wenn jedoch die Activity ($objActivity) innerhalb einer Sequential Activity oder Parallel Activity eingebettet ist, führt dieser Aufruf nur auf die nächst höhere Ebene eines Parent WorkItems.

Ich habe daher eine Funktion geschrieben, die es erlaubt, auf das Parent WorkItem einer bestimmten Klasse zuzugreifen. In diesem Beispiel will ich auf den übergeordneten Service Request zugreifen, egal wie verschachtelt die Activity ist:

Function GetServiceRequest ($objActivity){
 
 $objSR = (Get-SCSMRelationshipObject -ByTarget $objActivity | ?{$_.RelationshipID -eq "2DA498BE-0485-B2B2-D520-6EBD1698E61B"}).SourceObject
 
 if($objSR.classname -eq "System.WorkItem.ServiceRequest"){
 return $objSR
 }
 else {
 $objSR1 = GetServiceRequest $objSR
 return $objSR1
 }
 
 } 

Hierbei wird die Funktion solange aufgerufen, bis die Ziel-Klasse System.WorkItem.ServiceRequest erreicht ist und das Object wird dann von der Funktion zurückgegeben.

Viel Spass beim testen...

Dieser Blog Eintrag soll der Beginn sein für eine Reihe von Beiträgen zur deutschen Service Manager Community. Da ich von mehreren Personen gefragt wurde, wie in Service Manager 2012 – oder SvcMgr Workflows mit PowerShell implementiert werden können, sehe ich das als Anlass den ersten Blog Eintrag dem Thema Workflows und PowerShell zu widmen.

Um ein Error Handling in PowerShell Scripts zu implementieren, die für Workflow Activities in SvcMgr verwendet werden, ist ein Error Handling und Benachrichtigung im Fehlerfall zu implementieren. Service Manager kann innerhalb von Workflows nur anzeigen, ob ein Script mittels PowerShell Engine gestartet und ausgeführt wurde, jedoch ist man über die Statusanzeige der Workflows nicht in der Lage, Exit Codes oder Error Messages zu übergeben. Das sorgt schnell für Unmut, da man die Scripts dadurch im Blindflug bedient und oft nicht sagen kann, wieso nun ein Wert nicht gesetzt oder eine beliebige Aktion nicht ausgeführt wurde.

Ich will nun beschreiben wie ein einfaches Error Handling implementiert werden kann, welches auch ohne tiefe .NET Error Objekt Erfahrung in fast allen Fällen angewendet werden kann. Ziel soll sein, ein einfaches Werkzeug mit hohem Wiederverwendungswert zu bieten. Natürlich ist das bestimmt nicht der Weisheit letzter Schluss und ich bin gerne für Feedback offen um auch diesen Beitrag weiter zu entwickeln.

Erkennen von Fehlern:

Bei einem Fehler in PowerShell wird nach jedem Command abgefragt, ob das letzte Kommando erfolgreich war oder nicht:

If($? -ne $true)

Auf dieser Basis lässt sich dann die Exception, die von PowerShell geworfen wird, an eine Funktion übergeben. Da die Scripts innerhalb eines Try – Catch Blocks laufen, wird zunächst die Exception geworfen:

 {

   Throw $error[0].exception

  }

Verarbeitung des Fehlers:

Im Catch Block findet sich dann der Funktionsaufruf mit der Übergabe des Error Objekts und des Activity Objects:

Catch

 {

  LogError $error[0] $Activity

  Exit 1

 }

Die Aktivität ist für die Funktion wichtig, da die Funktion die Fehlerbenachrichtigung baut und diese an die Property outResult an die Aktivität zurückgibt.

Die Funktion wird initialisiert mit den Übergabewerten $objError und $objActivity

Function LogError ($objError, $objActivity)

Als erstes wird die Variable outResult erzeugt. Diese beinhaltet die folgende Struktur:

Source:                                Activity Title

ID:                          Error ID

Text:                     Exception Message; Script Stack Trace

{

    $outResult = ("Source: "+$objActivity.Title+"ID:"+$objActivity.Id,

                $objError.FullyQualifiedErrorId,

                $objError.exception.message,

                $objError.ScriptStackTrace)

 # Danach wird der Inhalt von outResult in die Property outResult der Aktivität geschrieben:

$objActivity | SetSCSMObject –Propery outResult –Value $outResult

}

Das CmdLet Set-SCSMObject ist Teil der SMLets, die unter smlets.codeplex.com heruntergeladen werden können.

Unterstützung für Error Handling in der Aktivität:

Um die Fehlerausgabe später in der Console lesen zu können muss eine vererbte Klasse für die Aktivität angelegt werden und die Property „outResult“ hinzugefügt werden.

  <ClassTypes>

        <ClassType ID="System.WorkItem.WorkflowActivity.MyAutomatedActivity"

                    Accessibility="Public"

                    Abstract="false"

                    Base="ActivityLibrary!System.WorkItem.Activity"

                    Hosted="false"

                    Singleton="false"

                    Extension="false">

          <Property ID="outResult"

                           Type="string"

                           AutoIncrement="false"

                           Key="false"

                           CaseSensitive="false"

                           MaxLength="2048"

                           MinLength="0"

                           Required="false"

                           Scale="0" />

        </ClassType>

 </ClassTypes>

Zu bemerken ist, dass die MaxLength für das neue Property 2048 Byte groß ist. Je nach Volumen des Fehlers ist es notwendig, die vorgegebene Größe von 256 Byte zu erweitern.

Im Anschluss daran kann ein beliebiges PowerShell Script mit Hilfe des Authoring Tools in einen Workflow geladen und in SvcMgr importiert werden.

Implementieren eines PowerShell Scripts als Workflow in SvcMgr:

Öffnen des Authoring Tools und anlagen eines neuen Management Packs:

Demo.Example.Base

Danach Erstellen einer neuen Klasse:

Die default Property löschen:

Eine neue Property anlegen: outResult

Den Wert Maximum Length ändern:

Einen neuen Workflow erstellen:

Die Bedingungen festlegen wann der Workflow gestartet werden soll:

In dem Fall soll der Workflow zu einem Ereignis in SvcMgr gestartet werden.

Dieses Ereignis wird genauestens festgelegt:

Wenn die Klasse Demo.Workflow.Activity sich ändert

UND zusätzlich

Activity STATUS = „in Progress“

Dabei ist zu beachten, dass Changed To ausgewählt ist.

Den Wizard beenden und man erhält einen neuen Workflow ohne Aktivitäten:

Hier kann man mit Drag und Drop eine PowerShell Aktivität hinzufügen:

Im Details Window kann neben dem Namen auch der Script Body hinzugefügt werden:

Dabei kann das Script eingefügt / importiert werden:

Auf die Funktion WriteEvent werde ich in einem späteren Blog eingehen.

Zusätzlich muss die Activity ID an das Script übergeben werden um das Ergebnis zurückschreiben zu können. Dazu ist ein Script Property zu erstellen:

Mit Ok wird das Script in den Management Pack übernommen.

Der Management Pack kann nun versiegelt und importiert werden:

Beim speichern des Management Packs wurde vom Authoring Tool eine DLL erzeugt:

Diese DLL muss in den Ordner „C:\Program Files\Microsoft System Center 2012\Service Manager“ kopiert werden.

In der SvcMgr Console kann nun ein neues Template erzeugt werden unter „Library – Templates“:

Für das Template ist ein neuer Management Pack zu erzeugen: Demo.Example.Configuration

Der Name der Aktivität ist in diesem Fall: Demo Activity

In der Generic Form ist auch schon unser outResult Property zu sehen:

In einem Work Item welches Aktivitäten enthalten kann – z.B. ein Service Request – kann nun die neue Aktivität hinzugefügt werden:

Wenn nun ein Ticket erzeugt wird und die Aktivität „an der Reihe“ ist, wird unter Administration – Workflows – Status angezeigt, ob die Aktivität erfolgreich war oder nicht:

Laut Statusanzeige ist das Script Erfolgreich gelaufen, jedoch sieht die Aktivität im Ticket nicht so aus:

Das Property outResult hat nun folgenden Wert:

 Damit ist ein Fehler im Script nun auch in der Console sichtbar.

 Viel Spass beim testen.

in diesem Beitrag finden Sie die Anleitung um den RTM-Lizenz-Key für Configuration Manager 2012 zu hinterlegen. Als Voraussetzung benötigen Sie den definierten RTM-Lizenz-Key für Configuration Manager 2012 Ihres Unternehmens.

Wie in beiden Screenshots ersichtlich, befindet sich diese Configuration Manager 2012 Umgebung in der Build Number: 7711 (RTM) und der Evaluierung-Status der CAS und der jeweiligen Primary-Site liegt nur noch bei max. 125 Tagen.

In weniger als 10 Schritten hinterlegen Sie in 10 Minuten den RTM-Lizenz-Key für Configuration Manager 2012. Starten Sie dazu aus dem Installationsverzeichnis von Configuration Manager 2012 im administrativen Kontext aus der Eingabeaufforderung  die “Setup.exe” mit dem Installationsparameter “performancemaintence”.

• Setup.exe /performancemaintence

Danach startet sich automatisch der Installation Wizard von Configuration Manager 2012 und klicken Sie auf “Next”.

Wählen Sie hier “Perform site maintenance or reset this Site” und klicken Sie auf “Next”.

Hinterlegen Sie unter “Convert form Evaluation to Full Product Version. Enter your 25-character product key:” den definierten RTM-Lizenz-Key für Configuration Manager 2012 ihres Unternehmens und klicken Sie auf “Next”.

Bestätigen Sie die Lizenzbestimmungen und klicken auf “Next”.

Nach max. einer Minute sollte die Installation erfolgreich durchgeführt worden sein “Core setup has completed”.

Der Verlauf der Installation kann durch Öffnen der Logdatei “C:\ConfigMgrSetup.log” verfolgt werden. Zur besseren Darstellung der Datei wird empfohlen, das CM 2012 eigene Trace Log Tool zu verwenden. Die Installation des definierten RTM-Lizenz-Key für Configuration Manager 2012 ihres Unternehmens muss für die CAS und alle Primary-Sites durchgeführt werden. Hier die Logdatei “C:\ConfigMgrSetup.log” der CAS:

Hier die Logdatei “C:\ConfigMgrSetup.log” der CAS mit der Bestätigung “ Successfully Converted from Evaluation to Full Product Version”.

Nach erfolgreichem Abschluss ist in der CM-Konsole der CAS kein Evaluierung-Status mehr zu sehen.

Hier die Logdatei “C:\ConfigMgrSetup.log” der Primary-Site mit der Parameterübergabe an die "SetupWpf.exe"  /performancemaintence”.

Hier die Logdatei “C:\ConfigMgrSetup.log” der Primary-Site mit der Bestätigung “Successfully Converted from Evaluation to Full Product Version”.

Nach erfolgreichem Abschluss ist in der CM-Konsole der Primary-Site kein Evaluierung-Status mehr zu sehen.

Aus 180 Tagen “Time Bomb” wird so nachträglich eine lizensierte Configuration Manager 2012 Umgebung in der Build Number: 7711 (RTM).

Viel Spass beim testen.

Viele Grüße

Christian Hilber

die RTM von CM 2012 ist auf der MSDN-Seite für Microsoft-Partner und alle VL-Kunden ab jetzt verfügbar:

Download Links:

Build Versions:

Somit ist der nächste große Schritt geschafft und es können die neuen Funktionen getestet werden.

Weitere Informationen und Downloads finden Sie auch auf der MSDN-Seite. 

Viele Grüße

Christian Hilber

Nachfolgend wird die Platzierung einer customized class beschrieben:

1. Erstellung der neuen Class

Als ersten Schritt die originale configuration.mof wegsichern. Danach eine weitere Copy des Originals zur Bearbeitung an einem anderen Ort abspeichern.
Nachdem die configuration.mof mit einem Editor geöffnet wurde, fällt am Ende der Datei auf, das dort Erweiterungen einzusetzen sind.

//========================
// Added extensions start
//========================

//========================
// Added extensions end
//========================

Genau dort wird soll die Erweiterung platziert werden.

Und hier ein Beispiel zur Erweiterung:
Hier wird eine Registrypfad nach bestimmten Einträgen abgefragt:

////////////////////////////////////////////////////////////////////////
//
//  Class Import_RegKeys from HKLM\System\myRegKey
//
////////////////////////////////////////////////////////////////////////

#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("MyRegKey", NOFAIL)
[DYNPROPS]
Class MyRegKey
{
[key] string KeyName;
String Jahr;
String Monat;
String Tag;
};

[DYNPROPS]
Instance of MyRegKey
{
KeyName="RegKey";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SYSTEM\\MyRegKey|Jahr"),Dynamic,Provider("RegPropProv")] Jahr;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SYSTEM\\MyRegKey|Monat"),Dynamic,Provider("RegPropProv")] Monat;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SYSTEM\\MyRegKey|Tag"),Dynamic,Provider("RegPropProv")] Tag;
};

2. Test der configuration.mof

Nachdem die configuration.mof erweitert wurde, sollte diese auf Fehler überprüft werden. Dazu nutzen wir das Tool mofcomp. Der Aufruf zur Überprüfung der neuen configuration.mof ist könnte so aussehen: c:\mofcomp –check c:\temp\configuration.mof

Sollte hierbei ein Fehler eingeschlichen haben, wird er hier dargestellt.

3.  Import der neuen configuration.mof

Nachdem die neue configuration.mof auf Fehler überprüft wurde,  wird diese unter %Installpath%\inboxes\clifiles.src\hinv platziert.
Die Überprüfung des Vorgangs erfolgt unter %Installpath%\Logs\dataloader.log

4.  neue configuration.mof registrieren

Damit in den Clientsettings die neue Klasse importiert werden kann, muss diese noch mittels mofcomp registriert werden.

Hier der Aufruf:  mofcomp %Installpath%\inboxes\hinv\configuration.mof

Nun sind alle Voraussetzungen erfüllt, um das Inventory entsprechend zu erweitern.

5. Auswahl der neuen Klasse mittels Client Hardwaresetting

Jetzt kann im SQL Server Manager noch überprüft werden, ob eine entsprechende View erstellt wurde.

6. Start Hardwareinventory

Damit die DB mit Inhalten gefüllt wird, muss jetzt die neue Policy von einem Client verarbeitet werden. Hierzu beispielhaft den Policyintervall über den Configuration Manager Client starten.

7. Analyse der Ergebnisse

Die Ergebnisse sind in der SQL DB oder aber auch per WQL Query in der System Center Configuration Console einzusehen.

by Michael Wendlandt
and Thorsten Henking