Manchmal ist die Sache einfacher, als zunächst angenommen. Möchte man CrystalDiskInfo bei der Anmeldung ausführen, genügt es unter „Optionen – Mit Windows starten“ zu aktivieren.

Tipp: Möchten man CrystalDiskInfo minimiert starten, muss der Haken bei „Optionen – Im SysTray anzeigen“ gesetzt sein.

Daraufhin wird automatisch im Hintergrund eine Aufgabe angelegt, die bei der Anmeldung des Benutzers ausgeführt wird. Da in dieser Aufgabe der Haken bei „Mit höchsten Priviligien ausführen“ gesetzt ist, erscheint zudem keine Benutzerkontenabfrage.

Das Ganze gelingt allerdings nur, wenn der angemeldete Benutzer administrative Berechtigungen hat.

Was ist, wenn der Benutzer keine Administrator-Rechte hat?

Hat der Benutzer keine administrativen Rechte, kann die Aufgabe so wie sie von CrystalDiskInfo erstellt wird, nicht ausgeführt werden:

Lösen lässt sich das, wenn man über Drittanbieter-Tools dafür sorgt das CrystslDiskInfo dennoch mit erhöhten Rechten bzw. als Administrator ausgeführt wird. Als quick’n’dirty-Lösung beispielsweise mit MiniRunAs. Man erstellt ein simples Skript wie dieses:

@echo off

cd "C:\Tools\CrystalDiskInfo"

miniRunAs.exe Administrator <Kennwort> DiskInfo64.exe /Startup

Und lässt es dann als Aufgabe bei Anmeldung ausführen.

Das Skript sollte natürlich vor neugierigen Augen geschützt werden, damit nicht jeder an das Administrator-Kennwort gelangt. Dies gelingt in dem man es in einem Ordner ablegt und auf diesem Ordner die Rechte für „Otto-Normal-Benutzer“ dahingehend einschränkt, das zwar die Aufgabenplanung laufen kann, aber nicht der Dateiinhalt eingesehen werden kann. Anbei stichpunktartig die notwendigen Schritte:

• Auf Ordner-Ebene die Vererbung deaktivieren.
• „Benutzer“ und „Authentifizierte Benutzer“ die Rechte auf den Ordner und seinen Inhalt entziehen (die entsprechenden Gruppen entfernen).
• Nur dem Benutzer bzw. besser der gewünschten Gruppe auf Ordnerebene das (erweiterte) Recht „Ordner durchsuchen / Datei ausführen“ erteilen.

Quelle: Dr. Windows – Datei ausführbar, aber nicht lesbar machen

Troubleshooting

Klappt es auf Anhieb nicht, das CrystalDiskInfo via Aufgabe gestartet wird, kann es helfen, eine Verzögerung einzustellen. Dazu die Aufgabe editierien, auf die Registerkarte „Trigger“ wechseln, doppelt auf „Bei Anmeldung eines Benutzers“ klicken und bei „Verzögern für“ z.B. ein bis zwei Minuten eintragen.

Danksagung

Danke an Bernd für die Inspiration zu diesem Beitrag.

So manches Programm lässt sich bei Windows 10 – 1809 mittels „Als Administrator ausführen“, runas oder Drittanbietertools wie z.B. MiniRunAs nicht mehr ausführen. Bis Windows 10  – 1803 funktionierte das noch ohne Schwierigkeiten.

Die Fehlerbilder reichen von das überhaupt nichts passiert bis hin z.B. bei runas in der Eingabeaufforderung diese Meldungen erscheinen:

• 5: Zugriff verweigert
• 740: Der angeforderte Vorgang benötigt erhöhte Rechte

Offenbar hat Microsoft eine (Vor-)Einstellung verändert. Unter Windows 10 Pro kann man via Gruppenrichtlinie Abhilfe schaffen:

• Den Gruppenrichtlinien-Editor öffnen.
• Zu „Computerkonfiguration – Windows-Einstellungen – Sicherheitseinstellungen – Lokale Richtlinien – Sicherheitsoptionen“ wechseln.
• Dort die Richtlinie „Benutzerkontensteuerung: Administratorgenehmigungsmodus für das integrierte Administratorkonto“ auf „Deaktiviert“ setzen.

In einer Domäne führt das allerdings zu anderem Ungemach, siehe dazu:

Windows 10: Domänen-Administrator hat keine ausreichenden Berechtigungen

Außerhalb der GPO kann man die Einstellung manuell in der Registry, via *.reg-Datei

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"FilterAdministratorToken"=dword:00000000

oder per Befehl ändern:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v FilterAdministratorToken /t REG_DWORD /d 0 /f

P.S.: Windows 10 Home wurde nicht getestet.

Update 28.02.2019

Der oben genannte Weg funktioniert bei stand-alone Computern mit dem Buildin-Administrator. Hat man allerdings zusätzliche angelegte Administratoren, kommt es dennoch zu Fehlern. Theoretisch könnte die Richtlinie

Benutzerkontensteuerung: Alle Administratoren im Administratorgenehmigungsmodus ausführen

auf „Deaktiviert“ zu setzen helfen, allerdings hat dies der Beobachtung nach sehr viele negative Auswirkungen. So klappte zwar die Ausführung von runas und MiniRunas, allerdings funktionierte dann „Als Administrator ausführen“ und z.B. entsprechend markierte Punkte in der Systemsteuerung (die erhöhte Rechte erfordern) nicht mehr. Vermutlich betrifft das auch weitere Punkte im System.

Von daher ist dieser Weg über die letztgenannte Richtlinie aktuell nicht zu empfehlen.

Bekanntlich lässt sich bei Microsoft’s runas-Befehl kein Kennwort mitgeben. Versuche dies mittels echo zu tun scheitern bei aktuellen Versionen.

Sofern runas grafisch sichtbar ausgeführt wird, kann mittels Unipass die Eingabe des Kennworts automatisiert werden. Damit das gelingt, bemüht man ein kleines Skript, da Unipass einen Fenstertitel benötigt. Anbei ein Beispiel:

@echo off
start UniPass_x64.exe RunAs-Window Geheim

title RunAs-Window

runas /noprofile /user:"%computername%\administrator" "C:\Program Files (x86)\FreeCommander XE\FreeCommander.exe"

Die Microsoft Produktaktiviererei kann eine lästige Angelegenheit sein, vorallem immer dann, wenn es nicht klappt.

So brauchte ich vor gut drei Wochen fast einen kompletten Arbeitstag um ein Office 2016 Home and Business zu aktivieren. Nach dem x-ten Anruf bei Microsoft und einem der vielen Support-Gespräche stellte sich damals heraus, das gerade Wartungsarbeiten durchgeführt werden und es wohl deswegen über Stunden nicht möglich war, das Produkt freizuschalten.

Ein anderes Ärgernis besteht darin, das es relevant ist, über welchen Vertriebskanal (ESD, Retail, …) Office bezogen wurde, welches Setup man verwendet und welches Setup mit welchem Produktschlüssel verwendet werden kann. Dies hängt immer mit dem Vertriebskanal zusammen. Hinzu kommt, das Product Key nicht gleich Product Key ist. Ein aktuelles Fallbeispiel:

Die Aktivierung eines Office 2019 Home and Business klappte zunächst nicht. Nach der Installation und beim ersten Start von Word wurde der Produktschlüssel abgefragt. Dieser wurde eingetragen, daraufhin erscheint folgender Dialog:

Ohne Konto geht es an dieser Stelle nicht weiter. Versucht man den Produktschlüssel via Eingabeaufforderung einzutragen erscheint diese Meldung:

C:\Windows\system32>cscript "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
Microsoft (R) Windows Script Host, Version 5.812
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

---Processing--------------------------
---------------------------------------
ERROR CODE: 0xC004F050
ERROR DESCRIPTION: The Software Licensing Service reported that the product key is invalid.
---------------------------------------
---Exiting-----------------------------

Liest man, das der Produktschlüssel ungültig ist, kommt man evtl. erst Mal auf den Gedanken, das etwas nicht stimmt. Dem ist allerdings nicht so. In diesem Fall handelt es sich um ein Retail-Office, dieses benötigt zwingend seit Version 2016 zur Aktivierung ein Microsoft (Live) Konto! Hat man keines, kann man ab dem dargestellten Dialog eines anlegen. Es muss nicht zwingend eine neue E-Mail-Adresse verwendet werden.

Ist das Konto angelegt und bestätigt, kann man die E-Mail-Adresse samt Kennwort eingeben und im Idealfall ist Office sofort freigeschaltet. Manchmal ist ein Neustart des Office notwendig, damit unter „Datei – Konto“ endlich „Produkt aktiviert“ angezeigt wird.

Der vom Händler erhaltene Product Key ist also nicht die eigentliche Lizenz, sondern dient lediglich dem Hinzufügen der Lizenz zum MS Konto. Daher die Aussage „Product Key ist nicht gleich Product Key“.

Für Microsoft bietet diese herangehensweise Vorteile, wird so doch recht effektiv unterbunden, das man ein Office-Paket, das man nicht mehr benötigt weiter veräußert wird, denn ein Herauslösen aus einem MS Konto ist laut Support nicht vorgesehen.

Tipp: Möchte man nicht, das nun (dauerhaft) die E-Mail-Adresse des „Aktivierungskontos“ angezeigt wird, kann man, sofern keine MS Dienste verwendet werden, unter „Datei – Konto“ dieses Konto abmelden.

Quelle:

Gebrauchtsoftware.de – Office 2016 Retail / OEM: Microsoft verbietet Installation ohne Live-Account 

Da es immer wieder Kommentare oder gar E-Mails zum Thema RDP Wrapper in Verbindung „geht nicht“ gibt, versuche ich mit diesem Beitrag eine Art zentrale Anlaufstelle (innerhalb dieses Blogs) dafür zu schaffen. Das bedeutet, wenn möglich soll der Beitrag weiter aktualisiert werden.

Zu Beginn ein wenig Historie und Hintergrund

Während RDP Wrapper beispielsweise unter Windows 7 lange Zeit ohne Updates auskam ist es bei Windows 10, aktuell allem voran bei 1809 leider ganz anders. Die Ursache ist dabei relativ einfach: Ändert Microsoft die „termsrv.dll“, das ist die Bibliothek die die Remotedesktopdienste realisiert, muss auch die „rdpwrap.ini“ des RDP Wrappers angepasst werden.

Zugegeben, leider kommen vom Macher des RDP Wrappers schon seit geraumer Zeit keine Updates mehr, daher nutzt es dann auch wenig wenn man die „update.bat“ ausführt, helfen tut dafür in der Regel die Community. Auf GitHub findet man unter Issues der Projektseite meist relativ schnell die notwendigen Änderungen, die man selbst per Hand einpflegen darf.

Als Alternative zum Aktualisieren der „rdpwrap.ini“ kann man ein Downgrade/Rollback der „termsrv.dll“ durchführen, damit der RDP Wrapper wieder läuft. Erwähnt wurde dies z.B. bereits hier:

Windows: Wenn RDP Wrapper nicht mehr funktioniert, ein Downgrade der termsrv.dll durchführen

Als auch in den Kommentaren zu

Windows Vista, 7, 8.x und 10 mit dem RDP Wrapper zum Terminalserver machen

Grundsätzlich muss man allerdings festhalten, das Microsoft jederzeit durch entsprechende Änderungen den RDP Wrapper (oder andere Lösungen dieser Art) unbrauchbar machen kann oder gar gänzlich diese „Option“ verbaut. Ferner stören sich zudem so manche Virenscanner am RDP Wrapper, das ist sogar verständlich, können solche Tools positiv wie negativ verwendet werden.

Zu Empfehlen vor dem Einspielen von Windows Updates, nicht nur wegen dem RDP Wrapper, ist ein Backup anzulegen oder z.B. in einer virtuellen Maschine zunächst zu prüfen, ob alles nach der Installation der Updates noch so läuft, wie es soll.

Das häufigste Problem lösen: Nach Windows Update funktioniert der RDP Wrapper nicht mehr, die „RDPconf.exe“ meldet „unsupported“.

I.d.R. habe ich fast ausschließlich mit Windows 7, 8 und 10 in der Pro-Edition zu tun, von daher kann ich zu den Home-Editionen nicht allzuviel beitragen. Ferner sind die allermeisten Systeme mit 64-bit-Windows bestückt, 32-bit wäre damit ebenfalls quasi raus. Ferner verwende ich keine Test- oder Vorabversionen von zukünftigen Windows 10 Builds. Was den RDP Wrapper betrifft greife ich immer zur ZIP-Datei, die MSI habe ich noch nie verwendet (oder es ist solange her, das ich mich nicht mehr daran erinnern kann).

Meldet die „RDPconf.exe“ bei „Listener state“ ein „[not supported]“ liegt das an einer Version der „termsrv.dll“ die bislang nicht unterstützt wird und folglich ein Update der „rdpwrap.ini“ notwendig ist.

„rdpwrap.ini“ aktualisieren

Die „rdpwrap.ini“ findet sich unter „C:\Program Files\RDP Wrapper“. Diese kann mit einem einfachen Text-Editor wie dem Windows-Bordmittel Notepad oder externen Tools wie z.B. Notepad++ editiert werden. Es werden erhöhte Rechte benötigt.

In der Regel müssen nur weitere Zeilen für die neu zu unterstützende „termsrv.dll“-Version am Ende der Datei hinzugefügt werden.

Wichtig: Ganz am Ende der „rdpwrap.ini“ muss eine Leerzeile sein! Andernfalls funktioniert es nicht (mehr).

Damit die Änderung direkt an der Datei vorgenommen werden kann, muss der Dienst „Remotedesktopdienste“ beendet sein. Gleiches gilt, wenn man die Datei ersetzen möchte.

Wichtig: Führt man diese Änderung bereits über eine RDP-Verbindung durch und es geht irgendetwas schief, sperrt man sich aus! Ein Plan B um z.B. mittels VNC, TeamViewer, PsExec oder direkt an der Konsole Zugriff zu haben ist also wärmstens zu empfehlen!

Anbei nun ein Beispiel von der Installation bis zum Updaten des RDP Wrappers:

System: Windows 10 Pro – 1809 – Build 17763.348
Die Version der „termsrv.dll“ lautet: 10.0.17763.292

Ist der RDP Wrapper noch nicht installiert, sieht die Ausgabe von „RDPconfig.exe“ so aus:

Nach dem Ausführen des „install.bat“ sieht es so aus (daran ändert auch das Ausführen der „update.bat“ nichts):

Das wäre soweit der klassische Fall, das eine „termsrv.dll“-Version nicht unterstützt wird. Für die angezeigte Version findet sich die Lösung unter

Add support for build 10.0.17763.292 #645

in der Antwort von RoosterIllusion und von ditchmagnet. Letzerer bietet sogar eine fertige „rdpwrap.ini“ zum Download an. Das Archiv entpacken, den Dienst „Remotedesktopdienste“ beenden, die Datei unter „C:\Program Files\RDP Wrapper“ ersetzen und den Dienst wieder starten.

Das Ergebnis von „RDPconf.exe“ nach diesem Eingriff sieht so aus:

Damit sind die grundsätzlichen Voraussetzungen für den (Weiter-)Betrieb des „Quasi-Terminalserver“ geschaffen.

Vergleich der original und der aktualisierten „rdpwrap.ini“

Mit Tools wie WinMerge lässt sich leicht ermitteln, was es für Differenzen zwischen zwei Dateien gibt. Nachfolgend als Screenshot der Vergleich zwischen Original (links) und Fälschung ähm Update (rechts):

Letztlich wurden für diese Version nur die folgenden Zeilen eingefügt:

[10.0.17763.292]
; Patch CEnforcementCore::GetInstanceOfTSLicense
LocalOnlyPatch.x86=1
LocalOnlyOffset.x86=AFAD4
LocalOnlyCode.x86=jmpshort
LocalOnlyPatch.x64=1
LocalOnlyOffset.x64=77A11
LocalOnlyCode.x64=jmpshort
; Patch CSessionArbitrationHelper::IsSingleSessionPerUserEnabled
SingleUserPatch.x86=1
SingleUserOffset.x86=4D665
SingleUserCode.x86=nop
SingleUserPatch.x64=1
SingleUserOffset.x64=1322C
SingleUserCode.x64=Zero
; Patch CDefPolicy::Query
DefPolicyPatch.x86=1
DefPolicyOffset.x86=4BE69
DefPolicyCode.x86=CDefPolicy_Query_eax_ecx
DefPolicyPatch.x64=1
DefPolicyOffset.x64=17F45
DefPolicyCode.x64=CDefPolicy_Query_eax_rcx
; Hook CSLQuery::Initialize
SLInitHook.x86=1
SLInitOffset.x86=5B18A
SLInitFunc.x86=New_CSLQuery_Initialize
SLInitHook.x64=1
SLInitOffset.x64=1ABFC
SLInitFunc.x64=New_CSLQuery_Initialize

[10.0.17763.292-SLInit]
bInitialized.x86 =CD798
bServerSku.x86 =CD79C
lMaxUserSessions.x86 =CD7A0
bAppServerAllowed.x86 =CD7A8
bRemoteConnAllowed.x86=CD7AC
bMultimonAllowed.x86 =CD7B0
ulMaxDebugSessions.x86=CD7B4
bFUSEnabled.x86 =CD7B8

bInitialized.x64 =ECAB0
bServerSku.x64 =ECAB4
lMaxUserSessions.x64 =ECAB8
bAppServerAllowed.x64 =ECAC0
bRemoteConnAllowed.x64=ECAC4
bMultimonAllowed.x64 =ECAC8
ulMaxDebugSessions.x64=ECACC
bFUSEnabled.x64 =ECAD0

Zugriffsrecht erteilen

Damit Nicht-Administratoren via Remotedesktop zugreifen dürfen, müssen diese Mitglied der Gruppe „Remotedesktopbenutzer“ sein. Es gibt mehrere Wege die Benutzer dieser Gruppe zuzuweisen:

Der Klassiker wäre:

Computerverwaltung - System - Lokale Benutzer und Gruppen - Gruppen

In der Eingabeaufforderung mit

net localgroup Remotedesktopbenutzer <Benutzername> /add

Weitere Probleme:

Firewall

RDP Wrapper richtet bei der Installation eine Regel in der Windows-Firewall ein, die den Zugriff zulässt. Verwendet man eine Firewall von einem Drittanbieter, so müssen dort ggf. die Ports 3389/tcp und 3389/udp freigegeben werden.

Nach der Deinstallation von RDP Wrapper funktioniert RDP überhaupt nicht mehr

Bei der Deinstallation wird RDP deaktiviert, man kann es ganz einfach wieder aktivieren.

Windows 10 Kuriositäten

Ob RDP aktiv ist oder nicht, sollte man einfach via Einstellungen oder Systemsteuerung klären können. Bei meinem Testsystem fiel mir folgendes auf:

Hinweis am Rande: RDP Wrapper ist installiert und funktioniert. Warum unter „Einstellungen – System – Remotedesktop“ allerdings Remotedesktop als „Aus“ angezeigt wird und unter „Systemsteuerung – System – Remoteeinstellungen“ als aktiviert bleibt offen.

Wenn man Hilfe benötigt

Grundsätzlich muss man folgende Angaben parat haben:

• Windows-Version und -Edition, Beispiel: Windows 10 Pro – 1809, idealerweise mit Build-Nummer
• Version der „termsrv.dll“ (kann via „RDPconf.exe“ ermittelt werden)
• Status des RDP Wrapper (gemeint ist das was die „RDPconf.exe“ anzeigt)
• Genaue Fehlerbeschreibung und zwar so, das man das Vorgehen reproduzieren kann! Einfach zu schreiben „geht ned“ hilft nicht.

Die erste Anlaufstelle bei Schwierigkeiten ist die „RDPconf.exe“, steht da schon ein „unsupported“, „not installed“, „stopped“, „not listening“ o.ä. ist das schonmal ungut. Als nächstes lohnt ein Blick auf die Issues-Seite des RDP Wrapper.

Neulich meldete sich ein Kunde, das er plötzlich weder Drucken noch Scannen könnte. Geändert hatte sich nichts, auch keine Updates etc. Es ging vom einen auf den anderen Tag nicht mehr.

Das Gerät ist via Netzwerkkabel angeschlossen und über’s Netzwerk auch einwandfrei erreichbar, Ping als auch der Zugriff auf das Web-Interface sind tadellos. Virenscanner (G Data) schlossen wir als erstes nach der grundsätzlichen Konnektivitätsprüfung als Ursache aus.

„Interessant“ wurde es über das Canon IJ Network Device Setup Utility, das beständig behauptete, es gäbe keine Netzwerkverbindung:

Drucken konnte reanimiert werden, in dem man den Anschluss von WSD-irgendwas auf TCP/IP umstellte. Beim Scannen gab es leider keine funktionierende Alternative.

Der Canon-Support benötigte jenseits der ersten Kontaktaufnahme und dem üblichen ersten Blabla (Installieren sie die neuesten Software, prüfen sie die Verbindung, …) drei Wochen um eine weitere Antwort zu senden, die dann lautete: Wir können das Problem nicht nachstellen, prüfen sie die Netzwerkverbindung.

In solchen Momenten möchte man in die Tischplatte beißen.

Vom Hersteller hat sich im übrigen nie jemand das Problem mal direkt auf dem betreffenden Windows 10-Computer angesehen, es gab auch kein Log oder sonstige Diagnose-Tools die man hätte verwenden können. Enttäuschend.

Jedenfalls nach ein paar Tagen lief es plötzlich wieder, woran es lag oder wie lange es nun gut geht kann man nicht sagen. Naheliegend das es an der WSD-Schnittstelle liegt. Schaut man im Netz, ganz gleich zu welchem Hersteller, findet man weitere Probleme in dieser Richtung.

Das gleiche Problem begenete mir bereits vor zwei Jahren bei einem anderem Kunden, seinerzeit mit Windows 7, eine Lösung gab es damals ebenfalls nicht. Drucken lief dort ebenfalls nur noch via TCP/IP. Scannen klappte wenigstens an einem von fünf PC noch. Letztlich wurde Canon, nicht nur deswegen, verbannt und durch Brother ersetzt.

Vor Jahren hatte ich zudem oft bei HP und solchen Problemen zu kämpfen, allerdings weiß ich nicht mehr, ob es da schon WSD war, die alte Software war gruselig, der Support aber wenigstens bemüht die Probleme zu lösen. Bei neueren Geräten (inkl. neuere Software) war’s dann besser.

Auf der anderen Seite hatten wir noch nie Probleme in der Art mit Geräten von Epson (gilt für WorkForce- und AcuLaser-Modelle).

Bei einem Kunden läuft unter anderem ein Debian 9 Stretch als virtuelle Maschine unter Hyper-V auf Basis eines Windows Server 2012 R2. Leider ist „ab Werk“ die Auflösung an der Konsole größer, als das Display bzw. via RDP und so darf man mitunter etwas Scrollen.

Es geht zwar „nur“ um ab und an jenseits von ssh etwas tippen zu können, da kein Desktop zum Einsatz kommt. Spätestens beim Editieren von Konfigurationsdateien mittels nano wird’s dann lästig die Bildlaufleisten bemühen zu müssen.

Ändert lässt sich die Auflösung durch eine Ergänzung der GRUB-Konfiguration (alle Befehle als root ausführen):

• nano /etc/default/grub
• Die Zeile „GRUB_CMDLINE_LINUX_DEFAULT=“quiet“ um „video=hyperv_fb:<Auflösung>“ erweitern. Diese sieht dann z.B. so aus:

  GRUB_CMDLINE_LINUX_DEFAULT="quiet video=hyperv_fb:1024x768"

• grub-update
• reboot

Zur besseren Veranschaulichung noch ein Screenshot:

Diese Lösung funktioniert laut den Kommentaren der Quelle (s.u.) ebenso mit anderen Distri’s wie z.B. Ubuntu und Derivate, RedHat, Fedora, usw.

Quelle:

Ben Armstrong’s Virtualization Blog – Changing Ubuntu Screen Resolution in a Hyper-V VM

In der Voreinstellung von Windows sollten Festplatten nach 20 Minuten der Inaktivität schlafen gehen. Das klappt nicht immer und kann verschiedene Gründe haben.

Grundsätzlich lässt sich sowohl unter Linux als auch unter Windows (und unter BSD sowie macOS) mit folgenden Tools der aktuelle Status der Festplatte ermitteln:

hdparm -C /dev/sdb
smartctl -n standby /dev/sdb

Zusätzlich kann man mit hdparm eine Festplatte manuell schlafen legen:

hdparm -y /dev/sdb

Den Status abzufragen hilft dabei zu Überprüfen, ob die Energiespareinstellungen überhaupt greifen. Bei Laufwerken kommt erschwerend hinzu, das Zugriffe als auch Treiberfehler den Wechsel in den Standby verhindern.

Unter Windows kann z.B. der ProcessMonitor mit einem gesetzten Filter für das gewünschte Laufwerk dabei helfen, festzustellen, welche Zugriffe stattfinden und so das Energiesparen verhindern:

Zu bedenken gilt allerdings, das nicht jeder Zugriff das Aufwachen (spinup) verursacht. Die im Screenshot zu sehenden Zugriffe durch Explorer oder Panda (AgentSvc.exe) lösen keinen Moduswechsel aus. Automatische Wartung wie z.B. chkdsk (Datenträgerprüfung) und defrag (Defragmentierung) hingegen schon.

Weitere Beispiele für ungewolltes Aufwachen der Festplatte

Bei meinem Heimserver sorgte wiederum ein aktiviertes UPnP des DVBViewers dafür, das die Datenplatte immer wieder aufwachte. Beim Test sorgten Tools wie HWiNFO oder CrystalDiskInfo ebenfalls dafür, das die Festplatte erst gar nicht in den Standby wechselte.

Tricky können manche Versionen von Intel-Festplattencontroller-Treiber (Intel Rapid Storage Technology, RST) sein, die einen Bug enthielten, durch den die Festplatte erst gar nicht schlafen ging. Ein Wechsel zum Microsoft-eigenen Treiber hilft mitunter.

Plan B wenn die OS-Bordmittel zum Energiesparen streiken

Auf einem Windows Server 2012 R2 Standard, der Hauptsächlich als Datengrab läuft, sollte die Datenplatte (neben der SSD für’s OS gibt es tatsächlich nur diese Eine, kein RAID) sich schlafen legen. Leider klappte es trotz entsprechender Einstellung in den Energieoptionen, Intel-Treiber up-/downgrade als auch mit dem Microsoft-Treiber einfach nicht. „Verdächtige Zugriffe“ konnten ebenfalls nicht ausgemacht werden.

In solchen Fällen kann man mittels hdparm versuchen einen Timer für das Abschalten der Platte zu setzen:

hdparm -S 240 /dev/sdb

Das wären die 20 Minuten. Doch dies half beim betreffenden System nur zum Teil. Soll heißen: Zwar ging die Platte nun immer mal wieder in den Standby, dieser dauerte aber meist nie allzulange, mal nur 5, 10 oder evtl. auch mehr mehr Minuten.

Da häufige Spinup’s und -downs sowohl für den Energieverbrauch als auch für die Lebensdauer der Festplatte kontraproduktiv sind, blieb in diesem Fall keine andere Wahl über, als sie doch einfach durchlaufen zu lassen.

Quellen:

hdparm

HDPARM TOOL FOR WINDOWS

smatmontools

superuser – See if HDD is in Sleep Mode for Windows (enthält auch Beispiele für WMI und PowerShell)

LUI – Festplatten automatisch im Betrieb in den Standby schalten

howtoeverything – List Of Timeout Values For „hdparm -S“

Für die Neuinstallation oder per Softwareverteilung ist es hilfreich Schritarten per Befehl oder Skript installieren zu können. Unter Windows sind im Grunde nur zwei Schritte notwendig.

Ein simples Kopieren der Schriftartdatei nach „C:\Windows\Fonts“ reicht nicht aus. Die Schriftart muss dem System noch bekannt gemacht werden. Daher werden zwei Schritte für die Einrichtung benötigt. Als Beispiel dient der berühmt-berüchtigte Code 128 der beispielsweise für die PDFs vom Zoll benötigt wird.

copy code.ttf %systemroot%\fonts
reg import Code128.reg

Für beides benötigt man administrative- bzw. erhöhte Rechte.

Der Inhalt der Registry-Datei sieht wie folgt aus:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"Code-128 (TrueType)"="code.ttf"

Wie genau die Registry-Einstellungen aussehen, ermittelt man am besten auf einem System, bei dem die Schriftart bereits installiert wurde.

Quellen:

ITProToday – How can I install a font from the command line/batch file?

superuser – How do I install a font from the Windows command prompt? (enthält ein Beispiel mit VBS)

Microsoft TechNet – Richard Spitz – How to install a font from the command line on Windows 7 (ebenfalls VB Script)

Wer Windows 10-Funktionsupdates (aka Upgrade) mittels WSUS verteilen möchte, dem begegnet evtl. folgende Meldung:

Funktionsupdate für Windows 10 (Anwender-Editionen), Version 1809, de-de
Ereignis berichtet um 26.02.2019 08:30:
(Die Ressource wurde nicht gefunden.:) ReportingEvent.Client.167; Parameter: Funktionsupdate für Windows 10 (Anwender-Editionen), Version 1809, de-de

Die Windows 10-Clients können das Upgrade nicht vom WSUS herunterladen. Dies kommt dadurch Zustande, das der IIS den MIME-Typ „.esd“ nicht kennt. Typischerweise ist das bei WSUS-Servern auf Basis von Windows Server 2012 R2 und früher der Fall. Windows Server 2016 und neuer sind davon ausgegnommen.

Man muss lediglich kurz den fehlenden Eintrag hinzufügen und schon läuft’s:

• Den „Internetinformationsdienste (IIS)-Manager“ öffnen.
• Auf „MIME-Typ“ klicken.
• Auf „Hinzufügen“ klicken.
• Bei „Dateinamenerweiterungen“ „.esd“ und bei „MIME-Type“ „application/octet-stream“ eintragen und mit „OK“ bestätigen.

Beim Kunden war kein Neustart des IIS-Dienstes oder gar das Servers notwendig. Kaum war der MIME-Typ gesetzt fingen die Clients schon das Herunterladen an.

Quelle:

Windows-FAQ – Windows 10 Feature Updates mit WSUS verteilen (application/octet-stream)

Kurz notiert: Wer selbst nicht an all den möglichen Stellschrauben in Firefox für mehr Datenschutz drehen möchte, der kann auf fertige Einstellungen des Librefox-Projekts zurückgreifen.

Hierbei handelt es sich nicht um einen weiteren Fork der Firefox-Browsers, sondern lediglich um vorkonfigurierte Einstellungen. Einfach das aktuelle zum Betriebssystem passende Archiv herunterladen und den Inhalt in den Firefox-Ordner entpacken.

Tools zum sicheren Löschen gibt es sehr viele. Wenn’s schnell, einfach und auf Wunsch portable sein soll kann man auf Permadelete zurückgreifen.

Das Tool kann installiert, portable oder als App genutzt werden. Dabei ist es erfreulich kompakt und genial einfach. Zudem ist es open source. Einfach die zu löschenden Dateien oder Ordner auf das Programm ziehen, loslassen, den Vorgang bestätigen und das war’s dann auch schon. Hat man das Tool installiert, gibt es darüber hinaus noch einen Eintrag im Kontextmenü unter „Senden an“.

Das Setup oder die Portable-Ausgabe gibt’s auf GitHub:

https://github.com/DevelopersTree/permadelete/releases

Die Windows-App gibt’s zudem im Store.

Weitere Tools dieser Art:

Wer lieber eine, unter anderem, deutschsprachige Anwendung haben möchte kann den Alternate File Shredder (nicht getestet) ausprobieren. Diesen gibt es allerdings nur zum installieren.

Ebenfalls portable und open source wäre z.B. EraserDrop Portable.

Microsoft’s Office Suite für einen Terminalserver zu lizenzieren ist eine teure Angelegenheit, denn das nötige Nutzungsrecht gibt es erst ab Office 200xx Standard bzw. Professional Plus und diese gibt es wiederum nur im Rahmen eines Volumenlizenzvertrags ab OPEN NL mit Mindestabnahmemenge von fünf Lizenzen.

Zusätzlich kommt hinzu, das wenn Office auf einem Terminalserver installiert ist und somit quasi allen dortigen Benutzern zur Verfügung steht, für alle Benutzer, auch für die, die es gar nicht verwenden, lizenziert werden muss! Via Rechte oder SRP die mögliche Nutzung auf technischem Wege einschränken ist nicht Lizenzkonform.

Das ist besonders ärgerlich, wenn man nur für eine Mitarbeiterin Excel benötigt, wie es gerade bei einem Kunden der Fall ist, der Rest aber kein MS Office braucht.

Die bekanntesten MS Office-Alternativen sind aus der Historie heraus OpenOffice, das seit geraumer Zeit allerdings an Bedeutung verliert und sein aktuellerer und modernerer Fork LibreOffice. Beide laufen der Erfahrung nach gut, sowie im Allgemeinen wie auch im Speziellen auf Terminalservern. Aber was gibt es noch, wenn es um bessere Kompatibilität oder optische Ähnlichkeit zu MS Office geht?

Da wäre zum Beispiel noch SoftMaker Office bzw. FreeOffice (Versionsunterschiede). Dieses Produkt der Nürnberger gibt es seit vielen Jahren und das nicht nur für Windows! Es ist ebenfalls kompatibel sowohl zu den Redmonder Dateiformaten als auch zum Terminalserver (Systemvoraussetzungen). Die Lizenzierung ist wesentlich entspannter, da nur für die Nutzer, die es verwenden sollen bzw. müssen  jeweils eine Lizenz vorhanden sein muss. Die technische Beschränkung, wer das Office-Paket überhaupt ausführen kann bzw. darf ist via Rechte und/oder SRP gestattet.

Am Beispiel von FreeOffice wird man beim ersten Start sogar danach gefragt, wie die Oberfläche aussehen soll, dies kann jederzeit in den Einstellungen unter „Aussehen“ geändert werden. Zusätzlich steht bei SoftMaker Office dann noch ein „Dark Theme“ zur Verfügung. Bereits an dieser Stelle hat man mehr Auswahl als bei Microsoft, kämpfen selbst über 10 Jahre nach dem Wechsel zur Ribbon-Oberfläche so manche Anwender nach wie vor mit der Handhabung.

Nebenbei bemerkt: Wenn’s um Mail geht, kann man Outlook oft durch Thunderbird (ist samt Addon in SoftMaker Office enthalten) ersetzen. Es kommt wie bei anderen Office-Anwendungen immer darauf an, wie z.B. Abhängigkeiten von anderer Software, die MS Office voraussetzt und natürlich auch der Wille, sich etwas anderes anzuschauen und ggf. etwas umzugewöhnen.

Wenn es zwingend Microsoft sein muss, aber nicht unbedingt die aktuellste bzw. neueste Version, kann man sich im Gebrauchtmarkt umschauen und so günstig z.B. die vorige Version bekommen.

Ebenso wie Microsoft’s Office lässt sich Libre- als auch SoftMaker Office mittels Gruppenrichtlinien konfigurieren:

LibreOffice – Wiki – Deployment and Migration – Windows Group Policy ADMX files

SoftMaker Office – Tipps & Tricks: Installation – SoftMaker Office Professional 2018 mit administrativen Vorlagen konfigurieren

Ein weiteres Goodie ist, das man LibreOffice und Free-/SoftMaker Office portable nutzen kann:

FreeOffice – Tipps & Tricks: Portable Installation

SoftMaker Office – Tipps & Tricks: Installation – SoftMaker Office für Windows auf einem USB-Stick installieren

Und außerdem: Free- und SoftMaker Office gibt es für Windows, Mac, Linux und Android.

Randbemerkung: Ein Libre-, Free- und SoftMaker Office ist wesentlich zügiger installiert als ein MS Office, die Setups sind zudem wesentlich kompakter.

Kurzes Fazit

Günstiger fährt man mit den Alternativen allemal. Zudem sind sie i.d.R. schneller installiert und einfacher aktiviert. Ob’s für die eigenen Anforderungen und ggf. Gewohnheiten passt sollte vorab immer ein Test klären.

Quellen:

WindowsPro – Office 2016 und 365 für Remote Desktop Services lizenzieren

technikkram.net – Stolpersteine bei der Microsoft Office Lizenzierung auf Terminal Servern

Die beiden Office-Editionen von SoftMaker lassen sich mit Hilfe des im Lieferumfang enthaltenen Assistenten bequem Portable machen. Allerdings setzt das Tool ein Laufwerk voraus, es kann nicht einfach ein Ordner auf dem gleichen Laufwerk ausgewählt werden.

Mit einem kurzen Ausflug in die Eingabeaufforderung kann man einen Ordner als Laufwerk anlegen und in diesen dann Free- bzw. SoftMaker Office portable ablegen. Dies ist hilfreich wenn man z.B. aus einer virtuellen Maschine heraus den Vorgang durchführen möchte oder wenn man gerade keinen USB-Stick zur Hand hat. Ebenso kann dieser Trick dazu verwendet werden, dieses Portable Office später auf dem eigenen Cloudspeicher abzulegen. Anbei am Beispiel von SoftMaker Office 2018 eine Kurzanleitung:

• Eine Eingabeaufforderung mit erhöhten Rechten öffnen.
• Einen neuen Ordner mit „md C:\SoftMakerOfficePortable“ anlegen.
• Mit „subst A: C:\SoftMakerOfficePortable“ den zuvor angelegten Ordner als Laufwerk A: zur Verfügung stellen.
• Nun aus dem Startmenü unter Free- bzw. SoftMaker Office\Hilfsprogramme das Tool „SoftMaker Office 2018 auf USB-Stick installieren“ ausführen.
• Das zuvor angelegte Laufwerk A: auswählen und den Vorgang ausführen.
• Mit „subst A: /D“ wird das zuvor erstellte Laufwerk wieder entfernt und der Ordner kann beliebig verschoben werden.

Kurzer Link-Tipp: Möchte man mit Hilfe einer pfSense Werbung und potentielle Angriffe ausfiltern, ähnlich wie bei Raspberry Pi und dem pi-hole-Projekt, kann man sich von den Beiträgen von Marcel Stritzelberger inspirieren lassen:

Mit pfSense Werbung und potentielle Angriffe blockieren ala piHole

pfBlockerNG Whitelisting

Ich hatte leider noch keine Zeit und Muse das „Nachzubasteln“, lesen tut es sich auf jeden Fall gut.

Mitunter macht es (sehr viel) Sinn, einem Dienst, einer Anwendung, einem wie auch immer geartetem Prozess eine andere Priorität und die maximal zu verwendene Kerne bzw. CPUs zuzuweisen.

Als Fallbeispiel dient mein Heimserver zusammen mit DVBViewer und HandBrake (siehe dort das Update vom Update 09.11.2018). HandBrake wird automatisch nach einer Aufnahme als Aufgabe ausgeführt, um das Format zu ändern. Das spart Platz, aber während die Konvertierung läuft, kommt der kleine olle i3 ganz schön ins Schwitzen. Blöd, wenn dann noch etwas anderes laufen soll. Aber Abhilfe ist einfach: Das Tool soll sowohl mit niedrieger Priorität als auch nur eine gewisse Anzahl an Kernen verwenden. Via Batch lässt sich das für noch zu startenden Prozesse einfach mittels „start“ lösen:

start /wait /belownormal /affinity 7 "" "C:\Program Files\HandBrake\HandBrakeCLI.exe" --preset "Fast 720p30" -i %InputFile% -o %OutputFile%

„/belownormal“ führt mit der nächst niedrigeren Priorität als Normal aus und „/affinity 7“ bedeutet bei diesem System, das nur drei von vier Kernen benutzt werden sollen und dürfen.

Das Bestimmen der „Affinity“ fällt anhand der Tabelle unter

MS Docs – SQL – Installation – Configuration – Server Configuration Options – affinity mask

leichter.

Prüfen kann man den (Miss-)Erfolg z.B. mittels Task-Manager. Auf der Registerkarte „Leistung“ kann man beobachten, ob alle oder nur bestimmte Kerne aus- bzw. belastet sind. Auf der Registerkarte „Details“ kann man die Priorität sehen, sofern man zuvor die Spalte „Basispriorität“ eingeblendet hat.

By the way:

Bei bereits laufenden Prozessen kann man (natürlich) via Task-Manager händisch die Prio und Kerne/CPUs ändern (Registerkarte „Details“, Rechtsklick auf den Prozess und „Priorität festlegen“ bzw. „Zugehörigkeit festlegen“), automatisch geht das z.B. via WMI oder Powershell, siehe Quellen.

Quellen:

davychiu – Limit Handbrake Useable CPU Cores in Windows

superuser – Changing Windows process priority via command line

stackoverflow – Change affinity of process with windows script

Eigentlich war bzw. ist ein eigener Beitrag zu Remote Desktop Plus in der Mache. Bislang fand das Tool bereits im Beitrag Windows: RemoteApps für verschiedene Benutzer per Aufgabe automatisch starten und trennen – Der kurze Weg Erwähnung. Anbei nun eine (kurze) Info zur Möglichkeit das Tool via Kommandozeile und damit aus Skripten heraus steuern zu können.

Neben den bereits anderweitig beschriebenen Möglichkeit RDP-Sitzungen oder -RemoteApps automatisch starten zu lassen hat Remote Desktop Plus (kurz RDP+) noch die weiteren Vorteilen, das es eine recht umfangreiche Kommandozeile gibt. Hinzu kommen die Optionen sowohl ein Protokoll schreiben zu lassen als auch einen Rückgabewert zwecks weiterer Auswertung zu haben. Ein Beispiel:

rdp.exe /v:wts02 /u:Administrator /p:<Passwort> /batch /log:rdp.log /disconnect:15

Diese Anweisung verbindet automatisch den angegebennen Benutzer mit dem Terminalserver, das Ganze erfolgt als Skript („/batch“), wird protokolliert /“log…“ und nach 15 Sekunden wieder getrennt.

Das Log sieht beispielsweise so aus:

Date-Time;Local-Computer;Local-IP-Address;Windows-Version;Local-User;TS-Client-Name;TS-Client-IP-Address;Remote-Computer;Remote-Port;Remote-User;RDP-Version;RDC-Version;Password-Mode;Session-Type;Application
2019-03-19 04:15:02;SRV02;192.168.0.26;Microsoft Windows Server 2016 Standard;SRV02\Administrator;-;-;wts02;3389;WTS02\Administrator;7.0.1;10.0;Password;Normal;-

Man kann es also, dank CSV-Format, wunderbar in einer Tabellenkalkulation der Wahl auswerten, wie im Screenshot in LibreOffice’s Calc:

Das es sich um eine simple Text-Datei handelt, könnte man diese zudem mit weiteren Tools auswerten.

Das Name der Protokolldatei kann fest vorgegeben oder alternativ mit Variablen dynamisch erzeugt werden. Die Macher geben dazu folgendes auf ihrer Homepage an:

%s: Will be expanded to the server name you’re connecting to.
%u: Will be expanded to the username used to login to the remote computer.
%c: Will be expanded to the name of the local client computer. When starting RDP+ locally, this will be the same as %COMPUTERNAME%. When starting RDP+ from within a Terminal Server or Citrix session, %c will contain the computername of the originating client computer (i.e. %CLIENTNAME%).
%y: The 4-digit representation of the current year.
%m: The 2-digit representation of the current month.
%d: The 2-digit representation of the current day.

Example: rdp /log:%y%m%d-%s.log

Alternativ kann man mit dem Parameter „/eventlog“ entsprechende Einträge in das Windows-Ereignisprotokoll schreiben lassen.

Rückgabewerte (Errorlevel, Exit Code) liefert RDP+ nur wenn der Parameter „/batch“ gesetzt ist. Folgende Werte stehen zur Verfügung:

0: No errors.
1: General undefined error.
2: Specified connection file not found.
5: Target computer not in the list of allowed targets.
29: Cannot write to the log file.
30: Profile not found.
87: Invalid command line parameter or combination of command line parameters.
161: The format of the specified path is invalid (filename of the connection file, log file or command options file).
259: No responsive server found in the list (when using /lb).
2382: Invalid notation of the specified host name or IP address.
10060: Connection timed out to the specified server.
11001: Remote hostname not found.

Kurzum: Alles größer Null ist ungut.

Wichtig ist, das man RDP+ via „start“ ausführt, da sonst wenn das Programm z.B. bei irgendetwas ewig hängen bleibt oder die Verbindung ohne Timeout aufgebaut wird, man sonst unter Umständen nie einen Rückgabewert erhält. Ein Beispiel (Auszug aus einem Skript):

rem Sicherheits-Massnahme, fuer den Fall das rdp.exe im Fehlerfall haengen bleibt

echo timeout /t 60 > temp01.cmd
echo taskkill /im rdp.exe /f >> temp01.cmd
echo taskkill /im mstsc.exe /f >> temp01.cmd
echo exit >> temp01.cmd

start temp01.cmd

rem RDP+ ausfuehren
start /wait rdp.exe /v:wts02 /u:Administrator /p:<Passwort> /batch /log:rdp.log /disconnect:15

if %errorlevel% gtr 0 (
set mail=true
echo Fehler bei der RDP-Verbindung - Rueckgabewert: %errorlevel% >> e-mail.txt
echo. >> e-mail.txt
if exist rdp.log type rdp.log >> e-mail.txt
echo. >> e-mail.txt
)

Es wird zunächst ein weiteres Skript erstellt und gestartet („temp01.cmd“). Dieses hat die Aufgabe RDP+ und den abhängigen Mstsc zu beenden, falls beides länger als 60 Sekunden läuft.

Dann wird RDP+ gestartet, die Verbindung nach 15 Sekunden beendet und der Rückgabewert ausgewertet.

Auf diese Art lässt sich automatisiert die RDP-Verbindung testen und ggf. im Fehlerfall z.B. eine Alarmierung und weitere Massnahmen auslösen.

Unter Windows kann man in Batch-Skripten den Erfolg oder Misserfolg eines Befehls mit dem Rückgabewert (Errorlevel, exit code) feststellen. Mit entsprechenden Operatoren lässt sich das sogar noch einfacher umsetzen.

Statt auf die Art

befehl...
if %errorlevel% ...

zu hantieren, kann man mit einer bedingten Befehlsverkettung arbeiten. So stehen die Operatoren „&&“ dafür den zweiten Befehl nur bei Erfolg und „||“ nur bei Misserfolg auszuführen. Das Ganze lässt sich sogar miteinander kombinieren.

Ein Beispiel:

taskkill /im test123.exe && echo Prozess beendet || echo Prozess nicht gefunden oder Beenden fehlgeschlagen

Die Ausgabe im Erfolgsfall:

C:\Users\user>taskkill /im test123.exe && echo Prozess beendet || echo Prozess nicht gefunden oder beenden fehlgeschlagen
ERFOLGREICH: Ein Beendigungssignal wurde an den Prozess
"test123.exe" mit der PID 4376 geschickt.
Prozess beendet

Die Ausgabe bei Misserfolg:

C:\Users\user>taskkill /im test123.exe && echo Prozess beendet || echo Prozess nicht gefunden oder beenden fehlgeschlagen
FEHLER: Der Prozess "test123.exe" wurde nicht gefunden.
Prozess nicht gefunden oder Beenden fehlgeschlagen

Quellen:

stackoverflow – Killing a process in Batch and reporting on success

Wikibooks – Batch-Programmierung: Batch-Operatoren

Um bei den Pro (und höher) Editionen von Windows die Remote Desktop-Funktionalität zu aktivieren stehen mehrere Wege zur Auswahl.

Neben dem händischen Einschalten kann man in einer Domäne mittels Gruppenrichtlinie den Zugriff aktivieren. Als weitere Möglichkeiten stehen ein Eingriff in die Registry, Batch und Powershell zur Wahl.

Per Skript oder Befehl sieht die vermutlich einfachste Variante so aus:

rem RDP aktivieren

 reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

rem RDP deaktivieren

 reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 1 /f

Ein Neustart von Windows oder dem „Remotedesktopdienste“-Dienst ist nicht notwendig. Die Änderung greift sofort.

Allerdings genügt das bloße Aktivieren der RDP-Funktion nicht, denn die Firewall muss entsprechend konfiguriert sein. Entweder man nutzt die vordefinierte Regel(n) oder man legt eine neue an.

Im Nornalfall müssen die Regeln

Remotedesktop - Benutzermodus (TCP eingehend)
Remotedesktop - Benutzermodus (UDP eingehend)

für die gewünschte Netzwerkkategorie aktiviert werden.

Per vordefinierter Regelgruppe kann man RDP ebenfalls freischalten:

netsh advfirewall firewall set rule group="Remotedesktop" new enable=yes

Dies hat allerdings den Nachteil, das damit auch RDP für öffentliche Netze freigegeben wird. Bei Notebooks im Außendienst ist das durchaus nicht wünschenswert.

Quellen:

interface – How to Remotely Enable and Disable (RDP) Remote Desktop

m.a.x. it – Konfiguration der Windows Firewall per Kommandozeile

Wake on LAN funktioniert über’s Internet nicht, das gilt auch für VPN. Abhilfe kann man sich schaffen, in dem von einem (Dauer-)laufenden System aus z.B. der Arbeitsplatz gestartet wird.

Damit man nicht extra beispielsweise aus dem Web-Interface einer Securepoint UTM, einem bereits laufenden PC oder einem Server aus der eigentliche Ziel-Rechner gestartet werden muss, kann man sich relativ leicht behelfen. Vor Jahren habe ich eine Lösung für einen Kunden gebaut, die bis heute läuft und in der Zwischenzeit auch bei anderen Kunden Anwendung findet.

Der Ablauf ist dabei simple:

Auf dem sowieso immer laufenden Server wird ein Apache (oder anderer Webserver) betrieben. Mittels (automatischen) Aufruf eines Skripts wird der zu startende Computer per WoL eingeschaltet.

Am Bespiel von Apache (die Variante von Apache Lounge) sieht das so aus:

Unter „C:\Apache24\cgi-bin“ wird folgendes Batch-Skript und die wol.exe von Gammadyne hinterlegt:

@echo off

cd "C:\Apache24\cgi-bin"

REM echo %date% %time% - hello world >> test.txt

wol.exe <MAC-Adresse>

echo Content-type: text/plain

echo.

Wenn man erstmal nur testen möchte, kann man erstmal nur ein Protokoll schreiben lassen und die Zeile mit „wol….“ auskommentieren.

Ruf man mit einem Browser nun folgende URL auf:

http://<IP-des-Servers>/cgi-bin/<Skriptname>.cmd

wird das Skript ausgeführt. Eine weitere Konfiguration des Apache ist nicht notwendig.

Damit das Ganze vom VPN-Client aus anwenderfreundlicher ist, kommen ein paar kleine Skripte ins Spiel:

Der VPN-Client startet nach dem Aufbau der Verbindung automatisch das Skript „vwr.cmd“, dieses wiederum startet die „vwr.exe“:

@echo off

cd C:\VPN
vwr.exe

Die „vwr.exe“ ist ein kompiliertes AutoIt-Skript. Anbei der Quellcode:

; AutoIt TrayIcon ausblenden

#NoTrayIcon

; Include-Dateien

#include <GUIConstantsEx.au3>

; Konfiguration einlesen

$Host = IniRead("vwr.ini", "VPN", "Host", "error")
$Countdown = IniRead("vwr.ini", "VPN", "Time", "error")
$WoL = IniRead("vwr.ini", "VPN", "WoL", "error")

If ($Host="error") or ($Countdown="error") or ($WoL="error") then
MsgBox(16, "VPN", "Fehler beim Lesen der Konfiguration")
Exit
EndIf

; Wartezeit in Sekunden umrechnen
; 60000 ms = 60 Sekunden = 1 Min

$Countdown = $Countdown*60000/1000

; Prüfen, ob der Ziel-Host erreichbar ist, andernfalls diesen per WoL starten und warten

$Pong = Ping($Host, 1000)

If $Pong = 0 Then

; WoL auslösen
InetGet($WoL, "")

; Countdown-Timer
; Fenster erzeugen
GUICreate("VPN", 268, 55)
GUISetState(@SW_SHOW)
GUICtrlCreateLabel("Bitte warten, bis das der Arbeitsplatz-PC gestartet ist:", 10, 10)

While 1
GUICtrlCreateLabel ( $Countdown & " Sekunden", 10, 30)
$Countdown=$Countdown-1
If $Countdown=0 Then ExitLoop
; Pause von einer Sekunde
sleep(1000)
WEnd

; Fenster schliessen
GUIDelete() 

EndIf

; Remotedesktopverbindung aufbauen

Run("mstsc.exe arbeitsplatz.rdp")

In der „vwr.ini“-Datei wird die IP-Adresse des Ziel-Computers hinterlegt und der Webserver-Aufruf. Beispiel:

[VPN]
Host=192.168.2.36
Time=2
WoL=http://192.168.2.10:8080/cgi-bin/test.cmd

VWR steht übrigens für VPN, Wake on LAN und RDP.

Zunächst wird der Ziel-Computer angepingt, kommt keine Antwort, kann man davon ausgehen, das dieser heruntergefahren ist. Daraufhin wird der „WoL-Aufruf“ durchgeführt, eine vordefinierte Zeit (Time, 2 Minuten) gewartet und dann die RDP-Verbindung initiiert.

Während auf das Starten des Ziel-Computers gewartet wird, läuft ein sichtbarer Countdown ab.

Nebenbei bemerkt: Es gibt noch eine ältere Variante, bei der PHP zum Einsatz kam, evtl. reiche ich diese bei Gelegenheit nach. Das Ganze dürfte sich zudem leicht z.B. auf Linux adaptieren lassen.