3
DC Zweigstelle als Backupumgebung
Es soll ein Backupstandort eingerichtet werden.
Ziel ist es alle Benutzer (RDP) auf diesen Standort umzuleiten, wenn in der Hauptstelle ein Problem auftritt (Brand, Internet, etc.)
Hallo,
wir binden unsere Benutzer per RDP an mehreren Terminal Server Clients an ein von uns entwickeltes Managementsystem an.
Unser Datacenter ist über das Internet per RDP erreichbar (Kunden nutzen es auch).
Jetzt planen wir für den Fall, dass am Hauptstandort nicht lösbare Probleme, wie z.B. Internetausfall, Brand etc. auftreten an einem zweiten Standort ein Backupsystem aufzubauen.
Der Backupstandort hat eine eigene Internetanbindung.
Beide Standorte sind über eine 5 Mbit Leitung (Up/Down) verbunden.
---
Das Backupsystem soll die Anmeldung via RDP erlauben, ohne das die Benutzer einen Unterschied bemerken.
Die Computer der Backupumgebung sollen ständig laufen.
Die Idee ist eine neue Zweigstelle (untergeordnete Domäne) einzurichten und die Backupserver dort anzumelden.
Anmeldungen sollten dann ja nur innerhalb eines Standortes passieren.
Was ist bei der Einrichtung des Domänencontroller zu beachten?
Meine Idee bisher war die Domäne backup.mycomp.local zu nennen und alle Backup-Server zu dieser Domäne hinzuzufügen.
So melden sich die Benutzer des Haupstandortes definitiv nicht in der Zweigstelle an.
Der Domänencontroller sollte GC werden, damit im Falle einer Unterbrechung zum Hauptstandort weiterhin funktioniert.
Jetzt meine Fragen
1.) Funktioniert das so?
2.) Kann ein Benutzer der Gruppe "MainTerminalUser" vom Haupstandort sich an der Backupdomäne anmelden?
3.) Kann ich verhindern, dass die Anmeldung versucht zur Hauptdomäne vorzudringen?
(Profile, etc. sind unwichtig, es geht nur um die Anmeldung). Wir hatten einmal einen DC am Backupstandort und die Verbindung ist immer wieder abgebrochen und ging dann wieder. So das es geraume Zeit Anmeldeprobleme gab.
4.) Habe ich vergessen was zu erwähnen?
5.) Danke, dass schon so weit gelesen wurde.
Anmerkung: Es geht mir nur um die Anmeldemöglichkeit an der Domäne. Ein Backup der Daten wird selbstveständlich erzeugt. Es geht hier um einen jederzeit verfügbare Ersatzumgebung. Die Daten unserer Anwendung werden separat repliziert (Manuell, Logshipping, etc..)
Ich bin für jeden Tipp dankbar.
Wissensbasis: Mit Domänen an einem Standort konnte ich mittlerweile viel Erfahrung sammeln. Da habe ich eine solide Wissenbasis.
Gar keine Erfahrung habe ich bisher mit Vertrauensstellungen oder Subdomains. Deswegen bin ich hier auf gute Tipps, auch gerne weiterführende Dokumentation oder Büchertipps angewiesen.
wir binden unsere Benutzer per RDP an mehreren Terminal Server Clients an ein von uns entwickeltes Managementsystem an.
Unser Datacenter ist über das Internet per RDP erreichbar (Kunden nutzen es auch).
Jetzt planen wir für den Fall, dass am Hauptstandort nicht lösbare Probleme, wie z.B. Internetausfall, Brand etc. auftreten an einem zweiten Standort ein Backupsystem aufzubauen.
Der Backupstandort hat eine eigene Internetanbindung.
Beide Standorte sind über eine 5 Mbit Leitung (Up/Down) verbunden.
---
Das Backupsystem soll die Anmeldung via RDP erlauben, ohne das die Benutzer einen Unterschied bemerken.
Die Computer der Backupumgebung sollen ständig laufen.
Die Idee ist eine neue Zweigstelle (untergeordnete Domäne) einzurichten und die Backupserver dort anzumelden.
Anmeldungen sollten dann ja nur innerhalb eines Standortes passieren.
Was ist bei der Einrichtung des Domänencontroller zu beachten?
Meine Idee bisher war die Domäne backup.mycomp.local zu nennen und alle Backup-Server zu dieser Domäne hinzuzufügen.
So melden sich die Benutzer des Haupstandortes definitiv nicht in der Zweigstelle an.
Der Domänencontroller sollte GC werden, damit im Falle einer Unterbrechung zum Hauptstandort weiterhin funktioniert.
Jetzt meine Fragen
1.) Funktioniert das so?
2.) Kann ein Benutzer der Gruppe "MainTerminalUser" vom Haupstandort sich an der Backupdomäne anmelden?
3.) Kann ich verhindern, dass die Anmeldung versucht zur Hauptdomäne vorzudringen?
(Profile, etc. sind unwichtig, es geht nur um die Anmeldung). Wir hatten einmal einen DC am Backupstandort und die Verbindung ist immer wieder abgebrochen und ging dann wieder. So das es geraume Zeit Anmeldeprobleme gab.
4.) Habe ich vergessen was zu erwähnen?
5.) Danke, dass schon so weit gelesen wurde.
Anmerkung: Es geht mir nur um die Anmeldemöglichkeit an der Domäne. Ein Backup der Daten wird selbstveständlich erzeugt. Es geht hier um einen jederzeit verfügbare Ersatzumgebung. Die Daten unserer Anwendung werden separat repliziert (Manuell, Logshipping, etc..)
Ich bin für jeden Tipp dankbar.
Wissensbasis: Mit Domänen an einem Standort konnte ich mittlerweile viel Erfahrung sammeln. Da habe ich eine solide Wissenbasis.
Gar keine Erfahrung habe ich bisher mit Vertrauensstellungen oder Subdomains. Deswegen bin ich hier auf gute Tipps, auch gerne weiterführende Dokumentation oder Büchertipps angewiesen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 142728
Url: https://administrator.de/contentid/142728
Printed on: April 20, 2024 at 01:04 o'clock
3 Comments
Latest comment
Servus,
dazu müsst ihr aber nicht eine Subdomäne erstellen. Ihr könntet vor Ort lediglich einen DC installieren,
ohne eine Subdomäne erstellen zu müssen. Wenn du dann in der MMC "AD-Standorte und -Dienste" einen AD-Standort samt dem Subnetz erstellst,
den neuen DC dorthin verschiebst, melden sich automatisch die Clients an dem DC der vor Ort steht an.
Details siehe:
[LDAP:Yusufs.Directory.Blog/ - Domänencontroller am Standort]
http://blog.dikmenoglu.de/Dom%c3%a4nencontroller+Am+Standort.aspx
Mit den bisherigen Informationen würde ich lediglich einen zusätzlichen DC zur bestehenden Domäne hinzufügen.
[LDAP:Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen]
http://blog.dikmenoglu.de/Einen+Zus%c3%a4tzlichen+DC+In+Die+Dom%c3%a4ne ...
Wenn du das in "Standorte und Dienste" richtig konfigurierst, passiert so etwas nicht.
Die Clients versuchen sich immer zuerst an einem DC der an ihrem AD-Standort steht anzumelden.
Erst wenn sie vor Ort keinen DC finden, benutzen Sie einen DC aus einem anderen AD-Standort.
Und was wäre wenn sich die Clients vom Huptstandort an dem DC in der Zweigstellt authentisieren? Das wäre erstmal auch kein Problem.
Der GC und das DNS sollte "per se" wegen der Ausfallsicherheit auf jedem DC aktiviert bzw. installiert werden.
Wenn man es "richtig" macht funktionert es. Ich würde aber "meinen" Weg gehen.
Wie gesagt, erstellle KEINE zusätzliche Domäne sondern lediglich einen zusätzlichen DC.
Dafür reicht ein zusätzlicher DC allemal und das erleichtert die Administration ungemein, gegenüber einer weiteren Domäne!
Ich hoffe meine genügen dir. ;-Þ
Der Nachteil bei mehreren Domänen innerhalb einer Gesamtstruktur ist:
- Bei mehreren Domänen ist der adminstrative Aufwand (Updates, Virenscanner usw.) höher, da auch jede Domäne wegen der Ausfallsicherheit mindestens zwei DCs haben sollte.
- Dadurch entstehen höhere Hardware- sowie Lizenzkosten.
- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.
- Jede Domäne muss gesichert werden (Backup).
Bei mehreren Domänen wären die Vorteile, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren
sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Wobei das letztendlich nur mit getrennten Gesamtstrukturen und nicht
mit mehreren Domänen innerhalb einer Gesamtstruktur zu regeln ist.
Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien (bis einschließlich Windows Server 2003) anwenden. Ab Windows Server 2008
gibt es die "Password Settings Objects, kurz PSOs".
Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration.
Weniger DCs sind notwendig und somit auch weniger Hardware- sowie Lizenzkosten.
Ich persönlich tendiere gerne - wann immer möglich - zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten des Kunden darauf an.
Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen.
Viele Grüße
/ > Yusuf Dikmenoglu
Zitat von @kbudde:
Die Idee ist eine neue Zweigstelle (untergeordnete Domäne) einzurichten und die Backupserver dort anzumelden.
Anmeldungen sollten dann ja nur innerhalb eines Standortes passieren.
Die Idee ist eine neue Zweigstelle (untergeordnete Domäne) einzurichten und die Backupserver dort anzumelden.
Anmeldungen sollten dann ja nur innerhalb eines Standortes passieren.
dazu müsst ihr aber nicht eine Subdomäne erstellen. Ihr könntet vor Ort lediglich einen DC installieren,
ohne eine Subdomäne erstellen zu müssen. Wenn du dann in der MMC "AD-Standorte und -Dienste" einen AD-Standort samt dem Subnetz erstellst,
den neuen DC dorthin verschiebst, melden sich automatisch die Clients an dem DC der vor Ort steht an.
Details siehe:
[LDAP:Yusufs.Directory.Blog/ - Domänencontroller am Standort]
http://blog.dikmenoglu.de/Dom%c3%a4nencontroller+Am+Standort.aspx
Was ist bei der Einrichtung des Domänencontroller zu beachten?
Mit den bisherigen Informationen würde ich lediglich einen zusätzlichen DC zur bestehenden Domäne hinzufügen.
[LDAP:Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen]
http://blog.dikmenoglu.de/Einen+Zus%c3%a4tzlichen+DC+In+Die+Dom%c3%a4ne ...
So melden sich die Benutzer des Haupstandortes definitiv nicht in der Zweigstelle an.
Wenn du das in "Standorte und Dienste" richtig konfigurierst, passiert so etwas nicht.
Die Clients versuchen sich immer zuerst an einem DC der an ihrem AD-Standort steht anzumelden.
Erst wenn sie vor Ort keinen DC finden, benutzen Sie einen DC aus einem anderen AD-Standort.
Und was wäre wenn sich die Clients vom Huptstandort an dem DC in der Zweigstellt authentisieren? Das wäre erstmal auch kein Problem.
Der Domänencontroller sollte GC werden, damit im Falle einer Unterbrechung zum Hauptstandort weiterhin funktioniert.
Der GC und das DNS sollte "per se" wegen der Ausfallsicherheit auf jedem DC aktiviert bzw. installiert werden.
1.) Funktioniert das so?
Wenn man es "richtig" macht funktionert es. Ich würde aber "meinen" Weg gehen.
2.) Kann ein Benutzer der Gruppe "MainTerminalUser" vom Haupstandort sich an der Backupdomäne anmelden?
3.) Kann ich verhindern, dass die Anmeldung versucht zur Hauptdomäne vorzudringen?
(Profile, etc. sind unwichtig, es geht nur um die Anmeldung). Wir hatten einmal einen DC am Backupstandort und die Verbindung ist
immer wieder abgebrochen und ging dann wieder. So das es geraume Zeit Anmeldeprobleme gab.
3.) Kann ich verhindern, dass die Anmeldung versucht zur Hauptdomäne vorzudringen?
(Profile, etc. sind unwichtig, es geht nur um die Anmeldung). Wir hatten einmal einen DC am Backupstandort und die Verbindung ist
immer wieder abgebrochen und ging dann wieder. So das es geraume Zeit Anmeldeprobleme gab.
Wie gesagt, erstellle KEINE zusätzliche Domäne sondern lediglich einen zusätzlichen DC.
Anmerkung: Es geht mir nur um die Anmeldemöglichkeit an der Domäne. Ein Backup der Daten wird selbstveständlich
erzeugt. Es geht hier um einen jederzeit verfügbare Ersatzumgebung. Die Daten unserer Anwendung werden separat repliziert
(Manuell, Logshipping, etc..)
erzeugt. Es geht hier um einen jederzeit verfügbare Ersatzumgebung. Die Daten unserer Anwendung werden separat repliziert
(Manuell, Logshipping, etc..)
Dafür reicht ein zusätzlicher DC allemal und das erleichtert die Administration ungemein, gegenüber einer weiteren Domäne!
Ich bin für jeden Tipp dankbar.
Ich hoffe meine genügen dir. ;-Þ
Gar keine Erfahrung habe ich bisher mit Vertrauensstellungen oder Subdomains. Deswegen bin ich hier auf gute Tipps, auch gerne
weiterführende Dokumentation oder Büchertipps angewiesen.
weiterführende Dokumentation oder Büchertipps angewiesen.
Der Nachteil bei mehreren Domänen innerhalb einer Gesamtstruktur ist:
- Bei mehreren Domänen ist der adminstrative Aufwand (Updates, Virenscanner usw.) höher, da auch jede Domäne wegen der Ausfallsicherheit mindestens zwei DCs haben sollte.
- Dadurch entstehen höhere Hardware- sowie Lizenzkosten.
- Jeder DC sollte/muss vor Ort physikalisch geschützt sein.
- Jede Domäne muss gesichert werden (Backup).
Bei mehreren Domänen wären die Vorteile, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren
sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Wobei das letztendlich nur mit getrennten Gesamtstrukturen und nicht
mit mehreren Domänen innerhalb einer Gesamtstruktur zu regeln ist.
Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien (bis einschließlich Windows Server 2003) anwenden. Ab Windows Server 2008
gibt es die "Password Settings Objects, kurz PSOs".
Der Vorteil einer Domäne wäre z.B. das man nur eine DNS-Zone/Domäne verwalten muss. Mit einer Domäne hat man eine bessere Übersicht und leichtere Administration.
Weniger DCs sind notwendig und somit auch weniger Hardware- sowie Lizenzkosten.
Ich persönlich tendiere gerne - wann immer möglich - zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten des Kunden darauf an.
Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen.
Viele Grüße
/ > Yusuf Dikmenoglu
Zitat von @Yusuf-Dikmenoglu:
Wenn man es "richtig" macht funktionert es. Ich würde aber "meinen" Weg gehen.
/ > Yusuf Dikmenoglu
Wenn man es "richtig" macht funktionert es. Ich würde aber "meinen" Weg gehen.
/ > Yusuf Dikmenoglu
Und das beste an der ganzen Nummer "sein" Weg ist auch derjenige, vor dem man sich nicht "schämen" müßte, wenn ein externer sich das KOnstrukt ansieht, denn der würde es sofort erkennen und somit wissen, das es wie aus dem "Handbuch" gemacht wurde.
Auch wenns komisch klingt, aber als Admin sollte man immer dran denken, das man austauschbar ist / mal längere Zeit krank sein kann oder ähnliches - und es einem Nachfolger nicht unnötig schwer machen
Gruß
Ich bin schlichtweg begeistert.
Ich hatte die Standorte bisher schlichtweg ignoriert. Das ist aber genau die Lösung, die gesucht war.
Vielen Dank das Erspart viel Aufwand mit der zweiten Domäne.
Tausenddank!
Ich hatte die Standorte bisher schlichtweg ignoriert. Das ist aber genau die Lösung, die gesucht war.
Vielen Dank das Erspart viel Aufwand mit der zweiten Domäne.
Tausenddank!
