Hier das WQL-Statement für eine dynamische Collection (Sammlung), die alle Distribution Points enthält:

select
SMS_R_SYSTEM.ResourceID,
SMS_R_SYSTEM.ResourceType,
SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,
SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client
from
SMS_R_System
where
SMS_R_System.Name
in
(Select
Servername
from
SMS_SystemResourceList
where
RoleName = ‘SMS Distribution Point’)

Entsprechend lassen sicha auch Sammlungen für’SMS Fallback Status Point’, ‘SMS Reporting Point’, ‘SMS SQL Server’, ‘SMS Management Point’, ‘SMS SRS Reporting Point” usw erstellen.
(Vorsicht bei copy’n paste: WordPress ersetzt die “straight quotes” durch “smart quotes”)

Vor langer Zeit veröffentlichte ich schon einmal einen Artikel über “not in”-Collections (http://www.mssmsfaq.de/index.php?option=content&task=view&id=78). Da meine alte SMS-Webseite sicher schon längst in Vergessenheit geraten ist, möchte ich hier das Thema nochmals aufgreifen, da es manchmal doch noch zu Missverständnissen führt.

Eine Collection, die alle Rechner enthält, auf denen Software xyz installiert ist (oder analog auch ein Dienst in einem gewissen Status ist, die alle Rechner vom Hersteller abc enthält, …) ist einfach.
Ein Beispiel dafür ist die Sammlung “Alle Rechner mit Forefront Client”:

select SMS_R_SYSTEM.ResourceID 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 = “Microsoft Forefront Endpoint Protection 2010″

Bis hierher also überhaupt kein Problem.

Leider aber funktioniert es nicht, den “Operator” von “is equal to” auf “is not equal to” zu ändern!

Stattdessen muss man folgenden Weg gehen, um alle Rechner ohne Forefront zu erhalten: man nimmt alle Rechner und zieht die Rechner ab, auf denen Forefront installiert ist. Übrig bleiben also die, auf denen Forefront nicht installiert ist. Eigentlich logisch!

Die Rechner, auf denen Forefront installiert ist, kennen wir ja schon. Siehe dazu die WQL-Query weiter oben im Artikel. Hier kommt das “Subselect / not in”-Konstrukt in’s Spiel:

Dabei wird im Subselect einfach die Query verwendet, die wir bereits erstellt haben und kennen (alle Rechner MIT Forefront).
Die resultierende Abfrage lautet also:

select SMS_R_SYSTEM.ResourceID from SMS_R_System inner join SMS_G_System_SYSTEM on SMS_G_System_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM.ResourceID not in (select SMS_R_SYSTEM.ResourceID 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 = “Microsoft Forefront Endpoint Protection 2010″).

Einfach – aber trotzdem verwirrend? Keine Angst. ConfigMgr 2012 bietet auch hier eine Verbesserung an. Denn neben “Query Rules” und “Direct Rules” (die es beide ja schon in ConfiMgr 2007) gibt sind zwei neue “Rule Types” hinzugekommen: “Include” und “Exclude”:

Collections in ConfigMgr 2012 wurden auch einigen Änderungen unterzogen.

ConfigMgr 2007: es gibt bei Collections keine Möglichkeit, Ordner (“Folders”) anzulegen. Stattdessen verwendet man für eine bessere Strukturierung einfach leere Collections (d.h. die keine Mitgliedschaftsregeln beinhalten) und erstellt dann untergeordnete Collections (“Subcollections”).
ConfigMgr 2012: es besteht nun die Möglichkeit, Ordner anzulegen. Gleichzeitig wurde die Möglichkeit entfernt, SubCollections anzulegen.

ConfigMgr 2007: hier kann man Benutzer- und Computer-Objekte in der selben Collection mischen.
ConfigMgr 2012: diese Mischung ist nicht mehr möglich. Es gibt entweder Device- oder User-Collections.

Neu in ConfigMgr 2012:

• Inkrementelles Aktualisieren der Collections (bisher nur in ConfigMgr 2007 R3 vorhanden)
• “Power Management Settings” (bisher ebenfalls nur in ConfigMgr R3)
• “include” und “exclude” Rules: hier kann man einfach Rechner einer bereits vorhandenen Sammlung hinzufügen oder ausnehmen, ohne umständlich WQL-Statements (Stichwort “subselect” und “(not) in”) verwenden zu müssen

Eine Voraussetzung für ConfigMgr 2007 R3 ist die Installation von kb977384. Hierbei gibt’s einen kleinen Haken: dieser lässt sich nicht auf Sites installieren, auf denen ICP1 oder ICP2 installiert ist. Wer also R3 auf einer Site mit ICP installieren will, der muss noch warten, bis der Hotfix für die ICP-Versionen verfügbar ist.

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)

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:

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:

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.