RobertWi

Solange wir uns einig sind. :)

Und die Ausgabe von "Get-CmdletExtensionAgent | ft Name,Enabled,IsSystem"?

Ich gehe von Ol 2010 aus, weil Du nichts anderes gesagt hast: Das kommt darauf an. Höchstwahrscheinlich taucht es dank Automapping von ganz alleine auf: Exchange 2010 SP1 "Auto Mapping" Feature Allerdings hat Automapping auch Nachteile: Der Absender wird nicht automatisch vorausgewählt, keine automatische Signaturauswahl, keine automatische Ablage im richtigen Postfach. Wenn Du das nicht willst, musst Du den AD-Eintragm wie im Link gezeigt, entfernen und das Postfach als weiteres Konto einbinden (nicht in den Einstellungen des vorhandenen Kontos, sonder als neue Konto!).

Ja. Sie "empfangen" darüber nicht, die dürfen damit auf den Inhalt eines anderen Postfaches zugreifen. Aber mehr als die beiden Dinge sind in Exchange nicht einzustellen.

Ach ja, stimmt, die Begrenzung hatte ich vergessen. Ärgert mich auch manchmal. Bei dem Rest warte ich ab.

Moin, 1. Bitte versuche herauszufinden, ob der Fehler bei get- oder bei set-Mailbox auftritt. Ändere hierzu die Zeile: get-mailbox -identity $args[0] | set-mailbox -CustomAttribute3 "Lync" -DomainController <DC> In: $a = get-mailbox -identity $args[0] $a | set-mailbox -CustomAttribute3 "Lync" -DomainController <DC> 2. Wenn Du den "fehlerhaften" Befehl identifiziert hast, bitte diesen um den Schalter "-verbose" ergänzen und das Script nochmal ausführen und die Ausgabe hier posten. 3. Bitte mal folgende Ausgabe posten: Get-CmdletExtensionAgent | ft Name,Enabled,IsSystem Ach ja: Und allgemein ist es hier lieber gesehen, wenn Du nicht mit Screenshots arbeitest, sondern mit C&P den Fehler rauskopierst. Das hat auch den Vorteil, dass Suchmaschinen Deinen Fehler indexiert und andere Leute den auch finden könnten. Aber ich bin kein Moderator, d.h. das nur als Tipp. ;)

Du findest es übertrieben, dass Leute Dir Dir hier kostenlos helfen, Dich bitten, ein wenig mitzuarbeiten? Nun gut. Ich habe kein Problem, ich wollte nur helfen.

Bei Usern, die bereits auf Ex2010 waren, wäre eine Korrektur relativ einfach, das hebt set-mailbox mit. Bei Usern, die noch nicht migriert waren, wird eine Korrektur sehr aufwendig. Pro Userobjekt sind es einige Attribute, aber dann sind noch die sehr vielen Attribute, über die man via ADSIEdit kommt. Das einzige wo ich sicher bin: Bei einer neuen Struktur wird man später weniger Probleme haben.

Wieso? Du kannst einen beliebigen neuen Receive-Connector anlegen und dort die Remote IP-Adresse der Exchange Server eintragen. Dann wird nur dieser Connector von den Exchange Servern benutzt. Hier kannst Du dann wegen TLS den FQDN nicht ändern. Bei den anderen Connectoren nimmst Du die Exchange Server-Berechtigung raus und kannst dann auch den Namen ändern. Wir sprachen doch über Receive-Connectoren und den FQDN, das hat doch mit dem Postfach nichts zu tun.

Ja, dann hast Du die Stelle gefunden und herausbekommen, dass Du es nicht ändern kannst. Alternativ könntest Du einen weiteren Connector einrichten, dort die Remote Adressen der Exchange-Server vergeben und dann nur auf dem neuen mit der Berechtigung "Exchange Server" arbeiten. Dann kannst Du den Default auch ändern.

Man muss die Scripte auch lesen und verstehen und in seine Umgebung umsetzen. Niemand hier hat die Zeit, für Dich die fix-und-fertig Lösungen zu übernehmen. Mit dem Befehl änderst Du nur Mailboxen. Wenn Du in anderen Objekten noch ein Leerzeichen hast, werden die natürlich nicht angefasst. Nimm meine Links, da sind diverse Beispiele drin. Speziell in dem von Frank ist ein Beispiel, dass falsche Zeichen in allen Objekten sucht.

Ja, sollte er. Wobei hier nur der Empfangsconnector wichtig ist. Poste mal die Ausgabe von "Get-ReceiveConnector | fl Name,fqdn"

Hast Du Dir die Links angeschaut in Post #12?

Ganz ehrlich: Würde ich auch so machen. AD ist die fundamentale Grundlage für Exchange und viele andere Produkte. Wenn ich zu einem Kunden gehe und Exchange "einführe", dann analysiere ich zuerst AD und beginne mit Exchange erst, wenn AD nachweislich sauber läuft. Solange Du AD-Probleme hast, wirst Du mit Exchange vermutlich nie auf einen grünen Zweig kommen. Und irgendwann wird es dann eine Frage des Geldes: Wie lange will man noch suchen und was kostet das und wie lange braucht es, das Ding sauber neu aufzubauen. Viel Glück auf jeden Fall und Ontrack wird sicher eine gute Hilfe sein!

Wobei meine Antwort natürlich ohne 100% Gewähr ist, denn es sind ja auf der anderen Seite auch Server und Spamfilter beteiligt und niemand kann richtig vorhersagen, ob da nicht einer "wild" läuft und bei "merkwürdigen" Header-Einträgen doch ablehnt. Aber im Prinzip kann es nicht schaden. (Im Gegenteil könnte es sogar positiv sein: Gmail verweigert die Annahme, wenn mehr als 15 Hoops benutzt worden sind. Durch das Entfernen des Headers senkt man die Anzahl der Hoops.)

Nö, das dürfte unkritisch sein. Du nimmst Dir damit nur die Möglichkeit, den Mailflow nachvollziehen zu können. Aber wenn Du das weißt, kannst Du ja für Troubleshooting die Regel kurz deaktivieren.

Moin, das klingt eher danach, als wären die Server unterschiedlich konfiguriert. Sind die Receive-Connectoren wirklich identisch (lieber mal per Shell prüfen)? Wie erfolgt den das LB bei SMTP - über einen gemeinsamen Namen und NLB oder über Round Robin und DNS?

Moin, das bekommst Du nicht "sauber" weg. Mit Bordmitteln gar nicht, aber Du könntest mit einem Proxy oder eigenem Transport-Agenten da eingreifen. Gefährlich wird es bei der Message-ID. Die wird von Exchange z.B. auch für die Dupletten- und Schleifenerkennung benutzt. Wenn hier falsch verändert wird, dann können Schleifen entstehen.

Prima, das freut mich! Natürlich ist das Einarbeiten der Logs wichtig, den da stecken ja Daten drin. Sonst bräuchten wir die Logs ja nicht, oder. :) Wobei ich Deine Schritt nicht als pauschal ansehen würden. Man muss schon bei den einzelnen Schritt und eventuellen Fehlern ein bisschen anlysieren. Nach eseutil /r kann die Datenbank schon "Clean Shutdown" sein, dann ist kein eseutil /p notwendig. Auch isinteg ist nur dann notwendig, wenn eseutil /p auf eine "Dirty Shutdown" Datenbank angewendet wird. Wäre die nach /r Clean, dann wären /p und isinteg überflüssig, usw.

Nein - das war aber schon vorher "verboten" (warum wohl.... ) Erlaubt sind: Weiter Infos auch mit ein paar Scripten: Exchange 2007 Scripting Corner: fix-alias - Exchange Team Blog - Site Home - TechNet Blogs MSXFAQ.DE - FixAlias How to Remove Spaces From Recipient Aliases by Using the Exchange Management Shell: Exchange 2007 Help

Moin, an der Stelle greift noch kein Connector. Das ist die MAPI-Submission von Mailbox-Server. IMHO kann man das nicht ändern. Aber Du könntest mal mit ExternalDSNReportingAuthority und InternalDSNReportingAuthority bei Set-TransportServer rumspielen. Allerdings riskierst Du dann, dass NDR und andere automatischen Nachrichten unzustellbar werden.

Ja, das meinte ich. Obwohl nach RFC eigentlich nicht erlaubt, gibt es folgenden Test: HELO-FQDN -> IP-Adresse (A) IP-Adresse -> FQDN (PTR) Und die sollten identisch sein.

Oh, Leerzeichen in E-Mail-aktiveren Ordner führen schnell zu so einer hohen Zahl von Fehlern. Auch andere Zeichen mag Exchange da nicht mehr, z.B. Schrägstriche. Allerdings sollte ein PowerShell-Script die fehlerhaften Einträge finden und beheben können.

Na ja, nicht ganz. Du hast jetzt definitiv mehr in der Datenbank, weil Du mit dem /r ja noch diverse Logs eingearbeitet hast. Vermutlich sind nicht die fehlenden Mails dabei, aber das kannst Du ja nun ausprobieren: eseutil /p + isinteg und dann schauen, wie es in Outlook aussieht. Und wenn Du Dir jede "Version" der EDB aufhebst, kannst Du immer noch überlegen, ob und mit welcher Du via Ontrack rangehst. Was ich aber denke: Wenn Du eseutil /p + isinteg durchhast, erreichst Du mit normalen Mitteln keinen vollständigeren Zustand mehr. Die Bordmittel sind das ausgereizt.

Irgendein Fehler "0x8...." wurde dabei nicht im Text der Eventlogs protokolliert? Hast Du den Start mal mit aktivierten Haken bei "Diese Datenbank kann bei einer Wiederherstellung überschrieben werden" probiert zu starten?