RobertWi

Moin, ganz ehrlich: Entweder ihr habt echten Bedarf an einer Sicherung in andere Standorte, dann darf es an vernünftiger Infrastruktur nicht fehlen. Was nützt eine "Bastellösung", wenn keiner weiß, ob die im Ernstfall schnell oder überhaupt einsatzfähig ist. Die meisten Kunden, die ich kenne, haben im Fall eines Brandes ganz andere Sorgen, als ihre Exchange-Server. Schön, wenn der Exchange am anderen Standort noch läuft, nur Clients gibt es leider nicht mehr. ;) Exchange kann man wie beschrieben sicher, man muss sich aber gut mit ESE und dem Funktionieren der Datenbank auskennen. Sonst sind die Daten am Zweifelsfall weg und nichts gewonnen. Und außerdem ist es ja nicht nur Exchange. Es braucht auch DNS, AD, eventuell DHCP. Also: Nicht Basteln, sondern ein sinnvolles Gesamtkonzept erarbeiten - das ALLEN hilft und möglichst wenig SPoF lässt (keine geht prinzipbedingt nicht).

Moin, die Autodiscover-URLs sind egal, wichtig ist hier nur die Einstellung von "Get-Clientaccessserver". Vermutlich sind es die EWS und OAB-URL: Get-OwaVirtualDirectory | fl Name,internalurl,externalurlGet-WebServicesVirtualDirectory | fl Name,internalurl,externalurl Und wenn Du schon dabei bist, kannst Du die übrigens URLs auch prüfen, die sind aber nicht primär für Outlook wichtig: Get-EcpVirtualDirectory | fl Name,internalurl,externalurlGet-OwaVirtualDirectory | fl Name,internalurl,externalurl Get-ActiveSyncVirtualDirectory | fl Name,internalurl,externalurl Natürlich müssen die internen Clients dann auch in der Lage sein, eine korrekte IP-Adresse für die URL zu bekommen. Du musst also eventuell auch SplitDNS einführen - was aber eh empfohlen ist.

Du musst ja nicht glauben, dass diverse Probleme bekannt sind. ;)

Moin, es ist offiziell nicht supported und läuft auch nicht stabil. Es sind diverse Probleme bekannt, u.a. mit dem IIS (siehe z.B. hier) Das gilt übrigens sowohl für den Server, auf dem Exchange läuft, also auch für die Domäne! R2 ist in beiden Fälle mit Exchange noch nicht einsetzbar. Den echten Support gibt es erst mit dem Service Pack 1 -> http://blogs.technet.com/b/exchange/archive/2013/11/20/exchange-server-2013-service-pack-1-coming-in-early-2014.aspx

Moin, nach meinem Kenntnisstand wird nur Client-SMTP umgestellt (Port 587). Auf dem Server-SMTP-Port 25 bietet auch 1&1 schon seit langem TLS-Verschlüsselung an - nur nicht zwingend. Das können sie dort auch kaum aktivieren, weil es auf der weiten Welt garantiert noch viele Server gibt, die kein TLS machen wollen. TLS kannst Du auf dem Conector aktivieren, allerdings nur via Shell (Klick -requiretls). SMTP/S (also SSL) kann Exchange nicht und es wird auch bei Server-zu-Server kaum verwendet. Siehe auch hier: http://hilfe-center.1und1.de/mail-c82645/rund-um-ihre-e-mail-adresse-c82704/bedienung-c82755/einstellungen-fuer-ihr-e-mail-programm-a783411.html http://hilfe-center.1und1.de/e-mail-c82645/rund-um-ihre-e-mail-adresse-c82704/problemloesung-c82756/versand-ueber-smtp-port-25-schlaegt-fehl-a783818.html BTW: Das ganze ist nur Augenwischer und Marketing-Geblubber. Die Mails liegen bei Dir und bei 1&1 immer noch komplett unverschlüsselt und niemand kann den Zugriff kontrollieren. Richtig sicher wäre das erst mit einer Ende-zu-Ende-Verschlüsselung, also mit verschlüsselten Mails. Das hier ist ungefähr so, als wenn Du Deine Postkarte auf dem Weg zum Briefkasten noch mal in einem Umschlag steckst, im Briefkasten selbst ist der aber dann weg und alles, was danach passiert, bekommst Du nicht mit.

Ist jetzt nicht wirklich ein Geheimnis -> Klick

Das stimmt leider nur teilweise. Er darf nicht damit senden, wenn er sich das Postfach als weiteres einbindet. Er darf es aber sehr wohl, wenn er ein neues Outlook-Profil nur mit diesem Postfach benutzt oder das zusätzliche Postfach in OWA öffnet. Das ö#sst sich auch nicht verhindert, da er in diesem Augenblick die Identität des anderes Postfaches übernimmt und damit zu "Selbst" wird und das darf natürlich senden.

Nein, auch noch nicht.

Für SCOM müsste das reichen, von DPM bin ich nicht so der Freund, damit kenne ich mich nicht richtig aus.

Moin, CU3: ja. Key: ist egal, wird erst nach nachhinein eingegeben Und bevor das wieder schiefgeht: KEIN Windows 2012 R2 erlaubt, nur ohne R2.

Moin, exchange-technisch ist eine Unterscheidung in verschiedene AD-Domänen nicht notwendig. Sie bringt i.d.R. auch nur sehr wenig, da Exchange immer auf Infos des gesamten Forest zurückgreift. Also ist anderes wichtig, nämlich die Administation: - wieviele Admins wird es geben, die das verwalten? - welche Berechtigungen müssen die haben? - kann man Verwaltungsdelegierung auf OU-Ebene machen und braucht man Dienste-Trennung auf Domänen-Ebene?

Das habe ich schon gesehen. Es geht trotzdem wild durcheinandern. Erst will er die DB löschen, als ich ihm sage wie es geht (über die GUI), führt er stattdessen ein "Clean" über die Shell aus und danach ein ESEUTIL. Und da hoffe ich doch, dass Problembeschreibungen und -lösungen in der Praxis beim TO ein wenig strukturierter sind, als wildes "herumexperimentieren". Bei der Backup-Software entdecke ich auf den ersten Blick auf der Webseite die mich immer wieder abschreckenden Marketingmängel: Wahnsinnig viel Marketinggedöns, wie einfach eine Sicherung ist - und quasi keine Infos zu Wiederherstellung.

Oben wolltest Du noch eine Datenbank löschen und nun bist Du bei der Auswahl der Backup-Software. Du solltest ein weniger planvoller arbeiten.

"rechte Maustaste".... ;)

Moin, RMT -> Löschen. Danach die Dateien aufräumen, die bleiben stehen.

Der Doppelppost ist kein Problem, Du sollst nur daraufhinweisen. Es gibt Leute wie mich, die in beiden Foren unterwegs sind. Andere sind aber nur in einem aktiv und die müssen nicht nochmal das antworten, was eventuell im anderen Forum schon steht. Wir machen das ja alle unentgeltlich. ;)

Bitte weise auf Multi-Posting hin: http://social.technet.microsoft.com/Forums/de-DE/b9421ac3-68ee-4850-8ee6-932684da54db/nach-exchange-2010-deinstallation-fehler-bei-neuinstallation?forum=exchange_serverde Antwort seht im anderen Thread.

Also läuft doch alles in Exchange und das Problem sitzt danach, oder? Exchange konvertiert sie auch intern. Aber diese Konvertierung wird Millionenfach auf der Welt gemacht - Probleme hast nur Du. Dann mach einen Call bei Microsoft auf. Ein Bug ist hierbei wie gesagt in Exchange nicht bekannt. Weil neben den vielen technischen Besonderheiten vorallem die Qualität von Ex 2013 leider noch nicht produktionsreif ist. Im Augenblick muss man vom produktiven Einsatz in größeren Strukturen leider noch abraten. Nachtrag: Wir gehen natürlich davon aus, dass Du CU3 einsetzt.

Den Client Virenscanner meine ich nicht, sondern die Server Virenscanner. Aus Erfahrung: Glaube nie etwas von Dritten, was Du nicht selbst gesehen hast. ;) Was soll man da sehen? Oder anders ausgedrückt: Hättest Du hier ein Exchange-Problem (was bei der 2013 Beta nicht mal ausgeschlossen ist), dann wäre das Internet voll damit, oder? Also hast Du eher ein Problem in Deiner speziellen Umgebung.

Moin, eine Pipline gibt es nur für eingehende Mails, nicht für ausgehende. Als erstes musst Du alle externen Fehlerquellen ausschließen: - Virenscanner - Firewall Und das bei Dir und beim Empfänger. Es ist viel wahrscheinlicher, dass bei einem der Stationen dazwischen was passiert, als bei Exchange.

Da ich das Verhalten nicht nachvollziehen kann (ich arbeite hier mit mehreren Umleitungen, wo ich genau den ursprünglichen Empfänger in der Mail sehe), schau Dir mal den Header an.

Auf den Screenshots sehe ich, dass Du eine Regel für "Weiterleiten" gemacht hast. Du willst aber "Umleiten". bei Umleiten wird der "TO"-Empfänger normalerweise nicht umgeschrieben. Das müsstest Du auch im Quelltext der Mail sehen können. Aber natürlich wird in beiden Fälle RCPT TO angepasst, sonst würde die Mail ja nicht zugestellt werden können. Sollte Deine Anwendung darauf gehen, gibt es keine Lösung dafür.

Im Prinzip lässt sich das nicht eindeutig sagen.Für diesen konkreten Fehler findest man wenig. In Bezug auf den Event gibt es einige, das passt hier aber vermutlich nicht. Ich würde das erstmal beobachten. Für die spätere Reparatur gibt es mehrere Möglichkeiten: Mailbox-Repair, Mailbox-Move, Eseutil.

Wie lautet denn der komplette Event?

Moin, via PowerShell (einfach) gar nicht, weil es darüber keinen Zugriff auf Postfachinhalt gibt. Das kann via EWS gehen oder eventuell mit anderen Dritt-Tools, wie z. B. MFCMAPI.