NorbertFe

Ist am Router ipv6 aus? Von der Telekom sind die speedports auch so doof, dass man sie dafür nicht einsetzen kann. Das dürfte bei dir auch das Problem sein, auch wenn du oben meinst es wäre was anderes.

https://www.msxforum.de/community/index.php/Thread/16393-Exchange-Konto-einbinden-schlägt-fehl/?pageNo=1 Bist aber nicht der Einzige. ;) Vielleicht hilft ja, wenn du die dortigen Tipps mal versuchst.

Am besten nimmst du den Haken raus, dass der Switch auch für den Host verwendet werden soll, dann brauchst du auch keine ip Konfiguration vornehmen.

Trackinglog. Wenn’s aktiviert ist. Ansonsten natürlich nicht. Aber immer dran denken: dsgvo;)

Und was ist jetzt deine Frage? Die Domain ist eigentlich überflüssig, schadet aber auch nix. Und ja du brauchst autodiscover.domain.tld und einen weiteren Namen.

Spricht alles dafür, dass dir irgendwo ein Proxy oder ähnliches dazwischen grätscht.

Nein kann er nicht. Er scannt einfach die pst Datei. Siehe:
Quelle: https://docs.microsoft.com/de-de/windows/security/threat-protection/windows-defender-antivirus/configure-advanced-scan-types-windows-defender-antivirus
 
zumindest liest sich das für mich so. ;)

Lösch doch das Benutzerprofil auf dem terminalserver mittels „System“. 

Korrekt.
 
An deiner Spamlösung oder indem du dem Ding halt eine nur intern adressierbare Emailadresse gibts - sowas wie import2@domain.local usw.
 
Bye
Norbert

Hallo,
interessant wäre zu wissen, welche Exchangeversion du in welchem Patchstand einsetzt.
Nur die Default Policy einzusetzen ist schlechter Stil, denn die greift immer und für alles. Damit man das etwas "sinnvoller" steuern kann, definier doch mal eine neue, welche nur für Kontakte wirkt und definiere darin dann die entsprechenden Bedingungen.

Da die Optionen nicht repliziert werden, muss man das auf jeden Server manuell aktivieren. Wenn man das nicht so oft macht, fällt es nicht auf, dass man was vergisst.

DEswegen sollst du ja auch VOllzugriff einrichten und KEINE Credentials speichern, weil das gar nicht notwendig ist.

Lokale Anmeldung an den PCs für die Gruppe rds User verweigern. Fertig.

Booten und deinstallieren und dafür sorgen, dass es nicht wieder automatisch installiert wird. Der Server wird deswegen nicht explodieren, aber wenn dir der supportzustand bzw. die -zusage des herstellers wichtig sind, solltest du obiges durchführen.
 
bye
norbert

Lehne die Updates ab. :) Die stehen schließlich auf nicht genehmigt, und die Clients teilen dir mit, dass sie das Update gern freigegben hätten.

Läuft der Anmeldedienst auf den betroffenen Geräten?

Wahrscheinlich gar nicht. :) Denn dafür müßtest du dann Windows Server 2016 mit SA besitzen afaik und selbst dann ist die 1803 eben kein "vollwertiger" WIndows Server 2016.

Nutzt du den central store? In irgendeiner Version der Windows 10 Admx war an der Stelle mal ein Fehler. Im Zweifel die Admx aktualisieren.

Das Sysvol ist kein geeigneter Ort für Softwaredeployment. Eigentlich sollte das so pauschal einleuchten. Jeder der schonmal ein DSF-R Problem lösen mußte, weiß, dass viele/große Dateien und GPOs gleichzeitig zu troubleshooten einfach mistig ist. Im Allgemeinen geht dabei dann auch irgendwas "verloren". Ansonsten ist die Softwareverteilung per GPO sowieso nicht unbedingt sinnvoll, sondern sollte mit Tools wie bspw. WSUS oder anderen 3rd Lösungen realisiert werden. Hängt dann meist von den Anforderungen ab.

Du musst die aber in den central store kopieren. Da wo du es hinkopiert hast, wird’s auch nicht repliziert.

Das funktioniert auf Dauer garantiert nicht sinnvoll, weil eben der Autodiscover-Prozess nicht vom Linux Spamfilter auf die beiden verschiedenen Exchangesysteme verteilen kann. ;) Meiner Meinung nach ginge es, wenn du für jede Domain noch A.emaildomain.com und B.emaildomain.com anlegst und den Nutzern aus diesen Domains dann jeweils auch eine gültige Emaildomain zuweist und im public und internen DNS dann die Autodiscover Einträge entsprechend anlegst. Dann könnte man sogar Federation Trust konfigurieren.
 
Bye
Norbert

Nein, aber den Wunsch, den gibts schon ewig.
 

Nein das wird nix. Du wirst per Powershell das Team bearbeiten müssen (weils per GUI abstürzen dürfte) und entfernst dort die nicht mehr vorhandenen NICs und steckst die neuen wieder rein. Die MAC interessiert beim Team ja nicht. Für deine iSCSI Adapter wirst du afaik einfach alles "neu konfigurieren" müssen. Aber auch da ist die MAC im Endeffekt egal.

Hast du evtl. Deadlines für deine Updates im WSUS konfiguriert? Kannst du ggf. am Client direkt in der Registry mal nachschauen ob sich diese und ggf. widersprüchliche Einstellungen wiederfinden?

Ja solche Netzwerke gibt es, die sowas begrenzen und evtl. will man ja auch nicht einfach jedes RootUpdate zulassen. Dann bleibt eben nur der "manuelle" Weg, herauszufinden, welche Root-Zerts man tatsächlich benötigt und diese dann entsprechend an seine Clients zu verteilen. Eine "Wasch mich aber mach nicht naß" Policy gibts an der Stelle eben tatsächlich nicht. :)
Nein das Offline Paket gibts afaik nicht mehr. Und wenn du sowieso "pauschal" alles was MS zuläßt an der Stelle zuläßt, dann kannst du auch den Zertifikatsagent die Root-Zerts laden lassen.