Bei einem Kunden musste Notfallbedingt ein Server ausgetauscht werden. Es kam ein anderer Server mit gleichem Betriebssystem zum Einsatz, diverse Daten wurden aus der Datensicherung wiederhergestellt. Lediglich die Aufgaben konnten vorab nicht ex- und in Folge nicht importiert werden.

Als Plan B kann man die Dateien der gewünschten Aufgaben aus dem Ordner

C:\Windows\System32\Tasks

auf das neue bzw. andere System kopieren. Anschließend kann man wie gewohnt in der Aufgabenplanung Diese bearbeiten. I.d.R. müssen, sofern verwendet, die Anmeldeinformationen aktualisiert werden.

Bemerkung am Rande: Auch wenn die Aufgaben-Dateien im genannten Ordner keine Endung haben, so handelt es sich um XML-formatierte Dateien.

Besser ist es in jedem Fall geordnet und geplant eine Migration ganz gleicher welcher Art durchführen zu können. In einer Notfallsituation kann es allerdings vorkommen, das es schnell gehen muss.

So kam es überraschend bei einem Kunden zum Ausfall eines Server, unglücklicherweise war dieser zudem der OCC-Connector von Server-Eye. Offensichtlich gibt es einen Fallback, sollte der OCC-Connector nicht erreichbar sein, so das die Sensorhubs dann direkt ans OCC melden. Man ist also nicht völlig blind.

Geplant lässt sich der OCC-Connector wie bei Server-Eye beschrieben umziehen:

OCC-Connector umziehen

Ebenfalls interessant ist dieser Artikel:

OCC-Connector neu installieren ohne Werte und Sensoren zu verlieren

Quick & dirty kann man auch so vorgehen:

• Vom Altsystem aus den Ordner „C:\ProgramData\ServerEye3“ auf das neue System an gleicher Stelle kopieren.
• Das Server-Eye-Setup bis zum Einrichtungsassistenten laufen lassen und dann beenden. Dieser Schritt ist wichtig, damit die Programmdateien, Dienste und Firewall-Regeln vorhanden sind.
• Die Dienste „Server-Eye OCC Connector“ und „Server-Eye Sensorhub“ starten.

Im OCC meldet sich das neue System wie der bisherige OCC-Connector, d.h. unter gleichem Namen. Bis alle Sensoren laufen, kann es einen Moment dauern, bis im Hintergrund die notwendigen Dateien heruntergeladen wurden. Mitunter kommt es vor, das der eine oder andere Sensor neu konfiguriert werden muss. Konkret mussten wir das bei einem Securepoint-Sensor tun.

Hinweis: Empfohlen ist das nicht und nur ein Notbehelf!

Drive Snapshot sichert virtuelle Computer als auch andere Daten unter Windows mithilfe der Schattenkopien (VSS). Bei der Wiederherstellung sind ggf. ein paar Dinge zu beachten.

Im Augenblick der Datensicherung erstelt Hyper-V einen Sicherungsprüfpunkt (Backup Checkpoint), dies ist wichtig zu wissen, denn man kann nicht einfach die VHD(X) zurückkopieren. Bei der Wiederherstellung z.B. auf einen neuen Hyper-V Host kopiert man den gesamten Ordner bzw. alle relevanten Dateien des virtuellen Computers auf das System. Anschließend importiert man den virtuellen Computer im Hyper-V Manager.

Bereits an diesem Punkt kann der virtuelle Computer gestartet werden. Unter „Prüfpunkte“ sieht man allerdings, das der Sicherungsprüfpunkt verwendet wird:

Wie bei Prüfpunkten so üblich, werden Änderungen in der virtuellen Festplatte nicht in der *.vhd(x) sondern in eine *.avhd(x) geschrieben. Je mehr Änderungen sich ergeben, umso größer wird diese. Man sollte also bei Zeiten den Sicherungsprüfpunkt „loswerden“. Leider geht dies nicht im Hyper-V Manager, dafür aber in der Powershell:

Get-VMSnapshot-VMName “<VMName>” | Remove-VMSnapshot

Anschließend kann im Hyper-V Manager der Fortschritt beobachtet werden:

Der Vorgang kann im laufenden Betrieb durchgeführt werden. Je nach Umfang und Leistungsfähigkeit des Servers kann dies eine Weile in Anspruch nehmen. Ggf. ist es notwendig die Ansicht des Hyper-V Managers zu aktualisieren, damit der Prüfpunkt nicht mehr angezeigt wird.

Im Dateisystem bleibt mitunter eine „<VMName>-AutoRecovery.vhdx“ übrig. Meiner Erfahrung nach kann diese einfach gelöscht werden. Zumindest sind mir bislang keine negativen Auswirkungen unter gekommen. Angabe ohne Gewähr.

Quellen:

Alexander’s Blog – Removing Backup Checkpoint in Hyper-V That Has No Delete Option

Working Hard In IT – Remove Lingering Backup Checkpoints from a Hyper-V Virtual Machine

Das pfSense Wake-on-LAN (WoL) beherrscht und automatisiert werden kann wurde bereits im Beitrag pfSense: Automatisches Wake-on-LAN einrichten beschrieben. Möchte man nun WoL aus der Ferne nutzen, so bietet es sich an über ssh den notwendigen Befehl abzusetzen.

Aus der Ferne ist in diesem Kontext z.B. mit über’s Internet, via VPN oder aus einem anderen Netz heraus zu verstehen. Damit das Ganze sicher vonstatten geht, wird ssh mit einem eigenen Benutzer verwendet. Grundsätzlich könnte man auch den admin-/root-Benutzer her nehmen, das wäre allerdings zuviel des Guten.

ssh aktivieren

• Am Web-Interface anmelden.
• Zu „System – Advanced“ wechseln.
• Den Haken setzen bei „Enable Secure Shell“ und die Änderung speichern.

ssh-Benutzer anlegen

• Zu „System – User Manager“ wechseln.
• Auf „+ Add“ klicken und einen neuen Benutzer hinzufügen. Es muss mindestens ein Benutzername und ein Kennwort vergeben werden.
• Den neu angelegten Benutzer bearbeiten und bei „Effective Privileges“ auf „+ Add“ klicken.
• Bei „Assigned privileges“ „User – System: Shell account access“ auswählen und speichern.

Tipp: Sollen mehrere Benutzer ssh-Zugriff erhalten, am besten eine eigene Gruppe anlegen und die notwendigen Rechte zuweisen.

Ggf. müssen noch Firewall-Regeln angelegt werden, je nachdem von wo, gemeint ist welche Schnittstelle oder welches Netz, man sich verbindet.

WoL über ssh verwenden

Nun kann man sich über ssh verbinden und mit folgendem Befehl ein Magic Paket zum Starten eines entsprechend kompatiblen und konfigurierten Computers zu starten:

/usr/local/bin/wol -i <Broadcast-Adresse des Zielnetzes> <MAC-Adresse>
z.B.
/usr/local/bin/wol -i 192.168.1.255 12:34:56:78:90:12

WoL per Doppelklick

Damit man via Doppelklick unter Windows den Startbefehl absetzen kann, kommt KiTTY, ein PuTTY-Fork, zum Einsatz. Bequem ist hier, das man die Zugangsdaten als auch den Befehl hinterlegen kann.

• KiTTY starten.
• Bei „Session – Hostname“ die IP-Adresse oder den Hostnamen der pfSense eintragen.
• Unter „Connection – Data“ in den „Auto-Login“-Feldern den Benutzernamen und das Kennwort eintragen.
• Unter „SSH“ im Feld „Remote command“ den obigen Befehl eintragen.
• Der Sitzung einen Namen geben und diese abspeichern.
• Eine Verknüpfung zu KiTTY anlegen und den Befehl erweitern:
• kitty_portable.exe -load „<Sessionname>“

Klickt man die Verknüpfung doppelt an, so wird automatisch eine ssh-Verbindung aufgebaut, der Befehl abgesetzt und die Verbindung wieder beendet.

Auf diese Weise kann man z.B. bequem vom Sofa aus den Rechner in der Firma starten.

Quellen:

pfSense – HOWTO enable SSH access

KiTTY : Command-line options

Smart Home Beginner – Putty shortcut to saved session in Windows

PuTTY – Chapter 3: Using PuTTY

Nach der Neuinstallation eines Kunden-PC mit Windows 10 klappte im Homeoffice der Betrieb mit einer PS/2- und einer USB-Funk-Tastatur nicht mehr.

In unserer Werkstatt kam eine kabelgebundene USB-Tastatur zum Einsatz, dabei viel nichts negatives auf. Gute zwanzig Minuten nachdem der Kunde seinen PC abgeholt und im Homeoffice aufgestellt hatte kam der erste Anruf, das die Tastatur nicht gehen würde. Nach kurzem Gespräch stellte sich heraus, das der Kunde eine PS/2-Tastatur verwendet. Diese hatte zuvor mit dem gleichen PC und Windows 7 einwandfrei funktioniert.

Auf die Schnelle fand sich im Netz dazu z.B. folgendes:

Microsoft Community – PS/2 drivers windows 10

superuser – Do PS2 Keyboards work on Windows 10

Probleme scheinen also nicht unbekannt zu sein. Abhilfe soll Updaten oder Neuinstallieren der Treiber zu schaffen. Beides wurde durch den Kunden nicht versucht.

Damit man (hoffentlich) schneller wieder zu Gange gehen konnte, wurde eine USB-Funk-Maus/Tastatur-Kombi von Logitech angeschlossen. Der Receiver wurde richtig erkannt und installiert. Die Maus funktioniert auf Anhieb, die Tastatur allerdings nicht. Das die Kombi ansich in Ordnung ist, konnte der Kunde durch die Angabe, das er diese an seinem Tablet ohne Probleme verwendet geklärt werden. Batteriewechsel und ein Pairing halfen nicht. Seitens des Herstellers kann die Kompatibilität mit folgender Aufstellung geklärt werden:

Logitech Support – Windows 8 and Windows 10 support for Logitech mice and keyboards

Leider verriet der Kunde nicht, welches Modell er zur Hand hat.

Ein weiterer Kandidat für Schwierigkeiten kann nach wie vor der USB Guard von G Data sein (betrifft auch die Einzelplatzlösungen):

G Data Antivirus Business 13.2 und Thinstuff XP/VS Server: Probleme mit der Tastatur ab dem dritten angemeldeten Benutzer

Ein Deaktivieren dieser Schutzfunktion änderte ebenfalls nichts. Letztlich hat der Kunde eine kabelgebundene Maus und Tastatur angeschlossen.

Server-Festplatten sollten lange halten, wenn nicht greift i.d.R. zumindest bei Seagate eine längere Garantie, meist fünf Jahre. Mit den Seagate Cheetah ST3600057SS 600GB haben wir aktuell aber kein Glück.

Zugegeben, wir haben diese Festplatten nur bei einem Kunden in einem Server im RAID10-Verbund im Einsatz. Es ist aber schon auffällig, das in gut drei Jahren vier Festplatten ausgefallen sind und auch schon bereits ausgetauschte Festplatten ebenfalls wieder ausfallen. Bislang zeigten sich zwei Fehlerbilder: Medienfehler, gemeint sind damit fehlerhafte Sektoren oder Totalausfall. Letzteres ohne Vorankündigung.

So ergab es sich vergangenes Wochenende das nur wenige Stunden zwischen melden eines Medienfehlers auf einer Festplatte etwas später eine weitere Festplatte komplett ausstieg und während der Datensicherung auf einer anderen Festplatte plötzlich ebenfalls Medienfehler gemeldet wurde und letztlich noch einen Tick später das RAID komplett Tod war. Zwei ausgefallen Festplatten verkraftet ein RAID10 je nach Konstellation noch, aber bei Dreien ist definitiv Schluss.

Da das Ganze uns nun zu bunt wurde, tauschten wir den kompletten Server jetzt erstmal durch ein Leihgerät von uns aus, damit in Ruhe geklärt werden kann, was mit dem Kundengerät oder den Festplatten im Speziellen los ist.

Glück im Unglück, dass das Ganze am Wochenende geschehen ist und so trotz dieses Ärgernisses in Ruhe der Server ausgetauscht und die Datensicherung eingespielt werden konnte.

Eine Recherche im Netz lieferte nur wenige potentielle Treffer zu diesem Thema:

WebHosting Talk – Seagate Cheetah Failures?

Hier ist interessant, das der Thread-Ersteller mit den 300GB Ausgabe dieser Festpaltten keine negativen Erfahrungen gemacht hat, aber, wie bei uns, die 600GB zu Fehlern neigt.

FreeNAS Forum – Many Seagate 600GB 15K SAS Failures (ST3600057SS)

Ebenfalls viele Ausfälle, aber mit gebrauchten Festplatten.

Die Festplatten wurden jetzt erstmal nach Rücksprache zum Lieferranten zwecks Überprüfung und weiterer Abklärung eingesendet. Ich bin gespannt was dabei herauskommt und wie es weiter geht. Der Server selbst steht bei uns im RZ und läuft mit anderen Festplatten aktuell im Testbetrieb, um zu sehen, ob es zu irgendwelchen Auffälligkeiten kommt.

Das OPNsense-Projekt beobachte ich seit seiner Gründung. Für viele Anwender ist es eine Alternative zu pfSense oder der Nachfolger der m0n0wall. Im Gegensatz zu den beiden genannten ist es bei OPNsense weniger einfach, einen Zugriff auf das Web-Interface über die WAN-Schnittstelle zu ermöglichen.

Warum sollte man sowas überhaupt tun?

WAN muss nicht immer gleich das „böse“ Internet bedeuten. So kann die Firewall im eigenen Netz Bereiche oder Server abtrennen. Fernadministration oder Support wäre ein anderer Punkt. Testumgebungen ein weiterer.

Zugriff erlauben

Während es bei pfSense und seinerzeit bei der m0n0wall ausreichend war, auf der WAN-Seite in der Firewall die notwendigen Ports (z.B. 22, 443) freizuschalten, so reicht das bei OPNsense allein nicht.

In der WAN-Regel selbst muss zusätzlich unter

Advanced Options - disable reply-to

aktiviert werden:

Im übrigen gilt dies auch, wenn man den Zugriff via ssh erlauben möchte.

Verwendet man Port-Forwarding, so steht diese Option nicht in der WAN-Regel zur Verfügung. Dann kann man alternativ unter „Firewall – Settings – Advanced“ global „disable reply-to“ aktivieren. Beim Testen über mehrere Versionen hinweg war diese Änderung mal notwendig und mal nicht. Im Einzelfall also immer prüfen.

Wichtig zu wissen: Ist die genannte Option an einen der genannten Stellen aktiviert, so greift dies dann auch auf einem anderen Weg. Z.B. ist „disable reply-to“ in einer WAN-Regel aktiviert, so funktioniert es dann auch beim Port-Forwarding, selbst wenn sie global inaktiv ist.

Den Hintergrund mit dieser Option verstehe ich um ehrlich zu sein nicht ganz. Das man aus Sicherheitsgründen den Zugriff verwährt macht wiederum Sinn. Das allein scheint hier allerdings nicht der Grund bzw. Ursache zu sein.

Quellen:

OPNsense Forum – External access to opnsense GUI

OPNsense Forum – Access webGui from WAN

Bei einer Test-Wiederherstellung eines Windows Server 2016 Standard stolperte ich über die Meldung „Error 87: during write operation“ bzw. „Error 57: Falscher Parameter“.

Die Meldungen kommen vom Windows-Kernel, haben also soweit mir bekannt ist nicht direkt mit Drive Snapshot zu tun. Es spielt dabei keine Rolle, ob man versucht die gesamte Festplatte auf einmal wiederherzustellen oder manuell einzeln den Inhalt der jeweiligen Partitionen. Die Meldung erscheint lediglich bei der MSR-Partition (in diesem Fall die 1. Partition, Microsoft-reserved, 128MB groß). Diese wird im übrigen in der Datenträgerverwaltung von Windows nicht angezeigt. Nur mit diskpart (list partition) oder Tools wie eben Drive Snapshot oder „besseren“ Partitionsverwaltern sieht man Diese. Der Inhalt der anderen Partitionen lässt sich ohne Probleme wiederherstellen, bootfähig ist das System in diesem Fall ebenso und startet ohne Schwierigkeiten. Das liegt nicht zuletzt daran, das in dieser MSR-Partition keinerlei Informationen enthalten sind. Sie ist lediglich angelegt, aber weder formatiert, noch irgendwie zugewiesen. Mit anderen Worten: Man kann diesen Fehler ignorieren und muss sich keine Gedanken machen.

Die genauen Hintergründe werden bei Tom Ehlert Software, dem Macher von Drive Snapshot, untersucht. Ein Update dieses Beitrags wird folgen, sobald es neue Erkenntnisse gibt. Vielen Dank an dieser Stelle an Tom Ehlert Software für den Support und die vielen Erklärungen zu diesen Fall.

Bislang bekannt ist, das wohl das Alignment, die Ausrichtung der ersten Partition nicht stimmt. Gesichtert wurde im übrigen von einem Wortmann Terra Miniserver G3 mit Adaptec RAID 8405-Controller.

Das von Microsoft vorgesehene UEFI-Layout auf einem GPT-Datenträger sieht wie folgt aus (Beispiel von Windows Server 2012 R2):

1. Partition – MSR (Microsoft-reserved) – 128MB
2. Partition – Windows RE Tools (Recovery Environment) – 450MB
3. Partition – Boot-Partition – 100MB
4. Partition – Laufwerk C: (Windows) – Restlicher Speicherplatz

Auf dem vorliegenden System ist dieses Schema auch vorhanden bzw. verwendet worden. Die Reihenfolge als auch Größen der Partitionen können erfahrungsgemäss variieren. Dies hängt z.B. davon ab, ob per Windows-Setup und dessen Vorgaben installiert wurde oder ob ein Computer-Hersteller ein verändertes Schema/Layout verwendet. So sieht es beispielsweise auf einem per Setup installierten Windows Server 2016 Standard aus:

Partition 1 – Wiederherstellung (Win RE) – 450 MB
Partition 2 – System (Boot) – 99 MB
Partition 3 – Reserviert (entspricht der MSR) – 16 MB
Partition 4 – Primär (Windows, LW C:) – 138 GB

Test-Wiederherstellungen von anderen Windows Server 2016 Standard waren hingegen ohne irgendwelche Überraschungen erfolgreich. Gut denkbar ist, das der oder die Fehler durch das Partitionsschema vom Server-Hersteller oder dem verwendeten RAID-Controller verursacht werden. Mangels baugleichen Systems konnte bislang nicht direkt verglichen werden.

Nebenbei bemerkt war die Sicherung immer erfolgreich, keine Fehler oder Unregelmässigkeiten.

Quellen:

Thomas Krenn – wiki – OS-Installation auf UEFI-Systemen

Wikipedia – Microsoft Reserved Partition

Microsoft – Docs – UEFI/GPT-based hard drive partitions

Nach der Installation der Windows Updates vom März 2018 streikte auf einem Windows Server 2016 der WSUS.

Die Installation der Updates verlief gewohnt lahm aber erfolgreich durch. Der notwendige Neustart klappte ebenso. Allerdings war anschließend keine Verbindung der WSUS-Verwaltungsoberfläche möglich. Im Ereignisprotokoll fand sich dies:

Alle relevanten Dienste liefen allerdings. Für zusätzliche Verwirrung sorgt, das es keinen Dienst mit dem Namen „Update Services“ (mehr) gibt, vermutlich ist „WsusService“ gemeint, dieser lief allerdings ebenfalls.

Nach einem weiteren Neustart startete dann der WSUS-Anwendungspool im IIS nicht, dieser wurde manuell nachgestartet, aber so richtig rund lief es dann immer noch nicht.

Alle guten Dinge sind drei, sagt man, also nochmal neu gestartet und siehe da, es lebt wieder.

Möglicherweise hängt dies alles mit der nicht gerade üppigen Ausstattung des virtuellen Computers zusammen. So hat das System nur 4GB Arbeitsspeicher zur Verfügung. Man muss allerdings dazu erwähnen, das es seit der Inbetriebnahme keinerlei Schwierigkeiten gegeben hat. Auffällig ist, das es zu Abstürzen des IIS-Anwendungspool des WSUS kommt, wenn über die Einstellungen von Windows nach Windows Updates gesucht wird. Sucht man die Updates über sconfig geschieht dies nicht, das mag aber nur Zufall sein.

Wir haben nun erstmal mehr RAM zur Verfügung gestellt und die Speicherbegrenzung des WSUS-Anwendungspool von 1.75GB (Voreinstellung) auf testweise 0 (keine Begrenzung) gesetzt.

Mal sehen, was bei der nächsten Windows Updates-Runde geschieht.

Ein seit langem lästiges Problem sind die Verbindungsabbrüche wenn man den Serverberinigungsassistenten beim WSUS ausführt. Meist geschieht dies beim entfernen alter Updates.Für die Abbrüche kann es mehrere Ursachen, wie z.B. den Verbindungs-Timeout zur Datenbank oder langsame Hardware. Ersteres kann man relativ leicht ändern. Auf einem Windows Server 2016 mit WSUS 4.0 und WID (Windows Internal Database) hatte ich allerdings mit der grafischen Oberfläche des Management Studio (getestet mit Version 2012 und 2017) kein Glück, die Verbindungeinstellungen ändern zu können. Es erschien immer folgende Fehlermeldung beim Versuch auf die Eigenschaften zuzugreifen:

Oder als Text (damit die Suchmaschinen auch etwas davon haben):

TITEL: Microsoft SQL Server Management Studio
------------------------------

Das angeforderte Dialogfeld kann nicht angezeigt werden.

------------------------------
ZUSÄTZLICHE INFORMATIONEN:

Das angeforderte Dialogfeld kann nicht angezeigt werden. (SqlMgmt)

------------------------------

Fehler beim Abrufen von Daten für diese Anforderung. (Microsoft.SqlServer.Management.Sdk.Sfc)

Hilfe erhalten Sie durch Klicken auf: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476

------------------------------

Ausnahme beim Ausführen einer Transact-SQL-Anweisung oder eines Transact-SQL-Batches. (Microsoft.SqlServer.ConnectionInfo)

------------------------------

Für den aktuellen Befehl ist ein schwerwiegender Fehler aufgetreten. Löschen Sie eventuelle Ergebnisse.
RegQueryValueEx() returned error 2, 'Das System kann die angegebene Datei nicht finden.' (Microsoft SQL Server, Fehler: 0)

Hilfe erhalten Sie durch Klicken auf: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=12.00.2000&EvtSrc=MSSQLServer&EvtID=0&LinkId=20476

------------------------------
SCHALTFLÄCHEN:

OK
------------------------------

Die Links zu Microsoft führen allerdings ins „nirgendwo“, außer zu Surface-Werbung.

Den Timeout kann man alternativ über folgenden Weg ändern:

Eine Eingabeaufforderung öffnen:

osql -E -S \\.\pipe\Microsoft##WID\tsql\query

exec sp_configure 'show advanced option', '1';
reconfigure;
exec sp_configure; <- Zeigt die Eintellungen an, sobald das nachfolgende go abgesetzt wird. Am besten diese zur Sicherheit Kopieren.
go
exec sp_configure 'remote query timeout (s)', 0;
reconfigure with override;
go
quit

Den Dienst „Interne Windows-Datenbank“ (Dienstname: „MSSQL$MICROSOFT##WID“) neu starten, um die Änderung zu übernehmen.

Mit etwas Glück läuft der Assistent nun durch. Leider war mir das Glück nicht hold, nach etwas über 1.5 Stunde kam es erneut zum Abbruch. Wiederholte Ausführungsversuche halfen auch nicht wirklich weiter, dem Hörensagen nach, soll aber immer ein Fortschritt stattfinden.

Plan B

Es gibt einige Skripte zum Automatisieren der WSUS-Bereinigung. Ein recht umfangreiches Exemplar kommt dabei von Adam Marshall:

Adam Consulting – WSUS Automatic Maintenance

spiceworks – WSUS Automated Maintenance (Formerly Adamj Clean-WSUS)

Das Skript ist gut dokumentiert, es können bzw. müssen nur wenige Variablen den eigenen Bedürfnissen angepasst werden und automatisierbar samt E-Mail-Benachrichtung ist es obendrein auch noch. Aber das ist nicht alles: So lässt sich z.B. auch das Speicherlimit des Anwendungspools ändern, dieses Thema hatten wir ja neulich erst:

Windows Server 2016: WSUS-„Schluckauf“ nach März 2018-Updates

Im Vergleich zum Assistenten war es in diesem Fall-Beispiel nicht nur erfolgreich, sondern auch rasend schnell. Nach 1.5 Minuten waren 5980 Updates entfernt und damit ca. 78 GB zusätzlich an Speicherplatz frei. Und das war nur der „First-Run“. Weitere Durchläufe kann man mit gewünschten Parametern durchführen.

Unterwegs oder beim Surfen kann es schon mal vorkommen, das man Office-Dateien auf seinem Android-Gerät einsehen oder gar Bearbeiten muss.

Zum Betrachten und für experimentierfreudige Nutzer, da noch Beta-Stadium, auch zum Bearbeiten bietet sich der LibreOffice Viewer an:

LibreOffice Viewer for Android

Google Play Store – LibreOffice Viewer

Die App ist übersichtlich, kostet nichts, ist Open Source und ohne Werbung, aber leider bislang nicht zuverlässig. So klappte im Test mitunter nicht mal das Öffnen einer einfachen Datei. Mal ging es, mal nicht, aber was ja noch nicht ist, kann ja noch werden.

Umfangreicher ist da schon AndrOpen Office (Google PlayStore Link):

Selbst auf einem Smartphone klappt das Tippen auf die Symbole erstaunlich gut, was man zunächst nicht unbedingt annehmen würde. Die App ist zwar gratis, aber leider mächtig mit Werbung versetzt.

Neben den OpenDocument-Formaten können die Apps auch Microsoft-Office-Dateien und weitere Formate öffnen und ggf. bearbeiten.

Microsoft treibt die PowerShell weiter voran, was des einen Freud ist des anderen Leid. So ist es seit Windows 10 – 1703 (leider) der Fall, das im Kontextmenü nicht mehr die Eingabeaufforderung, sondern die PowerShell zu finden ist.

Um nur mal schnell einen „ollen DOS-Befehl“ absetzen zu können, benötigt die PowerShell-Eingabeaufforderung schon ordentlich Zeit alleine schon zum Öffnen. Ohne Zweifel ist die PowerShell mächtiger, aber wenn’s nur um Kleinigkeiten geht, schon etwas nervig immer warten zu müssen.

Eine meiner Meinung nach optimale Lösung findet sich bei Deskmodder.de:

Powershell und Eingabeaufforderung austauschen Windows 10

Nachdem die „cmd-powershell.reg“ importiert wurde, findet man im Kontextmenü sowohl die gute alte Eingabeaufforderung als auch die PowerShell, beides sogar sowohl für den aktuell angemeldetene Benutzer als auch mit erhöhten Rechten (Admin):

Das Ganze dann sogar, ohne das man vorher die Shift-Taste drücken muss.

Ein etwas kurios Phänomen beschäftigt mich gerade bei einem Windows 8.1-Notebook. Dieses geht in den Standbymodus, nachdem eine RDP-Verbindung zu diesem Gerät getrennt wurde.

Im System-Ereignisprotokoll findet sich dazu folgender Eintrag:

Protokollname: System
Quelle:        Microsoft-Windows-Kernel-Power
Datum:         10.04.2018 07:59:56
Ereignis-ID:   42
Aufgabenkategorie:(64)
Ebene:         Informationen
Schlüsselwörter:(4)
Benutzer:      Nicht zutreffend
Computer:      HOSTNAME
Beschreibung:
Das System wird in den Standbymodus versetzt.

Ursache: Systemleerlauf

Die Energiesparmodi sind allerdings deaktiviert.

Hintergrund dieser Geschichte ist, dass das Gerät mitunter via VPN und RDP verwendet wird. Dazu wird es aus dem Standby mittels WoL gestartet, dann wird gearbeitet und anschließend die Verbindung getrennt (schlicht ausge-x-t). Sofort nach dem Trennen geht das Gerät in den Standby.

Im Moment habe ich noch nicht raus, woran das liegt. Vielleicht hat ja jemand einen Tipp für mich. Vielen Dank im Voraus.

Bei der nächtlichen Datensicherung bei einem Kunden von einem Windows 7-Arbeitsplatz tauchte bei der differentiellen Sicherung plötzlich dieser Fehler auf:

07:56:17 Start of Snapshot 1.44.17383 [May 25 2016] at 29.03.2018
07:56:17 Running on Windows 7 64-bit Service Pack 1 (7601)
07:56:17 Memory Info: Total: 16221Mb, Free: 14481Mb, Pagefile total: 32441Mb, Pagefile free: 30711Mb
07:56:17 Command line: snapshot.exe C: V:\Clients\PC03\Diff-1-Thursday-$disk.sna -hV:\Clients\PC03\Full-1-Saturday-$disk.hsh -W --AllWriters -L0 --LogFile:V:\Clients\PC03\Logs\Diff-1-Thursday.log --FullIfHashIsMissing
07:56:17 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x134 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:17 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x138 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:17 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x134 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:17 ***********************************************************
07:56:17 Snapshot error physdisk, line 127
07:56:17 reading 8 sectors at sector 0 ((null))
07:56:17 last Windows Error: 5-Zugriff verweigert
07:56:17 ***********************************************************
07:56:17 ***********************************************************
07:56:17 Snapshot error physdisk, line 127
07:56:17 reading 1 sectors at sector 0 ((null))
07:56:17 last Windows Error: 5-Zugriff verweigert
07:56:17 ***********************************************************
07:56:23 Disks in backup:
07:56:23 c: -> V:\Clients\PC03\Diff-1-Thursday-C.sna
07:56:23 Preparing for backup
07:56:23 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x214 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:23 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x218 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:23 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x214 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:23 ***********************************************************
07:56:23 Snapshot error physdisk, line 127
07:56:23 reading 8 sectors at sector 0 ((null))
07:56:23 last Windows Error: 5-Zugriff verweigert
07:56:23 ***********************************************************
07:56:23 ***********************************************************
07:56:23 Snapshot error physdisk, line 127
07:56:23 reading 1 sectors at sector 0 ((null))
07:56:23 last Windows Error: 5-Zugriff verweigert
07:56:23 ***********************************************************
07:56:36 Including all available VSS writers
07:56:37 Starting Snapshot creation
07:56:37 Creating shadow set {c0963898-4ab9-4ce7-8aaf-c80d8e124d96}
07:56:40 Register shadow copy {208b39c5-e46c-427a-a3f3-3caa4b29ee0b}
07:56:40 The Volume Snapshot was created successfully
07:56:47 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x3c0 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:47 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x3c8 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:47 Read error in GPT_Check (\\.\PhysicalDrive1) for handle 0x3c0 at offset 0 (4096 bytes) Errorcode: 0x5
07:56:47 ***********************************************************
07:56:47 Snapshot error physdisk, line 127
07:56:47 reading 8 sectors at sector 0 ((null))
07:56:47 last Windows Error: 5-Zugriff verweigert
07:56:47 ***********************************************************
07:56:47 ***********************************************************
07:56:47 Snapshot error physdisk, line 127
07:56:47 reading 1 sectors at sector 0 ((null))
07:56:47 last Windows Error: 5-Zugriff verweigert
07:56:47 ***********************************************************
07:56:47 Start differential VSS backup of c: -> V:\Clients\PC03\Diff-1-Thursday-C.sna
07:56:48 free space info: total 488.385MB, 296.584MB free, 153.722MB must be saved
07:56:48 c: -> V:\Clients\PC03\Diff-1-Thursday-C.sna
08:04:09 c: 191.801MB in use - stored in 12.923MB - 7:22 minutes
08:04:09 Success
08:04:10 Deleting previously generated shadow copy
08:04:10 Unregister shadow copy {208b39c5-e46c-427a-a3f3-3caa4b29ee0b}
08:04:10 Snapshot finished successfully
08:04:10 End of Snapshot 1.44 [May 25 2016] at 29.03.2018

Die Sicherung läuft dennoch durch. Diese Meldungen kommen von Windows, also nicht von Drive Snapshot ansich. Eine Prüfung der SSD, des Dateisystems und der Ereignissprotokolle lieferte keine Auffälligkeiten. Selbst ein Update von Drive Snapshot änderte nichts. Eine Test-Wiederherstellung verlief dennoch erfolgreich und ohne Überraschungen. Unklar ist, woher diese Fehler kamen und, wenn man so möchte, wohin sie wieder verschwunden sind, denn  seit einer neuen Vollsicherung traten Sie nicht mehr auf.

Seit eingier Zeit beobachte ich ein lästiges Problem: Reagiert eine RemoteApp zeitweise nicht, da sie gerade beschäftigt ist, wird die Sitzung getrennt und gleich wieder verbunden.

Bei mehreren gleichzeitig geöffnenten RemoteApps betrifft das alle Verbindungen zum gleichen Terminalserver bzw. RDSH. „Witzigerweise“ geschieht dies bei vollständigen Desktops nicht, es liegt also irgendwie an der RemoteApp-Session.

Ebenfalls kann dies auftreten, wenn der Server einen Moment lang ausgelastet ist.

Dieses Verhalten wird im MS TechNet Forum ebenfalls beschrieben:

RDP Session Disconnect/Reconnect when RemoteApp is in Not Responding State (Server 2012)

Recht häufig habe ich das bislang bei Thunderbird als RemoteApp beobachtet. Abhilfe, zumindest teilweise, kann schaffen, die eine oder andere Maßnahmen aus folgenden Beiträgen anzuwenden:

mozillaZine – Minimize the size of a profile

mozillaZine – Performance – Thunderbird

Auf dem Server findet sich zum Zeitpunkt der Verbindungsunterbrechung folgendes:

Protokollname: Application
Quelle:        Desktop Window Manager
Datum:         10.04.2018 22:55:09
Ereignis-ID:   9009
Aufgabenkategorie:Keine
Ebene:         Informationen
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      HOSTNAME
Beschreibung:
Der Desktopfenster-Manager wurde mit dem Code (0xd00002fe) abgebrochen.

Laut Suchmaschine bedeutet das allerdings mitunter nur, das der RDP-Client beendet wurde. Auf dem Client taucht wiederum überhaupt keine Meldung auf.

Schön wäre es, wenn man einen Timeout einstellen könnte. Dazu konnte allerdings leider nichts gefunden werden.

Beim Versuch ein 3CX-Debian Linux auf einem PC Engines APU1-Board zu installieren, kam es während des Bootvorgangs zu einer Kernel Panic. Abhilfe können verschiedene Maßnahmen schaffen.

BIOS aktualisieren

Bei älteren Boards sollte zunächst das BIOS (Coreboot) auf die letzte verfügbare Version “ Build 9/8/2014 (beta, reduced „spew level“)“ aktualisiert werden. Am einfachsten geht dies, indem ein USB-Stick mit TineCore-Linux und dem aktuellen BIOS präpariert, davon das Board gestartet und den Anweisungen gefolgt wird. Einen passenden Installer für Windows und Anleitungen für Linux und MacOS findet man beim Hersteller:

PC Engines – HowTo – TineCore

Ältere SSD ersetzen

Ältere SSDs können bereits beschädigt sein oder kommen ggf. mit neueren Dateisystemen oder TRIM nicht zurecht. Siehe dazu

Wie eine pfSense auf einem PC Engines APU-Board stirbt und man sie wiederbelebt

SSD vor der Installation löschen

Manche Setups bzw. Installer stolpern über vorige Installationen auf der SSD. Auf diesem System war zuvor eine pfSense installiert. Ein löschen der Partitionen, dies geht z.B. ebenfalls über TineCore Linux, kann Abhilfe schaffen. Eine beispielfhafte Anleitung wäre z.B.

nixCraft – Linux: How to delete a partition with fdisk command

USB-Verlängerung verwenden

Mitunter gibt es mit bestimmten USB-Sticks Schwierigkeiten, sei es so banale Dinge, das diese von der Bauform her nicht in die Buchse passen, da neben dran der Netzteilstecker ist oder das es Timing-Probleme gibt. Helfen kann dabei eine USB-Verlängerung.

Kurz notiert: Wer Askozia-Lizenzen zu 3CX umwandeln möchte, der nutzt ggf. dieses Formular:

https://www.3cx.com/phone-system/pbx-licence/

Leider ist dieses hinsichtlich Sonderzeichen, Umlauten usw. etwas empfindlich. Passiert nach einem Klick auf „Submit & Download“ nichts, so sollte man seine Eingaben prüfen. So darf z.B. kein Leerzeichen im Askozia-Lizenzschlüssel enthalten sein (passiert gerne bei copy&paste). Im Namen sollten zudem keine Umlaute oder Apostroph (‚), Akut (´), Gravis (`) oder ähnliches enthalten sein.

Wir hatten jüngst mit dem Vornamen eines Kunden diese Schwierigkeiten. Mit „André“ geschah nichts, es kommt noch nicht mal eine Fehlermeldung, also kurzerhand zu „Andre“ geändert und alles ist gut.

Am 15. April 2018 erhielt mein Nokia 6 das Update auf Android 8.1.0. Die Aktualisierung lief soweit stressfrei durch und bislang ist nichts negatives aufgefallen.

Einzig das Sicherheitsupdate vom April 2018 vermisse ich noch:

Nokia Smartphone Security Maintenance Release Summary

Android Security Bulletin—April 2018

Für Bedenken sorgt, das in der Mitteilung von Nokia/HMD Global nur die Rede vom Nokia 6.1 (Nokia 6 Refresh von 2018) und nicht vom Nokia 6 (wenn man so möchte 6.0 von 2017) die Rede ist. Mal sehen was da noch kommt.

Bei einem Kunden der Outlook 2007 und 2010 im Einsatz hat streikte von einem auf den anderen Tag auf allen Arbeitsplätzen die Aktualisierung eines gemeinsam genutzten IMAP-Postfachs.

Neue Nachrichten wurden in Outlook schlicht nicht angezeigt, geschweige denn heruntergeladen. Eine Fehlermeldung gab es nicht. Beim Anbieter, 1&1, waren neue Nachrichten via Webmailer zu sehen.

Der erste Verdacht, es könnte an den Konteneinstellungen, der Sende-/Empfangsgruppe oder dem Virenscanner, G Data Internet Security, oder der Firewall liegen bestätigte sich nicht. Ein Test mittels telnet und ein Abruf mittels Thunderbird und KomaMail klappte ohne Schwierigkeiten. Selbst mit deaktivierten Addons und im abgesicherten Modus aktualisierte Outlook den Posteingang nicht. POP3-Konten waren wiederum kein Problem.

Letztlich half nur, das bzw. die IMAP-Konten aus Outlook zu entfernen und neu anzulegen.

Der Gedanke ist naheliegend, das es mit den Office-Updates vom April 2018 zusammenhängen könnte.

Microsoft Office Updates

Microsoft Support – April 2018 updates for Microsoft Office

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

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

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

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

• Configuration – Fan Mode (Default: Optimal Speed)

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

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

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

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

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

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

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

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

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

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

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

14:56:06,44

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

Quellen:

Any Source – Lüftersteuerung für Supermicro IPMI

STH – Supermicro X9/X10/X11 Fan Speed Control

Thomas Krenn – Wiki – IPMI Konfiguration unter Linux mittels ipmitool

Thomas Krenn – Wiki – Ipmitool zur Remotesteuerung von Servern nutzen