da_doni

Es gibt Angriffe, die fallen auf, weil sie die Windows-Firewall deaktivieren - ein Fall ist bei MSXFAQ dokumentiert: MSXFAQ.DE:Patchen ist wichtig

Zum 2.Screenshot: klickst du dazu auf das "von" oder tippst du bei "an" einen Buchstaben ein? Lösch mal die Adresse, die da drin steht, mit dem Kreuz raus und tipp sie manuell nochmals ein.

Zur Not versuchs mit ner Pipeline. Get-Mailbox Vorname.nachname | Set-MailboxAutoReplyConfiguration

Wenn du den Usern die lokalen Adminrechte wegnehmen kannst, dann hast du dein Ziel erreicht... In der Standardeinstellung haben Domänen-Admins das Recht zum Bearbeiten der Gruppenrichtlinien. Von daher würde ich eine Test-Gruppenrichtlinie anlegen, in der die Domänen-Admins eine Firewallregel eintragen können und als Sicherheitsfilter einen Test-PC eintragen. Dann kannst du eine Regel ändern, an dem PC gpupdate durchführen und wenn alles nach dem Testen klappt wie erwartet, trägst du die Regel in die Haupt-GPO für die Firewall (also für alle PCs) ein. @Ozelott Die GPO hat Vorrang.

Zudem sollte man auf einem DC nur einen Netzwerkadapter bereitstellen - "multihomed DCs" sind für Probleme bekannt: Active Directory communication fails on multihomed domain controllers Multihomed DCs with DNS, RRAS, and/or PPPoE adapters | Ace Fekay

Die Firewallkonfiguration ist eine Computerrichtlinie, hat also auf die Gruppe "Domänen-Benutzer", die nur Benutzer enthält, keine Auswirkungen. Die Firewall müsste nun also von allen Benutzern mit lokalen Adminrechten auf den PCs bearbeitbar sein. Da die Gruppe "Domänen-Admins" standardmäßig in die lokale Administratorengruppe aufgenommen wird, klappt das auch mit dem Bearbeiten der Richtlinie als Domänen-Admin. Von daher hast du mit deiner Richtlinie nichts anderes gemacht, also die Einstellung der Gruppenrichtlinie außer Kraft zu setzen - daher dürfen nun alle lokalen Admins auf den PCs die Firewall konfigurieren... Im Grunde genommen solltest du also gar keine Richtlinie brauchen, du könntest die Richtlinie daher genauso gut deaktivieren....

Ich würde mir jetzt mal keine Sorgen machen, denn es funktioniert ja der Versand - eventuell musste ja sowieso zum Aktivieren von SSL der Hostname des Smarthostes angepasst werden. Zur Not frag einfach beim Provider nach, welchen Smarthost du eintragen musst.

Auf einem SBS die Hyper-V-Rolle zu aktivieren ist nicht supported....

Nur noch als Hinweis - bitte bei Multihomed-DCs beachten: Active Directory communication fails on multihomed domain controllers

Ich würde das ganz einfach per Transportregel lösen.

Vermutlich schickt die FritzBox ihre IPv6-Adresse per Router Advertisement oder DHCPv6 raus. Das solltest du prüfen und ggf. abschalten: FRITZ!Box Hilfe

Bitte poste mal ein "ipconfig /all" vom Server.

Hast du da einen Link o.Ä. dazu? Würde da gerne mehr dazu lesen....

Hängen die Hosts mit in der Domäne? Existiert ein physikalischer DC? Da könnte es unter Umständen Probleme geben.... Prüfe auch vorher sicherheitshalber deine Backups!

War bisher auch kein "Rundum-Sorglos-Paket", da der SBS-POP-Connector offiziell von Microsoft nur für eine Übergangsphase zu SMTP eingebaut worden ist. Wollte ich noch als Hinweis reinwerfen und schließe mich ansonsten der allgemeinen Meinung an, dass POP-Connectoren möglichst zu vermeiden sind.

Ist das Thema noch aktuell? Ich würde prüfen, auf welche IP der Domain Name verweist (nslookup oder ping). Sind das die gleichen Adressen?

Was sagt das Eventlog dazu?

Ich würde als Erstes mal in die Eventlogs eines problematischen Clients schauen....

Warum nicht Group Policy Preferences (GPP) verwenden? Group Policy Preferences Getting Started Guide

Achtung: damit das oben stehende funktioniert, muss auf älteren Systemen (XP, Server 2003, z.T. auch Vista, wenn nicht aktuell) das Update KB943729 installiert sein.

Ist dieser DC gleichzeitig der NTP-Server oder sind das 2 verschiedene Server? Wenn sie unterschiedlich sind, musst du auf dem DC (der hoffentlich auch PDC ist - nachzuprüfen auf der Kommandozeile mit dem Befehl "netdom query fsmo") die Eventlogs prüfen, um nachzusehen, ob die Zeitsynchronisierung dort läuft. Wenn auf dem PDC alles OK ist, schaust du mittels "netstat -ano" nach, ob der Server auch den NTP-Port 123 abhört.

Gibts denn an dem problematischen Remotestandort einen DC oder sollen sich die Clients die Zeit übers WAN holen? Stimmen Datum und Zeit auf den PCs am Remotestandort mit den Daten am DC überein?

Die Antwort kommt zwar etwas spät, aber: Du musst in diesem Fall für jedes Subnetz eine eigene Reverse-Zone erstellen. Deine erste Idee war also absolut richtig.

Kann man analog auch über eine Verteilergruppe regeln, in der nur dieser User Mitglied ist - somit hat der User nur ein Postfach in seiner Ansicht.

Hier muss ich dich korrigieren, die Migration auf Exchange 2013 ist seit 2007 SP3 RU10 möglich.