„Früher war alles besser“ ist schätzungsweise eine passender Anfang für diesen Beitrag. Hintergrund ist, das ein Kollege sich danach erkundigte, warum eine „Zugriff verweigert“-Meldung auf seinem Windows Server 2012 R2 RDS-Host erscheint, wenn man als Benutzer versucht eine Nachricht an andere Benutzer zu schicken.
Der Hintergrund ist dort folgender, das eine Anwendung Meldungen bzw. Nachrichten an die Benutzer verschicken muss. Unter dem bisherigen Windows Server 2003 hatte das mittels Nachrichtendienst, den es im übrigen seit Windows Vista nicht mehr gibt, und dem Befehl „net send“ immer funktioniert.
„net send“ wurde durch „msg“ ersetzt (siehe dazu Net Send Ersatz) und Mitglieder der Administratoren-Gruppe können nach wie vor erfolgreich Nachrichten zustellen. „Zugriff verweigert“ bedeutet (fast immer) das eine Berechtigung fehlt. Bislang konnte man das unter „Konfiguration des Remotedesktop-Sitzungshosts“ in den Eigenschaften von „RDP-Tcp“ auf der Registerkarte „Sicherheit“ und deren Untermenüs konfigurieren. Easy sozusagen.
![RDP-Tcp - Sicherheit]()
Ab Windows Server 2012 fehlt dieser bekannte Dialog. Als Alternative wird das Setzen und Ändern von Berechtigungen mittels WMI genannt. Daran haben wir uns die vergangenen zwei Tage versucht. Dazu sei erwähnt, das wir in Sachen WMI nicht ganz firm sind (man hat’s halt kaum gebraucht), also wurde recherchiert und probiert, leider ohne ein positives Ergebnis. Dennoch nachfolgend die gegangenen Wege und Quellen. Gut möglich, das jemand noch eine Idee oder gar Lösung zu dem Thema hat (falls ja, her damit ;-)).
Rechercheergebnisse und Tests
Allem voran ist zunächst wichtig zu wissen, was es für Berechtigungen gibt, die man ändern könnte. Aufschluss gibt dazu Microsofts TechNet:
ModifyPermissions method of the Win32_TSAccount class
Man ist mit dem Problem nicht alleine, wie folgender Link zeigt. Dort wird mit Windows Server 2012 gearbeitet. Wir haben das dort aufzeigte PowerShell-Skript unter Windows Server 2012 R2 verwendet, aber leider ohne Erfolg:
server fault – windows server 2012 remote desktop – Send messages between standard users
Im Skript selbst wurde „BUILTIN\\Remote Desktop Users“ durch „VORDEFINIERT\\Remotedeskopbenutzer“ ersetzt, um der jeweiligen Sprachversion gerecht zu werden. Alternativ kann man die SID verwenden (siehe weiter unten). Interessant an dieser Stelle war, das wir bei „PermissionsAllowed“ statt „289“ wie im Thread immer nur, ganz gleich ob vorher oder nachher den Wert „433“ erhielten. Mit anderen Worten: Es wurde nichts geändert.
Nicht viel anders sah es mit dem von Configure „Permissions for Remote Desktop Services Connections“ via Policy or Script abgeleiteten Lösungsweg aus:
WMIC.exe /node:localhost /namespace:\\root\cimv2\TerminalServices PATH Win32_TSAccount where "(TerminalName='RDP-Tcp' or TerminalName='Console') and SID='S-1-5-32-555'" CALL ModifyPermissions TRUE,4
Dort haben für lediglich die vier (Shadowing) am Ende durch die sieben (Msg) ersetzt. Zur Sicherheit haben wir’s aber auch mit dem Original-Befehl versucht. Beides ohne Erfolg. Die angegebenen SID entspricht übrigens der lokalen Gruppe „Remotedesktopbenutzer“, diese ist auf allen Windows-Systemen identisch. Statt der SID kann man auch „AccountName=VORDEFINIERT\\Remotedesktopbenutzer“ verwenden.
Versucht man die genannten Lösungswege auf einen Domänen-, lokalen Benutzer oder schlicht einer anderen Gruppe anzuwenden, so erhält man die Meldung „Keine Instanzen“. Fragt man mit dem Beispielsskript von Win32_TSAccount – WMI sample in VBScript ab, so erhält man als Ausgabe alle vordefinierten Gruppen, aber es werden keine anderen Gruppen oder Benutzer, ganz gleich ob lokal oder aus der Domäne, angezeigt.
Weitere Skripte die wir zumindest in Teilen ausprobiert haben sind:
Configure Guest OS for Microsoft VDI (VB Script)
Configure connection security, in the Scripting / Automation forum on BrianMadden.com
Diese sind allerdings schon etwas älter und für andere Windows-Versionen (und Umgebungen) geschrieben worden. So muss z.B. „root\cimv2″ durch „root\cimv2\terminalservices“ ersetzt bzw. ergänzt werden, das kommt dann aber auch wiederum auf den Kontext darauf an.
Der Vollständigkeit halber sei erwähnt, das man auf grafischen Wege mittels „wbemtest“ sich in WMI durchhangeln kann:
Configuring Terminal Services with WMI
Noch „gruseliger“ wird das Thema, wann man am Ende des Beitrags Windows 8.1 / Windows Server 2012 R2 – RDS Shadowing is back! folgendes liest:
„Only an administrator may shadow sessions. The ability to shadow sessions cannot be delegated to users that are not part of the administrators group.“
Negativ fällt auf, das es nur Administratoren möglich ist Sitzungen spiegeln zu können und man könnte das Ganze dann auch im Kontext dieses Beitrags so deuten, das es eben nicht mehr vorgesehen ist, das zu ändern.
Fazit
Kurzum: Schlecht. Es kommt zwangsläufig die Frage auf, was man sich in Redmond dabei gedacht hat, eben solche bislang relativ einfach zu deligierenden Dinge abzuschaffen. Der Fauxpas begann bereits mit Windows Server 2012 als überhaupt kein Spiegeln von Sitzungen mehr möglich war, mit dem R2 kam die Funktion dann glücklicherweise wieder zurück.
Mir persönlich stellt sich die Frage, wie ich mittelfristig den Kunden, die dann irgendwann von Windows Server 2008 R2 auf die zum jeweiligen Zeitpunkt aktuelle Windows Server-Version umsteigen erklären soll, das deren hausinternen Supporter nun administrative Rechte auf den Terminalserver benötigen, um Nachrichten abzusetzen oder Sitzungen spiegeln zu können.
Bleibt zu hoffen, das es (vielleicht) ab Windows Server 2016 wieder aufwärts geht in diesem Bereich.
P.S.: Wie bereits erwähnt ist unklar, ob wir noch etwas übersehen oder gar falsch gemacht haben, Feedback ist auf jeden Fall willkommen.
Öffnet man “das neue Programm” (Doppelklick), erscheint folgendes Fenster:
Herunterladen kann man also noch nicht, lediglich reservieren. Nun gibt es letzte Gewissheit mit dem eingangs erwähnten Update, das es eben im weitesten Sinne Werbung einblendet.
