testperson

Hi, das wichtigste wäre die Terminalserver aktuell zu patchen und die aktuellsten Druckertreiber zu nutzen. Zu diesem Problem gibt es hier einiges zu lesen: https://www.mcseboard.de/topic/199355-2012-r2-rds-extreme-druckerprobleme/ Wie viele Terminalserver sind im Einsatz? Was nahezu immer hilft (aber eigentlich keine zufriedenstellende Lösung ist), die Drucker nicht in die User Session verbinden sondern auf den Terminalservern installieren. Gruß Jan

Oha, ich Depp Demnächst auch alles lesen und verstehen. Das betrifft nur "EV-Zertifikate" und sowohl wir, wie scheinbar auch die DKB, nutzen Domain- bzw. Organization-Validated Zertifikate.

Hi, nach https://www.heise.de/news/Jetzt-handeln-DigiCert-erklaert-zehntausende-TLS-Zertifikate-fuer-ungueltig-4840972.html?wt_mc=rss.red.security.security.atom.beitrag.beitrag sollten gestern 20 Uhr verschiedene Intermediates von Digicert revoked werden. In den Kommentaren bei heise.de habe ich als Beispiel die DKB gefunden (und muss nicht drauf eingehen, dass bei "uns" verschlafen wurde, zu erneuern), die noch ohne Zertifikatswarnung aufgerufen werden kann. Die Sperrlisten wurden jedenfalls gestern aktualisiert. Ist das jetzt ein Grund weshalb es https://www.michael-wessel.de/blog/2020/04/27/lets-talk-about-it-warum-pki-ein-krankes-konzept-ist/ gibt? Gruß Jan

Hi, hast du nach dem Update durchgebootet? Laufen alle Dienste? Gab es irgendwelche Besonderheiten beim Update oder lief das komplett problemfrei durch? Sind das die einzigen Fehler im Eventlog oder finden sich in administrativen Ereignissen weitere? Mir sind zuletzt eine Hand voll Exchange Server begegnet wo - losgelost von einem Update - keine Zertifikate mehr ans Backend gebunden waren. Da gab es dann auch entsprechende Serverfehler. Je nachdem wie lange du schon nicht mehr weiter weißt, wäre ggfs. ein Restore eine Idee. Danach würde ich dann direkt auf CU17 updaten. Gruß Jan

Die 12.1-57.18 ist auch nicht betroffen und im 12.1er Release die aktuellste Firmware aus Juni.

Hi, ein DC, ob virtualisiert oder physikalisch, ist irgendwie zwangsweise immer Mitglied der Domain. Der Essentials muss lediglich die FSMO Rollen halten, die sich dann beim Herunterstufen i.d.R. automatisch einen neuen Inhaber suchen. Gruß Jan

Hi, wie filtert denn der Kaspersky? Ggfs. kommt die Mail ja gar nicht bis ins Exchange SMTP Log. Exchange meldet AFAIK auch kein "452 4.3.1 Insufficient system storage". Gruß Jan

Hi, ich habs noch nie benutzt aber laut Website sollte Transend das können: https://www.transend.com/scenario/imap-microsoft-exchange-2013/ Gruß Jan

Hi, ich würde Software nicht per GPO verteilen. Ich würde da auf WSUS und WPP oder eben direkt eine Softwareverteilungslösung setzen. Ansonsten könnte dir hier der (erweiterte) Ruhezustand (PowerCfg.exe /h Off) oder ein zu schneller Bootvorgang (https://www.gruppenrichtlinien.de/artikel/ssd-zu-schnell-synchroner-startvorgang-nicht-moeglich/) dazwischen funken. Gruß Jan

Hi, bevor ich mich über "die zwei Klicks" aufregen würde, würde ich mich bzgl. aufregen. Ansonsten bau dir dein eigenes "Frontend" bspw. per PowerShell. Gruß Jan

Hi, bring den Usern bei, sich mit der E-Mail-Adresse bzw. dem UPN anzumelden ;). Alternativ SSON aktivieren? Kannst du nicht die RDP Datei speichern und einfach bei Benutzer nur "<Domain>\" eingeben? Ich meine, dass hätten wir "früher" so gemacht. Gruß Jan

Hi, kam grade aus dem Citrix Knowledge Center Alarm bzw. über die RSS Feeds: https://support.citrix.com/article/CTX276688 Im Citrix Blog wird auf die, sich größtenteils im Management befindlichen, Schwachstellen eingegangen: https://www.citrix.com/blogs/2020/07/07/citrix-provides-context-on-security-bulletin-ctx276688/ Gruß Jan

Hi, die benötigten Ressourcen und die Lizenzierung. Gruß Jan

Ist denn "mail.<deine Domain>.<tld>" überhaupt (einer) der MX Record(s)? Was ergibt denn nslookup -querytype=MX <deine Domain.tld> und wohin zeigt dieser A-Record?

Hi, wie kommen denn die Mails zum Exchange? Was findet sich in den SMTP Logs auf deiner und ggfs. der absendenden Seite? Gruß Jan