NWC Services Blog
Blogs von Consultants der NWC Services GmbH
In DSM 7 gibt es zwei Arten von Schemaerweiterungen. „StateInfo“ und „ManagementInfo“. „StateInfo“ werden vom DSM Client verwaltet. „ManagementInfo“ können nur über die DSMC verändert werden (oder über die PowerShell Extensions).
Mit DSM 7.1 wurde eine Funktion hinzugefügt, um auf einzelnen Clients den Wert einer „StateInfo“ Schemaerweiterung auch über die DSMC zu ändern. Dazu gibt es den Kontextmenüeintrag „Clientseitige benutzerdefinierte Eigenschaften ändern“.
Mit DSM 7.2 wurde dieses Verhalten deutlich erweitert.
Wie mein Kollege Michi Dönselmann bereits hier beschrieben hat gab es in früheren DSM Versionen eine nicht dokumentierte Möglichkeit um Abhängigkeiten bei Installationsparametern zu ermöglichen. Leider konnte das bisher nicht über die Konsole realisiert werden.
Seit DSM 7.2 kann man dies nun durch eine Eigenschaft am Installationsparameter direkt erreichen. Da dieses Feature (stand heute) ebenfalls eher unzureichend dokumentiert ist, kann die korrekte Vorgehensweise hier nachgelesen werden.
Nach der erfoglreichen Paketierung eines Paketes erfolgt der Rollout eines Paketes. Genau wie der Paketierung, sind beim Rollout in einem Unternehmen viele verschiedene Einstellungen und organisatorische Tätigkeiten zu beachten. Um die Steuerung des Rollout möglichst effizient zu gestalten steht unter Services -> Downloads -> pdfpool -> services ein neues Dokument zur Verfügung, welches in Form einer Checkliste den Rollout-Manager dabei unterstützt eine Anwendung in den produktiven Betrieb zu überführen.
Vor einiger Zeit habe ich beschrieben, wie es möglich ist, die DMSC direkt von einem lokalen Verzeichnis aus zu starten, ohne direkt auf den Share zuzugreifen. Der Eintrag ist hier zu finden. Leider ist diese Möglichkeit nur dafür nützlich, um die Performance der DSMC zu steigern, nicht aber um komplett ohne Zugriff auf den Share zu arbeiten. Hintergrund dafür ist, dass die DSMC immer versucht, die NCP Dateien direkt vom Share zu laden.
11:21:24.542 2 Loading configuration information from \\kngsvh01\koenig_dsm\NiCfgSrv.ncp...
11:21:24.549 1 Database file time: 11/29/12 10:43:14
In der Vergangenheit habe ich die drei folgenden Formulare vorgestellt, die dabei helfen den Paketierungsprozess zu optimieren:
Neben den Checklisten, die die Qualität der einzelnen Schitte in einem Paketierungsprozess sicherstellen, ist es wichtig den Überlick über alle Pakete, die an diesem Prozess beteiligt sind, zu behalten.
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?