6
Neue AD mit neuen Namen anlegen
Hallo zusammen,
ich stehe vor folgendem Projekt und würde gerne wissen wie ihr das Angehen würdet.
Wenn ich den kompletten Holzweg einschlagen sollte, könnt ihr mich gerne korrigieren
Also folgende Ist-Situation:
- Es besteht ein Server + AD + O365 + Diverse Dienste (ERP usw.)
- Die aktuelle Domäne hat noch den alten Firmennamen (alterfirmenname.local)
- Das AD ist über AADC (Azure AD Connect) an die O365 bzw. Azure AD angebunden
- Es besteht ein Fileserver auf welchem Ordner relativ Simpel via NTFS für die Benutzer freigegeben ist (bspw. Ordner IT -> Freigabe für Gruppe IT im AD)
- Alte Server werden komplett ersetzt
Dies soll entstehen:
- Bei den zusätzlichen Diensten mache ich mir keine Sorgen, diese können mit relativ wenig Aufwand an ein neues AD angebunden werden für SSO usw.
- Eine neue Domäne mit dem neuen Firmenname (int.neuefirma.de)
- Das neue AD soll wieder mit dem vorhanden O365 Tenant verknüpft werden
- Der Fileserver wird auch neu installiert, hier können ggf. die NTFS Berechtigungen neu gesetzt werden
- Neue Server werden auf neuer Hardware virtualisiert
Das Active Directory beinhalten aktuell 20 User und 10 Service Accounts. Tatsächlich ist es so das es hier mehr Gruppen als User gibt, das kommt daher das durch das Berechtigungskonzept immer eigene Gruppen für die verschiedenen Ordner angelegt wurden, auch für den VPN gibt es verschiedene Gruppen. Es sind in 25 Gruppen vorhanden. Das sollte aber nicht weiter stören.
Das AD ist so überschaubar das eine komplette neu Anlage mit einem relativ geringen Zeitaufwand möglich wäre. Das umbenennen des AD´s ist keine Option.
Aber es gibt ja auch noch das AD Migration Tool von Microsoft... Dies wäre ggf. hier eine Option, aber ich habe noch keine Erfahrung damit.
Also Grundsätzlich wäre mein Vorgehen wie folgt:
- Neuen Hyper-V Host installieren
- ersten Active Directory Controller installieren mit neuen Domänen Namen (int.neuefirma.de)
- Option 1:
Alle Benutzer, Gruppen usw. im neuen AD abtippen (erhalten neues Kennwort)
- Option 2:
Mit dem AD Migration Tool die Benutzer, Gruppen usw. auf das neue AD (int.neuefirma.de) migrieren (Somit behalten die Benutzer ihr vorhandenes Passwort)
- Benötigte GPO´s auf neuem DC konfigurieren
- SMTP Adressen bei den Benutzern hinterlegen (1:1 altes AD)
- Azure AD Connect auf alten DC deaktivieren
- Azure AD Connect installieren, die Synchronisation wieder auf das vorhandene Tenant konfigurieren
- Alle Clients manuell im neuen AD registrieren (Wochenend Aktion)
Wozu ich noch wenig Informationen gefunden habe ist wie sich das Azure AD verhält wenn sich das lokale AD ändert. Soweit ich aber die Architektur verstanden habe sollte wenn sich die Primary SMTP Adresse nicht ändert auch alles weiterhin für die neuen lokalen AD User in Office 365 funktionieren und alle Daten (Exchange, Sharepoint, Teams) weiterhin mit dem Account verknüpft sein. Denn ist ja "nur" eine Synchronisation und bei dieser kann man beim installieren den Primary Key angeben, dieser ist die SMTP Adresse.
Sehr ihr in meinem Vorgehen einen größeren oder kleineren Denkfehler? Oder würdet ihr das so absegnen?
Vielen Dank schonmal für jeglichen Input.
Liebe Grüße
Somebody
ich stehe vor folgendem Projekt und würde gerne wissen wie ihr das Angehen würdet.
Wenn ich den kompletten Holzweg einschlagen sollte, könnt ihr mich gerne korrigieren
Also folgende Ist-Situation:
- Es besteht ein Server + AD + O365 + Diverse Dienste (ERP usw.)
- Die aktuelle Domäne hat noch den alten Firmennamen (alterfirmenname.local)
- Das AD ist über AADC (Azure AD Connect) an die O365 bzw. Azure AD angebunden
- Es besteht ein Fileserver auf welchem Ordner relativ Simpel via NTFS für die Benutzer freigegeben ist (bspw. Ordner IT -> Freigabe für Gruppe IT im AD)
- Alte Server werden komplett ersetzt
Dies soll entstehen:
- Bei den zusätzlichen Diensten mache ich mir keine Sorgen, diese können mit relativ wenig Aufwand an ein neues AD angebunden werden für SSO usw.
- Eine neue Domäne mit dem neuen Firmenname (int.neuefirma.de)
- Das neue AD soll wieder mit dem vorhanden O365 Tenant verknüpft werden
- Der Fileserver wird auch neu installiert, hier können ggf. die NTFS Berechtigungen neu gesetzt werden
- Neue Server werden auf neuer Hardware virtualisiert
Das Active Directory beinhalten aktuell 20 User und 10 Service Accounts. Tatsächlich ist es so das es hier mehr Gruppen als User gibt, das kommt daher das durch das Berechtigungskonzept immer eigene Gruppen für die verschiedenen Ordner angelegt wurden, auch für den VPN gibt es verschiedene Gruppen. Es sind in 25 Gruppen vorhanden. Das sollte aber nicht weiter stören.
Das AD ist so überschaubar das eine komplette neu Anlage mit einem relativ geringen Zeitaufwand möglich wäre. Das umbenennen des AD´s ist keine Option.
Aber es gibt ja auch noch das AD Migration Tool von Microsoft... Dies wäre ggf. hier eine Option, aber ich habe noch keine Erfahrung damit.
Also Grundsätzlich wäre mein Vorgehen wie folgt:
- Neuen Hyper-V Host installieren
- ersten Active Directory Controller installieren mit neuen Domänen Namen (int.neuefirma.de)
- Option 1:
Alle Benutzer, Gruppen usw. im neuen AD abtippen (erhalten neues Kennwort)
- Option 2:
Mit dem AD Migration Tool die Benutzer, Gruppen usw. auf das neue AD (int.neuefirma.de) migrieren (Somit behalten die Benutzer ihr vorhandenes Passwort)
- Benötigte GPO´s auf neuem DC konfigurieren
- SMTP Adressen bei den Benutzern hinterlegen (1:1 altes AD)
- Azure AD Connect auf alten DC deaktivieren
- Azure AD Connect installieren, die Synchronisation wieder auf das vorhandene Tenant konfigurieren
- Alle Clients manuell im neuen AD registrieren (Wochenend Aktion)
Wozu ich noch wenig Informationen gefunden habe ist wie sich das Azure AD verhält wenn sich das lokale AD ändert. Soweit ich aber die Architektur verstanden habe sollte wenn sich die Primary SMTP Adresse nicht ändert auch alles weiterhin für die neuen lokalen AD User in Office 365 funktionieren und alle Daten (Exchange, Sharepoint, Teams) weiterhin mit dem Account verknüpft sein. Denn ist ja "nur" eine Synchronisation und bei dieser kann man beim installieren den Primary Key angeben, dieser ist die SMTP Adresse.
Sehr ihr in meinem Vorgehen einen größeren oder kleineren Denkfehler? Oder würdet ihr das so absegnen?
Vielen Dank schonmal für jeglichen Input.
Liebe Grüße
Somebody
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: 667078
Url: https://administrator.de/contentid/667078
Ausgedruckt am: 24.11.2024 um 22:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
das Projekt steht bei mir auch bald an, folgende Anleitung fand ich hilfreich um den Azure AD Sync nach der Migration aufrecht zu erhalten
www.smikar.com/move-users-to-another-domain-and-retain-ad-connect-sync/
Ich würde einen Trust zwischen der alten und neuen Domain machen und dann die User mit dem Migration Tool verschieben.
Hat den Vorteil das du beim Azure AD Sync weniger Probleme hast und es noch der "alte User" ist.
das Projekt steht bei mir auch bald an, folgende Anleitung fand ich hilfreich um den Azure AD Sync nach der Migration aufrecht zu erhalten
www.smikar.com/move-users-to-another-domain-and-retain-ad-connect-sync/
Ich würde einen Trust zwischen der alten und neuen Domain machen und dann die User mit dem Migration Tool verschieben.
Hat den Vorteil das du beim Azure AD Sync weniger Probleme hast und es noch der "alte User" ist.
Hey notmyjob,
danke dir für die schnelle und hilfreiche Antwort.
Ich würde meine Skills zum googeln als relativ gut einschätzen, aber den Artikel habe ich tatsächlich nicht gefunden. Sehr hilfreich.
Danke dir schonmal.
danke dir für die schnelle und hilfreiche Antwort.
Ich würde meine Skills zum googeln als relativ gut einschätzen, aber den Artikel habe ich tatsächlich nicht gefunden. Sehr hilfreich.
Danke dir schonmal.
Moin,
und der einzige Grund für eine neue Domäne ist der alte Firmenname ?
Dann würde ich mir überlegen, ob ich den Aufwand betreibe.
Und wenn es tatsächlich der Grund sein sollte, würde ich NICHT wieder den Firmennamen in der Domäne unterbringen.
Gruß
Jasper
und der einzige Grund für eine neue Domäne ist der alte Firmenname ?
Dann würde ich mir überlegen, ob ich den Aufwand betreibe.
Und wenn es tatsächlich der Grund sein sollte, würde ich NICHT wieder den Firmennamen in der Domäne unterbringen.
Gruß
Jasper
Hallo Jasper,
es ist nicht der einzige Grund. Die Domäne ist auch relativ alt von Windows Server 2003 hoch migriert.
Es wurde alles mögliche in der Default Domain Policy angepasst, es gibt manchmal ein seltsames verhalten in der Berechtigungsstruktur...
Deshalb der Schritt das AD jetzt mit dem Server Umzug neu zu installieren.
Du hast recht das es eigentlich bescheuert ist den Domänennamen wieder an die Firma zu koppeln. Aber dieser Name ist sowas von in Stein gemeißelt auch im Zusammenhang mit der öffentlichen Domäne das ein erneuter Wechsel auszuschließen ist.
Gruß
Somebody
es ist nicht der einzige Grund. Die Domäne ist auch relativ alt von Windows Server 2003 hoch migriert.
Es wurde alles mögliche in der Default Domain Policy angepasst, es gibt manchmal ein seltsames verhalten in der Berechtigungsstruktur...
Deshalb der Schritt das AD jetzt mit dem Server Umzug neu zu installieren.
Du hast recht das es eigentlich bescheuert ist den Domänennamen wieder an die Firma zu koppeln. Aber dieser Name ist sowas von in Stein gemeißelt auch im Zusammenhang mit der öffentlichen Domäne das ein erneuter Wechsel auszuschließen ist.
Gruß
Somebody
Liest sich passabel und funktionell, einen Stolperstein wirst du hier bekommen:
Zumindest wenn der Hyper-V Host als Core Server laufen soll.
Die sind ohne Domainanbindung recht zickig.
Zitat von @SomebodyToLove:
Also Grundsätzlich wäre mein Vorgehen wie folgt:
- Neuen Hyper-V Host installieren
- ersten Active Directory Controller installieren mit neuen Domänen Namen (int.neuefirma.de)
Also Grundsätzlich wäre mein Vorgehen wie folgt:
- Neuen Hyper-V Host installieren
- ersten Active Directory Controller installieren mit neuen Domänen Namen (int.neuefirma.de)
Zumindest wenn der Hyper-V Host als Core Server laufen soll.
Die sind ohne Domainanbindung recht zickig.
Guter Einwand, aber ich werde die Hyper-V Server tatsächlich mit GUI installieren (Asche auf mein Haupt) aber hier werden noch zwei andere Dienste installiert.. auch wenn es nicht ganz korrekt ist.
Allerdings benötige ich die Backupsoftware und vor allem die Alarmanlage direkt am Host.
Allerdings benötige ich die Backupsoftware und vor allem die Alarmanlage direkt am Host.
