RobertWi

Moin, hier ist das ganze nochmal für 2003: MSXFAQ.DE - How-To: Exchange 2003 SMTP-Connector Wie sieht den das aus, wenn Du die EMS alleine öffnest?

Moin, da ich Postfächer kenne, wo TotalDeletedItemSize > TotalItemSize ist, gehe ich davon aus, dass die Deleted nicht in der Gesamtsumme enthalten ist. Aber das kannst Du ja selbst überprüfen: Leeres Postfach, 5 große Mails rein, löschen bis in den Dumpster und die Zahlen überprüfen.

Moin, das ist vollkommen normal und RFC-konform: Jeder Server auf dem Weg "verewigt" sich mit seinem Namen. Da wird sicher auch nicht zu einem Spam-Verdacht führen, sonst würde jede Mail von jedem Mail-Server (auch bei Nicht-Exchange stehen die internen Server da drin!) bei GMX im Spam landen. Wenn Dich der Eintrag stört, könntest Du eine Transport-Regel bauen, die den Header-Eintrag löscht. Damit verlierst Du im Fehlerfall aber die Nachvollziehbarkeit. Ich denke, das das Problem woanders liegt, genau kann Dir das aber nur GMX sagen.

Das erklärt dann auch, warum nslookup fehlerfrei funktioniert hat - manchmal ist ein simpler ping besser. :)

Moin, na dann ist hier mal was zum Lesen: MSXFAQ.DE - Internet Mail Connector 2000/2003

Moin, HELO und PTR scheinen zu stimmen (von extern kommt dort übrigens ein Postfix). Vermutlich sendet Dein Exchange direkt ins Internet, ohne den Postfix als Relay-Host zu benutzen.

Moin, wo testest Du denn, intern oder extern? Geht die Verbindung intern (dann wird i.d.R. kein OA verwendet). Gibt es einen eingehenden Proxy, welchen?

Das dachten schon viele - und vergaßen die UAC. In welchen Exchange-Gruppen ist Dein Benutzer denn Mitglied?

BTW: heise online - T-Online-Mailserver von Blacklistings betroffen

Und was steht im MessageTracking und im SMTP-Log? Der Fehler 0x8004010f deutet daraufhin, dass das ein interner Empfänger ist oder war.

Die Updates sind übrigens kumulativ - das letzte reicht. BTW: Es gibt schon UR 5!

Außerdem tippt niemand solche Namen in der PowerShell von Hand ein: cd $exscripts + ENTER .\in + TAB-TASTE (bis der richtige Eintrag da ist) + ENTER Das dauert keine fünf Sekunden und Tipp-Fehler gibt es dabei auch nicht.

Kein Wunder, wird auch in der IIS-Konsole geprüft. Aber der Hinweis auf Proxy war auch gut und wird von mir um Firewall, Virenscanner, etc. erweitert.

Eben nicht. Self-Signed Zertifikate sind nicht supported, weil sie mal funktionieren und mal wieder nicht. Das hängt mit Betriebssystem, Service Pack und manchmal sogar mit einzelnen Updates zusammen. Welche Authentifizierungs-Methoden sind dem OAB eingestellt? Allerdings kannst Du den Browser nicht als Referenz nehmen, da hier explizit Outlook erwartet wird, verhält sich die Seite im Browser anders.

Moin, Zertifikat installiert? Ein Zertifikat sollte ohne Installation fehlerfrei sein, sonst kann das eine Fehlerquelle sein. Wenn Du keine Ex2007/2010 Erfahrung hast, solltest Du einen Kurs besuchen, ein Buch kaufe oder Dir mal jemanden für einen Tag ins Haus holen. Es ist schwer, aus der Ferne Autodiscover, Zertifikate und die verschiedenen Fehlerquellen zu beschreiben.

Moin, Office 2007 und Office 2010 verhalten sich gleich, was die Kalender angeht. Prüf mit Hilfe der "E-Mail-Autokonfiguration testen..." in Outlook, ob die dort erscheinenden URLs (vor allem die mit EWS) fehlerfreie sind und das Zertifikat korrekt ist.

Oder ein vernünftiges Backup-Programm mit Bricklevel-Recovery. Ein schöner Fall, dass sich der Wert eines Backup-Programmes nicht am Backup, sondern am Restore bemisst. ;)

Moin, ein wenig mehr Informationen, bitte! Wer sendet da an wen? Intern oder extern?

Moin, ich tippe darauf, dass die URLs für OAB oder EWS nicht fehlerfrei sind oder das Zertifikat nicht stimmt. Benutze mal die Funktion "E-Mail-Autokonfiguration testen..." in Outlook und überprüfe die dort per Autodiscover übergebenen URLs. Diese müssen für den Client fehlerfrei öffnenbar sein (Test mit MSIE). Wenn die URL nicht stimmt, muss die über die EMC/EMS korrigiert werden. Falls das Zertifikat falsch ist, wird ein fehlerfreies benötigt.

Moin, Frank beschreibt die HA-Optionen hier recht gut: MSXFAQ.DE - 2-Server-DAG Lizenzfragen können wir ohne Deine Verträge zu kennen nicht wirklich beantworten, also gehen wir mal vom Standard aus: Jeder Server eine Exchange-Lizenz.

Moin, in allen wichtigen Werkzeugen wird intern "ö" zu "oe" konvertiert. Es hilft also nichts, Objekte mit diesem Unterschied anzulegen, da dies unter Umständen für Exchange nicht unterscheidbar ist. Bessere wäre es, die Objekte anders zu benennen. Allerdings kann es sich auch um Verzögerungen mit dem Adressbuch handeln. Exchange cacht Berechtigung i.d.R. 2 Stunden, das Adressbuch wird eventuell bis zu 48 Stunden verzögert.

Moin, Port 443 ist HTTPS. RPC benutzt Port 135 + einen Port größer 1023. Dies mögen Firewalls nicht. Daher "tunnelt" Outlook Anywhere die RPC-Daten in HTTPS und benutzt HTTPS, um den CAS zu erreichen, der dann RPC auspackt und untern RPC weiterleitet. Norbert hat Dich falsch verstehen müssen, da Du oben von RPC und nicht von Outlook Anywhere redest. Bevor Dir wir Dir also sagen, was Du an Deinem Exchange konfigurieren willst, musst Du uns schon ein weniger genauer sagen, was Du am Ende erreichen willst. Die Einrichtung eines CAS-Arrays ist aber grundsätzlich nur sinnvoll, wenn Du einen Load Balancer hast, sonst wird der nicht funktionieren.

Sorry, kann ich nicht viel zu sagen. Mit Office365 konnte ich mich aus Zeitgründen noch nicht wirklich beschäftigen (zumal auch MVPs - sogar die von Exchange) nicht unbedingt Vergünstigungen beim Mieten von Office365 bekommen. Aber das wird nicht unbedingt klappen: Nach der Änderungen im MX geht alles auf den Office 365-Server. Was der nicht kennt (Person2) geht unzustellbar wieder zurück - nicht an den zweiten MX. Das Postfach "Person2" nützt Dir also nicht wirklich viel. Office365 kennt Koexistenz-Szenarien, aber ich weiß nicht, ob die auch mit Fremd-Produkten funktionieren. Daher wäre es eventuell besser, alles in ein System zu liefern und stattdessen mit einem "Eimmerketten"-Prinzip die Mails an das andere System weiterzuleiten: MSXFAQ.DE - Verbinden von Organisationen

Moin, die externe Adresse ist an dieser Stelle noch nicht wichtig (die wird später mal für Autodiscover wichtig). OWA muss auch ohne gehen, wenn es technisch von außen erreichbar ist. Das klingt eher so, als wäre in der Installation etwas schiefgegangen.

Moin, dann solltest Du mal analysieren, was bei den beiden Outlooks anders ist. Waren dort Autodiscover eventuell mit XML-Datei oder Regkey verbogen?