stevenki

Nein, ich kann da leider nichts einstellen außer Kontingente

Hallo, wir haben unsere Migration von Exchange 2010 zu 2016 erfolgreich und problemlos durchgeführt. Leider habe ich noch ein Problem mit den öffentlichen Ordnern bzw. mit dem Postfach für öffentliche Ordner. Beim erstellen hat dieser sich leider die Emailadresse mit der internen Domain gezogen ... diese ist natürlich nicht im Zertifikat enthalten. Wie bekomme ich diese Mailadresse geändert? über Get-mailbox -PublicFolder bekomme ich das Postfach angezeigt, über Get-mailbox -PublicFolder | Select-Object displayname,EmailAddresses, PrimarySmtpAddress,WindowsEmailAddress bekomme ich das Postfach aufgeführt und in allen Spalten steht @domain.local Aber wie bekomme ich die Werte angepasst? Wenn ich über Get-mailbox -PublicFolder | Set-Mailbox -PrimarySmtpAddress PF_master@domain.de versuche, die Adresse anzupassen, sagt er mir folgenden Fehler: Das Objekt ist natürlich vorhanden und sämtliche andere Vorgänge (neuer Mailbox / neuer User, Mailbox / User ändern) funktionieren einwandfrei über die Powershell. Das Problem betrifft tatsächlich nur das Konto für die öffentliche Ordner. Vielen Dank für eure Hilfe

Hallo, vielen Dank erstmal für eure Antworten. Leider kann ich die Kritik teilweise nicht ganz verstehen - warum eine Umgebung nachbauen, die nicht aussagekräftig ist? Es ist doch ein 1:1 Abbild der original Umgebung, wenn diese Testumgebung nicht aussagekräftig ist, welche dann? Warum wir das selber machen steht leider in der Form nicht zur Diskussion, auch wenn ich eure Argumente verstehe. Aber das entscheide ja nicht ich. Und an sich finde ich unsere Exchange Umgebung ja auch nicht wirklich komplex, es ist keine DAG vorhanden oder die Rollen auf unterschiedlichen Servern verteilt sondern ein Single-Server. Und es ist auch nicht so , dass ich Exchange vorher noch nie gesehen habe, es ist halt meine erste Migration, die ihr ja auch irgendwann mal als erstes gemacht habt. Könnt ihr mir den Tips geben, wo ich ansätzen könnte? Die DNS Einträge (Split-DNS) sehen folgend aus: autodiscover.domain1.de -> interne IP Exchange 2010 autodiscover.domain2.de -> interne IP Exchange 2010 autodiscover.domain3.de -> interne IP Exchange 2010 usw. mail.hauptdomain.de -> sämtliche URLs auf dem Exchange 2010 sowie auf dem 2016. -> zeigt auf den 2010er. Je nachdem, wo ich diese Einträge hinlenke, dieser Exchange funktioniert dann in Bezug auf Outlook Konnektivität ... Die Proxyfunktion fürs OWA funktioniert wiederrum ohne Probleme wenn die DNS Einträge auf den 2016er zeigen und ich mich im "neuen" OWA anmelde

Hallo zusammen, eins vorab, es ist meine erste Exchange Migration und ja ich weiß, dass das hätte schon lange passieren müssen, aber leider ist die Personaldecke eben sehr sehr dünn. Ich habe unsere Umgebung auf einem Testserver wiederhergestellt um dort entsprechend mit der Liveumgebung bauen zu können. Unsere Liveumgebung besteht aus mehreren Standorten, 15 DCs und 1 Exchange. Der Exchange hat eine DB Größe von ca. 3 TB (aufgeteilt auf 5 DBs) und ca. 2000 Postfächer und ca. 20 Domains. (Ja ich weiß, 1 Exchange ist deutlich zu wenig für eine gewisse Verfügbarkeit, allerdings auch hier siehe mein Eingangstext ) Ich hab den DC, der am selben Standort wie der Exchange steht und Inhaber sämtlicher Rollen ist im Testsystem wiederhergestellt, sämtliche anderen DCs sauber entfernt (NTDSUTIL,...), Standorte gelöscht usw. Desweiteren habe ich den Exchange wiederhergestellt und mir noch 2 Clients Windows 10 mit Office 2016 installiert. Dann habe ich in der Testumgebung einen weiteren Server installiert (Server 2016) und den Exchange (aktuellster Patchstand) installiert und mich in soweit an dieser Anleitung orientiert: https://www.frankysweb.de/migration-von-exchange-2010-zu-exchange-2016-teil-1/ Leider habe ich jedoch ein großes Problem mit der Outlook Konnektivität. Wenn ich den DNS auf den alten Exchange zeigen lasse, kann ich Outlook mit Benutzern nutzen, dessen Postfächer noch auf dem alten Exchange liegen. Ändere ich den DNS auf den neuen Exchange, funktioniert dies jedoch nicht mehr. Beim Start erhalte ich dann nur die Fehlermeldung, das die OST Datei beschädigt ist und die Ordnergruppe nicht erweitert werden kann (an der OST kann es nicht liegen, das betrifft auch neue Profile). Andersrum ist es genauso. Lasse ich den DNS Eintrag auf den alten Exchange zeigen, bekomme ich die gleiche Meldung von Benutzern, deren Postfächer schon auf den neuen Server migriert wurden. Ändere ich die DNS Einträge auf den neuen Exchange, funktionieren eben diese Postfächer. Ich kann also immer nur die Postfächer nutzen, die auf dem Exchange Server liegen, auf den der DNS auch zeigt. (ich rede hier natürlich von autodiscover Einträgen und und den entsprechend konfigurierten URLs, in unseren Fall mail.domain.tld) Konfiguriert ist Split DNS. Ansonsten was funktioniert: Zeigt der DNS auf den neuen Exchange, kann ich über die URL auf das OWA zugreifen. Hier funktioniert beides, ein Postfach, welches auf dem neuen Exchange liegt, wird mir nach Anmeldung im neuen OWA angezeigt. Ein Postfach, welches auf dem alten Exchange liegt, wird mir nach erfolgreicher Anmeldung im alten OWA angezeigt. Auch der Mailfluss funktioniert auf beiden Exchange Servern ein- sowie ausgehend und auch zwischen Postfächern untereinander. (habe eine zusätzliche Domain auf dem Testsystem konfiguriert, welche im Echtsystem nicht existiert - daher kann ich auch Ein- und Ausgehend Extern Testen) Vielleicht könnt ihr mir ein Denkanstoss geben, wie ich das Problem lösen könnte. Sollten noch Infos fehlen, liefere ich die natürlich gerne nach. Vielen Dank an euch

Hallo an alle, wir befinden uns derzeit in der Planung zur Migration zu O365, vorrangig geht es da erstmal nur um die Ablösung unseres Exchange. Leider ist in unserer Umgebung aufgrund von Übernahmen usw. kein einheitliches Konzept für Emailadressen vorhanden. Die bestehenden Mailadressen sind alle Unterschiedlich (mal nur der Nachname, mal Vorname[1]Nachname, usw.) Wir wollen das auf ein einheitliches Konzept setzen und in diesem Zuge auch die Anmeldenamen anpassen. Eigentlich war mein erster Gedanke die Anmeldenamen identisch zu den neuen Emailadressen [Vorname].[Nachname]@ zu erstellen. Das wäre für unsere überwiegend sehr unerfahrenen PC-User einfach verständlicher, wenn Sie sich später für Teams oder andere Dienste mit einen Account identisch zu Ihrer Emailadresse anmelden. Wäre der Account <> Emailadresse sehe ich bei uns großes Chaos, da ja die Anmeldung bei Microsoft in Form einer Emailadresse stattfindet. Naja ich denke ihr wisst was ich meine. Jetzt bin ich unser gesamtes AD durchgegangen und habe in einer Excel mal das neue Konzept [Vorname].[Nachname] als AD Konto und gleichzeitig Emailadresse durchgeplant. Jedoch ist mir erst mit dem neuen Konzept aufgefallen, dass der samAccountName max. 20 Zeichen lang sein darf. Das doppelte Einträge vorhanden sind, war natürlich vorher schon abzusehen. Hier mal das Ergebniss der Excel: insgesamte AD-Konten: 2079 Doppelte Anmeldenamen: 27 zu lange Anmeldenamen: 43 Sicher sind die doppelten und zulangen im Verhältnis zum Gesamten relativ gering. Aber grade die zu langen Anmeldenamen verunsichern mich etwas, und daher wollte ich hier einfach nach euren Erfahrungen (in etwas größeren Umgebungen) fragen, wie ihr das handhabt? Vorallem in Bezug auf das Zusammenspiel mit O365 wo ja der UPN zur Anmeldung genutzt wird? -Wie geht ihr mit Doppelungen um? Auch in Bezug auf die Mailadresse? -Mir noch viel wichtiger, wie geht ihr mit zu langen Anmeldenamen um? Macht ihr samAccountName und UPN dann unterschiedlich? Wie ist der samAccountName dann in diesem Fall? (hier habe ich Wiederrum Sorge, dass das zu Verwirrung führt, da einige Programme bei uns "AD" gekoppelt sind und die meist den samAccountName nutzen) Wie melden sich die User bei euch an? Mit dem samAccountName oder dem UPN? Vielleicht kann mir ja jemand ein paar Denkanstöße geben Lieben Dank

Das klappt soweit, was aber beinhalten die "Shadow" Paramter? Ich habe einen User angepasst, den Alias via Exchange Shell. Soweit alles gut, aber die Parameter msExchShadowMailNickname msExchShadowProxyAddresses sind noch "alt". Bei ProxyAdress ist noch die alte Email drin, in Mailnickname eben der alte Alias. Für was sind diese Attribute vorhanden? Kann / Muss ich die via Powershell anpassen (AD-Modul) oder müssen die ggf. über ein O365 Powershell / Exchange Modul geändert werden?

Okay, aber der Alias bzw. die Exchange Funktion ist ja demzufolge erstmal unberührt von der AD Konto Umbennenung, korrekt? Das heißt den Alias kann ich "Alt" lassen, wenn er eh nicht per Powershell angepasst werden darf, richtig? Danke schonmal für deine Antwort

Hallo an alle, wir möchten / müssen bei uns im AD die Kontonamen umstellen vom Schema [Vorname(1)][Nachname] auf [Vorname].[Nachname]. Derzeit ist im Einsatz AD Domain und Funktionslevel Level 2008 R2 (ja ich weiß) sowie Exchange 2010. Der Exchange soll zukünftig durch O365 abgelöst werden, Azure AD Connect ist schon im Einsatz. Unabhängig von der späteren Exchange Umstellung geht es jetzt erstmal nur ums on premise. Wenn ich mir mit Get-Aduser [username] -properties * alle Attribute anzeigen lasse, finde ich den Kontonamen derzeit in folgenden Attributen: samAccountname - ist klar UserprincipalName - auch klar mailNickname msExchShadowMailNickname Jetzt meine Frage, welche Bedeutung haben diese beiden Attribute? Wenn ich die oberen beiden Werte per Powershell anpasse, muss ich das dann auch mit diesen beiden Attributen machen? Vielen Dank für eure Infos und Hilfe