Exchange Online / Mailadressen abweichend der Domäne

[PEASANT KING]

Guten Morgen,

zur Zeit besitzen wir lokal eine Domäne im Stile von DOMAINNAME.local, in Zukunft gibt es eine komplett neue Domäne im Stile von ad.DOMAIN-NAME.de. Wir setzen Office 365 Business Standard ein. Hier wird auch der Exchange Online bereit gestellt.
Zur Zeit wird ein On-Premise Exchange eingesetzt, der soll aber zeitnah rausfliegen...

Im Office Admin sind Benutzer angelegt und den Benutzern sind Lizenzen hinterlegt. Nun habe ich hier schon die zwei Domänen.
An den Mailadressen im Stile von vorname.nachname@fir-ma.de hat sich nichts geändert aus der alten Domäne.

Gerne würde ich die Mailadressen in der neuen Domäne weiter nutzen, allerdings habe ich in Exchange Online gar nicht die Möglichkeit diese Mailadressen zu zu ordnen, da er mir nur vorname.name@ad.fir-ma.de zulässt.

Was muss ich machen? Kann mir Jemand sagen, was ich hier falsch mache? Steh hier etwas auf dem Schlauch...
Ich wollte das Ganze mal vorab testen mit einem Testbenutzer Account, um dann später das Ganze zu migrieren, wenn es so funktioniert wie wir uns das vorstellen.

 

[Zensai]

Hast du definitiv fir-ma.de im Tenant validiert?

Admincenter-> Einstellungen-->Domänen?

Subdomain verifizieren nicht automatisch die Hauptdomain mit und umgekehrt. Jede muss separat validiert sien.

Lautet euer UPN auf fir-ma.de? (Nicht notwendig, aber sinnvoll).
Baust du einen Hybrid? Wenn nein, warum nicht? Das wäre der richtige Weg. Du kannst ja schlecht testen ohne Hybrid, da der MX, autodiscover etc pp ja auf die Onprem Umgebung zeigt.

 

[mawa78]

Warum keine Hybrid Konfiguration und anschließend die Postfächer migrieren?

 

[nitech]

Du musst, wie Zensai schon geschrieben hat, die zweite Domain in den Einstellungen hinterlegen und validieren.
mfg

 

[PEASANT KING]

Der Experte der die Hauptdomain vor meiner Amtszeit hier angelegt hat, hat Hauptdomain schon hinzugefügt, allerdings mit FIRMA-Name.de was mich schon stört, da die Hauptdomain firma-name.de lautet.

Der UPN Name im On-Premise lautet vnachname@XXX.local wobei die drei X dem Pattern entsprechen wie die Domain auf dem DC lautet.
Ich würde gerne eine Hybrid Geschichte aufsetzen, da ich denke, das hier auch die Übernahme der Konten plus Inhalt viel einfacher von statten gehen wird.

Ich frage mich auch, wenn ich die Hauptdomain im Office Admin lösche und neu einpflege was passieren wird.
Bis jetzt sind hier nur die Benutzer angelegt mit dem Username endend auf eine Groß und Kleinschreibung im Domain Namen was mich stört, da im Absender das Ganze dann auch so drin steht. Was sonst das alles für Auswirkungen hat, da wir ja nur den On-Premise benutzen zur Zeit weiß ich nicht.

Wir haben ja auch noch Azure da ist die Domäne auch eingebunden, aber Azure Domänen Dienste werden soweit ich weiß gar nicht genutzt.

Ich muss mich hier durch kämpfen, weil keiner hier sagen kann was gemacht wurde, wie es gemacht wurde, warum etc. das ewige Problem von mittelständischen Unternehmen die schnell gewachsen sind und mit der IT nicht hinterher gekommen sind.

 

[Zensai]

Uff, da würde ich jetzt aber aufpassen. Das hört sich stark danach an als hätte einfach mal jemand probiert was einzurichten und es dann liegen lassen.

Ich würde gerne eine Hybrid Geschichte aufsetzen, da ich denke, das hier auch die Übernahme der Konten plus Inhalt viel einfacher von statten gehen wird.

Deshalb wäre das auch der richtige Weg, abgesehen von vielen anderen Faktoren, die da noch eine Rolle spielen werden.

Ich frage mich auch, wenn ich die Hauptdomain im Office Admin lösche und neu einpflege was passieren wird.

Hängt von eurer Implementierung ab. Sind das noch komplett getrennte Systeme oder habt ihr einen AzureAD Connect oder ähnliches aufgesetzt. Allererster Punkt, an dem man ansetzt ist bis auf wenige Ausnahmen IMMER die Synchronisierung der Identitäten bzw des Active Directorys. Von da aus gehts dann Richtung Exchange, Sharepoint, Teams etc.
Habt ihr einen DIenstleister mit M365 Knowhow an der Hand? Ich würde euch DRINGEND empfehlen euch mal ein paar Stunden dahingehend beraten zu lassen, evtl bekommt ihr in PreSales Terminen schon einige wichtige Infos und könnt euch dann eine Strategie überlegen. "Einfach mal machen" ist der Hauptfaktor dafür, dass solche Projekte scheitern.
Falls keiner vorhanden ist, würde ich die üblichen verdächtigen Fragen. Auf der Microsoft Partner Seite findet ihr entsprechende Kandidaten: https://www.microsoft.com/de-de/solution-providers/home
Ein paar übliche "große" Verdächtige: SVA, Cancom, DimensionData, SoftwareOne, Novacapta, Adesso, Accenture... aufzuzählen in beliebiger Reihenfolge.

 

[PEASANT KING]

Moin moin,

deine Fragen habe ich hier ja gar nicht gesehen @Zensai ....

Also zur Zeit sind es zwei getrennte Systeme die aktuelle Domäne in Nutzung, liegt hier im Hause auf einem Server. Office 365 wird nur genutzt für die Office Anwendungen plus Teams, wobei hier ja die ganzen Vorteile nicht genutzt werden können, da die On-Premis Domäne nicht mit der Azure AD verknüpft ist.

In der Tat hat wohl mein Vorgänger hier einfach mal mit Azure AD etc rumgespielt es einfach irgendwie eingerichtet halbherzig und dann ja so hinterlassen. Ich bin dabei eine neue Domäne auf zu setzen.

Wie gesagt, die alte Domäne lautet FIRMENKÜRZEL.local und die Mailadressen bei unserem Hoster lauten VORNAME.NACHNAME@fir-ma.de, die neue Domäne lautet ad.FIRMA-NAME.de jetzt würden alle Accounts im Office 365 ja erstmal VORNAME.NACHNAME@ad.FIRMA-NAME.de lauten. Hier ist die Frage, ob es dann auch gleichzeitig die Mailadressen wären, denn ich benötige VORNAME.NACHNAME@fir-ma.de als Mailadressen, da dies unsere offiziellen Adressen nach Außen sind, oder ist hier die Möglichkeit gegeben die Adressen anzupassen? Der NETBIOS Name würde sich auch ändern von FIRMENKÜRZEL nach FIRMEN-KÜRZEL.

Wenn das klar ist, wäre es nicht so schwierig einen Umzug zu gestalten und die Vorteile nutzen zu können, die hier dann geboten würden.

Grüße

 

[t-6]

jetzt würden alle Accounts im Office 365 ja erstmal VORNAME.NACHNAME@ad.FIRMA-NAME.de lauten.

Nope, genau das wird nicht passieren, außer Ihr validiert die öffentliche Domäne ad.firma-name.de - was aber nicht gemacht werden sollte.

Die Vorgehensweise wäre ungefähr wie folgt:
-neue interne Domäne ad.firma-name.de aufsetzen
-in der internen Domäne einen separaten UPN-Suffix fir-ma.de anlegen (ja, das ist eure öffentliche Domäne! wichtig!)
-wenn Ihr jetzt im AD neue Benutzerkonten anlegt, dann solltet Ihr künftig als Benutzername das - geplante - Email-Alias nehmen + das UPN-Suffix fir-ma.de aus dem Dropdown-Menü wählen --> als Endergebnis sieht der (moderne) Benutzeranmeldename aus wie die Email-Adresse des Benutzers; so müsst Ihr den Benutzern nur noch sagen, dass sie sich "am Computer" mit der Email-Adresse anmelden sollen. weniger Verwirrung. Mischt bloß nicht Computer-Benutzeranmeldename & O365-Anmeldename. Die Leute sehen nur das @Zeichen und denken sofort an die Email-Adresse; also nehmt auch besser die "Email-Adresse"
-die Domäne fir-ma.de bei Office 365 validieren & als Standarddomäne in O365 hinterlegen
-Azure AD Connect installieren & durchkonfigurieren --> als Endergebnis werden Benutzer aus dem AD zu O365 hochsynchronisiert, wahlweise/idealerweise mit demselben Passwort wie für den PC
-diesen O365-Benutzern können dann die O365-Lizenzen zugeordnet werden
-idealerweise noch 2FA für die Anmeldung an den O365-Diensten aktivieren + alles was Azure als Sicherheitsfeatures sonst noch so anbietet

Da ist schon noch ein wenig mehr hinter, soll aber erst mal einen groben Abriss geben.

 

[PEASANT KING]

Danke schon mal für die ausführlichen Beschreibungen.

In der Azure AD kann ich ja das User Prinzipal von VORNAME.NAME@ad.fir-ma.de ändern in VORNAME.NAME@fir-ma.de und das gleiche kann ich auch mit der Mailadresse machen.

Frage aus folgendem Grund, das Problem ist, die Benutzer sind schon in O365 angelegt worden vom Vorgänger, allerdings in einer falschen Domäne FIR-Ma.de und so lauten auch deren Mailkonten.
Durch die Anlage einer neuen Domäne im O365 die ad.fir-ma.de lautet werden alle Benutzer dann leider die Mailadresse vorname.name@ad.fir-ma.de lauten. Das ist Käse denn die Mailadressen lauten eigentlich vorname.name@fir-ma.de

Ich habe es soweit konfiguriert, das Mails aus einem Testkonto in der neuen Domäne versendet werden, innerhalb der Domäne, allerdings kommen die eingehende Mails nicht auf dieser Testadresse an sondern auf die ....@ad.fir-ma.de hier geht auch das erhalten externer Mails von Drittanbietern.

Sinn der Sache ist, das ich neben der bestehenden Domäne einfach die Neue aufsetzen kann und Stück für Stück die Mitarbeiter etc. umziehen kann.

 

[t-6]

Durch die Anlage einer neuen Domäne im O365 die ad.fir-ma.de lautet werden alle Benutzer dann leider die Mailadresse vorname.name@ad.fir-ma.de lauten. Das ist Käse denn die Mailadressen lauten eigentlich vorname.name@fir-ma.de

Na das war ja richtig dämlich dass die interne Domäne bei O365 verifiziert wurde und diese Adressen anscheinend auch nach draußen - wenn auch unabsichtlich - kommuniziert und produktiv genutzt werden.

Usus bei der Benennung einer internen AD-Domäne: Sie soll den Namen einer - öffentlich - fiktiven Subdomäne haben, die auf einer Domäne basiert die der Firma gehört. So weit so gut. ad.fir-ma.de erfüllt das.

Aber: Diese Subdomäne darf öffentlich nicht auflösbar sein (das beinhaltet btw auch Wildcard-DNS)

Also irgendwie alles falsch gemacht.

===

An dieser Stelle würde ich die Domäne (intern sowie extern) ad.fir-ma.de in den Ruhestand schicken und die alten @ad.fir-ma.de Adressen als Alias auf den Postfächern lassen (MX-Einträge beibehalten!) und verdammt noch mal sicherstellen, dass die Domäne fir-ma.de auch wirklich die Standard-Domäne ist, damit neue Konten nicht aus Versehen wieder mit der falschen Domäne primär angelegt werden.

Die neue interne Domäne soll dann lauten bspw. intern.fir-ma.de mit einem alternativen UPN-Suffix fir-ma.de

In O365 die "Cloud"-Konten von der Konvention her geradeziehen, also den AzureAD-Anmeldenamen & die Haupt-Email-Adresse angleichen.
Im lokalen AD (neue Domäne) die Konten mit dem Benutzeranmeldenamen mittels des UPN-Suffix identisch wie im AzureAD anlegen.
AzureAD-Sync sollte(tm) die AAD-Cloud-Konten dann mit den lokalen AD-Konten matchen, da der Benutzeranmeldename identisch ist. Hier sollte sich aber jemand ins Boot geholt werden, der die Umgebung noch mal genau analysiert und die Schritte durchgeht.

Von wieviel Konten reden wir hier?

 

[PEASANT KING]

Wir reden hier zur Zeit von 41 Konten.

Ne ich glaub ich habe mich falsch ausgedrückt. Die zur Zeit interne Domäne lautete FIRMAKÜRZEL.local
in Azure AD hat man die Domäne angelegt mit FIR-ma.de, die aktuellen Konten und Mailadressen enden alle auf vorname.name@FIR-Ma.de, das sieht nicht nur scheiße aus, es ist auch dumm.

Ich kann in Azure Center ja die Anmeldungen ändern in vorname.name@fir-ma.de aber die Mailadresse basiert immer noch auf der schlecht angelegten Domäne im Azure.

Was würde passieren, wenn ich die Domäne lösche, die User vorher in einer temporäre Domäne schiebe in Azure, dann die Domäne im Azure einmal richtig aufsetze und dann die neue interne Domäne mit Azure verknüpfe?

Wenn ich die Domäne in Azure lösche, wie sieht es mit der Nutzung von Team und den MS Produkten aus?
Da der komplette Mail und KAlernder Kram über Exchange on premise läuft würde es hier ja schon mal keine Probleme geben oder? Aber wie sieht es aus mit Teams oder den Produkten? Muss ich dann die Lizenzen wieder neu zu ordnen, weil die komplette Domäne weg ist?

EDIT:
Kann ich den Domänennamen nachträglich von FIR-Ma.de in fir-ma.de glattziehen?

 

[t-6]

What. Es geht hier nur um Groß/Kleinschreibung?

Woher kommt denn jetzt bitte die Domäne ad.fir-ma.de aus dem ersten Beitrag?

 

[PEASANT KING]

Die Domäne ad.fir-ma.de ist die neue interne Domäne im Unternehmen. Die alte ist FIRMENKÜRZEL.local.
Beide Domänen gibt es im Office Center bzw. Azure. Weg müssen beide, wobei die FIRMENKÜRZEL.local als
FIR-Ma.de in Azure bzw. Office anglegt worden ist.

Hier war die Frage, kann ich die einfach löschen und vernünftig lowercase anlegen, damit ich die mit der neuen internen Domäne verknüpfen kann? Was hat das Löschen der FIR-Ma.de für Auswirkungen auf zugeordnete Lizenzen und Benutzer. Für was anderes wird zur Zeit Office365 auch nicht genutzt.

 

[t-6]

Weg müssen beide, wobei die FIRMENKÜRZEL.local als
FIR-Ma.de in Azure bzw. Office anglegt worden ist.

Es ist nicht möglich eine .local-Domäne bei O365 zu registrieren, weil man dazu eine öffentliche Domäne braucht. Was bei .local aber nicht möglich ist.
Daher die Frage: Inwiefern ist FIRMENKÜRZEL.local exakt in O365 "angelegt"? Was bedeutet dass FIRMENKÜRZEL.local als FIR-Ma.de "angelegt" ist? Habt Ihr in irgendeiner Form AzureAD Sync am Laufen?

 

[PEASANT KING]

Ich glaub ich komme hier total dumm rüber xD.

Also wir besitzen mehrere öffentliche TLDs unsere Haupt TLD ist fir-ma.de diese wurde im Office 365 als FIR-Ma.de angelegt, ist aber nicht wirklich in Benutzung, weil damals nur Office 365 angeschaft wurde wegen der Programme im Abo .... Diese Domäne hat nichts mit der internen FIRMANAME.local erst mal zu tun.

Die interne Domäne wurde sehr leienhaft eingerichtet und verwaltet, wenn man das überhaupt Verwalten nennen kann. Ich bin dabei eine neue Domäne intern anzulegen ad.fir-ma.de und diese mit einer neuen Domäne fir-ma.de in Office 365 bzw. Azure zu verbinden.
Dafür würde ich allerdings gerne erst mal die FIR-Ma.de in Office löschen und dann als fir-ma.de neu anlegen
und dann Stück für Stück migrieren.

Also ja FIRMENKÜRZEL.local ist in Azure bzw. Office 365 als FIR-Ma.de angelegt, ich hätte es allerdings gerne richtig, nämlich als fir-ma.de.
Eine Synchronisierung mit der lokalen Domäne gibt es zur Zeit zum Glück nicht. Ansonsten denke ich würde das Neuaufsetzen in Office 365 viel aufwendiger...

 

[nemix]

Dafür würde ich allerdings gerne erst mal die FIR-Ma.de in Office löschen und dann als fir-ma.de neu anlegen
und dann Stück für Stück migrieren.

Also ja FIRMENKÜRZEL.local ist in Azure bzw. Office 365 als FIR-Ma.de angelegt, ich hätte es allerdings gerne richtig, nämlich als fir-ma.de.
Eine Synchronisierung mit der lokalen Domäne gibt es zur Zeit zum Glück nicht. Ansonsten denke ich würde das Neuaufsetzen in Office 365 viel aufwendiger...

Denk dran das du damit im Zweifelsfall euren kompletten Mail/Teamsflow kaputt machst und jegliche Berechtigungen im Bereich Sharepoint/OneDrive damit weg sind.
Das ist keine mal eben so Sachen, einige Kollegen von mir machen derzeit viele Tenant zu Tenant Migrationen die durch Merger und/oder komplett falsche Erstinstallation ausgelöst wurden. Das muss gut durchgeplant werden, teilweise mit Microsoft Support für spezielle Anwendungsfälle und wird dann an einem Wochenende durchorchestriert um den Kunden nicht lahmzulegen.

Und wieso dich die Großschreibung stört verstehe ich nicht? Das ist eine Anzeige im Adminportal, evtl. kannst du sogar kurz ein Supportticket aufmachen und nachfragen ob man das für dich anpasst. Wenn das der einzige Grund für so eine Großbaustelle ist solltest du das ganze noch mal überdenken.

@t-6 Hat den Aufbau super beschrieben, allerdings musst du vorher prüfen welche Dienste Ihr in O365 schon nutzt und ob Ihr damit ggf. Berechtigungen etc. aushebelt.
Das ganze würde ich ohne Begleitung durch ein fähiges Systemhaus/MS Partner nicht durchführen. Im Zweifelsfall geht nach der Umstellung nichts mehr und dann stehst du alleine im Regen!

 

[Evil E-Lex]

Denk dran das du damit im Zweifelsfall euren kompletten Mail/Teamsflow kaputt machst und jegliche Berechtigungen im Bereich Sharepoint/OneDrive damit weg sind.

Genügt es nicht, alle Accounts temporär auf die onmicrosoft.com Domain umzustellen und dann die eigentliche Domain zu löschen und neu anzulegen? Natürlich ist das mit einer Ausfallzeit verbunden, aber die Accounts und Shared Mailboxes, sowie Berechtigungen bleiben erhalten. Oder bin ich da komplett auf dem Holzweg?

 

[PEASANT KING]

Das was @Evil E-Lex fragt wäre eine klasse Aktion.

@nemix es stört einfach, da die Mailadresse als vorname.name@FIR-Ma.de dargestellt wird, sieht total dämlich aus und ist auch nicht korrekt.

 

[Evil E-Lex]

@nemix es stört einfach, da die Mailadresse als vorname.name@FIR-Ma.de dargestellt wird, sieht total dämlich aus und ist auch nicht korrekt.

Das mag schon sein. Allerdings ist den Personen, die das geändert haben möchten, oft nicht klar, welche technischen Herausforderungen eine vermeintlich simple Änderung mit sich bringt.
Ich hatte mal einen Kunden der umfirmiert hat. Aus example-company wurde erst example.company und dann examplecompany. Die AD-Domain hieß aber noch so wie die ursprüngliche Domain: example-company.com
Ich sollte das nun umstellen auf examplecompany.de. Ich schlug daraufhin die Nutzung eines neuen UPN-Suffix examplecompany.de vor. Wurde abgeleht, da der NetBIOS-Domänenname weiterhin EXAMPLE-COMPANY lautete und man die Anmeldung weiterhin mit den klassischen DOMÄNE\user-Format beibehalten wollte. Die Änderung wäre also nicht sichtbar gewesen. Aufgrund von Exchange war die Änderung des NetBIOS-Domänennamens keine Option.
Nachdem ich mittels Angebot darauf hinwies, dass die gewünschte Umstellung einem vollständigen Neuaufbau der Domäne mit entsprechenden Ausfallzeiten und Kosten gleichkommt, war der Wunsch nach Umbenennung plötzlich nicht mehr so wichtig.

Kurz: Mach ein Preisschild dran und das "ach so wichtige" Problem löst sich von selbst. 🙂

 

[nemix]

Genügt es nicht, alle Accounts temporär auf die onmicrosoft.com Domain umzustellen und dann die eigentliche Domain zu löschen und neu anzulegen? Natürlich ist das mit einer Ausfallzeit verbunden, aber die Accounts und Shared Mailboxes, sowie Berechtigungen bleiben erhalten. Oder bin ich da komplett auf dem Holzweg?

Wenn kein neuer Tenant hochgezogen wird dann ja. Man sollte sich nur darum kümmern das die Emails nicht verloren gehen, falls der MX Record schon direkt auf O365 zeigt.