Wenn ein Hersteller eine neue Version einer von uns verwendeten Software bereitstellt, gehen wir immer nach demselben Schema vor, falls wir die neue Softwareversion bereitstellen wollen:

• Wir erstellen ein aktualisiertes Paket in der Testumgebung und testen dieses. Dabei kontrollieren wir nicht nur die Funktionstüchtigkeit einer Neuinstallation, sondern überprüfen auch, ob bestehende Installationen vonVorversionen der betreffenden Software aktualisiert werden können.
• Sobald wir von der Tauglichkeit des neuen Paketes überzeugt sind, stellen wir dieses als zusätzliches Paket in der Produktionsumgebung bereit. Das Paket der Vorversion bleibt daneben unverändert erhalten.
• Ab diesem Zeitpunkt wird dann normalerweise auf den Clients die neue Version installiert, doch ein Rückgriff auf die Vorversion wäre nötigenfalls immer noch möglich, falls mit der neuen Version unerwartete Probleme auftauchen sollten.
• Zu einem bestimmten Zeitpunkt – bei uns normalerweise gebündelt mit der monatlichen Microsoft-Updaterunde -  wird dann die Aktualisierung der auf den Clients installierten Vorversionen in Angriff genommen. Hierzu wird unseren Benutzern die Installation des Updates eine Woche lang angeboten; während dieser Zeit kann der Benutzer sich den für ihn geeigneten Installationszeitpunkt selber auswählen. Danach wird die Installation des Updates per Assignment durchgesetzt.
• Sobald die Aktualisierung aller Clients abgeschlossen ist, kann das veraltete Paket der Vorversion entsorgt werden. (Aber gerade bei diesem Schritt lassen wir uns üblicherweise tüchtig Zeit… )

Wie man Softwarepakete via SCCM verteilt, dürfte wohl jedem Administrator bekannt sein, der sich mit diesem Thema beschäftigt. Doch wie funktioniert der Schritt „Aktualisierung installierter Vorversionen“ genau?

Hierzu erstellen wir jeweils eine Collection, an welche die Installation des Updates dann advertised bzw. assigned werden kann. Die Mitgliedschaft in dieser Collection wird jeweils anhand einer Query definiert, welche bei uns immer folgenden Aufbau hat: „Gesucht sind alle Clients, die eine bestimmte Software installiert haben, jedoch nicht in der von uns aktuell gewünschten Version“. Wie dies in einem konkreten Fall aussieht, möchte ich anhand des kürzlich publizierten Update „Java Version 6 (Update 22) zeigen:

Ein x86-Client mit einer veralteten Java-Version

Wir erkennen hier im Bereich „Programme und Funktionen“ in der Systemsteuerung eines Clients, dass auf diesem noch das Update 20 von Java installiert ist. Genau diese Information können wir auch für folgende WQL-Query zur Definition einer Collection in SCCM verwenden:

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
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 "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

Wir suchen also nach Programmen mit der Zeichenkette „Java“ am Anfang des Anzeigenamens, die nicht eine Versionsbezeichnung haben, welche mit „6.0.220“ beginnt. Bei der Versionsnummer gilt es zu beachten, dass es sich hier um eine Zeichenkette und nicht um einen Wert handelt; eine Query in der Form „Version < 6.0.220“ funktioniert nicht. Dass man auch bei der Wahl des Suchbegriffes im Anzeigenamen die nötige Vorsicht walten lassen sollte, dürfte sich von selbst verstehen. Schliesslich möchte man ja nicht ein Java-Update auf einen Client installieren, weil dort auch noch zufälligerweise irgendein „Java-Free-Editor“ (und dummerweise leider nicht in der Version 6.0.220.7) vorhanden ist. Den Suchbegriff sollte man also möglichst spezifisch definieren, nötigenfalls lässt sich auch noch ein Hersteller mit einer weiteren Klausel in der Form „and ..._ADD_REMOVE_PROGRAMS.Publisher like "...%"“ einbeziehen.

Dies funktionierte im vorliegenden Fall bestens und schon hatten wir die passende Collection aller Clients, welche dringend ein Java Update nötig hätten, bereit. Wirklich?

Nein, leider nicht ganz. Denn wir haben nicht nur 32bit (d.h. x86)-Systeme im Einsatz, sondern es sind auch 64bit (d.h. x64)-Systeme vorhanden. Und da sieht das Ganze leicht anders aus:

Ein x64-Client mit zwei veralteten Java-Versionen

Wir erkennen in diesem Screenshot, dass auf diesem Client zwei Java Versionen installiert sind; zwar in beiden Fällen die Version 6u20, aber einmal als 32bit- und einmal als 64bit-Variante. Also galt es dafür zu sorgen, dass überall dort, wo die 32bit-Version installiert ist, auch das 32bit-Update installiert wird und überall dort, wo die 64bit-Version vorhanden ist, auch das entsprechende 64bit-Update geliefert wird.

Leider passt die oben angegebene WQL-Query auch auf „Java(TM) 6 Update 20 (64-bit)“. Und wir beabsichtigen nicht, auf allen Clients die 32bit-Version nachzuinstallieren, auf denen nur die 64bit-Variante installiert ist. Zudem fehlt noch eine passende Collection für die Aktualisierung der 64bit-Variante. Also flugs eine zweite Collection erstellt und die erste modifiziert!

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
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 "Java%"
and SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

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
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 "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS.Version not like "6.0.220%"

Und jetzt: sind wir nun bereit für die Verteilung der beiden Updates? Nein, leider immer noch nicht…

Im Falle der ersten Collection für die 32bit-Variante scheint alles bestens: Es sind genau diejenigen Systeme in der Collection enthalten, welche das 32bit-Update nötig haben. Die zweite Collection ist … leer!?!

Dabei wussten wird doch ganz genau, dass es bei uns Systeme gibt, welche die 64-bit-Java-Version installiert haben. Nach einer längeren Suche nach der Ursache entdeckten wir dann des Rätsels Lösung: Es gibt nicht nur eine Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS„, sondern auch noch eine zweite Tabelle „SMS_G_System_ADD_REMOVE_PROGRAMS_64„. Die Angaben über die auf einem Client installierte Software werden also in separaten Tabellen für 32-bit- und zu 64-bit-Software gespeichert. Kein Wunder also, dass unsere obige Query ein unbrauchbares Ergebnis liefert und demzufolge die Collection leer bleibt, denn wir suchen schlicht und einfach in der falschen Tabelle!

Wir haben dann die Collection für die 64-bit-Java-Version nochmals angepasst, worauf diese dann tatsächlich das gewünschte Ergebnis lieferte:

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
inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64
on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId
where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName like "Java%(64-bit)"
and SMS_G_System_ADD_REMOVE_PROGRAMS_64.Version not like "6.0.220%"

Endlich hatten wir die notwendigen Collections definiert und die Verteilung der beiden Updates konnte starten. Erst später merkten wir dann noch, dass im Falle der ersten Collection für die 32-bit-Java-Version die Erweiterung ..._ADD_REMOVE_PROGRAMS.DisplayName not like "Java%(64-bit)" gar nicht nötig gewesen wäre, da ja in der betreffenden Tabelle gar keine Angaben zu installierten 64bit-Versionen gespeichert sind.