fha

Hi! Danke für die Antwort. Ja, ich habe da schon Tage damit zugebracht... Habe bisher aber noch keinen ANhalt woran das liegen könnte....

Hallo Zusammen, Ich habe aktuell folgendes Problem: Zwei Verteilerlisten: DisGrp1 und DisGrp2 Beide sind konfiguriert Mails von internen und externen Absendern zu akzeptieren Wenn ich eine Mail an DisGrp1 schicke bekommen alle Benutzer-Mitglieder die Mail zugestellt. Wenn ich eine Mail an DisGrp2 schicke bekommen alle Benutzer-Mitglieder die Mail zugestellt. Nun mache ich DisGrp2 zum Mitglied von DisGrp1 und schicke eine Mail an DisGrp1. Die direkten Mitglieder-Benutzer bekommen die Mail, die Mitglieder der DisGrp2 nicht. Scheinbar funktioniert also die Verschachtelung nicht. Beide Gruppen sind nicht ausgeblendet in der Adressliste. Jemand eine Idee woran das liegen könnte?

Hi Norbert, Das Ganze ist als NLB-DAG Lösung mit vier Servern verkauft worden. Allerdings ist nun erst bei der Realisierung unserem VMWare-Admin der Gedanke gekommen, dass seine Farm mit NLB Probleme haben könnte. Daher wurde von PL-Seite entschieden die Firewall (ein Barrcuda-Cluster) dafür zu nutzen. Die vier (virtuellen) Server stehen aber schon und sind so verkauft/vermietet. Split-DNS war bisher wegen Einwänden des Kunden keine Option. Aufgrund der Aufwände sieht es aber so aus als ob sich die Einstellung geändert hat.

Hallo! Vielen Dank für Eure Antworten. Ich habe mir etwas Zeit gelassen weil ich mir das Thema noch mal grundsätzlich angesehen habe. Also es sind bereits vier Ex2010 installiert, 2* HT/CAS und 2* MBX, zusätzlich zum produktiven Multi-Role-Exchange. DAG ist eingerichtet, Datenbanken angelegt. NLB kommt nicht zum Einsatz, wir handeln das über die vorgeschaltete Firewall. Die sucht sich RoundRobin einen der beiden CAS aus, prüft ob auf dem angeforderten Port eine TCP-Session zustande kommt und wenn nicht versucht sie es beim anderen CAS. Das nur als Info zu Euren Einwänden bzgl. NLB. AKtuell geht die PLanung zu einem zusätzlichen öffentlichen Zugangspunkt der durch einen HTTPS-Proxy mit Public-Certificate belegt ist. Dieser leitet weiter auf den CASARRAY der mit internen Zertifikaten bestückt ist. Allerdings gehe ich davon aus, dass ich damit die kompletten Zugänge auf Outlook Anywhere und ActiveSync neu anlegen darf. Aber die interne Domäne bekomme ich nicht mehr in ein öffentliches Zertifikat.

Hallo Zusammen, Ich habe hier die Situation, dass ein einzelner Exchange 2010 Server migriert werden soll auf eine hochverfügbare Umgebung (2* CAS/HT, 2*MB), ebenfalls mit Exchange 2010. Wir bleiben also in der selben Organisation, dem selben Netzwerk und auf der selben Version. TMG ist nicht im Einsatz, HTTPS geht gerade durch die Firewall auf den Exchange. Ich bitte Euch NICHT über den letzten Punkt zu schreiben, der war nur als Info gedacht. Nun hat der Kunde eine sehr hohe Anzahl an Outlook Anywhere Clients und ich wollte einfach einmal fragen wie Ihr den Umzug angehen würdet!? Mein Kollege hat den Umzug so geplant (ist nun leider nicht mehr bei uns), dass lediglich die Postfächer umgezogen werden. Zugriffspunkt im Internet etc. bleiben gleich. Ich bin mir aber nicht sicher ob die Outlook-Clients das auch so mitbekommen. Daher spiele ich mit der Überlegung einen neuen Internetzugriffspunkt anzulegen mit eigenem Autodiscover etc. Wie wäre Eure grundsätzliche Herangehensweise?

Hallo Zusammen, erst einmal vielen Dank an alle die geantwortet haben. Ein Wort zu der Domäne: In diesem Fall war der .de-Name schon vorgegeben, aber wir gehen tatsächlich bei neuen AD-Domänen dahin vermehrt öffentliche Namen zu verwenden. Der Hintergrund ist einfach die Geschichte mit den Zertifikaten. Ab Ende nächstes Jahr werden keine Zertifikate mehr für interne Namen vergeben. Und da weißen wir eben gerne auf öffentliche Namen hin, wenn es sich in der Situation anbietet. Zum Problem: Das ist gelöst, Outlook Anywhere funktioniert nun. Zwei Dinge haben uns weitergebracht. Erstens: In der Firewall-Regel für den Port 443 waren irgendwelche Dienstausnahmen eingetragen. Ich weiß nicht welcher Art, ich weiß nur, dass die Regel für den Port 443 neu gemacht wurde ohne jegliche Einschränkung und damit kamen wir einen Schritt weiter. Allerdings wurde das Postfach nicht gefunden. Zweitens: Ausgerechnet bei den beiden Testusern gab es eine ungewöhnliche Konstellation. Im Outlook muss als Benutzername etwas eingegeben werden dass nicht nur das AD sondern eben der Exchange als eindeutig erkennt. Und der hat den AD-Benutzernamen bzw. Alias nicht erkannt, weil hier im Vorfeld bereits die Postfächer so konfiguriert waren dass sich die Angaben im Exchange von denen im AD unterschieden haben. Da nicht klar ist bei wievielen Benutzern das zutrifft wurde entschieden für zukünftige Benutzeranlagen auf dieses Problem zu achten. Bis dahin wird als Benutzername im Outlook die primäre Mailadresse (Antwort-Mailadresse) verwendet. Das funktioniert. CU.

Hallo Zusammen, In den Ereignisprotokollen findet sich nichts außer dem Watson-Fehler den auch die EMS ausgibt. Der Client steht im Internet. Es handelt sich dabei sowohl um Domain-member- als auch Standalone-Computer. Aber alle haben das Root-Zertifikat der Domäne in den Trusted-Root-CA installiert. Die öffentliche Adresse des Exchange ("mob.webdomain.de") lässt sich auflösen aber nicht pingen (das unterbindet die Firewall). Die interne Adresse des Exchange ("ex.addomain.de") lässt sich nicht auflösen und nicht pingen. IPv6 ist aktiv auf der Netzwerkkarte des Ex2010. Allerdings habe ich bereits überprüft, dass auch auf den IPv6-Adressen die Ports für die RPC-Kommunikation offen sind. Was mir gerade einfällt: Die interne Domain (addomain.de) ist vom Namen her eine öffentliche Domäne... Macht das Probleme?

Hallo Zusammen, Ich habe hier einen Exchange 2010 auf den ich gerade von einem Exchange 2003 migriere. Ich habe gerade die ersten Testpostfächer auf den 2010er verschoben, die Produktivpostfächer und auch die Sende-Empfangsconnectoren sind alle noch auf dem alten Exchange. Mein Problem: Outlook-Anywhere funktioniert nicht. Ich konfiguriere mein Outlook manuell (kein Autodiscover) und lasse den Namen des Users prüfen. Dann kommt ein Loginfenster in welches ich die Logindaten des Users eingebe, danach kommt eine Meldung, dass der Exchange-Server nicht erreicht werden kann. Da ich für SSL ein Zertifikat der internen CA einsetze kommt der ConnectivityAnalyzer nicht über den Zertifikatsfehler hinaus. Führe ich das CMDlet test-Outlookconnectivity für den RPCProxyType:extern aus bekomme ich folgende Meldung: Für intern funktioniert das CMDlet. Ich stehe gerade ein bißchen auf dem Schlauch.... wo gibt es noch Hinweise wie es weiter geht bzw. was das Problem ist.

Hi! Sorry, was genau verstehst du unter dem Transportprotokoll? Ich habe im SMTP Receive nachgesehen und finde keine Fehler. THX. Hallo Zusammen, zunächst einmal Danke an alle die geantwortet haben. Das SMTPReceive-Log hatte keine Fehler, aber viele "AUTH" anfragen und die Antwort "503 5.5.2 Auth command already specified" Dadurch bin darauf gekommen, dass im virtuellen Standardserver auf dem 2003 zwar kein Smarthost mehr drin stand, ABER die Authentifizierung war noch konfiguriert! Die "Ausgehende Sicherheit" auf anonym gestellt und siehe da alles läuft... Im Nachhinein habe ich gesehen, dass es auch einfacher gegangen wäre. In den Weiteren Warteschlangeninformationen auf dem 2003 stand nämlich die Meldung "Der Remote-SMTP-Dienst hat die AUTH-Vereinbarung zurückgewiesen" Wie ich diese Meldung übersehen könnte ist mir rätselhaft. Auf jeden Fall funktioniert jetzt auch die PF-Replikation die auch noch ein Problemfall war Öffentliche Ordner wäre dann mein nächstes Thema gewesen ;-) CU

Hi! Also für den Mailversand ist momentan noch komplett der 2003er zuständig. Der Empfangsconnector des Ex2010 ist so konfiguriert, dass er Mails von anonymen Benutzern annimmt und die Authentifizierung steht auf "Exchange Server". Transportlog schaue ich noch. Die NDR_Meldung sieht so aus:

Hi! Es handelt sich sowohl um interne als auch externe. Nach einem Tag oder so bekommt man die Mail, dass sich die Zustellung verzögert und am zweiten Tag dann die Unzustellbarkeitsnachricht. Ich habe es selbst nachgesehen: Im virtuellen SMTP auf dem 2003 steht kein Smarthost drin. Oder gibt es da noch eine andere Möglichkeit als den System-Manager?

Hallo Zusammen, Habe hier eine Domäne mit 2 * DC (Win2003) und 1* Ex (Ex2003). Ich habe bereits die beiden DCs durch zwei neue DCs ersetzt auf Basis Windows 2012. Auf einem weiteren Windows 2012 Server wurde der Exchange 2010 SP3 installiert. D. h. die neue Struktur sieht so aus: 2 * DC (Win2012) und 2 * Ex (Ex2003 & Ex2010). Wenn ich nun eine Testmigration eines Postfachs auf den 2010er durchführe kann ich von dort Mails verschchicken, ich kann aber keine Empfangen. Die Connectoren sind alle noch nicht umgezogen, der 2003er ist für die Zustellung verantwortlich. Außerdem ist die Maildomäne mit der Mails verschickt werden als "interer Relay" konfiguriert weil es hier auch Postfächer auf einem externen Mailserver gibt. Verschickt wird via Smarthost der aber nur im Sendeconnector eingetragen ist, nicht im Virtuellen Standardserver SMTP. Hat jemand einen Hinweis?

Hallo Zusammen, Vielen Dank an Alle die geantwortet haben. Speziell natürlich an dich, Nils. Ich habe zwar die Specs zu NSLookup noch nicht gefunden, habe aber nun einen Überblick über die Funktion bekommen. Das erklärt auch einige unterschiedliche Ergebnisse die Ping und NSlookup liefern. Noch eine Frage zum Schluss: Gibt es außer Ping noch eine Möglichkeit die Ergebnisse des Client-Resolvers sichtbar zu machen?

Hallo Zusammen, Folgende Situation: AD-Domain: addomain.net DC1: Windows 2008 R2, 192.168.0.1, AD-intergierter DNS, Forwarder im DNS auf 8.8.8.8 DC2: Windows 2012, 192.168.0.2, AD-intergierter DNS, Forwarder im DNS auf 8.8.8.8 und 208.67.222.222(OpenDNS) Client: Windows 7 Domainmember, 192.168.0.10, DNS-Reihenfolge DC1, DC2, Liste mit DNS-Suffixen in der Netzwerkverbindung z. B. csuffix.net Mache ich von DC1 auf DC2 einen nslookup für addomain.net bekomme ich als Antwort "addomain.net:192.168.0.1, 192.168.0.2" Mache ich von DC2 auf DC1 einen nslookup für addomain.net bekomme ich als Antwort "addomain.net:192.168.0.1, 192.168.0.2" Mache ich vom Client einen nslookup auf DC1 für addomain.net bekomme ich als Antwort "addomain.net:192.168.0.1, 192.168.0.2" Mache ich vom Client einen nslookup auf DC2 für addomain.net bekomme ich als Antwort "addomain.net.csuffix.net: 67.x.x.x" Das Problem ist prinzipiell gelöst: Die openDNS-Server geben immer diese 67.x.x.x Adresse zurück wenn sie eine Domain nicht kennen anstatt einfach zuzugeben dass sie die DOmain nicht kennen. Ich habe daher den openDNS-Forwarder am DC2 entfernt und alles läuft wieder einwandfrei. NUR: (Jetzt kommt die Frage!) Der Windows DNS (Ich habe mal die Gegenprüfung gemacht, der Windows 2008 R2 verhält sich genauso wie der 2012er) fragt hier scheinbar einen Forwarder an. Für eine Forward-Lookup-Zone für die er selbst verantwortlich ist!? Warum? Wieso gibt er nicht einfach die Antwort aus seinem eigenen Speicher? :confused: Hat mir hier jemand eine Erklärung?

Hallo Zusammen, Also das Phänomen ist für mich nicht erklärbar. Allerdings konnte ich es lösen. In dem Netzwerk war in der Firewall alles geblockt bis auf ganz wenige Dienste. DNS war nicht dabei. Soll heißen: Der Server konnte via Port 53 nicht ins Internet. Neue Regel für Port 53 und die Timeouts waren weg. Ich habe verschiedene Kombinationen ausprobiert: Port 53 zu, Forwarder eingetragen - Port 53 offen, Forwarder eingetragen - Port 53 offen, Kein Forwarder - Port 53 zu, Kein Forwarder.... es lief alles darauf hinaus: Wenn Port 53 ins Internet zu ist kommen zunächst Timeouts bevor das Ergebnis geliefert wird. Was für mich die Frage aufwirft: HÄ? Und vor allem: Woher kamen denn dann in der oben aufgeführten Befehlsreihe die Antworten der ROOT-Server wenn Port 53 zu ist.... Wie gesagt, Problem ist für mich nicht erklärbar. Nun ist Port 53 eben offen und es sind neben den Root-Devices zwei Forwarder ins Internet eingetragen.