RobertWi

Moin, ja, kann man. Man kann das RBAC komplett frei gestalten, bis runter auf einzelne Parameter. Allerdings ist das ein wenig zu aufwendig, um es in einem Forum zu beschreiben. Ein guter Einstieg mit weiterführenden Links gibt es bei Frank: http://www.msexchangefaq.de/e2010/rbac.htm

Moin, das ist doch Office 365. Da bezahlst Du explizit für den Support mit und im Gegensatz zu hier sind in den Office36-Foren auch MSFT-Leute unterwegs (ok, manchmal ist Daniel hier, aber eher selten). Also stell doch die Frage dort mal. Das hat auch gleich noch den Vorteil, dass MSFT ein Feedback bekommt und wenn diese Wünsche öfter kommen, sie ins Programm einbaut.

Moin, im Normalfall probiere ich, die Wartung sauber zu machen. Sauber heißt: DAG-Scripte verwenden LB-Knoten einzeln abhängen (nur, wenn das kein WNLB ist) Dabei habe ich mir alle Aktionen als Scripte auf einem Exchange vorbereitet. Allerdings muss ich auch sagen, dass das ein HA Konzept ist. Und das muss natürlich auch dann bestehen, wenn ich mal keine Zeit dafür habe.

Gerne: http://robertwilleswelt.wordpress.com/2011/07/08/owa-verkurzung-der-url-auf-anderem-weg/ Benutze ich immer noch sehr oft und hat den absoluten Vorteil für mich, dass ich nicht fehlträchtig an den IIS-Einstellungen rumbasteln muss. Aber IMHO ist das Umstellen der OWA-Url ansich gar nicht möglich.

Unabhängig davon: In der EMC das Postfach deaktivieren, in den Bereich "getrennte Postfächer" gehen und das Postfach einem anderen Konto wieder verbinden. Dauert vielleicht 60 Sekunden, danach kann das PF wieder mit einem anderen AD-Konto benutzt werden. Allerdings kann es ein wenig dauern, bis die E-Mail-Adressen in den Adresslisten stehen, das ist aber bei jedem neuen Postfach so.

Ok, hast Du denn irgenwelche Replikationsfehler in AD in Windows? Sind DCDIAG und REPLMAN /showrepl fehlerfrei. Wenn ja, dann ist das halt bei Euch so. Es ist ja auch nicht falsch - nur nicht notwendig. IPv6 darf übrigens nicht deaktiviert sein. Entweder aktiviert und möglichst konfiguriert, oder komplett deinstalliert (geht nur via Regkey), aber nicht deaktiviert.

Wenn auf dem Exchange noch nichts drauf ist: Runter mit Exchange, runter mit dem DC und wieder raus mit Exchange

Das die von einem Linux eingeliefert werden, hast Du oben nicht geschrieben. Da hast Du "import aus PST" geschrieben. Dann ist das Problem wahrscheinlich in der Codierung der Mail beim Linux zu suchen.

Warum hast Du den den jetzt wieder zum DC gemacht? Hast Du aus den Problemen nichts gelernt! Exchange soll nicht auf einem DC laufen und da Du zwei anders hast, ist es auch nicht notwendig.

Was hast Du den nun eigentlich repariert? Ist "Mail_Neu.de" der neue Exchange? Hast Du den auch wieder zu einem DC gemacht?

Moin, schau mal ins Eventlog (Anwendungsprotokoll) und such nach dem Event 2080. Da findest Du, welche DC/GC mit welchen Rollen Exchange entdeckt hat.

Schau mal, on das hilft: http://support.google.com/a/bin/answer.py?hl=de&answer=176054 Aber sonst habe ich leider keine Ahnung von Google. Es gibt aber Anbieter für Relay mit beliebigen Absender-Adresse. Eventuell reicht schon ein ganz kleines Webpacket bei einem Hoster. Dann muss nur noch die mögliche Spam-Frage (SPF) geregelt sein.

Moin, Exchange macht an dieser Stelle nichts. Addres-Rewriting gibt es erst mit dem Einsatz eines Edge Transport-Servers. kann es sein, dass der Provider keine variablen Absender erlaubt und den auf den Login umstellt? Das mache einige so, vorallem in den "billigen" Tarifen.

Und bei mir bleiben öfter mal "Leichen" unter AD Standorte und Dienste im alten Standort übrig.

Das ist leichter mit einem Link erklärt: Klick

Ah, ok. Das habe ich mir gedacht. Die leichter Lösung für den Übergang wäre es, die Datenbank mit dem Namen "Mailbox Database 1752826095" wieder einzubinden (in der EMC -> Organ-Konfig -> Datenbanken -> Mailbox Database 1752826095 -> RMT -> einbinden. In dieser Datenbank befinden sich die SystemMailboxen und in diesen wird das Audit-Log geschrieben. Und dann sollte sich eventuell ein Fachmann das mal in Ruhe ansehen, denn wer weiß, wo noch Korken stecken.

Moin, bitte führe mal die beiden folgenden Befehle in der EMS aus und postet das Ergebnis: Get-MailboxDatabase -Status | ft Name,Mounted - Autosize Get-Mailbox -ResultSize unlimited -Arbitration | ft Alias,ServerName,Database -AutoSize

Und wieder mal wundert mich, warum die Leute das nicht in die Foren von Microsoft fragen. Leute ihr BEZAHLT für jedes Postfach, dann darf sich Microsoft auch über den Support machen. Eine kurze Googlesuche fand übrigens als ersten Treffe den hier: http://support.microsoft.com/kb/2646504/en-us Es ist also genau so, wie bei einer lokalen Installation.

Moin, wirf mal in den Postfach-Eigenschaften einen Blick auf die Reiter "Postfachfunktion". ;)

Bei Microsoft wird das "Application-Awareness" genannt und bedeutet, dass die Application WEISS, was gerade passiert und darauf geeignet reagieren kann. Exchange ist Hyper-V-aware und es ist VSS-aware, auch im Hyper-V. Aber es ist zur Zeit noch nicht Replica-Aware. Aber nichts desto trotz, überträgt ein Replica ja trotzdem noch ca. alle 5 Minuten Daten hinterher. Und diese Differenz führt zu inkonsistenten Datenbanken. Also muss man in Hyper-V wieder einen Snapshot zurückspringen und Snapshots sind nicht supported. Wie auch immer Du das drehst, Du landest im Augenblick in einem unsupported Szenario. Und wenn Du es falsch machst, landest Du auch bei defekten Datenbanken. Und wenn Du dann auch noch DAGs einsetzt, kannst Du in einem Failover-Fall die Kopie wegwerfen und musst Reseeden, da die Daten dann nicht mehr synchron sind. Wie so oft heißt es bei "unsupported" ja nicht zwingend, dass es nicht funktioniert. Daran hatte mich die ursprüngliche Eingangsfrage in diesem Thread ja auch interessiert.

Wieso sollte ein Konstrukt, wo Datenverlust sicher auftritt, supported und geeignet für eine Disaster Lösung sein? Aaus Exchange-Sicht sind das Snapshots, die auch unsupported sind. Ob die überhaupt von Exchange sauber als VSS-Backup erkannt werden, habe ich noch nie ausprobiert. Aber falls es Dich beruhigt. Wir haben das intern wirklich schon mal diskutiert. Eindeutig Antwort: Unspported. Auf die Rückfrage, ob das irgendwo steht, gab es die Antwort: Ist das hier (Klick 2010 oder Klick 2013) eine supported Lösung? Nein! Also ist es unsupported!

Moin, die 2x 2 Dienste laufen (die sind auch bei 2013 auf manuell gestellt)? Sind Computer-Einschränkungen für die User-Accounts gesetzt? Login mit UPN sollte eigentlich gehen (Achtung: UPN sieht nur aus wie eine E-Mail-Adresse, entspricht aber bei den meisten Installationen NICHT der E-Mail-Adresse). Aber eventuell spielst Du mal ein wenig mit den Login-Methoden rum: http://technet.microsoft.com/de-de/library/aa997154(v=exchg.150).aspx Parameter LoginType.

Ja, und das funktioniert auch. Habe ich schon zweimal im Einsatz. Und natürlich KEINE Replica für die Exchange-VMS! Bei mir sieht das so aus: Je Host: 1x DC und 1x Exchange. Und dazu habe ich z.B. einen virtuellen RDS und einen WSUS - die sind beide Replika. Keine Ahnung, ob das offiziell supported ist, aber darin verändert sich nicht ständig wichtige Daten.

Aber die sieht ja normalerweise niemand. Nur der Admin, der sich auf die Mangement-Webseite der Firewall bewegt. Und da kann ich mit einer Warnung leben, wie oft bin ich da schon. Im Prinzip kannst Du das halten, wie der berühmte Dachdecker - und am Ende ist es auch eine Kostenfrage. Ein Zertifikat mit nur einem Namen ist billiger, als ein SAN-Zertifikat. Wenn man aber mehrere Namen braucht, ist SAN am Ende billiger, als 10 einzelne Zertifikate. Wenn alles unter einer Hauptdomäne läuft, kannst Du eventuell auch ein Wildcard-Zertifikat einsetzen (d.h. es hört auf "*.deinedomäne.tld"). Exchange kann das, die Frage muss aber geklärt werden, ob es die anderen Dienste auch kenne. Die wichtigste Frage: Wie vertrauenswürdig muss das nach außen sein? Wenn es nur Mitarbeiter und ein paar ausgewählte externe sind, würde ich das sehr einfach halten. Wenn aber viele Kunden ein Zugriff haben, würde ich zumindest für diese Dienste eigene Zertifikate machen. Korrekt. Aus meiner Sicht ist Ex 2013 einfach noch nicht marktreif. Das wurde schlicht 6 bis 12 Monate zu früh veröffentlicht. In der internen Maillingliste diskutieren wir eine Menge, lustiger Bugs. Bugs, die aber für manche Kunden sehr schnell zum Show-Stopper werden können (wenn z.B. der Transportdienst einfach aufhört zu funktionieren und nur durch einen Dienstrestart wieder aktiviert werden kann - ärgerlich dabei ist: Die Dienst selbst steht auf gestartet, er funktioniert nur schlicht nicht mehr). Es ist die merkwürdige Bedienoberfläche, wo viele Dinge einfach fehlen (keine Ausgabe der PowerShell-Befehle, z.B.). Es ist das sehr kritische Update-Verhalten der CU, die quasi jedesmal ein Service Pack sind, und besondere Berechtigungen und in vielen Firmen auch besonderes QM brauchen. Es ist die noch nahezu fehlende Drittanbeiter-Unterstützung, also fehlende Virenscanner, Anti-Spam oder Backup Lösungen. Meine Kunden bekommen von mir ganz deutlich gesagt: Testen ja, produktiv noch nicht.

Moin, bist Du sicher, dass das Archiv wirklich von den einzelnen Nutzern ist? Jeder, der das freigegebene Postfach einbindet, bekommt natürlich auch das Archiv des freigegebenen Postfaches eingebunden (Autodiscover sei dank). Ansonsten ist die Frage vielleicht in den offiziellen Support Foren von Microsoft besser aufgehoben, weil dort im Gegensatz zu hier auch Microsoft-Leute aktiv sind. Und schließlich bezahlst Du die ja auch dafür, oder?