Normalerweise starten virtuelle Maschinen (VM) unter VirtualBox immer mit „angekoppelter“ Oberfläche, d.h. möchte man das Fenster der VM schließen, aber diese soll weiterlaufen, so ist das nicht möglich.

Ein nachträgliches Abkoppeln ist nicht möglich, da dazu von vornherein die VM in einem separaten Prozess gestartet werden muss. Dies geht über die grafische Oerfläche, wenn man darauf achtet, das man  die VM entweder ohne GUI oder abgekoppelt startet:

Immer darauf achten zu müssen kann allerdings lästig und vorallem ärgerlich sein, wenn man es dennoch mal vergisst und daraufhin die VM nochmals herunterfahren und neustarten muss. Mit folgendem Befehl gibt man vor, das die ausgewählte VM immer mit abgekoppelter GUI startet:

VBoxManage modifyvm "<VM-Name>" --defaultfrontend separate

Alternativ kann man Einstellen, das ohne GUI gestartet wird:

VBoxManage modifyvm "<VM-Name>" --defaultfrontend headless

Der Name der VM muss identisch zur Anzeige in VirtualBox eingegeben werden, die Groß-/Kleinschreibung wird beachtet! Bei Erfolg gibt es keinerlei Rückmeldung von diesem Befehl. Die Änderung greift ab dem nächsten Einschalten der VM.

Nachdem der Befehl ausgeführt wurde, kann die VM schlicht über die „Start“-Schaltfläche sozusagen eingeschaltet werden, es muss nicht mehr auf die Auswahl geachtet werden. Die GUI kann nach der Änderung jederzeit über „Maschine – GUI abkoppeln“ geschlossen  und über die Schaltfläche „Zeigen“ wieder angezeigt werden.

GUI beim Schließen des Fensters abkoppeln (nur bis VirtualBox 5.0.x)

Per Vorgabe ist nur ein Speichern, Herunterfahren und Ausschalten der VM beim Schließen des Fensters möglich:

Mit nachfolgendem Befehl lässt sich vorgeben, das die GUI abgekoppelt wird und so die VM im Hintergrund weiterläuft:

VBoxManage setextradata <VM-Name> GUI/DefaultCloseAction Detach

Damit die Änderung greift, muss einmalig die VM aus-/eingeschaltet werden.

Leider greift diese Änderung nicht mehr bei VirtualBox-Versionen ab 5.1.x. Siehe dazu:

VirtualBox –  Ticket #16085 – Headless/detachable VM cannot be detached (again)

VirtualBox – Forum – [NotABug] Detacheble started VM can’t be detached

So bleibt nur der Weg über „Maschine – GUI abkoppeln“ übrig.

Quelle:

VirtualBox – GUI Always Start Headless – GUI Always Start Headless

VirtualBox – Manual – Chapter 8. VBoxManage – 8.12. VBoxManage startvm

VirtualBox – Manual – Chapter 8. VBoxmanage – 8.29. VBoxManage getextradata/setextradata

VirtualBox – Manual  – Chapter 9. Advanced topics – 9.20.9. Default action when terminating the VM

Wie bei Windows kann es auch bei Samba-Servern auf Linux/Unix-Basis zu Schwierigkeiten beim Zugriff auf Dateien kommen, wenn diese angeblich noch im Zugriff sind.

In diesem Szenario kam der Zugriffs-Fehler dadurch zustande, da während des Kopierens einer Datensicherungsdatei die VPN-Verbindung durch eine DSL-Störung mehrere Stunden unterbrochen war. Während auf der Sender-Seite (ein Windows Server) definitiv alle Verbindungen weg waren, konnte es folglich nur noch an der Empfänger-Seite (Debian mit Samba) liegen.

Der Schnellschuss besteht darin, schlicht den Samba-Server neu zustarten. Dazu reicht es aus, den smb-Daemon einmal durchzustarten:

service smbd restart

Allerdings unterbricht dies alle aktuellen Verbindungen. In diesem Fall ist der Windows-Server auf der Sender-Seite der einzige Client, von daher war es kein Problem.

Nachdem die Sperre aufgehoben war, konnte über den „copy /z …“-Befehl der Kopiervorgang fortgesetzt werden. Die zuvor bereits erfolgreich kopierten Teile der Datei gingen dabei nicht verloren.

Eine unter Umständen bessere Lösung wird unter den nachfolgenden Links beschrieben. So lässt sich gezielt der smbd-Prozess ermitteln und beenden, ohne die anderen Verbindungen bzw. Zugriffe zu beeinflussen:

Sysadmins Tips – Unlock network files locked by Samba Linux / Unix Server

VAFtech – How to find which SAMBA user has locked a file

Kommt es häufiger zu Schwierigkeiten mit gesperrten Dateien, so lässt sich das Verhalten des Samba-Servers verändern:

serverfault – How to prevent samba from holding a file lock after a client disconnects?

Samba – Docs – Chapter 17. File and Record Locking

Wechselt man bei einer USV den Akku, so sollte schon aus Dokumentationsgründen das Datum in der USV eingetragen bzw. geändert werden. Bei Geräten von APC in Verbindung mit apcupsd ist dies leicht möglich.

• Den Dienst (Windows) bzw. Daemon (Linux/Unix) beenden.
• „apctest“ aufrufen.
• „4) View/Change battery date“ auswählen und das neue Datum eintragen.
• Mit „q“ (für Quit) „apctest“ verlassen und den Dienst bzw. Daemon wieder starten.

Anbei ein paar Screenshots am Beispiel einer Windows-Installation:

Troubleshooting:

Bei einer APC Back-UPS 700 funktionierte zunächst das Ändern des „battery date“ zunächst nicht. Es kam zu einem Timeout bei „Waiting for change to take effect“. Nach einem Neustart der USV und des Computers wurde die USV Anschluss-seitig via USB überhaupt nicht mehr erkannt. Erst nachdem die USV ein paar Minuten stromlos war (Stecker raus, Akku raus) und anschließend wieder montiert wurde, klappte die Kommunikation und das Ändern des Datums.

Der Einrichtungsassistent von Thunderbird nimmt einem bereits viel ab, am Beispiel von Freenet in Verbindung mit IMAP sollte man allerdings die Zuordnung der Ordner anpassen.

Konkret geht es darum, wo die gesendeten Nachrichten und die Entwürfe gespeichert werden. Für Freenet muss dies manuell in den Konten-Einstellungen unter „Kopien & Ordner“ konfiguriert werden:

"Beim Senden von Nachrichten automatisch" - "Eine Kopie speichern unter" - "Anderer Ordner" - "Posteingang - sent"

"Entwürfe und Vorlagen" - "Entwürfe speichern unter" - "Anderer Ordner" - "Posteingang - drafts"

Quelle:

freenet.de – Kundenservice & Hilfe – Thunderbird: E-Mail Empfang / Versand einrichten über IMAP 

Schön wenn der Tag mit einem Virenalarm beginnt, noch schöner, wenn nicht’s weiter passiert ist.

So geschehen heute Morgen: Von einem Kunden bzw. direkt von Panda Adaptive Defense 360 kam eine Alarmmeldung, das etwas blockiert wurde:

Kurzfassung: Es kam eine Mail mit einer vermeintlichen Rechnung als Word-Datei, diese wurde gespeichert und geöffnet, ein Makro wollte via PowerShell einen (oder mehrere) Schädlinge herunterladen und ausführen. Panda Griff an dieser Stelle, so das nichts heruntergeladen wurde und in Folge auch nichts weiter geschehen ist.

Ich nahm den Alarm zum Anlass, diese Word-Datei via VirusTotal zu prüfen:

Wie man sieht, würde dieses „Ding“ bei fast allen Virenscannern durchgehen. Ziemlich ernüchterndes Ergebnis also. In diesem Fall hies die Datei übrigens „Rechnung-Oktober-2017.doc“. Mittlerweile finden sich auch andere Dateinamen im VirusTotal-Ergebnis, ferner steigen die Community-Beiträge in denen z.B. die Malware-URLs angegeben sind:

https://www.virustotal.com/#/file/27690febddc8bf29d57cee5e527e3a386d0d32afa4ae9bc1fa4a18cf849f5be3/detection

Zwei Stunden später erkennen immerhin vier Virenscanner diesen Downloader.

Bemerkung am Rande: Nicht wundern, das im VirusTotal-Ergebnis Panda die Datei ebenfalls nicht als schädlich einstuft. Soweit mir bekannt ist, kommt bei VirusTotal nur die Panda Signatur zum Einsatz (kein AD360!).

Übrigens: Bei diesem Kunden wird eine Securepoint UTM eingesetzt und die Mail ging ohne zu Murren beim Mailfilter durch (nichts gegen Securepoint bzw. Cyren was dort zum Einsatz kommt), ferner wird SRP verwendet.

Ein Sperren von Word oder Word-Anhängen geht leider nicht, ebenso wenig der Makros. Einzig den Mitarbeiter, der dem Ausführen des Makros zugestimmt hat kann man nochmal auf die Gefahr hinweisen, das hilft aber auch nur, wenn die Mail von einem unbekannten Absender kommt. Wird z.B. die Absender-Adresse gefälscht oder wird ein vertrauenswürdiges Mail-Konto von einem Angreifer übernommen und verwendet, so hilft dies herzlich wenig.

Gut gedacht aber nicht ganz unproblematisch kann das Windows Defender Security Center von Windows 10 (ab Version 1703) sein. Gut ist es eigentlich, da es einen Überblick über den aktuellen Stand der Sicherheit des Computers liefern kann, problematisch, wenn’s mit Sicherheitssoftware von Drittanbietern nicht ganz rund läuft.

Bei einem Kunden hielt nun der erste Windows 10-PC einzug, direkt nach der Inbetriebnahme war zunächst alles in Ordnung. Nach der Installation des Fall Creators Update meckerte allerdings das Security Center die Firewall von Panda Adaptive Defense 360 an. Das ist zwar soweit fast richtig, da diese nicht verwendet wird, stattdessen kommt die Windows-Firewall zum Einsatz. Folglich sollte eigentlich (imho) die Windows-Firewall überwacht werden. Leider fanden sich dazu keine Infos wie man das Regeln kann (falls jemand welche hat, bitte melden).

Mittels Gruppenrichtlinie lässt sich steuern, welche Teile im Security Center angezeigt werden. Sobald allerdings der Firewall-Teil ausgeblendet war, wurde plötzlich der Virenschutz mit Handlungsbedarf angezeigt. Folglich war das kein wirklich gangbarer Weg. Als letzte Massnahme blieb also nur noch übrig, das Windows Defender Security Center zu deaktivieren.

Im übrigen sind solche Schwierigkeiten nicht auf Panda begrenzt, im Netz kann man nachlesen, das z.B. auch Symantec/Norton betroffen ist.

Dienst deaktivieren:

• „regedit“ ausführen.
• Zu „HKLM\SYSTEM\CurrentControlSet\Services\SecurityHealthService“ wechseln.
• Den Wert von „Start“ von „2“ auf „4“ setzen.

Infobereichssymbol deaktivieren/entfernen:

Deaktivieren kann man das Symbol im Task-Manager auf der Registerkarte „Autostart“. Dauerhaft bzw. für alle Benutzer geht dies durch das Entfernen aus dem Autostart:

• „regedit“ ausführen.
• Zu „HKLM\Software\Microsoft\Windows\CurrentVersion\Run“ wechseln.
• Den Eintrag „C:\Program Files\Windows Defender\MSASCui.exe“ entfernen.

Nach einem Neustart ist der Dienst deaktiviert und das Symbol ist verschwunden.

Quellen:

Microsoft Partner Network – Disable Windows Defender Security Center – Windows 10 Creator’s Update  

Winaero – How To Disable Windows Defender Security Center

HELP WANTED! Ich bin aktuell auf der Suche nach einer Lösung für folgende Aufgabe:

Bei einem Kunden werden alle ausgehenden E-Mail-Adressen durch postfix auf „info@domain.tld“ umgeschrieben. Das ist so gewollt und läuft seit Jahren. Nun soll aber per Server-Eye’s MailRoundTrip ein Monitoring des E-Mail-Ablaufs erfolgen, d.h. eine Adresse darf nicht umgeschrieben werden.

Jetzt bin ich in postfix nicht so firm und alle bisherigen Versuche klappten leider nicht. Von daher hier mal ein Ruf in die Runde, ob jemand einen Tipp hat oder unterstützend mitwirken kann?

Aktuell ist es so, das via header_checks die Nachrichten umgeschrieben werden:

/^From:.*<.*@domain.tld>.*$/		REPLACE From: NAME <info@domain.tld>
/^From:.*@domain.tld.*$/		REPLACE From:NAME <info@domain.tld>
/^Reply-To:.*<.*@domain.tld>.*$/	REPLACE Reply-To: NAME <info@domain.tld>
/^Reply-To:.*@domain.tld.*$/		REPLACE Reply-To: NAME <info@domain.tld>

Ich nehme an, man könnte evtl. mit sowas wie

if !/^From:<nichtinfo@domain.tld>...
endif

arbeiten.

Das Thema habe ich zudem auch bei debianforum.de gepostet:

Postfix, alle ausgehenden Mail-Adressen umschreiben mit einer Ausnahme

Heute sollte bei einem Kunen eine länger nicht mehr aktualisierte pfSense-Installation auf den neuesten Stand gebracht werden. Normalerweise ist das kein Problem, seltsamerweise meldete die installierte Version 2.3.4-p1 das sie aktuell wäre.

Aktuell ist allerdings Version 2.4.1. Auch mehrmaliges Prüfen änderte nichts und die Protokolle lieferten auf den ersten Blick nichts ungewöhnliches. Jenseits des Web-Interfaces kann sowohl an der Konsole als auch via ssh ebenfalls aktualisiert werden. Dort erhält ggf. eher eine Meldung, wenn etwas nicht klappt.

Via ssh und nach Auswahl von „13) Update from console“ tauchte folgende Ausgabe auf:

>>> Updating repositories metadata...
Updating pfSense-core repository catalogue...
pkg: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory
pkg: https://pkg.pfsense.org/pfSense_v2_3_4_amd64-core/meta.txz: Network is unreachable
repository pfSense-core has no meta file, using default settings
pkg: https://pkg.pfsense.org/pfSense_v2_3_4_amd64-core/packagesite.txz: Network is unreachable
Unable to update repository pfSense-core
Updating pfSense repository catalogue...
pkg: Repository pfSense load error: access repo file(/var/db/pkg/repo-pfSense.sqlite) failed: No such file or directory
pkg: https://pkg.pfsense.org/pfSense_v2_3_4_amd64-pfSense_v2_3_4/meta.txz: Network is unreachable
repository pfSense has no meta file, using default settings
pkg: https://pkg.pfsense.org/pfSense_v2_3_4_amd64-pfSense_v2_3_4/packagesite.txz: Network is unreachable
Unable to update repository pfSense
Error updating repositories!

„Network is unreachable“ führte auf die richtige Spur. Diese pfSense wurde neulich im Zuge einer Telekom-VDSL/VoIP-Umstellung vom Router zum VPN-Server „degradiert“, da nun ein LANCOM-Router den Zugang regelt. Jedenfalls wurde schlicht beim Ändern der Konfiguration übersehen, das Standard-Gateway zu ändern.

Das die Updates nicht laufen, kann allerdings auch andere Gründe haben. Im Einzelfall muss immer geprüft werden, woran es hängt.

Der Titel ist Programm: Wer hat als Anwender oder Admin Erfahrung mit engelhaustechnik von Engel Dataconcept GmbH?

Wir betreuen seit ca. drei Jahren einen Heizungs- und Sanitärbetrieb mit einer engelhaustechnik-Installation an dem fünf Arbeitsplätze hängen. Solange wir den Kunden kennen kämpft man bereits mit Performance-Problemen. In dieser Zeit wurde der Quasi-Server von Windows 7 auf Windows Server 2012 (ohne R2, Bestand vom Kunden) geändert, mit einer Ausnahme alle Arbeitsplätze von klassischem PC auf Terminalserverbetrieb mit Igel-ThinClients umgestellt, der Arbeitsspeicher vom Server (HP ProLiant ML350p Gen8) verdoppelt, Ausnahmen im Virenscanner konfiguriert, eine Aufgabe angelegt das Nachts eine Reorganisation der Datenbank durchgeführt wird, vor drei Monaten wurde testweise die Software (zwei Hyper-V VMs: 1x Fileserver, 1x WTS) vom Kundenserver auf eine Leihmaschine von uns, die mit SSDs bestückt ist verschoben, der engel-Außendienst war ebenfalls bereits vor Ort und hat diverse Einstellungen geändert. Zu guterletzt wurden automatische nächtliche Neustarts eingerichtet, da es anscheinend bei den Druckjobs zu einem memory leak kommt.

Dauerhaft blieb das Programm leider nicht schnell. Monatelange Dauertests als auch Messungen zeigen, das der Server (gemeint ist der Hypervisor als auch die VMs) sich größtenteils langweilen, die hauptsächliche Last ist die nächtliche Datensicherung.

Seit Anfang des Jahres kommt es darüberhinaus bei fast jedem Update der Branchensoftware zu Fehlern, die bislang meines Wissens nach immer auf fehlerhafte Datensätze in der Datenbank zurückzuführen waren. Wie diese zustande kommen ist bislang ein Rätsel. Ganz nebenbei erwähnt: engel setzt auf SAP’s ADS.

Laut Kundenaussage war der engel-Stammtisch nicht so ergiebig, von daher hier mal der Ruf in die Runde, ob jemand Erfahrung mit dieser Anwendung hat?

Vorab schonmal vielen Dank.

CamStudio hat eine wechselvolle Geschichte, leistet aber dennoch gute Dienste, wenn es darum geht, ein Video vom kompletten Desktop, einem bestimmten Bereich oder einem einzelnen Fenster aufzunehmen.

Aufgrund des mit Ad- und/oder Malware versetzten Installers auf CamStudio.org kommt eine Installation von dort nicht in Frage. Bei SourceForge.net findet sich leider nur eine ältere Version, die zumindest bei mir unter Windows 8.1 nicht läuft. Eine weitere Quelle das Programm zu erhalten, ohne sich dabei irgendeinen Schnick-Schnack einzufangen gibt es mit der portablen Version von PortableApps.com.

Letztgenanntes hat zudem den Vorteil, das keine Installation benötigt wird und somit das Programm einfach und überall genutzt werden kann. Nach erfolgtem Entpacken kann nahezu direkt losgelegt werden.

Je nach Qualitätsanspruch oder wenn CamStudio bei der Aufnahme abstürzt kann es notwendig sein, zuerst den Compressor (Codec) zu ändern:

Options - Video-Options - Compressor

„Microsoft Video 1“ ist meist kompatibel und oft der kleinste gemeinsamer Nenner, dieser findet sich z.B. auch auf Windows Servern (falls man mal etwas dort aufzeichnen muss) Allerdings ist die Qualität mitunter nicht so toll und die Datei wird relativ groß. Nicht jeder Codec funktioniert mit jeder Anwendung, so kommt man mitunter an durchprobieren nicht vorbei.

Marco Radoux von machines.de schrieb mich an mit einem Beitragsvorschlag basierend auf seiner Erfahrung mit DPInst.exe beim Umzug einer Windows 7-Installation auf einen Intel NUC6i5.

Grundsätzlich sollte vor jedem Umzug geprüft werden, ob das Betriebssystem mit der neuen Hardware kompatibel ist. Im Fall der Intel NUCs lohnt ein Blick auf die Homepage des Herstellers:

Intel Support – Supported Operating Systems for Intel® NUC Products

Der Umzug ansich ist dabei nicht das eigentliche Problem, sondern der Umstand, das diverse Treiber nicht in Windows 7 integriert sind und man nach dem Umzug z.B. aufgrund fehlender USB 3.x- und Netzwerktreiber das System weder an der Konsole noch aus der Ferne steuern kann.

Abhilfe kann vorab das Installieren der notwendigen Treiber schaffen. Alternativ ließe sich ein Skript erstellen, das automatisch beim ersten Start auf der neuen Hardware ausgeführt wird und die Treiber installiert. Imho gefällt mir vorab die Treiber zu installieren besser. An dieser Stelle kommt DPInst ins Spiel:

Driver Package Installer (DPInst) ist bzw. war Teil des Windows Driver Kit (WDK). Ab dem Windows 10 Version 1607 WDK ist es nicht mehr enthalten (siehe DIFx Guidelines), d.h. zuletzt war es in Version 1511 enthalten. Aktuell findet sich der Downloader noch hier:

http://download.microsoft.com/download/C/E/1/CE19C726-6036-4443-845B-A652B0F48CD7/wdk/wdksetup.exe

Genau genommen handelt es sich bei diesem WDK um Version 10.0.10586.0. Nach der Installation findet sich die für die Sprache und der 32-/64-bit Architektur passende Version unter

C:\Program Files (x86)\Windows Kits\10\redist\DIFx\dpinst

Für diesen Beitrag wurde zum Test die Version aus

C:\Program Files (x86)\Windows Kits\10\redist\DIFx\dpinst\MultiLin\x64

unter Windows 8.1 Enterprise (Evaluierungsversion) verwendet. Diese *.exe-Datei auf das Zielsystem in einen Ordner (z.B. „C:\Driver“) kopieren. Anschließend die Treiber-Dateien (min. *.inf, *.sys) in den gleichen Ordner kopieren. Möchte man Unterordner verwenden, so muss auf eine Batch- oder XML-Datei zurückgegriffen werden (siehe weiter unten). Für diesen Beitrag bzw. zum Test wurde der Treiber eines Adaptec 8405E verwendet. „dpinst.exe“ via Rechtsklick und „Als Administrator ausführen“ mit erhöhten Rechten starten und dem Assistenten folgen. Je nach Umfang der Treiber-Installation erscheint nach einer gewissen Zeit der finale Dialog:

Dieser Vorgang kann mittels Skript automatisiert werden, siehe dazu:

MS TechNet Blog – Driver installation and updating made easy: DPInst.exe

MS TechNet – Driver Package Installer (DPInst)

MS TechNet – Customizing Driver Installation

Cmehren.de – DPInst Treiber Installation

Unter „C:\Windows\DPINST.LOG“ wird ein Protokoll erstellt, das ggf. bei der Fehlersuche hilfreich ist. Von dieser Installation sieht das Protokoll wie folgt aus:

INFO:   ****************************************
INFO:   11/08/2017 21:14:38
INFO:   Product Version 2.1.0.0.
INFO:   Version: 6.0.6000
INFO:   Platform ID: 2 (NT)
INFO:   Service Pack: 0.0
INFO:   Suite: 0x0100, Product Type: 1
INFO:   Architecture: AMD64.
INFO:   Interactive Windows Station
INFO:   Command Line: '"C:\Driver\dpinst.exe" '
INFO:   DPInst is not multi-lingual.
INFO:   ****************************************
INFO:   Current working directory: 'C:\Driver'
INFO:   Running on path 'C:\Driver'
INFO:   No valid 'dpinst.xml' file provided.
INFO:   Found driver package: 'C:\Driver\adpenc.inf'.
INFO:   Found driver package: 'C:\Driver\arcsas.inf'.
INFO:   Preinstalling 'c:\driver\adpenc.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
SUCCESS:c:\driver\adpenc.inf is preinstalled.
INFO:   RETURN: DriverPackagePreinstallW  (0x0)
INFO:   ENTER:  DriverPackageGetPathW
INFO:   RETURN: DriverPackageGetPathW  (0x0)
INFO:   Preinstalling 'c:\driver\arcsas.inf' ...
INFO:   ENTER:  DriverPackagePreinstallW
SUCCESS:c:\driver\arcsas.inf is preinstalled.
INFO:   RETURN: DriverPackagePreinstallW  (0x0)
INFO:   ENTER:  DriverPackageGetPathW
INFO:   RETURN: DriverPackageGetPathW  (0x0)
INFO:   ENTER:  DriverPackageInstallW
INFO:   Installing INF file 'c:\driver\adpenc.inf' (Plug and Play).
INFO:   Looking for Model Section [ADAPTEC_device.NTamd64]...
INFO:   No matching devices found in INF "C:\Windows\System32\DriverStore\FileRepository\adpenc.inf_amd64_875b5554aac4a142\adpenc.inf" on the Machine.
INFO:   No drivers installed. No devices found that match driver(s) contained in 'C:\Windows\System32\DriverStore\FileRepository\adpenc.inf_amd64_875b5554aac4a142\adpenc.inf'.
INFO:   RETURN: DriverPackageInstallW  (0xE000020B)
INFO:   No matching device was found for 'c:\driver\adpenc.inf'. Driver will be installed when plugged in.
INFO:   ENTER:  DriverPackageInstallW
INFO:   Installing INF file 'c:\driver\arcsas.inf' (Plug and Play).
INFO:   Looking for Model Section [ADAPTEC.NTamd64.6.2]...
INFO:   No matching devices found in INF "C:\Windows\System32\DriverStore\FileRepository\arcsas.inf_amd64_36103e6b6a2652f6\arcsas.inf" on the Machine.
INFO:   No drivers installed. No devices found that match driver(s) contained in 'C:\Windows\System32\DriverStore\FileRepository\arcsas.inf_amd64_36103e6b6a2652f6\arcsas.inf'.
INFO:   RETURN: DriverPackageInstallW  (0xE000020B)
INFO:   No matching device was found for 'c:\driver\arcsas.inf'. Driver will be installed when plugged in.
INFO:   Created entry in Add or Remove Programs for 'C:\Windows\System32\DriverStore\FileRepository\adpenc.inf_amd64_875b5554aac4a142\adpenc.inf'.
INFO:   Created entry in Add or Remove Programs for 'C:\Windows\System32\DriverStore\FileRepository\arcsas.inf_amd64_36103e6b6a2652f6\arcsas.inf'.
INFO:   Returning with code 0x200
INFO:   11/08/2017 21:17:34

In diesem Fall „meckert“ das System an, dass das Gerät nicht vorhanden ist, der Treiber wurde Windows dennoch bekannt gemacht, so das der Treiber instaliert wird, sobald es das entsprechende Gerät vorfindet.

Vor einer Weile rief mich ein Kollege an mit folgender Situation:

Bei einem seiner Kunden hatte ein Verschlüsselungstrojaner zugeschlagen, d.h. der Server, die Arbeitsplätze, alle für den Schädling erreichbaren Daten verschlüsselt. Da der Kunde vergessen hatte regelmässig die USB-Festplatte zu wechseln, auf die täglich die Datensicherung läuft, war das letzte verfügbare Backup gut ein halbes Jahr alt.

Soweit also ein Zustand quasi kurz vor grande inferno.

Kurzerhand wurde der Server, ein Windows Small Business Server, aus der Datensicherung wiederhergestellt, allerdings wollte dieser nicht so recht. Beim Starten gab es bereits Unstimmigkeiten, der angepeilte reguläre Betrieb klappte ebenfalls nicht.

Beim Wiederherstellen von „älteren“ Backups von Domänen-Computern, ganz gleich ob Domänen-Mitglied oder Domänencontroller, muss man immer bedenken, das sich inzwischen die Computer-Kennwörter geändert haben. Diese werden automatisch generiert und aktualisiert, je nach Windows-Version und ggf. eigener Konfiguration geschieht dies i.d.R. alle 30 Tage.

An dieser Stelle der Hinweis, das die folgende Vorgehensweise nur für einzelne bzw. alleinige Domänencontroller funktioniert! Hat man zwei oder mehr Domänencontroller im Einsatz sollte davon abgesehen werden, diese wieder ins Netz zu bringen (Stichwort: USN Rollback, dieses sollte unbedingt vermieden werden)!

Mein Vorschlag lautete, den Server vom Netzwerk zu trennen, allerdings muss die Netzwerkkarte mit einem Switch verbunden sein, damit ein „Link up“ vorhanden ist, dann im BIOS das Datum z.B. auf einen Tag nach der letzten erfolgreichen Sicherung stellen und erst dann die Wiederherstellung durchführen.

Hintergedanke dieser Vorgehensweise ist, das nach der Wiederherstellung das System erstmal sozusagen in einem bekannten Zeitrahmen ist. Wenn das soweit geklappt hat, aus Windows heraus das Datum ändern, damit das Betriebssystem „bewusst“ den Zeitwechsel mitbekommt. Erst dann wieder den Server ans reguläre Netzwerk anschließen.

Lange Rede, kurzer Sinn: Das hat soweit funktioniert, ist allerdings die Kurzfassung. Alle Details was zuvor und danach noch gelaufen ist, habe ich nicht mehr im Kopf. Wichtig war mir an dieser Stelle, den Kern der Lösung zu dokumentieren.

Schön wenn man am Montag-Morgen mit einer Speicherplatzwarnung bei einem Kunden durch das Monitoring begrüßt wird. Das ist soweit harmlos, da noch Puffer vorhanden ist, also kann man in Ruhe auf Ursachensuche gehen. So geschehen an diesem trüben und kalten Morgen.

Man könnte meinen, der Server, ein Windows SBS 2008 weiß das er abgelöst werden soll und gibt sich deswegen auf die letzten Tage nochmal Mühe einen zu Nerven (da gab es noch mehr Vorfälle als diesen hier). Der neue Server steht schon bereit bzw. wird gerade vorbereitet und dann geht es an die Migration. Damit wird der vorletzte SBS bei unseren Kunden abgelöst.

Zur Sache: Wenn langsam aber sicher der Speicherplatz schwindet, kann das jenseits vom „natürlichen“ Datenwachstum andere Ursachen haben. In diesem Fall lag es an der SharePoint-Datenbank des SBS. Genauer ausgedrückt lag es am Transaktionsprotokoll, das mittlerweile 11.5 GB an Größe erreicht hatte. Da dieses auf Laufwerk C: unter

C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data

liegt und zudem „nur“ SSDs mit einer Kapazität von 240GB zum Einsatz kommen, wurde es langsam zusammen mit allen anderen Programmen und Daten knapp.

Da SharePoint bei diesem Kunden nicht verwendet wird, wurde schlicht die Datenbank bzw. Protokoll verkleinert und das Sicherungsmodell geändert. Die Lösung fand sich sehr schnell im Blog von Bent Schrader:

Bents Blog – SharePoint Datenbanken auf Windows Small Business Server 2008 verkleinern

Einfach wie beschrieben vorgehen.

Sowohl Mirko als auch Daniel haben sich bei mir gemeldet mit dem Hinweis, das die Windows Updates vom November 2017 Nadeldrucker lahmlegen. Offenbar ist dieses Problem nicht auf eine bestimmte Windows-Version beschränkt, da es Meldungen von Windows 7 bis Windows 10 gibt.

Abhilfe scheint aktuell nur die Deinstallation der Updates zu bringen. Daniel hat mir diesen Link zukommen lassen (Danke dafür):

Windows TenForums – Dot Matrix Printer Stopped Working After Update

Betroffen sind nach aktuellem Kenntnisstand Nadeldrucker von Epson, genannt wurden bislang die Modelle LQ-630 und LX-310, LX300, LQ2180, LQ2190, LQ-590.

Als Workarounds außer komplett die Updates zu installieren finden sich im Forum noch die Möglichkeit den Anschluss umzuleiten:

Antwort von „dadaniel“:

I have the same problem, the only workaround I found is using
"net use LPT2 \\pc\printer" and install printer and point it to LPT2
on another PC without the update.

„louis8888“ deinstallierte folgende Updates:

I'm having the same issue too after the windows update on my Windows 7 in my office.
I'm not sure which update causing the issue but I uninstalled KB4048957 and KB2952664
which updated on 15/11/2017 or 16/11/2017 mostly the November system updates and
my dot matrix printer Epson LQ590 printing issue fixed and resolved!"

„sergitux“ liefert für die Deinstallation folgendes Skript, das je nach Windows-Version angepasst werden muss:

KB Windows10: KB4048953 & KB4048954
KB Windows 8.1: KB4048958
KB Windows 7: KB2952664 & KB4048958

@echo off
cls
wusa /uninstall /kb:4048953 /quiet /warnrestart
wusa /uninstall /kb:4048954 /quiet /warnrestart
wusa /uninstall /kb:4048958 /quiet /warnrestart
wusa /uninstall /kb:2952664 /quiet /warnrestart
exit

Verwendet man Outlook (mit mehreren Profilen) und dazu läuft noch ein MailStore Client, der gerade Mails aus einer Datendatei (PST) archiviert oder in eben eine solche Datei exportiert, so kann Outlook in dieser Zeit nicht geöffnet werden.

Genau genommen startet Outlook dann schon, aber es läuft der Ersteinrichtungs-Assistent an, was an dieser Stelle eher weniger praktisch ist. Hatte man Outlook schon offen und startet dann erst den MailStore Client samt Archivierungs-/Exportaufgabe gibt es meines Wissens nach keine Schwierigkeiten, das kommt möglicherweise darauf an, wer wohin archiviert. Ausgetestet ist das nicht.

Das Einstellen unter „Systemsteuerung – Mail“ das beim Start von Outlook abgefragt wird welches Profil genommen werden soll funktioniert an dieser Stelle leider nicht, da dennoch der Assi startet. Lösen kann man dies über einen gezielten Aufruf von Outlook mit dem Profil:

Die Outlook-Verknüpfung bearbeiten und bei Ziel (d.h. hinter „…\outlook.exe“)

/profile "<Profilename>"

anhängen. Nur „/profile“ um den Auswahldialog der Profile zu erhalten funktioniert übrigens nicht, es erscheint eine Meldung das Outlook nicht nochmal gestartet werden kann.

Ein wenig Hintergrund

Aktuell sammeln wir bei einem Kunden massenhaft PST-Dateien ein, da von Outlooks-Datendateien auf MDaemon mit Outlook Connector (OC) gewechselt wird. Damit die Bestandsdaten wie Mails, Termine, Kontakte, … übernommen werden können, läuft ein dedizierter Computer mit Office und MailStore Client, der den ganzen lieben langen Tag nur dazu da ist, die Daten zu migrieren. Während Termine & Kontakte einfach innerhalb von Outlook auf das OC-Konto umkopiert werden, archiviert MailStore die Mails aus den Datendateien, zum Zeitpunkt des Schreibens dieser Zeilen ist man bei knapp 300.000 Nachrichten angekommen, die Migration ist aber noch im Gange.

Bei einem wenige Tagen altem MDaemon Server vielen mir etliche Fehler im Ereignisprotokoll-System von dieser Art auf:

Protokollname: System
Quelle:        Schannel
Datum:         16.11.2017 15:56:12
Ereignis-ID:   36888
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      srv02.domain.local
Beschreibung:
Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet.
Dies kann dazu führen, dass die Verbindung beendet wird.
Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 20.
Der Windows-SChannel-Fehlerstatus lautet: 960.

Kurz beim Support nachgefragt, kam der Tipp zurück, zum einen den Webserver via

https://www.ssllabs.com/ssltest/

zu prüfen, was so out-of-the-box ein eher schlechtes Ergebnis liefert, sofern nicht schon etwas getan wurde oder z.B. ein Reverse Proxy, Security Gateway o.ä. vor den Webserver geschaltet wurde. Als weiterer Hinweis kam, man solle mit folgendem Tool die best practice in Sachen SSL/TLS anwenden und neustarten:

IIS Crypto (Download)

Wie hängt das nun mit dem MDaemon zusammen?

Die Antwort darauf liefert alt-n in seinem Blog:

The encryption protocol and cipher used by MDaemon and SecurityGateway
depend on the operating system and can be configured via the registry.
You can use the free IIS Crypto tool to set the appropriate registry keys.
More information can be found here:
https://www.nartac.com/Products/IISCrypto

Quelle: SecurityGateway 4.5.1 – With Integrated Encryption, Tracking & E-Sign with RMail!

Bevor man nun Blindlinks IIS Crypto laufen lässt, sollte man sich darüber im Klaren sein, was alles von SSL/TLS abhängig ist. Dabei spielt eine Rolle ob, was alles auf dem Server läuft. Lesenswert dazu ist dieser Artikel von Rob Willis:

RobWillis.info – Hardening SSL & TLS connections on Windows Server 2008 R2 & 2012 R2

Danksagung

Vielen Dank an den Support von EBERTLANG für die schnelle Antwort und die Tipps.

Update 16.11.2017 – 20:29

Bei einer Prüfung mit Qualys SSL Server Test gegenüber einem Kerio Connect-Server der auf einem Windows Server läuft erhält man man out-of-the-box die Note A (sofern man ein öffentliches Zertifikat verwendet). Verwendet man ein selbst-signiertes Zertifikat, erhält man ein T mit dem Hinweis, wenn man dies ignoriert, es ein A wäre.

Daraus kann man gut Erkennen, das es darauf ankommt, ob Windows-Bordmittel verwendet werden oder ob der jeweilige Webserver eigene Komponenten und Konfiguration benutzt.

Seit Java 8 Update 131 ist MD5 als Prüfsummen-Algorithmus gesperrt. Versucht man z.B. auf ein BMC der Marke ASUS ASMB8-iKVM zwecks Remoteverwaltung zuzugreifen, so erhält man eine Fehlermeldung, die einem erklärt, dass das JAR mit „MD5withRSA“ signiert ist und dies als unsicher gilt.

Trotz Update der Firmware auf 2.04.51, die eigentlich genau für diese und neuere Java-Versionen gedacht ist, hilft (zumindest bei mir) nicht. Ein Workaround besteht darin, in Java die Sperrung aufzuheben:

• Die Datei

  C:\Program Files (x86)\Java\jre1.8.0_151\lib\security\java.security

  mit erhöhten rechten editieren. Ggf. zuvor den Pfad anpassen.

• In der Zeile „jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024“ den „MD5“-Eintrag entfernen und die Änderung speichern.

Nun klappt der Zugriff wieder. Eine Anfrage meinerseits beim Support läuft, mal sehen, ob es noch einen anderen Weg gibt.

Quelle:

ammann – Java Fehler „MD5withRSA“ bei IPMI-KVM-Zugriff

Update 17.11.2017

Da es sich bei dem Server, auf den ich Zugreifen wollte um einen Wortmann Terra Miniserver handelt, hatte ich beim dortigen Support nachgefragt. Nun kam eine Antwort:

Asus (und auch andere Hersteller) arbeiten dran.
Leider habe ich keine Timeline, und sehr wahrscheinlich muss ein
komplette Bios-IKVM Update gemacht werden, daher die länge Entwicklungszeit.

Ist zwar nicht das Erhoffte, aber es gibt wenigstens den oben genannten workaround. Parallel dazu kann man wohl sagen: Wohl dem, der BMCs mit KVM-Funktionalität auf HTML5-Basis hat. Bei so manchen selbst Jahre altem Supermicro-System gab es bereits Updates, die von Java auf HTML5 gewechselt sind.

Das es sich bei Firefox 57 (aka Quantum) um einen weiteren Meilenstein in der Geschichte dieses Browsers handelt steht meiner Meinung nach außer Frage. Leider ist so manches Add-on nicht kompatibel. Davon betroffen ist z.B. der Session Manager von Michael Kraft, da dieser noch dem alten Add-on Typ entspricht. Und nun?

Wer aktuell auf dieses Add-on angewiesen ist, dem bleibt nur ein Schritt zurück, d.h. auf Firefox 56.0.2 downzugraden. Das Setup kann man hier herunterladen:

https://ftp.mozilla.org/pub/firefox/releases/56.0.2/

Unbedingt das automatische Aktualisieren von Firefox vor dem Downgrade deaktivieren, sonst hat man nach ein bis zwei Firefox-Starts wieder Version 57. Nach dem Download einfach das Setup ausführen und über die bestehende Installation sozusagen drüberbügeln.

Da sich mit Firefox 57 das Theme ändert, ist dieses auch in Version 56.x verändert. Um dieses Wiederherzustellen, mit der rechten Maustaste auf die Symbolleiste klicken und „Anpassen…“ auswählen. Anschließend auf „Standard wiederherstellen“ klicken und ggf. noch so manches Symbol wieder zurechtrücken.

Leider muss man sagen, das die Änderung ja nicht ohne Ansage oder Ankündigung kam. Ich hoffe sehr, dass dieses Add-on eine Aktualisierung erfährt. Entsprechende Wünsche von Anwendern existieren jedenfalls:

Session Manager – Bewertungen

Bugzilla – Not compatible with firefox 57+?

mozillaZine – [Ext]Session Manager 0.8.1.13 – January 30, 2017

Ein Dauerzustand, d.h. mit alter Firefox-Version (jenseits der ESR) unterwegs zu sein, sollte dies allerdings nicht sein.

Update 17.11.2017

Mit MySessions steht eine Alternative zur Verfügung. Siehe dazu:

Firefox 57: MySessions als Session Manager-Alternative inkl. Import bisheriger Sitzungen

Im letzten Beitrag wurde bereits beschrieben, wie man durch ein Downgrade auf Firefox 56.0.2 den Session Manager wieder nutzen kann. Da dies wie zuletzt angemerkt keine Dauerlösung sein sollte, anbei eine Alternative.

Durch den Session-Manager-Thread im mozillaZine-Forum bin ich über das Add-on MySessions gestolpert:

[Ext]Session Manager 0.8.1.13 – January 30, 2017

Firefox Add-on – MySessions

Damit steht eine Alternative zum Session Manager zur Verfügung, der mit Firefox 57 kompatibel ist. Ein weiterer Pluspunkt ist, das man Sitzungen aus dem Session Manager Add-on importieren kann.

Sitzungen aus Session Manager importieren

• Nach der Installation des Add-ons auf das Symbol und dann auf „Import“ klicken.
• Nun auf „Import file“ und auf „Durchsuchen“ klicken.
• Zum Ort des Session Manager-Sitzungen navigieren:
• C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\<profilename>.default\sessions
• Z.B. die neueste Datei anklicken und ggf. Auswählen, welche Tabs geöffnet werden sollen.

Man kann wohl sagen, da ist noch Luft nach oben: Das Laden meiner aktuellen Sitzung mit 170 Tabs dauerte mehrere Minuten, dies ist mindestens der Wartezeit zwischen dem Laden von zwei Tabs (diese entspricht 300 ms) geschuldet als auch dem Umstand, das wohl alle Seiten geladen werden. Das ergibt für einen Poweruser eine mehrminütige Geduldsprobe, aber es klappt.

Beim Öffnen einer Sitzung wird ein neues Firefox-Fenster geöffnet und dort die Tabs geladen. Das kann man gut finden oder auch nicht (schlichtweg Geschmackssache).

Aktuell kann dieses Add-on nicht mit dem Handling und der Performance des Session Managers mithalten, aber es läuft soweit ich das nach dieser kurzen Zeit beurteilen kann.

Heute ist bei mir irgendwie Firefox (57)-Tag: Nachdem nun die aktuelle Version läuft und auch das Ding mit dem Session Manger geklärt ist (siehe vorangegange Beiträge), war ich mal neugierig da nun 170 Tabs offen sind und die Seiten dank MySessions auch geladen wurden, wie es um den Arbeitsspeicherverbrauch steht.

Bislang lag der Verbrauch bei gut 2,3 GB (wohlgemerkt 64-bit Version von Firefox). In der Vergangenheit sah man sich dazu gezwungen entweder immer mal wieder „about:memory“ aufzurufen um via „GC, CC und Minimize memory usage“ den Verbrauch zu senken oder mit Tools wie Firemin diesen zu reduzieren, da es irgendwann nicht mehr Rund lief.

Bis Version 56.x wurden alle Seiten bzw. Tabs unter einem Hauptprozess ausgeführt, in Folge war es relativ leicht festzustellen, wieviel Arbeitsspeicher Firefox belegt. Nun ist dies anders:

Ja, es wird mehr belegt, dafür läuft es imho auch besser. Bei mir war es oft so, das Firefox lahmte, aber noch jede Menge RAM frei war. Nach den ersten Stunden mit Firefox 57 sieht das zumindest für den Moment anders aus. Es flutscht soweit.