Zumindest der kostenlose Virenschutz von Avast erkennt fälscherweise manche Drive Snapshot-Sicherungen als Malware.
Im konkreten Fall wurde die Abbilddatei der Windows 7-Boot-Partition (“System-reserviert”) als Schädling erkannt. Es handelt sich um eine Falschmeldung.
Um eine Remotedesktopverbindung ohne Kennwort nutzen zu können, muss auf dem Ziel-Computer eine Einstellung geändert werden.
Ein Neustart ist der Beobachtung nach nicht notwendig. Keine Kennwörter zu verwenden ist (natürlich) nicht zu empfehlen. Getestet bzw. notwendig war diese Änderung bislang nur bei einem Kunden-Szenario unter Windows 7 Professional. Alternativ kann man auch folgenden Befehl ausführen:
Reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" /v LimitBlankPasswordUse /t REG_DWORD /d 0 /f
Als *.reg-Datei sieht das Ganze dann wie folgt aus:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] "LimitBlankPasswordUse"=dword:00000000
speedguide.net – FAQ – How to connect using Remote Desktop without a password ?
Achtung: Der Wert im Befehl aus dem Kommentar ist falsch!
VirtualBox ist eigentlich eine feine Lösung und tut meist was sie soll, zumindest bei den Dingen die ich so mache. Manchmal stösst man allerdings an Grenzen oder stolpert über Probleme.
Unter anderem verwende ich z.B. ein Linux Mint als virtuelle Maschine und je nachdem was man gerade macht, wird dann auch der dortige Firefox bemüht. Seit einiger Zeit läuft das allerdings nicht mehr rund. Ein Test mit Chromium verlief noch schlechter. Auch in einem virtualisierten Manjaro siehts nicht besser aus. Das (De-)Aktivieren der Hardwarebeschleunigung in den Browsern, als auch das Ändern der VM-Einstellungen mit mehr Speicher bis hin zum Maximum von 128 MB, aktivierter 2D- oder 3D-Beschleunigung änderten nicht viel. Besser ja, aber nicht wirklich viel. Das kommt aber auch darauf an, was man für Seiten besucht und dort ggf. für Skripte, Animationen, Videos etc. laufen.
Laut Recherche soll das Ändern der Einstellungen bei manchen viel geholfen haben, dieses Glück war mir allerdings nicht gegönnt. Nachdem schon die Installation von VMware Workstation Player wegen der leidigen WLAN-Netzwerkbrückenthematik erfolgte, wurde in den dortigen virtuellen Maschinen mal getestet. Wie bei der WLAN-Netzwerkbrücke läuft es auch dort schlichtweg besser. Schaut man sich die Einstellungen an, wird einem schnell klar, warum das so ist:
Mal unabhängig von der emulierten Hardware bietet VMware einfach mehr Grafikspeicher. Bereits in der Default-Einstellung ist es um ein vielfaches mehr als bei VirtualBox. Zumindest für meinen Anwendungsfall ist aktuell der VMware Workstation Player die bessere Wahl.
Musste man bisher bei Raspbian etwas tüffteln um via VNC oder Xrdp auf den angezeigten Desktop zu gelangen, so geht das mit der aktuellen Raspbian-Version, dem neuen PIXEL-Desktop und dem integrierten RealVNC-Server sehr einfach.
Für diesen Beitrag wurde ein Raspberry Pi 2 Model B verwendet.
Im Blog des Projekts sind die notwendigen Schritte beschrieben. Folgende Befehle führen das Upgrade durch:
sudo apt-get update sudo apt-get dist-upgrade sudo apt-get install -y rpi-chromium-mods sudo apt-get install -y python-sense-emu python3-sense-emu sudo apt-get install -y python-sense-emu-doc realvnc-vnc-viewer
Beim ersten Durchlauf von „sudo apt-get dist-upgrade“ gab es allerdings ein paar Fehlermeldungen, nach einem Neustart und auf den zweiten Versuch klappte das Upgrade fehlerfrei.
Mit
sudo apt-get install -y realvnc-vnc-server
wird der RealVNC-Server installiert.
Achtung: Der integrierte RealVNC-Server „beißt“ sich mit Xrdp, von daher muss man sich für die eine oder die andere Lösung zuvor entscheiden!
„Ab Werk“ ist der RealVNC-Server nicht aktiviert, dies kann man sowohl im Terminal bzw. via ssh über
sudo raspi-config Advanced Options VNC -> Yes
oder in der grafischen Oberfläche über
Menü - Einstellungen - Raspberry-Pi-Konfiguration - Schnittstellen - VNC -> Aktiviert
tun.
Die Konfiguration erfolgt in den „VNC Server – Optionen“, diese erreicht man über einen Rechtsklick auf das RealVNC-Symbol.
In der Voreinstellung kann via RealVNC-Viewer (Download) oder über einen Browser mit Java (URL: „http://<IP-oder-Hostname>:5800“) zugegriffen werden.
Möchte man z.B. den UltraVNC-Viewer verwenden, so muss die Authentifizierung von „UNIX-Kennwort“ auf „VNC-Kennwort“ umgestellt und ein Kennwort vergeben werden. Ein Vorteil vom Original-Viewer ist allerdings die Verschlüsselung.
heise – PIXEL: Neuer Desktop für Raspbian und Raspberry Pi
Um auf eine virtuelle Festplatte in VMware’s VMDK-Format unter Windows zugreifen zu können gibt es einige Möglichkeiten. Geht es nur um’s entpacken von Inhalten, kann man z.B. auf 7-Zip zurückgreifen. Zum lesenden Einhängen gibt es ebenfalls mehrere Tools. Deutlich dünner wird die Auswahl, wenn es um den schreibenden Zugriff geht.Eine Übersicht über verschiedene Tools für den lesenden und/oder schreibenden Zugriff findet sich unter
Raymond.cc – 7 Ways To Open Virtual Hard Disk Images For Read And Write Access
lmDisk stellt dabei eine einfache Möglichkeit dar, die im Test gut funktionierte:
Tipp: Den Haken setzen bei „Entfernbar“, dann muss nicht zu „Systemsteuerung – lmDisk Virtual Disk Driver“ gewechselt werden, um die virtuelle Festplatte wieder trennen zu können, dann genügt ein Rechtsklick auf das Laufwerk und „Auswerfen“.
Eine weitere Option ist der Arsenal Image Mounter (ungetestet).
Die genannten Tools können als Alternative zu den Bordmitteln von VMware betrachtet werden, vorallem dann wenn es zu folgenden Fehler kommt:
In Linux Mint ist Vino als VNC-Server bereits vorinstalliert und muss lediglich aktiviert und konfiguriert werden.Auf „Einstellungen – Freigabe der Arbeitsfläche“ klicken und wie folgt konfigurieren:
Mit den Voreinstellungen funktioniert kein Zugriff z.B. mit dem UltraVNC- oder RealVNC-Viewer. Damit man diese Viewer dennoch verwenden kann, muss die Verschlüsselung deaktiviert werden:
Je nachdem was man so alles mit seinem Raspberry Pi und dem dortigen Raspbian anstellt, kann es unter Umständen schnell dazu kommen, das einem der Speicherplatz ausgeht. Ist man an diesem Punkt angekommen, so sollte man schauen, was man evtl. aufräumen kann.
In der Paketverwaltung sammeln sich oft einige Daten an, die sich leicht entfernen lassen:
sudo apt-get clean
Die Protokolldateien können durchaus einiges an Speicherplatz belegen. Im Notfall macht es Sinn zunächst die archivierten Protokolle zu entfernen:
sudo rm -f /var/log/{*.gz,*.[0-9]}
Ist der Speicherplatz generell knapp bemessen, ist es sinnvoll das Verhalten anzupassen:
Auf jeden Fall sollte man prüfen, ob denn das Dateisystem bzw. die Partitionsgröße zur Größe der Speicherkarte passt. Soll heißen: Evtl. hat man nach der Installation vergessen, die Größe anzupassen und verschenkt dadurch Platz. Mit meinem ersten Raspi ist mir genau das passiert und ich wunderte mich kurze Zeit später, warum alles voll ist.
Über den Download der Woche beim IT-Administrator wurde ich auf die Evorim Free Firewall aufmerksam.
Folgende Punkte wissen zu gefallen:
Das die Firewall auch auf Windows Servern eingesetzt werden kann, ist nicht selbstverständlich bei Desktop-Firewalls. Interessant ist die Ankündigung einer portablen Version und der Schutz vor betrügerischen Webseiten. Mit anderen Worten: Die Lösung wächst.
Vermissen tue ich aktuell die Integration ins Sicherheitscenter (soll kommen) als auch ein Protokoll. Die Evorim Free Firewall ist eine Application Firewall, d.h. sie reglementiert Anwendungen und Dienste. Wer mit Protokollen (tcp,udp,…) und Ports arbeiten möchte, findet bei dieser Firewall keine Einstellungsmöglichkeiten.
In der aktuellen Form betrachte ich persönlich die Evorim Free Firewall als Ergänzung zur Windows-Firewall. Die einfache Konfiguration als auch die Möglichkeit die Privatsphäre zu Schützen sind ein deutliches Plus.
Oft ist man es von klassichen Telefonanlagen gewohnt, das man einfach durch Auflegen des Hörers weiterverbinden kann. Damit das mit snom-Telefonen funktioniert muss „transfer on hangup“ bzw. „transfer on onhook“ aktiviert werden.
In der Voreinstellung erfolgt das Weiterverbinden via
Hold + <NR> + OK
Statt das man abschließend „OK“ drücken muss, soll einfach der Hörer aufgelegt werden, das kennt man z.B. von Auerswald, Agfeo und Avaya-Anlagen. Grundsätzlich gibt es zwei Möglichkeiten, die Einstellung zu setzen: Entweder im Web-Interface des Telefons, was zur Folge hätte, das Auto-Provisioning nicht mehr funktioniert oder durch entsprechende Einträge unter „Manual Attributes (Provisioning template)“ im Telefon-Konto der Askozia.
Für letztgenanntes ist folgende Änderung notwendig:
Firmware 9.x:
<phone-settings> <transfer_on_onhook perm="rw">on</transfer_on_onhook> </phone-settings>
Firmware 6.x, 7.x, 8.x:
<phone-settings> <transfer_on_hangup perm="rw">on</transfer_on_hangup> </phone-settings>
Firmware 8.x:
<phone-settings><transfer_on_hangup_non_pots perm="rw">on</transfer_on_hangup_non_pots></phone-settings>
Die Einstellungen für unterschiedliche Firmware-Versionen können kombiniert werden:
<phone-settings> <transfer_on_onhook perm="rw">on</transfer_on_onhook> <transfer_on_hangup perm="rw">on</transfer_on_hangup> </phone-settings>
snom – Wiki – Settings/transfer on onhook
In kleinen Netzwerken kommt oft kein eigener DNS-Server zum Einsatz. Ggf. kümmert sich der Router um die Namensauflösung, unter Umständen greifen auch andere Mechanismen. Kommt es in solch einer Umgebung zu Problemen beim Auto-Provisioning der Telefone, kann dies an einer fehlerhaften Namensauflösung liegen.
So geschehen bei der Inbetriebnahme einer neuen Askozia Desktop-PBX 5.0.3 und snom 720 VoIP-Telefonen. Ein Blick ins Log eines snom-Telefons zeigte schnell, das etwas nicht stimmt:
Oct 6 09:50:59 [DEBUG1] DNS: Add Cache: askoziapbx.local=192.168.1.116 (ttl=60, type=7)
Eigentlich sollte der Hostnamen „askoziapbx.local“ zur IP-Adresse „192.168.1.3“ aufgelöst werden. Die angezeigte Adresse stammte noch von der Inbetriebnahme der PBX, bevor diese eine feste IP-Adresse eingestellt bekommen hatte. Zu diesem Zeitpunkt war allerdings das Telefon noch nicht angeschlossen. Somit war klar, das in diesem Fall die FRITZ!Box die veraltete Info lieferte. Auch ein Neustart der FRITZ!Box als auch des Telefons änderte daran nichts. Letztlich wurde einfach auf den Hostnamen für die Provisionierung verzichtet:
Beim nächsten Neustart der Telefone klappt’s wieder mit dem Auto-Provisioning.
Bei den unterstützen Geräten von Askozia ist die M300 DECT-Basis von Snom noch mit „under development“ gekennzeichnet. Auf Nachfrage beim Support kam kurz und gut die passende Antwort zu der Frage, ob man diese dennoch irgendwie verwenden könnte.
Kurzum: Die M300 lässt sich genauso wie die M700 anbinden. Im Wiki sind die notwendigen Schritte beschrieben:
Askozia – Wiki – DECT-Basen – Snom M700
Vielen Dank an den Askozia-Support für die zügige Antwort.
Kleiner Nachtrag, was noch als zusätzliche Info vom Support gekommen ist:
„In der deutschen Übersetzung der Version 5.0.3 haben wir leider den Bug, dass bei der Auswahl des Typs der DECT Basis die falschen Namen angezeigt werden. Wenn Sie das Webinterface der Anlage auf Englisch umstellen wird hier auch die M300 aufgeführt.“
So etwas Troublehsooting zum zentralen Adressbuch am Mobilteil:
Erscheint am Mobilteil beim Versuch auf das zentrale Adressbuch zuzugreifen die Meldung „Verbindung fehlgeschlagen“ sollte die Firmware sowohl auf der Basis als auch dem Mobilteil überprüft werden. In unserem Fall war die Version 3.24 vorinstalliert. Laut Askozia-Support sollte Version 3.55 installiert werden.
Bei dem Versuch gemäss dem Snom-Wiki die Firmware zu aktualisieren, geschah allerdings nichts:
FAQ/snom M/update using dect snom com
Das Log der Basis gab lediglich ein
"loc2 .Info 2016-10-06T18:13:27Z 173-[ SendFwuKillMail Succeeded]"
aus. Kurzerhand wurde ein Apache Webserver installiert und die Firmware-Dateien gemäss folgender Snom-Doku platziert:
Im Web-Interface der Basis muss unter „Firmware Aktualisierung“ folgendes durchgeführt werden:
Hinweis: Der Screenshot ist bereits von der Version 3.55, bei 3.24 sieht es noch etwas anders aus.
Dann zunächst die Basis aktualisieren:
Im Log des Webserver sollte jetzt angezeigt werden, das aus dem Unterordner „M300“ die Firmwaredatei abgerufen wird. Es dauert ein paar Minuten mit die Datei übertragen und verifiziert ist. Sobald die Aktualisierung startet steht die Basis nicht mehr zur Verfügung und die LED blinkt.
Mobilteil aktualisieren:
Es dauert einige Zeit bis das Update auf das Mobilteil geladen und installiert wird. Im Log des Webservers sollte man den Abruf der Firmware-Datei sehen können. Ferner liefert das Log der Basis einen Hinweis auf das Update:
loc2 .Info 2016-10-07T12:29:03Z 173-[ Firmware update started to version 0355 for handset: 0]
Wichtig: Das Mobilteil wird nur aktualisiert, wenn es sich in der Ladeschale befindet.
Interessant bei dieser Firmware-Update-Thematik ist folgendes:
„Hinweis zu Domain-DNS-Installationen: Endet der lokale (interne) FQDN bei einem Domain-DNS-gestützt installierten 3CX Phone System auf “.local”, führt die DECT-Basisstation der M-Serie KEINE DNS-Server-Abfrage zur Auflösung der URL durch. Stattdessen wird ein Host mDNS-basiert gesucht. Dies hat zur Folge, dass die Provisionierung fehlschlägt und keine Konfigurationsdatei vom 3CX-Server abgerufen wird. Nutzen Sie daher die Provisionierungsoption 2B, und ersetzen Sie den FQDN durch die IP-Adresse des 3CX Phone System. Dieses Problem betrifft die Firmware B7 und B12 der DECT-Basisstation und wird voraussichtlich in einer künftigen Firmware-Version behoben werden.“
Quelle: Auto-Provisionieren der DECT-Basisstation snom M300 und M700 für das 3CX Phone System
Das bezieht sich zwar auf das Provisioning, könnte aber evtl. auch ein Hinweis darauf sein, warum das Firmware-Update direkt von „http://dect.snom.com“ nicht funktionierte. Ein Test mit der IP-Adresse dieses Hosts half allerdings ebenfalls nichts, so das letztlich nur die Verwendung eines lokalen Webservers mit IP-Adresse übrig blieb.
Der Shrew Soft VPN Client kann z.B. in Verbindung mit der AVM FRITZ!Box oder der Digitalisierungsbox Premium der Deutschen Telekom verwendet werden. In der Voreinstellung wird allerdings jeder Datenverkehr durch den Tunnel geschickt.
Unter Umständen ist das nicht gewünscht oder nicht notwendig. Die notwendigen Einstellungen finden sich leicht:
Eigentlich ist es recht einfach, eine VPN-Verbindung mit Hilfe des Shrew Soft VPN Clients zu einer FRITZ!Box mit aktueller Firmware aufzubauen.In der Anleitung von AVM ist alles relevante beschrieben:
VPN-Verbindung zur FRITZ!Box mit Shrew Soft VPN Client einrichten
Das Ganze hat bislang auch mehrmals erfolgreich ohne Probleme geklappt. In diesem Szenario komme ich aktuell leider nicht weiter:
Bemerkung am Rande: Der Computer (ein Notebook) ist dabei immer der Gleiche.
Ich vermute es hängt irgendwie mit der pfSense zusammen. Die Logs sind allerdings unauffällig. Der Cisco-workaround hat ebenfalls nicht geholfen:
Cisco VPN pass through not working when behind pfSense
Es scheint kein generelles IPsec(Passthrough)-Problem zu sein, da beispielsweise die Verbindung zu einer Telekom Digitalisierungsbox Premium, ebenfalls mit dem Shrew Soft VPN Client und gleichem Notebook als auch pfSense, funktioniert.
Im Moment versuche ich neben der weiteren Recherche (die bis jetzt nichts gebracht hat) und dem Trace Utilitiy des VPN-Clients dahinter zu kommen, woran es hängt.
Falls noch jemand einen Tipp hat, immer her damit!
Da weiß man gleich wieder, warum man OpenVPN stressfreier findet 
pfSense – IPsec Troubleshooting
Shrew Soft – VPN Bug Report Windows (interessant wegen des Trace Utility)
Eine Verbindung zu einem Linksys RV082 klappt ebenfalls.
Der AVM-Support kann oder will nicht helfen und verweist auf den Hersteller des VPN-Clients.
Zum Testen wurde in einem Netzwerk in dem eine FRITZ!Box 7490 den Internetzugang stellt, unter VMware Workstation Player eine virtuelle Maschine mit pfSense und jeweils eine mit Linux Mint und Windows 8.1 angelegt. Anschließend wurde der Shrew Soft VPN Client installiert und entsprechend konfiguriert. In dieser Testumgebung funktioniert der Zugriff, daraus lässt sich evtl. schließen, das es nicht direkt mit pfSense im Allgemeinen zusammenhängt.
Inzwischen glaube ich nicht unbedingt mehr daran, das es an der pfSense liegen könnte. Ein weiterer Kandidat könnte das verwendete VDSL-Modem vom Typ ZyXEL VMG1312-B30A (Firmware: 1.00(AAEB.5)) sein. In Verbindung mit diesem Modem gab es bereits Probleme mit IPsec:
[GELÖST]Zyxel VMG1312-B30A IPSec tot nach 24 Stundentrennung
Im Netz finden sich auch neuere Firmware-Versionen, allerdings bin ich unschlüssig, ob man eine davon installieren sollte. Jedenfalls wurde der Herstellersupport kontaktiert.
Den Shrew Soft VPN Client findet man in einigen Linux-Distributionen, so auch bei Linux Mint. Möchte man von diesem aus eine Verbindung zu einer FRITZ!Box 7490 herstellen und richtet dies gemäss der AVM-Anleitung ein, so klappt der Verbindungsaufbau zunächst nicht.
Den VPN-Client findet man in der Anwendungsverwaltung z.B. mit dem Suchbegriff „shrew“:
Wählt man den Treffer „Ike-qtgui“ aus und installiert dieses Paket findet sich im Anschluss unter „Menü – Internet – Shrew Soft VPN Zugangsverwaltung“ der VPN-Client.
Nun kann man zunächst via eingangs erwähnt mit der AVM-Anleitung die Einrichtung erfolgen. Sobald man damit durch ist, sollte eine kleine aber relevante Anpassung gemacht werden:
Offenbar sind die Voreinstellungen von der Windows und Unix-Version unterschiedlich. Hat man die Änderung vorgenommen und gespeichert, kann die Verbindung aufgebaut werden.
Nach dem Upgrade von Windows 10 1511 auf 1607 auf einem Toshiba Satellite L350-20H kam kein Ton mehr aus der Soundkarte. Weder über die Lautsprecher noch via Kopfhörer ist etwas zu hören. In der anderen Richtung funktioniert das Mikrofon ebenfalls nicht mehr.
Zugegeben das Notebook ist schon älter, mit Windows 7 und Windows 10 – 1511 gab es keine Probleme. Erst das Upgrade auf 1607 machte die Soundkarte unbrauchbar. Wobei man dazu sagen muss, das Toshiba nur Treiber bis Windows 7 zur Verfügung stellt. Der Kunde hatte von Windows 7 zu Windows 10 gewechselt.
Solche Probleme sind generell seit dem Upgrade von Windows 7 auf Windows 10 und von 1511 auf 1607 bekannt. Mehrheitlich scheint es, wie in diesem Fall, Schwierigkeiten mit Realtek-Soundkarten zu geben. Laut Recherche sollen folgende Massnahmen zumindest zum Teil bei anderen Geräten und Anwendern geholfen haben:
Die Versuche den Treiber zu reinstallieren, den neuesten Treiber von Toshiba, den Aktuellsten von Realtek (2.79), die aktualisierte Version aus dem Microsoft Update Catalog, Kompatibilitätsmodus oder einen generischen Treiber zu verwenden änderten nichts an der Sache. Die Soundkarte bleibt stumm. Es gibt keine Fehlermeldung, die Setups laufen erfolgreich durch, in der Lautstärkeregelung wird sogar ein Pegel angezeigt.
Führt man ein Downgrade auf 1511 durch oder bootet ein anderes Betriebssystem funktioniert die Soundkarte. Daraus lässt sich schließen, das die Hardware ansich wohl in Ordnung ist.
Woran es nun genau scheitert oder wer dafür Verantwortlich ist (Microsoft, Realtek, der Computerhersteller) bleibt offen. Ärgerlich ist es allemal, das einmal mehr etwas funktionierendes „kaputtgepacht“ wurde.
Links:
WinFuture – Windows 10 Jubiläums-Update: Die nervigsten Fehler gelöst
Battle.net – Nach Windows 10 Anniversary Update kein Ton mehr
Microsoft Blog – Troubleshooting: how to install the Microsoft HD Audio class driver
technikaffe – Windows 10 Preview Build 10041 und der Realtek Audio Bug (Lösung!)
Microsoft Community – *FIXED* Windows 10 1607 anniversary update broke my realtek audio driver.
Microsoft Update Catalog – Realtek High Definition Audio 6.0.1.7954
Der T.38 Printer stellt unter Windows (ab XP) einen Drucker für das direkte Faxen aus Anwendungen via VoIP heraus zur Verfügung. So können entsprechende Telefonanlagen wie auch VoIP-Provider für das „Wegfaxen“ genutzt werden.
Zuerst sollte man sich von der Homepage nicht abschrecken lassen, die Software ist in der Version weiter, als das es die News einen meinen lassen. Zum Test wurde der T.38 Printer auf einem Notebook mit Windows 8.1 Pro x64 installiert. Als Telefonanlage kommt eine Askozia PBX zum Einsatz, der Provider ist die Deutsche Telekom.
In der Konfiguration kann ein Mail-Konto, genauer gesagt eine SMTP-Verbindung angelegt werden. Das Programm schickt dann den Fax-Ausdruck an die dort hinterlegte E-Mail-Adresse.
Beim Drucken bzw. Versand kann man dann Auswählen, ob das VoIP- oder das E-Mail-Konto verwendet werden soll.
An Adressbücher kann das Windows-Adressbuch oder das Adressbuch einer 3CX-Telefonanlage verwendet werden.
Versendete (oder fehlgeschlagene Faxe) werden unter
C:\Users\%username%\AppData\Roaming\T.38 Printer
gespeichert.
Während des Tests klappte es zunächst nicht, ein Fax erfolgreich zu versenden. Abhilfe schaffte das Heruntersetzen der Geschwindigkeit. Dazu auf der Registerkarte „Fax-Einstellungen“ die „Maximale Übertragungsrate“ von „14400“ auf „9600“ ändern. Dieses Problem ist vmtl. auf die Telekom zurückzuführen, da diese in ihrem VoIP-Netz keine Faxübertragungen oder T.38 unterstützt.
Der T.38 Printer ist nur während seiner Konfiguration oder Nutzung an der Telefonanlage oder beim Provider angemeldet.
Beim Gerätestatus der Askozia als auch in deren Log viel auf, das der T.38 Printer als nicht erreichbar angezeigt wird. Dies kann man ignorieren, da es sich wie im vorigen Abschnitt verhält.
Generell hilfreich bei der Fehlersuche ist das „T.38 Printer Log“. Das Tool kann über den entsprechenden Startmenüeintrag aufgerufen werden.
Vielen Dank an Herrn Andreas Teiß, dem Macher des T.38 Drucker, für die Unterstützung.
Bei einem Kunden schlugen mehrere Aufgaben mit der Meldung
"Die Anforderung wurde vom Operator oder Administrator zurückgewiesen. (0x800710E0)"
fehl.
Ein Blick in den Verlauf einer dieser Aufgaben brachte dann noch eine Meldung sinngemäss mit „Zeitplan nicht ausgeführt“ hervor. Eine Begründung blieb das System allerdings schuldig.
Sucht man nach dem Fehlercode so findet man schnell mögliche Workarounds wie z.B. unter „Bedingungen – Energie“ die Haken rauszunehmen oder
unter „Einstellungen“ den Haken zu setzen bei „Aufgabe so schnell wie möglich nach einem verpassten Start ausführen“.
Das half allerdings nicht. Erst ein Neustart des Servers brachte die Aufgaben wieder auf die Reihe. Auffällig ist, das am Wochenende zuvor die Zeitumstellung (Ende der Sommerzeit) stattfand, wenn da mal nicht was schiefgelaufen ist.
Fixing a failed scheduled task: The operator or administrator has refused the request 0x800710E0
Ein ehem. Kunde beschwerte sich bei uns darüber, das er keine Termine mehr mit seinem Outlook synchronisieren könne. Das wunderte uns, da wir zu der Zeit als wir den Kunden noch betreuten keinerlei Groupware o.ä. implementiert hatten. Besprochen und Angeboten wurde es freilich öfters, es kam allerdings nie zu einem Auftrag. Jedenfalls ein Blick in die Konten von Outlook 2013 offenbarte, das ein Office 365-ActiveSync-Account eingetragen wurde. Damit war zunächst zum einen geklärt das es nicht von uns eingerichtet wurde und damit erstmal Microsoft zuständig ist.
Microsoft wiederum hatte laut Kundenaussage den Support nach einem kurzem Blick auf das installierte Outlook 2013 mit den Worten beendet „das die Product ID bereits mehrfach verwendet wurde“. Auf den Hinweis, das die Original-PKC vorliegt und die Lizenz vorher zwar auf einem anderen Computer mal installiert war, aber vor der Nutzung auf dem jetzigen Computer entfernt wurde, ging man gar nicht erst ein. Darüber hinaus zeigte das Office an, das es aktiviert sei und auch im Microsoft-Konto des Kunden wurde die Lizenz angezeigt.
Somit waren wir sozusagen wieder an der Reihe. Je nach Office 365-Abo (bei Microsoft „Plan“ genannt) sind installierbare Office-Pakete für Windows oder Mac bzw. Apps für Tablets und Smartphones enthalten:
Privat-Anwender ab „Office 365 Home“, siehe https://products.office.com/de-de/compare-microsoft-office-products
Geschäftskunden ab „Office 365 Business“, siehe https://products.office.com/de-de/business/compare-office-365-for-business-plans
Jedenfalls war damit die Entscheidung einfach, das Office 2013 zu deinstallieren und durch die Version aus dem Office 365-Plan zu ersetzen. Nun sollte Microsoft keinen Grund mehr haben „zu meckern“ und auch wieder für den Support bzw. die Lösung des Sync-Problems zuständig sein.
Was allerdings „die Show“ vom Support sollte ist mir nicht ganz klar. Man könnte zum einen wie auch immer geartete Kompatibilitätsprobleme vermuten, gestärkt wird dieser Gedanke z.B. von Suchergebnissen wie diesen:
„In Office 2013 for Windows, activation produces "The user id or password is incorrect. Please try again." when attempting to sign-in to your Office 365 account The version of Office 2013 for Windows downloaded from within the campus software library is not compatible with UW-Madison's Office 365 implementation. If you attempt to install/run this version, it will return an error within the activation screen: The user id or password is incorrect. Please try again. Current Work Around - install the version Office 2013 available to you via . Uninstall Office 2013 (including OneNote/OneDrive). Follow these instructions to install the correct version of Office. Make sure to follow the steps to update your registry.“
Quelle: https://kb.wisc.edu/office365/page.php?id=33784
Das hat zwar vordergründig nichts mit ActiveSync zu tun, zeigt aber, das es mit lokalem installierten Office 2013 und Office 365 Schwierigkeiten geben kann. Zum anderem könnten böse Zungen auch „Marketing“ oder „Verkauf“ ins Feld führen.
Bei einer Kundin funktionierte der Firefox nicht mehr. Ganz gleich welche verschlüsselte Internetseite aufgerufen wurde, es erschien immer die Meldung „ssl_error_rx_record_too_long“.
Laut Kundin trat das Problem erst nach der Installation der aktuellen Windows Updates auf. Als Betriebssystem kommt Windows Vista zum Einsatz. Der erste Gedanke unsererseits war das es evtl. am Virenschutz liegen könnte. Mit verschiedenen Herstellern gab es bereits Schwierigkeiten in Verbindung mit HTTPS und SSL-Interception.
Kurzum wurde der installierte Avast Free Antivirus deaktiviert und schon klappte der Aufurf im Firefox wieder. Zur weiteren Eingrenzung wurde dann nur der Webschutz deaktiviert, soweit alles gut. Im weiteren Verlauf wurde nur der Scan von HTTPS deaktiviert, allerdings klappte dann der Zugriff immer noch nicht. Erwartet hatten wir das anders, bei anderen Virenscannern hatte dies i.d.R. geholfen. Selbst wenn im Avast beim Webschutz alle Haken raus sind, klappt der Zugriff nicht. Nach aktuellem Stand hilft nur das Deaktivieren oder Deinstallieren des Webschutzes.
Auf einer WAMP-Installation bestehend aus Windows Server 2012 R2, Apache Webserver, MySQL Server und PHP kam es seit ein paar Tagen zu Stabilitätsproblemen des Apache Webserver, dieser stürzte unvermittelt und unregelmässig immer wieder ab.
Durch den automatischen Neustart bzw. dadurch das nur Child-Prozesse abstürzten war zwar schnell ein Weiterarbeiten möglich, allerdings störten die Unterbrechungen und es kam immer wieder zu doppelten Einträge in die Datenbank.
Zunächst war die Vermutung gegeben, das es seit der Installation der Windows Updates vom Oktober 2016 zusammenhängt, da zumindest gefühlt seit diesem Zeitpunkt die Probleme auftraten. Gestützt wurde dieser Eindruck vom „php_errors.log“, das Fehler seit dieser Zeit aufzeigte. Dort fanden sich Einträge wie z.B.:
[14-Nov-2016 17:56:22 Europe/Berlin] PHP Fatal error: Wrong parameters for Exception([string $exception [, long $code [, Exception $previous = NULL]]]) in C:\Apache24\htdocs\osticket\include\class.orm.php on line 1063 [14-Nov-2016 17:56:31 Europe/Berlin] PHP Warning: mysqli::query(): (HY000/6): Error on delete of 'C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\#sqlb5c_1bc2_1.MYI' (Errcode: 13 - Permission denied) in C:\Apache24\htdocs\osticket\include\mysqli.php on line 165
Stutzig machte uns vorallem die „Zugriff verweigert“-Meldung, ein direktes Löschen der temporären Datein unter
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp
funktionierte ohne Probleme. Parallel dazu stellte sich heraus, das die Datensicherung des MySQL mittels „mysqldump“ fehlschlug:
mysqldump -u<BENUTZERNAME> -p<KENNWORT> <DATENBANKNAME> > mysqldump.sql Warning: Using a password on the command line interface can be insecure. mysqldump: Couldn't execute 'show fields from `ost_api_key`': Error on delete of 'C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\#sqlc44_c2_f.MYI' (Errcode: 13 - Permission denied) (6)
Da die Probleme unregelmässig auftraten wurde zunächst auf Timing-Schwierigkeiten getippt, zum Test wurde der Virenschutz „G Data Business Antivirus“ deaktiviert, daraufhin traten keine Abstürze oder sonstige Fehlermeldungen mehr auf.
So wie es nach weingen Stunden aussieht, genügt es den Ordner
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp
als Ausnahme im Virenschutz zu definieren.
