3
AD Server 2019 - Office 365 - hosted Exchange - Verbindung und Sync - Website
Hallo,
ich habe eine Frage zur besten Realisierung im folgenden Szenario. Ich habe einen neuen 2019er Windows Server. Dieser wird komplett neu aufgesetzt mit neuer Domäne. Dazu soll es ein Office 365 professional geben, inklusive hosted Exchange. Die MX Einträge der eigenen Domain "firmaxyz.de" wurden geändert und zeigen auf den Exchange.
Wenn ich jetzt die lokale Domäne auch firmaxyz.de nenne, kann ich mit dem Azure AD Connect Tool meine AD mit Office 365 verbinden. Somit habe ich die echten Emailadressen komplett integriert. Der Nachteil ist, dass der lokale DNS Server bei der firmaxyz.de" Domain nicht auf die Webseite verweist, solange ich das nicht per DNS Eintrag einstelle. Bei einfachen Webseiten ist das wohl kein Problem.
Oder ist es sinvoller die lokale Domäne nicht öffentlich zu benennen? Also firma.xyz.local. Funktioniert dann die Syncronisation mit Office365 noch? Macht das dann Sinn mit dem Exchange online? Was habt Ihr für Meinungen dazu? Ich möchte gern die am besten machbare Version herausfinden. Hauptsächlich geht es um kleinere Netze mit maximal 50 Usern.
Vielen Dank für Eure Antworten...
Grüße Carsten
ich habe eine Frage zur besten Realisierung im folgenden Szenario. Ich habe einen neuen 2019er Windows Server. Dieser wird komplett neu aufgesetzt mit neuer Domäne. Dazu soll es ein Office 365 professional geben, inklusive hosted Exchange. Die MX Einträge der eigenen Domain "firmaxyz.de" wurden geändert und zeigen auf den Exchange.
Wenn ich jetzt die lokale Domäne auch firmaxyz.de nenne, kann ich mit dem Azure AD Connect Tool meine AD mit Office 365 verbinden. Somit habe ich die echten Emailadressen komplett integriert. Der Nachteil ist, dass der lokale DNS Server bei der firmaxyz.de" Domain nicht auf die Webseite verweist, solange ich das nicht per DNS Eintrag einstelle. Bei einfachen Webseiten ist das wohl kein Problem.
Oder ist es sinvoller die lokale Domäne nicht öffentlich zu benennen? Also firma.xyz.local. Funktioniert dann die Syncronisation mit Office365 noch? Macht das dann Sinn mit dem Exchange online? Was habt Ihr für Meinungen dazu? Ich möchte gern die am besten machbare Version herausfinden. Hauptsächlich geht es um kleinere Netze mit maximal 50 Usern.
Vielen Dank für Eure Antworten...
Grüße Carsten
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 600856
Url: https://administrator.de/contentid/600856
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo Carsten,
ein möglicher Weg wäre es, dem Server (=DC) z.B. die Domäne "firma.int" zu geben. Anschließend legst du unter "Active Directory-Domänen und Vertrauensstellungen" ein Benutzerprinzipalnamen-Suffix mit "firma.xyz" an. Dann könntest du im AD die User auf dieses alternative Suffix im Anmeldenamen ändern. Die User haben dann als Benutzername außer "vorname.nachname@firma.int" auch noch den Anmeldenamen "vorname.nachname@firma.xyz".
Damit hat dann Azure AD Connect eine eindeutige Identifikation der User. Der Sync erfolgt dann mit dem Suffix "firma.xyz" und nicht mit "firma.int".
Hier mal die Anleitung von MS: Verzeichnissync nicht routingfähiger Domänen
Und bitte als lokale Domäne nicht mehr ".local" verwenden. Hier wird erklärt, warum:
Warum .local nicht verwendet werden sollte
Gruß Arno
ein möglicher Weg wäre es, dem Server (=DC) z.B. die Domäne "firma.int" zu geben. Anschließend legst du unter "Active Directory-Domänen und Vertrauensstellungen" ein Benutzerprinzipalnamen-Suffix mit "firma.xyz" an. Dann könntest du im AD die User auf dieses alternative Suffix im Anmeldenamen ändern. Die User haben dann als Benutzername außer "vorname.nachname@firma.int" auch noch den Anmeldenamen "vorname.nachname@firma.xyz".
Damit hat dann Azure AD Connect eine eindeutige Identifikation der User. Der Sync erfolgt dann mit dem Suffix "firma.xyz" und nicht mit "firma.int".
Hier mal die Anleitung von MS: Verzeichnissync nicht routingfähiger Domänen
Und bitte als lokale Domäne nicht mehr ".local" verwenden. Hier wird erklärt, warum:
Warum .local nicht verwendet werden sollte
Gruß Arno
ich habe eine Frage zur besten Realisierung im folgenden Szenario. Ich habe einen neuen 2019er Windows Server. Dieser wird komplett neu aufgesetzt mit neuer Domäne. Dazu soll es ein Office 365 professional geben, inklusive hosted Exchange. Die MX Einträge der eigenen Domain "firmaxyz.de" wurden geändert und zeigen auf den Exchange.
Wenn ich jetzt die lokale Domäne auch firmaxyz.de nenne, kann ich mit dem Azure AD Connect Tool meine AD mit Office 365 verbinden. Somit habe ich die echten Emailadressen komplett integriert. Der Nachteil ist, dass der lokale DNS Server bei der firmaxyz.de" Domain nicht auf die Webseite verweist, solange ich das nicht per DNS Eintrag einstelle. Bei einfachen Webseiten ist das wohl kein Problem.
Wenn ich jetzt die lokale Domäne auch firmaxyz.de nenne, kann ich mit dem Azure AD Connect Tool meine AD mit Office 365 verbinden. Somit habe ich die echten Emailadressen komplett integriert. Der Nachteil ist, dass der lokale DNS Server bei der firmaxyz.de" Domain nicht auf die Webseite verweist, solange ich das nicht per DNS Eintrag einstelle. Bei einfachen Webseiten ist das wohl kein Problem.
Nimm die eigene Domain mit einer freien Sublevel Domain für das AD. Die Anbindung an Azure AD könnte man dann über einen geeigneten UPN machen.
Oder ist es sinvoller die lokale Domäne nicht öffentlich zu benennen? Also firma.xyz.local. Funktioniert dann die Syncronisation mit Office365 noch? Macht das dann Sinn mit dem Exchange online? Was habt Ihr für Meinungen dazu? Ich möchte gern die am besten machbare Version herausfinden. Hauptsächlich geht es um kleinere Netze mit maximal 50 Usern.
.local ist nach RFC 6762 keine so gute Idee.
Bei jeder anderen Toplevel Domain kann man in der Regel heute auch nicht sicher sein, dass sie kurzfristig vergeben wird.
Hallo Arno,
vielen Dank für den Beitrag. Das kling gut, so werde ich das versuchen umzusetzten. Besten Dank!
@mbehrens
vielen Dank für den Hinweis zu .local
Grüße
Carsten
vielen Dank für den Beitrag. Das kling gut, so werde ich das versuchen umzusetzten. Besten Dank!
@mbehrens
vielen Dank für den Hinweis zu .local
Grüße
Carsten
