RobertWi

Moin, dann würde ich auf dem Client mal die OST-Datei löschen und neusynchronisieren.

Moin, davon habe ich zwar noch nie gehört, könnte mir aber theoretisch vorstellen, dass es was mit dem Cache Mode zu tun hat. Und dann würde gelten, dass man in OWA via Papierkorb löschen sollte.

Moin, bei Exchange 2003 gibt es noch keine "einfachen" Möglichkeiten, hier würde man Programme via WebDAV einsetzen. Outlook Macros gehen sicher auch, Google findet zum Beispiel das hier: RDO - Folder Set permissions on an Outlook folder with vbscript

Moin, "Übermittlungsberichte" benutzen IMHO das Messagetracking. 30 Tage Aufbewahrung ist da der Standardwert, Deine Beobachtung passt dazu. Den Zeitraum musst Du über die EMS anpassen. Mit "Get-TransportServer | fl identiy,message*" bekommst Du die aktuellen Werte heraus. Änderungen dann mit "Set-TransportServer" usw.

Klar. Die Agent bekommst Du mit .\install-AntispamAgents.ps1 wieder und der Standwert für SCLJunkThreshold ist 4.

Moin, in Outlook gibt es keine Rekursion (und auch keine echte Vererbung). Eventuell kann man am Exchange was machen, aber dafür müsste man die Exchange-Version wissen.

Moin, in der EMS folgenden Befehl ausführen: Set-OrganizationConfig -SCLJunkThreshold 9 Danach kannst Du die Transport-Agenten für Anti-Spam auch komplett deaktivieren: cd $exscripts .\uninstall-AntispamAgents.ps1 auf allen HT ausführen und jeweils den Transport-Dienst einmal neustarten. Danach sollte der "Spuk" vorbei sein.

Moin, zur Migration: Das ärgerliche ist, dass Du jetzt schon mindestens einen Zwischenschritt brauchst (auf Exchange 2003 oder 2007, bevor Du auf Ex2010 gehen kannst). Mit dem Erscheinen des nächsten Exchange-Server wird es wohl keine Unterstützung für Exchange 2003 mehr geben, das macht die Sache dann auch nicht leichter. Aber auf einer nicht-supporteten, nicht mehr gepatchten und damit mit Sicherheitslücken laufenden Software zu fahren, geht IMHO nur, wenn die Software extrem unwichtig ist oder wenn man sehr risikofreudig ist. :(

Moin, beim OP geht es ja offensichtlich nicht um Spam, sondern um falsch-positive und das kann ich nachvollziehen. Gerade wenn dort nur sehr wenig drin landet, dann schaut man nicht so oft in diesen Ordner und bemerkt dort liegende Mails erst Tage später. Bei mir landen danke gutem Spam-Filter quasi nur noch falsche-positive im Junk-Mail-Ordner und bei sieben eingebundenen Exchange-Konten übersieht man schon mal einen Junk-Mail-Ordner. Die Konsequenz: Jeder Filter in diesen Ordner habe ich deaktiviert.

NEIN. Du kannst nur SERVERS löschen, das schreibe ich aber oben auch. Wenn Du Standort löschst, gehe Deine öffentlichen Ordner nicht mehr.

Moin, dann schau doch ins SMTP-Protokoll. Dort wurde die IP-Adresse des einliefernden "Servers" protokolliert.

Moin, nein, das reicht aus. Und den Container CN=SERVERS auch gleich noch löschen (wenn er leer ist), aber NICHTS darüber.

Nicht für den Client-Zugriff.

Moin, ich verstehe schon Dein Problem. Technisch gesehen hast Du dann halt leider keine Loop. Du hast jedesmal eine neue E-Mail, nur leider sehr viele davon in beide Richtungen. Damit wird es auch schwer, dort eine sinnvolle Erkennung hinzubekommen. Für Exchange gibt es da leider keine Bordmittel. Man könnte einen Transport-Agenten programmieren, der über solche Mails Buch führt. Mal abgesehen vom Datenschutz, stelle ich mir das aber nicht gerade trivial vor, weil ich immer unterscheiden muss, zwischen gewollten und ungewollten Mails. Und das schlimmste: Es darf keine falsch-positiven geben, denn ich will die Mails ja wegwerfen (NDR geht aus verständlichen Gründen nicht). Wenn meine Erkennung versagt und ich lösche Mails, die nicht hätten gelöscht werden dürfen, erfährt das niemand. Für einen Mensch wird so eine Erkennung leicht sein, über eine Maschine aber nur mit einer wahrscheinlich nicht mehr akzeptablen Fehlerquote. Ob es bei fremden Produkten oder anderen Mail-Servern da was gibt, kann ich nicht sagen. An den grundsätzlichen Problemen ändert das aber nichts. Als eine Möglichkeit würde ich ein gutes Monitoring sehen, dass bei Auffälligkeiten "unterbricht" und auf eine menschliche Entscheidung wartet. Dabei könnte die Throttelinpolicy von Exchange helfen. Da gibt es eine Option "MessageRateLimit". Die Hilfe sagt dazu: Das blockt nicht komplett, führt aber zu Verzögerungen. Im Standard ist der Wert nicht gesetzt, es sollte als keine Verzögerung geben. Da man die Throttelingpolicy pro Mailbox setzt, kannst Du damit den einen oder anderen Lernresistenten wenigstens ein wenig bremsen. Aber auch hier: Die Richtlinie greift auch bei gewollten Mails.

Moin, ich habe in mehr als 10 Jahren Exchange-Erfahrung mit inzwischen tausenden Mailboxen noch nie von einem Fall gehört, wo Exchange an einer Loop schuld war. An Loops waren entweder Benutzer, Fehlkonfigurationen oder andere Mails-Systeme schuld. Du kannst dazu nichts einstellen und es ist auch nicht notwendig, denn: - Exchange erkennt "echte" Loops (siehe meinen Link) - Exchange antwortet nicht auf DSN, wenn diese RFC-konform sind - Exchange schickt Abwesenheitsnachrichten nur einmal pro Abwesenheit und Empfänger raus Du musst Dir also einen konkreten Fall anschauen und sehen, warum es hier zu einer Loop gekommen ist und dann sehen, wie Du das abstellen kannst. Wobei das vermutlich nicht einfach sein wird, wenn das Fremdsystem oder Anwender an der Loop schuld ist.

Moin, so kann es funktionieren, wenn Du nicht die ganze Domäne umstellen willst. Das Nette daran: Du kannst beides parallel fahren und erstmal mit einigen Konten testen.

Moin, das kann Exchange selbst: Understanding Recipient Resolution: Exchange 2010 Help (Abschnitt "Detection of Recipient Loops").

Moin, it's not a bug, it's a feature und nennt sich "Automapping": Exchange 2010 SP1 "Auto Mapping" Feature

Moin, die direkte Abfrage aus MySQL geht nicht, Du musst die Daten schon ins AD schaufen. Aber wenn Du sie zur Zeit in ein LDAP schiebst, bekommst Du sie doch genauso ins AD. AD ist ja nur ein aufgebohrtes LDAP. Dort legst Du dann Objekte vom Typ "contact" an und am Ende braucht es nur noch einen PowerShell-Befehl, um das Ding für Exchange zu aktivieren. Du kannst natürlich auch Importe aus CSV machen, würde ich aber lieber per PowerShell und nicht per VBS machen.

Moin, und was gibt es für eine Fehlermeldung? Und was steht im SMTP-Protokoll?

Nö. Du kannst bei deinen bisherigen Postfächern beim Provider eine Weiterleitung einrichten auf eine Adresse, die dann auf Deinen Exchange zeigt. Dann gehen die Mails über den Provider, der filtert ordentlich und bei Euch kommt nur gefiltertes an. Es gibt Würg-Arounds, aber das heißt nur, den Teufel mit dem Beelzebub austreiben. Richtig sauber ist nur SMTP-Zustellung. Dann hätte es bei diesen Mails eine saubere Unzustellbarkeitsnachricht gegeben und der Absender wüsste bescheid. Im Augenblick bekommt es niemand mit und im schlimmsten Fall sind die Mails verloren. Diese Funktion ist nur für Migrationen gedacht, um den Inhalt von fremden Postfächern einmalig in den SBS zu transferieren. Danach soll auf SMTP-Zustellung umgestellt werden. Und das das nicht problemlos funktioniert, liegt nicht an MSFT, sondern an den Protokollen SMTP/POP3 Du wirst keinen POP3-Connector finden, der 100%ig funktioniert. Es gibt nur welche die mehr und welche die weniger Probleme haben. Ich hab mich bisher nicht wirklich mit der SMTP geschichte beschäftigt, der SBS2011 hat beim Kunden einen Uralten W2000 Server ersetzt auf dem AVM Ken! lief, dort wurde die Mails ebenfalls per POP3 abgerufen. Da es damit nie Probleme gab hat in meine Augen nichts dagegen gesprochen die Mails auch mit dem SBS per POP3 abzuholen. Und da Microsoft die Funktion anbietet gehe ich mal davon aus das sie auch funktionieren sollte.

Moin, wohin wird die Forward-Lookup-Zone zeigen? Ins Internet oder auf einen anderen internen DNS, der die Adresse des neuen Exchange kennt?

Prima, das freut mich. War ja doch eine etwas aufwendigere Aktion, aber das Ergebnis zählt!

Ja, wieder eines der Probleme, dass man ohne POP3-Abholen gar nicht erst hätte. :(

Moin, Du legst eine akzeptierte Domäne mit Typ "internes (!) Relay" an. Entweder zeigt dann Dein interner DNS auf den Exchange 2010 (dann musst Du nichts mehr machen), oder Du legst zusätzlich einen Sende-Connector für den Adressraum Deiner neuen Domäne an, der als Smarthost den neuen Exchange hat. Achtung: Wenn Exchange 2010 auch über den alten SBS raussendet, kann es beim Senden an die neue Domäne zu Schleifen kommen, wenn man nicht aufpasst! Falls der neue Connetor nicht zu greifen scheint, ändere noch den Kostenfaktor so ab, dass der Standard-Connector eine höhere Zahl bekommt, als der an die neue Domäne.