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.

Seit DSM 7.1 gibt es die Möglichkeit, den Runtime im Context des SYSTEM Users laufen zu lassen. Dies hat folgende Vorteile:

• Lokale Admins werden verringert
  Die Konfiguration eines Runtime Users kann komplett entfallen. Dies muss allerdings bei einer DSM 7.1 Neu-Installation nachträglich erfolgen, der Installations-Wizard ist noch nicht darauf angepasst.
   
• Mangement von Konfiguration auf die nur SYSTEM zugreifen darf
  Beispiel: Der Microsoft Forefront Client sollen nicht via GPO konfiguriert werden, sondern Ihre Settings via DSM Paket erhalten. In diesem Fall müssen die Exclusions unter "HKLMSoftwareMicrosoftMicrosoft ForefrontClient Security1.0AMExclusions" gepflegt werden. Auf diesen Registry Zweig hat aber nur SYSTEM Schreibzugriff. Auch ein vorhergehender "ChangeRegSecurity" hilft da nicht weiter, um dem Runtime Dienst Zugriff zu geben. 
   
• Management von Domain Controllern
  Wird ein Domain Controller mit einem DSM Client versehen, wurde der assoziierte User immer automatisch zum Domain Admin.

Soll dieses Feature eingesetzt werden, müssen folgende Dinge beachtet werden:

seit DSM 7.1 gibt es eine neue Möglichkeit, während der OSD Phase über z.B. ein PreOS Action Paket, den Wert einer Schemaerweiterung zu bearbeiten.

Ein Beispiel hierfür ist, den Installationsstatus zu definieren, welcher später für die Reboot Steuerung abgefragt werden kann.

So kann zu Beginn einer Installation der Wert „Grundinstallation“ in eine State Info Schemaerweiterung geschrieben werden. Solange dieser Wert gesetzt ist, kann der Client ohne Rücksicht auf Verluste rebootet werden. Mit dem letzten DSM Paket kann über den Befehl „ModifyObjectProperty“ der Wert auf „Produktiver Client“ gesetzt werden. Somit müssen gewisse Sachen geprüft werden, bevor ein Reboot durchgeführt werden kann.

Eine weitere bisher undokumentierte Neuerung in DSM 7.1 – wenn auch nicht ganz so spektakulär wie das von Michi hier beschriebene Feature – betrifft die Möglichkeit, einen Vorgabewert für den Kommentar anzugeben, der beim Freigeben eines Paketes eingetragen werden kann und sollte.

Im Normalfall stellt sich das Fenster beim Auswählen des "Paket freigeben" folgendermaßen dar:

Vermutlich wird es den meisten Lesern dieses Beitrags so ergehen, dass hier in der Regel nichts eingetragen wird. Seit DSM 7.1 ist es jedoch nun möglich, hier automatisch einen Vorgabe-Text eintragen zu lassen, um den Paketierern das Ausfüllen zu erleichtern oder ganz abzunehmen.

Mit Einführung der DSM 7, gibt es ein neues Feature, welches von den meisten Paketierern wohl sehnsüchtig erwartet wird.

Sobald ein neues eScript oder MSI Paket erstellt wird, sollten div. Informationen im Skript schon vorhanden sein. Dazu können ein Header, Return Code Variablen, Deinstallations Sektion usw. gehören.

Am einfachsten ist es, sich ein Referenz eScript zu erstellen und die dort vorhandene Script.inc aus dem Paketverzeichnis als Vorlage zu nehmen.

Jeder kennt die Arbeit, die auf einen zukommt, wenn in der DSM eine neue Revision eines Bootenvironments ansteht. Es müssen ggf. Folgerevisionen von Paketen und OS-Installation Sets angelegt werden.

Mit der DSM 7.1 wird diese Arbeit ganz erheblich vereinfacht. Für jeden Client ist jetzt individuell konfigurierbar, welches Bootenvironment in welcher Revision verwendet werden soll.

Einige Hersteller von Softwaremanagement Systemen (mitunter eben auch Frontrange mit DSM 7) stellen eine eigene Packaging Workbench und einen Satz von Skript-Befehlen zur Verfügung, die sich auf die Anforderung für die Verteilung von Software spezialisiert haben. Ein Nachteil dieser Lösungen ist, dass sie nicht portierbar sind, da die Skript-Befehle nicht in einer bekannten Sprache (MSI, VB-Script, Powershell, etc.) implementiert sind, sondern jeweils individuelle Lösungen darstellen. Daher werden immer wieder Empfehlungen von verschiedenen Seiten ausgesprochen, alle Softwarepakete doch zu standardisieren und die Softwaremanagement Umgebung nur noch für die reine Verteilung im Unternehmen zu nutzen. Dies ist auch der Ansatz, den Microsoft mit seinem hauseigenen Produkt SCCM verfolgt. So sinnvoll diese Aussage auf den ersten Blick auch zu sein scheint, gibt es oft gute Gründe, die nativen Skript-Systeme der Hersteller einzusetzen.