In der Ausgabe 16/2018 der c’t findet sich der Artikel Rasende Robbe –
Mit X2Go grafische Linux-Anwendungen aus der Ferne nutzen. Ich nahm diesen zum Anlass meine Tests aus der Vergangenheit zu wiederholen.

Für den Versuch wurde unter Hyper-V auf Basis von Windows Server 2012 R2 Standard auf einem Fujitsu Primergy TX150 S7 (Intel Xeon X3430, 32GB RAM) ein neuer virtueller Computer mit zwei vCPUs und 4 GB RAM erstellt und frisch Debian 9.5 Stretch installiert.

Firefox etwas pimpen

Wie man im genannten Artikel oder unter

Mozilla Bugzilla – Firefox 40+ are very sluggish through x2go

lesen kann, hilft eine kleine Konfigurationsänderung, die Lage bei Remote-Nutzung etwas zu bessern:

• Firefox starten
• about:config in die Adresszeile eingeben
• gfx.xrender.enabled von „false“ auf „true“ ändern
• Den Browser neu starten

X2Go

Wie im c’t-Artikel beschrieben, bringt die Änderung im Firefox tatsächlich etwas, Wunder darf man allerdings keine erwarten. Grundsätzlich scheint es mir zudem eine gute Idee zu sein, nicht die ESR- sondern die aktuelle Stable-Ausgabe des Browsers zu verwenden.

Etwas mehr bringt dann die Alternative Pale Moon, ein ehemaliger Firefox-Fork, der mittlerweile eher eigenständig ist.

Getestet wurde übrigens die Wiedergabe eines YouTube-Videos.

Xpra

Bei Xpra konnte ich irgendwie keine Verbesserung, eher eine Verschlechterung feststellen. Allerdings schien mir beim ersten Test vor einiger Zeit, das diese Art der Fernnutzung besser auf realer statt virtueller Hardware funktioniert. Das mag allerdings von der genutzen Anwendungen abhängig sein.

Fazit

Ja, es bringt etwas, aber vielleicht habe ich einfach zuviel erwartet. Auf nativer Hardware, also nicht virtualisiert, klappts ein bischen besser. Nungut, Browser und auch noch gleich VIdeo-Wiedergabe geht schon recht in die Vollen.

Leider muss man, zumindest in dieser Testumgebung, zugeben das es mit Windows und RDP besser klappt. Da ruckelt es zwar auch ein wenig, ist aber um Längen besser.

Wenn mehrere Systeme (PCs, Server, …) auf eine USB-Festplatte die im Netzwerk freigeben ist gleichzeitig sichern wollen, kann es je nach Performance zu diversen Schwierigkeiten kommen.

Ein Punkt wäre dabei die Geschwindigkeit, die schlicht in den Keller geht, bei längeren Zugriffen kommt es auch gerne zu Timeouts und damit zu Verbindungsabbrüchen.

Am Beispiel von Drive Snapshot heisst es dann mitunter, dass das Ziel oder das Hashfile (wenn es denn auf der USB-Festplatte liegt) nicht gefunden werden konnte, oder weitere netzwerkbezogene Meldungen.

Stein des Anstoßes für diese Zeilen ist eine Kunden-Situation, bei der während der Server-Migration nach wie vor auf eine USB-Festplatte die mittels USB 2.0 angebunden ist gesichert wird. Zwei Server schaffen es noch nahezu gleichzeitig (Startzeitpunkt um eine Stunde verschoben) zu sichern, beim Dritten war dann Schluss.

Als workaround kann man die Startzeitpunkte weiter auseinderlegen, in der Regel hilft das bei der Vollsicherung die mehrere Stunden dauert dann eher wenig. Es kommt schlichtweg auf die Situation an.

Drive Snapshot-spezifisch kann man über „–LimitIORate“ eine Limitierung der Geschwindigkeit vorgeben, das hilft allerdings erfahrungsgemäss nicht immer. Auch hier kommt es einfach darauf an.

Eine weitere Idee kann sein, die Sicherungen nicht pro Server mittels jeweiliger Aufgabe laufen zu lassen, sondern zentral von einem Server aus der Reihe nach mittels psexec anzustarten. Das hätte den Vorteil, das die Last vertretbar ist, die Sicherungen der Reihe nach laufen und dazwischen ggf. keine Überschneidung oder unnötiger Leerlauf liegt.

Kann oder möchte man nicht direkt etwas ändern, da z.B. der Wochentag mit in die Sicherung einbezogen ist, kann ein Trick darin bestehen, innerhalb der Skripts eine Pause bzw. Verzögerung zu setzen.

Beim Kunden ist es so, das die Fehlersituation nur bei der Vollsicherung eintritt, daher wurde schlicht im Backup-Skript eine sechs stündige Pause für den dritten Server „eingebaut“:

timeout /t 21600 /nobreak

Diese Zeile wurde direkt vor dem snapshot-Befehl eingefügt.

Zu beachten gilt, wenn für das Backup Dienste beendet werden, das diese bei Zeiten wieder laufen sollten.

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

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

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

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

Vorbereitung

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

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

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

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

Die Migration ansich

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

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

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

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

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

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

Kerio Connect deinstallieren

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

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

C:\Program Files\Kerio

Diese kann man ebenfalls nochmal sichern und dann entfernen.

MDaemon umziehen

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

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

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

Clients anpassen

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

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

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

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

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

%LocalAppData%\Kerio

Nacharbeiten

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

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

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

Abschlussbemerkung

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

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

Beim Versuch die aktuellen Windows Updates auf einem Windows 8.1-Computer zu installieren, kam es beim KB4343989 immer zum Fehler 0x800F0922.

Die üblichen Verdächtigen wie „chkdsk“, „sfc /scannow“ als auch „Dism /Online /Cleanup-Image /ScanHealth“, „Dism /Online /Cleanup-Image /CheckHealth“ und „Dism /Online /Cleanup-Image /RestoreHealth“ fanden zwar alles etwas und konnten es reparieren, aber leider war das noch nicht alles.

Für den genannten Fehler kann es mehrere Gründe geben, wie man z.B. hier nachlesen kann:

Borns IT- und Windows-Blog – Windows 10: Update-Fehler 0x800f0922

Der entscheidende Hinweis kommt zum Schluss des Beitrags:

"Ungenügender Speicher bei Windows 10
Als Ergänzung bin ich in diesem Beitrag noch auf den Hinweis gestoßen,
dass laut Microsoft ungenügende freie Speicherkapazität auf der Partition
“System Reserviert” die Ursache für den Fehlercode 0x800F0922 sein kann
(siehe auch obiger Text)."

Also fix der Partition einen Laufwerskbuchstaben verpasst und mal drauf geschaut. Die Partition war so gut wie voll. Eigentlich sollten um die 74MB im Vergleich zu einem anderen System frei sein, dem war nicht so.

Mit WizTree wurde die Belegung mit einem anderen, erfolgreich gepatchten Windows 8.1 verglichen, dabei fiel eine Datei auf:

Die „iobw.tst“ wird beim Testen mit Iometer angelegt. Scheinbar wurde ein Tag zuvor ein Test durchgeführt und vmtl. abgebrochen, daher dieser Rest. Die Datei entfernt, den Laufwerksbuchstaben entfernt, zur Sicherheit einmal durchgestartet und Windows Updates wiederholt.

Praktisch als Ergänzung zum Beitrag VMware Workstation Player: Zeit-Synchronisation deaktivieren, diesmal allerdings für VirtualBox, eine Anleitung zum Deaktivieren des Abgleichs von Datum und Uhrzeit.

Im Gegensatz zu VMware genügt zum Deaktivieren der Zeit-Synchronisation ein Befehl:

VBoxManage setextradata "VM name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1

Die virtuelle Maschine sollte selbstverständlich zum Zeitpunkt des Ausführens des Befehls beendet sein. Idealerweise sollte VirtualBox ebenfalls geschlossen sein, andernfalls kann es vorkommen, das die Änderung nicht übernommen wird.

Beim Starten der virtuellen Maschine wird die aktuelle Uhrzeit vom Host übernommen. Stellt man nun in der virtuellen Maschine ein anderes Datum bzw. eine andere Uhrzeit ein, so läuft diese dann weiter bis zum nächsten Neustart.

Nicht übersehen darf man die Zeit-Synchronisation die innerhalb der virtuellen Maschine seitens des dort installierten Betriebssystems stattfindet. Bei Windows und Linux beispielsweise der Abgleich via NTP über das Internet.

Möchte man bereits ab dem Startvorgang der virtuellen Maschine einanderes Datum mitgeben, so muss dies vorab über den Befehl

VBoxManage modifyvm "VM name" --biossystemtimeoffset <ms>

realisiert werden. Das setzt voraus, das man die Differenz in Millisekunden kennt. Wie man diese Zeit ermitteln kann, wird in diesem Beitrag erläutert:

Winaero – How to set the BIOS date in VirtualBox

Wichtig zu wissen ist, das der Offset fest in die Konfigurationsdatei der virtuellen Maschine eingetragen wird, d.h. es wird dann immer mit diesem Wert gestartet, der (natürlich) dann nicht mehr zum gewünschten Zeitpunkt passt und praktisch jedesmal vor dem Start aktualisiert werden muss.

Als Batch-Skript für Windows sieht das Ganze, gemeint ist Sync deaktivieren, Differenz ermitteln und VM starten, so aus:

@echo off

rem Konfiguration

 set VMname=Debian
 set VMdate=08/01/2018

 set VBoxPath=C:\Program Files\Oracle\VirtualBox

rem Zeit-Differenz von heute bis zum definierten Zeitpunkt ermitteln

 powershell ([datetime]'%VMdate%' - [datetime]::Now) | find "TotalMilliseconds :" > temp.txt

 set /p MS=< temp.txt
 del temp.txt /q

 rem Variable beschneiden ("TotalMilliseconds :" und
 rem alles nach dem Komma, inkl. dem Komma selbst entfernen, da die Zeit als Ganzzahl angegeben werden muss)

  set MS=%MS:~20,-5%

rem Zeit-Sychronisation mit dem Host deaktivieren

 "%VBoxPath%\VBoxManage" setextradata "%VMname%" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1

rem Offset setzen

 "%VBoxPath%\VBoxManage" modifyvm "%VMname%" --biossystemtimeoffset "%MS%"

rem Virtuelle Maschine starten

 "%VBoxPath%\VBoxManage" startvm "%VMname%"

Quellen:

Oracle VM VirtualBox – User Manual – 8.8. VBoxManage modifyvm (–biossystemtimeoffset <ms>)

Oracle VM VirtualBox – User Manual – Chapter 9. Advanced topics – 9.14.4. Disabling the Guest Additions time synchronization

Zeigt der VLC media player nach dem Update auf Version 3.0.3 bei der Wiedergabe eines Videos nur einen schwarzen Bildschirm, gibt aber den Ton wieder, liegt das mit hoher Wahrscheinlichkeit an der Hardwarebeschleunigung. Diese kann man wie nachfolgend beschrieben deaktivieren:

• Auf „Werkzeuge – Einstellungen“ klicken.
• Bei „Interface – Einstellungen anzeigen“ auf „Alle“ klicken.
• Zu „Eingang/Codecs – Videocodecs – FFmpeg“ wechseln.
• „Hardware Dekodierung“ auf „Deaktiviert“ stellen.
• Auf „Speichern“ klicken und den VLC media player neu starten.

Alternativ kann man ein Downgrade auf die vorige Version 3.0.2 durchführen:

https://download.videolan.org/pub/videolan/vlc/3.0.2/

Quelle:

The VideoLAN Forums – SOLVED: black screen after 3.0.3 vetinari update

Wird die Verbindung mittels Shrew Soft VPN-Client erfolgreich aufgebaut, aber es gehen keine Daten durch, so kann dies einen simplen Grund haben.

Sofern Routing- und Firewall-Konfiguration stimmen und richtig gesetzt wurden und die Verbindung in der Vergangenheit bereits erfolgreich funktionierte, liegt dieser „Aussetzer“ vermutlich an einem abgstürzten oder anderweitig gestörten Dienst.

Unter Windows können der Status und ein (Neu-)Start der notwendigen Dienste in der entsprechenden MMC überprüft und durchgeführt werden:

• ShrewSoft IKE Daemon (Dienstname: iked)
• ShrewSoft IPSEC Daemon (Dienstname: ipsecd)

Bei einem Supportfall war der Dienst „ShrewSoft IPSEC Daemon“ beendet. Nachdem dieser und der erstgenannte (neu)gestartet und die VPN-Verbindung nochmals neu aufgebaut wurde, klappte wieder alles wie gewohnt.

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

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

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

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

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

oder z.B. PsExec aus:

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

Die Ausgabe sieht wie folgt aus:

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


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

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

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

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

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

...

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

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

Anschließend sollte das System im OCC erscheinen.

Bei einem Kunden streikte die USB-Festplatte für die Datensicherung. Nachdem diese von USB und Strom getrennt und erneut angeschlossen wurde, konnte darauf nicht geschrieben werden.

Das Laufwerk war plötzlich schreibgeschützt. Dies merkt man zum einen daran, das keine Daten geschrieben oder gelöscht werden können, sehen kann man dies in der Computerverwaltung unter Datenträgerverwaltung.

Diesen Schreibschutz kann man mittels diskpart entfernen:

• Eine Eingabeaufforderung mit erhöhten Rechten öffnen.
• „diskpart“ eingeben.
• Mit „list disk“ die Laufwerke anzeigen.
• Mit „select disk <NR>“ das betroffenen Laufwerk auswählen.
• „attributes disk clear readonly“ eingeben um den Schreibschutz zu entfernen.
• Diskpart mittels „exit“ verlassen und die Eingabeaufforderung schließen.

Das Laufwerk ist nun wieder beschreibar.

Quelle:

Chip – Praxistipps – Hardware – Schreibschutz von Festplatte entfernen – so geht’s

Der VSS-Fehler 0x800423f0 wurde vor längerem bereits im Beitrag https://www.andysblog.de/windows-fehler-mit-drive-snapshot-v1-41-und-dem-parameter-allwriters-vermeiden behandelt. Erneut durch Drive Snapshot fiel dieser Fehler bei einem Kunden auf.

Da allerdings alle Partitionen bzw. Laufwerke im entsprechenden Sicherungskript berücksichtigt waren, musste die Ursache eine Andere sein. Über

DELL EMC – Product Communities – NetWorker – Diskussionen – Inconsistent Shadow Copy with System Writer

fand sich in der Antwort von R.Friberg vom 16.04.2018 05:58 eine Herangehensweise wie man den Fehler eingrenzen kann:

• Eine Eingabeaufforderung mit erhöhten Rechten starten.
• „diskshadow /l log.txt“ eingeben.
• Innerhalb von „Diskshadow“ folgendes eingeben:
  set verbose on
  list writers
  exit

Die daraus resultierende Protokolldatei z.B. mit Notepad öffnen und nach möglichen Warnungen oder Fehlern durchsuchen. Da in diesem Fall bereits bekannt war, das es am System Writer „hängt“, reichte es aus den entsprechenden Abschnitt zu durchsuchen, dabei fand sich dies:

- Von dieser Komponente betroffene Volumes:
- \\?\Volume{9bed0254-44af-4680-b478-8f94677d09b9}\ [C:\]
- \\?\Volume{ddaccd07-83b2-47be-9bea-695ea7362f5f}\ [D:\]
- "\\SRV01\FREIGABEN\" [nicht vorhanden]

Wie man sieht wurde C: und D: berücksichtigt und gefunden, aber eine Freigabe nicht und genau das ist der Grund.

Der Kunde hat Dienste auf diesem Server installiert. Untypsicherweise liegen die entsprechenden ausführbaren Dateien nicht lokal auf dem System, sondern auf einem anderen Server in einer Freigabe. Der System Writer möchte aber alle Volumes mit system-relevanten Daten sichern und das geht bei einer Freigabe nicht (ist ja schließlich kein Volume oder lokales Laufwerk, ferner handelt es um eine Block- und keine Dateisicherung).

Die Lösung besteht in diesem Szenario schlicht darin, die für die Dienste benötigten Dateien lokal abzulegen und die Dienste entsprechend anzupassen.

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

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

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

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

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

Quelle:

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

Beim Synchronisieren des Musik-Ordners fiel bei einer Windows 10-Maschine auf, das nicht nur Musik-Dateien sondern auch jede Menge Bilddateien kopiert wurden.

Ein näherer Blick zeigte, das es sich dabei um Album-Cover als verstecktes JPEG-Bild handelte. Bewusst und gewollt waren diese nicht. Nach einer schnellen Suche fand sich folgendes in den WindowsTenForums:

Windows 10: Disable Hidden JPGs For Album Art?

Der Windows Media Player, obwohl auf diesem System nicht genutzt, stattdessen kommt VLC media player zum Einsatz, generiert diese Bilder. Genau genommen ein Dienst, der für Plug-&Play-Geräte relevant ist. Nutzt man diese Funktion nicht, kann man den Dienst „Windows Media Player-Netzwerkfreigabediens“ deaktivieren:

Anschließend können die bereits angelegten Album-Cover entfernt werden. Schnell und einfach z.B. aus der Eingabeaufforderung heraus:

del "C:\Users\%username%\Music\*.jpg" /S /AH

Die in Windows 10 integrierte neue Foto- bzw. Bildanzeige ist imho nicht gerade die Schnellste. So störte mich alleine schon die Ladezeit des Tools. Mit einem kleinen Eingriff in die Registry lässt sich die alte Windows-Fotoanzeige wiederbeleben.

Eine bebilderte Anleitung findet in der Tipps&Tricks-Sektion bei heise.de:

Windows 10: Alte Fotoanzeige verwenden

Kurz zusammengefasst muss man in der Registry ein paar Einträge hinzufügen:

Unter

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Photo Viewer\Capabilities\FileAssociations

für jedes gewünschte Bildformat einen weiteren Eintrag in der Art

.jpeg | REG_SZ | PhotoViewer.FileAssoc.Tiff

hinzufügen.

Für gebräuchliche Bilddateien sieht eine entsprechende *.reg-Datei zum Importieren wie folgt aus:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Photo Viewer\Capabilities\FileAssociations]
".jpg"="PhotoViewer.FileAssoc.Tiff"
".png"="PhotoViewer.FileAssoc.Tiff"
".bmp"="PhotoViewer.FileAssoc.Tiff"
".jpeg"="PhotoViewer.FileAssoc.Tiff"
".ico"="PhotoViewer.FileAssoc.Tiff"
".gif"="PhotoViewer.FileAssoc.Tiff"

Verwendet man Gigaset-Mobilteile und hat z.B. Schwierigkeiten mit der in der AVM FRITZ!Box integrierten DECT-Basis oder man möchte bestimmte Funktionen der Mobilteile und/oder der Gigaset-Basen nutzen, so kann man die Gigaset-IP-Basen an der FRITZ!Box mittels VoIP anbinden.

Es könnte eigentlich ganz einfach sein: Bei neueren IP-DECT-Basen wie der aktuellen Gigaset GO-Box 100, die bei verschiedenen Sets mit dabei ist, muss man eigentlich nur schnell einen Assistenten durchlaufen. Leider ist die Doku bzw. Angabe bei der Ersteinrichtung nicht ganz zutreffend.

Im Feld „Name IP-Telefon“ bzw. wenn man manuell einen Provider anlegt im Feld „Anmelde-Name“ den bei der Einrichtung des IP-Telefons vergebenen Benutzernamen eintragen, nicht wie beschrieben die interne Rufnummer wie beispielsweise „620“.

Dieser entscheidene Hinweis fand sich bei

Carsten’s Blog – Gigaset GO an FRITZ!Box betreiben

Stolperfalle: Wenn die FRITZ!Box nicht der Router ist

Der Assistent geht nach der Auswahl von „Fritz!Box Fon“ automatisch davon aus, das Registrar, Domäne und Proxy „fritz.box“ ist. Das funktioniert, solange die FRITZ!Box der Router im Netz ist und wie vom Hersteller und dem Durchschnitt der Anwender verwendet wird. Wird die FRITZ!Box allerdings „nur“ als WLAN-Basis und ggf. Bindeglied zum VoIP-Provider verwendet, so muss „fritz.box“ durch die IP-Adresse der FRITZ!Box ersetzt werden.

Nachfolgend ein Screenshot von einer älteren Siemens Gigaset S685 IP-Basis:

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

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

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

nslookupset q=MX<Domain>

Quelle:

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

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

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

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

Quelle:

nixCraft – Linux / UNIX: DNS Lookup Command

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

Mittels CrystalDiskInfo kann man schnell den Status einer Festplatte oder SSD überprüfen. Möchte man dies z.B. automatisiert via Skript oder aus der Ferne via PsExec tun, geht das ebenfalls.

Schlicht an die jeweilige Exe-Datei die Option „/CopyExit“ anhängen. Beispiele:

DiskInfo32.exe /CopyExit
DiskInfo64.exe /CopyExit

Das Resultat wird in der Datei „DiskInfo.txt“ im Ordner von CrystalDiskInfo gespeichert. Nachfolgend ein Auszug aus einer dieser Dateien:

----------------------------------------------------------------------------
CrystalDiskInfo 7.7.0 (C) 2008-2018 hiyohiyo
                                Crystal Dew World : https://crystalmark.info/
----------------------------------------------------------------------------

    OS : Windows 7 Professional SP1 [6.1 Build 7601] (x64)
  Date : 2018/09/18 13:39:54

-- Controller Map ----------------------------------------------------------
 + Intel(R) 8 Series/C220 Chipset Family SATA AHCI Controller [ATA]
   - INTE    SSDSC2BW120H6 SCSI Disk Device

-- Disk List ---------------------------------------------------------------
 (1) INTEL SSDSC2BW120H6 : 120,0 GB [0/0/0, pd1] - il

----------------------------------------------------------------------------
 (1) INTEL SSDSC2BW120H6
----------------------------------------------------------------------------
           Model : INTEL SSDSC2BW120H6
        Firmware : RG21
   Serial Number : xxxxxxxxxxxxxxxx
       Disk Size : 120,0 GB (8,4/120,0/120,0/120,0)
     Buffer Size : Unbekannt
     Queue Depth : 32
    # of Sectors : 234441648
   Rotation Rate : ---- (SSD)
       Interface : Serial ATA
   Major Version : ACS-3
   Minor Version : ----
   Transfer Mode : SATA/600 | SATA/600
  Power On Hours : 1854 Std.
  Power On Count : 244 mal
      Host Reads : 2867 GB
     Host Writes : 1792 GB
     NAND Writes : 41066 GB
     Temperature : 34 C (93 F)
   Health Status : Gut (85 %)
        Features : S.M.A.R.T., APM, 48bit LBA, NCQ, TRIM, DevSleep
       APM Level : 00FEh [ON]
       AAM Level : ----
    Drive Letter : C:

-- S.M.A.R.T. --------------------------------------------------------------
ID Cur Wor Thr RawValues(6) Attribute Name
05 100 100 __0 000000000000 Anz. wiederzugewiesener Sektoren
09 100 100 __0 00000000073E Betriebsstunden
0C 100 100 __0 0000000000F4 Anz. Geräte-Einschaltvorgänge
AA _85 100 _10 000000000000 Verfügbarer Reservespeicher
AB 100 100 __0 000000000000 Programmfehler
AC 100 100 __0 000000000000 Löschfehler
AE 100 100 __0 000000000005 Anz. unerwarteter Spannungsabfälle
B7 100 100 __0 000000000000 SATA Downshift Count
B8 100 100 _90 000000000000 Ende-zu-Ende-Fehlererkennungszählerstand
BB 100 100 __0 000000000000 Nicht korrigierbare Fehler
BE _34 100 __0 0012003C0022 Temperatur
C0 100 100 __0 000000000005 Unsachgemäße Ausschaltung
C7 100 100 __0 000000000000 CRC-Fehler, Anzahl
E1 100 100 __0 00000000E003 Host-Schreibvorgänge
E2 100 100 __0 00000000FFFF Indikator der Mediumabnutzung unter Arbeitslast
E3 100 100 __0 00000000003D Prozentsatz der Host-Lese-/Schreibvorgänge unter Arbeitslast
E4 100 100 __0 00000000FFFF Arbeitslastmessung
E8 _85 100 _10 000000000000 Verfügbarer Reservespeicher
E9 _79 100 __0 000000000000 Medienabnutzungsanzeiger
F1 100 100 __0 00000000E003 LBA geschrieben (gesamt)
F2 100 100 __0 00000001666B LBA gelesen (gesamt)
F9 100 100 __0 00000000A06A NAND geschrieben (gesamt)

Am interessantesten dürfte wohl „Health Status“ sein.

Quelle:

Crystal Dew World – CrystalDiskInfo – Advanced Features

Möchte man eine bestimmte Reihenfolge bei den Mailkonten in Thunderbird haben, so kann diese „ab Werk“ nicht ohne weiteres geändert werden.

Einen sehr bequemen Weg mit noch mehr Möglichkeiten bot bislang das Add-on Manually sort folders, leider funktioniert dieses ab Thunderbird 60 nicht mehr. Etwas umständlicher aber ebenfalls zum Erfolg führt das manuelle Ändern der Konten-Reihenfolge. Eine sehr gute Anleitung findet sich unter

Sidvind – Thunderbird/Change account order

• Auf „Extras – Einstellungen“ klicken.
• Zur Registerkarte „Erweitert“ wechseln.
• Auf „Konfiguration bearbeiten“ klicken (Zur Info: Dies entspricht „about:config“.)
• Die Warnmeldung bestätigen.
• „mail.accountmanager.accounts“ eingeben und die Reihenfolge ändern.

Bei mir war bereits durch den früheren Einsatz von Manually sort folders die Reihenfolge geändert. Wer also vor dem Wechsel auf Thunderbird 60 (oder neuer) bereits das genannte Add-on im Einsatz hatte, braucht sich zumindest wegen der Konten-Reihnfolge keine Gedanken zu machen.

vCard-Dateien (*.vcf) kann man zwar mit jedem beliebigen Editor bearbeiten, schöner oder bequemer geht es allerdings mit diversen Anwendungen.

Bei einem Kunden ging es darum 70 Telefonbucheinträge in ein Gigaset-IP-DECT-System (einzu-)pflegen. Bequem am PC lässt sich dies z.B. mit einer Tabellenkalkulation wie MS Excel oder Calc aus dem Libre- oder OpenOffice-Paket erledigen. Hilfreich ist dabei das Tool vCard Grid von Stefan Däubner, das wiederum vCard-Dateien zu *.csv- oder Excel-Dateien und zurück konvertieren kann.

Das Vorgehen für das genannten Vorhaben ist dabei ziemlich einfach:

• Zunächst von vCard Grid die Vorlage erstellen lassen.
• Diese in einer beliebigen Tabellenkalkulation öffnen (ich nahm dafür LibreOffice’s Calc und die *.xls-Datei).
• Die gewünschten Felder eintragen und speichern.
• Mittels vCard Grid die Excel-Datei zu vCard-Datei(en) umwandeln lassen.
• Als letzter Schritt die „contacts-all.vcf“ mittels Browser über die IP-DECT-Basis auf die Mobilteile hochgeladen.

Gigaset IP-DECT-Basen samt Mobilteile lassen sich als kostengünstige Schnurloslösung an einer 3CX-Telefonanlage betreiben. Gemeint ist damit dabei Consumer-Varianten, nicht die Gigaset Pro-Geräte. Die Pro-Geräte bieten Vorteile wie z.B. Provisionierung, zentrales Telefonbuch etc. (siehe Konfigurieren der DECT-Basisstation Gigaset N510 für 3CX).

Möchte man nur schlicht ein paar Mobilteile ohne weitere Komfortfunktionen anmelden, geht dies einfach durch das verwenden eines generischen VoIP-Providers, bei Gigaset „Anderer Provider“ genannt.

Zum Test stand nur eine ältere Siemens Gigaset S685 IP-Basis mit verschiedenen Mobilteilen zur Verfügung. Bei den aktuellen Gigaset GO-Box 100-Geräten dürfte es ähnlich sein.

Vorab wurden die Mobilteile an der Basis angemeldet. Als Vorbereitung muss aus der Nebenstelle der 3CX die „Auth.-ID“ samt Kennwort ausgelesen werden. Diese Angaben zusammen mit der IP-Adresse der 3CX und der Nebenstellennummer müssen im VoIP-Konto der IP-DECT-Basis eingetragen werden:

Der „Anmelde-Name“ entspricht der „Auth.-ID“ der 3CX,
das Anmelde-Passwort entspricht dem Kennwort der Nebenstelle,
der „Benutzer-Name“ ist die Nebenstellennummer.

Darüberhinaus muss die IP-Adresse oder der Hostname der 3CX in den weiteren Einstellungen eingetragen werden.

Das Thema Outlook umziehen wurde vor geraumer Zeit bereits im Beitrag Microsoft Outlook 2013 umziehen behandelt. Mit etwas genaueren Angaben zu den Speicherorten von verschiedenen Outlook-Versionen kommt nun quasi ein Update.

Bei PCtipp.ch kann man im Artikel Outlook-Kontoeinstellungen übertragen die Pfade zum jeweiligen Outlook-Profil für verschiedene Versionen nachlesen. So findet sich z.B. bei Outlook 2010 das Profil unter

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion \Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676

Diesen Schlüssel kann man ex- und anschließend beim Ziel-Benutzer bzw. -Computer importieren.

Mit dem Wissen des Speicherorts in der Registry kann man natürlich auch eine Sicherung des Profil vornehmen, bevor man beispielsweise irgendwelche Experimente mit Einstellungen vornimmt.

Fallbeispiel:

Inspiriert wurde dieser Beitrag durch eine Situation die ein Kunde nach der Auffrischung seines Windows 10-Computers hatte. MS Office inkl. Outlook und des Profils war nach diesem Vorgang nicht mehr vorhanden.

MS Office wurde neu installiert und das bisherige Outlook-Profil wurde wie folgt „gerettet“:

• regedit mit erhöhten Rechten öffnen.
• Auf „Datei – Struktur laden“ klicken.
• Die Datei „C.\Windows.old\Users\<Benutzername>\ntuser.dat“ auswählen.
• Als Namen z.B. USER.OLD eingeben.
• Anschließend unter „HKEY_USERS\USER.OLD“ zu oben bzw. bei PCtipp.ch genannten Schlüssel wechseln und diesen mit „Rechtsklick – Exportieren“ sichern.
• Die zuvor geladene Struktur durch „Datei – Struktur trennen“ entladen und regedit beenden.
• Die exportierte Datei mit Notepad öffnen und „HKEY_USERS\USER.OLD“ durch „HKEY_CURRENT_USER“ ersetzen.
• Die Änderung speichern und die Datei doppelt anklicken.
• Die Meldung(en) bestätigen.

Nun sollte das Outlook-Profil vorhanden sein und genutzt werden können. Ggf. müssen die Kennwörter neu gesetzt werden. Sollten sich die Pfade zu den Datendateien geändert haben, so müssen diese ebenfalls aktualisiert werden.