SMS 2003: Abhängige Ankündigungen (Dependent Advertisements)

In den Programmeigenschaften eines SMS-Paketes lässt sich festlegen, ob es von einem anderen Programm abhängig ist (Advanced / Run another program first). Es muss jedoch bei solch einer Kettenbildung stets gewährleistet sein, dass das abhängige Programm erfolgreich läuft, sonst bricht die Kette ab. Genau hier liegt aber ein Problem: Wurde z.B. ein abhängiges Programm manuell installiert, schlägt die zweite Installation derselben Anwendung (per SMS) gegebenenfalls mit dem Fehler fehl, dass die Software bereits installiert ist. Vielleicht soll auch ein Programm von mehreren anderen abhängig sein, ohne dass diese einer gegenseitigen Abhängigkeit unterliegen. Es macht also Sinn, nach Alternativen in der Programmsteuerung zu suchen, die sogar eine definierte Reihenfolge von Installationen zulässt.

Eine Möglichkeit besteht darin, in den Collections (Sammlungen), an die angekündigt wird, mit Queries (Abfragen) zu arbeiten, die sich auf durch die Hard- oder Softwareinventur zurückgemeldete Daten beziehen. Die Collections kann man in kleinen bis mittelgroßen Umgebungen bedenkenlos sich halbstündlich aktualisieren lassen. Nachteil dieser Variante ist jedoch, dass die Inventur möglichst jeweils unmittelbar nach Softwareinstallation stattfinden muss, um die Pausen in der Installationskette gering zu halten. Dies ginge am Ende des Installationsskripts mit sendsched.vbs aus dem SMS 2003 Toolkit, jedoch wird jedesmal eine komplette Inventur gemacht und ein paar Daten über das Netzwerk transportiert.

Deshalb habe ich mich gefragt, ob es auch möglich ist, sich auf den zurückgemeldeten Ankündigungsstatus zu beziehen, denn dieser wird immer unmittelbar nach der Installation an die SMS-Datenbank übermittelt. Unter den Statusmeldungsabfragen wird man fündig. Man könnte sie ein wenig umformuliert als Basis der Collection-Queries nutzen. Allerdings werden die entscheidenden Statusmeldungen standardmäßig nach 30 Tagen gelöscht. Man wird auch fündig bei den Reports. Hier wird, solange eine Ankündigung existiert, der letzte Status angezeigt (Success, Failed, oder anderes). Das Problem ist nur, dass Reports SQL verwenden, Collection-Queries jedoch WQL. Fragt sich also, ob die SQL-Views bzw. -Tabellen denn auch über das WMI-Repository zugänglich sind. Doch wir haben Glück: Die Nachverfolgung der View-Definition führt u.a. Tabelle “OfferStatusInfo”, wo der jeweils letzte Status aufbewahrt wird, und im WMI findet sich die Klasse “SMS_ClientAdvertisementStatus”, die alle Daten perfekt aufbereitet vorhält.

Zunächst bauen wir eine Query, die den Inhalt dieses WMI-Objekts erklärt, und alle wichtigen Daten zu einem Advertisement anzeigt:

select Sys.Name, Stat.LastStateName, Stat.LastState, Stat.LastStatusMessageIDName, Stat.LastStatusMessageID, Stat.LastStatusTime, Stat.LastAcceptanceStateName, Stat.LastAcceptanceState, Stat.LastAcceptanceMessageIDName, Stat.LastAcceptanceMessageID, Stat.LastAcceptanceStatusTime, Sys.ResourceID, Stat.AdvertisementID from SMS_R_System as Sys inner join SMS_ClientAdvertisementStatus as Stat on Stat.ResourceID = Sys.ResourceId where Stat.AdvertisementID like ##PRM:SMS_Advertisement.AdvertisementID##

Und nun können wir noch ein Vorlage für eine Collection bauen, wo geprüft wird, ob eine Software erfolgreich per Ankündigung installiert wurde, so wie es bei der Verwendung der eingangs erwähnten Eigenschaftsseite von Programmen im Prinzip auch gemacht wird. Ein Unterschied besteht darin, dass wir uns hier gezielt auf ein anderes Advertisement beziehen, dessen ID jeweils einzutragen ist. Dafür lässt sich die Abfrage beliebig mit anderen kombinieren, z.B. ODER-verknüpft mit Inventurdaten.

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 ResourceId in (select ResourceID from SMS_ClientAdvertisementStatus where AdvertisementID = "ABC2xxxx" and LastStateName="Succeeded")

ABC2xxxx ist jeweils durch die Ankündigungs-ID zu ersetzen, von der wir abhängig sein wollen. Desweiteren ist der Wert "Succeeded" abhängig von der jeweiligen SMS-Server-Sprachversion. Alternativ könnte sprachunabhängig LastState=13 verwendet werden.

Der große Vorteil ist nun, dass wir eine Kette auch beim Ergebnis "Failed" weiterlaufen lassen können, wenn stattdessen z.B. die Hardwareinventur aufzeigt, dass die Software bereits installiert ist.
Einziger Nachteil gegenüber der Kettenbildung in den Programmeigenschaften bleibt, dass die Collections häufiger aktualisiert werden müssen, am Besten doppelt so oft als wie das Policy-Abrufintervall in den Eigenschaften des Client-Agenten für angekündigte Programme definiert ist.

Wo wir schon dabei sind:
Hier noch ein SQL-Statement, um Pakete, bzw. Programme, mit klassisch definierter Abhängigkeit zu finden:

SELECT LTRIM(v_Package.Manufacturer + ' ' + v_Package.Name + ' ' + v_Package.Version) AS [Package Name], v_Package.PackageID, v_Program.ProgramName,
LTRIM(v_Package_1.Manufacturer + ' ' + v_Package_1.Name + ' ' + v_Package_1.Version) AS [Depends on: Package Name], v_Package_1.PackageID,
SUBSTRING(v_Program.DependentProgram, 11, 128) AS [Program Name]
FROM v_Program INNER JOIN
v_Package ON v_Program.PackageID = v_Package.PackageID INNER JOIN
v_Package v_Package_1 ON LEFT(v_Program.DependentProgram, 8 ) = v_Package_1.PackageID
WHERE (v_Program.DependentProgram != '') AND (LEFT(v_Program.PackageID, 3) LIKE @PkgSite)
ORDER BY LTRIM(v_Package.Manufacturer + ' ' + v_Package.Name + ' ' + v_Package.Version)

Das Statement kann im Report verwendet werden.
@PkgSite ergibt sich aus der einfachen Promptabfrage:

select distinct LEFT(DependentProgram,3) from v_Program

Promptname: "PkgSite"
Prompt Text: "Original-Standort der Pakete"
Allow Empty: "No"

Kommentarfunktion ist deaktiviert