Torsten's Blog » Collections

Collection aller Sitesysteme

Torsten — Mon, 21 Dec 2009 17:30:24 +0000

Wie bekommt meine eine Collection, die alle Sitesysteme enthält ohne dass der ConfigMgr-Client darauf installiert ist (und man somit nicht die Möglichkeit hat, Hardware-Inventory-Kriterien heranzuziehen)?
Die Lösung ist einfach:
select * from SMS_R_System where SMS_R_System.Name in (select distinct ServerName from SMS_SystemResourceList)

Subselect / not in – Abfragen

Torsten — Mon, 14 Dec 2009 11:30:52 +0000

Eine Abfrage zu erstellen, welches System eine bestimmte Software installiert hat, ist einfach.
Wenn man aber eine Collection haben will, die nur die Rechner enthält, welche eine Software nicht hat, so wird’s etwas komplizierter. Folgendes Beispiel dient zur Verdeutlichung.

Am besten startet man mit einer Liste der Rechner, die die Software installiert haben, so z.B. “zeige mir alle Rechner, die Winzip 9.0 installiert haben“:

select distinct SMS_R_System.Name from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like “%Winzip 9.0%

Um sich jetzt die Rechner anzeigen zu lassen, die Winzip 9.0 nicht installiert haben muss man das “subselect … not in” – Statement verwenden.

“Zeige mir alle Rechner, aber nicht die, die Winzip 9.0 installiert haben“, was nichts anderes bedeutet als “alle Rechner ohne Winzip 9.0“:

select distinct Name from SMS_R_System where Name not in (select distinct SMS_R_System.Name from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like “%Winzip 9.0%”)

In der GUI erkennt man auch sehr gut, dass der “Subselect” – Teil genau die erste Query (blau markiert) meines Beispieles ist, der nur der “not in” – Teil vorangestellt ist:

Mathematik mit ConfigMgr

Torsten — Wed, 02 Dec 2009 20:00:32 +0000

Manchmal stellt sich die Frage, ob aktuelle Einstellungen einer (Central) Site aus Performance-Sicht auch wirklich Sinn machen. Hier ein aktuelles Beispiel einer Central Site mit ca. 1000 dynamischen Collections und deren Update-Intervallen.
Solche Betrachtungen können teilweise nicht im Vorfeld gemacht werden, da man aktuelle Werte heranziehen muss, die erst dann ermittelt werden können, wenn die betroffene Site auch wirklich in Betrieb und unter Last ist. Es macht also Sinn, die Konfiguration einer Site ab und zu kritischen Bewertungen zu unterziehen.

Wie lange braucht also der Collection Evaluator, bis er eine Collection aktualisiert hat? Glücklicherweise gibt es dazu den View v_Collection in der Datenbank:

Für jede Collection gibt es also einen Zeitstempel, an dem mit der Evaluierung begonnen wurde und einen weiteren, an dem sie abgeschlossen war. Die Mathematik überlasse ich dem SQL-Server, der mit folgender Query die Collection-Evaluierungsdauer für jede Collection berechnet:

SELECT
Name AS [Collection Name],
DATEDIFF(s, EvaluationStartTime, LastRefreshTime) AS [Eval Time (s)]
FROM
v_Collection
ORDER
BY [Eval Time (s)] DESC

Somit kann man also auch den Mittelwert für die Aktualisierung pro Collection ermitteln (Stichwort: avg). In aktuellen Beispiel lag dieser bei ca. 2 Sekunden.

ConfigMgr braucht also 2000 Sekunden (2s * 1000 Collection), um alle Collections einmal zu aktualisieren. 2000s sind nach Adam Riese (oder auch dem Taschenrechner/calc.exe von Windows 7, der in der wissenschaftlichen Ansicht auch div. Umrechnungen vornehmen kann) also 33,3min:

Der Collection-Evaluator kann leider die Aktualisierungen nur sequentiell abarbeiten. Am vorliegenden Beispiel (alle Collections sind mit einem 30min Interval konfiguriert) sollte also dieser Wert definitiv erhöht werden (30min < 33min), denn die Site hat ja auch noch andere Dinge zu tun, als nur Collections zu aktualisieren.