rm-rf
-
Gesamte Inhalte
7 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von rm-rf
-
-
Ja stimmt hab ich mich ein wenig undeutlich ausgedrückt.
Es geht um die Übermittlungsbestätigung (DNS).
-
Hallo,
wir haben einen Exchange 2010 SP1 und davor einen Postfix-Server als Smarthost (Sendeconnector).
Jetzt ist uns aufgefallen, dass die Lesebestätigung, bzw. Outlook nennt es Übermittlungsbestätigung, nicht richtig funktioniert.
Wenn ich z.B. über Exchange von Outlook aus an GMX sende, erhalte ich eine Mail Delivery System Nachricht in der steht:
Die Zustellung an diese Empfänger oder Gruppen ist abgeschlossen. Vom Zielserver wurde keine Zustellungsbenachrichtigung gesendet:Header für diese Nachricht:
Received: from mail.xxx.de (xx.xxx.xxx.xxx) by exchange2010.net.xxx.de(192.168.3.11) with Microsoft SMTP Server id 14.1.218.12; Thu, 15 Sep 2011
08:50:30 +0200
Received: by mail.xxx.de (mailer@xxx.de) id BF214640003; Thu, 15 Sep
2011 08:52:36 +0200 (CEST)
Date: Thu, 15 Sep 2011 08:52:36 +0200
From: Mail Delivery System <MAILER-DAEMON@mail.xxx.de>
Subject: Successful Mail Delivery Report
To: <absender@xxx.de>
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="92B34640004.1316069556/mail.xxx.de"
Content-Transfer-Encoding: 7bit
Message-ID: <20110915065236.BF214640003@mail.xxx.de>
Return-Path: <>
X-MS-Exchange-Organization-AuthSource: exchange2010.net.xxx.de
X-MS-Exchange-Organization-AuthAs: Anonymous
Auf dem Postfix-Server, welcher ja die E-Mails zuerst annimmt kommt eine korrekte Nachricht an.
"Your message was successfully delivered to the destination(s)
listed below....."
Return-Path: <MAILER-DAEMON>Delivered-To: absender@xxx.de
Received: by mail.xxx.de (mailer@xxx.de)
id BF214640003; Thu, 15 Sep 2011 08:52:36 +0200 (CEST)
Date: Thu, 15 Sep 2011 08:52:36 +0200 (CEST)
From: MAILER-DAEMON@mail.xxx.de (Mail Delivery System)
Subject: Successful Mail Delivery Report
To: absender@xxx.de
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="92B34640004.1316069556/mail.xxx.de"
Content-Transfer-Encoding: 7bit
Message-Id: <20110915065236.BF214640003@mail.xxx.de>
Interne E-Mails zu schicken (also zwischen Konten auf dem Exchange) klappt auch.
"Ihre Nachricht wurde den folgenden Empfängern zugestellt:"
Logischerweise muss ja jetzt der Fehler irgendwo zwischen dem Postfix und dem Exchange liegen.
Postfix erhält ja die korrekte Bestätigungsemail vom Zielserver.
Weil der Satz "Vom Zielserver wurde keine Zustellungsbenachrichtigung gesendet" (und dann ist die korrekte Empfängeradresse, also z.b. GMX, angegeben) für mich eher heisst, dass hier mit "Zielserver" unser Postfix gemeint ist.
Der Postfix macht ja nur eine normale Weiterleitung der E-Mails auf den Exchange. Seltsam nur, dass er die Bestätigungsemails nicht einfach 1:1 weiterkopiert.
-
Hallo,
3 Mitarbeiter greifen auf einen öffentlichen Ordner zu, in dem Aufgaben gespeichert werden.
In nächster Zeit wird die Anzahl der Einträge immer weiter wachsen und jetzt stellt sich die Frage: Wann verweigert Exchange 2003 die Arbeit?
Also es werden so 4000+ Einträge.
Hat jemand praktische Erfahrungen oder Werte?
Man müsste halt wissen, wie viel Exchange 2003 verträgt, damit die Arbeit nicht eingeschränkt wird oder die Umstellung auf den öffentlichen Ordner nicht umsonst ist, weil dann mal wieder alles hängt und abstürzt etc. o.ä.
-
Leider kann ich dazu kein Feedback geben.
Aber es funktioniert jetzt, keine Zertifikatswarnungen mehr!
Warum weis ich nicht und möchte jetzt auch nichts umstellen.
Aber ich kann ja trotzdem schreiben was ich getan hatte:
Am 22.03. funktionierte der Exchange nicht mehr. Man kam nicht mehr in die Shell und auch nicht mehr in die Managementconsole.
Zum Glück hat ich ein paar Tage vorher ein Snapshot gemacht.
D.h. ich war auf dem Stand bevor ich HTTP Redirect versucht hatte.
Zur Erklärung:
Das ganze läuft in VMware und wir haben 2 zusätzliche IPs.
Der Exchange hatte eine und der DC hatte eine bekommen. Weil ich jetzt 2 IPs für Exchange brauchte hab ich dem DC die weggenommen.
(DC .117, Exchange .115)
Ich hatte, wie im Whitepaper angegeben, der Netzwerkverbindung die 2. IP zugeteilt.
Dann bei domain2go.net die DNS Einträge überprüft und autodiscover.domain.de auf .117 gestellt.
Bevor ich das IIS konfigurieren wollte, hab ich nochmal einen Test gemacht und dann ging es.
Also die Default Web Site hat keine IP Bindungen und habe demzufolge das Whitepaper nicht weiter befolgt.
Warum dies funktioniert ist mir rätselhaft, aber freue mich, dass es funktioniert :)
-
Bei domain2go.net kann man keinen SRV Eintrag anlegen.
Ich versuch jetzt mal White Paper: Exchange 2007 Autodiscover Service
"Using the Autodiscover service with redirection may be the ideal solution because some DNS providers do not support SRV records." klingt ja schonmal vielversprechend.
-
Hallo,
ich komm einfach nicht weiter und wollte nun hier um Hilfe fragen.
Folgende Konstellation:
- Exchange 2010 auf einem Server 2008 SP2
- 2. Server 2008 SP2 als AD
Beide stehen im Rechenzentrum und daher geht es nur um Verbindungen von Outlook ausserhalb der Domäne.
- interne Domäne und externe (im Rechenzentrum) heißen gleich
Hab schon viel gelesen, aber beim Start von Outlook kommt immer eine Zertifikatswarnung von autodiscover.domain.de und FQDN (also exchange.domain.de).
autodiscover.domain.de stimmt nur der Name nicht mit dem Zertifikat überein und bei exchange.domain.de ist es der Name und die Vertrauensstellung der ausstellenden Firma.
Ich habe bei startssl.com ein Zertifikat für mail.domain-mx.de erstellt, welches auch funktioniert.
(die mail.domain.de ist unser Linuxmailserver und der Exchange läuft dann auf mail.domain-mx.de)
Outlook fragt ja standardmäßig autodiscover.domain.de ab.
Also hab ich im externen DNS (domain2go) autodiscover.domain.de auf die IP des Exchange im Rechenzentrum geleitet (domain.de ist unser Webserver).
Ergebnis: Zertifikatswarnung in Outlook meckert nur noch über die verschiedenen Namen
Also bräuchte man ein SAN-Zertifikat, welches ich aber für die Testumgebung nicht bekomme und es soll ja auch ohne SAN lösbar sein.
Wollte es mit HTTP Redirect versuchen.
Exchange-Verwalltungskonsole -> Serverkonfiguration -> ClientAccess:
owa, ecp, ActiveSync und oab die interne und externe URL auf
https://mail.domain-mx.de/xxx geändert
(vorher war nur intere URL mit dem FQDN/xxx gesetzt)
Den SCP, also AutoDiscoverServiceInternalUri, auf https://mail.domain-mx.de/Autodiscover/Autodiscover.xml geändert, obwohl das nur nötig ist, wenn man in der gleichen Domäne wie der Exchange ist?!
Im IIS eine neue Site angelegt "autodiscover_redirect", Ordner Autodiscover erstellt und die autodiscover.xml und dann nach mail.domain-mx.de/Autodiscover/Autodiscover.xml umgeleitet.
Durch die neue Seite musst ich ja Port 80 bei der Default Web Site rausnehmen und dadurch geht die Umleitung von http auf https nicht mehr....schade
Was hab ich falsch gemacht oder was muss ich genau machen damit ich mit einer IP und einem Zertifikat, welches auf mail.domain-mx.de ausgestellt ist keine Zertifikatswarnungen bei Outlook bekomme?
(das Einloggen beim Outlookstart nervt, lässt sich ja leider nicht ändern, zum Glück wurde in 2010 mal an einer Kennwort speichern Checkbox gedacht...)
Server 2012 verfügbar
in Windows Forum — Allgemein
Geschrieben
Du hast 1 Jahr Zeit für die Migration.
"Muss ich auf die neuen Versionen umsteigen?
Ja, gemäß der Bestimmungen des Microsoft Partner Network, müssen Sie jedes Produkt der Microsoft Action Packs innerhalb von 12 Monaten aktualisieren. "
https://partner.microsoft.com/germany/40165018