Das man bei Terminalservern (aka Remote Desktop Session Hosts) mit Hilfe der Remoteüberwachung oder dem Spiegeln auf Benutzersitzungen zugreifen kann ist soweit nichts neues und bekannt. Man kann allerdings unter bestimmten Voraussetzungen z.B. auch auf die Konsolensitzung eines Clients zugreifen.

Mit RDP Wrapper oder ähnlichen Tools die RDP-Möglichkeiten von z.B. Windows 7 aufzubohren ist soweit nichts unbekanntes. Neu für mich war die Möglichkeit sich direkt auf die Konsolensitzung, d.h. die Anzeige die man sieht wenn man vor dem Computer sitzt, aufschalten zu können.

Voraussetzungen

Zuallerst muss (natürlich) die Remotedesktopverbindung zugelassen bzw. aktiviert sein. Dies wird jetzt einfach mal vorausgesetzt und weiter beschrieben.

ID ermitteln

Neben RDP Wrapper und Co. benötigt man zum Verbinden auf die Konsole oder eine andere RDP-Sitzung die ID. Auf Windows Servern und bei den Pro-Ausgaben von Windows 7 und neuer steht dazu der Befehl

query session

zur Verfügung. Die Home-Ausgaben kennen diesen Befehl nicht, die entsprechenden Dateien lassen sich zwar auffinden, aber eine Ausführung wird unterbunden. Abhilfe schafft der Task-Manager, wenn man auf der Registerkarte „Benutzer“ die Spalte „ID“ einblendet:

By the way: Ein „query session“ aus der Ferne auf eine Home-Ausgabe von Windows habe ich nicht zum Laufen bekommen. Daran änderte auch ein

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

Quelle: spiceworks – remotely Identifying a logged on user using CMD

und entsprechende Firewall-Konfiguration nichts. Denkbar, das es dennoch irgendwie möglich ist. Ich bilde mir ein, die Ausgabe kurz aufblitzen gesehen zu haben, leider war’s nicht umleit- oder eine Pause erfolgreich hinzufügbar.

Alternativ kann man LogonSessions von Sysinternals nutzen. Allerdings ist dieses Tool im Vergleich zu „query session“ und dem Task-Manager um einiges gemächlicher. Ferner muss man aus der Ausgabe dann noch den passenden Absatz heraussuchen:

[6] Logon session 00000000:00011ed2:
User name: <Computername\Username>
Auth package: NTLM
Logon type: Interactive
Session: 1
Sid: <SID>
Logon time: 09.10.2018 14:25:16
Logon server: <Logonserver>
DNS Domain: 
UPN:

Man sucht den Benutzernamen und „Logon type: Interactive“, „Session“ entspricht dann der ID.

Spiegeln zulassen

In der Voreinstellung wird das Spiegeln erst gestattet, nachdem der angemeldete Benutzer gefragt wurde und zugestimmt hat. Ändern lässt sich das entweder via Gruppenrichtlinie oder in der Registry:

Computerkonfiguration - Administrative Vorlagen - Windows-Komponten - Remotedesktopdienste - Remotedesktopsitzungshost - Verbindungen

Die Richtlinie „Regeln für Remotesteuerung von Remotedesktopdienste-Benutzersitzungen festlegen“ editieren:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"Shadow"=dword:00000002

Per Vorgabe kann nur der Administrator sich zu einer anderen Sitzung hinzuschalten. Ändern kann man dies wie folgt (ungetestet):

wmic /namespace:\\root\CIMV2\TerminalServices PATH 
Win32_TSPermissionsSetting WHERE (TerminalName=”RDP-Tcp”) CALL 
AddAccount “<Domain>\<Group>”,2

Quelle: Windows OS Hub – How to Shadow (Remote Control) a User RDP session on RDS Windows Server 2016 / 2012 R2

Firewall

Sofern über’s Netzwerk die Spiegelung erfolgen soll, muss neben dem RDP-typischen Port 3389/tcp und udp noch die folgenden Firewall-Regeln aktiv sein:

Datei- und Druckerfreigabe (SMB eingehend)
Remotedesktop - Schatten (TCP eingehend) (heißt ggf. auch RDP-Sitzungs-Agent

Soll aus einem anderen Subnetz, z.B. via VPN, die Spiegelung erfolgen, muss man dies in den Regeln auf der Registerkarte „Bereich“ unter „Remote-IP-Adresse“ einstellen.

Bei den Home-Ausgaben von Windows gibt es keine vorbereite Regel „Remotedesktop – Schatten“. Diese kann man selbst erstellen für die Anwendung

"%SystemRoot%\system32\RdpSa.exe"

und „TCP – Alle Ports“ zulassen.

Das eigentliche Spiegeln

Aus der Administrator-Sitzung wird der Zugriff auf eine Benutzersitzung bzw. die Konsole wie folgt eingeleitet:

mstsc /v:<Hostname/IP/localhost> /shadow:<ID> /control

Ohne Nachfrage, sofern die Vorkonfiguration stimmt, geht’s mit dem Parameter “ /noconsentprompt“.

Die Sitzung mit der ID „1“ ist dabei oft der erste angemeldete Benutzer und im Idealfall ist das auf/an der Konsole:

Das ist aber nicht immer so, von daher am besten vorher die richtige ID ermitteln.

Aus der Ferne ohne (!) vorige Anmeldung als Administrator klappt’s dann mit dem Anhängen von „/prompt“ und der Eingabe der Administrator-Zugangsdaten:

mstsc /v:<Hostname/IP/localhost> /shadow:<ID> /control /noconsentprompt /prompt

Die Testreihe

Nachfolgend die bislang getesteten Windows-Ausgaben:

Windows 7 Home Premium & Professional
Fehlermeldung „Spiegelfehler – Die auf diesem Server ausgeführte Windows-Version unterstützt das Spiegeln von Benutzern nicht“. Kurzum: Diesen Windows-Ausgaben fehlt die Möglichkeit zu Spiegeln. Das war bei beim Server-Pendant (Windows Server 2008) ebenfalls so.

Windows 8.1 (with Bing)
Funktioniert.

Windows 8.1 Pro
Ungetestet, sollte funktionieren.

Windows 10
Ungetestet, sollte funktionieren.

Windows 10 Pro
Funktioniert.

Was nicht möglich ist

An der Konsole anmelden, wenn kein Benutzer angemeldet ist funktioniert nicht. Klar, wenn keine Sitzung vorhanden ist, kann auch nicht gespiegelt werden.

Mehrere Spiegelungen, d.h. das mehr als ein entsprechend berechtigter Benutzer sich zu einer Sitzung hinzuschalten kann, ist nicht möglich.

Abschlussbemerkung

Generell hilft es bei vielen Support-Themen bereits, wenn man sich parallel zum aktuellen Benutzer als Administrator zu einem System verbinden kann. So lässt sich einiges machen, ohne den Benutzer verscheuchen zu müssen.

Mich wundert es schon etwas, das Microsoft neben einer Benutzersitzung, ganz gleich ob diese lokal oder per RDP läuft, nicht noch eine Administrator-Sitzung auf den Clients zulässt. Ferner bietet die vorhandene Technik, gemeint ist das Spiegeln, in Verbindung mit VPN o.ä. eine super Alternative zu TeamViewer, VNC und Co.

Kurz notiert: Wie die vergangenen Jahre auch ist Drive Snapshot in einer zeitlich begrenzten Version dieses Jahr ebenfalls wieder im c’t-Notfall-Windows 2019 enthalten.

Bei einem Kunden taucht unregelmässig bei einem PC das Problem auf, dass das Kopieren von Dateien von einem Windows 7-Computer auf einen Windows Server 2012 R2 extrem langsam ist.

Umgekehrt ist es nicht so und reproduzierbar leider auch nicht. Recht gut sozusagen nachlesen können wir dies zudem anhand der Protokolle der nächtlichen Drive Snapshot-Sicherung. Mal ist’s schön schnell, wie man es erwartet, mal extrem langsam bishin zum Timeout.

Gelöst bekommen haben wir es bis dato leider nicht, dabei wurde schon einiges versucht:

• PC neustarten. Ab und an half das bereits, vorallem wenn mal wieder vergessen wurde, den PC beim Feierabend herunterzufahren oder gar die Büchse tage-/wochenlang durchlief.
• Netzwerkkarten-Treiber aktualisieren. Manchmal ging es direkt nach einem Update plötzlich wieder flott.
• Virenscanner deaktiviert. Im Laufe der Jahre gab es sogar einen Wechsel des Anbieters. Ebenfalls keine Änderung.
• Diverse Einstellungen im Netzwerkkarten-Treiber de-/aktiviert (z.B. TCP Offload, etc.).
• Das Auto-Tuning in Windows deaktiviert (netsh interface tcp set global autotuninglevel=disabled).
• Die automatische Aushandlung der Netzwerkgeschwindigkeit deaktiviert und manuell full-/half-duplex, 100/1000 Mbit/s gesetzt.
• TCP/IPv6 de-/aktivieren brachte auch nichts.

Alles ohne dauerhaften Erfolg. Am Netzwerkkabel, Switch etc. kann es auch nicht liegen, da es zwischenzeitlich sogar einen Umzug in ein neues Gebäude samt neuer Verkabelung und Switche gegeben hat.

Eigentlich sollte diese Kiste schon seit Jahren ausgewechselt werden, leider wird dies Kundenseitig immer wieder verschoben. Alleine die Zeit für die Fehlersucherei hätte mittlerweile für mehrere neue Computer gereicht.

Mal eben schnell die Performance im Windows-Netzwerk kann man mit einigen Tools testen. Für auf die Schnelle tut’s die Lite-Variante von Totusoft’s LAN Speed Test.

Diese gibt es zum Installieren als auch portable. Man kann auf eine Freigabe oder einen anderen LAN Speed Test testen.

Die Windows-Aufgabenplanung ist zweifelsohne mächtig und im Regelfall zuverlässig. Mitunter wünscht man sich etwas schlichteres oder hat andere Ansprüche.

Neben den nachfolgend genannten Alternativen gibt es noch zahlreiche weitere Programme. Beim Test ging es darum, ein Batch-Skript ausführen zu lassen.

Freebyte Task Scheduler

Schlank, portable und auf den ersten Blick easy. Leider funktionierte im Test das Ausführen einer Batchdatei nicht.

Homepage

CodeCaged Schedule Manager

Die Oberfläche kann auf Deutsch umgestellt werden. Bereits ausgeführte Aufgaben werden automatisch gelöscht. Leider fehlt die Möglichkeit, eine Aufgabe sofort ausführen zu lassen.

Homepage

Kana Reminder

Kana Reminder kann mehr als nur Programme oder Skripte ausführen. Etwas gewöhnungsbedürftig ist die Handhabung. Während des Tests wurden versehentlich, wegen des Handlings, mehrmals die Aufgabe gelöscht.

Homepage

Solway’s Task Scheduler

Muss eigentlich installiert werden, man kann die Setup-Datei aber einfach mit z.B. 7-Zip entpacken und die darin enthaltene *.exe-Datei ausführen. In diesem kurzem Test ging dieses Programm wenn man so möchte als Sieger hervor.

Homepage

Gemein haben die hier genannten Alternativen, das sie nicht als Dienst laufen, d.h. es muss zur Ausführung der Aufgabe(n) ein Benutzer angemeldet und das jeweilige Programm ausgeführt sein.

Sonderfall „Aufgabe nur ausführen, wenn der Benutzer angemeldet ist“

Wer mit der Windows-eigenen Aufgabenplanung schon mal versucht hat, ein Programm oder Skript auszuführen, wenn der Desktop gesperrt oder z.B. die Remotedesktopverbindung zu diesem getrennt ist, wird festgestellt haben, das dies nur unter bestimmten Umständen, unzuverlässig oder schlicht auch gar nicht funktioniert.

Aufgrund dieses Umstandes wurde auf die Suche nach einer Alternativen für diese spezifische Anforderung gegangen.

Installiert man Android-x86 unter VirtualBox mit den Vorgaben der angelegten virtuellen Maschinen, z.B. aus Basis der Linux-Vorlage, so funktioniert die Maus nicht.

Ohne eben diese ist das Handling schwierig bis unmöglich. Selbst wenn man nach den Angaben der Anleitung arbeitet, klappt es nicht:

Android-x86 – Documentation – VirtualBoxHowTo

Leider ist in der Dokumentation von der Maus-Problematik keinerlei Rede. Abhilfe schafft das Ändern der Einstellungen von „USB-Tablet“ zu „PS/2-Maus“:

Startet man nun die virtuelle Maschine funktioniert die Maus:

Quelle:

superuser – Mouse pointer in Android-x86 inside Oracle Virtual Box

Wer häufig mit Screenshots hantiert und diese in bestimmten Größen anfertigen muss, freut sich sicherlich über das Tool Sizer.

Dieses ermöglicht auf einfache Weise das Anpassen der Fenstergröße auf vordefinierte Werte. Damit entfällt das händische und ggf. unpräzise Anpassen von Fenstergrößen.

Für den Einstieg sei die Doku wärmtens empfohlen, da man sonst an unpassenden Stellen nach dem Menü sucht:

Sizer user guide

Das Tool kann installiert oder portable ausgeführt werden.

Mal eben schnell im Internet etwas nachschlagen kommt evtl. auch mal auf einem unixoiden System vor, das keine grafische Ausgabe hat. Hier hilft Browsh weiter, ein Browser für die reine Textausgabe.

So ganz ohne klassischen Browser geht’s dann doch nicht, da mindestens Firefox 57 vorausgesetzt wird.

Am Beispiel von Debian ist die Einrichtung recht simple:

wget https://github.com/browsh-org/browsh/releases/download/v1.4.13/browsh_1.4.13_linux_amd64.deb

dpgk -i browsh_1.4.13_linux_amd64.deb

Durch Eingabe von „browsh“ im Terminal kann es dann direkt losgehen:

Wird von Windows aus eine OpenVPN-Verbindung aufgebaut, so landet diese Netzwerkverbindung in der Kategorie „Öffentliches Netzwerk“. Für den klasssichen Roadwarrior mag das keine Schwierigkeiten bereiten, in einem Kunden-Szenario ging es allerdings darum, einen entfernen Backup-Server anzubinden, folglich muss von der anderen Seite aus auf Diesen zugegriffen werden können.

Potentielle Abhilfe gibt es einige. Eine Variante wäre die Windows-Firewall für die OpenVPN-TAP-Schnittstelle zu deaktivieren, das wiederrum provoziert allerdings eine Warnmeldung durch das Sicherheits-Center bzw. Windows Defender Security Center. Für die Sicherheit ist das zudem nicht zuträglich.

Andere Optionen die man im Netz so findet bestehen darin, irgendein Gateway zuzuweisen. Allerdings zeigte die Erfahrung, das es damit andere Überraschungen geben kann.

Ein relativ einfacher Weg besteht darin, die Netzwerkkategorie für die OpenVPN-Verbindung zu ändern. Leider merkt sich Windows diese Einstellung nicht, so das sie nach jedem Verbindungsaufbau erneut gesetzt werden muss. Das gilt dann auch für etwaige Verbindungsabbrüche.

Per Batch-Skript lässt sich die Angelegenheit recht simple lösen:

@echo off

powershell get-netconnectionprofile -interfaceindex 11 | find "Private"
if %errorlevel%==1 powershell set-netconnectionprofile -InterfaceIndex 11 -NetworkCategory Private

Zuvor muss man natürlich schauen, welchen Index die Verbindung hat. Dieser bleibt glücklicherweise der bisherigen Beobachtung nach immer gleich.

Damit nicht manuell nach jedem automatischen Verbindungsaufbau das Skript ausgeführt werden muss, wurde dieses als Aufgabe mit einem Intervall von fünf Minuten hinterlegt.

Unter Windows 10 klappt die Änderung allerdings zunächst nicht, da die Powershell anmeckert, das sie nicht preveligiert wäre (d.h. keine Admin-Rechte hat). Das geschieht auch dann, wenn der für die Aufgabe verwendete Benutzer Administrator-Berechtigungen hat. Abhilfe kann dadurch geschaffen werden, in dem das System-Konto („SYSTEM“ bzw. „NT AUTORITÄT\SYSTEM“) verwendet wird oder der Bord-eigene Administrator aktiviert und mit einem Kennwort versehen die entsprechende Aufgabe ausführt.

By the way: Versuche, das Ändern der Netzwerkkategorie beim Verbindungsaufbau anzutriggern klappten leider nicht, daher erschien mir der Weg über die Aufgabe als einfache Lösung.

Bei einem Kunden wurde plötzlich eine Druckerpatrone nicht mehr erkannt. Ganz so einfach austauschen liese diese sich allerdings nicht.

Im Display des Canon MB2700 Serie-Multifunktionsgeräts wurde für die Farbe gelb schlicht ein Fragezeichen angezeigt. Leider fährt der Druckkopf nur in die Position zum Auswechseln von der jeweiligen Patrone, wenn das System der Meinung ist, die Patrone sei leer. Folglich war einfach herausnehmen bzw. auswechseln nicht möglich, der Druckkopf fuhr beim Öffnen der Frontklappe schlicht nur einmal hin und her und parkte und verriegelte dann.

Weder über das Menü am Gerät selbst noch über die Windows-Software lässt sich ein Auswechseln der Patronen auslösen, so muss man leider zu dem einen oder anderen Trick greifen.

Möglichkeit 1:

Im Netz findet man recht häufig Anleitungen die beschreiben, das man einen Druckvorgang starten soll und dann das Gerät vom Strom nimmt. Anschließend kann man die Frontklappe öffnen, den Druckkopf in die gewünschte Position schieben und die betroffene Patrone entriegeln als auch entnehmen.

heise – ct – Patrone bei Canon Maxify-Drucker ausbauen

Diesen Weg sind wir auch zuerst gegangen, es funktioniert, führt aber dann leider zu einem recht langwierigen Reinigungsvorgang des Geräts sobald es wieder am Strom ist.

Möglichkeit 2:

Da wir mit dem ersten genannten Weg nur einen Teilerfolg hatten, es gab mit der Austauschpatrone ebenfalls Probleme, musste eine schnellere Lösung her, ohne lange auf den Abschluss der Reinigung warten zu müssen. Das Gerät wird etwas austrickst, damit der Druckkopf entriegelt bleibt und man relativ bequem die Patrone(n) austauschen kann.

Zunächst dem Gerät „vorgaukeln“, das die Frontklappe geschlossen ist, obwohl sie offen ist. Das geht mit einem kleinen Schlitz-Schraubendreher, der einfach den Endschalter betätigt. Im Foto ist dieser gelb, der Schraubendreher wird ganz leicht in den entsprechenden Schlitz gesteckt.

Dadurch bleibt der Druckkopf entriegelt und kannbei geöffneter Frontklappe nun einfach mit einem Finger verschoben werden:

An der „Austausch“-Position angekommen kann man die Patrone(n) entriegeln und anschließend entfernen. Im Idealfall klappt dies über die dafür vorgesehene Taste. Mitunter kann es aber auch vorkommen, das diese außer Funktion bei dieser Heransgehensweise ist, so das man mit einem kleinen Schlitz-Schraubendreher die jeweilige Lasche zum Entriegeln drücken muss (siehe zuvor verlinkte Anleitung bei heise).

Wie man auf den Bildern sieht, verwendet der Kunde keine Original-Patronen von Canon. Womöglich liegt hierin die Ursache für die Schwierigkeiten.

Grundsätzlich empfehlen wir immer Original-Patronen, da wir es schon öfters unabhängig vom Patronen-Anbieter als auch Drucker-Hersteller erlebt haben, das Geräte beschädigt werden, dies ging schon bishin zum Totalschaden.

Eigentlich wird das Canon Pixma MX860-Multifunktionsgerät seitens des Herstellers unter Windows 10 nicht unterstützt. Klar, hat es doch schon ein paar Jahre auf dem Buckel.

Installieren lässt es sich dennoch, wenn man die Software-Pakete die für Windows 8.1 gedacht sind verwendet. Das klappt soweit ohne besondere Vorkommnisse, allerdings wurde beim betroffenen Kunden nur der Drucker- und Scanner-Treiber installiert. Die Zusatz-Software wie z.B. My Image Garden, etc. wird nicht verwenden.

Konkret kommt nur

• IJ Network Driver v. 2.5.7 / Network Tool v. 2.5.7 (Windows) und
• MP Navigator EX v. 2.13 (Windows 8.1/8.1 x64/8/8 x64/7/7 x64/Vista/Vista64/XP/2000)

zum Einsatz. Das Gerät ist übrigens via Netzwerk angebunden.

Troubleshooting:

Ob es mit bestimmten Windows 10-Updates oder gar -Upgrades zusammenhängt konnten wir nicht klären, aber irgendwann klappte das Scannen über’s Netzwerk nicht mehr. Drucken lief hingegen nach wie vor ohne Beanstandung.

Abhilfe liefert dann das nochmalige Ausführen des Network Driver-Setups. Der Scanner wird wieder im Netz gefunden und kann wie gewohnt verwendet werden. Leider erstellt das Setup einen weiteren Druckeranschluss. Der stört erstmal nicht, der Ordnung halber sollte man den Drucker auf diesen dann umstellen und den alten Anschluss entfernen.

Um schneller in den Arbeitstag starten zu können, sollten automatisiert lokal auf einem Server bereits die RemoteApps für verschiedene Benutzer gestartet werden. Damit entfällt die Wartezeit, bis mehrere Programme vollständig geladen sind.

Das Vorhaben war letztlich aufwendiger als zuerst angenommen. Es gibt ein paar Punkte in diesem Szenario zu beachten, wie sich im Laufe der Realisierung zeigte. Im mehrfachen Sinne lehrreich war es auf jeden Fall.

Es gibt einen (imho) schnelleren bzw. einfacheren Weg, dennoch ist die eine oder andere Hintergrund-Info aus diesem Beitrag interessant. Zum „Kurzen Weg“ geht’s hier lang:

Windows: RemoteApps für verschiedene Benutzer per Aufgabe automatisch starten und trennen – Der kurze Weg

Geplanter Ablauf

Vor Arbeitsbeginn, also mit genügend zeitlichem Vorlauf, sollen auf einem Terminalserver automatisch für diverse Benutzer die RemoteApps gestartet werden. Da man in Windows nur einen Satz Anmeldedaten pro Server hinterlegen kann, muss der Anmeldedialog der Remotedesktopverbindung automatisch mit verschiedenen Benutzername/Kennwort-Kombinationen ausgefüllt werden. Nach dem Start und Anmelden für den ersten Benutzer muss die Sitzung getrennt werden, da sonst keine weitere Anmeldung mit einem anderen Benutzer möglich ist, und dann die nächsten RemoteApps für den nächsten Benutzer gestartet bzw. angemeldet werden.

Das Ganze geschieht übrigens in der Konsolensitzung, da der Administrator automatisch angemeldet (und gleich gesperrt) wird. Nebenbei bemerkt: Die automatische Anmeldung vom Administrator erfolgt aus mehreren Gründen (div. abhängige Anwendungen) und wird in diesem Zusammenhang lediglich um die automatische Anmeldung/Trennung der RemoteApps erweitert.

Windows-Automatisierung: Unterschiede ob eine Sitzung entsperrt/verbunden, gesperrt oder getrennt ist

Mit AutoIt Interaktionen unter Windows zu automatisieren ist relativ einfach. So lassen sich schnell Skripte erstellen, mit dessen Hilfe Aktionen mit Fenstern, Eingaben etc. lösen lassen.

Im ersten Moment und wenn man sich damit bislang nicht auseinder gesetzt hat, wundert man sich, warum so gewohnte Befehlt wie „Send()“ im gesperrten (Lokal oder RDP) oder getrennten Zustand (RDP) dann allerdings nicht funktionieren. Hierzu lieferte die AutoIt-FAQ die Erklärung:

„Why doesn’t my script work on a locked workstation?
On a locked station any window will never be active (active is only dialog with text „Press Ctrl+Alt+Del“). In Windows locked state applications run hidden (behind that visible dialog) and do not have focus and active status. So generally don’t use Send() MouseClick() WinActivate() WinWaitActive() WinActive() etc. Instead use ControlSend() ControlSetText() ControlClick() WinWait() WinExists() WinMenuSelectItem() etc. Doing so allows you to interact with an application regardless of whether it is active or not. It’s possible to run such a script from scheduler on locked Windows stations.“

Quelle: AutoIt – Wiki – FAQ – Why doesn’t my script work on a locked workstation?

Mit anderen Worten: Im gesperrten oder getrennten Zustand gibt es keine aktiven Fenster, es funktioniert dann auch nicht, einem Fenster den Fokus zu geben. Man muss also mit anderen Befehlen (s.o.) arbeiten und ggf. etwas tricksen. Dazu gleich mehr.

Windows-Sicherheit automatisch ausfüllen lassen

Das Anmeldefenster der Remotedesktopverbindung mit dem Titel „Windows-Sicherheit“ automatisch ausfüllen zu lassen war relativ spannend. Im angemeldeten Zustand klappte das mit Send() ohne Probleme. Im gesperrten und getrennter Zustand musste dann ControlSend() herhalten. Das klappte nach einigen probieren dann endlich wie erwartet.

Interessanterweise gelang es nicht, direkt in die Felder für Benutzername und Kennwort die Daten eintragen zulassen, obwohl mit AutoItInfo mit richtigen IDs ausgelesen und im Skript bei „ControlSend()“ angegeben wurden. Hier kommt dann das Tricksen im weitesten Sinne ins Spiel.

Damit in die richtigen Felder Benutzername und Kennwort eingetragen werden, wird ein Tastendruck auf „Down“ (Pfeiltaste runter) ausgelöst, dann zunächst der Benutzername und nach einem weiteren „Runter“ das Kennwort eingetragen. Das zugehörige AutoIt-Skript sieht wie folgt aus:

; Die Parameter den Variablen zuweisen

$Domain = $CmdLine[1]
$Username = $CmdLine[2]
$Password = $CmdLine[3]

; Dem Fenster "quasi" den Fokus geben/dieses aktivieren

ControlFocus ("Windows-Sicherheit", "", "")

; Kurze Pause, da sonst der folgende "Pfeil runter" nicht funktioniert

sleep (1000)

; Einmal "Pfeil runter" drücken

ControlSend ("Windows-Sicherheit", "", "", "{DOWN}")

; Kurze Pause, da sonst die Eingabe im falschen Feld erfolgt

sleep (500)

; Den Benutzernamen eintragen

ControlSend ("Windows-Sicherheit", "", "", $Domain & "\" & $Username)

; Zum Kennwort-Feld wechseln

ControlSend ("Windows-Sicherheit", "", "", "{DOWN}")

; Das Kennwort eintragen

ControlSend ("Windows-Sicherheit", "", "", $Password)

; ENTER drücken

ControlSend ("Windows-Sicherheit", "", "", "{ENTER}")

Domäne, Benutzername und Kennwort werden als Parameter übergeben. Beim zur *.exe-Datei kompilierten Skript sieht das so aus:

RDPAutoLogon.exe <Domain> <Username> <Password>

Hinweise: Wurde „mstsc“ schonmal verwendet, dann wird der letzte verwendete Benutzername pro Ziel-Computer gespeichert. Bei der automatischen Eingabe der Zugangsdaten bei abweichendem Benutzername muss also zunächst „nach unten“ gesprungen werden.

By the way: Hinterlegt ist der zuletzt verwendete Benutzername in der Registry unter

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers\<IP der Hostname>

UsernameHint

Bei einer „jungfräulichen“ mstsc bzw. wenn erstmals zu einen Zielserver verbunden wird, entfällt das erste „runter“ drücken und man kann direkt den Benutzername etc. eintragen. Das gilt aber wirklich nur für das erste Mal!

Das Ganze hier wurde unter Windows Server 2012 R2 realisiert. Unter anderen Windows-Versionen kann der „Windows-Sicherheit“-Dialog varrieren, so das Anpassungen notwendig sind.

Windows-Aufgabenplannung: Aufgabe wird nur ausgeführt, wenn der Benutzer angemeldet und verbunden ist

Die Aufgabe wird also nur ausgeführt, wenn man wirklich angemeldet und aktuell verbunden ist. Im gesperrten oder getrennten Zustand geschieht schlicht nichts oder nicht richtig.

Die Aufgabe unabhängig vom angemeldeten Benutzer auszuführen bringt leider nichts, da dann die „Fenster-Automatisierung“, also das Eintragen der Zugangsdaten nicht greift.

Als Plan B musste eine andere Aufgabenplanung her, alternativ kann man ein Skript schreiben, das regelmässig die Uhrzeit prüft und nur zum festgelegten Zeitpunkt eine Aktion ausführt.

Als alternative Aufgabenplanung für diesen Job dient nun Solway’s Task Scheduler, siehe dazu den Beitrag Windows: Alternativen zur Aufgabenplanung.

Je nach Zustand unterschiedliches Verhalten von AutoIt

Ebenfalls unerwartet war das Verhalten von AutoIt im gesperrten/getrennten Zustand wenn es ums reine Ausführen geht. Während der Skript-Entwicklung wurde mit Hilfe der AutoIt3.exe das jeweilige Skript gestartet. Während es im angemeldeten Zustand einfach mit „AutoIt3.exe <Skript>“ klappt, blieb es in den anderen Zuständen bei der Ausführung „hängen“. Gelöst werden konnte das so:

start /d <Ordner> AutoIt3.exe <Skript>

RemoteApp(s) trennen für den nächsten Benutzer

Wie man die RemoteApps bzw. generell RDP-Sitzungen trennen kann, ist im Beitrag Windows: RemoteApps trennen beschrieben. Auf die dortigen Skripte wird für dieses Vorhaben zurückgegriffen.

Das Gesamtkunstwerk

Lange Rede, kurzer Sinn: Das eigentliche Batch-Skript das als Aufgabe ausgeführt wird sieht (auszugsweise) so aus:

@echo off

rem Konfiguration

set SessionDomain=localhost
set SessionUsername=<Benutzername>
set SessionPassword=<Kennwort>

rem Automatische Anmeldung vorbereiten

cd C:\Skripte\RemoteAppAutoLogon

start RDPAutoLogon.exe %SessionDomain% %SessionUsername% %SessionPassword%

rem RemoteApps starten

mstsc "Outlook.rdp"

timeout /t 5 > nul

mstsc "Firefox.rdp"
mstsc "3CXPhone for Windows.rdp"
mstsc "PhoneSuite CTI Client.rdp"
mstsc "JTL-Wawi.rdp"

rem Sitzung trennen

set next=eof
goto rdp-disconnect

rem ------------------------------------------------------
rem Naechster Benutzer
:<username>
rem Benutzername, RemoteApps, etc.

rem ------------------------------------------------------
rem Skript beenden

:eof
 exit

rem ------------------------------------------------------
rem Quasi-Funktion "RDP-Sitzung trennen"
:rdp-disconnect

rem Automatische Bestaetitung der Trennung vorbereiten

 start ClickDiscRAWa-x64.exe
  
rem Pause, damit die RemoteApps vollstaendig starten koennen

 timeout /t 60

rem Aktuelle Sitzungen auflisten

 query session /server:"%WTSServer%" | find "%SessionUsername%" > "%TEMP%\Session.txt"
 set /p Session=<"%TEMP%\Session.txt"
 
rem ID des Benutzers ermitteln

 rem Ab Zeichen 43 in der Zeile,
 rem drei Stellen in die Variable schreiben.

  set SessionID=%Session:~43,3%
 
 rem Ggf. vorhandene Leerstelle(n) entfernen, falls die ID nur ein- oder zweistellig ist.
 
   set "SessionID=%SessionID: =%"
 
rem "Session.txt" entfernen

 del "%TEMP%\Session.txt" /q
 
rem Sitzung trennen
 
 tsdiscon %SessionID% /Server:%WTSServer%
 
rem Pause bevor es weiter geht, damit es zu keinen Schwierigkeiten beim Bestaetigen der Trennung kommt

 timeout /t 15
 
rem Zur naechsten Marke springen
 
 goto %next%

Man beachte die Pause nach dem Start von Outlook, diese dient dazu, das die RemoteApp geladen werden kann und die Abfrage nach dem Benutzernamen und Kennwort erscheint und automatisch ausgefüllt werden kann.

Sinnvoll können je nach zu startender/n Anwendung(en) zudem mehrere Pausen sein. Dies verhindert dann z.B. Lastspitzen bei CPU, Storage, etc.

Dieser Auszug ist nur für einen Benutzer und kann um mehrere erweitert werden. In der Praxis werden damit bereits mehrere Benutzer bedient.

Offene Punkte

Noch nicht berücksichtigt ist das Thema, wenn das Server-Zertifikat erneuert wurde, diese haben meist eine Gültigkeit von einem Jahr, und dann die Abfrage erscheint, ob man diesem Vertraut. Bei einem Schnelltest konnte diese Abfrage bislang nicht abgefangen werden. Vermutlich muss man auch hier etwas Tricksen.

Wie verbindet sich nun der Anwender von seinem Arbeitsplatz aus?

Diese Frage ist einfach zu beanworten: Es genütgt eine RemoteApp zu starten und die zuvor automatisch erstellte Sitzung wird verbunden. Aber Achtung: Manche Anwendung startet dann doppelt! Gut, d.h. ohne doppelten Start, funktioniert das Verbinden wenn man Outlook als RemoteApp aufruft.

Wie der Zufall es so wollte, fand sich am Ende des Schreibens von Windows: RemoteApps für verschiedene Benutzer per Aufgabe automatisch starten und trennen – Der lange Weg eine simplerere Möglichkeit, das Vorhaben umzusetzen bzw. nun deutlich zu vereinfachen.

Umsonst waren die vorigen Bemühungen dennoch nicht, da z.B. das Thema mit der Aufgabenplanung nach wie vor relevant hat. Um es relativ kurz zu machen: Statt auf eigene AutoIt-Skripte zum Automatisieren der Remotedesktopverbindungsanmeldung zu setzen wird nun Remote Desktop Plus verwendet, ein Wrapper für die „mstsc.exe“ von Windows.

Einer von vielen Vorteilen von Remote Desktop Plus ist die Möglichkeit, quasi alles über Befehle und Parameter steuern zu können, dies schließt die Angabe von Benutzername und Kennwort mit ein. Also Bordmittel aufgebohrt, wenn man so möchte.

Vorbereitungen

Zunächst benötigt man die rdp.exe, die einfach heruntergeladen werden kann. Optional wird vom gleichen Anbieter Gencrypt zum Verschlüsseln des RDP-Kennworts benötigt. Ferner, wenn’s als Aufgabe erfolgreich laufen soll, wird Solway’s Task Scheduler benötigt. Zu guterletzt, damit man nach dem Trennen die Meldung automatisch loswird, wird noch die „ClickDiscRAWa.exe“ bzw. „ClickDiscRAWa-x64.exe“ aus dem Archiv RemoteApp_trennen_abmelden.zip benötigt.

Die Hintergründe zu dem wieso, weshalb und warum man diese Tools verwenden sollte, bitte in den zugehörigen Beiträgen nachlesen:

Windows: RemoteApps trennen (betrifft ClickDiscRAWa.exe)

Windows: RemoteApps für verschiedene Benutzer per Aufgabe automatisch starten und trennen – Der lange Weg

Windows: Alternativen zur Aufgabenplanung

Damit das nachfolgende Skript noch kompakter ist, wurde das Trennen der RDP-Sitzung ebenfalls als RemoteApp hinterlegt. Dazu reicht es aus, schlicht „tsdiscon“ als RemoteApp z.B. mit dem Namen „Trennen“ freizugeben.

Der kurze Weg

So sieht das Batch-Skript für einen Benutzer aus:

@echo off

title RemoteApp(s) starten und die Sitzung trennen

rem Konfiguration

 set RDPServer=
 set RDPDomain=
 set RDPUsername=
 set EncryptedRDPPassword=

rem ---

rem RemoteApps starten

 rdp.exe Outlook.rdp /v:%RDPServer% /domain:%RDPDomain% /u:%RDPUsername% /pe:%EncryptedRDPPassword%
 rdp.exe Firefox.rdp /v:%RDPServer%
 rdp.exe "3CXPhone for Windows.rdp" /v:%RDPServer%
 rdp.exe JTL-Wawi.rdp /v:%RDPServer%
 
rem ---

rem Pause

 timeout /t 60 /nobreak

rem ---

rem Trennen und/oder Abmelden

 rdp.exe /remoteapp:"||Trennen" /v:%RDPServer% /domain:%RDPDomain% /u:%RDPUsername% /pe:%EncryptedRDPPassword%
 start ClickDiscRAWa-x64.exe

Diese Befehlszeilen kann man für jeden Benutzer wiederholen oder eigene Skripte pro Benutzer anlegen. Nur für die erste RemoteApp müssen Anmeldedaten angeben werden. Sobald eine Sitzung besteht und verbunden ist, werden alle nachfolgenden RemoteApps in eben dieser gestartet. Das klappt aber nur, wenn keine zu große Pause zwischen den RemoteApps liegt. Im Zweifelsfall bei jeder RemoteApp die Zugangsdaten mitgeben.

Statt der RDP-Verbindungsdateien können die RemoteApps auch direkt mit ihrem Namen angesprochen werden:

rdp.exe /v:%RDPServer% /remoteapp:"||Outlook" /domain:%RDPDomain% /u:%RDPUsername% /pe:%EncryptedRDPPassword%

Ein weiteres Umstellungsargument

Zusätzlich nimmt einem Remote Desktop Plus das „Vertrauen sie diesem Server/Zertifikat“ ebenfalls ab. So das sich mit dieser Umstellung dieser Punkt als abgehakt betrachtet werden kann.

Troubleshooting

Kein Licht ohne Schatten, wobei es halb so schlimm ist: Beim Ausprobieren klappte manchmal das Anmelden nicht und es erscheint der „Windows-Sicherheit“-Anmeldedialog für die Remotedesktopverbindung. Der bisherigen Erfahrung nach ist das dann auf eine hängen gebliebene „mstsc.exe“ zurückzuführen, die nach irgendeinem Fehlversuch im Hintergrund noch läuft. Diese einfach per Task-Manager oder

taskkill /im mstsc.exe /f

abschießen und schon läuft’s wieder.

Etwas unberechenbarer ist die Meldung nach dem Trennen der RemoteApps, wozu die „ClickDiscRAWa-x64.exe“ zum automatischen Anklicken dient. Zum einen spielt die Reihenfolge im Skript eine Rolle, soll heißen:

• Erst „rdp.exe…“ ausführen, dann
• „ClickDiscRAWa-x64.exe“ starten

Andernfalls tauchen gleich mehrere RemoteApp-getrennt-Meldungen auf, die dann nicht mehr automatisch weggeklickt werden. Ferner kommt es vor, das überhaupt keine Meldung erscheint, was als Dauerzustand eigentlich ideal wäre, aber leider nicht so ist. Dann würde allerdings ewig die „ClickDiscRAWa-x64.exe“ weiterlaufen bzw. bei jedem weiteren Durchlaufen des Skripts weitere Instanzen gestartet werden. Als kleinen workaround kann man diese nach einer kurzen Pause beenden:

...
start ClickDiscRAWa-x64.exe
timeout /t 5
taskkill /im start ClickDiscRAWa-x64.exe /f

Ebenfalls hilfreich ist eine Pause beim Benutzerwechsel, da es sonst zu Schwierigkeiten bei der Anmeldung kommen kann.

rdp.exe... für Benutzer A
timeout /t 60
rdp.exe... für Benutzer B

Schlussbemerkung

Ursprünglich hatte ich genau nach solch einer Lösung gesucht, aber seinerzeit nichts gefunden. Waren wohl die falschen Schlüsselwörter für die Suchmaschine So oder so waren beide Wege durchaus lehrreich und interessant. Remote Desktop Plus bietet aber noch weit mehr, als es hier für diesen einen Zweck verwendet wurde, reinschauen lohnt sich also.

Wie man RemoteApps trennen kann ist im Beitrag Windows: RemoteApps trennen beschrieben. Die umgekehrte Richtung, also das Wiederverbinden, folgt nun.

Grundsätzlich kann man die RemoteApp(s) erneut aufrufen, um eine Verbindung wiederherzustellen, allerdings startet so manche Anwendung dann als weitere Instanz. Um das zu vermeiden, kann man auf einen simplen Trick zurückgreifen.

Man erstellt eine leere Batch-Datei, nennen wir sie mal „reconnect.cmd“ und gibt diese z.B. mit dem Namen „Wiederverbinden“ als RemoteApp frei.

In diesem Fall habe ich lediglich eine kleine Info in die Datei geschrieben, damit man später auch noch erahnen kann worum es geht:

@echo off
rem Dummy-Skript als RemoteApp freigegeben,
rem zum Wiederverbinden von RemoteApp-Sitzung.

Hat ein Benutzer seine RemoteApp-Sitzung getrennt und möchte sie nun wiederverbinden, muss er bzw. sie lediglich die „Wiederverbinden“-RemoteApp ausführen und schon ist die gesamte Sitzung mit allen bereits laufenden entfernten Anwendungen wieder da.

VeraCrypt lässt sich dank CLI wunderbar via Verknüpfungen oder Skripte steuern. So bastelte ich mir Skripte für die Portable-Ausgabe die unter Windows automatisch erhöhte Rechte (zum Laden des Treibers) anfordern als auch das gewünschte Volume/Container einhängen und den Explorer öffnen.

Hintergedanke der Geschichte ist, das auf einem USB-Stick VeraCrypt-Portable hinterlegt sein soll. Durch möglichst nur einen Doppelklick (auf die RunAsAdmin.cmd) soll die Kennwort-Abfrage erfolgen.

Da solch ein Stick ggf. an unterschiedlichen Computern verwendet wird und nicht überall Erhöhte- bzw. Administrator-Rechte direkt verfügbar sind, war die vorige Anforderung nach eben diesen relevant. Daher wird zunächst mittels AutoIt die erhöhten Rechte eingefordert und dann fortgefahren:

RunAsAdmin.au3:
; AutoIt TrayIcon ausblenden

#NoTrayIcon

; Erhöhte Rechte anfordern

#RequireAdmin

; Skript ausführen

Run ($CmdLine[1])

RunAsAdmin.cmd:
@echo off

title RunAsAdmin VeraCrypt Portable

echo.
echo Bitte warten...
echo.

rem Unter/Als 32- oder 64-bit ausfuehren

if exist "C:\Program Files (x86)" (
start AutoIt3_x64.exe RunAsAdmin.au3 VeraCrypt.cmd
) else (
start AutoIt3.exe RunAsAdmin.au3 VeraCrypt.cmd
)

Für die weitere Bequemlichkeit sollte der nächste freie Laufwerksbuchstabe als auch der Explorer automatisch geöffnet werden. Das macht VeraCrypt durch die Parameter „/l /a“ (kann man angeben, muss man aber nicht) und „/e“ von selbst. Zu guterletzt sollte durch einen Tastendruck das Volume bzw. der Container wieder ausgehängt werden. Das Ganze ohne nochmals die erhöhten Rechte anzufordern.

VeraCrypt.cmd:

@echo off

title VeraCrypt Portable wird ausgefuhert

echo.
echo Bitte warten...
echo.

rem VeraCrypt-Container einhaengen und Explorer oeffnen

cls

echo.
echo VeryCrypt Portable wird gestartet und
echo der Container wird nach Eingabe des Kennworts eingehaengt
echo.

start /wait VeraCrypt\VeraCrypt.exe /q /v Daten /e /m label=VeraCrypt

rem Auf beliebige Taste warten

cls

echo.
echo Druecken Sie eine beliebige Taste,
echo um den VeraCrypt-Container auszuhaengen und
echo das Programm zu beenden.
echo.

pause > nul

rem Alle VeraCrypt-Container aushaengen

start VeraCrypt\VeraCrypt.exe /q /d

P.S.: Die Skripte funktionieren natürlich auch auf einer Festplatte oder SSD.

Muss man öfter Installationsdateien aus WIndows Installer-Setups entpacken, geht das bedingt z.B. mit 7-Zip, mit Tipperei in der Eingabeaufforderung (msiexec…) oder ganz bequem mit lessmsi.

Beim Versuch das aktuelle Setup von TightVNC zu entpacken stolperte ich zuerst über die Ausgabe von 7-Zip, die zwar prinzipiell funktioniert, man dann aber die Dateien noch händisch umbenennen darf.

Mit msiexec hatte ich diesmal überhaupt kein Glück, da ständig gemeckert wurde, mit dem Paket würde etwas nicht stimmen. Witzigerweise verwende ich genau diese Setup-Datei aktuell für alle TightVNC-Installationen.

Zu guterletzt suchte ich dann im Netz nach einem Plan C und fand durch

The Backroom Tech – The Best MSI Extractor

dann eben lessmsi. Über eine simple GUI lassen sich einzelne oder alle Dateien entpacken:

Auf Wunsch geht das ebenfalls via CLI und Explorer-Integration.

gtop ist eine schicke im Terminal laufende top-Alternative und eignet sich mit seinem Dashboard für das System-Monitoring.

Für eine erfolgreiche Installation unter Debian 9 Stretch wird nicht viel benötigt. Die wichtigste Voraussetzung ist Node.js. Allerdings reicht die Version aus den Standard-Paketquellen nicht aus.

Am besten man verwendet die Repositories der Node.js-Macher:

curl -sL https://deb.nodesource.com/setup_11.x | bash -
apt-get install -y nodejs

Ist der Grundstein gelegt kann das Tool bequem installiert werden:

npm install gtop -g

Im Terminal wird es dann schlicht wie folgt aufgerufen:

gtop

Quellen:

NodeSource Node.js Binary Distributions

Bleeping Computer – How to install Gtop on Ubuntu

Nachdem die Entwicklung der Classic Shell eingestellt und der Quellcode freigegeben wurden, gibt es z.B. mit dem Open-Shell-Menü einen potentiellen Nachfolger.

Wer die Classic Shell bereits unter Windows 8.1 oder Windows Server 2012 R2 einsetzt, wird sich wohl kaum Gedanken um ausbleibende Updates machen müssen, schließlich ändert sich an diesen Systemen nicht (mehr) allzuviel.

Anders sieht die Welt bei Windows 10 aus. Nicht nur wegen dem neuen durchaus gewöhnungsbedürftigem Startmenü, sondern auch wegen der halbjährlichen Upgrades und dem Wegfallen alter Funktionen auf die Classic Shell zurückgreift.

Auf den ersten Blick, zumindest beim Setup, gibt es keine großen Unterschiede. Auch beim ersten Start begrüsst einem der gewohnete Assistent. Differenzen gibt es dann naturgemäss bei den Einstellungen, speziell zu Windows 10.

(Imho) Findet sich der alt-gediente Windows-Anwender mit dem Open-Shell-Startmenü unter Windows 10 schneller bzw. leichter zurecht.

Das Windows-eigene Startmenü kann wie von Classic Shell gewohnt durch einen Druck auf die Shift-Taste und einem Mausklick wieder aufgerufen werden. Ferner bleibt es dabei, das man die getätigten Einstellungen aus der Registry ex- und bei einem anderen Benutzer oder Computer importieren kann.

Grundsätzlich ist es mit AutoIt leicht, ein Programm mit ausgeblendeten bzw. verstecktem Fenster zu starten.

Die einfachste Syntax wäre:

run("Irgendeine.exe", "", @SW_HIDE)

Das funktioniert super, sofern das Programm nur ein Fenster öffnet. Starten allerdings mehrere Fenster z.B. der Reihe nach, so bleibt das Erste zwar versteckt, die nachfolgenden werden allerdings angezeigt.

Das kann man zwar z.B. über

WinSetState("Fenstertitel", "", @SW_HIDE)

weiter eingrenzen, allerdings geschieht diese Änderung mit kurzer Verzögerung. Das bedeutet, das Fenster „blitzt“ kurz auf. Kennt man zudem nicht alle nachfolgenden Fenstertitel, wird das Unterbinden der Anzeige unter Umständen unmöglich.

Problematisch kann zudem sein, wenn man ein Fenster über „WinSetState“ direkt bzw. kurz nach dem Start einer Anwendung versteckt, das der gesamte Programmstart dann nicht gelingt.

Abhilfe kann schaffen, das Programm auf einem versteckten Desktop zu starten. Diese Lösung fand sich im Forum:

_shellExecuteHidden (allow no windows to become visible)

Als simples AutoIt-Programm habe ich einfach die Funktion zusammen mit den nachfolgenden Zeilen in ein Skript gepackt und als ausführbare Datei kompiliert:

#NoTrayIcon

$CMD = $CmdLine[1]

_shellExecuteHidden($CMD)

; Ab hier kommt die Funktion
...

Hinweis: Ein Download von winapiex ist nicht notwendig, da dieses als UDF in AutoIt mittlerweile enthalten ist.

Die Syntax lautet z.B.:

RunCompletelyHidden.exe C:\Windows\System32\Notepad.exe

Download

Im Archiv ist der Quellcode als auch eine 32- und 64-bit Exe-Datei enthalten:

RunCompletelyHidden.zip

Einschränkungen

Leider ist es mir bislang nicht gelungen, z.B. Text oder überhaupt das Vorhandensein ein auf diese Art ausgeblendeten Fensters/Programms zu ermitteln. Da muss ich dann leider dazusagen, das ich kein Entwickler bin. Falls jemand eine Idee hat, dann raus damit!

Zum Thema Automatisieren von MailStore Home gab es bereits Beiträge:

MailStore Home: Automatisch archivieren und bei Erfolg beenden

MailStore Home von 4.2 auf 5.0 updaten + Automatisierung der Archivierung

Auf Basis des letzten Beitrags folgt nun eine etwas aufgebohrtere Variante.

Gleich Vorweg, es gibt zwei Möglichkeiten, MailStore Home versteckt auszuführen. Die erste bietet die Möglichkeit einer Auswertung, hat aber den Nachteil, das, wenn auch nur kurz, das eine oder andere Fenster erscheint.

Teilweise verteckt ausführen mit Auswertung

In der vorigen Variante war es so, das bei Erfolg MailStore Home geschlossen wurde. Das Ganze wurde recht simple umgesetzt, in dem in der Fortschrittsanzeige nach dem entsprechenden Abschlusssatz gesucht wurde.

Die Prüfung auf den Abschluss der Archivierung erfolgt nun auf Basis des vorhandenseins der Schaltfläche „Details…“. Diese erscheint in der Fortschrittsanzeige erst, wenn die Aufgabe abgeschlossen wurde. Als nächstes wertet man aus, ob die Archivierung erfolgreich war oder eben nicht.

Diese erweiterte Version ermöglicht über die Auswertung des Rückgabewertes im Anschluss an die Ausführung der Archivierung dann z.B. eine Alarmeriung per Mail o.ä.

Das AutoIt-Skript inkl. Kommentare sieht dann so aus:

; AutoIt TrayIcon ausblenden

 #NoTrayIcon

; Parameter übergeben 
 
 $MailStoreCMD = $CmdLine[1]

; MailStore Home ausführen 

 Run($MailStoreCMD, "", @SW_HIDE)

; Das Auslesen von verstecktem text aktivieren

 Opt ("WinDetectHiddenText", 1)
 
; Die Fortschrittsanzeige ausblenden

While 1

; If WinExists ("MailStore Home") Then
  ; WinSetState ("MailStore Home", "", @SW_HIDE) <- verhindert den erfolgreichen Start des Programms
  ; WinSetState ("MailStore Home", "", @SW_MINIMIZE) <- Dann erscheint wieder das Hauptfenster
; EndIf

 If WinExists ("Fortschrittsanzeige") Then
  WinSetState ("Fortschrittsanzeige", "", @SW_HIDE)
  ExitLoop
 EndIf
 
WEnd

; Auf den Abschluss der Archivierung warten und den Rückgabewert ermitteln
; 0 = Alles OK
; 1 = Fehler/Warnung

While 1

  If WinExists ("Fortschrittsanzeige", "Details...") Then
   If WinExists ("Fortschrittsanzeige", "Der Vorgang wurde erfolgreich abgeschlossen.") Then
    $ExitCode = 0
   Else
    $ExitCode = 1
   EndIf
   ; If WinExists ("Fortschrittsanzeige", "Der Vorgang wurde abgeschlossen mit Fehlern.") Then $ExitCode=1
   ProcessClose ("MailStoreHome.exe")
   Exit ($ExitCode)
  EndIf
  Sleep (500)
  
WEnd

Aufgerufen als kompilierte Exe-Datei wird es dann zusammen mit MailStoreHome:

start /wait "" HMSHwE_x64.exe "MailStoreHomePortable\Application\MailStoreHome.exe /c archive --id=1"

Der Rückgabewert kann wie gewohnt per Errorlevel abgefragt werden. 0 bedeuet Erfolgreich, größer als 0 Warnung/Fehler.

start /wait "" HMSHwE_x64.exe "MailStoreHomePortable\Application\MailStoreHome.exe /c archive --id=1"
if %errorlevel% gtr 0 smtpsend.exe...

Download

Das Archiv enthält den Quellcode und jeweils eine Exe-Datei für 32- und 64-bit.

HMSHwE.zip

Nebenbei bemerkt: HMSHwE bedeutet „Hide MailStore Home with Errorlevel“

Vollständig versteckt ausführen ohne Auswertung

Um MailStore Home vollständig versteckt auszuführen kann man auf die „RunCompletelyHidden.exe“ aus dem Beitrag AutoIt: Alle Fenster eines Prozesses ausblenden zurückgreifen:

RunCompletelyHidden.exe C:\Skripte\MailStoreHome.cmd

MailStoreHome.cmd:
start "" C:\MailStoreHomePortable\Application\MailStoreHome.exe /c archive --id=1

Diese Methode hat allerdings den Nachteil, das man (bislang) nicht den Status bzw. Text der „Fortschrittsanzeige“ abrufen kann. Folglich weiß man nicht, ob der Job mit welchem Ergebnis abgeschlossen wurde.

Um MailStore Home dann dennoch zu beenden könnte man nach einer Pause den Prozess beenden. Folgende Zeilen zur „MailStoreHome.cmd“ hinzufügen:

timeout /t 360
taskkill /im mailstorehome.exe /f