RobertWi

Moin, das kommt entweder aus einer Transportregel oder von einem Fremdsystem. Exchange kennt die Fehlercode IMHO 999 nicht. Ich würde die Mail daher auch mal via Messagetracking und SMTP-Log verfolgen.

Moin, IMHO ist der Besitzer eines Termins immer ein User/Postfach. Und offiziell kann man den im nachhinein nicht ändern. Man kann zwar die Verwaltung über eine Gruppe und Vollzugriff machen, aber der Besitzer bleibt ein Postfach. Daher wäre es eventuell sinnvoller, wenn das über ein separates Postfach gemacht wird, nicht über eine Gruppe. Das Ding kann man notfalls immer normal einbinden. Und es hat den Vorteil, das da die entsprechenden Mails gesammelt werden können.

Nur, wenn von Anfang an ein CAS-Array eingerichtet wurde. Sonst muss das Profil in der Tat neu eingerichtet werden (zumindest offiziell, haben wir hier schon mal diskutiert inkl. eines Workarounds).

OK, danke für die Info.

Moin, wenn Du Dir nach dem Seeding in den Eigenschaften der fehlerhaften Kopie das Protokoll anschaust, wie lautet denn da der genaue Fehler? Eventuell siehst Du das Protokoll erst, wenn du nach dem Seeding im fehlerhaften Zustand die Kopie einmal "fortsetzt" und sie dann wieder angehalten ist.

Moin, was steht denn im Titel der Junk-Mail, wer die Mail in den Jun verschoben hat?

Da wir über Ex 2013 reden, ist das zumindest nicht unwahrscheinlich.

Moin, ja, damit wir die Exchange Organisation entfernt. Auf das normale AD hat es keine Auswirkungen. Die FSMO kannst Du danach ganz normal verschieben, der GC verschwindet mit DCPROMO von alleine. Kontrolliere aber vorher, ob bei allen Clients, Servern und besonders dem neuen DC der korrekte DNS-Server eingetragen ist. Das sollte der neue DC sein. Auch schadet ein Blick ins Eventlog der beiden DC und eine Prüfung mit "repadmin /showrepl" nicht. Wenn es Replikationsprobleme gibt, sollten die vorher behoben werden.

Bis heute hast Du uns ja nicht wirklich verraten, welche Art von Prüfung der Exchange vornimmt, die ein anderes Programm nicht kann. Ich wüsste da im Vergleich zu einem ET nichts, was ORF nicht auch oder besser kann. Und ob ein ET überhaupt an ein anderes Gerät außer Exchange senden kann (eingehend), weiß ich aus dem Kopf gar nicht. Kann durchaus sein, dass ein vollständiges Edge-Abonnement nur an einen HT sendet und dann hast Du nicht wirklich was gewonnen.

Moin, führ in der EMS mal den folgenden Befehl aus, Ausgabe müsste so aussehen, wie darunter: C:\>Get-MailboxRegionalConfiguration ALIAS| fl TimeZone TimeZone : W. Europe Standard Time Falls nicht oder es einen Fehler gibt, versuch mal, die Timezone manuell zu setzen: Set-MailboxRegionalConfiguration ALIAS -TimeZone "W. Europe Standard Time"

Die Mails sind doch verschlüsselt, was kann Exchange denn da prüfen? Und wenn Eure PGP-Lösung nicht mal eine einfache Empfängerprüfung hinbekommt, dann ist die wohl nicht wirklich enterprisetauglich.

Der OP hat ja 2010, aber solche Schleifen müssten auch mit einem Linked Connector nicht gehen. Er will ja jede Mail zwei Mal durch den Exchange schieben und da müsste es dann einen Filter geben, der erkennt, dass die Mail jetzt entschlüsselt ist, bzw. je nach IP-Adresse unterschiedliche Connectoren nehmen. Ein herrliches Szenario für bösere Schleifen und Mails, bei denen keiner mehr nachvollziehen kann, warum sie nicht angekommen sind.

Moin, es gibt in Exchange kein PolicyBased Routing (zumindest nicht das, was man landläufig im Firewall-Bereich son nennt). Das, was Du willst, wird sich sehr schwer mit Bordmittel und nur mit viel Bastelei mit Transportregeln, Zusatz Headern und einem erheblichen Risiko aufbauen lassen. Warum soll Exchange denn vor der Entschlüsselung, bzw, nach der Verschlüsselung die Mails ein zweites Mal anfassen? Sinnvoller wäre es daher, die Kette zu ändern: Mail -> PGP -> Exchange -> Client Client -> Exchange -> PGP -> Mail So funktionieren normalerweise alle Signatur/Verschlüsselungs Gatewaylösungen.

Moin, ist Benutzer C irgendwie ein priviligierter User (Admin, o.ä.)? Kann er mit der Gruppe auch eine neue Mail senden? Nachtrag: Und falls noch nicht passier, den Exchange auf aktuellen Stand bringen (sprich CU 6).

Du kannst in Exchange jedem Postfach jede E-Mail-Adresse zu weisen. Leg einen normalen Benutzer an, trag dort die administrativen E-Mail-Adressen ein und Du hast auf die Infos Zugriff. Merkwürdig ist die letzte Beobachtung allerdings schon, denn es ist normalerweise genau anders rum. Allerdings ist dann auch noch ein SBS, der macht wieder Dinge anders.

Moin, Exchange selbst braucht keinen SQL-Server, höchstens irgendein Dritt-Anbieter-Produkt.

Ohh.... Ich hatte mit mehr Gegenwehr gerechnet. :P Meistens arbeiten die Leute aus irgendeinem merkwürdigen, unsinnigen oder komischen Grund mit einem Admin und sind nur schwer zu überzeugen, dass das nicht sinnvoll ist und verstehen nicht, dass Microsoft da keine Rücksicht drauf nimmt.

Administrative Konten werden von AD besonders geschützt. Dieser Schutz verhindert, dass eine solches Konto EAS verwendet und es gibt auch andere Probleme damit (z.B. bei Senden Als). Seitens Exchange gibt es hier keine Lösung oder Workaround, denn die Philosophie ist ganz einfach: Mit Admin-Konten arbeitet man nicht.

Noch besser wäre es, den externen Zugriff komplett zu deaktivieren und möglich schnell auf mindestens 2010 zu gehen. Da wären dann auch problemlos OWA-Policys möglich, wo auf Userebene die ÖO abgeschaltet werden können.

OWAAdmin kann das doch aber nicht auf Userebene, oder? ist schon so lange her und habe ich eigentlich nur wegen der PW-Änderungsfunktion genutzt.

Exchange was? 2003 ist nicht mehr supported. Einen öffentlichen Zugriff auf den zuzulassen ist mehr als fahrlässig! (bei 2003 gab es IMHO noch keine Möglichkeit, den Zugriff zu begrenzen)

Moin, über welche Exchange Version reden wir denn?

Da das Thema ein wenig komplizierter ist und es Unterschiede zwischen den Einstellungen in Outlook und in OWA gibt, empfehle die die Lektüre dieses Artikels: http://blogs.technet.com/b/exchange/archive/2009/11/13/exchange-anti-spam-myths-revealed.aspx Darin ist auch beschrieben, wie man mit MFCMAPI zumindest auf die Spur des Verursachers kommen kann.

Richtig "sauber" würde das mit einer Exchange-Deinstallation und einen DCPROMO laufen. Aber natürlich wird man einen Exchange oder DC auch manuell loswerden - die Dinge können ja auch einfach mal ausfallen (wobei bestimmte Änderungen, z.B. die Schemaänderungen, nicht entfernt werden können).

Nein. Die FSMO können auch ohne Exchange Deinstallation übertragen werden. Nur den GC darfst Du auf dem SBS nicht löschen. DAS geht erst, wenn Exchange da runter ist.