RobertWi

Beschäftigt man sich nicht mit Produkten, die man einsetzt? CU2v2 ist das letzte und damit aktuelle Update für Exchange 2013.

Moin, was Dukel schreibt, ist korrekt. Da OWA kein "Postausgang" hat, verschiebt Exchange diese in die Entwürfe, wenn das Senden nicht klappt. Bei Outlook würden sie im Postaufgang liegen. Das hat aber nichts mit dem Connector zu tun, der kommt erst später zu Zuge. Bitte prüfe mit "Test-Servicehealth" ob alle Exchange-Dienste laufen und starte zur Sicherheit den Transportdienst einmal neu. Ach ja und wie gehen natürlich davon aus, dass der Windows 2012 KEIN R2 ist und das CU2v2 für Ex 2013 installiert ist. ;)

Na ja, es gibt halt noch eine andere Komponente in dem Spiel, die man am Ende nur wirklich mit Microsoft klären kann: Exchange 2013.... :( Das Ding ist immer noch verbuggt, dass bei solchen Merkwürdigkeiten nicht klar ist, ob das ein neues Feature oder ein Bug ist.

Würde mich auch interessieren. Die Patcherei nervt, aber ich traue mich nicht, das automatisch zu machen, da zu viele Fehlermöglichkeiten und Stolperstellen dabei sind.

Moin, Ungewöhnlich. Wenn man so migriert, sollte man schon sehr genau wissen, was man tut. Man sollte IMMER die Bordmittel nehmen, um Daten zu verschieben - egal bei welchem Produkt. Exchange macht es einem sehr einfach, da der Verschiebevorgang im Hintergrund abläuft. Das wäre grundsätzlich bei einem Verschieben von Datenbankdateien korrekt gewesen. Das können wir Dir aus der Ferne nicht sagen. Wie gesagt: Man kann das so machen, aber man braucht dafür Wissen und Erfahrung. Das ist aus der Ferne ohne die Geräte zu sehen reine Spekulation und Glaskugelleserei. Ich denke, Du solltest Dir jemanden ins Haus holen, der sich mit Exchange richtig gut auskennt. Das wird in einem Forum nichts und die Gefahr, dass dabei noch mehr kaputt geht, ist hoch.

Moin, normalerweise wird "Senden Als" bevorzugt. Allerdings ist das grundsätzlich ein inkonsistenter Zustand, der vermieden werden sollte.

Dann dürfte das ein Fall für einen Call bei Microsoft sein.

Du hast aber zwei Fragen gestellt: Wie wird es mit privaten Postfächern gehandhabt: Siehe oben. Ich kenne alles, von "nicht getrennt" über Kennzeichnungen, Betreff, Ablage, Kategorien, usw. bis hin zur "zwei Postfächer". Wie kann man private Mails kontrollieren? IMHO gar nicht, weder können noch dürfen. Ergänzend zu DavidS: DLP ist teuer und aufwendig, denn man muss ja nicht nur die eigenen Daten beachten, sondern auch die legitimen Empfänger außerhalb der Organisation. DRM-Techniken wären daher noch zu erwähnen, wie das ADRMS von Microsoft.

Moin, private Mails sind daher privat, weil Du sie NICHT kontrollieren darfst (zumindest nicht pauschal und ohne konkreten Anlass). Kontrollieren, ob etwas unerlaubtes rausgeschickt wird, darfst du höchstens bei dienstlichen Mails (mit "du" meine ich berechtigte Personen in der Firma, dass muss nicht zwangsläufig ein Admin sein). Ich denk daher, ihr solltest zuerst die juristischen Fragen klären, bevor ihr über die technischen Fragen redet. Für Firmen ist meist die einfachste Lösung, die private Mailnutzung komplett zu verbieten (+ Kontrolle und Konsequenzen bei Verstößen). Rein technisch gibt es verschiedene Möglichkeiten: Markierungen in Mails, Prefixe im Betreff, getrennte Mails-Adressen, usw. Aber ob das am Ende wirklich gegen Datendiebstahl hilft, wage ich zu bezweifeln. Dann finden die Leute halt andere Wege raus.

Moin, wo steht denn was von "AD anheben"? Er will Ex 2013 installieren. @chaosNET. 1. Stell sicher, dass Du das Setup mit einem Admin-Konto durchführst (lokal, Domain, Enterprise und Schema - eventuell mit "Ausführen als anderer Benutzer...." das Setup starten. 2. Öffne auf einem DC "ADSIEdit" und geh an die Stelle in der Fehlermeldung "CN=Administrative Groups,CN=Post DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAIN,DC=LOCAL" Darin liegt ein Objekt "CN=Exchange Administrative Group (FYDIBOHF23SPDLT)", wie sind die Sicherheitsberechtigungen auf diesem Objekt? Sie müssen "vom übergeordneten Objekt" vererbt sein.

Doch, das ist technisch eine Datenbank, eine ESE genau, wie die für die Postfächer. Liegt, wenn nicht verschoben, unter "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue", muss aber nicht vergrößert werden, das geht automatisch, bis die Platte voll ist.

Korrekt zumindest in diesem Fall. Set-Mailbox könnte man machen, wenn keine Daten verschobene werden sollen oder die Datenbankdatei kopiert wurde. Das Verschieben funktioniert auch gut via EMC.

Moin, die Entwickler haben die Systeme für bestimmte Postfächgrößen ausgelegt und darauf optimiert. Das betrifft besonders Outlook und den Cache-Mode, ist aber auch in Exchange z.B. für den Content Index zu: Ex 2007 / Ol 2007: 2 GB Ex 2010 / Ol 2010: 10 GB Ex 2013 / Ol 2013: 100 GB Größere Größen sind aber möglich, nur eben nicht optimal.

Kann man nicht konfigurieren. Und die meisten Meldungen basieren auf einem Bug und können ignoriert werden.

Moin, von welchem Log redest Du? Exchange und Outlook kennen dutzende.

Warum sollte das Ausrollen von Zertifikaten via GPO etwas mit der Exchange-Version zu tun haben? Schau halt einfach bei irgendeinem Client nach, ob das richtige Root-Cert da vorhanden ist.

Moin, das Werkzeug hat sich geändert, die Thematik ist aber die gleiche geblieben.

Korrekt, wenn das der ist, der auf Post 25 auf alle Remote IP hört. Ich habe im Augenblick keinen Zugriff auf einen Ex 2013, weiß aber, dass alle "falschen" Connectoren auch in der Berechtigungs- und Authentifizierungs Konfiguration auffallend anders aussehen.

Doch, er beantwortet genau Deine Frage, welcher Connector für welchen Teil zu ständig ist. Ok, ein wenig transferieren musst Du noch, die dort erwähnten Verbindungslinien in die Namen Deiner Connectoren, aber alles, Du dort alsLinie und Port findest, findest Du am Ende irgendwo in den Connectoren wieder. In der Praxis ist die Sache aber eigentlich ganz einfach: Hände weg von allem, was nicht auf Port 25 oder Port 587 hört. Nur die anfassen, der Rest interessiert nicht.

Deine URL funktioniert leider auch. Kaputte Technet-URLs wegen der dämlichen Klammern war der erste Fehler, den ich im neuen Forum damals gemeldet habe - passiert ist damit leider bisher nichts.

Cooler Link.... :)

Was soll mir das Bild sagen? Nachtrag: Hab gerade mal selbst nachgeschaut, dass Attribute "otherWellKnownObjects" lässt sich mit Bordmitteln nicht einfach ändern, weil es vom Type "DN-Binärzahl" ist. Also würde ich die Exchange-Orga löschen: - Backup von AD machen -> sicherstellen, dass das funktioniert! Ein ForestRecovery sollte man geübt haben! - sicherstellen, dass wirklich kein Exchange-Server mehr in der Organisation ist - mit ADSIEdit die beiden obigen "CN=Microsoft Exchange" und "CN=Microsoft Exchange Autodiscover" komplett mit allen Untereinträgen löschen - in ADUC falls vorhanden die beiden Einträge "OU=Microsoft Exchange Security Groups" und "CN=Microsoft Exchange System Objects" löschen Danach ist das AD quasi jungfräulich und Exchange neu installiert werden. Und noch ein Nachtrag: Alle Anweisungen OHNE GEWÄHR! Eine Fehlbedienung kann das AD komplett zerstören. Daher unbedingt ein Backup machen (ich persönlich würde einen zweiten DC installieren, den offline nehmen und notfalls den ersten DC abschalten - muss man aber auch wissen, was man macht mit DNS, FSMO, GC, usw.).

Moin, es gibt (finden mit ADSIEdit) einen Container "CN=Microsoft exchange,CN=Services,CN=Configuration,DC="BLUBB",DC=local" Darin gibt es ein Attribute "otherWellKnownObjects". In diesem Attribute ist ein falscher Eintrag, den man nur löschen muss. Genau DAS steht nur in Microsoft-Sprache oben in der Fehlermeldung drin. ;)

(Dein Zitat ist irgendwie falsch) Ich kann mich nicht erinnern, das ein RU unter 2007 oder 2010 Schema-Änderungen mitbrachte, bzw. Schnittstellen brach. Ein SP ja, aber kein RU. Bei den CUs kann das aber mit jedem Update passieren. Und ich bekomme das CU im Notfall nicht mehr runter, ich muss neuinstallieren. In er Praxis führt daher jedes CU zu einem deutlich erhöhten Prüfaufwand. Ach, eines fällt mir noch ein: Bei Ex 2013 ist es nicht mehr möglich, Rollen nachzuinstallieren oder wieder wegzunehmen. OK, das passt in das Rollenkonzept des Multi-Role-Servers, das MSFT vorsieht. Und bei den Connectoren erinnere ich mich an einen Spruch eines anderes MVPs letzte Woche: "wo kann ich diesen mist mit den unterschiedlichen empfangsconnectoren (frontend usw.) nachlesen. sind die bei MS voll bekloppt?".... :) Das meine ich mit: Bewährte Konzepte werden geändert (mir ist der technische Hintergrund klar, aber einen praktischen Nutzen hat das irgendwie noch nicht gebracht).

Da gibt es einige: - Neue Bedienoberfläche, der Features aus 2010 fehlen (muss dann via EMS gemacht werden) - schlechte bis keine Drittanbieterunterstützung (laufen Deine Virenscanner, Backup, Archiv, etc. mit Ex 2013?) - unsinnige Featureänderungen bei Dingen, die vorher problemlos funktioniert haben (z. B. hat das Einrichten einer DAG einen früher nicht notwendigen Schritt bekommen, ohne den die Einrichtung komplett scheitert) - Designänderungen im Rollenkonzept, die für erfahrene Admins mal wieder ein komplettes Neulernen erfordern und daraus entstandene andere Hardware-Anforderungen - veränderte und für Kunden aufwendige und fehlerträchtige Updates Strategie (= jedes Update ist quasi ein Servicepack und kann Schema-Änderungen enthalten und die Zusammenarbeit mit Dritt-Produkten brechen - es muss also intensiv getestet werden, kann aber gleichzeitig der einzige Weg sein, ein sicherheitskritisches Updates zu bekommen) Der für mich aber schlimmste Punkt: Extrem schlechte Produktqualität. Bugs ohne Ende und oft die Frage, ist das ein neues Feature oder ein Bug ist. CU 2 musste zurückgezogen werden (der Fehler wurde nicht gefunden, weil das Ding intern gar nicht getestet wurde!) und das CU2v2 MUSSTE installiert werden, da man Exchange sonst nicht mehr updaten konnte (btw: Eine Deinstallation eines CU gibt es nicht mehr, die Kunden hatten das fehlerhafte CU2 an der Backe, bis zu Korrektur oder sie haben den Server neuinstalliert). Das CU 3 ist schon mindestens vier Wochen überfällig und wird einen Bug beinhalten, der intern schon bekannt ist, aber nicht mehr behoben werden kann - weil die Prozesse zu aufwendig sind. Einen weiteren Bug (wenig Auswirkung, aber fatale Außenwirkung) konnten die MVPs eventuell noch verhindern. Na ja, wobei erst der Release des CU3 zeigen wird, ob Microsoft diesen Bug (die Korrektur ist Peanuts, der Starttyp eines Dienstes ist verkehrt) beheben konnte oder in den Release Notes nur darauf hin weist. Schau Dich einfach mal in den Foren um, wie viele Probleme mit Ex 2013 auftauchen, die es mit 2010 nicht gibt/gab. Sicher, ist das Ding neu und die Admins haben noch wenig Erfahrungen. Aber an so viele Installations-Probleme, die zum Totalverlust führten, kann ich mich bei 2010 nicht erinnern. Eines dieser Installationsprobleme hatte ich selbst in meiner Mini-Testumgebung (1x DC, 1x Ex 2013 - nichts los darin). Offensichtlich war es ein Fehler, die Windows Updates vor dem CU2v2 zu installieren. Das beschwerte sich danach, dass ein "Interims Update" auf der Kiste sei, das erst deinstalliert werden müsste. Es sagte mir aber nicht, welches. Und: Das fiel erst während der Installation auf. Ergebnis: Exchange komplett unbrauchbar, halb aktualisiert, Dienste deaktiviert und Null Informationen darüber. In der Testumgebung war die Reparatur einfach - Snapshot zurücksetzen und erst CU2v2, dann Windows Updates. In einer Produktivumgebung hätte das mehrere Stunden gedauert. Jedes einzelne Problem ist oft nur ein "Problemchen", aber es zeigt, wie MSFT mit dem On-Prem-Produkt "Exchange 2013" umgeht und welche Bedeutung es hat. Es gehört schon einiges dazu, Kunden in Bugs laufen zu lassen, weil man selbst das Update nicht getestet hat und in der eigenen Cloud eine komplett anderen Updates-Weg fährt (eigentlich gar keinen, die Dinger werden im Rotationsprinzip immer wieder neuinstalliert).