Beiträge von fx.trix

  • Workaround gegen PrintNightmare blockiert den automatischen Ausdruck von eingehenden Faxen

    Hallo riawie,

    der Server ist neugenug und bekommt den s. g. Notfallpatch von Microsoft.

    Du kannst aber u. a. hier und hier nachlesen, dass ein vollständig gepatchter Server 2019 trotzdem weiter anfällig gegen den Exploit ist.

    RCE soll unter gewissen Umständen entschärft sein (wenn das System in den Standardeinstellungen läuft, die 'Point-and-Print-Einschränkung' also nicht aktiv ist) , aber die LPE steht wohl weiterhin offen. Mal abgesehen von den genannten Quellen, die den Patch grundsätzlich in Frage stellen. Daher möchte ich eigentlich momentan nicht auf den Workaround verzichten.

    Ich hoffe, trotz der aktuellen offiziellen Statements von MS, dass da noch nachgelegt wird. Bis dahin bleibt der Workaround aktiv, der auch normalerweise die bestehenden Druckfunktionen nicht behindert. Die Frage ist also, was macht der David-Server an der Stelle anders, dass die eingehenden Faxe nicht mehr automatisch ausgedruckt werden können, sonst aber das Druckgeschehen von dem Server aus nicht beeinträchtigt ist?

    Gruß

    fx.trix

  • Workaround gegen PrintNightmare blockiert den automatischen Ausdruck von eingehenden Faxen

    Hallo,

    habe kurz per Suche geschaut, aber keine einschlägigen Beiträge gefunden.

    Folgendes Verhalten stellt sich leider im Zusammenhang mit dem Workaround gegen PrintNightmare ein (dem User SYSTEM Änderungsrechte auf c:\windows\system32\spool\drivers verweigern):

    seit der Aktivierung werden eingehende Faxe nicht mehr wie vorgesehen automatisch ausgedruckt. Andere Druckoperationen auf dem Server funktionieren hingegen normal weiter. Nimmt man den Workaround zurück, holt der David-Server die ausstehenden Ausdrucke nach. In der Printque sind sie bis da aber nicht zu sehen.

    Ist das Verhalten bekannt? Kann man seitens David-Server irgendwie wieder um den PrintNightmare-Workaround darumherum arbeiten? Hat jemand eventuell eine Erklärung für dieses Verhalten des David-Servers?

    Gruß

    fx.trix

  • Sporadisch Fehlfunktion Fax mit Primux USB 2

    Nachtrag: mittlerweile scheint das Problem gelöst. Die Lösung bestand in unserem Fall in der Anpassung des ISDN-Protokolls auf dem S0-Port der TK-Anlage. Ich war leider nicht bei der Modifikation dabei und kann hier daher nicht die spezifischen Änderungen dokumentieren, aber wer so einen Primux USB 2 an einem internen S0 einer TK-Anlage angeschlossen hat und diese Hänger bekommt, kann ggf. dann in der TK-Anlage ansetzen.

  • Eingangsverarbeitung von Mails anhand von Header-Informationen (X-Spam)?

    Hallo,

    gibt es eine Möglichkeit ohne MIS, dass der David-Server als Spam klassifizierte Mails anhand von Header-Informationen über so etwas wie Verteilregeln in dafür angelegte Ordner verschieben kann?

    Hintergrund ist, dass wir kürzlich den Provider gewechselt haben und dort momentant nicht mehr die Möglichkeit besteht, den Betreff zu modifizieren, um entsprechende Mails auf diesem Wege zu identifizieren.

    Die Filter beim neuen Provider arbeiten recht gut, legen ihr Rating aber nur in den Headerdaten ab. Etwa in der Art:

    Code
    X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on 
X-Spam-Flag: YES
X-Spam-Level: *********
X-Spam-Status: Yes, score=9.4 ,required=5.0, tests=FREEMAIL_FORGED_REPLYTO,
    FROM_NOT_REPLYTO,HTML_IMAGE_RATIO_04,HTML_MESSAGE,MIME_HTML_ONLY,
    RDNS_NONE,RELAYCOUNTRY_GOOD,SPF_HELO_SOFTFAIL,SPF_NEUTRAL,
    TO_NO_BRKTS_NORDNS_HTML

    Wenn man das Ergebnis schon hat, muss man ja nicht unbedingt noch mal prüfen und extra für MIS zahlen, meiner Meinung nach.

    Gruß

    fx.trix

  • Sporadisch Fehlfunktion Fax mit Primux USB 2

    Hallo,

    sporadisch hängt sich bei uns die Primux USB 2 Box weg (bisher noch nicht länger als 14 Tage bis zum nächsten Hänger). Vom Server aus gesehen sieht alles gut aus, TLDs laufen, Gerätemanager ok, keine Einträge im Ereignisprotokoll. Prüft man mit dem Tool von Gerdes ("Verbindungstest"), kommt die Fehlermeldung "Es war kein Zugang zum ISDN-Netz möglich. Dies kann mehrere Gründe haben: Die Kabelverbindung ist beschädigt / Ihr ISDN-Anschluss ist derzeit überlastet".

    Der David-Server wurde kürzlich von Blech (W2K8 R2) auf Blech (W2K16) migriert. Leider können wir die vorher eingesetzte Dialogic DIVA BRI-2 nicht mehr einsetzen. PCIe wäre zwar im neuen Server noch vorhanden, aber der Hersteller erteilt keine Freigabe für den alten PCIe-Standard der DIVA.

    Daher sind wir den Weg zur kostengünstigen Primux USB 2 gegangen, nicht zuletzt aufgrund der Infos hier im Forum.

    Die Primux-Box hängt an einem internen S0 einer Panasonic TK-Anlage (wie die DIVA vorher auch). Ein TLD läuft RX/TX einer nur RX.

    Im Monitor des jeweiligen TLD tauchen öfter mal "DISCONNECT_IND (0x3304) Another application got that call" auf. Das scheint kein Problem zu sein. Sieht fast so aus, als ob sich die TLDs da gegenseitig Konkurrenz machen. Aber wenn die Box sich weghängt, dann findet sich auch typisch "DISCONNECT_IND (0x3303) Protocol error layer 3".

    Hat hier wer ähnliche Erfahrungen gemacht oder vielleicht sogar eine Lösung für dieses Problem gefunden? Kann es wirklich sein, dass die Box durch "Überlastung" des S0-Bus dermaßen irritiert wird, dass sie sich weghängt?

    Ein Firmware-Update (Stand April 2019) und die aktuellsten Treiber (3.9.128-gd48eedb) für die Primux-Box haben wir bereits auf Empfehlung des Support von Gerdes durchgeführt.

    Gruß

    fx.trix

  • pdf24 und tobit (öffnet sich nicht)

    Hab das Problem gelöst. Für das Protokoll: es hatte nicht mit dem aufgezeigten Registry-Eintrag zu tun, sondern die Microsoft Desktop Apps, eine wunderbare neue "Erfindung" unter Windows 10, waren es. Durch die Vorinstallation eines Office 365 seitens des OEM war dort unter Desktop Apps auch ein Eintrag "Microsoft Desktop Apps" und der blockierte die Wirksamkeit der Einstellung von David als Standard für Mail. Den deinstalliert, anschließend das Office 365 noch mal richtig installiert und schon funktioniert die Vorgabe von David als Standard Mail Client.

    Gruß

    fx.trix

  • pdf24 und tobit (öffnet sich nicht)

    Hallo Leute,

    dieses Problem habe ich jetzt auch auf neuen PCs mit Windows 10 Build 1803, wobei der Registry-Key wie von RobDust in #3 beschrieben bereits so gesetzt ist ohne das ich das erst manuell eintragen musste. Dennoch öffnen Mail-Links oder MAPI-Calls nicht das TIC. Gibt es hier vielleicht weitere Ideen, woran es noch liegen könnte?

    Auffällig ist, dass PCs mit Win 10, die vor dem Build 1803 mit dem David-Client versorgt wurden, weiterhin normal laufen. Alle Installationen, die nach 1803 aufsetzen, funktionieren nicht.

    Falls das hier an dem eigentlich gelösten Thema nicht richtig ist, @admin, bitte an die richtige Stelle verschieben.

    Gruß

    fx.trix