root - childdomain - Exchange -> geht das so überhaupt?

[Stonehedge 12]

Hallo Zusammen,

 

Ich stehe gerade vor ein paar Fragen, wo ich nicht weiterkomme.

 

Eine Zentrale und mehrere Außenstellen sollen untereinander verbunden werden und von der Zentrale aus verwaltet werden.

 

Ich habs mir bisher so gedacht:

 

Hauptstelle: domain.local

Außenstellen(ca 15): subdomain.domain.local

 

Da in den Außenstellen nur ca 20 Leute sitzen, soll Exchange zentral von der Hauptstelle für alle Außenstellen verwaltet werden. Bekomme ich ein Problem für einen Subdomainuser ein Postfach zu erstellen?

 

Alles andere(File, Print, Anwendungen) wird an den Außenstellen seperat installiert.

 

Eine andere Frage, die ich mir stelle ist: Welchen Vorteil habe ich, wenn ich mit Subdomains arbeite? Kann ich das ganze nicht besser mit OUs strukturieren?

 

Ich bin für jede Antwort dankbar.

 

Viele Grüße,

Stonehedge

[dmetzger 10]

Eine andere Frage, die ich mir stelle ist: Welchen Vorteil habe ich, wenn ich mit Subdomains arbeite? Kann ich das ganze nicht besser mit OUs strukturieren?

 

Ich frage mich ebenfalls, für was Du Subdomänen benötigst.

 

Ich denke, mit einer Domäne und verschiedenen Standorten (Sites) für die Aussenstellen bist Du besser bedient, denn es soll ja alles zentral verwaltet werden. Mit Subdomänen müsstest Du z.B. Gruppenrichtlinien für die Stamm- und für die Subdomäne konfigurieren etc.

 

Im Grundsatz funktioniert eine Exchange-Organisation innerhalb einer Gesamstrtuktur (1 Exchange-Organisation pro Gesamtstruktur möglich), hier hättest Du keine Probleme. Doch eben - siehe oben.

 

Ach ja, noch ein Tipp: An Stelle der domain.local arbeitest Du lieber mit firma.domain.de als Stammdomäne (auch wenn es die einzige Domäne in der Gesamtstruktur bleibt). Du wirst dankbar dafür sein, wenn Du z.B. irgendwann in Zukunft DirectAccess einführen sollst.

[Stonehedge 12]

Hallo,

 

vielen Dank für die Antwort.

 

Welchen Vorteil bringen denn Subdomains? Eigtl doch nur, dass es eine einigermaßen eigenständige Domain ist oder? Das würde bei uns vielleicht noch Sinn machen, da die Daten in den Außenstellen sehr sensibel sind und die Nutzer in den Außenstellen sind alles Kunden. Aber ich sehr den Vorteil irgendwie nicht, außer man möchte Verwaltungsberechtigungen für die Subdomains delegieren.

 

Grüße

[Daim 12]

Servus,

 

Ich habs mir bisher so gedacht:

 

Hauptstelle: domain.local

Außenstellen(ca 15): subdomain.domain.local

 

vermeide für 15-20 Mitarbeiter eine Subdomäne zu erstellen und arbeite stattdessen mit OUs und AD-Standorten, wenn keine *trifftigen* Gründe für eine Subdomäne existieren. Schließlich sollte sich in jeder Domäne mindestens zwei DCs befinden, wozu min. zwei Serverlizenzen benötigt werden würden, jeder DC sollte/muss vor Ort physikalisch geschützt sein, jede Domäne muss gesichert werden (Backup). etc.

 

Die Aussenstelllen können sich problemlos an den DCs der Zentrale authentisieren. Sofern ein "vernünftiges" VPN existiert.

 

Eine andere Frage, die ich mir stelle ist: Welchen Vorteil habe ich, wenn ich mit Subdomains arbeite? Kann ich das ganze nicht besser mit OUs strukturieren?

 

Mit deinen bisher genannten Informationen bist du mit OUs und AD-Standorten bestens bedient.

[gb69 10]

Die Aussenstelllen können sich problemlos an den DCs der Zentrale authentisieren. Sofern ein "vernünftiges" VPN existiert.

Hallo Yusuf,

 

prinzipiell stimme ich dir zu, aber ich würde bei 20 Clients pro Standort einen DC in jede Außenstelle stellen.

 

Egal wie "vernünftig" das VPN ist, kann es doch zu Verbindungsproblemen kommen und dann gäbe es für 20 Clients keinen Anmeldeserver. ;)

 

Zumeist ist es ja auch kein Problem, wenn diese DCs gleich noch File-, Print-, DHCP-Server für die Standorte sind.

 

Für die Branchenlösungs-Datenbank (SQL oder Oracle)gibt es dann einen 2. Server.

 

Einverstanden?

[Daim 12]

Huhuu,

 

prinzipiell stimme ich dir zu, aber ich würde bei 20 Clients pro Standort einen DC in jede Außenstelle stellen.

 

das kannst DU gerne so tun, aber zum einen ist das keineswegs notwendig und zum anderen würde --> ich <-- es *nur* dann tun, wenn es eine berechtigte Situation erfordert. Denn stell dir vor es existieren 100 Benutzer verteilt in fünf Standorte (an jedem Standort sitzen 20 Mann). Das würde ja bedeuten, du installierst *fünf* DCs. Und das halte ich aber gewaltig mit "Kanonen auf Spatzen" geschossen. Weiterhin darf die physikalische Sicherheit der DCs keineswegs vernachlässigt werden(!) und überlicherweise ist das in Aussenstandorten leider meistens genau der Fall (DC steht unter dem Tisch der Sekretärin).

 

Apropos bin ich zur Zeit bei einem Kunden, der 700 Benutzer verteilt an 23 Standorte hat und sich alle Benutzer an den DCs in der Zentrale anmelden! Zur Verfügung steht ein vom rosaroten Pather gehostetes MPLS-VPN.

 

Des Weiteren kommt es wie immer auf die Umgebung an! Handelt es sich mindestens um eine Windows Server 2008 Umgebung, kommen RODCs in Frage. Dann zumindest müssen keine beschreibbaren DCs mehr in den Aussenstandorten existieren. Ansonsten neige ich ich gerade bei 20 Mann (und mehr) Standorten stets dazu, die Benutzer an den DCs der Zentrale authentisieren zu lassen.

 

Egal wie "vernünftig" das VPN ist, kann es doch zu Verbindungsproblemen kommen und dann gäbe es für 20 Clients keinen Anmeldeserver. ;)

 

Natürlich gibt es keine Garantie dafür, das zum Zeitpunkt der Authentisierung (und nur dann!) die Leitung zur Verfügung steht. Aber beispielsweise bist du bei einem MPLS-Netz mit entsprechenden SLAs schon gut ausgestattet. ;) Aber wenn möglich kann man ja dann RODCs einsetzen.

 

Zumeist ist es ja auch kein Problem, wenn diese DCs gleich noch File-, Print-, DHCP-Server für die Standorte sind.

 

In der Praxis ist das meist kein Problem. Die "rosarote" Welt sieht jedoch anders aus, ja, auch die Realität sieht anders aus. ;) Denn jeder Dienst und jede Applikation "gefährdet" den DC. Siehe dazu:

 

LDAP://Yusufs.Directory.Blog/ - Warum es ein dedizierter DC sein sollte!

 

Für die Branchenlösungs-Datenbank (SQL oder Oracle)gibt es dann einen 2. Server.

 

Aber dann auch *nur* in der Zentrale. ;) Denn warum die Daten bzw. Applikationen zu den Benutzern bringen und nicht die Benutzer zu den Daten/Applikationen, RDS/RemoteApp sei Dank!

 

Einverstanden?

 

Das bin und kann ich, versteht sich von selbst, nicht sein. ;)

[Daim 12]

Welchen Vorteil bringen denn Subdomains? Eigtl doch nur, dass es eine einigermaßen eigenständige Domain ist oder?

 

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

wirklich 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".

 

Das würde bei uns vielleicht noch Sinn machen, da die Daten in den Außenstellen sehr sensibel sind

 

Das lässt sich durch ein entsprechendes Berechtigungskonzept regeln.

 

und die Nutzer in den Außenstellen sind alles Kunden.

 

Verschiedene Kunden befinden sich in derselben Domäne? :rolleyes:

 

Aber ich sehr den Vorteil irgendwie nicht, außer man möchte Verwaltungsberechtigungen für die Subdomains delegieren.

 

Verwaltungsberechtigungen delegiert man besser über Organisationseinheiten. Zum einen ist das einfacher und flexibler zu handhaben und zum anderen wird weniger Hardware für die DCs benötigt. Des Weiteren spart man wie bereits erwähnt, Serverlizenzen.

[Stonehedge 12]

Danke euch für die Antworten!!!!

 

Wir haben nun das geplante Konzept überarbeitet und werden mit einer Domäne arbeiten.

Ich bin heilfroh hier nochmal gefragt zu haben!

 

danke danke danke ;)

[Daim 12]

Wir haben nun das geplante Konzept überarbeitet und werden mit einer Domäne arbeiten.

Ich bin heilfroh hier nochmal gefragt zu haben!

 

danke danke danke ;)

 

Und mich freut es jedes Mal wenn ich sehe, dass wir mit unserer Community Leistung "hier und da" etwas bewirken können.

 

Danke für die für uns helfende, immens wichtige Rückmeldung.

 

Dann kann ja das Wochenende kommen. ;)