Quantcast
Channel: server – Andy's Blog
Viewing all 344 articles
Browse latest View live

MDaemon: Antivirus aktualisiert nicht (mehr)

$
0
0

Unter Umständen kommt es vor, das die automatische Aktualisierung der Virenschutz-Pattern/-Signaturen unter MDaemon Email Server nicht mehr funktioniert.

Ein Grund, bei Einsatzes von MDaemon AntiVirus, kann eine abgelaufene Lizenz oder fehlerhafte Aktivierung sein. Ein weiterer Grund kann ein nicht-vorhandener oder fehlerhafter Zeitplan sein.

Den aktuellen Stand der Signaturen kann man unter „Sicherheit – AntiVirus – AntiVirus – AV-Aktualisierung“ einsehen:

Ein manuelles Aktualisieren, die Ergebnisse der Aktualisierung sowie den Zeitplan kann man über die entsprechend beschrifteten Schalflächen einsehen. Funktioniert die Aktualisierung trotz eines vorhandenen Zeitplans nicht, dann diesen Löschen und neu erstellen:


Windows: Freigegebener EPSON-Drucker gibt verzögert aus

$
0
0

Vor kurzer und glücklicherweise vor dem März’21-Windows Update-Debakel wurde bei einem Kunden ein betagter Kyocera-Drucker durch einen EPSON WorkForce Pro WF-C579RB ersetzt.

Das neue Gerät wurde wie gewohnt ans Netzwerk angeschlossen, der Drucker-Treiber heruntergeladen und auf dem Server installiert, freigegeben und auf den Clients verbunden. Soweit, so normal. Die Testseite vom Server aus klappte ebenfalls ohne Auffälligkeiten.

Die Überraschung folgte dann auf den Arbeitsplätzen, alle samt Windows 10 Pro (der Server übrigens Windows Server 2012 R2 Standard). Sämtliche Ausdrucke erfolgten mit mindestens 30 – 45 Sekunden Verzögerung. Uff, was ist das auf einmal. Also angefangen zu Suchen. Die Anschlusseinstellungen von RAW als LP geändert, die erweiterten Druckeigenschaften deaktiviert, nicht über den Spooler sondern direkt ausdrucken, usw. usf. es half alles nichts.

Dann kontaktiert ich parallel unseren Servicepartner und EPSON direkt. Der Serviceleiter unseres Partners fragte zunächst Versionsstände von Treiber und Firmware ab (alles up-to-date so ganz nebenbei) und schlug vor die Anschlussart zu ändern. RAW und LP war da schon durch, fehlte noch der EPSON-eigene Anschluss, da funktionierte entweder noch weniger oder genauso verzögert. Vom Hersteller selbst kam von einem Servicemitarbeiter nur ein Textbaustein, das es an der Netzwerkverbindung liege müsse. Äh, nein, Ping, Zugriff auf’s Web-Interface und eben die Ausdrucke direkt vom Server aus war alles super.

Als nächstes installierte ich auf zunächst zwei Arbeitsplätzen den Drucker direkt ohne den „Umweg“ über den Server zu nehmen, einfach um zu schauen, ob es dann besser sei (so die Hoffnung), aber auch das half nichts. Ratlosigkeit machte sich breit.

Zu guter Letzt hab‘ ich dann den eigentlich passenden Drucker-Treiber durch den Universal Drucker-Treiber von EPSON ersetzt und siehe da, es rennt. In der Zwischenzeit konnte ich das Ganze auch noch mit einem EPSON WorkForce Pro WF-C5790DWF ebenfalls beobachten und lösen. Ich hoffe das nun dieser Spuk vorbei ist.

Drive Snapshot und Hyper-V Replikat (Replica)

$
0
0

Möchte man mit Drive Snapshot einen Hyper-V Server sichern, auf dem die Replikation der virtuellen Maschinen aktiv ist, so gibt es ein paar wenige Dinge zu beachten.

Grundsätzlich kann man wie evtl. gewohnt aus den virtuellen Computer heraus eine Datensicherung durchführen, hieran ändert sich nichts und dies ist völlig unabhängig von der Replikation. Möchte man allerdings vom Host aus die Datensicherung durchführen, so ist es eine gute Idee die Replikation zunächst zu pausieren und anschließend fortzusetzen.

Per Powershell geht dies mit folgenden Befehlen:

rem Hyper-V Replikation (Replica) für alle virtuellen Computer pausieren/anhalten

 powershell Suspend-VMReplication *

rem Die Datensicherung durchfuehren

 snapshot64.exe ...

rem Hyper-V Replikation (Replica) für alle virtuellen Computer fortsetzen

 powershell Resume-VMReplication *

Statt auf alle virtuellen Computer einzuwirken, kann man gezielt Einzelne ansprechen:

powershell Suspend-VMReplication <VM-Name>
powershell Resume-VMReplication <VM-Name>

Gibt es virtuelle Computer für die keine Replikation aktiviert ist, so erhält man eine Fehlermeldung:

Suspend-VMReplication : Der Vorgang kann nicht ausgeführt werden, solange sich der virtuelle Computer "<NAME>" im
derzeitigen Replikationsstatus befindet.
In Zeile:1 Zeichen:1
+ Suspend-VMReplication *
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Suspend-VMReplication], VirtualizationException
+ FullyQualifiedErrorId : InvalidState,Microsoft.HyperV.PowerShell.Commands.SuspendVMReplication

Für Resume dann quasi das Gleiche:

Resume-VMReplication : Der Vorgang kann nicht ausgeführt werden, solange sich der virtuelle Computer "<NAME>" im derzeitigen Replikationsstatus befindet.
In Zeile:1 Zeichen:1
+ Resume-VMReplication *
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Resume-VMReplication], VirtualizationException
+ FullyQualifiedErrorId : InvalidState,Microsoft.HyperV.PowerShell.Commands.ResumeVMReplication

Beides hat keine Auswirkungen und kann ignoriert werden.

In Verbindung mit Drive Snapshot und anderen Backup-Lösungen ist dann zu beachten, das alle Laufwerke die in Verbindung mit dem Hyper-V Host und der zu sichernden virtuellen Computer stehen in die Datensicherung mittels Schattenkopien (VSS, bei Drive Snapshot mit „–AllWriters“) einzubeziehen sind!

Die Datensicherung kann übrigens sowohl auf dem Hyper-V Server ausgeführt werden, auf dem sich die aktiven virtuellen Computer befinden oder auf dem Replikatserver. Letzteres bietet den Vorteil, das die Ausführung der Datensicherung keine Auswirkung auf den laufenden Betrieb hat. Nachteil kann dann wiederum sein, das die Wiederherstellung aufwendiger ist.

Persönlich ziehe ich die Datensicherung des Hyper-V Servers auf dem die virtuellen Maschinen ausgeführt werden vor, der Replikatserver wird in der Regel nicht gesichert. Es kommt aber immer auf das jeweilige Szenario an!

Quellen und Links:

Microsoft – Docs – Suspend-VMReplication

Microsoft – Docs – Resume-VMReplication

itsimple.info – HYPER-V RESUME REPLICATION SCRIPT

Microsoft – Docs – Why backup a Replica VM?

Altaro – What is Hyper-V Replica and how does replication work?

Exchange Server und die aktuellen Sicherheitslücke(n)

$
0
0

Man kann sich als ITler aktuell den Meldungen zu der schweren Sicherheitslücke in Microsoft’s Exchange Server und nicht installierter Updates kaum entziehen.

Microsoft beschrieb den Angriff auf eine 0-Day-Lücke bereits am 02.03.2021, wobei es wohl Angriffe bereits im Januar 2021 gegeben haben soll. Zu einem Massenproblem wurde das Ganze erst dadurch, das der oder die Angreifer in die Breite gegangen sind, sprich: Massenhaft Systeme infiltrierten. Das BSI warnt und die Angelegenheit schafft es in die Nachrichten wie der Tagesschau. Dies zeigt wie gravierend das Problem ist.

Mitunter rufen Lieferanten oder Dienstleister sowie Kollegen an oder es kommen E-Mails zu diesem Thema und welcher Hersteller/Anbieter wie unterstützen kann. Alleine heute z.B. zwei Mails von Server-Eye, eine von EBERTLANG (Exchange-Hack: So helfen ESET und MailStore bei kompromittierten Systemen), usw. Einzig etwas gewundert hat mich, das ich von Securepoint noch nichts gehört habe, im Forum gibt es allerdings bereits einen Thread dazu:

Securepoint Support Forum – Exhange hinter reverseproxy meldung bsi 6.3

Auf Seiten wie die vom heise-Verlag bekommt man ebenfalls jede Menge Informationen:

heise – Exchange-Hack: Welche Maßnahmen Unternehmen jetzt ergreifen müssen

heise – Analyse: Exchange und die Cyber-Abschreckungsspirale

Vor etlichen Jahren habe ich mich bereits vom Exchange Server verabschiedet und helfe nur noch ab und an aus, wenn mal Not am Admin ist, auf dem aktuellen Stand bin ich jedenfalls nicht mehr.

Problemfall: Updates für den Exchange Server

Während das Aktualisieren von Windows und so manch weiteren Microsoft-Produkten über die Windows Updates erfolgt, ist oder zumindest war das beim Exchange Server nicht der Fall. Man muss sich über die jeweilige Admin-Konsole selbst die Versionsnummer heraussuchen und dann gewissermaßen Wissen was diese bedeutet. Hinzu kommt das der Exchange Server aus vielen Komponenten besteht und Abhängigkeiten zu Windows-Diensten/Rollen hat. Insgesamt also recht komplex und aus menschlicher Sicht durchaus nachvollziehbar, wenn einem weniger geübten Exchange-Admin da mal was durchrutscht.

Der MDaemon Email Server oder weitere Produkte wie z.B. Kerio Connect sind da wesentlich kompakter und erheblich einfacher zu Aktualisieren. So muss lediglich ein Setup durchlaufen werden, welches am Beispiel von MDaemon sowohl via CLI oder per integriertem Mechanismus automatisiert werden kann.

Ich drücke jedenfalls allen Kollegen die Daumen, das sie schnell und gut diese Sache hinter sich lassen können und hoffentlich nichts schlimmeres passiert ist bis zum Einspielen der Updates.

Update 13.03.2021 – 1

Dieser Beitrag bei Deskmodder.de wirft (imho) weitere Fragen auf. Microsoft wusste demnach von der Lücke und womöglich durch ein internes Leck kam das Ganze erst so richtig ins Rollen:

Microsoft untersucht Leak beim Angriff auf die Exchange Server

Update 13.03.2021 – 2

Verzeiht mir diesen dummen Spruch, aber der kam mir gerade eben beim Lesen des nachfolgenden Beitrags in den Sinn: „Wenn du denkst es geht nicht mehr, kommt von irgendwie ’ne Ransomware daher.“

heise – Exchange Server: Angreifer nutzen Schwachstellen für Ransomware „DearCry“

Jeder Admin der Exchange Server betreut und gerade mit ungepatchten oder gar bereits infizieten Systemen zu tun hat tut mir aufrichtig Leid. Keep calm & carry on!

MDaemon: Kein ActiveSync mehr seit der Windows Updates vom März’21?

$
0
0

Die Windows Update vom März 2021 sorgen weiter für Ungemach, zwar hauptsächlich in Sachen Drucker oder Druckvorschau, aber manchmal gibt es noch weitere „Kollateralschäden“.

Bei einem recht neuem Kunden der seine IT selbst verwaltet und seit langem den MDaemon Email Server auf einem Quasi-Server unter Windows 10 Pro verwendet streikte ActiveSync seit dem Patchday.

Ein näherer Blick zeigte, dass das Problem weit- und tiefergehender ist. Beim ersten Verbindungstest via Browser und URL (ganz gleich ob via Internet oder lokal) fiel zunächst auf, das auf die https-Anfrage sogar mit dem richtigen Let’s Encrypt-Zertifikat geantwortet wird, aber dann kam gleich ein „404 Not Found“.

Beide URLs, sprich die zum Webmail (aka WorldClient)

https://<fqdn>

und die zu ActiveSync

https://<fqdn>/Microsoft-Server-ActiveSync

zeigten diesen Fehler.

Die entsprechenden Teile im MDaemon, sprich Webmail und ActiveSync, sind aktiv. Seltsam. Also mit NirSoft’s CurrPorts mal die Port-Belegung angeschaut („netstat -ano“ geht natürlich auch, CurrPorts finde ich persönlich hübscher, zumal man die zugehörigen Prozesse gleich mit aufgelistet bekommt) und da sah man dann, das der Port 443/tcp mehrfach belegt ist.

Da gab es die gewollten Bindungen durch die „WorldClient.exe“, das ist der Webserver des MDaemon für Webmail und ActiveSync, aber auch Bindungen auf „SYSTEM“ mit der PID „4“. Nach der Änderung von Port 443/tcp auf eine andere Nummer konnte der MDaemon-eigene Webserver wieder erreicht werden, die „SYSTEM-Bindung“ blieb allerdings bestehen.

Der erste Gedanke meinerseits in solchen Situationen ist immer: Da läuft bestimmt ein IIS, also der Webserver von Microsoft. Ein Blick in die Dienste-Liste sorgte allerdings für Ernüchterung, da der „WWW-Publishingdienst“ zwar installiert aber nicht gestartet und sogar deaktiviert ist.

Komisch ist zudem, das sozusagen ab Werk der IIS nicht einfach eine Bindung zu 443/tcp für https mit auch noch dem „richtigen“ Zertifikat von selbst macht. Als vorläufigen Workaround wurde zunächst im Firewall-Router des Kunden die Port-Weiterleitung geändert, damit ActiveSync erstmal wieder läuft. Die Abklärung zu diesem Port-Konflikt sollte später erfolgen.

Bei einem weiteren Termin wurde dann zusammen mit dem Support von EBERTLANG danach geschaut. Der IIS ist zwar installiert, wird allerdings nur für FTP genutzt, wie bereits erwähnt ist der WWW-Dienst deaktiviert. Zur Sicherheit wurden dennoch die Bindungen überprüft, dort war allerdings nichts in Richtung 443 vorhanden.

Interessant wurde es dann in der Eingabeaufforderung: Nach Absetzen des Befehls

net stop http

und dem Bestätigen das abhängige Dienst beendet werden dürften kam soweit erstmal die Bestätigung der jeweiligen Dienste-Stops:

Die folgenden Dienste hängen vom Dienst HTTP-Dienst ab.
Das Beenden des Dienstes HTTP-Dienst beendet auch diese Dienste.

UPnP-Gerätehost
SSDP-Suche
Druckwarteschlange
Routing und RAS
Funktionssuche-Ressourcenveröffentlichung

Möchten Sie diesen Vorgang fortsetzen? (J/N) [N]: J
UPnP-Gerätehost wird beendet.
UPnP-Gerätehost wurde erfolgreich beendet.

SSDP-Suche wird beendet.
SSDP-Suche wurde erfolgreich beendet.

Druckwarteschlange wird beendet.
Druckwarteschlange wurde erfolgreich beendet.

Routing und RAS wird beendet..
Routing und RAS wurde erfolgreich beendet.

Funktionssuche-Ressourcenveröffentlichung wird beendet.
Funktionssuche-Ressourcenveröffentlichung wurde erfolgreich beendet.

Systemfehler 1051 aufgetreten.

Ein Stoppzeichen wurde an einen Dienst gesendet, von dem andere Dienste abhängen.

Denn Fehler am Ende ignorieren wir jetzt einfach mal. Anschließend wurde Dienst für Dienst wieder gestartet und dazwischen beobachtet, ob der Port 443 wieder irgendwie belegt ist. Kurzum: Der Übeltäter ist „Routing und RAS“ (RRAS). Warum dieser den Port belegt konnten wir nicht klären. Da bislang nach der Beendigung dieses Dienstes keine Probleme auftraten haben wir ihn auf „Deaktiviert“ gesetzt.

So ganz zufrieden bin ich mit dieser Lösung nicht, konnte allerdings bislang leider noch ermitteln was da genau passiert. Ganz unbekannt sind diverse Probleme in dieser Richtung wohl nicht:

superuser  Why is the ‚System‘ process listening on port 443?

Vielleicht ergibt sich ja noch etwas. Jedenfalls danke ich an dieser Stelle dem Support von EBERTLANG für die tolle Unterstützung.

Server-Eye: S.M.A.R.T.-Sensoren liefern nur zeitweise Daten

$
0
0

Ein sehr kurioses Problem haben wir seit ein paar Tagen auf einem PC. Sensoren von Server-Eye die den Festplatten-Status abfragen (PC Gesundheit, SMART Gesundheit) liefern keine Werte mehr.

So melden die Sensoren schlicht

Nicht unterstützt
Es wurden keine unterstützten Festplatten gefunden!

Ruft man CrystalDiskInfo aus dem Ordner

C:\Program Files (x86)\Server-Eye\service\993\CrystalDiskInfo

direkt auf, klappt alles. Ebenso ein Aufruf von

DiskInfo64.exe /CopyExit

generiert den Bericht samt „Smart“-Ordner. Im Server-Eye-Log unter

C:\ProgramData\ServerEye3\logs

genauer gesagt der Datei „main_agents.log“ findet sich folgendes:

21.03.16 17:16:34 DEBUG ServerEye.Agents.Helpers.HDD.CrystalDiskInfo - executeCLIAndGetResult: Finished executing CrystalDiskInfo, now validating result
21.03.16 17:16:34 DEBUG ServerEye.Agents.Helpers.HDD.CrystalDiskInfo - executeCLIAndGetResult: Could not find the smartPath C:\Program Files (x86)\Server-Eye\service\993\CrystalDiskInfo\Smart
21.03.16 17:16:34 DEBUG ServerEye.Agent.Generics.GenericAgent - startAgent: agent:SMART Gesundheit | result executed | SMART Overview
----------------------------------
--ERROR: No supported disk found!!

Richtig seltsam ist, das es lediglich unterm Tag, z.B. von 07:00 – 17:00 Uhr nicht funktioniert. In der Nacht, wenn der PC per WoL gestartet und eine Datensicherung durchgeführt wird, klappt die S.M.A.R.T.-Abfrage ohne Probleme.

Mit dem Support zusammen geschaut konnte sowohl der Virenschutz als auch die Berechtigungen sowie UAC ausgeschlossen werden. Ein Update von CrystalDiskInfo half ebenfalls nicht. Ein Test des Aufrufs mittels Aufgabe im SYSTEM-Kontext zeigt, das weder Bericht („DiskInfo.txt“) noch der SMART-Ordner erstellt werden.

Ich bin dann mal dazu übergegangen den Aufruf mittels NSudo durchzuführen, um zu sehen ob es irgendwelche Fehlermeldungen im Zusammenhang mit dem SYSTEM-Konto unter dem die Dienste laufen gibt. Aber natürlich funktioniert es so ohne Probleme.

Um zu sehen ob der Aufruf generell via Aufgabe funktioniert habe ich dann mal ein kleines Skript geschrieben:

@echo off

cd "C:\Program Files (x86)\Server-Eye\service\993\CrystalDiskInfo"

echo %date% %time% - hello world > SMART.log

DiskInfo64.exe /CopyExit

echo %errorlevel% >> SMART.log

Die „SMART.log“ wird geschrieben, aber kein Bericht oder SMART-Ordner von CrystalDiskInfo. Es scheint, als wird CrystalDiskInfo nicht ausgeführt.

Ein komplettes De- und erneutes Installieren von Server-Eye half auch nichts. Einen Zusammenhang mit der Benutzeranmeldung hatte ich auch mal vermutet, kann dies aber weder bestätigen noch komplett ausschließen. Die Tests dazu fielen unterschiedlich aus.

Aktuell sind alle Beteiligten ratlos was da passiert. Vielleicht habt ihr eine Idee?

Apache, .htaccess und GeoIP

$
0
0

Möchte man Zugriffe aus bestimmten Ländern auf einen Webserver erlauben oder blockieren, bietet es sich an entweder (sofern vorhanden) dies in der Firewall zu regeln oder alternativ direkt auf dem Webserver.

Am Beispiel vom Apache Webserver und der „.htaccess“-Datei kann dies so aussehen:

order allow,deny
deny from 2.60.0.0/19
deny from 2.60.32.0/19
deny from 2.60.64.0/19
deny from 2.60.96.0/19
allow from all

Das ist nur ein kleiner Ausschnitt, denn die IP-Listen für einzelne Länder oder gar Kontinente sind sehr umfangreich. Es gibt mehrere mögliche Quellen aus denen man entsprechende IP-Listen bzw. gleich die passende Syntax für „.htaccess“ (und weitere) beziehen kann. Anbei ein paar Beispiele:

Country IP Blocks – Create an Access Control List to Block Countries or Continents

IP2Location – Block Visitors by Country Using Firewall

blog.erben.sk – Country CIDR IP ranges (oder direkt zu Download der Listen)

Quellen:

Hostinger – Tutorials – How to Allow or Block Visitors from Specific Countries Using .htaccess

raymond.cc – 8 Ways to Block Visitors to Your Website by Country

Der MDaemon-Dienst startet nicht erfolgreich nach einer Let’s Encrypt-Verlängerung oder einem Server-Neustart

$
0
0

Gleich Vorweg möchte ich erwähnen, das die im Titel genannten „Fehler“ nichts direkt mit dem MDaemon Email Server zu tun haben. Die jeweiligen Ursachen liegen an den zwei unterschiedlichen Servern, da diese nach heutigem Maßstab nicht mehr die Schnellsten sind und beispielsweise noch mit Festplatten (statt SSDs) arbeiten.

Ironischerweise hatte ich die letzten Tage gleich zwei Fälle, bei denen der MDaemon-Dienst nicht erfolgreich automatisch gestartet ist. Beides sind Windows Server 2012 R2, also nach heutigem Stand (März 2021) schon ein paar Tage alt und auf beiden Laufen noch so Dienste wie z.B. Lexware (Datenbank) und mehr.

Bei dem einen Server startet regelmässig der MDaemon-Dienst nicht mehr, nachdem das Let’s Encrypt-Zertifikat verlängert wurde. Laut Ereignisprotokoll antwortet der Dienst nicht in der vorgegebenen Zeit. Abhilfe schafft hier ein kleines Skript, das nachschaut ob der Dienst läuft und wenn nicht, diesen dann startet:

@echo off

rem In das Arbeitsverzeichnis wechseln

 cd "C:\Scripts\MDaemon"

rem Aeltestes Protokoll entfernen, voriges Protokoll umbenennen

 del /q MDaemon-prev.log
 ren MDaemon.log MDaemon-prev.log

rem Pruefen, ob der MDaemon-Dienst ausgefuehrt wird.
rem Falls dieser nicht laeuft dann den Dienst starten.

 net start | find /i "MDaemon"

if %errorlevel% gtr 0 (
 echo %date% - %time% - Der MDaemon-Dienst wird nicht ausgefuehrt. Der Dienst wird gestartet: >> MDaemon.log
 net start "MDaemon" >> MDaemon.log 2>&1
 net start "MDaemon Remote Administration Server"
 Tools\smtpsend.exe -f -t<Empfänger> -h127.0.0.1 -sMDaemon-Dienst -iMDaemon.log -lu<Anmeldename> -lp<Kennwort>
) else (
 echo %date% - %time% - Der MDaemon-Dienst wird ausgefuehrt. >> MDaemon.log
 REM Tools\smtpsend.exe -f -t<Empfänger> -h127.0.0.1 -sMDaemon-Dienst -iMDaemon.log -lu<Anmeldename> -lp<Kennwort>
)

Wie man sieht, wird zudem ein Protokoll und ggf. eine E-Mail versendet. Dieses Skript via Aufgabe ausgeführt zu einem Zeitpunkt, an dem der Email Server definitiv laufen sollte (beispielswiese in der Nacht außerhalb von Backup-, Let’s Encrypt-, Update- oder anderen Zeitfenstern) stellt den Dienst bei Bedarf wieder her. Natürlich kann man auch mit einem Monitoring seiner Wahl den Dienst-Status überwachen und reagieren lassen.

Bei Nummer Zwei startet der MDaemon-Dienst beispielsweise nach Windows Updates oder der automatischen Aktualisierung des MDaemon an sich (mit anschl. Windows-Neustart) nicht erfolgreich. Auch hier kommt es zu einem Timeout in der Dienste-Verwaltung.

Abmildern kann man dies mit einer Änderung der Dienst-Konfiguration:

  • Die Eigenschaften des MDaemon-Dienstes bearbeiten.
  • Den „Starttyp“ von „Automatisch“ auf „Automatisch (Verzögerter Start) ändern.
  • Optional: Auf der Registerkarte „Wiederherstellung“ bei „Erster Fehler“ „Dienst neu starten“ auswählen.

Zudem kann man das obige Skript ebenfalls hierfür verwenden, um sozusagen eine weitere Maßnahme zur automatischen Fehlerbehebung zu etablieren.

Der Vollständigkeit halber: Selbstredend könnte man die Timeouts in Windows ändern, das gilt dann allerdings für alle Dienste und ob man das wirklich möchte ist etwas anderes.


Den MDaemon Email Server automatisch Updaten

$
0
0

Während die ganze (IT-)Welt und sicherheitsbewusste Menschen über ungepatchte, gar abgekündigte Exchange Server spricht, hatte ich es bereits in meinem Beitrag dazu sowie an anderen Stellen anklingen lassen, das man den MDaemon Email Server einfacher und vor allem automatisch Aktualisieren lassen kann.

Das Ganze soll nun kein Seitenhieb auf den Exchange Server sein, jede Lösung am Markt hat seine Daseinsberechtigung. Für kleine bis mittlere Umgebungen ist zudem der Exchange Server aufgrund seiner recht hohen Voraussetzungen nicht unbedingt geeignet. Von den Cloud-Lösungen aus Redmond und Datenschutz als Alternative fange ich hier jetzt gar nicht erst an. Soviel dazu.

Ab Werk prüft der MDaemon Email Server regelmäßig, ob eine neue Version zur Verfügung steht und informiert den Postmaster darüber. Seit einigen Versionen ist es zudem möglich, die Aktualisierung automatisch durchführen zu lassen. Das Ganze funktioniert freilich nur wenn es

  • eine gültige Aktualisierungsgarantie gibt und
  • die Konfiguration entsprechend eingestellt ist.

Beides ist kein Hexenwerk. Eine Aktualisierungsgarantie macht auf jeden Fall Sinn, damit man immer die neueste Version nutzen kann und darf, das sollte selbstverständlich sein, gerade auch im Hinblick auf die Sicherheit. Letzteres, sprich die Konfiguration, ist nur einmalig und schnell ein-zwei Haken setzen.

Unter „Einstellungen – Voreinstellungen – Voreinstellungen – Aktualisierungen“ wird zum einen die Benachrichtigung und zum anderen der automatische Abruf samt Installation konfiguriert. Als ein weiteres Goodie können zudem alte Installationsdateien sozusagen von selbst entfernt werden. Das spart Speicherplatz und sorgt dafür, das man nicht langsam aber sicher das Laufwerk „zumüllt“.

Einzig zu beachten ist, das ggf. nicht nur der Dienst, sondern auch das zugrunde liegende Windows-System neu gestartet werden, entsprechend sollte man den Zeitpunkt mit Bedacht wählen!

Der Postmaster wird in Folge der Automatik entsprechend informiert. So erhält eine Nachricht wie diese:

MDaemon wurde automatisch auf Version 21.0.1 aktualisiert.

Sie erhalten eine Übersicht über die Änderungen in der neuesten verfügbaren Version unter http://files.altn.com/MDaemon/Release/RelNotes_ge.html.

Sie erhalten eine Übersicht über die Änderungen in der installierten Version (diese kann von der neuesten Version verschieden sein) in der Datei MDaemon\docs elnotes_ge.html auf Ihrem MDaemon-Server.

Vielen Dank dafür, dass Sie MDaemon einsetzen!

Mit freundlichem Gruß,

Ihr Vertriebs- und Support-Team für MDaemon

**Diese Nachricht wurde durch MDaemon automatisch erstellt.**

In den Relaese Notes kann man zudem wunderbar herauslesen was sich alles geändert hat, schön aufgeteilt ob Fehlerbehebung, Sicherheitsupdate oder Neuerung.

Hat man zudem beispielsweise den MDaemon Connector in Gebrauch erhält man ebenfalls zu diesem eine Benachrichtigung:

Versionsinformationen zum MDaemon Connector v7.x
MDaemon Connector 7.0.3 - 2021-03-16
BEHOBEN
• [24148] Wurde eine Besprechungseinladung über ein anderes MD-Connector-Benutzerkonto im selben Profil versandt, so wurden der zugehörige Termin nicht erstellt, und die Einladung selbst nicht versandt; behoben
• [24555] Nach der Umstellung auf den MDaemon Connector 7.0.2 wurde das Symbol der Büroklammer für Nachrichten mit Dateianlagen irrtümlich nicht angezeigt; behoben
• [24590] Aus Nachrichten, die über ein MDaemon-Connector-Benutzerkonto versandt wurden, wurden die Nachrichtentexte entfernt, falls das erste Benutzerkonto im Profil kein MDaemon-Benutzerkonto war; behoben
• [24591] Die Funktion, gesendete Nachrichten in einen bestimmten Ordner zu speichern, verschob die Nachrichten irrtümlich nicht mehr in den angegebenen Ordner; behoben
• [24607] Kontaktgruppen, die als Dateianlagen weitergeleitet wurden, waren beim Eingang beim Empfänger defekt; behoben
• [24638] Bei Nutzung von Microsoft Outlook 2010 wurden Antworten auf Besprechungsanfragen nicht versandt; behoben
...

Hier bekommt man direkt das Change Log präsentiert (Das Obige ist nur ein Auszug). Apropos MDaemon Connector: Dieser wird auf den Arbeitsplätzen i.d.R. automatisch aktualisiert. Die entsprechende Voreinstellung dazu findet sich unter

Einstellungen - MDaemon Connector - MC-Client-Einstellungen - Verschiedenes

Möchte man die MDaemon Connector-Aktualisierung selbst mittels Gruppenrichtlinie oder anderer Deployment-Methoden verteilen, so ist dies ebenfalls möglich. Seitens des Herstellers steht zum einen eine Setup-Datei auf dem „MDaemon-Server“ im Ordner

C:\MDaemon\WorldClient\HTML

und als Download unter

MDaemon.de – Downloads

zur Verfügung. Die *.exe-Datei kann einfach wie folgt automatisch und silent ausgeführt werden:

mdaemonconnectorclient32.exe /s

Eine *.msi- und *.mst-Datei (Microsoft Installer) für GPO und Co. steht zum Download unter obiger Adresse zur Verfügung.

CA-Zertifikat per OpenSSL ermitteln

$
0
0

Witzige kleine Angelegenheit: Ein Kunde betreibt keinen eigenen Mailserver und in Folge muss das neue EPSON-Multifunktionsgerät bzw. dessen E-Mail-Teil an Strato angebunden werden.

Die E-Mail-Einstellungen als solches werden via Web-Interface unter „Netzwerk“ eingestellt, soweit, so einfach. Beim Test kommt es allerdings zu einem Fehler der glücklicherweise auch gleich quasi erklärt wird. Die Meldung verweist schlicht auf ein fehlendes Root-Zertifikat.

Anscheinend ist es am Werk so, das die Geräte nur die Zertifikate mitbringen die für den Betrieb der EPSON Cloud Services benötigt werden. Andere öffentliche Zertifizierungsstellen kennt es einfach nicht.

Abhilfe ist einfach: Unter „Netzwerksicherheit – CA-Zertifikat“ kann man bis zu zehn Root-CA-Zertifikate importieren. Das führte jetzt allerdings zur nächsten Frage: Wie ermittelt man das Root-Zertifikat für einen E-Mail-Server?

Via Browser bei Webservern ist das einfach, das hilft in diesem Fall-Beispiel allerdings wenig, da Strato für Web- und E-Mail-Server verschiedene Ausgabestellen verwendet. Eine kleine Abfrage via OpenSSL zeigt die Zertifikatskette auf:

openssl s_client -servername smtp.strato.de -connect smtp.strato.de:465

CONNECTED(0000019C)
depth=1 C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, O = Strato AG, OU = Rechenzentrum, ST = Berlin, L = Berlin, CN = smtp.strato.de
verify return:1
---
Certificate chain
0 s:C = DE, O = Strato AG, OU = Rechenzentrum, ST = Berlin, L = Berlin, CN = smtp.strato.de
i:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA
1 s:C = DE, O = T-Systems International GmbH, OU = T-Systems Trust Center, ST = Nordrhein Westfalen, postalCode = 57250, L = Netphen, street = Untere Industriestr. 20, CN = TeleSec ServerPass Class 2 CA
i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
---
Server certificate
...

Die unterste Zeile in der „Certificate chain“ ist die Root-CA:

i:C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2

Über die Suchmaschine der Wahl kann man mittels des „Common Name“ (CN) in Verbindung mit dem Schlüsselwort „Download“ dann einfach das richtige Zertifikat finden:

Deutsche Telekom – Trust Center – TeleSec – Root Certificates

Ich bin mir fast sicher, das es auch irgendwie anders geht, das war zumindest jetzt mein erfolgreicher Schnellschuss.

Quelle:

ShellHacks – Get SSL Certificate from Server (Site URL) – Export & Download

SEH myUTN-50a USB Deviceserver: Auto-Connect Workaround

$
0
0

Die SEH myUTN USB-Deviceserver sind eigentlich eine zuverlässige Sache. Bei einem Kunden allerdings streikt seit neuestem leider immer mal wieder der Auto-Connect.

Die Funktion „Auto-Connect“ sorgt dafür, das ein ausgewählter USB-Port an einem Deviceserver automatisch an einem Computer zur Verfügung steht. Bei diesem Kunden hängt an Port 1 ein reinerSCT cyberJack-Kartenleser. Das gesamte Konstrukt funktionierte bislang ohne irgendwelche Überraschungen, aber seit März 2021 gab es bereits drei Mal den Fall, das der Kartenleser nicht automatisch verbunden wurde.

Umgesteckt oder irgendetwas geändert hat sich nichts. Das USB-Gerät wird angezeigt, nur eben der Connect fehlt. Klar kann man einfach im „UTN Manager“ den Port bzw. das Gerät wieder verbinden, die Anwenderin ist allerdings gewohnt, das es einfach so läuft.

Eine Überprüfung der Verbindungen, der Software- und Firmware-Stände brachte nichts. Ab und an läuft es schlichtweg nicht. Als Workaround habe ich mir dann ausgedacht, mittels einer Aufgabe den Connect nach der Benutzeranmeldung nochmal durchführen zu lassen. An dieser Stelle kommt einem gelegen, das SEH eine entsprechende CLI anbietet und man sich leicht aus dem „UTN Manager“ heraus zudem Verknüpfungen mit der nahezu komplett nutzbaren Befehlszeile anlegen lassen kann.

Die Verknüpfungen erzeugt man wie folgt:

  • Das betreffenden USB-Gerät mit der rechten Maustaste anklicken,
  • aus dem Kontextmenü den Punkt „UTN Aktion erstellen…“ auswählen,
  • die Voreinstellung belassen,
  • ggf. den Namen der Aktion ändern,
  • zu guter Letzt auf „Speichern & Beenden“ klicken.

Aus den Eigenschaften dieser Verknüpfungen lässt sich dann der Befehl entnehmen:

"C:\Program Files\SEH Computertechnik GmbH\SEH UTN Manager\screxe.exe" "C:/Program Files/SEH Computertechnik GmbH/SEH UTN Manager/utnm.exe" /c "activate 192.168.0.7 1"

Hier wird der Port 1 aktiviert. Das ist soweit schon sehr gut, allerdings erscheint eine Meldung am Ende des Vorgangs. Diese kann einfach durch das Anhängen von „/q“ unterdrückt werden. Erfreulicherweise liefert der Befehl einen Rückgabewert, den man Auswerten oder Protokollieren kann. Ein simpler Dreizeiler als Batch-Skript sieht so aus:

@echo off

rem Aktiviert den ersten USB-Port am SEH myUTN-50a

"C:\Program Files\SEH Computertechnik GmbH\SEH UTN Manager\screxe.exe" "C:/Program Files/SEH Computertechnik GmbH/SEH UTN Manager/utnm.exe" /c "activate 192.168.0.7 1" /q
echo %date% - %time% - %errorlevel% >> SEH-Port.log

Dieses Skript als Aufgabe bei der Benutzeranmeldung ausgeführt protokolliert den (Miss-)Erfolg der Port-Aktivierung. Anbei ein Auszug aus dem Log:

01.04.2021 - 23:26:19,83 - 0 
02.04.2021 - 23:26:19,04 - 0 
03.04.2021 - 23:26:19,59 - 0 
04.04.2021 - 23:26:18,44 - 0 
05.04.2021 - 19:46:16,47 - 0 
06.04.2021 - 8:31:36,65 - 0 
06.04.2021 - 13:05:39,08 - 23

Null bedeutet erfolgreich, 23 heißt das der Port bereits aktiv ist. Soweit also alles im grünen Bereich. Anbei die Hilfe der „utnm.exe“:

C:\Program Files\SEH Computertechnik GmbH\SEH UTN Manager>utnm /?

NAME

utnm.exe - UTN connection management, i.e. (de)activation of USB ports and
  connected USB devices, for UTN and INU servers by SEH Computertechnik GmbH

SYNOPSIS

  utnm.exe
    [/c <"command string">] [/h] [/k ] [/mr] [/nw]
    [/p ] [/q] [/sp ] [/t ] [/v]

DESCRIPTION

utnm is used to manage UTN connections, i.e. the (de)activation of USB ports
and connected USB devices.
It is the command-line interface of the SEH UTN Manager, i.e. the minimal
version of this tool (usable without graphical user interface, fewer features).

You need a UTN or INU server from SEH Computertechnik GmbH to use utnm.
You can also use utnm in scripts to automate UTN connections.

NOTE:
      - Options in square brackets are optional.
      - Elements in <> are to be replaced with the appropriate values.
        Examples:  = IP address or host name of a UTN or INU server;
         = vendor ID of the USB device;  = product ID of
        the USB device; etc.
      - Options are not case-sensitive.
      - Only the ASCII format can be read.

OPTIONS

  /c | /command 
       Runs a command. The command is specified in greater detail by the
       command string. Command strings:

       "activate  "
         Activates the connection to a USB port and the connected USB device.

       "activate   "
         Activates the first free device with the defined vendor ID product and
         product ID, if several identical USB devices are connected to the UTN
         or INU server.

       "deactivate  "
         Deactivates the connection to a USB port and the connected USB device.

       "set autoconnect=true|false  "
         Enables/disables Auto-Connect for the USB port: If a USB device is
         connected to the USB port, the connection will be automatically
         activated.

       "set userportkey=''  "
         Stores a USB port key locally on the system in a system user account.
         This way, the USB port key is always automatically sent and must not
         be specified each time with the command
         /k  | /key  (see below).
         (To remove the USB port key use the command string
         set userportkey=  .)
         NOTE: The command only sets the USB port key permanently to make the
         USB device available. The USB port key configuration is done via the
         Control Center (the server's graphical user interface).

       "set autoconnectportkey=''  "
         Stores a USB port key locally system-wide for the Auto-Connect
         feature. This way, the USB port key is always automatically sent and
         must not be specified each timewith the command
         /k  | /key  (see below).
         (To remove the USB port key use the command string
         set autoconnectportkey=  .)
         NOTE: The command only sets the USB port key permanently to make the
         USB device available. The USB port key configuration is done via the
         Control Center (the server's graphical user interface).

       "find [-]"
         Searches for all UTN and INU servers in the network segment and shows
         the servers found with IP address, MAC address, model, and software
         version.
         You can also search specified IP address ranges.

       "getlist "
         Shows an overview of the USB devices connected to the defined UTN or
         INU server (including port number, vendor ID, product ID, manufacturer
         name, product name, device class, and status).

       "state  "
         Displays the status of the USB device connected to the USB port.

  /h | /help
       Shows this help page.

  /k | /key 
       Specifies a USB port key.
       NOTE: The command only enters the key to make the USB device available.
       Use the command /c "command string"
       respectively /command "command string" to permanently store a USB
       port key on the system so that it is sent automatically each time (see
       above).
       The USB port key configuration is done via the Control Center (the
       server's graphical user interface).

  /mr | /machine-readable
       Separates the output of the command string 'getlist' with tabulators and
       the output of 'find' with commas.

  /nw | /no-warnings
       Suppresses warning messages.

  /p | /port 
       Uses an alternative UTN port. Use this command if you have changed the
       UTN port number.

  /q | /quiet
       Suppresses the output.

  /sp | /ssl-port 
       Uses an alternative UTN port with SSL/TLS encryption. Use this command
       if you have changed the encrypted UTN port number.

  /t | /timeout 
       Specifies a timeout for the command strings 'activate' and 'deactivate'.

  /v | /version
       Shows version information about utnm.


RETURN VALUES / ERROR LEVELS

  0  Command was executed successfully.
 20  Activation failed.
 21  Deactivation failed.
 23  Is already activated.
 24  Is already deactivated or not available.
 25  Activation failed: another user has activated the USB port incl. device.
 26  Not found: No USB device connected to the USB port or port key is missing
     or wrong.
 29  Not found: No USB device with this VID and PID connected.
 30  Isochronous USB devices are not supported.
 31  UTN driver error. Contact SEH Computertechnik GmbH support.
 40  No network connection to the UTN or INU server.
 41  Encrypted connection to UTN or INU server cannot be established.
 42  No connection to UTN service.
 43  DNS resolution failed.
 44  Missing rights (administrative rights required).
 47  Feature not supported.
200  Error (with error code).

.htaccess und Reguläre Ausdrücke

$
0
0

Kurz notiert, da ich es neulich leider für diesen Blog benötigt habe: In einer .htaccess-Datei kann man nicht nur direkt IP-Adressen (oder -Netze) und Domains zulassen bzw. blockieren, sondern zudem mit regulären Ausdrücken arbeiten.

.htacces:

order allow,deny
# Domain-Sperre via Regex
deny from .*domain\.tld.*
allow from all

Konkret ging es mal wieder um einen Spammer, der zwar mit ständig wechselnden IP-Adresse daherkam, diese allerdings (zumindest für eine gewisse Zeit) immer der gleichen Domain zugewiesen war. Mit Hilfe des oben gezeigten Regex konnten die typischen Domain-Varianten wie

domain.tld
www.domain.tld
www1.domain.tld
www2.domain.tld
usw.

abgefangen werden.

Quellen:

WhoIsHostingThis – 2020 Complete Guide To .HTACCESS – From The Basics To Advanced Learning

Liquid Web – Help Center – Allowing and Denying Website Access Using .htaccess

Windows: Sicherheitswarnung beim Öffnen einer ausführbaren Datei von einem Netzlaufwerk

$
0
0

Versucht man eine ausführbare Datei von einem anderen Arbeitsgruppen-Computer oder einem NAS zu starten, erhält man in der Regel folgende Sicherheitswarnung:

Ist der eigene oder der entfernte Computer nicht Mitglied der selben Domäne oder handelt es sich generell um eine Arbeitsgruppen-Umgebung ist diese Meldung normal. Die dahinter stehende Funktionalität soll verhindern, das unbemerkt bzw. ungewollt Anwendungen gestartet werden.

Mittels einer Konfigurationsänderung lässt sich diese Meldung verhindern bzw. dem entfernten Computer oder NAS vertrauen. Grafisch lässt sich unter

Systemsteuerung - Internetoptionen - Sicherheit - Lokales Intranet

nach einem Klick auf „Sites“ und „Erweitert“ die IP-Adresse, der Computername oder der FQDN des entfernten Computers eintragen. Je nachdem wie das Netzwerk gestaltet ist oder wo sich der entfernte Computer befindet, z.B. anderes Subnetz oder anderen DNS-Domäne, und wie auf Diesen zugegriffen wird, kann es sinnvoll sein alle drei Varianten einzutragen.

Hinweis: Diese Einstellung wird pro Benutzer gespeichert!

Via Gruppenrichtlinie (Lokal oder Domäne) lässt sich die Änderung unter

Benutzer- oder Computereinstellungen - Administrative Vorlagen - Windows-Komponenten - Internet Explorer - Internetsystemsteuerung - Sicherheitsseite

in „Liste der Site zu Zonenzuweisungen“ vornehmen. Hierzu muss man folgendes Wissen:

„Wertname“ stellt die „Site“, also die eigentliche Ziel-Adresse, dar und mittels „Wert“ wird die zugeordnete Zone angeben. Möglich ist:

  • 1 = Lokales Intranet
  • 2 = Vertrauenswürdige Sites
  • 3 = Internet
  • 4 = Eingeschränkte Sites

Hinweis: Sobald mittels Gruppenrichtlinie die Sites vorgegeben werden, kann der Benutzer keine eigenen bzw. weiteren Einträge hinzufügen!

Die Einstellung wird in der Registry unter

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

bzw.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

gespeichert. Folglich kann man diese ebenfalls via Skript, „reg import“ oder auch „reg add“ ändern. Ein Beispiel:

reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap" /v AutoDetect /t REG_DWORD /d 0 /f
reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%DeploymentServer%" /v * /t REG_DWORD /d 1 /f

Die Änderung greift im Vergleich zu früheren Windows-Versionen, wie z.B. XP, sofort. Ein Neustart ist nicht notwendig.

Quellen:

Microsoft Docs – Registrierungseinträge für Internet Explorer-Sicherheitszonen für erweiterte Benutzer

DeployHappiness – Managing Internet Explorer Trusted Sites with Group Policy

Bents Blog – Sicherheitswarnung „Datei öffnen“ in Domänen via Gruppenrichtlinien abschalten

rangee Thin Clients

$
0
0

Im Laufe der Jahre habe ich immerhin 11 Beiträge mit direkten Bezug zu Thin Clients von Igel geschrieben, aber bis dato keinen einzigen zu den Geräten von rangee, Zeit also etwas zu ändern.

Warum denn so spät wird man fragen, die Antwort ist relativ einfach und lässt sich anhand (m)eines kurzen Werdegangs darstellen:

Igel Thin Clients kenn’ ich seit schätzungsweise 15 Jahren oder sogar länger. Zwischendrin hatte ich mal kurz mit Wyse zu tun (bevor diese von DELL geschluckt wurden) und das war’s dann im wesentlichen auch schon.

Die Thin Clients von rangee hatte ich mal 2014 getestet, damals fehlte in der Tat nicht viel und der Wechsel hätte stattgefunden. Dann 2017 stand bei einem damaligen Kunden der Austausch sehr alter Wyse-Thin Clients an und ich zog rangee erneut in Betracht, aber es fiel die Entscheidung, wohlgemerkt ohne Evaluierung, zu Gunsten von Igel.

Nun etwas mehr als sieben Jahre nach dem Erstkontakt folgt ein neuer Test. Vorangegangen sind diverse Erfahrungen und Entwicklungen bei Igel die mir nicht ganz zusagen, so wurde z.B. zuletzt die maximale Maintenance von fünf auf drei Jahre gekürzt. Günstig sind die Teile mittlerweile auch nicht (mehr). Die Performance des UMS sowie die Bootzeit der Geräte sind weitere Punkte. Soviel zur Vorgeschichte, kommen wir nun zum eigentlichen Thema.

Zur Teststellung

rangee hat mir auf Anfrage freundlicherweise zwei unterschiedliche Thin Clients, und zwar die Modelle TC-LT550E-XL und TC-K10-XL, zur Verfügung gestellt. An dieser Stelle schon mal vielen Dank dafür.

Der K10 kommt mit einer VESA-Halterung daher und kann so direkt hinter ein Display montiert werden. Zudem ist das Gerät sehr kompakt, wird passiv gekühlt und es können via HDMI zwei Displays angeschlossen werden.

Der LT550E ist im klassischen Thin Client-typischen Desktop/Booksize-Format gehalten. Hier können ebenfalls zwei Displays (1x DP, 1x HDMI) angeschlossen werden. Neben diesen beiden erwähnten Geräten gibt es eine Vielzahl weiterer im Angebot, fernen können (alte) PCs konvertiert werden.

Übrigens: Die Gummibärchen sind immer, damals wie heute, mit dabei 😉 Ich wurde also nicht mit Süßigkeiten bestochen!

Für mich bzw. meine Kunden sind neben der selbstverständlichen zentralen Verwaltung bislang lediglich die Protokolle RDP (Remotedesktopverbindung, Windows Terminalserver, etc.) und VNC (Virtual Network Computing) relevant. Persönlich ziehe ich Linux auf einem Thin Client vor, bei Windows Embedded hat man zwar eine volle Domänen-Integration, dafür aber dann bei Upgrade-“Spaß” mit ggf. zu wenig “Plattenplatz” und vor allem die gleichen oder zumindest sehr viele ähnliche Lücken und Probleme wie mit einem vollwertigen Windows auch. Hinzu kommt dann auch wieder der Preis, das soweit unabhängig von rangee. Es mag alles Geschmacks- und Erfahrungssache sein.

Zentrale Verwaltung mit dem TCMS (Thin Client Management Server)

Der zentrale Dreh- und Angelpunkt bei rangee Thin Clients ist der TCMS. Diese Verwaltungsinstanz in Form eines dedizierten Thin Clients in physikalischer Form oder eines angepassten Linux-Systems das als virtuelle Maschine (VM) unter den Hypervisoren von VMware (ESX) und Microsoft (Hyper-V) installiert wird stellt über ein Web-Interface eine ansprechende sowie leicht verständliche Oberfläche zur Verfügung.

Der Vollständigkeit halber und damit wir uns nicht falsch verstehen: Man kann die Thin Clients auch ohne einen TCMS betreiben.

Im Testlab wurde der TCMS als VM unter Hyper-V installiert:

Die virtuelle Maschine an sich ist recht genügsam:

  • 4 GB RAM
  • 20 GB HDD

Als weiteres lädt man die aktuelle ISO herunter. Die eigentliche Installation geht schnell und ohne große Rückfragen von der Hand. Sozusagen: ISO rein, VM starten, Punkt 1 auswählen, Warnung das alles auf der virtuellen Festplatte gelöscht wird bestätigen, einen Moment warten, neu starten, fertig.

An diesem Punkt zitiere ich mal aus einer E-Mail:

"Es ist sinnvoll, dem TCMS eine feste Adresse zuzuweisen und
im DNS den Namen defaulttcms mit dieser IP zu hinterlegen,
damit neue Clients über die Suche nach defaulttcms direkt nach dem Auspacken
und Hochfahren in dem Management Server hineinlaufen und
darüber provisioniert werden können.

Auf die Management Oberfläche greifen Sie per Webbrowser zu:

https://IPAdresse-des-tcms"

Dem würde ich jetzt einfach mal so zustimmen.

Der Vorgang ist zudem sehr schön in den Hersteller-How-To’s beschrieben:

TCMS – Installation auf HyperV

Und dann gibt’s da natürlich noch ein Handbuch:

rangee – Knowledge Base – Handbuch TCMS 10 (DE)

Wichtig zu Wissen ist, das die allgemeine Oberfläche, Kommbox genannt, des rangee OS, ganz gleich ob Thin Client oder TCMS, unter der URL

https://IPAdresse-des-tcms

und die des TCMS unter

https://IPAdresse-des-tcms/tcms

erreichbar sind. Unter ersterer stellt man z.B. via “Anschlüsse – Netzwerkkonfiguration” die IP-Adresse usw. ein, während unter zweiterer die eigentliche Thin Client-Verwaltung aller Geräte im Netzwerk stattfindet. Die standardmäßigen Zugangsdaten lauten übrigens:

  • Benutzername: administrator
  • Kennwort: engels

Thin Client hinzufügen

Es gibt zahlreiche Wege einen neuen Thin Client zum TCMS hinzuzufügen, wie z.B. via DNS-Eintrag oder DHCP-Option, per Hand und Discover (Suche im Netzwerk) geht natürlich auch. Alle Mittel und Wege sind im Handbuch beschrieben. In meinem Testlab wurde zu Beginn ein entsprechender DNS-Eintrag angelegt und was soll man sagen, das klappte auf Anhieb.

Der erste Start eines Thin Clients dauert naturgemäß einen Moment, folgt doch der initiale Start, die Suche nach einem TCMS, die dortige Registrierung (sofern gefunden, versteht sich), der Bezug des Konfigurationsprofils, etwaiger Updates, usw.

Profile

Um ein Konfigurationsprofil zu erhalten, ist es im ersten Schritt notwendig eines von einem bereits konfigurierten Thin Client in den TCMS zu importieren. Daraus ergibt sich das immer ein Thin Client als Vorlage dienen muss. Dieser muss nicht in physikalischer Form vorhanden sein, es kann sich auch um eine virtuelle Maschine handeln.

Zur Info: Der TCMS kann nicht als Vorlage dienen!

FAQs

Während des Tests ergaben sich ein paar Fragen die im Rahmen einer Kurzeinführung, die übrigens sehr gut und informativ war, beantwortet wurden:

  • Wie wird zentral, also über den TCMS, Firmware und andere Updates verteilt?Zunächst ist es notwendig, dem “Vorlagen-Thin Client” den TCMS als Repository zuzuweisen. Dies geht via Kommbox unter “Software-Aktualisierung – Updateserver-Einstellungen”. Dann aktualisiert setzt man diesen einen Thin Client auf den Zustand “Test”, aktualisiert diesen und prüft anschließend ob alles in Ordnung ist. Ist das der Fall, ändert man den Zustand auf “Member”, aktualisiert man die Konfiguration der Gruppe und beim nächsten Neustart aktualisieren sich alle Thin Clients die der Gruppe bzw. der entsprechenden Konfiguration zugewiesen sind.
  • Wie werden neue oder geänderte Konfigurationen/Profile angewendet?
    Wie bereits erwähnt, muss ein Thin Client als Vorlage dienen, d.h. dieser muss entsprechend konfiguriert (und getestet) werden, dann zieht man die Einstellung von diesem Client und weist diese der Gruppe zu.
  • Wie sieht es mit der Datensicherung aus?
    Läuft der TCMS als virtuelle Maschine, kann diese einfach gesichert werden. Unabhängig davon kann ein Datenbank-Update lokal oder auf ein Netzwerk-Ziel erstellt werden.
  • Sind regelmäßige Aufgaben wie z.B. Wake-on-Lan (WoL) oder Herunterfahren möglich?
    Ja, auf der Registerkarte “Aktionen” zu Thin Clients auswählen, für die eine Aktion gelten soll und dann aus dem Kontextmenü den entsprechenden Punkt auswählen. Im daraufhin erscheinenden Dialog können die gewünschten Angaben wie Beschreibung, wann und wie oft die Aktion ausgeführt werden soll festgelegt werden. Zu bestehenden Aufgaben können weitere Thin Clients per Drag & Drop hinzugefügt werden.
  • Ist die Display Reihenfolge bei Dual- bzw. Multi-Monitor-Betrieb einstellbar?
    Ja.
  • Sind die Profile Modellabhängig?
    Nein.
  • Wie wird der TCMS und die Thin Clients lizensiert?
    Der TCMS ist kostenlos. Thin Clients die direkt von rangee stammen und konvertierte PCs erhalten eine lebenslange Lizenz. Zu beachten ist, das bei konvertierten Geräte die Lizenz nur drei Mal umgezogen werden kann. Mit Lebenslang ist in diesem Kontext das Geräte-Leben gemeint.

Fazit

Evtl. ungewohnt kann sein, das die Verwaltungssoftware nur als eigenständiges Linux zur Verfügung steht, wobei das gleichzeitig auch ein Vorteil ist, denn so bleibt die Thin Client-Verwaltung unabhängig von einem zugrundeliegenden Betriebssystem und ggf. weiterer Anwendungen die installiert sein können und so unter Umständen Wechselwirkungen auftreten. Oder anders ausgedrückt: Wer schonmal auf einem lahmen, alten, zugemüllten Windows Server ein noch lahmeres Igel UMS “verwalten” durfte versteht sicherlich was ich meine.

Ein weiterer Pluspunkt ist, das die Firmware (rangee OS), also das eigentliches Betriebssystem, sowie die Anwendungen (Browser, RDP-Client, etc.) voneinander getrennt sind, somit keine Abhängigkeit beseht das mit dem Update des einen oder gleich das Andere aktualisiert werden muss und dann ggf. irgendwelche Probleme auftreten, wo man zunächst nicht genau weiß, von welcher Seite sie herrühren.

Was mir bei rangee ebenfalls gefällt ist, das es sich um Standard-Hardware handelt, also keine wie auch immer “verdongelten” oder spezifischen ARM- oder “Sonst was”-Kisten. Nach Ableben als Thin Client könnte man ein OS seiner Wahl installieren und das jeweilige Gerät anderweitig verwenden.

Als weiteres kommt neben dem freundlichem Kontakt und dem Service hinzu, das die komplette Verwaltung, ganz gleich ob einzelner Thin Client oder Zentral für alle via Browser erfolgt. Es muss nicht erst irgendeine Komponente installiert werden.

Im Rahmen dieser Teststellung habe ich jetzt nur an der Oberfläche gekratzt, rangee kann (natürlich) noch viel viel mehr und dem Vernehmen nach kommt da noch einiges hinzu. Man darf also gespannt sein.

Beim nächsten Wechsel von Thin Clients bei Kunden oder bei neuen Projekten werden wir zukünftig auf rangee setzen. Die Handhabung ist einfach, der Kontakt und Service soweit wie ich ihn die letzten Wochen in Anspruch genommen habe (alles Anfänger-Fragen, ich habe nichts gefunden was einen zur Verzweiflung getrieben oder aus der Ruhe gebracht hat) ist einfach Spitze. Kurzer Dienstweg, super nett, informativ, kurzum: Passt!

P.S.: Ebenfalls interessant: WindowsPro – Rangee SIP: Softphone für Thin Clients im Test

Hardware: SEH utnserver Pro – USB Deviceserver mit zwei USB 3.2 Gen 1 Anschlüssen

$
0
0

Seit Ende 2020 steht von SEH der utnserver Pro, der Nachfolger des (imho) legendären myUTN-50a, zur Verfügung. Zeit für einen Blick auf das neue Gerät und so manche Verbesserung die damit Einzug hält.

Ein paar persönliche Worte zum Anfang

Gleich zu Beginn dieser Zeilen möchte ich darauf hinweisen, das mir SEH einen utnserver Pro zum Test nach voriger Frage ob ich denn einen haben möchte zur Verfügung gestellt hat. Dieser Beitrag ist kein Sponsored Post oder ähnliches, da die Teststellung bzw. Leihgabe mit keinerlei Bedingungen verbunden ist, man möchte lediglich Feedback von mir als langjährigen Anwender haben. Das ich das Thema nun verblogge ist sozusagen auf meinem Mist gewachsen.

Im Rahmen dieses Blog gibt es bislang sechs Beiträge mit Bezug zu den Produkten von SEH. Der erste Beitrag datiert dabei auf den März 2014, lediglich einer behandelt einen Workaround und einer zeugt vom sehr guten Service. Dies zeigt wie gut die Produkte sind und wie stabil diese laufen.

Jedenfalls freue ich mich, das SEH an mich gedacht hat und seit einem Weilchen das gute Stück hier ist. Vielen Dank dafür!

Gründe für einen USB Deviceserver bzw. USB over IP

Warum könnte man einen USB Deviceserver benötigen? Nun, da gibt es gleich mehrere potentielle Gründe für wie z.B. Lizenz-Dongles im geschützten Server- oder Technikraum unter zu bringen, so können diese schon mal nicht entwendet oder beschädigt werden. Ebenso kann es um Geräte gehen, die schlichtweg von sich aus nicht netzwerkfähig sind und entsprechend nach- bzw. umgerüstet werden sollen. Ein weiteres Szenario und das nicht erst seit COVID-19, ist die Nutzung im Home Office, von unterwegs oder einem anderen Standort aus.

Beim Einsatz von Protokollen wie RDP oder VNC ist ein USB Deviceserver ebenfalls sinnvoll, da nicht jeder Fat- oder Thin Client alle möglichen Arten von USB-Geräten weiterreichen kann, VNC dies überhaupt nicht unterstützt und RDP nur für bestimmte Geräte(klassen).

Ebenfalls ein prominentes Beispiel ist Virtualisierung. Warum nicht einfach am Hypervisor einen USB-Anschluss weiterleiten? VMware kann das, KVM auch, Hyper-V nicht. Spätestens bei Clustern nützt das Passthrough direkt am Hypervisor wenig, da das USB-Gerät ja am jeweiligen physikalischen Server steckt. Im Falle eines Failovers ist dann aufgrund der Nicht-Erreichbarkeit des USB-Geräts beispielsweise in Form eines Dongles der Lizenz-Server oder der DATEV-Kommunikationsserver sowie weitere Dienste offline.

Unboxing

Völlig unspektakulär in einem neutralen weißen Karton kommt der utnserver Pro daher. Enthalten ist neben dem Gerät als solches das Netzteil sowie ein Handbuch:

Die neues Generation ist geringfügig größer als der myUTN-50a, dies fällt allerdings nicht weiter ins Gewicht. Insgesamt bleibt er kompakt und das ist auch gut so.

Die aktuelle Software und mehr findet man auf der Hersteller-Seite unter

https://www.seh-technology.com/de/services/downloads/download-deviceserver/utnserver-pro.html

Inbetriebnahme

Aller Anfang ist beim utnserver Pro (wie gehabt) einfach. Das Gerät mit dem Netzteil und Netzwerk verbinden, den SEH UTN Manager herunterladen und installieren und schon ist man grundsätzlich bereit ein USB-Gerät über das Netzwerk nutzen zu können. Soweit ist das natürlich nur die absolute Kurzfassung, denn einem Infrastruktur-Gerät sollte man entweder eine statische IP-Adresse manuell oder per DHCP-Reservierung zuweisen.

Die IP- und weitere Konfigurationen kann man direkt aus dem UTN Manager oder alternativ über das Web-Interface vornehmen. Nicht unerwähnt bleiben soll der SEH Product Manager, mit dessen Hilfe man die generelle Inbetriebnahme und Verwaltung mehrerer verschiedener Produkte des Herstellers vornehmen kann. Direkt nach dem Start und sobald ein erstes Gerät gefunden wurde, kann man diverse Aktionen aus dem Kontextmenü und über den integrierten Browser ausführen.

Firmware aktualisieren

Im Gegensatz zu früheren Geräten gestaltet sich die Aktualisierung der Firmware einfacher, da es nur noch eine einzige *.bin-Datei gibt. Wir erinnern uns: Bislang gab es die eigentliche Firmware + die Software auf dem Gerät, die man getrennt von einander und in der richtigen Reihenfolge einspielen musste. Diese auf den ersten Blick simple Neuerung macht diesen kritischen Punkt um einiges angenehmer.

Die Firmware kann über das Web-Interface oder den Product Manager, allerdings nicht mittels des UTN Managers, aktualisiert werden:

USB-Gerät(e) über das Netzwerk nutzen

Hat man die Inbetriebnahme sowie die Grundkonfiguration, gemeint ist die IP-Adresse und mindestens unter “Sicherheit – Control Center” ein Kennwort gesetzt, kann man mit der eigentlichen Nutzung eines bzw. mehrerer USB-Gerät(e) über das Netzwerk fortfahren. Zunächst verbindet man das jeweilige Gerät mit dem utnserver Pro. Sowohl im Web-Interface als auch im UTN Manager kann man die verfügbaren Geräte sehen:

Wählt man den Port bzw. das USB-Gerät aus und klickt auf “Aktivieren” wird die Verbindung zum Computer hergestellt und man kann wie gewohnt bzw. als ob es ein lokal angeschlossenes USB-Gerät wäre damit arbeiten. Am Beispiel von USB-Massenspeichern funktioniert unter Windows dann auch das Auswerfen und der entsprechende USB-Port am utnserver Pro wird wieder freigegeben.

Ein automatisches Aktivieren beispielsweise sobald ein Gerät angeschlossen wird, lässt sich aus dem Kontextmenü des jeweiligen USB Deviceservers heraus aktivieren:

Hinweis: Dongle oder SmartCard-Lesegeräte sollten automatisch verbunden werden.

Einen automatischen Disconnect gibt es übrigens auch:

Neben dem manuellen und automatischen De-/Aktivieren besteht im UTN Manager die Möglichkeiten, sogenannte Aktionen zu definieren. Diese werden über einen Assistenten konfiguriert und als Verknüpfung auf dem Desktop des Anwenders abgelegt:

Von einfachen Verknüpfungen zum De-/Aktivieren über das Starten einer Anwendung und dem De-/Aktivieren nach dem Starten/Beenden dieser Anwendung bis hin zu relativ komplexen Verkettungen ist einiges möglich.

Neben dem manuellen oder automatischen Aktivieren besteht die Möglichkeit, ein bereits durch einen anderen Benutzer belegtes USB-Gerät anzufordern. Der Benutzer bekommt daraufhin ein Popup, das ihn über die Anforderung informiert und er so das Gerät freigegeben kann.

Speziell für USB-Drucker gibt es “Print-On-Demand”, das nach dem Anschluss und der Aktivierung unter “Automatische Geräteverbindung” aktiviert werden kann:

Benachrichtungen

Neu beim utnserver Pro sind die Benachrichtigungen die in Form von E-Mail und SNMP-Traps realisiert sind. Diese Benachrichtigungen können regelmäßig sein (Status per E-Mail) oder bei einem Ereignis wie z.B. Neustart oder De-/Aktivieren eines USB-Anschlusses.

Für den E-Mail-Versand muss zunächst unter “Netzwerk – E-Mail” der SMTP-Server konfiguriert werden.

Bemerkung: Der auf dieser Seite konfigurierbare POP3-Server ist nicht für POP-before-SMTP/SMTP-after-POP, sondern um den utnserver Pro mittels E-Mail administrieren zu können. Nebenbei bemerkt lässt sich der utnserver Pro zusätzlich noch ohne GUI, gemeint ist mittels CLI, verwalten.

Anschließend können unter “Gerät – Benachrichtigung” zwei Empfänger und der Intervall für den Status-Bericht konfiguriert werden:

An gleicher Stelle kann zudem der Betreff mittels Variablen angepasst und es können zwei unterschiedliche SNMP-Traps eingestellt werden.

Bemerkung: Sobald ein neuer E-Mail-Empfänger eingetragen und die Änderung gespeichert wurde, erhält man bereits eine Nachricht, so kann indirekt gleich getestet werden, ob die Benachrichtigung funktioniert.

Device: utnserver Pro
Name: <Geräte-Name>
Serial number:<Seriennummer>
MAC address: <MAC-Adresse>
Time: 2021-07-07 10:53:21 UTC+1:00 EU
================================
IPv4 address: <IP-Adresse>
Software: 20.0.15 
Firmware: 305.83
Uptime: 0 days 00:15:29 hours

Event: Restart

TAN: <TAN>


=== USB Devices ===================================================

Sicherheit

Bis hierhin läuft die Kommunikation über das Netzwerk unverschlüsselt und somit recht unsicher ab. Je nachdem was für Geräte angeschlossen und welche Art von Daten übertragen wird, ist dies allerdings nicht ratsam.

Neben dem Setzen von Kennwörtern für den Administrator und einem Benutzer, der lediglich einen lesenden Zugriff auf das Web-Interface erhält, kann ein Schlüssel pro Port unter “Sicherheit – USB – Ändern” gesetzt werden:

Dieser dient allerdings lediglich dafür, das der Port nur von Benutzern mit dem entsprechenden Schlüssel verwendet werden kann. An diesem Punkt können zudem USB-Eingabegeräte, gemeint ist die entsprechende Geräteklasse, deaktiviert werden. Ebenfalls möglich ist bestimmte Portschlüssel- und Gerätezuordnungen-Kombinationen anzulegen.

Ferner kann man die Zugriffe auf bestimmte Netze und MAC-Adressen unter “Sicherheit – TCP-Port-Zugriff” beschränken:

Darüber hinaus kann die Kommunikation sowie der Zugriff auf das Web-Interface und der Versand von Benachrichtigungen mittels SSL/TLS verschlüsselt werden. Unter “Sicherheit – SSL/TLS” kann man die minimale Verschlüsselungsprotokollversion sowie -stufe vorgeben und zu weiteren Menü-Punkten z.B. für die verschlüsselte E-Mail-Kommunikation springen.

Wichtig: Nach Möglichkeit sollten die niedrigsten Stufen (außer aus Legacy-Gründen) vermieden werden! Idealerweise sollte TLS und die höchste Verschlüsselungsstufe zum Einsatz kommen.

Von Haus aus kommt der utnserver Pro bereits mit einem selbst-signierten Zertifikat daher, das bereits für die verschlüsselte Kommunikation verwendet werden kann. Sofern vorhanden kann der UTN-Server in die eigene Zertifikatinfrastruktur eingebunden werden, das entsprechende CA-Zertifikat, eine CSR- und letztlich das ausgestellte Zertifikat können importiert bzw. erstellt (betrifft nur den CSR) werden.

Im UTN Manager muss kein Zertifikat importiert werden. Last, but not least: IEEE 802.1X wird ebenfalls unterstützt.

Den UTN Manager schützen

Sozusagen ab Werk bekommen alle Benutzer im UTN Manager alle UTN-Server samt der damit verbundenen Geräte angezeigt. Ob Sie diese nutzen können hängt unter anderem vom “Benutzer-Port-Schlüssel” ab. Möchte man die Ansicht einschränken das z.B. nur bestimmte Benutzer nur den für Sie bestimmten UTN-Server bzw. ein daran angeschlossenes Gerät sehen können, ist dies über das vorgeben einer benutzerindividuellen Auswahlliste möglich.

Die notwendigen Schritte und mehr sind im Benutzerhandbuch ab Punkt 5.7 (Seite 53 ff) beschrieben.

Monitoring

Neben den bereits erwähnten Benachrichtigungen via E-Mail und SNMP-Trap kann der utnserver Pro mittels SNMP überwacht werden. Neben dem (unsicheren) Klassiker v1 wird v3 unterstützt. Eine passende MIB stellt der Hersteller auf seiner Homepage zur Verfügung.

Weiteres

Natürlich wird auch VLAN und IPv6 unterstützt. Die Firmware sowie die Computer-seitige Software wird stetig weiterentwickelt. Zum jetzigen Zeitpunkt soll so manche “exotische” Hardware laut Hersteller beim utnserver Pro noch nicht funktionieren, was sich wohl in Zukunft mittels Updates ändern wird. Unabhängig davon kommen neue Geräte immer wieder hinzu.

Selbstverständlich kann die Konfiguration des UTN-Servers in Form eines Backups gesichert und wiederhergestellt werden. Da es sich im Text-Dateien handelt die frei editiert werden können, lässt sich so eine Standard-Konfiguration definieren, die auf neue Geräte quasi als Vorlage eingespielt werden kann. Dies spart bei der Erst-Einrichtung von mehreren Geräten viel Zeit und Aufwand.

Geräte-Tests

Aus meinem eigenen Fundus hat bislang jedes Gerät am utnserver Pro zuverlässig funktioniert. Es kamen neben diversen USB-Massenspeichern (angefangen von USB 2.0 die etliche Jahre auf dem Buckel haben bis zu aktuellen USB 3.x-Ausgaben) beispielsweise auch ein betagter Fujitsu ScanSnap S1500 (Baujahr 2010, der witzigerweise nur am Front-USB meines PCs funktioniert) oder ein reinerSCT-Kartenleser bislang erfolgreich zum Einsatz.

Ein vielleicht nicht ganz ernstgemeinter Test war die Nutzung einer USB-Soundkarte, wobei es durchaus Anwendungsfälle beispielsweise in virtuellen Maschinen geben kann, wo so etwas von Nöten ist. Da es eines meiner Themen ist, wurde die Latenz zunächst direkt am PC und dann über den utnserver Pro ermittelt:

Überraschenderweise war die Latenz über den utnserver Pro deutlich besser, als über den Front-USB (25 ms) meines PCs. Immerhin 10 ms Unterschied, erwartet hatte ich wegen der Konvertierung von “USB-zu-Netzwerk” und umgekehrt das diese eher etwas höher ausfallen würde.

Hinweis: Werden USB-Soundkarten nicht erkannt, liegt das in der Regel daran, das diese entweder eine externe Stromversorgung benötigen oder in den Einstellungen des UTN-Servers die Nutzung von HID-Geräten deaktiviert ist.

Als weiteres wurde eine Microsoft Lifecam HD-3000 (der Isochron-Modus wird unterstützt) getestet, zwar nicht gemessen, aber zumindest spürbar gegenüber dem direkten USB-Anschluss kam es zu keiner erhöhten Bildverzögerung.

Fazit

Bislang hat fast alles was einen USB-Anschluss beitzt mit den Geräten von SEH funktioniert. In all den Jahren gab es nur eine Ausnahme in Form eines Colortrac SmartLF CiC40 (Großformat-Scanner), welches irgendeinen seltenen USB-Modus oder eine andere “Spezialität” verwendet, das war seinerzeit anno 2015. Wenn ich mich recht entsinne war dieses Gerät damals schon alt. Jedenfalls wurde es nur direkt am Windows-PC erkannt, am damaligen myUTN-54 tauchte es schon gar nicht auf, da konnte der Support auch nichts daran ändern.

Auch beim utnserver Pro hat sich an der grundlegenden Linie von SEH nichts verändert. Die Geräte sind schlicht und kompakt im Design, funktional und leicht zu bedienen, nebenbei bemerkt ist das Handbuch sehr gut. Die bisherige Zuverlässigkeit, der gute Service, der überaus nette Kontakt und (nach Registrierung) fünf Jahre Garantie runden einmal mehr den insgesamt hervorragenden Eindruck ab.


MDaemon: Alle externen eingehenden Nachrichten in ein bestimmtes Postfach verschieben

$
0
0

Bei einem Kunden sollen alle von extern eingehenden Nachrichten zunächst im Info-Postfach landen, ein/e Mitarbeiter/in sortiert dann aus und verschiebt die jeweilige Nachricht ins eigentliche Mitarbeiter-Postfach. Das war schon immer so und soll auch so bleiben.

In Verbindung mit dem MDaemon Email Server war es bislang so, das alle Postfächer beim Provider mittels MultiPop abgerufen wurden. Da die entsprechenden Einträge nur beim Info-Benutzer vorhanden waren, ist hiermit der Wunsch entsprechend umgesetzt gewesen.

Nun wurde die Anbindung des MDaemon umgestellt, gemeint ist das dieser nun direkt mittels SMTP E-Mails versendet und empfängt. Daher musste ein anderer Weg gefunden werden, wie alle von extern eingehenden Nachrichten bei Info und nicht gleich im jeweiligen Postfach zugestellt werden.

Die Lösung ist simple: Es wird eine Regel im Inhaltsfilter benötigt, die wie folgt gebaut wird:

  • Auf “Sicherheit – Inhaltsfilter” klicken.
  • Unter “Inhaltsfilter – Regeln” auf “Regel erstellen” klicken.
  • Bei “Bedingungen…” “If the FROM HEADER” contains” und “IF the TO HEADER contains” anklicken.
  • Bei “Aktionen…” “COPY the message to FOLDER” und “DELETE the message” anklicken.
  • Nun in den Details die blau hinterlegten Links anklicken und anpassen.

So ist relevant, das beim “FROM HEADER” die eigene Mail-Domain ausgeschlossen wird, andernfalls werden alle eingehenden Nachrichten, ganz gleich ob von ex- oder intern, an das angegebene Ziel verschoben.

Der “TO HEADER” ist relevant, das nur Nachrichten an die eigene Mail-Domain in Verbindung mit externen Mail-Domains verarbeitet werden, deshalb ist das “and” an dieser Stelle wichtig.

Da der Inhaltsfilter kein Verschieben kennt, wird die Nachricht zunächst in den Ziel-Ordner kopiert und dann am ursprünglichen Ort gelöscht. Zu beachten ist beim Ziel-Ordner, wenn es der Posteingang sein soll, das man nicht in den INBOX-Unterordner kopiert!

Möchte man bestimmte E-Mail-Adressen von dieser Regel ausnehmen, erstellt man eine weitere Regel, die vor der zuvor erstellten Regel in der Reihenfolge steht und z.B. so aussieht:

MDaemon: Ausgehende Nachrichten direkt zustellen, wenn das nicht klappt dann via Smarthost

$
0
0

Mit dem MDaemon Email Server ist man in Sachen Anbindung sehr flexibel. So unterstützt dieser die direkte Nachrichten-Zustellung mittels SMTP ebenso wie den Abruf von POP3 -oder IMAP-Konten beim Provider.

Ist der MDaemon Email Server direkt und ordentlich mittels SMTP angebunden, sollte im Normalfall die Zustellung von ausgehenden Nachrichten funktionieren. Leider kommt es immer mal wieder vor, das andere Mail-Server oder -Provider die Verbindung oder Nachrichten ablehnen. Für diese Fälle kann man konfigurieren, das der MDaemon zunächst die direkte Zustellung versucht und wenn diese nicht klappt, den Weg über einen zuvor konfigurierten Smarthost nimmt.

  • Im einfachsten Fall genügt die Konfiguration unter “Einstellungen – Server-Einstellungen – Server und Zustellung – Postausgang”.
  • Hier setzt im Abschnitt “Nachrichten-Routing” den Punkt bei “Alle abgehenden Nachrichten zunächst direkt und nur bei Problemen über die Smarthosts senden”.
  • Im darunterliegenden Abschnitt “Standard-Smarthost” trägt man eben diesen ein.

Pro Mail-Domain kann ein eigener Smarthost festgelegt werden, dies geht über den Domänen-Manager. Noch detaillierter kann man für bestimmte Empfänger-Mail-Domains Ziel-Mailserver angeben. Für solche Szenarien sei dieser Beitrag empfohlen:

EBERTLANG – Knowledge Base – Bestimmte E-Mails über einen speziellen SMTP-Mailserver versenden

MDaemon: Mit der Protokollübersicht erfolgreiche und fehlgeschlagene Zustellungen einsehen

$
0
0

Neben der Live-Ansicht in der Verwaltungskonsole und den Protokollen unter “C:\MDaemon\Logs” gibt es mit dem “Warteschlangen- und Statistik-Manager” des MDaemon Email Servers eine weitere bequeme Möglichkeit Protokolle auszuwerten. Gerade letztgenannter bietet bequem die Option erfolgreiche und fehlgeschlagene Zustellungen zu erkennen.

  • Aufgerufen wird dieser unter “Warteschlangen – Warteschlangen- und Statistik-Manager…”.
  • Nun wechselt man auf die Registerkarte “Protokollübersicht” und klickt auf “Protokoll öffnen”.
  • Man wählt das vergangene oder aktuelle Protokoll, z.B. “MDaemon-2021-07-27-SMTP-(eing.).log”, aus.

Einen kurzen Augenblick später erhält man zunächst eine kurze Zusammenfassung und sieht dann tabellarisch die Einträge. Die jeweiligen Spalten können zwecks Sortierung angeklickt werden. Meist ist die Umkehr der zeitlichen Reihenfolge (damit die neuesten Einträge oben stehen) und die Sortierung nach Miss-/Erfolg interessant.

Die einzelnen Einträge können doppelt angeklickt werden. So erhält man Details, gerade bei Fehlschlägen lässt sich so schnell und leicht eingrenzen und herauslesen, woran es gelegen hat.

Zu beachten ist, das auch zunächst wegen Greylisting abgelehnte Zustellungen als Fehlschlag gelten. Ferner steht die Protokollübersicht nur für SMTP-, IMAP- und POP3-Protokolle zur Verfügung, alle Anderen können im Editor (Notepad) geöffnet werden.

MDaemon: Mittels Inhaltsfilter bestimmte Nachrichten (nach extern) weiterleiten

$
0
0

In einem Kundenszenario ging es darum, Nachrichten die auf eine bestimmte E-Mail-Adresse eingehen an bestimmte Empfänger weiterzuleiten.

Die klassisches Lösung wäre es, ein Postfach anzulegen und dort eine Weiterleitung einzurichten, allerdings ist dies recht unspezifisch da so alle Nachrichten weitergeleitet würden. In diesem Fall sollte allerdings kein Postfach im MDaemon Email Server “geopfert” werden, zumal es keinen internen Mitarbeiter für die Anliegen an diese E-Mail-Adresse gibt.

Die Lösung bestand nun darin, einem vorhandenen Postfach einen Alias zu geben, damit der MDaemon die Nachrichten überhaupt annehmen kann. Als nächstes wurde eine Regel erstellt, die dafür sorgt das Nachrichten an diesen Alias (nach extern) weitergeleitet werden. Kurz gefasst sieht die Regel so aus:

Wie man sieht, wird die Nachricht zuletzt gelöscht, da intern niemand etwas damit anfangen kann, und etwaige nachfolgenden Regeln werden nicht mehr angewendet.

MDaemon: Automatisches Löschen von (älteren) Nachrichten

$
0
0

Der MDaemon Email Server bietet gleich an mehreren Stellen Konfigurationsmöglichkeiten zum Löschen von alten Nachrichten an.

Der erste Beitrag zu diesem Thema in diesem Blog datiert auf das Jahr 2013 und hat nach wie vor seine Gültigkeit:

Windows: MDaemon und automatisches Löschen nach 30 Tagen

Wobei sich im Laufe der Zeit etwas die Menü-Bezeichnungen geändert haben. In aktuellen Versionen findet man den Dialog unter

Einstellungen - Server-Einstellungen - Bereinigen

Hier kann man ganz allgemein für den gesamten Server das Löschen von Nachrichten die älter als x Tage sind vorgeben.

Pro Domäne geht dies unter

Einstellungen - Domänen-Manager - Einstellungen

Beide Punkte haben gemein, das hierbei nur für alle Nachrichten-Ordner eine Bereinigung vorgegeben werden kann. Möchte man regelmäßig beispielsweise lediglich die gelöschten Objekte oder andere Nachrichten-Ordner bereinigen oder gar nur für bestimmte Postfächer ein automatisches Löschen einstellen, hilft der Griff zum Tool AccountPrune.

Dieses findet sich unter

C:\MDaemon\App\AccountPrune.exe

Im gleichen Ordner ist eine Datei mit dem Namen “AccountPrune.txt” vorhanden, die alle Parameter auflistet und Erklärungen bietet.

Mittels Skript lässt sich so zu einem beliebigen Zeitpunkt eine zielgerichtete Bereinigung realisieren. Beispiele sind:

C:\MDaemon\App\AccountPrune.exe /m /d=7 /p="Gesendete Objekte.IMAP"
C:\MDaemon\App\AccountPrune.exe /m /d=7 /p="Gel&APY-schte Objekte.IMAP"
C:\MDaemon\App\AccountPrune.exe /m /d=7 /p="Junk.IMAP"
C:\MDaemon\App\AccountPrune.exe /m /d=7 /p="Junk-E-Mail.IMAP"

In diesem Fall werden Nachrichten die älter als sieben Tage sind entfernt. Das Ergebnis eines AccountPrune-Durchlaufs findet man unter

C:\MDaemon\Logs\AccountPrune_<Datum>.log

Empfehlenswert ist die Ausführung bei der nächtlichen Wartung des MDaemon Email Servers. Die entsprechenden Befehlszeilen können hierzu einfach in die Datei

C:\MDaemon\App\midnight.bat

eingetragen werden.

Wichtig zu Wissen ist, das MDaemon bzw. AccountPrune zur Ermittlung des Alters einer Nachricht das Dateidatum und nicht das E-Mail-Datum verwendet!

Alternativ oder parallel zu den Bereinigungsmöglichkeiten des MDaemon Email Server kann man beispielsweise mit Hilfe einer E-Mail-Archivierungslösung wie dem MailStore Server Nachrichten die älter als ein bestimmter Zeitraum sind automatisch nach erfolgreicher Archivierung aus den Postfächern entfernen lassen.

Quellen

EBERTLANG – Knowledge Base – Automatisierte Bereinigung (Pruning) von E-Mails und Benutzerkonten

Everything MDaemon – MDaemon’s use of batch files

MDaemon Technologies – (FAQ) How can I clear out my users’ spam folders automatically?

Viewing all 344 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>