Jump to content

M. Bohlmann

Members
  • Gesamte Inhalte

    8
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von M. Bohlmann

  1. Nunja, da würde sich mir die berechtigte Frage stellen, wo sie denn sonst liegen sollte Ist ja beim 2010 "nur" eine zusätzliche DB, die Replikation stellt man halt durch die PF Replica sicher, nicht durch die DAG Features.
  2. Eigentlich schon. Als ich nach 14 Tagen nach MoveAllReplicas.ps1 gescahut habe, war nur noch ein Ordner vorhanden (get-publicfolderstatistics), dieser befand sich aber bereits auf dem DAG und hatte dort auch mehr Elemente. Ich habe danach noch 3 Tage zugewartet, weil ich auch erst dachte, der ist noch nicht fertig - es hat sich aber in den 3 Tagen gar nichts mehr am Ergebnis geändert. Hänge ich die PF DB auf dem ex3 aus, so kann man ganz normal auf diesen Ordner zugreifen, daher gehe ich davon aus, dass der auch rübergewandert ist, nur halt der Move nicht sauber abgeschlossen werden konnte. Das ist an sich nix Ungewöhnliches, das hatte ich auch schon an anderer Stelle. Das Interessante ist ja, dass Mails an Ordner nicht zugestellt werden, die definitiv nicht mehr auf dem ex3 liegen - erst wenn ich die PF DB dort wieder einhänge, gehen die aus der Queue auf dem ex3 raus und werden in die Ordner auf ex1 und ex2 zugestellt.
  3. Die sind alle aktuell. Ich hatte die hochgezogen vor der Migration.
  4. Andere Annäherung an das Thema.... verteil doch Profile auf deine iOS Devices. So machen wir das bei uns, allerdings geben wir dabei noch ein Clientzertifikat mit. Muss man aber nicht. Vorteil: der User hat nie was mit Mailkonfiguration zu tun. Nachteil: Ändert er sein Domain PW, muss er bei mir antanzen. Könnte man mit einem MDM aber auch in den Griff bekommen, ist mir aber zu Overkill bei den paar iOS Devices, die ich hab.
  5. Die Frage beantwortet hat allerdings auch noch keiner Search-Mailbox -Identity "Username" -SearchQuery 'empfangen:<30.04.2017' -deletecontent oder auch Get-mailbox -Identity "Username" | Search-Mailbox -SearchQuery "empfangen:<30.04.2017" -DeleteContent sollte das tun, was er sucht. Bevor du aber mit so Keulen wie -deletecontent hantierst, solltest du dir ziemlich sicher sein, dass du weisst, was passiert. Ich würde erst versuchen, den User zur Archivierung zu überreden - wie auch immer diese aussehen könnte.
  6. Hi Leute, ich bin bissel mit meinen Debugfähigkeiten am Limit angekommen und suche neuen Input zu einem Phänomen beim Mailrouting von emailaktivierten öffentlichen Ordnern. Das Setup ist sehr ungewöhnlich und wurde nicht durch mich "verbrochen", ich kämpfe da auch an anderen Stellen immer mal wieder mit seltsamen Phänomenen. Im Kern geht es darum: Wir haben einen DAG aus 2 Ex2010, die auch beide ein PF-DB haben, sowie eine sehr umfangreiche PF Struktur von mehreren 100 Ordnern, viele davon emailaktiviert. Bei einer kürzlich durchgeführten Migration wurden von mir aus einer externen Exchange Struktur Postfächer und auch Public Folders mittels eines zusätzlich danebengestellten Ex2010 übernommen (mit Code2 für Exchange). Das hat den Grund, dass ich den DAG nicht direkt anbinden konnte für die Migration. Wir haben also quasi einen Umweg über einen 3. Exchange 2010 genommen, den ich in die Domäne neben den DAG installiert habe. Die Migration der Postfächer war soweit unspektakulär, diese befinden sich mittlerweile in einer neuen Datenbank auf dem DAG, die MigrationsDB auf dem 3. Server ist ausgehängt. Nun habe ich vor ca. 4 Wochen die öffentlichen Ordner auf den DAG verschoben. Gemacht habe ich das (wie eigentlich immer) mit den entsprechenden PF Skripten. Zunächst habe ich die beiden DAG Server als Replikatserver auf den PF hinzugefügt (AddReplicaToPFRecursive.ps1) und 4 Wochen abgewartet (die Struktur ist sehr gross, wie gesagt). Vor ca. 4 Wochen habe ich dann alle Replica vom 3. Server auf einen der beiden DAG Server verschoben (MoveAllReplicas.ps1) und wieder 2 Wochen gewartet. Eine Prüfung der aktuellen Replica zeigt auch korrekterweise nur noch die beiden DAG Server an, der 3. Server ist da nicht mehr enthalten. Auf dem 3. Server selber ist ein Replikat nach MoveAllReplicas.ps1 verblieben, was schon mal passieren kann, aus welchen Gründen auch immer, get-PublicfolderStatistics -server ex3 zeigt also noch einen verbliebenen Public Folder an. Den gibt es aber auch auf ex1 und ex2, dort hat er mittlerweile auch mehr Elemente, also gehe ich davon aus, dass das irrelevant ist. Jetzt fängt aber der nicht so lustige Teil an. Ich habe die PF DB auf dem ex3 ausgehängt - und, da ich ein vorsichtiger Mensch bin, ein paar Tage abgewartet. Nach einigen Tagen hatten wir dann plötzlich Mails in einer Queue auf dem ex3, die alle an emailaktivierte öffentliche Ordner adressiert waren, die vorher in der PF DB auf dem ex3 residierten. Hänge ich die DB wieder ein, leert sich die Queue. Ich finde den ex3 in keiner Stelle der Konfig mehr, ich habe da mehrfach alles links und rechts gemacht. Die Benutzer können auch auf alle Public Folder zugreifen, wenn die PF DB auf dem ex3 ausgehängt ist, sie können halt nur keine Mails dahin schicken. Mir sind leider keine forensischen Mittel mehr bekannt, mit denen ich den Mailfluss tracen und sinnvoll debuggen kann, damit ich irgendwie dahinterkomme, an welcher Stelle in der Konfig diese eigentlich leere PF DB für eine Zustellung einer Mail an einen öffentlichen Ordner benötigt wird, der selbst eigentlich auf ex1 oder ex2 liegt. Ich brauche also ein wenig Schwarmwissen
  7. Hallo Leute, ich bin wahlweise blind oder doof, aber ich finde es einfach nicht. Vermutlich bin ich mittlerweile so betriebsblind, dass ich den Wald vor Bäumen nicht mehr sehe. Ich bitte um Hilfe. Folgendes: Exchange 2010 Koexistenz zu 2003 (Migration), die Migration ist zu grossen Teilen abgeschlossen. Alle Postfächer, sowie die öffentlichen Ordner und das OAB sind auf dem Ex2010. AD wurde ebenfalls auf neue Server migriert, alle FSMO Rollen sind transferiert. Auf dem Ex2010 wurde ein Wildcard Cert importiert und aktiviert, ich habe alle relevanten Pfade auf einen dem Zertifikat matchenden Namen umgestellt, der Name ist im DNS auf die interne IP des Server auflösbar. Sagen wir der Server heisst Ex2010 und ist in der Domäne kunde.local. Das Zertifikat ist ausgestellt auf *.externekundendomain.de, alle Pfade laufen auf ex2010.externekundendomain.de. Umgestellt habe ich (wie immer, und ich hab das schon mehr als einmal gemacht): ClientAccessServer -AutodiscoverServiceInternalUri AutodiscoverVirtualDirectory -internalUrl -externalUrl WebservicesVirtualDirectory -InternalUrl -externalUrl sowie die Pfade für ECP, OWA und OAB (auch internal und external). Outlook Anywhere ist (noch) nicht aktiviert. Soweit so gut, dachte ich und öffnete Outlook - welches mich freundlich mit einer Zertifikatswarnung empfing: der ausgestellte Name matcht nicht auf den Servernamen - kein Wunder, er versucht ja auch weiterhin auf Ex2010.kunde.local zu verbinden?!? Öhm. Autodiscover funktioniert tadellos, im gelieferten XML steht überall der "richtige" Name, nur nicht im Konto - da steht als Server immer noch der local domain name. Eigentlich dachte ich, dass das die Aufgabe der AutodiscoverServiceInternalUri ist. Also bis heute jedenfalls. Also, bin etwas ratlos, hoffe jemand haut mir leicht auf den Hinterkopf ;-) Danke, Martin
×
×
  • Neu erstellen...