Die Installation der Microsoft Patche wird in den meisten Fällen mit 2 Job Policies auf den Patch Management Execution Packages (PMExec) getriggert. Ein Job steht auf wöchentlich und "Scan only" der andere Job auf täglich und "InstallAndScanIfNeeded". Dies sorgt dafür, dass der Scan eines Systems auf einmal wöchentlich begrenzt ist,die Installation der Patche durch den zweiten job aber relativ zeitnah geschieht. Für den produktiven Betrieb auch eine meist sinnvolle Konstellation. Um die Patch Installation während der OS Installation durchzuführen, wird i.d.R. ein dritter Job geschrieben, der als Schedule "Nach der OS Installation" eingetragen hat. Dies führt zwar zu einem Update der Betriebbsystemkomponenten, lässt aber die folgenden Anforderungen ausser Acht:

1) Alle Patche sollen auf einmal am Stück installiert werden.
2) Patche sollen zu einem definierten Zeitpunkt installiert werden. 
3) Die Patche sollen nach den Paketinstallation laufen. 
4) Es sollen alle Patche die freigegeben sind, auch auf dem PC installiert werden. 
5) Der Benutzer darf sich erst anmelden, wenn alle Patche installiert sind.

Kürzlich kam ein Kunde auf mich zu mit der Frage, warum bei dem Versuch im Discovery ControlCenter das Ergebnis einer Abfrage zu exportieren, die Meldung "Keine zu exportierenden Daten vorhanden." ausgegeben wurde. Das konnte ja nicht sein, da der Kunde die Datensätze markiert und per Kontextmenü-Befehl "Daten exportieren..." den Export angestoßen hatte.

Desweiteren hat mir der Kunde glaubhaft berichtet, dass er ein ähnliches Phänomen bereits häufiger beobachtet hatte, nämlich dass erstellte Reports weniger Rechner-Objekte enthalten hätten, als die entsprechenden Abfragen im ControlCenter. Damit wären die Reports, seiner Aussage nach, unbrauchbar. Es ist verständlich, dass der Kunde hier auf Centennial "sauer war", die Lösung ist jedoch sehr einfach – wenn man sie weiß...

Jeder der einmal mit Softwareverteilung und 64-Bit Betriebssystemen in Kontakt gekommen ist, kennt sie: die 64-Bit Redirection.Doch was genau ist das und was ist bei der Softwareverteilung zu beachten?

Auf einem 64-Bit Windows Betriebssystem können sowohl 32-Bit als auch 64-Bit Applikationen installiert werden. Für jede Architektur gibt es unter Windows einen eigenen Bereich der für die Redirection relevant ist. Auf Fileebene ist es das Verzeichnis C:\Windows\System32\..., in der Registry ist es der Zweig HKLM\Software\... Hier befinden sich alle 64-Bit relevanten Informationen.

Der 32-Bit Bereich befindet sich unter C:\Windows\SysWOW64 bzw. unter HKLM\SOFTWARE\Wow6432Node

Wer sich schon einmal aufmerksam durch die DSM Logs gearbeitet hat, wird schon mal auf die Variablen "_LAST_ERROR_TEXT" und "_ERROR_SEVERITY" gestossen sein. Diese Variablen werden ggf. gefüllt, wenn ein interner DSM Befehl nicht funktioniert hat. I.d.R. ist die Auswertung der internen DSM Befehle allerding nicht sonderlich relevant. Simple Befehle wie ein "InstallFileList" erkenne selber, wenn eine interne Funktion (z.B. aufgrund eines Filelocks) eine Fehler erzeugt hat. 

Allerdings gilt dies nicht für alle Befehle oder alle Konstellationen von Befehlen. Kann z.B. ein "LocalGroupAddMember" Befehl den User, der in die Gruppe hinzugefügt werden soll nicht auflösen, wird das eScript trotzdem mit "Erfolg" verlassen. Im Worst case erfährt der Administrator also niemals etwas davon, dass ein Paket fehlgeschlagen ist. Die beiden oben genannten Variablen helfen bei der Fehleranalyse. Im Beispiel des "LocalGroupAddMember" Befehls wird (bei Fehler) die "ERROR_SEVERITY" mit "3" befüllt, der "_LAST_ERROR_TEXT" mit einem Informationstext über die Ursache des Problems. Folgende Randbedingungen sind beim Einsatz dieser Variablen zu beachten: 

In vielen DSM Umgebung befindet sich mittlerweile mehr als ein BLS. Eine Multi-BLS Umgebung hat die Vorteile einer besseren Skalierbarkeit wenn sehr viele Clients verwaltet werden, sowie einer höheren Ausfallsicherheit. Ein Update einer DSM Umgebung verringert so auch die Downtime des Systems.

Die BLS Server teilen sich für Ihre Operationen die zentrale Datenbank (CMDB).

Der Primary BLS ist aktuell noch für die DSM Infrastruktur verantwortlich. Hier heißt es abwarten, was die DSM 7.2 bringt ;-)

Die Clients wählen sich Ihren BLS per Zufallsprinzip aus. Der Einsatz eines externen Load Balancers ist jedoch auch möglich.

Was passiert jedoch in z.B. Mandantenfähigen Umgebungen, in denen durch Firewall Regeln ein Zugriff auf alle eingesetzten Business Logic Server nicht möglich ist?

Nach Zuweisung von Software und dem damit verbundenen Erzeugen neuer Policies, müssen Ihre Clients in der Regel bis zum nächsten Polling warten, damit die Änderungen angewendet werden.

Über die DSM 7 Konsole hat man jedoch – ähnlich der „Sofort-Installation“ unter NetInstall v5.x – die Möglichkeit, die Aktion „Änderungen ausführen“ durchzuführen und diese Wartezeit damit zu verkürzen. In diesem Blog-Artikel möchte ich Ihnen kurz zeigen, wie Sie diese Möglichkeit auch per PowerShell abbilden können.

Mein Kollege Michael Jeske und ich haben uns in einem gemeinsamen Projekt intensive Gedanken darum gemacht, wie ein Windows 7 Client optimal über die DSM Datenbank in internationalen agierenden Unternehmen auf seine regionalen Bedürfnisse hin präpariert wird. Folgende Ziele haben wir uns dabei gesteckt: 

• Es müssen alle regionsspezifischen Werte (Währung, Tausender-Trennzeichen, Papiergrösse, Datumsformate, Zeitzone, etc.) und das Tastaturlayout konfiguriert werden.
• Die Sprachen werden unabhängig von den regionalen Einstellungen verwaltet / zugewiesen.
• Im Sinne der Anwendung der DSM Datenbank als CMDB, sollen alle regionalen Einstellungen in der DSM Datenbank verwaltet werden. 
• Wechselt ein Client seinen primären Standort, müssen die regionalen Einstellungen ebenfalls automatisiert angepasst werden. 
• Das Keyboard-Layout muss statisch auf das Land konfiguriert werden (und kann später durch eine Einstellung im Benutzerprofil überschrieben werden). 
• Alle Einstellungen werden rein Computer-bezogen betrachtet. Benutzer-bezogene Konfiguration sollte im ersten Schritt aus dem Standardprofil heraus erfolgen (und nicht via DSM, GPO, etc.)
• Da es sich in unserem Fall um ein deutsches Unternehmen handelt, soll neben englisch die deutsche Sprache und Konfiguration immer, unabhängig vom Standort verfügbar sein, sofern dies Sinn macht.

Im Enteo-Forum gab es kürzlich eine angeregte Diskussion über die Frage, ob es seit Enteo v6 und erst recht mit DSM 7 nicht sinnvoller wäre, für neue Repositories die Option "Nur eine Kopie des Paketverzeichnisses halten" zu aktivieren, da man damit jede Menge teuren Storage-Space sparen könnte. Was natürlich auf den ersten Blick wie eine hervorragende Idee aussieht, entpuppt sich (womöglich) bei näherer Betrachtung als "Schuss in den Ofen".

Da ich das ganze Thema schon länger mal komplett durchdenken wollte, habe ich die Forum-Diskussion zum Anlass genommen, diesen Artikel zu schreiben...

Es gibt ein neues "Feature" in DSM 7.1, das meines Wissens nach ebenfalls auch nicht dokumentiert ist. Und zwar macht DSM seit dem aktuellen Release eine aktive Lizenzprüfung und weist – halbwegs penetrant – auf eine bestehende Unterlizensierung hin.

Wie Frank hier schon beschrieben hat, werden seit der DSM 7.0 wieder die „InstalledApps“ Keys in der Registry geprüft.

Somit werden bereits ausgeführte Installationen vom DSM Client automatisch berücksichtig und ohne erneute Ausführung auf compliant gesetzt.

Zusätzlich gibt es aber auch noch die so genannten „IsPreInstalled“ Bedingungen. Diese sind nicht wirklich neu, hörten allerdings zu Pre 7.1 Zeiten noch auf den Namen „IsInstalled“. Hier stehen dem DSM Administrator etliche Kriterien zur Verfügung, um dem DSM Client mitzuteilen, dass eine Anwendung bereits installiert ist. Der Fokus der Bedingungen liegt hier jedoch außerhalb von DSM. Es kann geprüft werden, ob eine Software z.B. manuell oder durch ein „Mitbewerber Deployment Produkt“ installiert wurde. Bei einer erfolgreichen Prüfung setzt der DSM Client die Policyinstanz auf compliant, ohne das Paket auszuführen.