Problem

Zwei Benutzer müssen (abwechselnd oder gleichzeitig) auf ein Tool zugreifen das aus den 80ern stammt und nicht Netzwerkfähig ist. Ein Terminalserver lohnt dafür aber nicht und es muss auf jeden Fall dieser eine Rechner sein. Kommt bei Kartenlesern, Abrechnungssystemen und ähnlichem schon mal vor.

Lösung

Windows 8/8.1 (und Windows 10 bisher) lässt sich problemlos als Terminalserver für mehrere Benutzer verwenden. Das ist zwar (bestimmt) total illegal aber technisch erst einmal kein Problem. Selbstverständlich gibt es für diese Funktion keinen Support und das System ist immernoch ein Windows 8, kein Server. Mehr Serverrollen gibt es also nicht. Allerdings ist auch die Spiegelung von Sitzungen problemlos möglich.

Die einfachste Möglichkeit ist die RDP Wrapper Library. Die schaltet sich als zwischen den Servicehost und die termsrv.dll und manipuliert die Aufrufe entsprechend. Das System hat sich bisher als „Update-Sicher“ und äußerst stabil herausgestellt.

Problem

Im Windows Server 2012 hat Microsoft die Funktion „Remoteüberwachung“ zum spiegeln von Benutzern vollständig entfernt. Ob absichtlich oder Unfall – ärgerlich ist das allemal. Glücklicherweise wurde das „Spiegeln“ oder zu neudeutsch „Shadowing“ mit dem Server 2012R2 wieder eingeführt. Leider auch hier nicht über den schnellen Klick im Taskmanager, sondern an der Kommandozeile (und auf Terminalservern im Servermanager).

Lösung

Man benötigt zuerst die Sitzungs-ID der Session, die es zu spiegeln gilt:

Alle Sitzungen anzeigen

C:\>query USER  /SERVER:<SERVERNAME>

Bestimmte Sitzung anzeigen:

C:\>query USER <USERNAME> /SERVER:<SERVERNAME>

Mit der entsprechenden ID lässt sich die Session dann mit dem eingebauten RDP-Client spiegeln:

C:\>mstsc /shadow:<SessionID> /control

Bessere Lösung

Dieses Script automatisiert den Vorgang und lässt sogar das direkt Remote-Spiegeln zu. Es wird eine Liste der aktiven Sitzungen präsentiert und man tippt nur noch die Nummer ein.

Achtung, die Remote-Spiegelung (zum Beispiel von einem Admin-Client) funktioniert nur wenn der Server lizenziert (RDSCAL) ist. Lokal klappt das hingegen immer.

@echo off
title Remoteueberwachung
REM --- Wie heisst der Server?
set termserver=localhost

REM --- Session IDs auslesen
query session /server:%termserver% & echo.
set /p sessionid=Die Session-ID eingeben oder mit q Beenden ...
if %sessionid%==q @exit
start mstsc /v:%termserver% /shadow:%sessionid% /control

Problem

Der Windows 2008/2008R2 DNS-Server („dns.exe“) konsumiert ohne Ende Speicher. Der Server startet mit 120Mb, wächst auf über 400Mb und erreicht auch gerne über 1Gb RAM. Das ist für mittlere Netzwerke mit ein paar hundert PCs ein bisschen viel.

Lösung

Standardmäßig öffnet der Windows DNS-Server einen Pool von 5000 UDP sockets (2500 IPv4 und 2500 IPv6). Unter Windows Server 2008 R2 werden für jeden Port ~2.5Kb RAM allokiert, plus zusätzliche ~7.2Kb pro Empfanspuffer fällig – und es wird pro CPU ein Buffer erstellt. Auf Maschinen mit mehreren CPUs läpper sicht das schnell ordentlich zusammen:

(2.5kb x 5000 sockets) + (32 cpus/cores x 5000 sockets  x 7.2kb ) = (12500kb) + (1152000kb) = 1164500kb = ~ 1.1GB

Sinnvollerweise verringert man also die Anzahl der Sockets:

dnscmd /Config /SocketPoolSize 100

100 ist ein guter Wert (~250PCs). Die aktuelle Anzahl prüft man mit:

dnscmd /Info /SocketPoolSize

Um unter Windows die Auswahlmöglichkeiten aus dem „Senden an“ Menü der rechten Maustaste zu bearbeiten, sind nur wenige Handgriffe notwendig:

1. Ordner %appdata%\Microsoft\Windows\SendTo öffnen
2. Die gewünschte Verknüpfung erstellen

Mit Start > Ausführen > „shell:sendto“ kommt man da noch schneller hin (thx heiko)

Problem

Auf einem Server können keine neuen Volumenschattenkopie-Jobs angelegt werden („Das Volumen ist bereits vorhanden“), es können keine weiteren Schattenkopien für ein DPM-geschütztes Voume angelegt werden („Die Schattenkopie mit der ID xxxxxxxxxxxxx ist bereits vorhanden“) und/oder bestehende DPM-Jobs starten nach einem Volumenwechsel nicht mehr, weil die bestehenden Jobs auf das „alte“ Volumen zeigen („Es wurde bereits eine Schattenkopie mit der ID xxxxxxxxxxx gefunden“).

Lösung

Zuerst sind die bestehnden verwaisten Schattenkopien zu entfernen, dann das Ziel-Volumen (Shadowcopy-Storage). Es gibt mehrere Möglichkeiten die Einträge der Schattenkopie-Liste  eines Systems aufzuräumen.

1) Sofern die orginal-Volumenzuordnung noch existiert, ist es möglich aud der Liste der Schattenkopien die ID der betroffenen Kopie zu extrahieren:

vssadmin list shadows

Aus der ausgegebenen Liste nun einfach die Schattenkopie-ID kopieren und löschen:

vssadmin Delete Shadows /shadow={Schattenkopie-ID}

Zum Beispiel: vssadmin Delete Shadows /shadow={affeaffe-dead-beef-b444-dfafafafafdf}

2) Wenn Vssadmin dabei aber seltsame Fehler ausspuckt, hat die Zuordnung nicht (mehr) richtig funktioniert. Hier hilft es in der Regel, die betroffene Kopie direkt zu entfernen; dazu gibt es ein WMI-Interface für den VSS-WMI-Provider.

C:\>wmic
wmic:root\cli>shadowcopy list

Zeigt die vorhandene Liste an. Einzelne einträge kann man löschen. pro Eintrag erfolgt eine einzelne Abfrage:

C:\>wmic
wmic:root\cli>shadowcopy delete
"\\SERERNAME\ROOT\CIMV2:Win32_ShadowCopy.ID="{Schattenkopie-ID}" löschen (J/N/?)?

ACHTUNG! Obwohl Das Tool nach J/N fragt, wird ein „Y“ zum bestätigen benötigt *seufz*.

Wenn ein ganzes Volumen verwaist ist, zum Beisspiel wenn ein Admin darauf geschützte oder vom DPM als Ziel verwendete Partitionen entfernt, ist uns keine andere Möglichkeit bekannt, als dem Volumen eine neue Seriennummer zu geben. Das geht indem man das betroffene physikalische Array einfach löscht und neu erstellt, oder die Seriennummer einer neu erstellten NTFS-Partition mit „Volume-ID“ aus der Sysinternals-Trickkiste verändert:

C:\>volumeid T: f0000-ba00

ACHTUNG: Danach die Maschine neu starten und NICHT VERSUCHEN eine Schattenkpie anzulegen. Nach dem Neustart sollte das Volumen aus der VSS-Zielliste verschwunden sein. Das ist zu prüfen mit:

C:\>vssadmin list shadowstorage