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.

Wer viel mit ODS Variablen arbeitet wird sicherlich schon einmal an dem Punkt angekommen sein an dem man sich die Frage stellt wo eine bestimmte Variable überhaupt überall gesetzt wurde. Leider ist dieser Verwendungsort über die DSMC nicht wirklich ersichtlich.

In folgendem Beitrag möchte ich einen Codeschnippsel erläutern, mit dem Sie die Zuweisungen der ODS Variable auslesen können.

Bei einem Import eines PnP-Paketes in eine DSM 2014.1 Umgebung kann es zu einem Import-Fehler kommen.

Sie haben ein PnP-Paket welches aus einer älteren DSM / enteo V6 Umgebung exportiert wurde. In diesem PnP-Paket sind in der PnP-ID-Liste mehr als ein Gerät aufgelistet.

Für die Migration einer vorher unter VMware genutzten virtuellen Festplatte auf Microsoft Hyper-V stellt uns der Hersteller das sogenannte Microsoft Virtual Machine Converter Tool (MVMC) in der aktuellen Version 3.0 bereit. Hiermit lassen sich über eine GUI virtuelle Systeme von einem VMware Hypervisor auf Microsofts Azure Plattform oder einen Hyper-V Server konvertieren. Dies setzt aber voraus, dass die Quell- und Zielserver natürlich auf unterschiedlichen Hostsystemen laufen.

In unserem Fall sollten virtuelle Maschinen einer Testumgebung von VMware auf Hyper-V migriert werden, die sich aber auf dem gleichen Hostsystem befinden. Für dieses Szenario bietet das Tool auch die Möglichkeit die Festplatten der Quellsysteme per PowerShell zu konvertieren, diese Lösung werde ich hier kurz beschreiben, um eine Neuinstallation der bereits vorhandenen Systeme zu vermeiden.

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.

Mit DSM 2014 wurden erstmals die Begriffe "Patch Kategorien" und "Patch Rollout Rules" eingeführt. Um diese neuen Konzepte zu verstehen, ist ersteinmal einiges herumprobieren notwendig. Der folgende Designvorschlag soll den Einstieg in dieses mittlerweile komplexe Thema erleichtern. Es wird folgend ausschliesslich auf die Konfiguration dieser neuen Features eingegangen. Für die vollständige Konfiguration von APM im jeweiligen DSM Umfeld müssen noch diverse weitere Dinge (Installationsreihenfolge von Patchen in Bezug auf Softwarepakete, Definition der Patchziele, Rolloutzyklen, Zusammenarbeit mit WSUS, etc.) betrachtet werden.

In größeren Umgebungen mit vielen Administratoren die diverse Aufgaben innerhalb der DSM delegiert bekommen sollen, empfiehlt es sich oft schon wegen der reinen Übersichtlichkeit die User nicht alle einzeln zu berechtigen, sondern mit Berechtigungsgruppen für die Tätigkeitsgebiete zu arbeiten.

Entscheidet man sich hier z.B. für die Verwendung von externen Gruppen aus dem Active Directory reicht es oft aus, das Berechtigungskonzept einmal zu implementieren und alles weitere nur noch über die Gruppenmitgliedschaften des Users im AD zu regeln. An dieser Stelle sollte man sich allerdings entweder gut merken wo man seine Gruppen berechtigt hat oder man denkt über den Kauf von PSX (Powershell Extensions) nach, denn die DSM bietet leider nach wie vor keine Möglichkeit diese Informationen anzeigen zu lassen.

Ich möchte heute kurz zeigen wie Sie mit Hilfe der PSX schnell und einfach herausfinden können wo ihre Gruppe berechtigt ist, ohne dass Sie sich mühevoll durch unzählige Objekte klicken müssen.

Bei der Installation von Hyper-V VMs der Generation 2 per DSM unter Verwendung eines WinPE 4.0 kommt es dazu, dass während der OSD Phase die Tastatur innerhalb der VM nicht verwendbar ist. Dies kommt daher, dass es bei virtuellen Maschinen der Generation 2 keine emulierte Tastatur gibt. Des Weiteren ist der Software-Tastatur Treiber ebenfalls kein Bestandteil eines WinPE 4.0.

Bei einer funktionierenden Umgebung stellt dies in der Regel auch kein Problem dar. Kommt man nun aber z.B. an den Punkt, dass man im PE eine Eingabeaufforderung zum Debuggen starten möchte, kann es durchaus vorteilhaft sein wenn man per Tastatur dann auch Eingaben tätigen kann.

Um diese kleine Unschärfe zu beseitigen können die Hyper-V Integration Services direkt in das Bootenvironment integriert werden. Wie Sie dies machen können, möchte ich Ihnen hier kurz zeigen.

Ein Kunde von uns hatte die Anforderung, dass die Patches von Microsoft im späteren Workflow anders behandelt werden sollten als die Patches von Drittanbietern. Vereinfacht dargestellt sollten erstere auf eine Gruppe und die der Drittanbieter auf eine andere Computergruppe zugewiesen werden.

Der Patch Management Dienst ist so konfiguriert, dass alle Patches einer statischen Computergruppe namens "DownloadOnly" zugewiesen werden, die allerdings keine Computer enthält. Von da aus werden sie mittels Targetlistenerweiterung weiter an die Gruppen "Microsoft" bzw. "ThirdParty" verteilt.

Die Pilotgruppen sind hier ausser acht gelassen, es geht um die grundsätzliche Logik.