testperson

Hi, das sollte mit dem Mailbox Replication Service / MRSProxy machbar sein und ist hier beschrieben: https://www.msxfaq.de/exchange/migration/org2org2016.htm Habe ich aber noch nie gemacht, wollte es aber schon immer mal in einer Testumgebung nachstellen ;) . Gruß Jan

Was möchtest du denn da letztlich abbilden und wieso muss es zwingend Outlook als Client bzw. Exchange sein?

Hi, evtl. ist Exchange (und Outlook) hier das falsche Mittel zur Wahl. Je nachdem was du (letztlich mit der Konfiguration) erreichen willst, könnte das etwas für ein Ticketsystem o.ä. sein. Gruß Jan

OT: Wenn man den Herrn zwischen "C:\Users\" und "\Desktop\..." nicht mit dir in Verbindung bringen soll oder der Herr hier vielleicht unwissend auftaucht, solltest du den Screenshot ggfs. anonymisieren :).

Hi, wäre es evtl. ein einfacherer Ansatz, die Server im derzeitigen IP-Netz zu belassen und "alles andere" in eigene VLANs / IP-Netze umzuziehen? Alternativ würde ich direkt alle Geräte durchgehen und prüfen, wie diese konfiguriert sind. Dann kannst du direkt die saubere Dokumentation "nachziehen". Gruß Jan

Hi, das klingt danach, als wäre es am zielführendsten sich einen Dienstleister zu suchen, der die Infrastruktur einmal aufnimmt und dann das Design bzw. die Möglichkeiten mit euch durchspricht. So hätte man auch noch jemanden in der Hinterhand, der bei Problemen unterstützen könnte bzw. direkt involviert wird. Wenn die Standorte nicht von einander abhängig sein wollen, wäre es ggfs. auch eine Option Exchange an einem "verfügbareren" Standort C, bspw. O365, zu betreiben. Ebenfalls könnte man beleuchten, ob ein zweiter DC je Standort sinnvoll wäre. Je nach Anforderung(en) könnte es vielleicht auch auf zwei getrennte Gesamtstrukturen (und ggfs. anschließendem Trust) rauslaufen. Meiner Meinung nach: Es kommt drauf an :). Gruß Jan

Hi, naja, Teamviewer liegt da ja nun auch nicht falsch mit der kommerziellen Nutzung. Du könntest die Remotehilfe / QuickAssist oder auch die Remoteunterstützung nutzen: https://support.microsoft.com/de-de/help/4026516/windows-solve-pc-problems-remote-connection-quick-assist Gruß Jan

Wenn ihr nur einen Terminalserver habt auf dem alle User arbeiten und die Anzahl der Drucker "überschaubar" ist, würde ich die Drucker auf dem Terminalserver installieren (und nicht freigeben). Das wird von Microsoft vermutlich noch weniger begrüßt ;).

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

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

Hi, damit die User ihr Outlook zumindest "ohne Zutun" auf kriegen, könntest du noch versuchen, das Profil bei Anmeldung aus der Registry und dem User-Profil zu löschen sowie https://gpsearch.azurewebsites.net/#6228 zu setzen. Zusätzlich ggfs. noch den Cache-Mode (aktivieren/)deaktivieren: https://gpsearch.azurewebsites.net/#6201 Gruß Jan

Hi, das dürfte am einfachsten mit HTTP-Redirect gehen: https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpredirect/ Sollte aber auch mit dem URL Rewrite Module machbar sein. Gruß Jan

Ein Ansatz könnte sein, dem VPN User am Gateway per Firewall alles andere zu verbieten.