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.

Während des Imports von Patches lädt der Patch Management Dienst die Patches herunter und entpackt diese in den temporärer Ordner "SPDTemp". Dieses Verzeichnis liegt standardmäßig im Verzeichnis "%CommonProgramFiles%\enteo", welches über die Infrastruktureinstellung "Directory on the computer for runtime data" (Site Einstellung) konfigurierbar ist.

Wer kennt das nicht – Sie versuchen sich an einer Console, Applikation, Website oder wo auch immer anzumelden, doch Ihnen ist das Passwort des Adminaccounts entfallen und lässt sich auch in keinem Passwortsafe oder alten Dokumentationen finden. In den meisten Fällen bleibt einem dann nur noch der mühsame Weg über den Support des Herstellers und im schlimmsten Fall zieht die kleine Gedächtnislücke sogar eine Neuinstallation der Applikation nach sich.

In meinem heutigen Blog möchte ich Ihnen kurz zeigen, wie Sie sich zumindest im Falle des Citrix License Servers das Passwort des Citrix Adminaccounts zurücksetzen können wenn keine weitere Anmeldung mehr funktioniert.

In den letzten Jahren habe ich sehr viele kundenspezifische Programme entwickelt, die über die SOAP Schnittstelle auf die DSM-Umgebung zugreifen. Es handelte sich dabei vielfach um Windows Dienste, die spezielle Aufgaben durchführten. Dazu zählten unter anderem:

• ein Abgleich der Computerkonten zwischen Active Directory, DSM und Discovery
• ein Patch Management Prozess, bei dem Policies nach einem Regelwerk verschoben / erweitert werden
• Policyinstanzen, die nicht compliant sind auf "Reinstallation" zu setzen und ggf. noch auf den Stand der Policy bringen 
• und viele verschiedene mehr.

Darüber hinaus habe ich auch reine Kommandozeilenprogramme entwickelt, die z.B. Computerobjekte anlegen, Gruppenmitgliedschaften und Policies verwalten sowie andere DSM Verwaltungsaufgaben durchführen. Bei allen Entwicklungen ging es entweder um die Integration der Aufgabe in bestehende / neue Prozesse oder um die Automatisierung von Standardaufgaben.

Alle Programme wurden in C# mit Visual Studio als Entwicklungsumgebung erstellt.

Seit gut einem Monat bin ich Senior Consultant im Team der NWC Services GmbH und habe die PowerShell Extensions für DSM 7 (PSX) (https://www.nwc-services.de/produkte/psx) kennen gelernt, die viele unserer Kunden einsetzen. Mittlerweile sind die PSX zum Standard geworden, wenn Anforderungen, wie sie oben genannt sind, umgesetzt werden sollen. Aber was sind die Gründe dafür?       

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...

Mit dem Windows Server 2012 wurde unter anderem ein neues Feature namens „Data Deduplication“ eingeführt, mit welchem der Speicherbedarf eines Systems optimiert werden kann.

Da ich auf meinem Windows 8.1 Notebook aufgrund von diversen virtuellen Maschinen, ISOs, Test- und Schulungsumgebungen ebenfalls einen sehr hohen Speicherbedarf habe, würde mir dieses Feature für Windows 8.1 auch sehr gelegen kommen – was allerdings „Out-Of-The-Box“ nicht möglich ist. In diesem Blog möchte ich kurz zeigen, wie Sie Data Deduplication unter Windows 8.1 aktivieren können und wie viel Speicher damit eingespart werden kann.

Anfang des Jahres hat Immidio sein neues Helpdesk Support Tool released, was es ausgwählten Administratoren ermöglicht, Benutzereinstellungen wieder auf einen definierten Stand zurückzusetzen. Dieses Szenario ist eine immer wiederkehrende Anforderungen im täglichen Betrieb. Werden Benutzereinstellungen durch Störungen in der Infrastruktur oder durch falsche Bedienung durch den Benutzer selber zerstört, müssen diese komfortabel wieder hergestellt werden. Zwar existiert dazu das Flex+ Selfservice Tool, erfordert aber einen interaktiven Eingriff durch den Benutzer und somit auch mindestens eine angemeldete Benutzersession.