Erstellt man eigene Management Packs (MP) für den Operations Manager (OpsMgr) oder den Service Manager (SCSM), so kommt es regelmäßig vor, dass er beim Öffnen eine bestimmte Version eines abhängigen MPs haben möchte. Wurde das neue Management Pack in einer Umgebung erstellt, die ein aktuelles Update Rollup eingespielt hat, so wird u.U. genau dieser benötigt.

Daher habe ich mir für meine tägliche Arbeit in einer Ordnerstruktur mit diversen Management Packs aufgebaut. Als Ordnername wird die Versionsnummer verwendet. Möchte das Authoring Studio somit die Version 1.0.1, kann ich in den Ordner wechseln und sehe direkt alle MPs mit dieser Version bzw. aufgrund des Filters im Dialog direkt das benötigte File.

Hardwareinformationen für IT Asset im Service Manager (SCSM) können am Besten über den ConfigMgr importiert werden. Plug&Play Monitore werden bereits mit ein paar Informationen erkannt. Dabei fehlen Seriennummern und auch ein Produktcode des Monitors.

Dank EDID (extended display identification data) stehen diese Informationen am Client in der Registry bereit. Bereits seit längerem gibt es einen kleinen WMI Provider bei SourceForge (http://sourceforge.net/projects/wmimonitor/), der die Registryinformationen auswertet und als WMI Klassen bereitstellen. Seit ConfigMgr 2012 ist das Einbinden weiterer WMI Klassen in die Hardwareinventur denkbar einfach geworden.

Ich verwende regelmäßig die Abkürzung SCCM für System Center Configuration Manager. In den MVP Foren wird man dafür regelmäßig gerügt. Ursache hierfür ist, dass Microsoft für seine Produkte nur offizielle Abkürzungen benutzt, die nicht von einer anderen Firma als Trademark eingetragen wurden.

Der Eintrag SCCM ist ein eingetragenes Trademark. Zu finden ist dies z.B. in der entsprechenden Datenbank der USA:

Sometimes if you are testing the import of a bunch of incidents, it is necessary to delete them.

As usual you can do it with a one-line powershell:

This command deletes all incidents that are created from yesterday to now:

(Get-SCSMClass -Name "System.WorkItem.Incident" | Get-SCSMClassInstance)
 | where {$_.FirstAssignedDate -gt ((get-Date).addDays(-1))} | Remove-SCSMClassInstance

In SCSM you first have to retrieve the class you are interessted in. After that you search for all instances of this class. The last command Remove-SCSMInstance deletes all matching instances.

Sollen eigene Management Packs voneinander abhängig sein, so kann man dies im Authoring Studio von System Center Service Manager 2012 (SCSM) nicht mehr über die Oberfläche konfigurieren. Dies ging noch im alten Authoring Console von SCOM 2007. Einige Abhängigkeiten werden automatisch eingetragen. Braucht man aber die Abhängigkeit zu dem signierten eigenen Management Pack (MP), so schlägt dieser Automatismus fehl. Notwendig ist die Abhängigkeit zu einem signierten MP, wenn bestehende Klassen durch eigene Attribute erweitern will. Diese müssen dann zwingend in einem signierten MP abgelegt werden. Gleichzeitig landen die Anpassungen an den Forms immer in einem unsignierten MP.

Das Thema Sortierreihenfolgen im SQL Server für die einzelnen System Center Produkte ist in 2012 etwas komplizierter geworden. Gerade wenn man SCSM und SCOM kombinieren will, dann stößt man auf das Problem, dass OM SQL_Latin1_General_CP1_CI_AS fordert und SM eine Warnung bringt, wenn man diese Collation benutzt. Ich habe bereits für ein SC Projekt eine Microsoft Support Anfrage gestellt und eine ausführliche Antwort bekommen. Auch in meinem Blog mehren sich die Suchanfragen zu SC 2012 und Collation.