RobertWi

Moin, erst mal abwarten. Berechtigungsänderungen können bis zu 2 Stunden brauchen, bis sie wirksam werden.

Moin, bei einer PFDB gibt es nur eseutil - oder abwarten. Es ist zwar nicht mehr empfohlen, das hat aber praktische Gründe. Supportet ist eseutil /d weiterhin.

Nimms mir nicht persönlich, aber Dir fehlen absolut elementare Grundlagen, was den Betrieb und die Architektur von Exchange betrifft. Ich würde Dir dringend empfehlen, mal einen Kurs zu besuchen oder intensiv ein Exchange-Buch zu lesen. Irgendwie kann man sonst nie ausschließen, dass es sich um simple Bedienfehler handelt oder wir einfach aneinander vorbeireden. Ein Forum kann Grundlagenwissen nicht ersetzen, dafür haben die Ehrenamtlichen hier nicht genug Zeit! Zum Thema: Ein CAS-Array regelt - wie der Name schon sagt - den Client-Zugriff, also Outlook, HTTPS, POP3 und IMAP4. Der Transport kann auf den gleichen Servern stattfinden, hat aber mit dem CAS-Array nichts zu tun. Daher kann ich nur wiederholen: Den Logging-Level stellt man im Receive-Connector selbst ein - in ALLEN einschalten!

Den Logging-Level stellt man im Receive-Connector selbst ein - in ALLEN einschalten!

Und, hast Du Dich noch nie gefragt, was es mit den Remote Ip-Adressen aufsich hat und wozu die benutzt werden? Im Standard 30 Tage oder 300 MB, je nach dem, was zu erst einsetzt. Kann man via set-transportserver konfigurieren. Natürlich kann man, sonst würde das Ding ja überflüssig sein und keine Mails dort ankommen. Aber natürlich muss man die Sicherheitsrichtlinien (Remote IP, Authentifzierung, etc.) auch mit Telnet beachten. Sonst wären die ja sinnlos.

Und steht die IP-Adresse des Hostes, mit dem Du Telnet ausprobiert hast, auch in der Liste der Remote-IP-Adressen. DOPPELT Prüfen, wenn da 175 Adressen drin sind. Ansonsten mal einen Blick ins SMTP-Protokoll werfen, dass könnte die Verbindung protokollieren und nennt dabei auch den Connector.

Und wie sind die übrigen Einstellungen (Remote IP-Adresse, z.B.) des Connectors "smtprelay.consito.intern"?

DCPROMO ist auf laufenden Exchange-Installationen unsupportet, d.h. zuerst muss Exchange umziehen. Zum eigentlichen Problem lässt sich mit den wenigen Informationen nur sehr wenig sagen. Eventuell AD-Probleme, eventuell Bedienfehler (soi "findet" der Assistent für lokale verschiebene Anforderungen z.B. keinen Server, sondern nur Datenbanken). Was bringt die Ausgabe von "test-servicehealth" auf beiden Maschinen? Was bringt die Ausgabe von "Get-MailboxDatabase -Status | fl Name,Server,Mounted"?

Habs mir fast gedacht. Die Leerzeichen stören in einigen Namen, darum werden die AL gar nicht aktualisiert. Schau mal hier: Adressbücher können nicht aktualisiert werden « Robert Willes Welt

Moin, in OWA sind sie auch noch drin? Bekommst Du Fehler, wenn Du folgende Befehle ausführst: get-addresslist | update-addressliste get-globaladdressliste | update-globaladdressliste get-offlineaddressbook | update-offlineaddressbock Update-FileDistributionService SERVERNAME Sind sie danach in OWA weg?

Ja, weil format-list dafür das falsche Werkzeug ist. Format-list formatiert, wie der Name schon sagt, für die Anzeige einer Liste, nicht für den Export in eine CSV-Datei. Siehe meinen Nachtrag oben, für EINEN Connector. Wenn Du in meinem Beispiel oben export-csv durch format-list ersetzt, hast Du auch eine Ausgabe in der Shell.

Nachtrag: Da Du oben nur EINEN Connector angibst, habe ich mal ein wenig rumgespielt und einen einfachen Export gefunden. Eigentlich darf man den gar nicht zeigen, denn PS-technisch ist das ziemlich schlechter Stil, aber er funktioniert: Get-ReceiveConnector "NAMEDESCONNECTORS" | foreach-Object {$_.RemoteIpRanges | Export-Csv d:\test1.txt } WICHTIG: Das geht nur mit EINEM Connector. Sollte man die Ausgabe mit mehreren probieren, dann steht nur das Ergebnis des letzten Connectors in der Datei!

Na siehste. Deine Frage klingt so, als würde die Shell die nicht kenne und daher nicht anzeigen. In Wirklichkeit kämpfst Du aber nur mit der PowerShell, bzw. der Anzeige im Fenster. Diese drei von mir da am Ende markierten Punkte zeigen an, dass es noch mehr gibt, die Ausgabe hier aber aus Platzgründen abgeschnitten wird. Hättest Du GLEICH Eingangs beschrieben, dass Du das in eine CSV-Datei exportieren willst, dann wäre klar geworden, dass das Problem ein ganz anderes ist, als die abgeschnittene Ausgabe von format-list. Mit einem Einzeiler lässt sich das leider nicht vernünftig lösen, da das bei Exchange ein mehrwertiges Attribute ist (das noch dazu größere Objekte enthält), Export-CSV dieses aber nicht rekursiv auflöst. Und format-list ist an dieser Stelle falsch. Da Du hier potentiell drei Dimensionen hast, musst Du also erstmal definieren, wie Du die Daten später in der CSV-Datei haben willst. In Zeilen könntest Du die Connectoren haben, in EINER Spalte dann alle Remote-IP-Adressen In Zeilen könntest Du die Connectoren haben, in den nachfrolgenden Spalten dann jeweils EINE Remote-IP-Adresse (wobei dann noch zu definieren wäre, wie Du die Ranges auflösen willst). Oder Du verzichtest auf die Connectoren, dann könnte man in jeder Zeile eine Remote-IP haben, muss aber definieren, aus welchem Connector die kommen soll. Was steht bei Nils in der Signatur: "... der beste Schritt zur Problemlösung: Anforderungen definieren!"

Mit den wenigen Infos ist das jetzt nur Glaskugellesen. Wenn wir Dir helfen sollen, dann musst Du schon ein wenig mehr zeigen, z.B. einen Screenshot der EMC-Ausgabe und der EMS-Ausgabe.

Moin, 1. die Datenbank kann man zwar auf einen anderen Server verschieben, aber das braucht entweder eine DAG (siehe Deine Fehlermeldung), oder man muss wissen, was man macht. 2. bei Verschieben der Postfächer selbst brauchst Du eine lokale Verschiebeanforderung. Remote verschiebt in andere Exchange-Organisationen (z.B. Office 365), lokale innerhalb einer Organisation. Laufen auf dem neuen Server alles Dienst? Fehlermeldungen im Eventlog? ExBPA bringt Fehler?

Moin, hast Du denn ALLE Adresslisten aktualisiert? get-addresslist | update-addressliste get-globaladdressliste | update-globaladdressliste get-offlineaddressbook | update-offlineaddressbock Update-FileDistributionService SERVERNAME

Moin, was wird Dir denn angezeigt und was fehlt? Bei mir funktioniert das i.d.R.

Und? Geht's damit?

Das ist genau das, was ich auch beschrieb, nur dass Du damit ein zusätzlich interne Adresse verwendet hast (ich schrieb das mit einer zusätzlichen externen Adresse). Allerdings ging aus Deiner Frage nicht eindeutig hervor, ob der Benutzer ein Postfach hat. Mit Postfach (was der häufigere Fall ist), wäre die Weiterleitung so nicht gegangen.

Manchmal ist die Exchange Bedienung unerwartet einfach. Leider nur "manchmal". Ja, wenn man die Adressrichtlinie selbst per Shell ändert, ok (ich arbeite auch oft genug in der Shell, die für viele Kleinigkeiten einfach schneller als die EMC ist). Aber wenn man damit manuell alle E-Mailadressen in den Benutzerkonten pflegen will, hat das einige Seiteneffekte (z.B. muss man dann pro Benutzer die Richtlinienverwendung deaktivieren, was bedeutet, dass gar keine Richtlinie für den Benutzer mehr greift), die man vorher wissen und beachten muss.

Ja, Du hast übersehen, dass man jede zu vergebenen Adresse nachträglich editieren kann. Einfach eine mit der Voreinstellung "vorname.name" auswählen und dann nachträglich "%g." wieder rausnehmen.

Keine Ahnung. TCP/IP und SMTP sind zwar Standards, aber weder lückenlos, noch ohne Interpretationsmöglichkeiten noch in allen Bereichen zwingend. Ohne eine detailierte Trafficanlayse wird man wohl nie herausbekommen, was genau bei Strato anders ist und woran sich Firewall oder Exchange stören.

Moin, nochmal: Warum per Script und Schleife manuell bauen, wenn eine E-Mail-Adressrichtlinie das doch offensichtlich perfekt abdeckt? Warum den Automatismus von Exchange umständilich nachbauen und dann bei jedem neuen Benutzer und jeder Änderung wieder alles manuell pflegen?

Was ich oft bei Firewalls finde, sieht wie folgt aus: Verbindung wird aufgebaut (Exchange protokolliert und sieht die Verbindung auch) Firewall unterbricht einfach irgendwann ist das für Exchange dann ein Timeout, da Exchange nichts von der Unterbrechung mitbekommen hat Als Ergebnis sieht das so aus, wie bei Dir: viele offene Verbindungen, und undefinierte Abbrüche im SMTP-Protokoll. Natürlich kann nicht ausgeschlossen werden, dass das auch ein Problem bei Exchange ist. Aber da Exchange 2003 aus dem Mainstream-Support ist und es daher keine Fehlerkorrekturen mehr gibt, mache ich mir wenig Hoffnungen, dass es an dieser Stelle eine Korrektur geben wird. Daher alle anderen Quellen ausschließen und wenn es dann wirklich nur noch Exchange sein könnte, über die Alternativen nachdenken.

Moin, nein, dass ist nicht möglich. Exchange "kennt" jeder intern benutzte Adresse intern, die falschgeschriebenen oder die eigentlich nicht möglichen. Daher wird die Mail immer an das Postfach gehen. Dort müsste dann eine Weiterleitung eingerichtet werden. Die geht aber nicht auf originale Externe Adresse (sonst Schleife), sondern müsste mit einer anderen Adresse gemacht werden, die Exchange nicht kennt.