Quasi als Fortsetzungsartikel zu Wie eine Securepoint UTM RC100 stirbt und man sie wiederbelebt folgt nun die Variante mit einer pfSense auf einem APU-Board von PC Engines. Im Grunde kann man die Diagnose auch auf andere Hardware anwenden.

Bei einem Kunden streikte die Standort-Vernetzung auf Basis von OpenVPN. Vor Ort auf der Client-Seite war schnell klar, das die pfSense nicht mehr ansprechbar war. Zunächst wurde über eine serielle Verbindung (da das APU-Board kein VGA o.ä. hat) überprüft, ob es eine aktuelle Ausgabe gibt. Allerdings reagierte das Gerät überhaupt nicht auf irgendwelche Eingaben, eine Ausgabe gab es in Folge nicht.

Bei einem Neustart wurde beobachtet, wie weit pfSense bootet. Das sah zunächst recht vielversprechend aus. Zunächst erschienen die Meldungen von Coreboot (BIOS), dann der Bootloader und das System startete über die Hardware-Enumierung soweit flott und gut. Dann erschien allerdings folgendes:

WARNING: / was not properly dismounted
WARNING: /: mount pending error: blocks 16 files 0

Danach ein Crash-Report usw.:

Kurzum: Nicht gut und ein Hinweis, das mindestens das Dateisystem fehlerhaft ist. Um dies weiter zu prüfen wurde das Gerät neugestartet.

Beim Bootmenü wurde „2“ gedrückt für „2. Boot [S]ingle User“ um in den Single User Mode zu starten.

Bei der Abfrage nach der Shell schlicht „Enter“ drücken.

Nun kann man das Dateisystem überprüfen:

fsck -f

Tipp: „-y“ anhängen um Meldungen automatisch bestätigen zu lassen.

Die Ausgabe verhies ein weiteres Mal nichts gutes:

** /dev/gptid/51b43281-0cc3-11e8-802f-000db9338214
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=1605142 (8 should be 0)
CORRECT? [yn]

INCORRECT BLOCK COUNT I=1605143 (8 should be 0)
CORRECT? [yn] y

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts

ahcich0: Timeout on slot 6 port 0
ahcich0: is 00000000 cs 00000000 ss 00000040 rs 00000040 tfd 50 serr 00000000 cmd 0000e617
(ada0:ahcich0:0:0:0): READ_FPDMA_QUEUED. ACB: 60 40 28 a2 4c 40 01 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Command timeout
(ada0:ahcich0:0:0:0): Retrying command
ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)

ahcich0: Timeout on slot 7 port 0
ahcich0: is 00000000 cs 00000080 ss 00000000 rs 00000080 tfd 80 serr 00000000 cmd 0000e717
(aprobe0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich0:0:0:0): CAM status: Command timeout
(aprobe0:ahcich0:0:0:0): Retrying command
ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich0: Timeout on slot 8 port 0
ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd 80 serr 00000000 cmd 0000e817
(aprobe0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich0:0:0:0): CAM status: Command timeout
(aprobe0:ahcich0:0:0:0): Error 5, Retries exhausted
ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080)

Mit den Timeouts ging es dann weiter. Fazit: Die SSD ist defekt. Bei diesem älteren Gerät handelt es sich um eine SuperSSpeed S328 aus dem damaligen PC Engines APU-Bundle. Laut Recherche sind wohl Schwierigkeiten mit neueren Dateisystemen und TRIM bekannt:

Notizbl0g. – SuperSpeed S328 SSD and TRIM Feature

PC Engines – 16GB mSATA SSD module (msata16a)

Wobei man dazu erwähnen muss, das pfSense ab Werk kein aktiviertes TRIM hat. Dieses muss manuell eingeschaltet werden:

Enable TRIM on pfsense 2.2.4

YUK Blog – pfsense SSD Harddisk Enable TRIM

Dies war übrigens hier nicht der Fall. Vermutlich ist die SSD ihres Alters wegen „gestorben“. Jedenfalls kann die SSD mit dem aktuellen Modell von PC Engines ersetzt werden:

PC Engines – 16GB mSATA SSD module (msata16e oder neuer)

Dieses gibt es beispielsweise bei VARIA:

VARIA – PC Engines mSATA16G – 16 GB mSATA SSD Module

Alternativ kann neben der PC Engines Eigenmarke z.B. auch Transcend verwendet werden (von mir bislang ungetestet):

VARIA – 16GB Transcend mSATA-SATA, SSD MLC, TS16GMSA370

Ist die Hardware wieder in Ordnung, muss pfSense neuinstalliert werden:

• Das System starten.
• „F10“ für’s Bootmenü drücken
• Das Boot-Medium auswählen, in diesem Fall die „1“ für „1. USB MSC Drive Multiple Card Reader 1.00“
• Bei „Console type“ die Eingabetaste drücken und den Anweisungen folgen (Quasi immer nur „Enter“ drücken), auf diese Weise wird pfSense mit den Standard-Einstellungen installiert.
• Vor dem Neustart die SDCARD entfernen.

Nach dem Neustart kann das System bis zu einem gewissen Grad an der Konsole konfiguriert werden, wie z.B. zuweisen der Netzwerkschnittstellen, IP-Adresse, …

Über „1) Assign Interfaces“ mindestens die WAN- (i.d.R. „re0“ bzw. „igb0“) und LAN-Schnittstelle (i.d.R. „re1“ bzw. „igb1“) zuweisen. Dieser Schritt ist relevant, auch wenn bereits „re0“ und „re1“ angezeigt wird, andernfalls ist keine Kommunikation möglich! Erfahrungsgemäss klappts allerdings bei neueren Boards mit Intel-Netzwerkchips automatisch, so das dieser Schritt übersprungen werden kann.

Mindestens sollte die IP-Adresse und ggf. der DHCP-Server für die LAN-Schnittstelle unter „2) Set interface(s) IP address“ eingestellt werden.

Nun kann man direkt via Netzwerk im Browser unter Angabe der voreingestellten IP-Adresse 192.168.1.1 (oder welche man selbst vergeben hat) und den Zugangsdaten

Benutzername: admin
Kennwort: pfsense

den Ersteinrichtungsassistenten durchlaufen. Die LAN-Schnittstelle ist die Mittlere von den Dreien, sofern man nichts anderes konfiguriert hat. WAN ist per Vorgabe die erste Schnittstelle neben dem COM-Port.

Bevor es dann weiter geht, sollte zunächst, sofern vorhanden, das aktuelle Update installiert werden. Anschließend kann man die Datensicherung einspielen und ist wieder auf dem aktuellen Stand.

Beim Kunden haben wir kurzerhand ein Leihgerät aufgestellt und die Datensicherung eingespielt, so war man innerhalb weniger Minuten fertig und das VPN lief wieder. Die Reparatur konnte so in Ruhe in der Werkstatt erfolgen und nebenbei dieser Beitrag verfassst werden.

Quelle:

OpenBSD – Manual Page – fsck

Bei einem Kunden haben wir aktuell die Situation das es zwei Internetzugänge jeweils mit eigenem Router gibt. Folglich gibt es zwei Gateways die man ansprechen kann, um ins Internet zu gelangen.

Damit zuerst der schnellere Zugang verwendet wird, kann man bei der manuellen Konfiguration der Gateways unter Windows die Metrik einstellen. Dabei gilt: Je niedriger der Wert, desto besser. Z.B.

192.168.19.2 - Metrik 10
192.168.19.4 - Metrik 20

Das Gateway mit dem niedrigeren Wert bei der Metrik wird zuerst angesprochen.

Welches Gateway verwendet wird, kann man mittels tracert prüfen:

tracert andysblog.de

Routenverfolgung zu andyblog.de [81.169.145.151] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms 192.168.19.4
2 21 ms 21 ms 20 ms 62.155.246.79
3 21 ms 21 ms 21 ms f-ed3-i.f.de.net.dtag.de [62.154.14.202]
4 21 ms 20 ms 21 ms xe-1-3-1.atuin.as6724.net [87.128.237.230]
5 24 ms 24 ms 29 ms vl481.fiddlersriddle.as6724.net [81.169.144.121]

6 24 ms 23 ms 23 ms w97.rzone.de [81.169.145.151]

Werden die IP-Adressen mittels DHCP verteilt, so hat man keine Möglichkeit, die Metrik vorzugeben. Wird erstmal nur mehrere Gateways (Router) verteilt, so nimmt Windows das Gateway, welches es für das Beste hält oder in der Reihenfolge zuerst erscheint. Im konkreten Kundenszenario war das aber immer der Router vom langsameren Anschluss. Erst nachdem die Option „003 Microsoft-Standard-Routerbasismetrik“ zusätzlich verteilt wurde, passte es:

Quellen:

serverfault.com – Windows 7 does not respect the prefered router order from DHCP

MS TechNet – The Cable Guy – September 2003 – Default Gateway Behavior for Windows TCP/IP

Die Sache mit den Netzwerkkategorien sorgen unter Windows gerne mal für Überraschungen. So auch bei einem stand-alone Hyper-V-Server auf dem zwei Gateways (Router) mit unterschiedlicher Metrik eingerichtet wurden.

Windows war nachdem das zweite Gateway eingetragen wurde der Meinung in einem öffentlichem Netzwerk zu sein:

PS C:\Users\Administrator> get-netconnectionprofile

Name : Netzwerk 3
InterfaceAlias : vEthernet (Virtual Switch 1)
InterfaceIndex : 18
NetworkCategory : Private
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork

Name : Netzwerk 4
InterfaceAlias : vEthernet (Virtual Switch 1)
InterfaceIndex : 18
NetworkCategory : Public
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork

Eigentlich kein größeres Problem, kann man dies in der Powershell mittels

set-netconnectionprofil -InterfaceIndex <NR> -NetworkCategory Private

regeln. Dem ist aber nicht so, wenn es sich um das selbe Interface handelt bzw. mehrere Gateways konfiguriert sind. Alle Versuche mit obigen Befehl als auch mit z.B.

set-netconnectionprofil -InterfaceAlias <Schnittstellenname> -NetworkCategory Private

oder

set-netconnectionprofil -Name <Netzwerkname> -NetworkCategory Private

oder einer Kombi aus beiden Herr der Lage zu werden, scheiterten. Die Befehle wurden ohne Fehlermeldung ausgeführt, aber die Kategorie änderte sich nicht.

Erst als man das alte Gateway entfernte, so das nur noch das Neue vorhanden war, führte dazu, das sich die Netzwerkkategorie ändern lies. Anschließend wurde das alte Gateway wieder hinzugefügt und so waren beide dann „Privates Netzwerk“:

PS C:\Users\Administrator> get-netconnectionprofile

Name : Netzwerk 3
InterfaceAlias : vEthernet (Virtual Switch 1)
InterfaceIndex : 18
NetworkCategory : Private
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork

Name : Netzwerk 4
InterfaceAlias : vEthernet (Virtual Switch 1)
InterfaceIndex : 18
NetworkCategory : Private
IPv4Connectivity : Internet
IPv6Connectivity : LocalNetwork

Wenn man so möchte als Ergänzungsbeitrag zu MS SQL Server 2014 Express auf einem Domänencontroller installieren folgt nun eine Kurzanleitung, wie man unter Windows Server 2012 R2 ein Group Managed Service Account (gMSA) für Dienste einrichtet.

Als Beispiel dient ein Microsoft SQL Server 2014 Express, der für SFIRM V4 verwendet werden soll und auf einem Domänencontroller installiert ist, bei dem nachträglich vom Systemkonto auf ein gMSA gewechselt werden soll.

Alle nachfolgenden Befehle werden auf dem Server in einer PowerShell-Eingabeaufforderung mit erhöhten Rechten ausgeführt.

KdsRootKey anlegen

Zunächst prüfen, ob es bereits einen Key Distribution Services Root Key (KdsRootKey) existiert:

Get-KdsRootKey

Falls nicht, diesen Anlegen:

Add-KdsRootKey –EffectiveImmediately

In der Vorgabe muss man allerdings 10 Stunden warten, bevor man weiter arbeiten kann. Hintergrund ist, sofern vorhanden, das die Replikation zwischen allen Domänencontrollern abgewartet werden muss. Umgehen kann man dies mit diesem Befehl:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Dadurch wird der Schlüssel zehn Stunden in der Vergangenheit angelegt. Bei einem einzelnen oder wenigen Domänencontroller(n) geht das in Ordnung.

gMSA erstellen

New-ADServiceAccount <Kontoname> -DNSHostName <FQDN-des-Servers-auf-dem-der-Dienst-läuft> -PrincipalsAllowedToRetrieveManagedPassword "Gruppe"

Beispiel:

New-ADServiceAccount SFIRMV4 -DNSHostName testdc01.testdom01.local -PrincipalsAllowedToRetrieveManagedPassword "Domänencontroller"

Per Vorgabe werden gMSA im Active Directory unter „Managed Service Accounts“ angelegt. Dort sollte man nun das Konto sehen können:

Dienstkonto dem Server zuweisen

Install-AdServiceAccount <Kontoname>

gMSA prüfen

Test-AdServiceAccount <Kontoname>

Dienstkonto des SQL Servers ändern

• Den „SQL-Server-Konfigurationsmanager“ starten.
• Zu „SQL-Server-Dienste“ wechseln.
• Die betreffende Instanz doppelt anklicken.
• Auf der Registerkarte „Anmelden“ „Dieses Konto:“ und „Durchsuchen“ anklicken.
• Auf „Objekttypen“ klicken, alles abwählen und „Dienstkonten“ aktivieren.
• Entweder den Kontoname eingeben oder auf „Erweitert“ klicken und das Konto auswählen.
• Auf „OK“ klicken.

Damit die Änderung übernommen wird, muss der Dienst neu gestartet werden. Dies als auch weitere notwendige Anpassungen (Registry, Rechte im Dateisystem, …), übernimmt der Konfigurationsassistent von selbst.

Quellen:

MS Docs – Create the Key Distribution Services KDS Root Key

MS Docs – Getting Started with Group Managed Service Accounts

Wydler – Group Managed Service Accounts

Active Direcotry FAQ – Group Managed Service Accounts

Auf unserer 3CX fiel auf, das ein Teilnehmer seit angeblich neun Tagen ein Gespräch führt. Tatsächlich gab es mal ein Gespräch, dieses wurde allerdings aufgrund eines unbekannten Fehlers unterbrochen. Offenbar hing es seitdem undefiniert fest. Tatsächlich wurde allerdings kein Gespräch mehr geführt.

Idealerweise kann man Gespräche in der Verwaltungsoberfläche (System Management Console) unter „Anzahl aktiver Gespräche“ durch ein Klick auf das „x“ beenden. In diesem Fall half das allerdings nicht. Nach kurzem Kontakt mit dem Support hies es, man solle die 3CX Dienste neustarten.

Wir haben nun lediglich den Dienst „3CX PhoneSystem 01 SIP Server“ neugestartet, abhängige Dienste werden automatisch ebenfalls neugestartet, und siehe da, das „Phantom“-Gespräch war verschwunden.

Kurz notiert: Ein seltener Kunde kam mit Notebook vorbei, auf diesem läuft noch Windows XP. Er wollte eine einfache Datensicherung haben, hauptsächlich für die Eigenen Dateien und eine weitere Partition mit reichlich Nutzdaten (Bilder, Office-Dateien, …).

Freilich hätte man auf die Windows-Datensicherung (ntbackup) oder Drive Snapshot setzen können. Ersteres birgt das Risiko in die Sicherung, wenn’s dann doch mal einen neuen Computer gibt, nicht mehr so ohne weiteres reinschauen zu können, letzteres kostet Geld, auch wenn’s nur 39,00 € für die Arbeitsplatz-Lizenz sind (ja ja, Geiz ist geil, ne).

Kurzum wurde zu Personal Backup gegriffen. Diese nette Freeware bietet sowohl für Einsteiger als auch Fortgeschrittene mehr als genug Möglichkeiten. Für diese Aufgabe war unter anderem relevant, eine Verknüpfung auf den Desktop erstellen zu können, um die Datensicherung manuell zu starten.

Viele greifen bei Thema „Texte in andere Sprachen übersetzen“ zu Google Translate. Wer Google vermeiden oder mitunter bessere Ergebnisse erzielen möchte kann z.B. auf die Online-Übersetzung vom PROMT zurückgreifen.

Diese steht unter http://www.online-translator.com/ zur Verfügung.

Wer überhaupt nicht seine Texte ins Internet oder in einen Browser (ein)geben möchte, kann auf die installierbaren Übersetzungslösungen vom gleichen Hersteller zurückgreifen. Diese gibt es für einzelne Computer, Android und iOS als auch als Netzwerk- bzw. Unternehmenslösung. Diese sind zwar nicht ganz günstig, aber dem Hörensagen nach (laut Kunde) sehr gut.

Seit dem Microsoft Patchday vom März 2018 (13.03.2018), genauer ausgedrückt ab der Installation von „2018-03 – Monatliches Sicherheitsqualitätsrollup für Windows Server 2012 R2 für x64-basierte System (KB4088876)“ unter Windows Server 2012 R2 Standard funktioniert der RDP Wrapper nicht mehr. Allen voran fällt dies auf, das sich nur zwei Benutzer via Remotedesktopverbindung anmelden können. Startet man „RDPConf.exe“ fällt beim „Listener“ ein „not supported“ auf:

Abhilfe schafft ein Downgrade der „termsrv.dll“ unter „C:\Windows\System32“ auf die vorige Version. Diese kann man beispielsweise aus den Schattenkopien oder einer Datensicherung kopieren.

Damit man die Datei umbenennen oder überschreiben kann, muss man zunächst den Besitzt übernehmen und der Benutzergruppe „Administratoren“ Vollzugriff gewähren.

Nachdem die vorige Version der „termsrv.dll“ eingespielt wurde, einmal den Dienst „Remotedesktopdienste“ neustarten.

Nun sollten wieder mehr als zwei RDP-Verbindungen möglich sein und „RDPConfig.exe“ zeigt beim „Listener“ wieder „fully supported“ an:

In wie fern es andere bzw. weitere Windows-Editionen und – Editionen betrifft kann ich nicht sagen.

Wahrscheinlich wird es in absehbarer Zeit eine neue *.ini-Datei für den RDP Wrapper geben, die dann die neue Version der „termsrv.dll“ unterstützt.

Quelle:

RDP Wrapper – GitHub – Add support for termsrv 6.3.9600.18928 #418

Während der Fehlersuche auf einem Kunden-PC mit Windows 7 stach einem ins Auge, das die CPU-Last durch „svhost.exe“ und „TrustestInstaller.exe“ durchaus hoch sein kann.

Bei einem Blick in „C:\Windows\Logs\CBS\CBS.log“ fanden sich quasi in Endlosschleife und selbst nach Stunden oder Tagen Dauerbetrieb mit jeweils anderen Session-Nummern Einträge dieser Art:

2018-03-18 13:20:26, Info CBS Session: 30654131_2137014950 initialized by client WindowsUpdateAgent.
2018-03-18 13:20:26, Info CBS Failed to internally open package. [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE]

„sfc /scannow“ fand ein paar Fehler und konnte diese beheben. CheckSUR (System Update Readiness Tool) fand wiederrum keine Fehler:

C:\Windows\Logs\CBS\CheckSUR.log

=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2018-03-17 12:44

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Summary:
Seconds executed: 371
 No errors detected

Selbst ein Zurücksetzen der Windows Updates (Dienste anhalten, „C:\Windows\SoftwareDistribution“ löschen, …) half nichts.

Das kuriose dabei ist, Windows Updates lassen sich erfolgreich und ohne Probleme installieren. Laut WSUS, es handelt sich um einen Firmen-PC, sind alle Updates erfolgreich installiert. Anwendungen laufen ebenfalls ohne Auffälligkeiten.

Im Moment und nach langer Recherche und Tests ist man ratlos, was man noch tun könnte. Bei vergangenen Fällen dieser Art half meist die Kombi aus sfc uind CheckSUR. Diesmal, so scheint es, bleibt wohl nur die Neuinstallation.

Bislang war ich mit der werkseigenen Bildschirmtastatur von Android zufrieden, aber mit dem letzten Update vor 1-2 Tagen änderte sich dies.

Nach dem Update nervte in Endlosschleife die Benachrichtigung von Gboard das man die Google-Dienste aktualisierren sollte. Da ich keine Google-Dienste nutze bzw. kein Google-Konto habe war das keine Option. Abhilfe kann schaffen, das Update wieder zu Deinstallieren und die werksseitige Version weiter zu verwenden. Damit war auf jeden Fall schonmal Ruhe mit dem „Benachrichtigungs-Terror“. Plan B bzw. Alternativ kann man andere Tastaturen verwenden.

Nach ein wenig Lesen im Netz wurde dann die SwiftKey Tastatur installiert:

Was soll man sagen: Es läuft. Gut kommt die Anpassbarkeit (Größe, Themes) aber vorallem die Einstellungsmöglichkeiten. So kommt mir gelegen, das man Nummernleiste und Pfeiltasten anzeigen lassen kann (nicht im Screenshot). Die App hat aber noch mehr zu bieten.

Quellen:

Google PlayStore – SwiftKey Tastatur

GIGA-Redaktion: Unsere 5 besten Android-Tastaturen

t3n – Android-Tastaturen: Die 5 besten alternativen Keyboards

PC Magazin – Top 5 Android-Tastaturen im Überblick

Vermutlich seit dem Update auf Android 8 bei meinem Nokia 6 funktioniert der Fingerabdruck bei KeepassDroid nicht mehr. Aufgefallen ist das erst jetzt, da der Passwort-Manager nur selten auf dem Smartphone verwendet wird.

Es erscheint immer nur die Meldung „fingerprint error“. Als Alternative kommt nun Keepass2Android zum Einsatz. Die Datenbank kann weiterverwendet werden. Witzigerweise war es vor zwei-drei Monaten noch anders herum gewesen.

Auf dem Windows 7-PC von einem Neukunden zeigten die Dialoge von Avira (Übersicht, Einstellungen, Deinstallieren, …) nur leere weißen Seiten, die aktuelle Java-Version lies sich nicht installieren (nach der Benutzerkontenabfrage erschien kein Fenster mehr) und die aktuelle ELSTER-Version lies sich ebenfalls nicht installieren.

Festplatte, Dateisystem und Windows waren soweit in Ordnung. Glücklicherweise lieferte das ELSTER-Setup eine Fehlermeldung mit dem Verweis darauf das kein Zugriff auf VBScript möglich sei. Diese Meldung und das Verhalten des Java-Setups führten zu von einander unabhängigen Treffern mittels Suchmaschine, die beide als gemeinsame Lösung hatten, das Installationsreste von McAfee entfernt werden mussten.

Auf dem PC, ein Gerät von Acer, war vermutlich ab Werk mal eine Trialversion von McAfee installiert. Spontan konnten zwar keine Desktopsymbole, Startmenüeinträge oder Ordner unter „C:\Program Files“ ausgemacht werden, dennoch führte eine Runde mit dem

McAfee Consumer Product Removal-Tools (MCPR)

zum Erfolg. Danach lief der PC sogar gefühlt schneller.

Manchmal geschehen Dinge, die man so nicht wollte: Durch einen doppelten Tippfehler hatte ich mich auf einem SuperMicro-Server vom SuperDoctor ausgesperrt. Eigentlich sollte nur das Kennwort geändert werden.

Im Handbuch und bei einer schnellen Suche im Netz fands ich leider keine Reset-Funktion für das Kennwort oder ich hab’s übersehen. Die Schattenkopien waren auf dem System nicht aktiviert und eine Datensicherung gab’s auch nicht (da nur Hyper-V Host). Lediglich zum Ändern des Keystore-Passworts der JVM oder was auch immer da genau läuft ist etwas in der Doku zu finden.

Jedenfalls kurz in den Ordner vom SuperDoctor geschaut, findet sich in verschlüsselter oder gehashter Form das ADMIN-Kennwort in der Datei

C:\Program Files\Supermicro\SuperDoctor5\config\agentweb.properties

#Sat Mar 24 08:16:17 CET 2018
contextPath=/SuperDoctor5
port=8181
enableHttp=true
keystorePassword=<keystore-password>
username=ADMIN
webcontentPath=plugins/builtin/web/WebContent
enableHttps=true
keystore=certificates/.keystore
healthInfo.interval=10
showAdminLogin=false
password=<admin-password>
enableTray=true
sslPort=8444

Also bei „password“ (rot markiert) steht das ADMIN-Kennwort. Leer lassen oder 123… reinschreiben hilft nichts. Damit Änderungen übernommen werden, muss immer der Dienst „SuperDoctor 5“ (Dienstname: „sd5“) neu gestartet werden.

Die Lösung bestand nun schlicht darin, den Wert von einer anderen SuperDoctor-Konfiguration, von der man das Kennwort kennt, zu kopieren, einzufügen, zu speichern und wie erwähnt einmal den Dienst neu zu starten.

Die vergangenen Tage war an ein Arbeiten mit meinem Lenovo ThinkPad T410 kaum noch zu denken. Ständig wurden die RemoteApps getrennt und der lokale Browser kam nicht in die Gänge.

Zunächst fiel der Verdacht auf die Netzwerkverbindung, da es in Verbindung mit der Dockingstation immer mal wieder Konnektivitätsschwierigkeiten gab. Zwar zeigte sich beim Dauerping immer wieder Ausreißer mit hohen Latenzen oder wenn man das Notebook mal verschoben hat komplette Ausfälle, das alleine war es allerdings noch nicht.

Da ich meist einiges lokal wie remote an Anwendungen offen habe und in Sachen Browser wohl als Heavy-User bezeichnet werden kann, war es erstmal kein Wunder, das der Arbeitsspeicher gut voll ist. Heute früh allerdings war dann das Maß voll und es wurde alles erstmal geschlossen. Allerdings beeindruckte das die Arbeitsspeicherauslastung herzlich wenig. Immer noch gut 97% der 8GB belegt. Ok, „ein Boot tut gut“ sagt man so schön, also einmal neugestartet. Das half allerdings wenig. Direkt nach dem Neustart und der Anmeldung, ohne das eine Anwendung geöffnet ist, waren bereits über 5GB belegt.

Abhilfe schaffte dann, nochmal die Einstellungen zur Auslagerung zu bestätigen und neu zu starten:

Geändert wurde dabei nichts, aber offenbar reichte dies aus, um etwas zu bewirken. Letztlich scheint es so gewesen zu sein, das Windows vermutlich gemeint hat, nichts mehr in die Auslagerungsdatei packen und den Speicher freigeben zu wollen.

Eigentlich wird der Canon Pixma MX860 seitens des Herstellers nicht mehr unter Windows 10 unterstützt. Bei Windows 8.1 war Schluss mit Treiber und Software. Dennoch bekommt man diesen, zumindest was Drucken und Scannen betrifft, zum Laufen.

Von der Produkthomepage die aktuelle Version der Treiber und Software für Windows 8.1 herunterladen. Es wird mindestens der Druckertreiber und der MP Navigator EX benötigt. Beides wie gewohnt installieren. Drucken kann man damit allerdings noch nicht.

Damit letztlich gedruckt werden kann, muss allerdings unter „Windows 10 – Einstellungen – Drucker“ das Gerät nochmals hinzugefügt werden. Dabei kommen offensichtlich Treiber von Microsoft (Windows Update/Microsoft Catalog) zum Einsatz, die wiederum unter Windows 10 funktionieren. Den zuvor durch das Canon-Setup angelegten Drucker kann man entfernen, da dieser sowieso nicht funktioniert.

Weitere Software und die PC-to-Fax-Funktion wurde nicht getestet.

Auf dem neuen Windows 10-PC eines Kunden funktioniert das Senden an E-Mail-Empfänger nicht. Windows meckerte, das eine ältere Version von Outlook läuft, obwohl nur eine vorhanden ist.

Der Kunde verwendet nach wie vor MS Office 2010 und aus diesem Packet das entsprechende Outlook 2010. So weit, so gut. Möchte man allerdings eine Datei direkt aus dem Explorer heraus über „Rechtsklick – Senden an – E-Mail-Empfänger“ verschicken, so erscheint folgende Meldung:

Der Task-Manager findet sogar ein vermeintliches Outlook 2016:

Witzigerweise ist kein anderes Office oder Outlook installiert. In den Einstellungen ist Outlook 2010 sogar als Standard hinterlegt. Nach etwas „Versuch und Irrtum“ (trial & error) mit verschiedenen potentiellen Lösungen erschien Folgende die beste Variante zu sein:

Unter

C:\Users\%username%\AppData\Roaming\Microsoft\Windows\SendTo

die Original „E-Mail-Empfänger“-Verknüpfung entfernen (z.B. an einen anderen Ort verschieben) oder umbenennen.

Eine neue Verknüpfung zu

"C:\Program Files (x86)\Microsoft Office\Office14\OUTLOOK.EXE" /a

anlegen. Der Einfachheit halber haben wir die Verknüpfung wie das Original benannt, also „E-Mail-Empfänger“. Macht man nun den Rechtsklick und wählt „Senden an – E-Mail-Empfänger“ aus, so sieht man zum einem bereits im Kontextmenü das Outlook-Icon und zum anderen klappt’s dann auch mit der Mail.

Quelle:

Microsoft Community – Senden an/ zum Beispiel aus Word 2010 via Outlook 2010 erst nach öffnen von Outlook (Antwort von Marco Seefeldt vom 16. Mai 2011)

Update 27.03.2018

Leider funktioniert diese Lösung nur bedingt gut. Ist Outlook bereits geöffnet, wird keine neue E-Mail aufgemacht. Ferner klappt das Versenden direkt aus den Office-Anwendungen heraus nicht, es kommt zur gleichen Fehlermeldung.

(Hoffentlich) Finale Abhilfe schaffte nun Office zu deinstallieren, von Microsoft den Office 2016-Uninstaller durchlaufen zu lassen:

Deinstallieren von Office auf einem PC – Option 2 – Vollständiges Deinstallieren von Office 2016 mit dem Tool für einfache Fehlerkorrekturen

Den PC neuzustarten und Office 2010 wieder zu installieren (Updates nicht vergessen!). So funktioniert das Senden an E-Mail-Empfänger (im Originalzustand) aus dem Explorer und auch aus Word, Excel und Co.

Unklar bleibt, wo dieses vermeintliche Outlook 2016 hergekommen ist, da auf dem PC kein Office vorinstalliert war. Ein weiteres Kuriosum ist, das die Windows-Suche ein Office 2016 findet, obwohl keines da ist. Selbst wenn man gezielt nach Office 2010 sucht wird nichts gefunden.

Beim stückweisen Wiederherstellen von Daten aus einem eingehängten Drive Snapshot-Abbild kam es beim Kopieren mittels Robocopy immer wieder zur Fehlermeldung „Unzulässige Funktion“, während es beim Kopieren im Windows-Explorer zu einer Fehlermeldung „Ungültige MSDOS-Operation“ kam.

Direkt nach dem Einhängen des Abbilds klappte das Kopieren, ganz gleich über welchen Weg, ohne Schwierigkeiten. Erst nach einer gewissen Zeit des Leerlaufs und einem erneuten Kopiervorgang kommt es zu den genannten Meldungen. Erst ein aus- und erneutes Einhängen sorgt dafür, das weiter kopiert werden kann.

Das Abbild liegt auf einer USB-Festplatte, der erste Verdacht das es an einer Energiesparfunktion liegt ist dabei naheliegend und sogar zutreffend. Ein Abschalten der Energiesparfunktion am USB-Anschluss über den Geräte-Manager als auch in der Systemsteuerung unter Energieoptionen half leider nichts.

Bei dieser USB-Festplatte, ein Modell von Samsung, scheint es eine interne Energiesparfunktion zu geben, die man nicht beinflussen kann.

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