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.

Hallo Zusammen, ich habe eine Domäne "domain.ext" bestehend aus drei Sites und vier DCs (alle Windows 2008 R2). Site1 hat die DCs DC1 und DC2(PDC, RID, IM). Site2 hat DC3, Site3 hat DC4(Schema, Domain) und EX1(Exchange 2010). Alle vier DCs sind Global Catalog. Ein NSLOOKUP gegen den DC4 bringt folgendes Ergebnis: Wenn ich www.google.de auflösen möchte bekomme ich nur Timeouts. Wenn ich allerdings die Rekursion deaktiviere sieht das ganz anderst aus: Alle Timeouts sind weg. Ich habe schon die Forwarders gecheckt, Die Konfiguration der DNS-Server geprüft - mir ist nichts aufgefallen. Hat jemand eine Idee woran das liegen könnte?

Hallo! Vielen Dank für die Antworten. Ich habe einen Exchange 2010 Grundinstalliert und die Mailkommunikation eingerichtet. Dann hat ein Kollege die Migration eines Exchange 2007 auf diesen Exchange 2010 durchgeführt. Und jetzt, nur ein paar Wochen nach der Migration habe wir das Problem, dass die zugespamt werden mit Mails die aus ihrer eigenen Domänen zu stammen scheinen aber von extern kommen. Open Relay ist nicht konfiguriert, es ist nicht möglich über diesen Exchange Mails wieder nach extern zu senden. Nachdem ich das Problem analysiert hatte habe ich Testweise das beschriebene Telnet-Verfahren auf zwei weiteren Exchange 2010 Kundensystemen durchgeführt und es hat bei allen funktioniert. Daher nahm ich an es wäre Standardverhalten. Nun bin ich etwas belämmert, weil es eher so aussieht das ich oder einer der Kollegen hier einen Bock geschossen hat. Und das mehrmals. Nur habe ich noch nicht ganz verstanden wo der Bock nun hängt... Habt Ihr da vielleicht noch einen Link zum RTFM?

Hi Zusammen, Standardmäßig ist es möglich dem Exchange Mails mit der internen Maildomäne von extern unterzujubeln. Beispiel: Es existieren die beiden Mailadressen "chef@maildomain.com" und "IT@maildomain.com". Natürlich ist "maildomain.com" eine accepted Domain. Nun kann ich mich von extern via Telnet auf den Exchange schalten und einfach eine Mail von "IT@maildomain.com" an "chef@maildomain.com" generieren und ihn wüst beleidigen. Gibt es hier einen "Best Practice"-Weg dies zu verhindern?

Hallo Zusammen, ich kenne es von Windows 2008 dass auf einem Hyper-V-Server (z. B. Windows Server 2008 Standard mit installierter Hyper-V-Rolle) keine weiteren Produktivdienste laufen dürfen. Wird von Micrsoft nicht supportet. Jetzt habe ich gelesen, dass bei Windows 2012 gilt: Wenn auf dem Hyper-V-Host irgendeine Produktivsoftware ausgeführt wird muss von den virtuellen Nutzungsrechten eine Lizenz abgezogen werden. Was heißt das nun im Umkehrschluss? Wird es mit Windows 2012 supportet das Backup (z. B. einen Backup Exec Medienserver) oder das Anti-Viren-Management auf einem Windows Server auszuführen der gleichzeitig Hyper-V-Host ist? Eine Bitte: Ich weiß, dass diese Vorgehensweise nicht sehr sinnvoll ist. Ich setze prinzipiell einen weiteren phys. Host ein. Schon wegen der DC-Thematik. Allerdings haben wir hier eine detaillierte Anfrage zu diesem Thema und mit unserem MS-Ansprechpartner bin ich momentan am verzweifeln.

Hi! Nochmals Herzlichen Dank. Das werde ich auf jeden Fall mal nachsehen denn das ist ein wirklich guter und greifbarer Nachweis dafür dass dieser Mechanismus auch für die Konsistenz einer Datenbank sorgt. Vielen Dank.

Hi! Herzlichen Dank für die Antwort. An diesem Konfigurationsdialog bin ich auch schon gehangen... Ich finde ihn nicht sehr gut beschrieben. Mir fehlt irgendwie einfach eine offizielle Quelle von Microsoft nach dem MOtto "... supportet für: X, Y, Z ..." oder eine Exclusion vom Exchange-Team, dass Replica nicht unterstützt wird. Irgendetwas in der Art, aber ich habe momentan noch nicht einmal eine Aussage von unserem Partner-Kontakt bekommen. Und das macht mich halt misstrauisch.

Hi Zusammen, ich bin gerade auf der Suche nach einer eindeutigen Quelle die mir sagt ob der Einsatz von Hyper-V-Replica für VMS mit Exchange, ADS oder SQL supportet ist. Ich habe bisher nur Dokumente gefunden auf denen zwar Exchange-VMs aufgezeichnet sind, aber nicht explizit angesprochen werden. Darüber hinaus finde ich Forendiskussionen die voll sind mit Mutmaßungen aber ich habe noch keine Supportmatrix oder ein Vorraussetzungen-Sheet für Hyper-V-Replica gefunden... Hat hier jemand eine Quelle?

Hallo Zusammen, ich habe eine Cross-Forest-Migration. Jeweils Exchange 2010 SP1. Ich habe auf einem Client ein Outlook so konfiguriert, dass es auf die öffentlichen Ordner beider Exchange-Server zugreifen kann. Nun kopiere ich die Ordner vom alten auf den neuen Exchange. Funktioniert auch soweit. Nur wenn in den Ordnern Mails mit der Größe 10MB und mehr drins sind bekomme ich die Fehlermeldung Die Elemente sind aber noch da. Und die Berechtigungen habe ich heute schon mehrmals geprüft. Ich vermute irgendeine Größenbeschränkung dahinter... Aber ich weiß nicht welche... Hat jemand einen Tip? Ach ja, die Maximum Message Size im Client Receive Connector auf beiden Seiten steht auf "1024000" (KB) und sollte damit Dicke reichen...

Vielen Dank für die Antworten! Den Gedanken mit der DMz hatte ich auch schon, scheute aber den Aufwand... aber das wird wohl der Weg werden den ich einschlage. @Norbert: Ja, das Vorgehen habe ich ja gewählt. Die Clients connecten sich auch alle via 443 um ihre Reports abzugeben oder die Liste mit anstehender Updates abzurufen. Aber der Download läuft nicht mehr auf den SSL-Port. Du kannst es dir so vorstellen: Wenn du die updates nicht automatisch installierst sondern nur bereitstellst und den User über neue Updates informierst, dann kannst du auf "Updates suchen" klicken und er sucht. Auf der Firewall registrierst du nur Datenverkehr auf Port 443. Schließlich ist er fertig mit suchen und sagt dir, dass für dein System 21 oder weniger Updates bereitstehen. Sobald du nun auf den Button "Updates installieren" klickst und der BITS mit dem Download der Updates beginnt schlägt auf der Firewall plötzlich Datenverkehr auf Port 8530 auf. Der Grund ist, dass das der Port ist auf den die WSUS-Installation konfiguriert wurde. Und laut dem netten MVP aus dem Link meines ersten Posts ist dieses Verhalten nicht konfigurierbar. Aber konfigurierbar ist der Netzwerkort in dem mein WSUS sitzt und der wird demnächst DMZ heißen ;-) Vielen Dank nochmals.

Hallo Zusammen, Bei einem Kunden war einmal geplant (keine Ahnung von wem...) den WSUS so einzurichten, dass die User von überall auf den WSUS via SSL zugreifen können. Die GPO wurde also so eingerichtet, dass alle Clients auf die Adresse "https://wsus.externedomäne.com:443" zugreifen. Das funktioniert auch soweit was die Reports und die Prüfung auf neue Updates betrifft. Aber sobald der Download der Updates startet greift der Client immer via http auf folgende URL zu: "http://wsus.externedomäne.com:8530". Nun habe ich bereits herausgefunden "It's not a bug, it's a feature" bzw. "This behaviour is by design" wie z. B. hier nach zu lesen ist: Social Technet: WSUS Client Commnunicates with WSUS server but fails to download updates Also habe ich nun im ISA 2006 eine Regel eingerichtet die die Anfrage auf Port 8530 annimmt und als seine eigene Anfrage an den WSUS auf Port 8530 weiterleitet. Es funktioniert! Aber: Ich kenne den ISA 2006 nicht wirklich, daher diese Frage an Euch: Wie groß ist das Tor das ich damit geöffnet habe? Ist es annähernd unbedenklich, weil der ISA noch dazwischen sitzt? Ist es eine katastrophale Sicherheitslücke weil nun via HTTP auf einen Server innerhalb der Domäne (keine DMZ) zugegriffen werden kann? Es würde mir sehr helfen wenn jemand, der sich mit den ISA-Strukturen auskennt hier eine Beurteilung posten könnte. Vielen Dank.