In letzter Zeit gewinnt die Versorgung und Verwaltung von Systemen in einer demilitarisierten Zone (DMZ) oder sogar über vollständig öffentliche Netze über DSM immer mehr an Bedeutung. Mobile Mitarbeiter, Heimarbeitsplätze und das Arbeiten von den unterschiedlichsten Orten sowie die steigende Anzahl von neuartigen Geräten wie beispielsweise den Windows Surface Tablets erzeugen den Bedarf, diese Systeme unabhängig von ihrem aktuellen Standort erfassen und verwalten zu können.

Die Implementierung einer solchen Infrastruktur ist alles andere als trivial. Während die meisten Systemadministratoren im Umgang mit (SMB-)Shares, NTFS-Berechtigungen und Active Directory Benutzerkonten erfahren und sicher sind, sind die für eine DMZ-unterstützende Konfiguration erforderlichen Technologien oftmals noch recht unbekannt beziehungsweise besteht wenig Erfahrung mit deren Umgang.

Es sind Themen wie die Internet-Protokolle http und https, Begriffe wie SSL und TLS, die Microsoft Internet Information Services (IIS), Zertifikate und Public Key Infrastrukturen (PKIs) oder auch Netzwerk-Infrastruktur Aspekte wie Firewalls oder TCP/IP-Ports relevant, um die Admins bisher oft einen großen Bogen gemacht haben oder für deren Beherrschung es einfach keine Notwendigkeit gab.

Kürzlich kam einer unserer Kunden auf mich zu mit dem Anliegen, dass er die bestehende ODS-Struktur seiner DSM-Produktionsumgebung auf eine Testumgebung übertragen möchte. Grundsätzlich ist es ja eine gute Idee, Test- und Produktionsumgebung möglichst identisch oder zumindest nahezu identisch zu halten und somit besteht die Notwendigkeit, diese Anforderung mit möglichst geringem Aufwand umzusetzen. Ein manuelle "Synchronisation" schied daher von vorneherein aus.

Die Vorstellung des Kunden war, sowohl die Domain- und OU-Struktur, sowie die statischen und dynamischen Gruppen zu übertragen. Als Kunde der PowerShell Extensions lag natürlich nahe, diese Aufgabe mittels eines PSX-basierten Scripts zu erledigen. Insbesondere bei der Übertragung der hierarchisch organisierten dynamischen Gruppen tat sich der Kunde jedoch schwer, und kam mit der Bitte um den ein oder anderen Tipp auf mich zu.

Da es sich um eine interessante und durchaus auch für andere Kunden relevante Aufgabenstellung handelt, möchte ich in diesem Artikel einen möglichen Ansatz bzw. eine einfach gehaltene Lösung zur Umsetzung dieser Anforderung vorstellen.

Vor kurzem haben wir die neue Version 3.0 der PowerShell Extensions für FrontRange DSM (PSX) freigegeben. Neben vielen internen Verbesserungen, wurden auch wieder eine ganze Reihe neuer Cmdlets aufgenommen, um die Verwaltung von DSM noch besser über die PSX steuern zu können.

Neben Cmdlets zur Erstellung, zum Abrufen und zum Löschen von Citrix-Objekten im DSM Organisationsverzeichnis, wurden insbesondere die mit DSM 2014.1 eingeführten neuen Möglichkeiten des Advanced Patch Managements (APM) adressiert und entsprechende Cmdlets implementiert.

In jüngerer Vergangenheit sind wir von einigen Anwendern unserer PowerShell Extensions für FrontRange DSM (PSX) darauf aufmerksam gemacht worden, dass es beim Absetzen von PSX-Kommandos die fehlschlagen, zu einer kryptischen Fehlermeldung kommt, die nur besagt dass das es sich bei der Antwort um nicht-wohlgeformtes XML handeln würde.

Dies ist natürlich wenig aussagekräftig und hilft bei der Ergründung der Fehlerursache nicht weiter.

Im oben dargestellten Fall kann man vielleicht noch selbst darauf kommen, dass es schlicht nicht möglich ist, eine Software-Kategorie unterhalb von "Managed Users & Computers" zu erstellen – in aller Regel wird man jedoch auf die konkrete Fehlermeldung angewiesen sein, um die Ursache des Problems erkennen und beheben zu können.

Das beobachtete Verhalten tritt im Übrigen nur auf, wenn die Umgebung schon auf DSM 2013.2 (oder neuer) aktualisiert wurde.

Eine der – weitgehend undokumentierten – Neuerungen in DSM 2013.2, ist die Möglichkeit im Rahmen des CSV-Imports von Objekten, diese gleich zu Mitgliedern statischer Gruppen im ODS zu machen.

Sinn und Zweck dieser Möglichkeit ist naheliegenderweise, dass ohne weitere manuelle Aktionen über die Mitgliedschaft in Softwarezuweisungs-Gruppen neuen Objekten (vermutlich in aller Regel Computer-Objekten) bestimmte Software-Pakete oder sogar ganze Sets an Standard-Paketen zugewiesen werden sollen. Damit lässt sich dann eine weitgehende Automatisierung von Rollouts oder Betriebssystem-Migrationen realisieren, wenn im Rahmen von Hardware-Tausch Szenarien, die Daten vom Lieferanten vorab bereitgestellt werden können.

Die Information beziehungsweise eine Dokumentation, welche Syntax das Import-File allerdings haben muss, um Objekte zu Mitgliedern statischer Gruppen zu machen, ist allerdings schwer zu finden...

Seit vergangenem Dezember ist die neue Version FrontRange HEAT DSM 2013.2 verfügbar und spätestens mit dem Release des ersten Hotfix-Bundles vor wenigen Tagen, stehen mehr und mehr Kunden vor der Umstellung auf die neue Version.

Wie mit jedem neuen Release, gab es auch diesmal etliche Änderungen am User-Interface, neue Möglichkeiten und neuen Infrastruktur-Optionen. Hinter den Kulissen wurde aber natürlich auch wieder viel geändert, unter anderem auch am Administration Webservice - der Schnittstelle, über die unsere PowerShell Extensions mit der DSM Infrastruktur kommunizieren. Das bedeutet, dass die Version 2.1 der PSX nicht vollständig kompatibel zum neuesten DSM-Release ist.

Wir freuen uns daher, Ihnen mitteilen zu können, dass seit heute der Kompatiblitäts-Release PSX 2.1.1 zur Verfügung steht, mit dem die vollständige Kompatibilität zur aktuellen Version wiederhergestellt wird.

Seit DSM 7.2.1 gibt es ja neben dem normalen Patch Management, das im Wesentlichen die Funktionalität bietet, die die Windows Server Update Services (besser bekannt als WSUS) auch bereitstellen, die erweiterte Variante des Avanced Patch Managements (APM).

Hauptmerkmal des APM ist, dass neben den üblichen Microsoft Produkten, die auch durch den WSUS mit Patches versorgt werden würden, eine große Anzahl von Dritthersteller-Produkten gepatcht werden kann. Fragt man jedoch, welche Produkte (oder zumindest wieviele) denn sonst noch mit Patchen versorgt werden können, erhält man oft ungenaue oder zum Teil sogar sich widersprechende Aussagen.

Da es sich beim APM um eine OEM-Version des Produkts "Shavlik Protect" handelt, kann man auf die Angaben des Herstellers zurückgreifen – sofern man diese findet...

Rund um das Thema "Umzug des ORG-Master Depots" gibt es jede Menge Unsicherheit, Gerüchte und fast schon moderne Märchen. Ganz früher (zu NetInstall 5.0-Zeiten) war dafür zwingend der sogenannte RAW-Modus erforderlich, der aber weder supported noch offiziell dokumentiert war.

Um ein supportbares Szenario zu schaffen, wurde mit der Version NetInstall 5.54 der Schalter "/AllowSrvMove" geschaffen, mit dem der NetInstall-Manager gestartet werden musste. In solch einer Sitzung konnte dann der ORG-Master durch Auswahl des Kontextmenü-Befehls "Umbenennen" oder durch Drücken von F2 umbenannt werden.

Wie mein Kollege David König in einem – mittlerweile veralteten und daher von ihm offline-genommenen – Artikel beschrieben hatte, gab es auch vor einiger Zeit mal eine DSM-Version, wo die alleinige Verwendung des "/AllowSrvMove"-Parameters nicht (mehr) ausreichend war. Beim Versuch eine so modifizierte NCP-Datei abzuspeichern kam es zu einer Fehlermeldung und so musste damals eine Kombination aus RAW-Mode und Schalter verwenden werden.

Mittlerweile (zum Zeitpunkt der Erstellung dieses Artikels ist die DSM-Version 7.2.1.2123 aktuell) wurden  diesbezüglich erneut Änderungen vorgenommen...

Die meisten Leser dieses Blogs dürften sich bereits mehr oder weniger intensiv mit FrontRange DSM (oder Vorgängerversionen davon) beschäftigen. Daher wird im Regelfall auch die Möglichkeit bekannt sein, Einstellungen aus der Konfigurationstabelle lokal zu überschreiben.

Das bekannteste und sicherlich auch meistgenutzte Szenario ist dabei, das in der Konfigurationstabelle eingestellte Loglevel lokal so zu modifizieren, dass ausführlichere und damit aussagekräftigere Logs erzeugt werden. Diese geschieht in der Regel durch Aufruf des NetInstall Monitors (nimoni.exe) und Auswahl des Menübefehls Protokolldatei-Optionen > Detailtiefe der Protokollierung einstellen. Dass durch diese Aktion im Endeffekt nur der Registrywert LogLevel im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\NetSupport\NetInstall\LogFileSettings gesetzt wird, ist auch noch geläufig. Dieser „überschreibt“ dann den zentral über die NCP-Datei vorgegebenen Wert NcpLogLevel.

Nun könnte man die Hoffnung haben, dass sich alle über die Konfigurationstabelle getroffenen Einstellungen auf diese Art und Weise überschreiben lassen. Dem ist jedoch (leider) nicht so...

In einem älteren Blogartikel habe ich beschrieben, dass mit DSM 7 wieder das alte – aus NetInstall 5.x bekannte – Verhalten eingeführt wurde, dass letztlich die lokale Registry des gemanageten Clients entscheidend ist, ob Pakete installiert oder nicht installiert werden und der Status der zugehörigen Policy-Instanz nicht mehr die entscheidende Rolle spielt, wie das noch unter Enteo v6 der Fall war.

In einem konkreten Kundenszenario wurde nun aber kürzlich ein Verhalten beobachtet, dass Pakete doch nicht neu installiert wurden, wenn zur Reinstallation eines Clients ein Image zurückgespielt wurde und Pakete im Image nicht installiert waren, die vorher über DSM 7 verteilt worden waren und daher eine grüne Policy-Instanz besaßen.

Dies scheint dem beschriebenen Verhalten zu widersprechen. Und in der Tat wurde in diesem Zusammenhang eine Information bekannt, die so vorher nicht dokumentiert war...