Bei einem ca. drei Jahre altem B-t-O Server eines Kunden bestehend aus dem Supermicro SuperChassis 732D2-500B mit einem X10SLH-F Mainboard wurden uns die Festplatten etwas zu warm. Punktuell hatten wir zu Spitzenzeiten bis zu 62°C ermittelt. Das Ganze hängt natürlich von den verbauten Festplatten ab, in diesem Fall vier 15K SAS HDDs, die im Vergleich zu 7K2 HDDs durchaus 10-20°C mehr an (Ab)wärme erzeugen können („Erfahrungswert“, ermittelt an bzw. in diesem System).

Ungut ist, das bei diesem Gehäuse keine Lüftermontage für die HDDs vorgesehen ist und zu allem Überfluss bei den oberen zwei HDDs im Festplattenkäfig Frontseitig die Anschlussplatine für USB und Audio im Weg des Luftstroms sitzt. Eine Möglichkeit wäre nun diese Platine zu entfernen, dies würde zwar den Weg sozusagen frei machen, allerdings kommt dann nur bedingt mehr Frischluft an die HDDs ran.

Da ein paar Gewindebohrungen auf das Basisplatte frei waren, konnte mit ein wenig Lochband ein zusätzlicher 120mm Lüfter hinter dem Festplattenkäfig montiert werden. Dieser Lüfter wurde an den Anschluss „FANA“ angebunden, dieser Punkt wird später noch relevant. Der Festplattenkäfig bleibt um 90° schwenkbar, so das man nach wie vor bequem die Laufwerke erreichen und ggf. austauschen kann.

Damit mehr Durchzug realisiert wird wäre eine Option, alle Lüfter höher Drehen zu lassen. Am einfachsten geht das in dem man den „Fan Mode“ via IPMI bzw. im BMC ändert. Via Web-Interface des Management Moduls lautet der Weg:

• Configuration – Fan Mode (Default: Optimal Speed)

Da allerdings der Rest des Systems mit um die 30°C in Sachen Temperatur entspannt war und ein unnötiger Verschleiss der Lüfter und die zusätzliche Geräuschentwicklung nicht nötig sind, sollte halbwegs gezielt nur der neue HDD-Lüfter schneller laufen. An dieser Stelle kommt der Lüfter-Anschluss ins Spiel, denn Supermicro unterteilt die FAN-Anschlüsse in zwei Zonen: CPU Zone (FAN1 bis FAN4) und Peripheral Zone (FANA).

Da der neue Lüfter an „FANA“ angeschlossen ist, kann man nun mittels IPMI gezielt für diese Zone eine höhere Drehzahl in Prozent konfigurieren. Dies geht mit ipmitool aus Linux heraus:

ipmitool raw 0x30 0x70 0x66 0x01 0x01 0x60

Der vorletzte Wert gibt die Zone an (0 = CPU Zone, 1 = Peripheral Zone).
Der letzte Wert gibt die Drehzahl in Prozent an.

Da der verbaute Lüfter laut Spezifikation maximal 1350 RPM „darf“, sollte dieser nicht auf 100% (0x64, entspricht 1400 RPM) laufen, daher wurde er auf 93,75% (0x60, laut Anzeige 1300 RPM) konfiguriert.

Hat man kein Linux auf dem Server installiert, kann man z.B. aus einer VM heraus die Konfiguration remote über’s Netzwerk durchführen:

ipmitool -I lanplus -H <BMC-IP> -U ADMIN raw 0x30 0x70 0x66 0x01 0x01 0x60

Unter Windows hatte ich leider mit Tools wie ipmicfg (von Supermicro) und ipmiutil keinen Erfolg die Einstellung zu ändern, daher blieb nur die Linux-Lösung.

Die Festplatten bleiben nun im Bereich von 43 – 47°C je nach Last und Einbauposition. In der Regel ist die unterste HDD am kühlsten und die Oberste am wärmsten.

Der Server-Hersteller/-Erbauer meinte auf Nachfrage zu dem Temperaturthema lediglich, das er die Server nach Spezifikation der Hersteller bauen würde und folglich nur die entsprechend freigegebenen Komponenten nehmen würde. In wie weit das zutrifft wurde nicht weiter hinterfragt. Faktisch war es allerdings so, das die Festplatten über ihren maximalen Temperaturbereich hinaus (max. 55°C laut Datenblatt) betrieben wurden. Kommt dann noch etwas Verschmutzung bei den An-/Absaugöffnungen hinzu, könnte es schnell noch schlechter werden. Leider fand sich keine Option, die Festplatten-Temperatur zu überwachen. Man könnte sich allerdings auf Basis der Ausgabe des Avago(LSI)-Kommandozeilen-Tools etwas „basteln“:

C:\Program Files (x86)\MegaRAID Storage Manager>echo. & echo %time% & echo. & st
orcli -PDList -a0 | find /i "Drive Temperature"

14:56:06,44

Drive Temperature :43C (109.40 F)
Drive Temperature :41C (105.80 F)
Drive Temperature :45C (113.00 F)
Drive Temperature :47C (116.60 F)

Quellen:

Any Source – Lüftersteuerung für Supermicro IPMI

STH – Supermicro X9/X10/X11 Fan Speed Control

Thomas Krenn – Wiki – IPMI Konfiguration unter Linux mittels ipmitool

Thomas Krenn – Wiki – Ipmitool zur Remotesteuerung von Servern nutzen

Im März 2018 kündigte Microsoft an, das eine Sicherheitslücke in CredSSP ab April 2018 geschlossen werden soll, dies betrifft unter anderem Remotedesktopverbindungen. Der Rollout der Updates bzw. davon abhängigen Änderungen erfolgte in zwei Schritten.

So wurde mit den April 2018-Updates zunächst die entsprechende Sicherheitsaktualisierung auf Datei- bzw. Systemebene verteilt, die Voreinstellung erlaubte bis dato allerdings noch die Verbindung von unsicheren bzw. ungepatchten Clients. Seit 8. Mai 2018 wurde diese Einstellung allerdings durch die Mai’18 Windows Updates geändert.

Wird nun eine Verbindung von oder zu einem ungepatchten System versucht, erscheint z.B. unter Windows 10 beim Versuch zu einem ungepatchten Windows 7 zu verbinden folgende Fehlermeldung:

Im Idealfall sollten beide Seiten mit aktuellen Updates bestückt sein. Ist dies nicht der Fall, sollte wenn möglich aktualisiert werden oder, wenn es überhaupt nicht anders geht, mittels Gruppenrichtlinie oder Registry die Einstellung geändert werden. Hierzu siehe den Beitrag vom Microsoft Support in den Quellen.

Andere RDP-Clients wie z.B. FreeRDP, ThinClients etc. müssen ebenfalls aktualisiert werden.

Quellen:

golem.de – Microsoft unterbindet RDP-Anfragen von ungepatchten Clients

Microsoft Support – CredSSP updates for CVE-2018-0886

Microsoft TechNet – Security TechCenter – CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability

Grundsätzlich sollte Software wenn möglich aktuell gehalten werden. Vorallem gilt das für durchaus kritische und/oder exponierte System wei z.B. Mailserver, so auch für den MDaemon Messaging Server. Das aktuelle Update empfiehlt sich auch wegen der EFAIL-Thematik.

Wir hatten bislang zwei Auffälligkeiten nach der Aktualisierung, jeweils in Verbindung mit dem „Outlook Connector“, der nun „MDaemon Connector“ heisst:

• Der auf den Arbeitsplätzen installierte Connector verbindet sich nicht mit MDaemon:
  In solch einem Fall den Connector, falls noch nicht geschehen, aktualisieren oder diesen neu installieren.
• Der Zugriff via Outlook Connector ist nicht möglich, die Option im Benutzerkonto unter „Mail-Dienste – Zugriff über IMAP – Zugriff über MDaemon Connector aktivieren“ ist deaktiviert und ausgegraut:
  Die Registrierung und die Lizenz-Anzahl wird zwar richtig angezeigt, aber dennoch kann der Connector nicht genutzt werden. Abhilfe schafft den Connector zu de- und erneut zu aktivieren:Hilfe – Aktivierung ihrer MDaemon-Software – MDaemon Connector deaktivieren/aktivieren

Quellen:

http://archive.altn.com/outlookconnector/Archive/5.5.1/RelNotes_en.html

Update 22.05.2018

Bei einer Installation reagierte der interne Webserver nicht mehr. Dieser lief zwar, aber es konnte kein WorldClient aufgerufen werden. Vermutlich in Folge klappte am 19.05.2018 die automatische Verlängerung des Let’s Encrypt-Zertifikats ebenfalls nicht. Da es sich um keinen dedizierten Dienst handelte und über die Verwaltungskonsole ebenfalls keine Reaktion auf „De-/Aktivieren“ erfolgte, wurde im Task-Manager die „WorldClient.exe“ beendet. Der Webserver startete automatisch neu und war zudem auch wieder erreichbar.

Weiss man von einem Netzwerkgerät nur die MAC-Adresse und das dieses per DHCP seine IP-Adresse erhält, kann man über die grafische Oberfläche schauen, ob man die entsprechende Zuordnung findet oder zielgerichteter per Eingabeaufforderung suchen.

Auflisten aller aktuell vergebenen IP-Adressen:

netsh dhcp server scope <Bereich> show clients

Die Ausgabe lässt sich dann z.B. mit „find“ gezielt durchsuchen:

netsh dhcp server scope <Bereich> show clients | find /i "<MAC-Adresse>"

Beispiel:

netsh dhcp server scope 192.168.2.0 show clients | find /i "ab-cd-ef-gh-ij-kl"

Das Ganze funktioniert auch mit einem Teil der MAC-Adresse. Hilfreich ist dies vor allem bei großen Bereichen.

Getestet unter Windows Server 2012 R2 Standard.

Quelle:

OneManArmy – Windows – see DHCP leases on cmd or powershell with netsh

Es scheint, es sei kein Update der Firmware der ASUS ASMB7 auf die aktuelle Version 2.03, zumindest bei den P9D-I Mainboards (z.B. Wortmann Terra Miniserver G2), möglich. Ganz gleich von welcher ursprünglichen Version man versucht zu aktualisieren, kommt es zu einem Fehler bei der Validierung der neuen Firmware.

So kann man im Moment höchstens auf die Version 2.01 umsteigen. Das Ganze ist dahingehend zusätzlich ärgerlich, da man so weiterhin in Java MD5 reaktivieren muss, damit man die Console verwenden kann:

ASUS ASMB8-iKVM und Java 8 Update 131 oder neuer <- Gilt auch für ASMB7

Diesen Fehler haben wir bei zwei Servern beobachtet.

Ab Version 7.4.0 kann die Business-Ausgabe von ALF-BanCo einen MS SQL Server verwenden. Laut Support ist das die Empfehlung für den Einsatz im Netzwerk mit mehreren Benutzern. Es reicht die Express-Ausgabe des SQL-Servers aus, dieser kann mit Standardeinstellungen installiert werden. Es wird die SQL-Authentifizierung benötigt, diese entweder bei der Installation oder später über das SQL Management Studio aktivieren und den „sa“-Benutzer konfigurieren.

Laut Hersteller behebt die Nutzung des MS SQL-Servers die schlechte Performance im Netzwerk, da nun nicht mehr SQlite auf einer Netzwerkfreigabe zum Einsatz kommt (Support-Aussage: SQlite Aktualisierungsintervall 1s, MS SQL-Aktualisierungsinterval 1ms!) und verbessert das Mehrbenutzer-Erlebnis.

Wir haben eine Server-Migration bei einem Kunden zum Anlass genommen, die neueste Version zusammen mit MS SQL einzusetzen.

Umzug zu MS SQL

Die Migration gestaltet sich relativ einfach:

• ALF-BanCo starten und sich als Administrator anmelden.
• Unter „Datei“ auf „Umzug auf SQL-Server“ klicken und dem Assistenten als auch der PDF-Anleitung folgen.

Etwas Geduld mitbringen und den Virenscanner vorher abschalten. Beim ersten Versuch wurde zunächst eine DLL blockiert und man wunderte sich, warum es nicht weitergeht.

Aufräumen nach dem Umzug

Ist die Umstellung der Datenbank erfolgt, kann die alte Datenbank („HbDat001.alfdb7“) und die Migrationsdateien („_SQL_HbDat001.mdb“, „AdoExport.log“) entfernt werden. Zur Sicherheit sollte man diese allerdings ein paar Tage aufbewahren, falls im Nachhinein noch etwas auffällt.

Die Sache mit der Benutzerverwaltung

Damit die (eingeschränkten) Benutzer dann ebenfalls den MS SQL-Server nutzen, muss bei jedem Einzelnen die Daten geändert werden.

• ALF-BanCo starten.
• Den gewünschten Benutzer auswählen.
• Auf „Daten ändern“ klicken.
• Den Pfad und Namen zur neuen Datenbank-Datei („HbDat001.alfsql7“) angeben.

Für mich sieht das so aus, als ob in der „neuen Datenbank“-Datei der Zugangsweg zum MS SQL hinterlegt ist.

Womöglich lag bei der Frage zu den Benutzern ein Missverständnis mit dem Support vor, jedenfalls speichert ALF-BanCo die Benutzerkonten nicht in der zentralen Datenbank (egal ob Pre- oder Post-MS SQL), sondern lokal auf dem Computer.

Die Benutzerkonten (nicht die Rechteverwaltung!) liegen lokal auf jedem Computer in der Datei

C:\Users\%username%\AppData\Roaming\ALFBanCo7\UserDat7.udb

Diese Datei kann einfach zwischen den Computern kopiert werden. Man muss also nicht auf jedem Computer die Benutzer händisch anlegen oder ändern.

Wir haben bei dieser Gelegenheit mal Ordnung geschafft und eine saubere Benutzerdatenbank angelegt und dann verteilt.

Tipp: Die Optionen-Datei („BanCoUser00x.aop7“) eines jeden Benutzers ebenfalls auf einer Freigabe des Servers ablegen. Für den Fall das Benutzer den Arbeitsplatz wechseln, stehen die eigenen Einstellungen so überall zur Verfügung. Das Ganze gilt natürlich nur, wenn man nicht ohnehin Windows-seitig servergespeicherte Profile verwendet.

Tipp: Die Optionen-Datei der Benutzer z.B. mit dem Namenskürzel benennen („BanCoUser00x.aop7“ -> „BanCoUser00x_AB.aop7“). So lässt sich im Falle einer beschädigten Datei leicht ermitteln, um welche es sich handelt.

Beim Einrichten des Sensors „Terra Server Health via IPMI“ auf einem neuem Wortmann Terra Miniserver wunderte ich mich über viele Meldungen bei den Spannungen, dass das obere kritische Limit erreicht sei.

Im OCC sah das so aus:

Und direkt im BMC dann so:

Ich glaube nicht, das der Server bei diesen Spannungswerten, wären sie real, noch laufen würde. Da beispielsweise mit OpenHardwareMonitor oder HWiNFO (ohne IPMI) keine Auffälligkeiten seitens der Hardware festzustellen waren und der Server zudem ansonsten ebenfalls unauffällig lief, war es naheliegend, das es sich um Messfehler handelt.

Wie war das doch gleich: Wer misst, misst Mist?!

Ein simpler Neustart des BMC änderte nichts. Erst das Zurücksetzen auf Werkseinstellung behob diese „Falschmeldungen“:

• Via Browser am ASMB8-iKVM anmelden.
• Auf „Maintenance – Restore Configuration“ klicken.
• Auf die Schaltfläche „Restore Configuration“ klicken und die anschließende Meldung bestätigen.

Daraufhin startet das BMC mit den Werkseinstellungen neu. Danach muss das ASMB8-iKVM neu konfiguriert werden. Per Vorgabe holt es sich per DHCP eine IP, man kommt je nach Netzwerkinfrastruktur also relativ leicht wieder dran.

Der Wortmann-Support anwortete zwischenzeitlich ebenfalls und empfahl ein Update der Firmware. Diese war allerdings bereits auf den möglichst neuesten Stand.

Da Lexware für so manches Produkt keine automatisierbare Datensicherung anbietet, wird meist auf die Variante „Datenbankdienst beenden, Daten sichern, Dienst wieder starten“ zurückgegriffen. Das funktioniert soweit gut.

Unschön kann allerdings sein, wenn noch Arbeitsplätze verbunden sind, denn dann stürzt die Client-Anwendung ab. Mitunter mit einigen Fenstern mit verschiedenen Fehlermeldungen, so das man erstmal einiges wegzuklicken hat.

Im Idealfall ist es so, das der Lexware-Client oder der gesamte Arbeitsplatz während der Sicherung beendet bzw. heruntergefahren ist. Bei so mancher Umgebung wird das allerdings schlicht vergessen. Abhilfe kann man dadurch leisten, das man vor der Datensicherung den Client beenden lässt. In einem Windows-Domänen-Netzwerk kann das vom Server aus mittels PsKill und einem Skript geschehen. Anbei ein Auszug aus einem Datensicherungsskript:

rem Lexware auf den Arbeitsplaetzen beenden

start Tools\pskill64.exe -nobanner -t \\PC01 "Framework.exe"
start Tools\pskill64.exe -nobanner -t \\PC02 "Framework.exe"

timeout /t 120 /nobreak

rem Lexware Datenbank-Dienst beenden

net stop "Lexware Premium Datenbank"

...

Soweit die aktuelle Variante. In der Vergangenheit wurde PsKill direkt, d.h. ohne „start…“, ausgeführt. Leider kam es dabei immer wieder mal vor, das es hängen blieb. Gut möglich das es an der seinerzeit älteren Version lag. Jedenfalls seit dem Einsatz der aktuellen Version und dem start-Befehl gab es bislang keine Schwierigkeiten mehr.

Kurz notiert: Wenn man via RDP versucht den Client eines Igel UMS zu öffnet und nur kurz das Banner und dann sonst nichts weiter geschieht, klappt irgendwie die Verbindung und/oder der Start nicht.

Bei einem Kunden ist mir das nun so ergangen. Wurde das Ganze mittels mRemoteNG unternommen, startete der Client nicht bzw. stürzte ab, ganz gleich ob als „gewöhnliches“ RDP oder als Konsole. Verbindet man sich direkt mittels mstsc funktioniert es. Die genauen Hintergründe konnten mangels Zeit nicht ermittelt werden.

Womöglich liegt es an der Kunden-Umgebung (Windows Server 2008 R2 Standard), die leicht angestaubte UMS-Version 5.05 oder das seit über einem Jahr keine Windows Updates mehr dort installiert wurden (dieser Kunde lässt keine Wartung machen, immer nur das nötigste und billigste soll es sein).

Ein grundsätzliches Problem lässt sich wohl ausschließen, da bei anderen Kunden die Kombi aus mRemoteNG, Windows Server (irgendwas) und UMS läuft.

Schlägt die Sicherung auf ein Netzwerk-Ziel wie z.B. auf einen Server oder ein NAS beim ersten Mal immer fehl und klappt ab dem zweiten Mal, sollte man die Anmeldung etwas anders einstellen.

Meist tritt dies nach einem Neustart des Computers oder von Bvckup 2 bzw. dessen Dienst (sofern verwendet) auf. Per Voreinstellung verwendet das Programm die hinterlegten Zugangsdaten erst dann, wenn es auf den Netzwerkpfad nicht zugreifen kann. Mitunter ist es dann allerdings bereits zu spät und die Anmeldung scheitert gänzlich und in Folge schlägt der Job fehl.

• Doppelt auf den betreffenden Backup-Job klicken.
• Bei „Backup to“ auf das Schlüsselsymbol klicken.
• Auf „More…“ klicken.
• „Logon“ von „If can’t access the share as is“ auf „Always“ ändern.

Per Voreinstellung wird die Qualität der Audiowiedergabe bei RDP-Verbindungen automatisch geregelt, leider ist das nicht immer optimal. So konnte bereits eine unstete Wiedergabe von iTunes über eine Remotedesktopverbindung zwischen Windows XP- und 7-Computern in der Vergangenheit oder aktuell in einer Kundenumgebung mit gerade mal fünf Terminalservernutzern auf Windows Server 2016 Standard, Gigabit-Netzwerk und Igel ThinClients bei der Wiedergabe von Internetradio hörbare Qualitätseinbußen wahrgenommen werden.

Per Gruppenrichtlinie lässt sich konfigurieren, welche Qualitätseinstellung für die Tonübertragung verwendet wird. Seitens Microsoft ist „Bei konfiguriert“ „Dynamisch“ vorgegeben, was laut Beschreibung bedeutet:

"Bei Auswahl von "Dynamisch" werden die Audiodaten mit einem durch die Bandbreite der Remoteverbindung vorgegebenen Komprimierungsgrad gesendet."

Zu finden ist die Einstellung unter

Computerkonfiguration - Administrative Vorlagen - Windows-Komponenten - Remotedesktopdienste - Remotedesktopsitzungs-Host - Geräte- und Ressourcenumleitung

Dort „Qualität der Audiowiedergabe beschränken“ aktivieren und die gewünschte Qualitätsstufe auswählen:

Client-seitig lässt sich unter Windows in der *.rdp-Datei über folgende Parameter die Qualitätstufe steuern:

audioqualitymode:i:0 (Dynamisch)
audioqualitymode:i:1 (Mittel)
audioqualitymode:i:2 (Hoch)

Am Beispiel von Igel ThinClients ist ab Werk bereits „Hoch“ konfiguriert. Ändern lässt sich dies unter:

System - Registry - rdp - winconnect - sound-compress - Aus
System - Registry - rdp - winconnect - sound-quality - Hoch

Weiter kann bei diesen ThinClients helfen, den verwendeten Treiber zu ändern (ungetestet):

System - Registry - rdp - winconnect - sound-driver - OSS

Quellen:

blog@cloud-client.info – Optimizing Audio quality for RDP connections for IGEL Universal Desktop LX/OS

Microsoft TechNet Forum – Remote desktop audio quality

Microsoft TechNet Forum – Sound and video not working properly on thin client

VPSBlocks – Knowledgebase – Sound Quality of RDP

Nach der nennen wir’s mal unglücklichen Übernahme von Kerio durch GFI und der daraus resultierenden Situation mit monatelang keine Updates und die, die es gab auch noch Schwierigkeiten verursach(t)en, wurde es Zeit sich etwas anderes einfallen zu lassen.

Etwas eigenartig war zudem die Situation, das der DACH-Vertrieb kurz nach der Übernahme sehr aktiv ein anderes Produkt als Kerio angeboten hat. Das wunderte nicht nur uns, sondern auch weitere Partner, wie sich in diversen Gespräche zeigte. Im Kerio-Forum war zudem des öfteren zu lesen, das aufgrund der Probleme mit Abgleich usw. der eine oder andere wohl zu Exchange migrieren will/muss oder sogar getan hat.

Wir nahmen die Schwierigkeiten der vergangenen Monate und die demnächst auslaufende Lizenz beim Kunden zum Anlass, ein Crossgrade von Kerio Connect zu MDaemon Messaging Server vorzunehmen. Zum einen fällt dann die Entscheidung leichter, zum anderen sollten die bekannten Probleme mit Kerio Connect ein Ende finden.

Bemerkung: Wenn von Kerio Connect die Rede ist, ist damit der eigentliche Server zzgl. ActiveSync und Outlook Connector gemeint. Ebenso verhält es sich mit MDaemon Messaging Server, nachfolgend MDaemon genannt, bei dem ebenfalls ActiveSync und MDaemon Connector (vormals Outlook Connector) verwendet wird.

Vorbereitung

Bei der vorhandenen Kerio-Installation mussten nur eine handvoll Postfächer umgezogen geworden, daher hielt sich der Aufwand in Grenzen und wurde manuell durchgeführt. Für größere Installationen muss man sich da eher Gedanken machen, ob und wie man die Daten von A nach B bekommt (z.B. MailStore, imapsync, …).

So eine Migration ist fast immer eine gute Gelegenheit aufzuräumen, so konnten alte nicht mehr benötigte Postfächer zuvor in Outlook als Datendatei (*.pst) exportiert werden. Die Mails ansich kann man sich dabei ggf. sparen, sofern eine Archivierungslösung verwendet wird. In dieser Umgebung war ein MailStore Server vorhanden, von daher reichte es aus die restlichen PIM-Daten (Kontakte, Kalendereinträge, …) zu exportieren.

Ebenfalls eine gute Idee ist es, die Postfachgrößen und Anzahl der Elemente zu prüfen. Mehrere belegte Gigabyte an Speicherplatz zusammen mit zehntausenden Elementen können zu einer langen Laufzeit bei der Migration führen, ferner „mag“ das Outlook auch nicht besonders. Handelt es sich um sehr viele Mails, was in der Regel der Fall ist, sollte man einstellen, das Nachrichten älter als ein bestimmter Zeitraum nach erfolgreicher Archivierung aus dem Postfach gelöscht werden.

Man kann zwar zwei Mail-/Groupware-Server auf einem System installieren, allerdings gibt das immer Heckmeck mit den Ports. Daher wurde vorab ein PC mit MDaemon und Outlook installiert, der für die Dauer der Migration als Quasi-Server herhalten musste. Da sich MDaemon bekanntermaßen schnell und einfach umziehen lässt, stellt das keinen großen Umweg dar.

Die Migration ansich

Am Stichtag wurde dann das Leihsystem vor Ort aufgestellt und der Kerio Connect Outlook Connector dort installiert. Anschließend wurden für jedes zu migriende Postfach ein Outlook-Profil angelegt und darin sowohl Kerio als auch MDaemon eingebunden. Als nächstes wurde die Erstsynchronisation des Kerio Outlook Connector durchgeführt. Auf diese Weise spart man sich die Zeit wenn es dann ans eigentliche Umstellen geht.

Nach Feierabend des Kunden wurde die Zustellung bzw. der Abruf von Kerio Connect, gemeint ist der Server, deaktiviert. Auf dem Leihsystem wurde das jeweils zu migrierende Postach mittels entsprechendem Outlook-Profil aufgerufen, der Kerio Connect sync abgewarted und dann mittels Kopieren und Einfügen die Daten umgezogen.

Je nach Menge der Daten ist dabei etwas Geduld gefragt, mitunter stürzt Outlook auch ab, so das man neu starten muss.

Bemerkung 1: Klappt es mit dem Outlook Connector nicht, kann man Outlook 2013 oder neuer via ActiveSync einbinden und darüber kopieren. Gerade bei dieser unklaren Synchronisations-Thematik in der letzten Zeit zwischen Kerio und Outlook kann man darauf zurückgreifen oder damit noch einen Export der Daten vornehmen.

Bemerkung 2: Apropos Export, mitunter klappt es mit der Export-Funktion von Outlook nicht, alle Daten herauszuholen. Zur Not muss man händisch eine Datendatei anlegen und Ordner für Ordner manuell kopieren.

Bemerkung 3: Natürlich kann auch IMAP und *DAV verwendet werden, dies dann lieber mit Thunderbird als mit Outlook.

Kerio Connect deinstallieren

Bevor man Kerio Connect deinstalliert sollte man zur Sicherheit eine finale Datensicherung erstellen. Danach, wie bei jeder anderen Windows-Anwendung auch, über die Systemsteuerung des Produkt deinstallieren.

Hinweis: Es bleiben die Nutzdaten sozusagen als Rest zurück. Der Standardpfad lautet

C:\Program Files\Kerio

Diese kann man ebenfalls nochmal sichern und dann entfernen.

MDaemon umziehen

Da gibt’s nicht wirklich was dazu zu sagen, das läuft wie immer:

Ein paar Notizen zur Migration von MailStore- und MDaemon-Servern

Nachdem die Daten aus Kerio Connect zu MDaemon kopiert und Kerio Connect deinstalliert war, wurde der MDaemon auf den Kundenserver verschoben.

Clients anpassen

Richtung Finale geht es dann an die Arbeitsplätze. Dort das Outlook-Profil löschen, den Kerio Outlook Connector deinstallieren, den MDaemon Connector installieren, ein neues Outlook-Profil an- und darin das MDaemon-Konto hinterlegen. Outlook starten und den Erstabgleich abwarten.

Leider kommt es immer wieder vor, das Outlook dabei abstürzt. Bislang scheint nur zu helfen, Outlook so oft neu zu starten, bis das der Abgleich abgeschlossen ist. Das kostet leider immer Zeit und Nerven.

Sofern Mobilgeräte (Smartphone, Tablet) verwendet werden, müssen dort die Konten gelöscht und neu angelegt werden.

Hinweis: Selbst wenn Serveradresse, Benutzernamen samt Kennwort, etc. gleich bleiben, müssen die Konten neu angelegt werden!

Da seitens des Kerio Outlook Connectors auf den Clients Reste zurückbleiben, sollte man diese ebenfalls entfernen. Bei diesem Kunden hat das pro PC immer um die 100GB ausgemacht! Der Standardpfad lautet:

%LocalAppData%\Kerio

Nacharbeiten

Sofern z.B. mittels Server-Eye der Kerio Connect überwacht wurde, müssen die entsprechenden Sensoren gelöscht werden. Für MDaemon gibt es leider keine spezifischen Server-Eye Sensoren, den E-Mail-Versand und -Empfang kann man mit Mailroundtrip überwachen.

Hat man an der Kerio-Datensicherung „gedreht“, siehe hier, sollte man dies ebenfalls entfernen.

Wird eine E-Mail-Archivierung wie MailStore Server verwendet, so müssen die Archivierungsaufgaben angepasst werden.

Abschlussbemerkung

Auch wenn für diese Migration ein Abend „drauf gegangen“ ist, so konnte der Kunde am nächsten Tag nahezu wie gewohnt arbeiten. Klar, ein paar Ordner sehen anders aus, im Großen und Ganzen war das allerdings kein Problem.

Durch den Wegfall von Kerio Connect ist nun auf dem Server sogar mehr Speicherplatz frei. Das liegt mitunter an der Art, wie Kerio Datensicherungen erstellt hat. Da bei MDaemon alles im Dateisystem liegt, ist eine Sicherung überaus einfach.

Es gibt ein paar Möglichkeiten Server-Eye auf mehrere Systeme auszurollen, sei es via Active Directory oder Arbeitsgruppe im OCC, via Gruppenrichtlinie oder mittels Skript oder Befehl.

Für letzteres greift man in der Vorbereitung auf die Anleitung zur Verteilung via Gruppenrichtlinie zurück:

Server-Eye – Wissensdatenbank – Server-Eye in Windows Domäne automatisch ausrollen (per GPO)

Letztlich führt man alle genannten Schritte aus. Die einzige Ausnahme ist dabei das Erstellen einer entsprechenden Richtlinie. Den Setup-Befehl führt man dann z.B. via Skript

powershell -Noninteractive -ExecutionPolicy unrestricted -file \\<Server>\<Freigabe>\se_install.ps1

oder z.B. PsExec aus:

psexec64 \\<Computer> -u <Domäne>\administrator -p Kennwort powershell -Noninteractive -ExecutionPolicy unrestricted -file \\<Server>\<Freigabe>\se_install.ps1

Die Ausgabe sieht wie folgt aus:

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Windows\system32>powershell -Noninteractive -ExecutionPolicy unrestricted -fi
le \\srv02\install\se\se_install.ps1
installing Vendor.ServerEye... done
installing ServerEye.Core... done
Finished!

Please visit https://occ.server-eye.de to add Sensors
Have fun!

Ggf. muss am Ende einmal die Eingabetaste gedrückt werden.

Es kann auch mal etwas länger dauern, bis das die Dienste gestartet wurden:

...

installing Vendor.ServerEye... done
installing ServerEye.Core... done
WARNUNG: Warten auf Start des Diensts "Server-Eye Sensorhub (CCService)"...
WARNUNG: Warten auf Start des Diensts "Server-Eye Sensorhub (CCService)"...
WARNUNG: Warten auf Start des Diensts "Server-Eye Sensorhub (CCService)"...
Finished!

Please visit https://occ.server-eye.de to add Sensors
Have fun!

Anschließend sollte das System im OCC erscheinen.

Klappt die Wiedergabe von Ton über eine Remotedesktopverbindung nicht und der Terminalserver meldet „Es ist kein Audiogerät installiert“ so muss man kurz an der Konfiguration drehen.

Der Klassiker besteht darin, das der „Windows-Audio“-Dienst nicht gestartet ist. Dieser Punkt sollte soweit kein größeres Problem darstellen. Zusätzlich kommt hinzu, das Terminalserver-seitig Audio über RDP zugelassen sein muss und, sofern abweichend von der Voreinstellung, auf dem Client in der dortigen Remotedesktopverbindung die Wiedergabe (und ggf. Aufnahme) angehakt sein sollte.

Auf einem Windows Server 2008 R2 Standard der als Terminalserver läuft „klemmte“ es sowohl am Dienst als auch an der Konfiguation:

• Die „Konfiguration des Remotedesktop-Sitzungshosts“ starten.
• Mit der rechten Maustaste auf „RDP-Tcp“ klicken.
• Zur Registerkarte „Clienteinstellungen“ wechseln.
• Im Abschnitt „Umleitung“ den oder die Haken bei „Audio…“ entfernen.

Die Änderung wird nach Ab- und erneutem Anmelden der Sitzung(en) übernommen.

Quelle:

Microsoft – TechNet Forum – Server2008 Terminal Server überträgt keinen Ton

Bei der Fehlersuche eines Mailproblems bei einem Kunden musste sowohl unter Windows als auch Linux geprüft werden, welches System in der Kette einen falschen MX-Eintrag verwendet.

Ausschlaggebend für die Annahme eines DNS-Problems war die Angabe in der Fehlermeldung, die sinngemäss da lautete, das der Host nicht gefunden werden konnte.

Unter Windows können die MX-Einträge mittels nslookup angezeigt werden:

nslookupset q=MX<Domain>

Quelle:

Microsoft TechNet – Überprüfen der Konfiguration von MX-Einträgen mithilfe von Nslookup

Unter Linux gibt es mindestens zwei Befehle die man nutzen kann:

host -t mx <Domain>
dig <Domain> mx

„host“ steht beispielsweise ab Werk auf Ubuntu als auch auf der Securepoint UTM (via ssh) zur Verfügung.

Quelle:

nixCraft – Linux / UNIX: DNS Lookup Command

Letztlich lag die Ursache darin, das im Postfix auf einem Ubuntu-Server in „transport“ für eine Domain ein Mailserver der nicht mehr existierte eingetragen war.

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.

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 damit die RemoteApps vollstaendig laden/starten koennen

 timeout /t 60 /nobreak

rem ---

rem Trennen und/oder Abmelden

 rdp.exe /remoteapp:"||Trennen" /v:%RDPServer% /domain:%RDPDomain% /u:%RDPUsername% /pe:%EncryptedRDPPassword%
 REM start ClickDiscRAWa-x64.exe <- Siehe Update vom 15.11.2018
 timeout /t 60 /nobreak
 taskkill /im mstsc.exe /f

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.

Update 15.11.2018

Leider erwies sich „ClickDiscRAWa-x64.exe“ nicht als zuverlässig in diesem Kontext. Von daher besser auf die Kombi aus „timeout“ und „taskkill“-Lösung setzen. Das Skript wurde entsprechend geändert.

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.