Zur Verwaltung des hMailServer’s steht per Standard der Administrator zur Verfügung. Möchte man Aufgaben verteilen oder z.B. pro Mail-Domäne einen Administrator verwenden, so kann das einfach über den „Administration level“ des jeweiligen Benutzers gesteuert werden. Somit eignet sich der hMailServer für mehrere Firmen, Mandanten oder im Bereich des Web-Hosting für Kunden.

Am Beispiel des PHPWebAdmin, der Web-Oberfläche von hMailServer zur Verwaltung, sieht das wie in diesem Screenshot aus:

Wird ein neues Konto angelegt, so steht der Level auf „User“. Alternativ kann man festlegen, das dieser Benutzer die Domäne oder den Server verwalten kann.

Keine Sorge: Ein Domänen-Admin kann keinen Server-Admin anlegen, auch wenn die mögliche Auswahl das zunächst vermuten lässt. Stellt man ein höheres Level ein, als das man zur Verfügung hat, so springt der „Administration level“ auf „User“ zurück.

Was das Verwalten von Regeln (Rules) betrifft, so kann dies über die „config.php“ des PHPWebAdmin gesteuert werden, allerdings sollte dies gut überlegt sein, da unter Umständen Einstellungen getroffen werden können, die zu Mail-Verlust oder Endlosschleifen führen.

Möchte man Microsoft’s Office 2010 telefonisch aktivieren, so wird seit geraumer Zeit im Assistenten angezeigt, das diese Form der Freischaltung nicht mehr angeboten wird, die entsprechende Hotline-Rufnummer wird zudem nicht mehr angezeigt.

Eine telefonische Aktivierung ist dennoch möglich. Man kann wie bisher unter folgender Nummer

0800 28 48 283 (Deutschland)

anrufen. Alternativ gibt es noch die Rufnummer

089 244 450 93 (Deutschland)

Letztlich kommt man an der gleichen Stelle raus.
Nicht verwirren lassen darf man sich vom Sprachmenü, das zwischenzeitlich auch mal von Windows XP spricht. Zudem ist etwas Zeit nötig, i.d.R. benötigt man um die 5-6 Minuten pro Aktivierung (ohne SmartPhone-App).

Ein Dauerbrenner: Das Herunterfahren von Windows kann unter Umständen mehrere Minuten in Anspruch nehmen. Bei einem Kundengerät dauerte dies sogar erheblich länger als ein paar Minuten.

Es kann viele Gründe geben, warum dies so ist, wie z.B. Windows Updates, Virenscan, Abmelde-/Herunterfahren-Skripte, usw. Zwei davon können sein, das Dienste zu lange brauchen um beendet zu werden oder konfiguriert wurde, das die Auslagerungsdatei beim Herunterfahren geleert werden soll:

In der Registry können folgende Werte schnell überprüft und ggf. geändert werden:

• „HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout“ steht ab Werk auf „20000“ (Millisekunden, sprich 20 Sekunden). Diesen Werte kann man z.B. auf fünf Sekunden („5000“) verkleinern.
• „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown“ steht ab Werk auf „0“, also Inaktiv. Steht dort eine „1“ wird die Auslagerungsdatei beim Herunterfahren geleert, was wiederum einige Zeit in Anspruch nimmt.

Beim Kundengerät war beides verstellt, statt 20 Sekunden waren dort 200 Sekunden eingetragen und das Leeren der Auslagerungsdatei war aktiviert. Nachdem beides geändert wurde, fährt der Computer nun in gut 17 Sekunden herunter.

Quellen

Microsoft TechNet – WaitToKillServiceTimeout

Microsoft Support – How to Clear the Windows Paging File at Shutdown

Möchte man in Erfahrung bringen, wie lange der Computer zum Hoch- oder Herunterfahren benötigt, kann man sich mit einer Stoppuhr davor setzen oder auf Protokolldaten zurückgreifen.

Windows erfasst in den Ereingnisprotokollen unter „Anwendungs- und Dienstprotokolle – Microsoft – Windows – Diagnostics-Performance – Betriebsbereit“ Einträge die das Hochfahren (ID: 100) oder Herunterfahren (ID: 200) betreffen. Um aus dieser Zahl der Einträge den Durchschnitt zu ermitteln, kann man auf ein Skript der PC-Welt zurückgreifen:

So beschleunigen Sie den Windows-Start – Hochfahren in 3 Sekunden

Ab Punkt „1.1 Bootzeiten im Windows-Ereignisprotokoll auswerten“ wird auf das Ereignisprotokoll und das Skript eingegangen. Das Skript kann direkt unter

PC-WELT-Performance

heruntergeladen werden. Anbei ein Screenshot von meinem Notebook:

Mein Computer (Lenovo ThinkPad T410, Intel Core i5 M560, 8GB DDR3, Samsung SSD 840 Pro 240GB, Windows 8.1 Pro x64) benötigt also im Schnitt ca. 62s bis er weitestgehend betriebsbereit ist. Die relativ lange Hoch-/Herunterfahrzeit gegründe ich mal mit Windows Updates, da das i.d.R. die einzige Situation ist, bei der das Notebook neu gestartet wird. Folglich wird in der Zwischenzeit sehr viel „Energie sparen“ (d.h. Zuklappen/Aufklappen) genutzt.

Möchte man mehr als die vergangenen 20 Hoch-/Herunterfahren-Zeiten mitteln, so kann das Skript leicht geändert werden:

• Die Datei „PC-WELT-Performance.vbs“ editieren.
• Nach „/count:20“ suchen und dieses z.B. durch „/count:100“ ersetzen.

Am Beispiel eines fünf Jahre alten Windows 7-Notebooks (Core i5, 8 GB DDR3) mit 1 TB klassischer Festplatte sieht das Ergebnis so aus:

Vor der Optimierung (Hinweis: 20 erfasste Ereignisse):

Nach der Optimierung (Hinweis: 100 erfasste Ereignisse):

Optimierung heisst in dem Fall, der Kunde monierte, das sein Notebook früher (wann auch immer das gewesen soll sein, eine genaue Angabe blieb er schuldig) in 30 Sekunden hochgefahren wäre. Wir haben dann zunächst die Hardware als auch das Dateisystem überprüft (alles ok), Datenträgerbereiningung und Defragmentierung durchgeführt, div. Autostart-Programme und Dienste deaktiviert, Treiber aktualisiert, Windows Updates repariert (lief seit sechs Monaten nicht mehr erfolgreich) und installiert, Virenscanner für langsame Computer konfiguriert (G Data Internet Security) und div. Tools zur Analyse und Optimierung des Startverhaltens laufen lassen (unter anderem WPT).

An „Boot-Zeit“, „Main Past Boot Time“ und „Boot Post Boot Time“ kann man erkennen, das sich etwas geändert werden.

Auf die vom Kunden angegebenen 30 Sekunden sind wir dennoch nicht gekommen. Schätzungsweise liegt ein Missverständnis oder Irrtum vor. Aus dem Standby ist das kein Problem, aber aus dem Kaltstart in dieser Konfiguration eher unwahrscheinlich (frisch installiertes Windows ohne Programme und Virenschutz auf dieser Hardware vielleicht, die Erfahrung sagt allerdings etwas anderes, 1TB Notebook-Festplatten sind nicht gerade die schnellsten).

Mit Visual Syslog Server for Windows steht ein kleiner, schneller und dennoch mächtiger Syslog Server zur Verfügung. Das Programm ist schnell installiert und kann quasi sofort verwendet werden.

Auf der Gegenseite muss nur eingestellt werden, das zum Visual Syslog Server die Protokolldaten geschickt werden sollen. Weiter kann man Ereignisse bei bestimmten Log-Meldungen auslösen lassen und es lässt sich die Ansicht filtern. Ideal also für die Fehlersuche oder -analyse. Im Screenshot sind z.B. Meldungen eines Switches zu sehen:

Zugegeben „link up/down“-Meldungen sind nun nicht allzu spannend (wenn sie zum Ein-/Ausschaltzeitpunkt von Netzwerkgeräten passen). Interessant wird es z.B. bei „warm-“ oder „cold-reset“-Einträgen, wenn diese ungeplant erscheinen kann das ein Hinweis auf Abstürze des Switches oder Stromversorgungsprobleme sein.

Leider läuft Visual Syslog Server nicht als Systemdienst, folglich muss immer ein Benutzer angemeldet und das Programm gestartet sein. Für zeitlich befristete, vorübergehende Situationen wie in diesem Szenario während einer Fehlersuche ist das durchaus in Ordnung. Für langfristige Installationen sollte man sich eher eine andere Lösung aussuchen.

Je nach Dauer und Umfang der Protokolldaten können die lokalen Dateien des Syslog Servers recht umfangreich ausfallen, daher sollte der Speicherplatz im Auge behalten oder Protokolle regelmässig gelöscht oder überschrieben werden.

Nach der Installation und den üblichen Windows Update-Runden auf einem neuem Windows Server 2016 viel mir folgendes zwischen „Updateverlauf“ und „Updateinstellungen“ ins Auge:

Ehrlich Microsoft, muss das sein? Man fragt sich allmählich, wofür man Geld bezahlt, wenn jetzt sogar (mehr oder weniger) Werbung auf einem Server erscheint. Erst kürzlich gab’s die Meldungen zu OneDrive-Werbung unter Windows 10:

heise online – Windows 10: Berichte über OneDrive-Werbung im Datei-Explorer

„Schlimm genug“, das man die Telemetrie nicht vollständig deaktivieren kann (ausgehend von der Standard-Ausgabe des Servers) und das Xbox-Dienste installiert sind:

Eine Neukundin brachte ihr Notebook zu uns mit der Aussage, das dieses sehr langsam sei. Sie hätte es vor drei Monaten (nicht bei uns) erworben und weil es so lahm wäre, hätte es bislang hautpsächlich im Schrank gelegen. Nun solle es für die Arbeit reaktivert werden.

Ein kurzer Blick auf die installierten Programme brachte diese Liste (jenseits der üblichen Verdächtigen) hervor:

AVG PC TuneUp, PC Reviver, WinZip Trial, WinZip Malware Protector, McAfee Life Safe Trial, Driver Finder, WebDiscover Browser, AVG Zen, Yahoo Powered, ByteFence Anti-Malware, Avast Free, Interstat, Registry Reviver, Driver Reviver

Dazu kommt eine 500 GB Festplatte mit 5400 RPM und Probleme mit Windows Updates (Stichwort: Endlosschleife). Alles in allem kein Wunder, das es nicht so recht laufen mag.

Die Deinstallation dieser ganzen „tollen“ Anwendungen dauerte etwas und nach einem Reset der Windows Updates geht’s nun besser. Ideal wäre noch gewesen, die lahme Festplatte durch eine SSD zu ersetzen, aber das kostet ja Geld.

Spannend war zudem die Aussage der Kundin, das sie nichts für einen Virenschutz bezahlen möchte, da man diesen, wenn überhaupt, nur einmal im Jahr benötigt. Ich frage mich, worauf diese Annahme beruht. Ein Virenscan per Stick förderte zudem noch ein paar Schädlinge zu Tage. Dagegen halfen die zuvor installierten Scanner offensichtlich nicht. Diese Standen sich vermutlich gegenseitig auf den Füssen bzw. da es sich teilweise um Trial-Versionen handelte die zudem noch abgelaufen waren, konnten sie nichts ausrichten.

Unser Werkstatt-Notebook mit Windows 8.1 Pro verrichtet seit Jahren brav seinen Dienst. Die letzte Zeit viel es allerdings unangenehm durch Lüftergeräusche auf. Ein Blick in den Task-Manager und den Ressourcenmonitor offenbarte, das der Prozess „TiWorker.exe“ die Ursache des Übels ist. Dieser trieb die Prozessor- und Festplatten-Auslastung hoch.

Abhilfe schaffte bei uns die Kombination aus folgenden Lösungsvorschlägen:

• Unter „C:\Users\%username%\AppData\Local\Packages\WinStore_cw5n1h2txyewy\LocalState“ den Ordner „Cache“ umbenennen und durch einen neuen leeren Ordner gleichen Namens ersetzen.
• Unter „Systemsteuerung – Problembehandlung – System und Sicherheit – Probleme mit Windows Update beheben“ anklicken und durchlaufen lassen.

Letzteres fand bei uns einen Datenbankfehler und behob ihn, seitdem ist wieder Ruhe.

Quellen:

Microsoft Community – hohe Prozessorlast (tiworker.exe)

wintips.org – How to fix TiWorker.exe high Disk Usage problems on Windows 10, 8.1, 8

Bei uns streikte ein snom 720 nach einem Firmware-Update, es startete schlichtweg nicht mehr, es leuchteten alle Tasten und auch mal kurz die Hintergrundbeleuchtung des Displays und das war’s.

Die Suchmaschine der Wahl führte zu diesem Treffer:

snom – Wiki – Firmware/Update/TFTP Update/de – TFTP-Update für Snom7x0 mit Pumpkin

War taten wie beschrieben und nun läuft’s wieder.

In der kleinsten Ausgabe des Microsoft SQL Server fehlt die Möglichkeit, eine Datensicherung zu automatisieren. Dieses kann man z.B. mit diversen Skripten tun oder ganz bequem mit einem Tool.

Bei der Einführung von JTL-Wawi kam unter anderem das Thema Datensicherung auf. In der Dokumenation wird darauf hingewiesen und für die Express-Ausgabe des MS SQL Server auch gleich eine Möglichkeit genannt:

SQLBackupAndFTP

Für ein simples regelmässiges Backup reicht die Free Version vollkommen aus. Das Tool ist leicht zu bedienen und schnell einsatzbereit. Gegenüber so mancher Skript-Lösung gefällt die ausführliche Benachrichtung über Erfolg oder Misserfolg der Datensicherung.

Mit dem Sensor „Asterisk Gesundheit“ (derzeit im Beta-Stadium) besteht die Möglichkeit mittels des AMI (Asterisk Manager Interface) entsprechende VoIP-Telefonanlagen wie z.B. die Askozia PBX zu überwachen.

Voraussetzung ist ein aktiviertes AMI mit konfiguriertem Benutzer, anschließend kann via OCC der Sensor angelegt und konfiguriert werden.

Der Screenshot zeigt einen aktuellen Status. Deutlich zu erkennen (trotz „Zensur“) ist der Ausfall eines Providers („Error“ bzw. „UNREACHABLE“). In diesem Fall ist der erste Provider-Eintrag quasi der Haupteintrag, das den gesamten Zustand dieses Providers angibt. Die darunterliegenden Einträge beziehen sich auf die einzelnen Rufnummern, die über diesen Provider laufen.

In diesem Fall handelt es sich um die Deutsche Telekom die (mal wieder) eine Störung in ihrem Telefonie-Netz hat.

USB 2.0 verrichtet nach wie vor Tapfer seinen Dienst, möchte man allerdings größere Datenmengen wie zum Beispiel bei einer Datensicherung bewegen, so ist dies recht langsam.

Konkret ging es im vorliegenden Fall auf dem dieser Beitrag beruht um einen älteren Server (Fujitsu-Siemens Econel 100 S2 mit Windows Server 2008 R2) bei dem USB 3.0 nachgerüstet werden soll, damit die Datensicherung schneller von statten geht.

Eine solche Maßnahme kann vorallem dann Sinn ergeben, wenn PCs oder Server noch nicht ausgetauscht werden können oder sollen und das Zeitfenster für die Datensicherung relativ klein ist.

Beim Aufrüsten von USB 3.0 mittels PCI-Express-Karte muss zum einem geprüft werden, ob die Hardware kompatibel ist, d.h. entsprechende Steckplätze auf dem Mainboard vorhanden und frei sind als auch das es Treiber für das verwendete Betriebssystem gibt. Nicht jede Karte liefert Treiber für Windows Server mit. Nach kurzer Suche wurden wir bei Lindy fündig. Für die „USB 3.0 Karte Lite, 2 Port, PCIe“ (Artikelnummer 51118) liefert der Anbieter Treiber von Windows XP bis einschließlich 8 und Windows Server 2003 bis 2008 R2 (auf der Artikelseite ist sogar von Windows 2000 und MacOS die Rede).

Um vorab zu prüfen, ob alles passt bevor es beim Kunden „ernst wird“, wurde ein baugleicher Server (wurde uns von einem anderen Kunden mal überlassen) samt der erwähnten Karte getestet. Dieser wurde frisch mit Windows Server 2008 R2 Standard (Evaluierungsversion) installiert und mittels Windows Updates und Treiber der Herstellers auf den aktuellen Stand gebracht. D.h. das System ist quasi jungfräulich und es sind nur ca. 20 GB belegt. Anschließend wurde mittels CrystalDiskMark und Drive Snapshot getestet. Anbei die Ergebnisse:

Lokale Festplatte:

USB 3.0-Festplatte via USB 2.0 angeschlossen:

USB 3.0-Festplatte via USB 3.0 angeschlossen:

Zeit für die Vollsicherung via Drive Snapshot:

• USB 2.0 – 4:14 Minuten
• USB 3.0 – 2:35 Minuten

Soweit schonmal ein paar Unterschiede, allerdings eben nur Testumgebung. Live und in Farbe wird es vermutlich nochmal etwas anders aussehen. Sobald die Karte beim Kunden verbaut ist und es (hoffentlich) Feedback gibt, wird der Beitrag ergänzt.

Seit neuestem ist unser Windows 8.1-Notebook der Meinung, USB-Massenspeicher wie Sticks oder Festplatten nicht mehr per Boardmittel auswerfen zu lassen oder anders ausgedrückt: Die entsprechenden Einträge beim Infobereich-Symbol als auch im Explorer fehlen.

Recherche und Tests von verschiedenen Lösungsvorschlägen halfen bislang nichts, als Plan B wurde nach anderen Wegen gesucht und der USB Disk Ejector gefunden. Ein kleines Tool, das ohne Installation daherkommt und macht was es soll.

Manchmal begegnen einem nicht mehr verwendete bzw. nicht verbundene Netzlaufwerke, die sich nicht einfach trennen oder löschen lassen. So geschehen auf unserer POS-Kasse. Weder via Explorer noch „net use * /d“ liesen sich die Laufwerke sozusagen rausschmeissen, sie waren echt hartnäckig.

Ein Blick in die Registry half nichts, an den bekannten Stellen waren schlicht keine Einträge zu finden oder überhaupt vorhanden. Ein schneller Blick ins MCSEboard lieferte dann einen passenden Treffer:

Nichtverbundenes Netzlaufwerk entfernen

Der Beitrag #8 von „schnarchzapfen“ (Geschrieben 17. Juni 2008 – 11:57) führte auf die richtige Spur. Gemeint ist: Die Netzlaufwerke wurden vermutlich als Benutzer „System“ verbunden. Bevor nun allerdings ein Dienst, eine Aufgabe etc. erstellt wird, wurde kurzerhand via PsExec eine Eingabeaufforderung im System-Kontext geöffnet:

psexec \\localhost -s cmd

Hinweis: Der Befehl muss als Administrator bzw. in einer Eingabeaufforderung mit erhöhten Rechten ausgeführt werden.

Mittels „net use“ waren dann die „verwaisten“ Netzlaufwerke auch gleich aufgelistet und wiederrum mit „net use * /d“ sofort gelöscht.

Ach was war das wieder mal herrlich, quasi pünktlich zum Wochenende „streikt“ erneut die Telefonie bei der Telekom. Nun, so kann man auch einen ruhigen (Nach-)Mittag erleben.

Historie

Kurz nach 11:00 Uhr am Freitag, den 05. Mai 2017 meldete der Asterisk-Sensor von Server-Eye den Ausfall des Telekom VoIP-Providers an unserer Telefonanlage. Da der Sensor sich noch im Beta-Stadium befindet zur Sicherheit den Status in der Telefonanlage überprüft und „rot gesehen“ (wie war das doch gleich: „rot ist tot“ ). Im Log passend dazu jede Menge „timeout“-Meldungen. Schön.

Gegenprüfung bei allestörungen.de (Störungskarte vom 05. Mai 2017), oh ja, ein sprunghafter Anstieg der „Negativ“-Meldungen ab 11:00 Uhr. Man ist also nicht alleine. Stichprobenartig div. Geschäftskunden mit Telekom-Anschluss überprüft, grob übern Daumen gepeilt ca. zwei Drittel ohne Telefon. Super! Kunden via E-Mail über den Ausfall informiert, die Reaktionen erwartungsgemäss gemischt, von „ach deswegen ist es gerade so ruhig“ bis „sofort beheben, ganz gleich wie“, „bei der Telekom druck machen“, „wer zahlt das“ (gemeint ist damit den Ausfall, entgangene Aufträge, Stress mit Kunden/Lieferanten/Mandanten/…) usw.

Hotline kontaktieren zwecklos

In solchen Momenten beim Anbieter eine Störung zu melden ist erfahrungsgemäss meist sinn- wie auch zwecklos. Wenn man nach entsprechender Wartezeit überhaupt durchkommt, können einem die Hotliner sowieso nicht helfen. Ganz im Gegenteil, ggf. bekommt man noch erzählt, es läge am Router oder es liege keine Störung vor.

Einzig sinnvoll ist es meist nur dann sich das anzutun, wenn man einen entsprechenden Anschluss respektive Tarif hat, bei dem geregelt ist, das man entschädigt wird. Das betrifft dann eher die größeren Geschäftskundenanschlüsse (Standleitung à la CompanyConnect z.B.)

Via Kundencenter den Anschluss prüfen und SMS-Benachrichtigung einstellen

Bei Grossraumstörungen geht nicht nur schnell die Hotline in die Knie, sondern ggf. auch das Kundencenter. Das war gestern zeitweise so, keine Anmeldung möglich oder wenn doch, ein unbrauchbares Interface. Schafft man es dann doch, ist bei der Prüfung des Anschlusses zu beachten, das man mit der Hauptrufnummer arbeitet. Für andere Rufnummern des Anschlusses kommt in der Regel sinngemäss ein „alles ist in bester Ordnung“ zurück.

Ein Lichtblick, wenn denn eine Störung attestiert wird, ist die mögliche SMS-Benachrichtigung wenn die Störung behoben ist. Aber Achtung: Die SMS wird nur im Zeitraum 08:00 bis 21:00 Uhr versendet. Selbst wenn mitten in der Nacht die Störung behoben ist, erfährt man das von der Telekom erst frühestens um 08:00 Uhr.

„Garantierte Entstörung innerhalb von acht Stunden“ – Ja ja, …

Bei den Geschäftskunden-Tarifen wird gerne damit geworben, das innerhalb von acht Stunden Störungen behoben werden. Dieses „Versprechen“ wurde alleine in den vergangenen Monaten gleich mehrfach gebrochen. Im aktuellen Fall bestand die Störung vom 05. Mai 2017 ca. 11:00 Uhr bis 06. Mai 2017 ca. 00:10 Uhr (zumindest in unserer Region (PLZ-Bereich 63xxx). Spricht man die Geschäftskundenbetreuung darauf an, bekommt man in der Regel zu hören, das es nicht schneller ging („es ist halt so“), das sich das ggf. nur auf den Anschluss aber nicht auf die Telefonie bezieht usw.

Fragen nach, im weitesten Sinne, Schadenersatz (man könnte ja imho einen Teil der Grundgebühr gutschreiben, da ja der Tarif ist vollwertig nutzbar war) laufen der Erfahrung nach meist ins Leere oder führen zu einem „geht nicht, gibts nicht, sie könnten sich an Stelle xyz wenden, aber es besteht wenig Hoffnung, …“.

Fazit

Es war mal wieder ein Erlebnis. Ich hoffe, das die Telekom ihre VoIP-Plattform in den Griff bekommt. Das ab und an mal etwas ausfällt wäre ja noch ok, aber die letzte Zeit ist das weniger gut. Plan B kann nach wie vor sein, einen zweiten VoIP-Telefonie-Anbieter zu verwenden, das man ggf. via Anrufweiterschaltung bzw. zweiter Rufnummer erreichbar ist bzw. selbst telefonieren kann. Dabei ist zu beachten, das der Zweit-Anbieter nicht gerade die Telekom als Partner verwendet, sonst hat man dabei nichts gewonnen.

Update 06.05.2017 – 08:30 Uhr

Punkt 08:15 Uhr kam die SMS, das nun alles wieder in Ordnung sei.

Samstag, der 06.05.2017, 07:52 Uhr, Mail von meinem Webspace-Provider, Virenfund im Blog. Wirklich? Ernsthaft? Nein! False-positive, again.

Oder auch:

• The return of the false-positive
• False-positive – Part II
• False-positive – The second arrival

Ok, Spass wobei eher Galgenhumor beseite. Das Ganze hatten wir schonmal, ist aber bereits eine Weile her:

Kompilierte AutoIt-Skripte und die Virenscanner

Jedenfalls wurden diverse ZIP-Archive von den Drive Snapshot-Rettungsbeiträgen mit „Win.Trojan.Generic-6299811-0“ als infiziert gemeldet und vom Virenscanner umbenannt. Zur Sicherheit die Archive und deren Inhalt überprüft, alles ok und im Original-Zustand, folglich keine Infektion. Den Support kontaktiert, das es ein False-positive ist und gefragt wie es weiter gehen kann/soll/muss. Die Antwort relativ ernüchternd aber nicht ganz hoffnungslos:

Zum Einsatz kommt ClamAV. Nun ein Zitat vom Support:

„Sie haben die Möglichkeit, die FalsePositives unter https://www.clamav.net/reports/fp zu melden und zu hoffen, das diese aus der Liste entfernt werden.“

Hoffen? Ah ha. Klingt naja… Welche Datei genau „meckert“ der Virenscanner eigentlich an. Also eines der angeblich infizierten Archive hergenommen, entpackt und erstmal die AutoIt-Skripte und deren „Exen“ bei VirusTotal gescannt. Dort meldet ClamAV allerdings das alles gut sei (ein paar andere Scanner melden vmtl. auf Basis von Heuristik das es Malware sein könnte, sind aber in der Minderheit). Ja wie nun?! Das Ganze Archiv gescannt und prompt den „Trojan.Generic-blablabla“ erhalten. Hm, nun gut. Jede einzelne Datei gescannt, kein Treffer. Äh, ja, hm.

Auf einer Testmaschine mal schnell ClamWin installiert und den Inhalt eines der Archive gescannt:

ds-update_x86.exe: Win.Trojan.Generic-6299811-0 FOUND

Also doch eine „AutoIt-Exe“. Kurios ist allerdings, das bei VirusTotal mit der selben Datei kein Treffer bei ClamAV gelandet wird. Es hängt vmtl. an der Version der Virensignatur:

main: 57, daily: 23361, Updated: 07:02 06 Mai 2017
bzw.
main.cvd (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd (version: 23361, sigs: 2064603, f-level: 63, builder: neo)
bytecode.cvd (version: 297, sigs: 58, f-level: 63, builder: anvilleg)

(Quelle: ClamWin)

Bei VirusTotal sieht man leider nur „20170506“, wenig hilfreich in diesem Moment. Ein weiterer Scan bei VirusTotal, gut eine halbe Stunde später und mit viel Geduld (weil’s gerade lahmt), liefert dann doch einen Treffer:

Antivirus | Ergebnis | Aktualisierung
ClamAV | Win.Trojan.Generic-6299811-0 | 20170506

Schön.

Wie geht es weiter?

Abgesehen vom Melden der False-positives besteht die Möglichkeit, ein Verzeichnis beim Webspace-Anbieter vom Scan ausschließen zu lassen. Das ist zwar eine Option, aber um ehrlich zu sein, möchte ich das nicht, denn wird der Webspace doch mal kompromitiert, wäre das ja ein wunderbarer Verteilungsort, ferner ist mir der Aufwand zu hoch, jedesmal wenn ein Progrämmchen online gestellt werden soll, darauf zu achten, das es an einem bestimmten Ort liegen muss. Man müsste es außerhalb von WordPress platzieren, also nix mit mal schnell auf „Dateien hinzufügen“ klicken, dann jenseits vom Browser noch einen FTP-/SCP-Client verwenden, … man ist halt bequem oder verwöhnt.

Parallel dazu könnte man natürlich hergehen und die betreffenden Skripte neu kompilieren, aber wie lange hält das dann? Ganz gleich, wie man es nun angeht, um Arbeit kommt man nicht drum herum. Die umbenannten Archive müssen „zurückbenannt“ oder neu hochgeladen werden damit die bestehenden Links wieder funktionieren oder neu kompilieren/packen/mit Kennwort schützen/… und die Links aktualisieren.

Jedenfalls habe ich jetzt erstmal Meldung erstattet. Mal sehen, ob da was zurückkommt. Parallel dazu werde ich auf der Testmaschine mit den jeweils neuen Clam-AV-Signaturen prüfen. Die Archive umbenennen geht im Moment nicht (trotz Besitz- und aller anderen Rechte, Supportanfrage läuft). Neu hochladen macht aufgrund der noch aktuellen Signatur wenig Sinn, würde gleich wieder geblockt/umbenannt/sonstwie gesperrt werden. Also erstmal abwarten.

Update 06.05.2017 – 10:58 Uhr

Die Dateien konnten nun umbenannt werden, die Links bzw. Downloads sollten damit wieder funktionieren.

Update 06.05.2017 – 15:34 Uhr

Die Hoffnung, das man schnell aus der Sache rauskommt schwindet. Mit der neuen Signatur nach wie vor Falsch-Meldung.

daily.cld (version: 23362, sigs: 2065037, f-level: 63, builder: neo) (Updated 15:02 06 Mai 2017)

Bislang zudem keinerlei „Lebenszeichen“ von der False-positive-Meldung, scheinbar gibt es nicht mal eine automatische Eingangsmail o.ä.

rsync ist unter anderem für den Abgleich von nur innerhalb einer Datei geänderten Daten (aka Delta-Kodierung/-Abgleich) für allem für die Synchronisation oder Datensicherung via Netzwerk oder Internet attraktiv. Für den Betrieb unter Windows gibt es verschiedene fertige Pakete, die das Tool zusammen mit den benötigten Cygwin-Teilen und ggf. einer grafischen Oberfläche bündeln.

Mit wenig Einarbeitung lässt sich das Tool bequem z.B. via Skript, Eingabeaufforderung oder als Aufgabe nutzen. Im Netzwerkbetrieb unter Windows (lokal wurde nicht getestet) fällt allerdings schnell auf, das die verfügbare Bandbreite bei weitem nicht genutzt werden.

Das rsync unter Windows durch die Emulation von Cygwin leidet ist Prinzip-bedingt klar. Aber das es sich so drastisch auswirkt das z.B. beim ersten Kopieren einer Datei im Gigabit-LAN gerade mal im Durchschnitt nur 15 Mbit/s übertragen werden tut schon fast weh. Recherchiert man ein wenig, findet man noch Angaben von um die 40 Mbit/s, das ist zwar besser aber auch nicht gerade der Hit. Scheinbar war es mit früheren Cygwin-Versionen wohl mal besser, aktuell ist leider „kein Land in Sicht“.

Acrosync – Ein nativer rsync-Client für Windows

Die Auswahl an nativen rsync-Clients für Windows ist gelinde gesagt überschaubar. Es findet sich bei Sourceforge ein älteres, offenbar nicht mehr gepflegtes Projekt, das über das Alphastadium nicht hinweis kam und dann ist da noch Acrosync.

Anbei ein Screenshot von einem Testaufbau mit einem Windows Server 2012 R2 Standard, Acrosync 1.16 (Trial) und als Gegenstelle kommt ein Debian 8.7 Jessie, das als rsync-Server (Daemon), agiert zum Einsatz

Wie man am Task-Manager unschwer erkennen kann kommt man locker über die 15 Mbit/s hinaus. Gesynct wird dabei eine virtuelle Maschine unter Hyper-V zum Debian basierten-Backupserver.

Nachfolgend ein paar Notizen eines kurzen Tests:

Pro:

• Profilverwaltung
• Läuft als Dienst
• unterstützt VSS
• Integrierte Aufgabenplanung
• integrierter SSH-Client
• Fortschrittsanzeige in der Fusszeile des Programs

Contra:

• Erzeug VSS-Fehler: 0x80070005
• Fehlende Statistik wie bei „rsync –stats“
• Nur rsync-Client, kein Server/Daemon

Acrosync gibt es außer für Windows zusätzlich für macOS und iOS sowohl mit Personal oder Commercial License.

Im Forum des Anbieters finden sich Hinweise auf einen Acrosync-Server:

Acrosync server

Client / Server

Aber die Einträge sind bereits Jahre alt. Wer weiß, ob da noch etwas kommt, wünschenwert wär’s allemal. Der Client hingegen wird nach wie vor gepflegt (letztes Update zum Zeitpunkt als der Beitrag geschrieben wurde: April 2017).

Windows-only Alternative

Wer nur mit Windows arbeitet und Wert auf Performance und den Delta-Abgleich legt, sollte sich Bvckup2 ansehen. Dabei handelt es sich zwar um ein kommerzielles closed-source Programm, dieses erfüllt seine Aufgabe (imho) außerordentlich gut.

Wer mehrere pfSense-Installationen betreut kommt schnell an den Punkt, an dem es eher unbequem wird sich zu jeder Installation verbinden und das Update mittels Web-Interface anstarten zu müssen. Schneller und automatisierbar geht dies mit einem Befehl.

Mittels „pfSense-upgrade“ (Gross-/Kleinschreibung beachten! Bordmittel) kann via ssh das Update bzw. Upgrade auf eine neue Version durchgeführt werden. ssh muss zuvor aktiviert werden:

pfSense – HOWTO enable SSH access

Via ssh verbinden, Punkt „8) Shell“ auswählen und folgenden Befehl ausführen:

pfSense-upgrade

Nach kurzer Zeit erscheint eine Abfrage, ob weitergemacht werden soll:

Reboot will be required!!
Proceed with upgrade? (y/N)

Möchte man direkt ohne weitere Abfrage das Upgrade durchführen, fügt man „-y“ an den Befehl an. Dabei wird das Upgrade ausgeführt und pfSense automatisch neu gestartet.

Der gesamte Vorgang kann z.B. unter Windows mittels plink als Skript automatisiert werden. In nachfolgendem Beispiel wird zunächst das Upgrade durchgeführt, dann fünf Minuten gewartet und anschließend ein neues selbst-signiertes Zertifikat generiert als auch eingebunden. Für diesen Beitrag wurde eine pfSense-Installation auf Version 3.4.3 aktualisiert und eine erforderliche Nacharbeit, gemeint ist das Zertifikat (Link), durchgeführt.

@echo off

plink.exe -ssh -l root -pw <Passwort> <IP> "pfSense-upgrade -y"
timeout /t 300
plink.exe -ssh -l root -pw <Passwort> <IP> "pfSsh.php playback generateguicert"

Bemerkung 1: Damit plink automatisiert ablaufen kann, muss einmalig eine Verbindung hergestellt und der Schlüssel werden.

Bemerkung 2: Unbedingt den Benutzer „root“ verwenden, mit „admin“ funktioniert es nicht.

Anbei die weiteren Optionen von „pfSense-upgrade“:

Usage: pfSense-upgrade [-46bdfhnRUy] [-l LOG_PATH] [-p SOCKET_PATH] [-c|-u|-i PKG_NAME|-r PKG_NAME]
        -4          - Force IPv4
        -6          - Force IPv6
        -b          - Platform is booting
        -d          - Turn on debug
        -f          - Force package installation
        -h          - Show this usage help
        -l          - Logfile path (defaults to /cf/conf/upgrade_log.txt)
        -p socket   - Write pkg progress to socket
        -R          - Do not reboot (this can be dangerous)
        -n          - Dry run
        -U          - Do not update repository information
        -y          - Assume yes as the answer to any possible interaction

The following parameters are mutually exclusive:
        -c          - Check if upgrade is necessary
        -i PKG_NAME - Install package PKG_NAME
        -r PKG_NAME - Remove package PKG_NAME
        -u          - Update repository information

Mit „-c“ kann auf Updates/Upgrades geprüft werden. Zum vorangehenden Testen kann „-n“ benutzt werden. Grundsätzlich sollten Upgrades nicht ungeprüft durchgeführt werden! Zumindest an einer Referenz-Installation zunächst den Vorgang testen, bevor man mittels Skript mehrere Installationen aktualisiert.

Ist Microsoft Office Starter 2010 oder eine andere Klick-und-Los- bzw. App-V-Anwendung installiert, kann es vorkommen, das die Datensicherung mittels Schattenkopie Fehlermeldungen erzeugt oder ganz scheitert.

Hintergrund ist das „ominöse“ Laufwerk Q:, auf dieses kann nicht direkt zugegriffen werden und verwendet zudem kein NTFS, aber letzteres wird von den Schattenkopien vorausgesetzt.

Bei einer Installation mit Windows 7 Professional 64-bit zusammen mit Office Starter 2010 und Drive Snapshot viel folgende Meldung im Ereignisprotokoll auf:

Abhilfe schafft eine kleine Änderung in der Registry:

• „regedit“ öffnen
• Zu

  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS\ServiceInclusions

• Eine neue Zeichenfolge mit dem Namen „VSS“ und dem Wert „swprv“ anlegen.
• Optional (Empfohlen): Neustart

Quelle

Microsoft Developer – Deutscher App-V Blog – App-V und VSS–Backup oder kein Backup…

Wenn der Speicherplatz auf Laufwerk C: langsam zur Neige geht und die Datenträgerbereinigung keine Abhilfe leistet, lohnt ein Blick auf das .Net-Framework.

Genauergesagt geht es um temporäre Dateien die die Laufzeitumgebung angelegt. Bei einem Kunden gab es nach der monatlichen „Windows-Update-Kur“ eines Windows Server 2012 R2 Foundation (Terra Miniserver) eine Speicherplatzwarnung. Nach einem eher ernüchternen Ergebnis nach div. Aufräumarbeiten fiel nach einem Durchlauf von TreeSize Free auf, das diverse Ordner unterhalb von „C:\Windows\assembly“ relativ umfangreich sind. Hauptsächlich betraf dies

C:\Windows\assembly\NativeImages_v2.0.50727_32\Temp
C:\Windows\assembly\NativeImages_v2.0.50727_64\Temp

Allen voran der „32-er“ Ordner hat es insich. Nach dem Zeitstempel der dort enthaltenen Dateien zu urteilen, wurden bzw. werden Dateien bei jedem Neustart des Servers erstellt. Alleine beim letzten Neustart umfasste dies gut 3 GB, alte Dateien werden offensichtlich nicht entfernt. So sammelte sich im Laufe der Zeit einiges an.

Das Problem scheint nicht unbekannt zu sein, eine genaue Ursache konnte zumindest zeitnah nicht ermittelt werden. Um wieder Platz zu schaffen, wurden alle älteren Dateien zunächst ausgelagert, bislang viel durch diese Massnahme keine Einschränkung auf. An manchen Stellen im Netz kann man Nachlesen, dass das Löschen des gesamten Ordnerinhalts unproblematisch sei, ob dies wirklich so ist, haben wir bislang nicht getestet.