RobertWi

Moin,

das ist ein bekanntes Problem und wie Du selbst schon gesagt hast: Es liegt beim Absender.

Du musst bei Dir dafür sorgen, dass die Mail an keiner Stelle verändert wird. Das ist von MSFT auf dokumentiert: Email received from a sender using Outlook includes a Winmail.dat attachment

Wenn Du das gewährleistet hast, muss der Absender sein Verhalten ändern - dann hast Du keine Chance, was zu machen.

Du könntest dem Absender auch noch sagen, "dass es bei anderen Kunden ja auch klappt" nur solange geht, wie der Kunde Outlook einsetzt. Sobald der ein anderes Mail-Programm nimmt, klappt es nicht mehr. Und das wäre mir als Absender zu heikel.

Hab mal nachgeschaut: Die VM hat 4 GB RAM und 1x X5560 zugewiesen und dümpelt bei 2,6 GB RAM Auslastung und 5% bis 10 % CPU-Auslastung vor sich hin.

@RobertWi

TMG für OWA/EAS/OA extern -> TMG für die externe Kommunikation? Blech oder VM?

Hier eine VM (ESX), ca. 300 gleichzeitige EAS-User, gut 50 OWA/OA. Und ja, nur für Extern. Intern geht OWA/OA/EAS direkt auf die Cisco-LB.

Moin,

beim Kunden hier:

TMG für OWA/EAS/OA extern

dahinter Cisco-LB für zwei CASE

SMTP via Linux-Postfix

Moin,

nicht persönlich nehmen: Aber wenn die Zeit drängt UND Du Dich nicht mit PowerShell auskennst, hol Dir einen Fachmann dazu.

Ein Forum ist immer ein schlechter Ort für die Grundlagen-Vermittlung und in Programmierung noch besonders - da braucht man vor allem viel Erfahrung.

Und hier mal eben ein Script auf die Schnelle zu basteln, wird sicher schief gehen.

Warum da so komische Zeichen sind, kann man Dir nur beantworten, wenn Du beschreibst, wie genau exportiert wurde.

Nehmen wir mal Wetten an:

- Festplatte voll

- DB-Limit bei Standard-Edition erreicht

Bin gespannt, was im Event-Log steht.

Moin,

nein, reicht technisch mach es keinen Sinn. Wie Du selbst sagst, passiert der Vorgang des Verschiebens im Hintergrund, durch den Mailbox Replication Service MRS.

Allerdings habe ich bei Exchange schon viele Dinge erfahren, die auf den ersten Blick sinnlos erscheinen und es hätte mich nicht gewundert, wenn ein Schalter (aber eher nicht confirm) zwar den Hintergrund-Prozess anwirft, dann aber im Vordergrund auf das Ergebnis wartet.

Ausprobiert habe ich es aber noch nicht, d.h. Du bestätigst nur, dass sich Exchange wie erwartet verhält.

Ja, aber in eine normalen PowerShell, NICHT in der Exchange Management Shell.

Eventuell auch mit "-confirm:$true" oder "-confirm:$false" - je nachdem, was der Entwickler gerade geraucht hat. :)

Mmmh oder...

 

man kann ja in der Verwaltungsconsole einen Haken setzen Erst abschließen nach bestätigung. Wenn man nun die BadItems hochsetzt und dann aber einfach nicht abschließt kann man vielleicht das Protokoll einsehen ohne zu verschieben. Mal testen.

Der verschiebt aber zu 95% und hält dann an, wenn der Benutzer getrennt werden soll. Das Trennen kann man damit auf später verschieben.

Siehe hier: https://robertwilleswelt.wordpress.com/2011/01/22/mailbox-verschieben-in-exchange-2010-wofur-steht-die-prozent-anzeige/

Bei "confirm" kann es sein, dass sich das in der EMS anders verhält, als in einer nackten PowerShell (das hat etwas mit der Einbindung der CMDLET zu tun und trifft auch auf warningaction zu).

Probier mal confirm wie folgt aus:

Normale PowerShell öffnen und Exchange-Snapin hinzufügen:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

Darin nochmal den Befehl mit "-confirm" benutzen. Würde mich nicht wundern, wenn Du da was anderes erlebst.

Moin,

1. eine Simulation gibt es nicht.

2. Alternativ könnte man probieren, mit "BadItem 0" zu spielen, dann "BadItem 1" usw.

2. Du kannst probieren, wie "-confirm" reagiert. Das ist aber nicht vorhersagbar, weil es Aufgabe des Programmierers ist, festlegen, was er confirmed haben möchte.

Moin,

das von außen kannst Du im SMTP-Protokoll sehen - so den eingeschaltet.

Intern geht das IMHO nicht, da Exchange hier wie Du selbst sagst nur "das Postfach" kennt und E-Mail-Adressen nur zweitrangig sind.

Moin,

leider habe ich keinen SMTP-IIS mehr, kann Dir aber sagen, dass man dort mehrere Domänen einrichten kann und IMHO auch unterschiedliche Relay-Einstellungen. Die Einstellungen sind aber nicht groß unterschiedlich zum Exchange 2003, weil dort der gleiche IIS-SMTP benutzt wird.

Wenn das Ding für Euch so wichtig ist, dann ist es aber umso wichtiger, dass es auf einer supporteten Plattform läuft. Noch ist Windows 2003 zwar ok, aber wenn der Support ausläuft und dann Fehler auftauchen, seit ihr den Webshop schneller los, als ihr schauen könnte.

Vielleicht solltet ihr aber für das ganze einen Berater ins Haus holen. Es ist schwer, in einem Forum fragen zu beantworten, wenn man nicht alles genau kennt. Und da das System wichtig ist, kann es dann auch nicht an ein paar Euros scheitern.

Moin,

ja, das kann man problemlos machen. Habe ich eine Zeitlang auch gemacht (und dann da noch Anti-Spam mit ORF gemacht).

-> SMTP installieren (Teil von IIS)

-> Neue Domäne einrichten und diese als Relay konfigurieren

-> Als Smarthost Euren DynDNS einrichten

-> MX-Einträge auf den exteren SMTP umstellen

Allerdings ist Windows 2003 nicht mehr wirklich lange im Support und im Internet würde ich einen solchen Server nicht mehr betreiben.

Ein vServer mit Windows ist doch nicht so teuer und hätte dann ein aktuelles BS.

Vorher würde ich allerdings noch mal überprüfen, ob es WIRKLICH an der Dyndns-Adresse liegt. Nicht das z.B. Euer Spam-Filter die Mails blockiert.

Nachtrag: Im Prinzip müsste man drei Tests machen, um sich bei Exchange sicher zu sein, das man kein falsch konfiguriertes Relay hat:

- beliebige Absender und beliebige Empfänger

- bekannte Absender und beliebige Empfänger (weil ich theoretisch einen Connector so umbiegen kann, dass er Anonym mit interner Domäne akzeptiert - nie probiert, k.A. ob das wirklich funktioniert).

- beliebige Absender und bekannte Empfänger - was aber in den meisten Fälle gewollt sein dürfte

Alles andere sind nur Angriff auf den SMTP-Server und Tests, wie gut MSFT die RFC-Spezifikation implementiert hat. Und sollte dabei ein Test erfolgreich sein, könnten wir eh nichts dagegen machen.

Hier werden auch mehrer Schritte durchgepielt: Open Relay Test

Schau Sie dir genau an: Das ist 18 Mal GENAU DAS GLEICHE. Nur die verwendete Mail-Adresse unterscheidet sich.

Da wird mit Fehlern im Server gespielt, aber technisch ist es immer das gleiche: Ein Relay Test ohne Authentifikation.

Relayen zu bewegen. ;)

Der OP fragte aber noch einem offenen Relay - und da gibt es IMHO genau einen Test.

_http://www.abuse.net/relay.html_ ich weiß nicht, warum das bei euch nicht geht. Bei mir geht da die Seite korrekt auf.

Auch, wenn Du auf den Knopf "Test for relay" klickst?

nein, aber ich kenne Server die für diverse Methoden anfällig sind.

Bei Exchange? Exchange kennt genau zwei Methoden des Relay: Mit oder ohne Authentifikation. Nur bei "mit Authentifikation" kann man noch ein paar Varianten unterscheiden.

Aber bei "ohne" ist das Relay offen, oder nicht.

@iDiddi: Das ist ein stinknormaler offener Relay Test, genau der gleiche, den auch EXRCA macht.

und dass genau ein Relaytest versucht wird. ;)

Hmmmm.... Bei einem Relay für alle gibt es nicht "nur ein bißchen" offen. Offen oder nicht, ist die einzige Auswahl.

Was sollte es denn bringen, zehn mal zu testen und zehn mal das gleiche Ergebnis zu bekommen?

Oder kennst Du Server, die zufällig den Zustand des Relays wechseln?

Und noch dazu funktioniert die Adresse von Norbert nicht, nach dem klick auf "Test for relay" gibt es nur "Not Found - The requested URL /cgi-bin/relaytest was not found on this server."

Moin,

dann werden wir bei der Policy wohl den Fehlerfall haben (ohne ihn erklären zu können).

Korrektur sollte mit

set-mailbox search -RoleAssignmentPolicy "Default Role Assignment Policy"

möglich sein. Zumindest ist das die Standard-Richtlinie auf meinen Servern.

Moin,

kannst Du denn das Postfach selbst über OWA oder Outlook öffnen?

Was sagt "Get-Mailbox search| fl *role*"?

Aha, und der testet auf open relay?

 

Bye

Norbert

Ja, wenn man den Test "eingehende SMTP-E-Mail" auswählt.

Dann lautet der letzte Prüfschritt:

"Der MX blablub.de wird auf offenes Relay getestet, indem ein Relay zu Benutzer Admin@TestExchangeConnectivity.com versucht wird.

Der Open Relay-Test war erfolgreich. Dieser MX ist kein Open Relay."

Ist aber wirklich gut versteckt.

Moin,

nicht persönlich nehmen, niemand kann alles kennen: Aber da Dir absolutes Grundlagenwissen fehlt (offensichtlich weiß Du noch nicht mal, wo auf dem Server die Datenbanken und Transaktionsprotokolle liegen), solltest Du Dir jemanden dazuholen, der sich mit der Materie auskennt.

Schau ihm dabei für die Schulter, dann kannst Du dabei was lernen. Aber in einem Forum wird das nur Stochern im Nebel.

Und ergänzend dazu: POP3 Abschalten und auf SMTP umstellen. Geht schneller und hätte wahrscheinlich auch viel schneller eine Fehlermeldung gegeben.

Moin,

mit verschleierten Domänen lassen sich diese Art von Problemen quasi nicht lösen, da alles nur raten ist.

Du solltest Dich also mal mit SPF beschäftigen und sicherstellen, dass es bei Deinen Domänen keine fehlerhaften SPF-Einträge gibt.

Aber was und wie Du korrigieren musst, ist ohne die Angabe von echten Domänen und echten IP-Adresse von uns nicht zu klären.