RobertWi

Na genauso, wie sonst auch, mit Import-Module.

Musst Du nicht. Wenn der Transportdienst läuft, gibt es da keine Probleme. Sonst wäre der gar nicht erst gestartet. Definitiv: JA.

Die Queue, liegt in der Standardinstallation hier: C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue

Danke für das Feedback. Ja, beim Transport-Dienst sind auch noch 2 ESE-Datenbank. Da reicht aber die einfache Lösung: Einfach komplett löschen, dann werden die neu angelegt (IPFilterung darf man natürlich nur löschen, wenn man keine IP-Filterung auf der Kiste benutzt). Das "calendar Ordner" soll vermutlich "CatalogData Ordner" heißen. Das ist der Volltextindex, den könnte man nach Stoppen von MSExchangeSearch auch löschen, dann wird er beim nächsten Starten neu erzeugt.

Es ist schwierig, die komplexen Grundlagen der ESE in einem Forum zu erklären, daher nochmal als Wiederholung: "Die Datenbank hat angeblich "Clean Shutdown". Dann werden die Log-Dateien nicht mehr benötigt und ein *Recovery bringt eh nichts mehr."

Die Datenbank hat angeblich "Clean Shutdown". Dann werden die Log-Dateien nicht mehr benötigt und ein *Recovery bringt eh nichts mehr. Eventuell wurde vergessen, die CHK-Datei auch zu löschen, so dass die ESE jetzt beim Start versucht, nicht vorhandene und eigentlich nicht benötigte Log-Dateien einzuarbeiten. Beim Clonen wurden offensichtlich wirklich die Sector Size angefasst. Hier ist was zum Lesen dazu: http://blogs.technet.com/b/exchange/archive/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes.aspx

Da gibt es wie immer zwei Varianten: Entweder die Mails sind wichtig, dann müssen sie wie auch immer sauber aufbewahrt werden - und das kostet Geld. Oder sie sind nicht wichtig, dann kann man sie auch löschen. Du möchtest sicher nicht mit PST-Dateien hantieren. Die sind fehleranfällig, über das Netz nicht supported und gehen dabei gerne mal kaputt, sind definitiv nicht performanter (Outlook öffnet die gesamte PST-Datei), Du kannst nicht mit mehreren darauf zugreifen (ohne Drittanbieter Software), sie verbrauchen deutlich mehr Platz im Backup, usw. usf.

Das mit den "*" ist an der Stelle auch ok. Ich denke, da war intern irgendwas verkehrt und es wurde stillschweigend einfach korrigiert, als Du die Bindungen angefasst hast. Du kannst ja mal testweise das "*" wieder rausnehmen. Alle Dienste müssen laufen, Mails rein/raus, Client-Zugriff. Jein. 1. Du brauchst das Stammstellenzertifikat für die Vertrauenskette -> Du hast die CA ja aber noch 2. Für das ausstellen eines SAN-Zertifikates muss man entweder die Web-Seite nehmen oder das umständlich via certutil manuell machen. Solange Du kein neues Zert brauchst, stört das nicht. Aber wie gesagt: Das ist eh die richtige Seite, die ist nicht schuld für die falschen Einstellungen gewesen. Die anderen sind problematisch. In der EMC dem Zertifikat die korrekten Dienste zuweisen -> Alles, außer UM. Wie gesagt, denke ich, dass im Hintergrund was verbastelt war. Es ist immer gefährlich, ein anderes IIS-intergriertes Produkt auf Exchange zu installieren. Ich brauche halt bei Exchange den IIS nicht nur für OWA, sondern eigentlich für alles, Management und Clients. Wenn dann am IIS was kaputt geht, ist der Spaß groß. Daher empfehle ich immer, nichts auf einen Exchange zu installieren, was den IIS ändert, z.B. WSUS, CA oder gar Sharepoint Services. Zum Spaß kann ich jedem nur empfehlen, mal in einem SBS in die IIS-Manager zu schauen und zu sehen, was Microsoft für Verrenkungen gemacht hat, damit Exchange, WSUS und Sharepoint auf einer Kiste laufen. Das will man eigentlich nicht und da sind Probleme vorprogrammiert.

Korrekt. Muss so aussehen, wie in der Anlage und bei den beiden 443 ist unter "Bearbeiten..." noch das korrekte Exchange-Zertifikat eingestellt. Zu Deinem Screenshot. Ok, offensichtlich hats die web.config zerhauen. Lad Dir das Service Pack für Exchange herunter, dass Du auf dem Exchange hast. Dann pack es aus (ist eine selbstwextrahierende Datei), such darin DIESE web.config (es gibt sie mehrmal, nimm die richtige aus dem korrekten Verzeichnis!) und kopier sie auf Deinen Server.

Moin, da ist so viel passiert, das wird eventuell schwierig, das aus der Ferne zu lösen. Zur ADCS: Technisch kann man sie auf dem Exchange installieren. Es gibt aber einen bösen Fallstrick, der können schuld am Versagen der Webdienste sein: Man darf auf keinen Fall die Rollendienste für die automatische Webkonfiguration installieren. Das verbastelt die Bindungen im IIS. Du musst die Webseite installieren, mit der User sich Zertifikate anfordern können, aber nicht die beiden anderen Rollendienste. Falls passiert: Lösch diese beiden Dienste und melde Dich wieder. Dann schaue ich bei mir nach, wie die Bindungen bei einem "sauberen" Exchange-IIS sind.

Also eigentlich auf alle und damit gehört das dann in die Default Domain Policy.

Sicher? Ich habe bei einem Kunden eine Konstellation, die (aus dem Kopf) ungefähr so aussieht, wie beim OP. Eventuell ist in der Liste aber auch nur genau der eine Rechner enthalten, auf dem der Task läuft. Kann ich im Augenblick nicht nachsehen.

Tja, und mit Hilfe der Fehlermeldung bist Du sogar alleine darauf gekommen, was wahrscheinlich das Problem ist (klingt plausibel). Hättest Du da gleich nachgeschaut, hättest Du Dir Zeit für die Frage hier sparen können. ;) Gemeint sind vermutlich die Umkreisserver in der globalen Transporteinstellung. Allerdings stellt sich die allgemeine Frage, warum der Server hinter dem POP-Connector nochmal Spam filtern muss. Aber vielleicht findet es die Firma hat toll, auf Blacklisten zu landen. :) Siehe den ersten Satz im ersten Antwortposting.

Hmmm.... Was ist in meiner PKI anders? Windows 2008 R2 - Original Vorlage wie man an der Version 2000 und den ausgegrauten Feldern sehen kann.

Moin, und einfach in den Kontoeigenschaften des Benutezr-Konto die Anmeldearbeitsstationen zu pflegen, ist zu einfach?

Wie genau hast Du das denn verlängert? Wenn Du eine Windows PKI benutzt, müsste Webserver IMHO zwei Jahre sein. Ansonsten müsstest Du die Vorlagen kopieren und den CSR mit der kopierten Vorlage beantworten.

Moin, IMHO muss beim Parameter -AddressLists ein Backslash vor dem Listennamen: New-OfflineAddressBook -Name "TenantA" -AddressLists "\TenantA - GAL" Man kann leider nicht sehen, ob Du den weggelassen hast, oder das Forum. Mein Befehl ist ungetestet!

Mich würde eher interessieren, wie der Verteiler jetzt konfiguriert ist. In einen Verteiler kann man nur andere AD-Objekte packen. Es muss also schone einen Kontakt oder ein Postfach geben, sonst hätte er gar nichts in den Verteiler stecken können. Aber die Beschreibung ist immer ncoh ein wenig durcheinander. Da steht "Die Mail an AAA@BBB.de kommt nicht an. Der Exchange lehnt die Annahme ab." Welche Exchange? Der vom Verteiler oder ist @BBB ein zweiter Exchange? Wie ist die Fehlermeldung?

Moin, dann solltest Du das nächste Mal erwähnen, wenn Du keine standardgemäße Migration, sonder eine Intra-Org-Migration durchführst. Das ist eine Info, die gerade beim Mailfluss quasi alles um 180 Grad dreht.

"Sowohl als auch" war die Antwort auf welche meiner beiden Fragen? Und dann müsste es ja eigentlich auch eine verwertbare Fehlermeldung geben. Bringt in der EMS das hier Fehler: get-globaladdresslist | update-globaladdresslist get-addresslist | update-addresslist

Moin, tritt das Problem nur bei einem Absender auf, oder bei allen? Intern oder Extern?

Moin, 1. POP-Connectoren sind Mist und schaffen mehr Probleme, als sie lösen. In diesem Fall hättest Du ohne POP-Connector übrigens eine saubere Fehlermeldung bekommen, was die Suche deutlich erleichtern würde. 2. Als raten wir: Die Verteilerliste nimmt Mails nur nach vorheriger Authentifizierung an -> das ist in den Eigenschaften der Verteilerliste zu finden und muss bei gewünschtem Empfang von Externen deaktiviert werden.

Ich rede hier nur über das Problem oben mit den Healthmailboxen. Kommt da der von Dir genannte Fehler? Wen ja -> eine Datenbank mit Set-Mailbox setzen.

Schaust Du hier: http://www.msxforum.de/modules/publisher/item.php?itemid=124 Nur der Teil mit der CA wird bei Dir anders aussehen.

Und zum Fehler oben: Der Fehler kann auch aus anderen ungültigen Attributen herrühren, beliebt ist nicht nur der Alias (Sonderzeichen) sondern bei den Systemmailboxen auch das man irgendwann mal die Datenbank gelöscht hat, ohne sie zu ändern. Mach mal in der EMS ein einfaches "Set-Maibox Health......." und schau Dir die Fehlermeldung danach an. Die solltest Du IMHO auch regelmäßig im Eventlog finden.