RobertWi

Moin, tja, das hättest Du dann auch mal schreiben sollen. Autodiscover hat nicht direkt was mit OOF zu tun. Prüfe mit Outlook und "E-Mail-Autokonfiguration testen...", welche URLs per Autodiscover kommen. Du suchst die OOF-Url, die hinten aus EWS endet. OOF kommt nämlich über die Exchange Webservices, nicht über Autodiscover. Da kommt nur die URL her. Diese URLs müssen bei Dir passen und fehlerfrei (SSL) vom Client aufrufbar sein.

Moin, korrekt, bei Ex2007 geht der Verschiebevorgang nur mit Trennung der Benutzer. Online-Move kennt erst Exchange 2010. Allerdings dürfte es immer noch besser sein, wenn einige Benutzer (es werden immer nur vier gleichzeitig verschoben, AFAIR) nicht arbeiten können, als wenn alle User offline sind, wenn eine Offline-Defragmentierung läuft.

Moin, Du hast also eine echte Reparatur gemacht? Wie hoch war denn dabei der Datenverlust (sprich, wie viele Log-Dateien wurden damit weggeworfen)? Schon mal isinteg über die EDB laufen lassen? Meine Prognose wäre, dass danach der Zähler links unten die korrekte Zahl zeigt (die vermutlich deutlich unter 1200 liegt).

Wenn Du zwei unterschiedliche Domänennamen hast, ist es kein SplitDNS. Dann brauchst Du mindestens zwei Namen im Zertifikat: intern: mail.meinefirma.local extern: mail.meinefirma.de Um ".local" extern zertifizieren zu lassen, braucht es i.d.R. ein teures Zertifikat mit persönlicher Überprüfung. Eine Umstellung auf SplitDNS ist daher meist die bessere Variante. Und weil hierbei die Clients eventuell angefasst werden müssen, kannst Du gleich noch ein CAS-Array einrichten (der Name muss muss/darf aber nicht ins Zertifikat) und den Servernamen in Outlook hierauf ändern. Für Autodiscover brauchst Du nicht unbedingt einen Namen im Zertifikat, dann müssen passende SRV-Einträge gesetzt werden. Ohne SplitDNS kommst Du also auf mindestens zwei Namen im Zertifikat.

Und im DNS daszu den passenden PTR.

Moin, es ist ein Unterschied, ob das Verzeichnis nur im IIS oder auch für Exchange vorhanden ist. Lösch es im IIS (eventuell auch noch mal in der Metabase des IIS) und versuch es danach, neu anzulegen.

Eine Mailheader-Analyse kann man übrigens perfekt hier machen: Email Header Analyzer, RFC822 Parser - MxToolbox Dann brauchst Du nur noch den Link des Ergebnisses zu posten. Und die Laufzeiten kannst Du da auch sauber ablesen.

Moin, Outlook 2010 kannst Du hier auch nicht mit Outlook-POP3 vergleichen, weil Outlook auf Apple EWS nimmt und Outlook mit POP3 sendet die Mails mit SMTP. Ansonsten scheint das ein Outlook-Problem zu sein, keins von Exchange. Eventuell löschst Du mal das komplette Outlook-Profil (vorher die PST des POP3 sichern, natürlich) und richtest alles noch mal sauber ein?

Wie müssen wissen, welche Server es gibt, existiert ein CAS-Array, Load Balancer, SplitDNS, Zugriff auf interne und externe DNS, welche Namen gewünscht werden, was für die Anwender sinnvoll ist, usw.

Na dann hast Du doch gar kein Verzeichnis. Und was nicht da ist, kann dann logischerweise auch nicht entfernt werden, oder? EXCHAN2010 sieht halt nicht nach einem korrekten Namen aus. Das solltest Du zuschreiben, dass die merkwürdige Schreibweise von Euch so gewollt ist.

Moin, die Frage, warum ihr jetzt noch auf ein Produkt wechselt, dass nicht mehr im Mainstreamsupport ist, würde mich auch interessieren. Ansonten: Namensauflösung prüfen + darauf achten, dass auf dem Server IPv6 aktiviert ist. Ansonsten würde ein Exchangesetuplog in voller Länger eventuell mehr Aufschluss bringen.

Bist Du sicher, dass das Verzeichnis mit dem Schreibfehler in "Exchan2010" wirklich so existiert? Ansonsten sind Hilfen schwer, wenn Du die Namen verschleierst. Dann können wir nicht sehen, ob der Fehler bei Exchange oder bei der Verschleierung entstanden ist. Was sagt "Get-AutodiscoverVirtualDirectory" denn aus? Wenn Du nur einen Server hast, da wäre "Get-AutodiscoverVirtualDirectory | Remove-Get-AutodiscoverVirtualDirectory" der kürzeste Weg, ohne sich um den Namen zu kümmern.

Ok, dann gibt es noch als letzte Info: Schau Dir die Berechtigungen aus meinem Befehl drei an. Such die raus, die nicht vererbt sind und ExtendedRights haben. Danach schau Dir die Berechtigungen mit ADSI-Edit auf dem Connector an und suche nach Leuten, die die Berechtigung "Accept any Sender" hat. Diese Leute können den Absender frei wählen. Und auf keinen Fall die Berechtigung bei irgendwelchen administrativen oder Exchange-Gruppen entfernen.

Natürlich wird es nicht geloggt, weil die Protokollierung auf allen Connectoren deaktiviert ist. Aber das probiere ich nun fast zwei Seiten lang Dir zu erklären. Und ob und wer in der Lage ist, den Absender zu fälschen, könnte man mit meinem dritten Befehl von oben sehen (oder zumindest einen Ansatz dafür bekommen).

Moin, also ich sehe da, dass Du zwei Server hast, auf denen alle Rollen laufen, auch die Transport-Rolle. Nichts ungewöhnliches. Wie bereits oben erwähnt, musst Du die Protokollierung auf ALLEN Connectoren aktiveren. Da das bei Dir einige sind, hilft die EMS: "Get-ReceiveConnector | set-ReceiveConnector -ProtocolLoggingLevel verbose". Danach protokollieren alle Receivconnectoren und Du findest im Protokoll, über welchen Connector der "Angreifer" rein kommt und seine Mails versendet. Da aber alle Connectoren, die von "außerhalb" empfangen, mit Authentifizierung arbeiten, denke ich, dass der Angreifer über einen gehackten Account mit geknacktem Password kommt. Mit Telnet ist ein Fakemail-Versand je nach Konfig der Connectoren und Zugangdaten/Ip-Adressen möglich. Mehr kann ich aber nicht sagen, da Du einige Infos (z.B. die vom letzten Befehl) nicht lieferst und auch nicht wirklich genau schreibst, was Du unter "Fake Mail" verstehst.

Moin, lies Dir mal die Fehlermeldung genau durch. Da werden ALLE Befehle, die man zum Suchen der übrigen Postfächer und zum LÖSCHEN dieser braucht, angezeigt. Vermutlich sind noch "Arbitration" Postfächer auf dem alten Server (die werden gelöscht und vom neuen Exchange neu erzeugt).

Ich nutze die. Achten muss man da eigentlich auf nichts. Ich benutze folgende Reihenfolge: Nur Windows Update Start-Script auf DAG 1 Windows Updates auf DAG 1 Reboot Stop-Script auf DAG 1 usw. für DAG 2 bis DAG x Redistribute-Script Danach die CAS/HT-Server - Reihenfolge beliebig, hängt vom NLB ab Bei Exchange-Updates ändere ich die Reihenfolge auf die MSFT-Empfehlung: CAS/HT mit FSW alle anderen CAS/HT Danach die DAG-Server wie oben beschrieben

Sehe ich wie Günther. Es ist supported und machbar, bedeutet nur einen "Ausfall" für die Anwender (daher die Empfehlung einer neuen DB und des Verschiebens der PF, was im Hintergrund stattfindet). Aber bringen würde es in Deinem Fall sicher was.

Nein, die DB verkleinert sich nie von alleine (Programmfehler ausgenommen). Nach der eingestellten Zeit (engli. Retention Period) werden gelöschte Elemente zu Whitespace. Whitespace wird dann entweder überschrieben oder durch eine Offline-Defragmentierung entfernt. Du würdest also erleben, dass Deine Datenbank einfach nicht mehr größer wird (bzw. nicht so viel wächst, wie reingeht), weil der Whitespace überschrieben wird. Aber kleiner wird sie von alleine nicht. Den verfügbaren freien Speicher kannst Du Dir übrigens so anschauen (nur ab 2010): Get-MailboxDatabase -Status | fl Name,AvailableNewMailboxSpace Get-PublicFolderDatabase -Status | fl Name,AvailableNewMailboxSpace Und dann kannst Du entscheiden, ob es sich lohnt, die Datenbank bei der Größe für mehrere Stunden außer Betrieb zu nehmen und offline zu defragmentieren.

Sicher, so etwas nennt sich "Single Sign On" - oder willst Du Dich zehnmal mit Deinen immer gleichen Windows-Daten anmelden. In Deinem Fall würde es vermutlich reichen, in den Kontoeinstellung unter "Sicherheit" die Funktion "Immer zur Eingabe von Benutzerinformationen auffordern" zu aktivieren.

Wie lange man abwarten muss, hast Du in den Eigenschaften der Datenbank eingestellt (Reiter Grenzwerte), im Standard sind es 14 Tage. Vorher hilft auch kein eseutil /d, denn dann ist es noch gar kein Whitespace. WS wird es erst, wenn die Aufbewahrungszeit abgelaufen ist.

Hast Du ihn schon mal aus Outlook raus und neueingerichtet? Geht der Zugriff via OWA (mit dem ersten User anmelden, dann wechseln ohne neue Anmeldung)?

Als ich antwortet, gab es nach Deiner Antwort noch eine weitere Antwort eines "Dritten", der vorschlug, ob es nicht einfach wäre, einfach den DC zu verschieben. Diese Antwort ist nun aber weg (gelöscht? Fehler?) und wäre falsch gewesen. Ich fragte Dich oben, ob alle Dienst laufen. Du sagtest ja, dem ist aber offensichtlich doch nicht so: Kleiner Tipp, um zu kontrollieren, ob alle Dienste auf einem Windows Rechner laufen: Dienste MMC öffnen und nach Starttyp sortieren. Dann sieht man auf den ersten Blick. Nicht alle für Exchange wichtigen Dienste beginnen in der Auflistung mit "Microsoft Exchange" und wenn man einfach nur die alphabetische Liste durchgeht, übersieht man die sonst zu einfach.

Braucht man für MFCMAPI nicht, mache ich regelmäßig auf meinem W8-Rechner. Allerdings braucht man Vollzugriff auf das fragliche Postfach. Außerdem wird es in der Standard-Einstellung nur im Cache Mode geöffnet. Das ist eventuell ****, weil man es daher vorher erst in Outlook einbinden muss. Ich gehe i.d.R. wie folgt vor: - Vollzugriff einrichten OHNE Automapping! - Neues Outlook Profil, dort das neue PF einbinden, OHNE Cache Mode - Outlook einmal im neuen Profil starten, muss danach aber nicht mehr laufen - in MFCMAPI unter tools/options den Cache Mode betrieb abschalten Bei Frank gibt es auch noch eine Anleitung für die "Rules Table": MSXFAQ.DE - MFCMAPI

Bitte poste mal die folgenden Ausgaben: Get-ExchangeServer | fl Name,ServerRole Get-ReceiveConnector | fl Name,Server,Bindings,RemoteIPRanges,PermissionGroups,AuthMechanism,ProtocolLoggingLevel Get-ReceiveConnector | Get-ADPermission | Where-Object { $_.AccessRights -like "*ExtendedRight*" -and $_.IsInherited -eq $false } | Sort-Object Identity,User | ft -AutoSize