Win2K3 DC ersetzen & ADS Benutzer zusammensammeln

[Volker Racho 10]

Hallo!

 

Wir haben ca. 10 kleine Server (alle Win2K3 mit ADS) in zehn einzelnen Einrichtungen mit je so ca. 20 Nutzern in unserem Unternehmen. Jetzt werden alle diese Einrichtungen über eine Standortvernetzung (VPN/IPsec) miteinander bzw. mit unserer Zentrale verbunden.

Die eingesetzen Router haben natürlich NATing und IP-Masquarading, so dass sie ihre IP-Bereiche behalten könnten. Die einzelnen Standorte haben feste IPs. Dazu habe ich ein paar Fragen, die ich so hier nicht beantwortet gefunden habe. Ich habe einige Ahnung von Netzwerkbetreuung, Win2K3 und ADS usw., jedoch für diese präkare Aufgabe wollte ich mich vorab nochmals genauer informieren.

 

 

01. Ich möchte alle Nutzer aus allen "Häusern" auf unserem Verwaltungsserver (neu, Win2K3 R2) zusammensammeln, u.a. da dieser auch demnächst einen Exhange 2K7-Server mit den Nutzeraccountinfos bedienen soll, aber auch weil sich dann prinzipiell jeder an jedem Rechner des Unternehmens aber über deren Server anmelden können soll. In der Umsetzung bin ich relativ flexibel, da ich das Ganze stufenweise abarbeiten kann (eine Einrichtung nach der anderen). Wie bewerkstellige ich das am besten?

 

02. Ist es ratsamer die IPs auf den Clients - sie sollen feste IPs behalten - fortlaufend neu zu vergeben oder können diese so bleiben wie sie sind (weil die Router ja NAT/IP-Masqu.) unterstützen)? Wir wollen natürlich optimalen User-Support durch Fernwartung leisten können.

 

03. Wenn das wie auch immer geschehen ist, möchte ich auch einen komplettes Backup des DC der Verwaltung erstellen, d.h. das ganze 1:1 auf eine gleiche Hard- und Softwareinstalltion übertragen, also quasi ein BDC einrichten.

 

 

Mit besten Grüßen,

MD

[Daim 12]

Aloha,

 

Wir haben ca. 10 kleine Server (alle Win2K3 mit ADS) in zehn einzelnen Einrichtungen mit je so ca. 20 Nutzern in unserem Unternehmen. Jetzt werden alle diese Einrichtungen über eine Standortvernetzung (VPN/IPsec) miteinander bzw. mit unserer Zentrale verbunden.

 

daraus entnehme ich, dass jeder Standort bisher seine eigene Single-Forest Domäne ist.

 

 

01. Ich möchte alle Nutzer aus allen "Häusern" auf unserem Verwaltungsserver (neu, Win2K3 R2) zusammensammeln, u.a. da dieser auch demnächst einen Exhange 2K7-Server mit den Nutzeraccountinfos bedienen soll, aber auch weil sich dann prinzipiell jeder an jedem Rechner des Unternehmens aber über deren Server anmelden können soll. In der Umsetzung bin ich relativ flexibel, da ich das Ganze stufenweise abarbeiten kann (eine Einrichtung nach der anderen). Wie bewerkstellige ich das am besten?

 

Das hört sich so an, als wenn du nach dem Single-Domain-Forest nun für alle Standorte suchst. Das bedeutet, alle Standorte befinden sich in einer Domäne und die einzelnen Standorte werden im Active Directory durch die AD-Standorte abgebildet. Das macht auch Sinn, wenn ihr in der Zentrale für alle Standorte verantwortlich seit.

 

 

02. Ist es ratsamer die IPs auf den Clients - sie sollen feste IPs behalten - fortlaufend neu zu vergeben oder können diese so bleiben wie sie sind (weil die Router ja NAT/IP-Masqu.) unterstützen)? Wir wollen natürlich optimalen User-Support durch Fernwartung leisten können.

 

Wie du das IP-technisch erledigst, bleibt dir überlassen.

Fakt ist, dass Routing muss zwischen den Standorten funktionieren (OSI-Layer).

Die IP-Adressen sollten sich nicht mit anderen Standorten überschneiden.

 

 

03. Wenn das wie auch immer geschehen ist, möchte ich auch einen komplettes Backup des DC der Verwaltung erstellen, d.h. das ganze 1:1 auf eine gleiche Hard- und Softwareinstalltion übertragen, also quasi ein BDC einrichten.

 

Das hast du bei der Single-Domänen Struktur automatisch.

Wenn möglich, würde ich an jedem Standorte einen DC hinstellen. Dieser dient dann als Anmeldeserver für die Clients. Natürlich müssen die Standorte im Snap-In "Active Directory-Standorte und -Dienste" erstellt und samt ihrem Subnetz verknüpft werden. Die jeweiligen DC-Icons müssen dann an ihren entsprechenden Standort verschoben werden.

 

Somit würde an jedem Standort ohnehin je ein DC der gleichen Domäne stehen und somit wäre die Domäne gegen einen DC Crash mehrfach (durch die DCs an den Standorten) gesichert. Es sollte lediglich sichergestellt werden, dass an den jeweiligen DCs, regelmäßig das System State gesichert wird.

 

 

Prinzipiell kann man sagen:

 

Der Nachteil bei mehreren Domänen wären:

 

- Bei mehreren Domänen ist der adminstrative Aufwand (Updates,Virenscanner usw.) höher, da auch jede Domäne zwei DCs haben sollte.

- Dadurch entstehen hohe 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. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien anwenden.

 

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.

 

Ich persönlich tendiere gerne zu dem Ein-Domänen-Modell, aber das kommt immer auf die Gegebenheiten darauf an.

Evtl. solltet ihr euch dazu einen Dienstleister zur Seite holen.

 

 

Lies dir auch diesen Artikel durch:

Welches Domänenmodell ist das Beste für Active Directory? - faq-o-matic.net

[Volker Racho 10]

Hallo Daim!

 

Ich danke Dir für Deine sehr ausführliche und gute Antwort und Tipps! Das hilft mir weiter.

Ich denke, ich werde um eine Neustrukturierung der Domain(s), Server und IPs nicht umhin kommen.

 

Die ganze IT-Umgebung ist seit ihrer Einführung vor 5 Jahren so schnell (zusammen)gewachsen, das ich noch nicht absehen konnte, wie das wohl am besten zusammen passt.

 

Es wird wohl - gerade in Hinsicht auf Unternehmensgröße usw. - auf einen Ein-Domänenmodell hinaus laufen. Das verlangt vorab natürlich viel Planung für die Umsetzung bei den internen und externen Diensten. Das macht auch im Bezug auf den Exchange-Server und Gruppenrichtliniennutzung mehr Sinn. Eigentlich in jeder Hinsicht. Das ist zwar einmalig sehr viel Aufwand, aber man hat es dann schüssig.

 

Wie eine Domänenmigration der Benutzer funktioniert, kann ich mir mit entsprechenden Tools vorstellen, jedoch habe ich keine Ahnung - wiel noch nie gemacht und nötig - , wie ich dann den DC der Domaine umfimieren kann. Der heisst nämlich jetzt "Unternehmen" und soll dann in der neuen Struktur dann "unternehmen.de" heißen und damit auch die Anmeldedomäne für alle Rechner des Unternehmens vorgibt. Gibt es dafür auch ein Tool oder geht das ebenfalls mit dcpromo hin und her?

 

Die anderen - jetzt noch - Domaincontroller der einzelnen Domainen "subunternehmen 1" usw. sollen dann als DC es Stadortes dienen. (-> Aufallsicherheit und sonstige Dienste). Unter_Admins wird und soll es nicht geben, dafür ist a) unser Unternehmen zu klein (800 Leute) und b) unsere User zu wenig kenntnisreich und Wollens. Da bin ich auch froh drum.

Auch hier die Frage, welche Option ich beim dcpromo wählen muss, um diese "als weiteren Server zur Domaine hinzufügen" und doch nicht bei "sub.unternehmen.de" (wird das nicht automatisch so erstellt?) zu landen, sondern nur als Server mit (replizierter AD) in der Domäne "unternehmen.de"?

Auch das habe ich noch nicht gemacht.

 

 

Gruß & Dank

MD

[Daim 12]

Es wird wohl - gerade in Hinsicht auf Unternehmensgröße usw. - auf einen Ein-Domänenmodell hinaus laufen. Das verlangt vorab natürlich viel Planung für die Umsetzung bei den internen und externen Diensten. Das macht auch im Bezug auf den Exchange-Server und Gruppenrichtliniennutzung mehr Sinn. Eigentlich in jeder Hinsicht. Das ist zwar einmalig sehr viel Aufwand, aber man hat es dann schüssig.

 

Das auf jedenfall. Es gilt eben solch eine Aktion sorgfältig zu planen und alle Eventualitäten mit einzukalkulieren.

Mir erscheint auch auf den ersten Blick, du für euch das Ein-Domänen Forest passen würde (sofern ich das von hier beurteilen kann).

 

 

Wie eine Domänenmigration der Benutzer funktioniert, kann ich mir mit entsprechenden Tools vorstellen,

 

Benutzer- sowie Computerkonten (Clients+Memberserver) kannst du mit ADMT migrieren.

Du kannst aber keine DCs damit migrieren!

Dieses müssen aus der alten Domäne herunter und in der neuen Domäne erneut zum DC gestuft werden.

 

Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

 

 

jedoch habe ich keine Ahnung - wiel noch nie gemacht und nötig - , wie ich dann den DC der Domaine umfimieren kann.

 

Wie bereits erwähnt, die DCs aus den anderen Domänen/Unternehmen musst du wie o.g. übernehmen (zuerst de- und dann promoten).

Bezgl. der Dienste werden wie üblich DNS (was ohnehin benötigt wird), DHCP und evtl. WINS laufen. Diese kannst du dann in der neuen Struktur leicht abbilden.

Was noch so an Diensten auf jedem einzelnen DC in jeder Filiale läuft, muss natürlich vorher gründlich aufgenommenanalysiert werden.

 

 

Der heisst nämlich jetzt "Unternehmen" und soll dann in der neuen Struktur dann "unternehmen.de" heißen und damit auch

die Anmeldedomäne für alle Rechner des Unternehmens vorgibt. Gibt es dafür auch ein Tool oder geht das ebenfalls mit dcpromo hin und her?

 

Du musst die "anderen" Domänen auflösen. Dieses beinhaltet, dass die DCs aus diesen Domänen zuerst heruntergestuft werden müssen um

dann in der neuen Domäne als DCs der neuen Domäne heraufgestuft zu werden.

 

Das Tool das du für deine Benutzer- sowie Computerkonten benötigst, lautet ADMT.

Um aber mit ADMT zu migrieren, wird eine bestehende Namensauflösung sowie Vertrauensstellung benötigt.

 

Jetzt kann man aber "Trick 17" anwenden, wenn der "Administrator" in beiden Domänen das gleiche Kennwort hat, funktioniert ADTM sogar ohne eine Vertrauensstellung.

Nur so als Info...

 

 

Die anderen - jetzt noch - Domaincontroller der einzelnen Domainen "subunternehmen 1" usw. sollen dann als DC es Stadortes dienen. (-> Aufallsicherheit und sonstige Dienste).

 

Schon klar. Diese musst du leider, wie du bereits nun erfahren hast, in der neuen Domäne zu "zusätzlichen DCs einer bereits bestehenden Domäne" hinzufügen.

Dabei sollte auf allen DCs das DNS installiert werden.

 

 

Auch hier die Frage, welche Option ich beim dcpromo wählen muss, um diese "als weiteren Server zur Domaine hinzufügen" und doch nicht bei "sub.unternehmen.de" (wird das nicht automatisch so erstellt?) zu landen, sondern nur als Server mit (replizierter AD) in der Domäne "unternehmen.de"?

 

Die Option lautet "Zusätzlicher Domänencontroller für eine bestehende Domäne".

 

Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

[Volker Racho 10]

Hallo Yusuf!

 

Danke für die hilfreichen Links auf Deinem Blog. Ich werde sie bald abarbeiten.

Damit komme ich klar. Also erst mit dem ADMT die Benutzer und Gruppen in die andere Domäne migriren und dann depromoten und neu promoten.

 

Aber werden beim depromote nicht die Benutzer in die normale Windows-Nutzerverwaltung gechrieben und dann beim repromote für die neue Domänenzugehörigkeit wieder aus der Windows-Benutzerverwaltung in die AD übernommen? Oder verschiebt das Tool die Benutzer richtig in die neue Domäne und "löscht" sie vom Quellsystem?

 

Beim demnächstigen Hauptserver-DC - mit dem ich ja irgendwie anfangen muss - kann ich natürlich die Nutzer nirgendwohin schieben. Da müsste das dann ja schon so funktionieren, damit mir auch diese Nutzer nicht flöten gehen, oder?

 

Meinst Du den wirklichen Account "Administrator" (die gibt es bei uns nirgendwo) oder die faktischen Administratoren (die heissen bei uns alle 'it' und haben auf allen DC-Systemen das gleiche Passwort)?

 

 

Besten Dank!

MD

[Daim 12]

Hallo Yusuf!

 

Auhaa... erkannt ;) .

 

 

Also erst mit dem ADMT die Benutzer und Gruppen in die andere Domäne migriren und dann depromoten und neu promoten.

 

... und die Computerkonten nicht vergessen ;) .

Erst danach und wenn alle weiteren Dienste übernommen wurden, gilt es die DCs in der alten Domäne herunter- und in der neuen Domäne erneut, zum DC der neuen Domäne hochstufen.

 

 

Oder verschiebt das Tool die Benutzer richtig in die neue Domäne und "löscht" sie vom Quellsystem?

 

Das ADMT legt ein neues Benutzerkonto in der neuen Domäne an und fügt die SID des alten Benutzerkontos der alten Domäne an das neue Konto der neuen Domäne als SID-History hinzu. Damit kann das neue Benutzerkonto die alte SID als Ausweis vorweisen, wenn seine neue SID keinen Zugriff bekommt.

 

Somit bleibt dem Benutzer auch das lokale Profil auf dem Client erhalten.

Denn zum Migrieren der Benutzerprofile musst du im ersten Schritt das Benutzer-, anschließend das Computerkonto migrieren.

 

 

Beim demnächstigen Hauptserver-DC - mit dem ich ja irgendwie anfangen muss - kann ich natürlich die Nutzer nirgendwohin schieben. Da müsste das dann ja schon so funktionieren, damit mir auch diese Nutzer nicht flöten gehen, oder?

 

Das habe ich jetzt zwar nicht verstanden, aber migriere eben die Konten zu der Domäne, die erhalten bleiben soll. Oder erstelle eine neue und migriere in diese Domäne.

 

 

Meinst Du den wirklichen Account "Administrator" (die gibt es bei uns nirgendwo) oder die faktischen Administratoren (die heissen bei uns alle 'it' und haben auf allen DC-Systemen das gleiche Passwort)?

 

Ich meine einen Benutzer, der in beiden Domänen den gleichen Benutzernamen und das gleiche Kennwort hat. Aber wenn du es "nach Vorschrift" machst (Namensauflösung+Trust), wärst du auf dem "supporteten" Weg ;) .

[Volker Racho 10]

Beim demnächstigen Hauptserver-DC - mit dem ich ja irgendwie anfangen muss - kann ich natürlich die Nutzer nirgendwohin schieben. Da müsste das dann ja schon so funktionieren, damit mir auch diese Nutzer nicht flöten gehen, oder?

 

Nun ja, drücke ich mich vielleicht unbeholfen aus. Nun, zu allererst müsste ich ja mit dem Server in unserer Verwaltung anfangen, der demnächst den "ersten DC der neuen Domaine 'unternehmen.de" sei soll (früher: PDC), jetzt aber noch der (einfache) DC der Domäne 'Unternehmen' ist. Von diesem kann ich doch mit dem Tool nicht die Benutzer in irgendeine andere Domäne schieben, weil ja erstmal keine weitere da ist. Aber für die Umfimirung muss ich ihn ja runterstufen (-'Unternehmen) und wieder promoten (+ 'unternehmen.de'). Wie handle ich in der Zwischenzeit die Benutzer- und Computerkonten?

 

 

Danke für Deine Geduld!

Md

[Daim 12]

Von diesem kann ich doch mit dem Tool nicht die Benutzer in irgendeine andere Domäne schieben, weil ja erstmal keine weitere da ist. Aber für die Umfimirung muss ich ihn ja runterstufen (-'Unternehmen) und wieder promoten (+ 'unternehmen.de'). Wie handle ich in der Zwischenzeit die Benutzer- und Computerkonten?

 

OK, jetzt habe ich dich verstanden ;) .

 

Du musst natürlich mit einer Maschine deine Ziel-Domäne bereits erstellt haben, sonst funktioniert das migrieren mit ADMT nicht.

Ich würde - wenn du keine weitere Maschine zur Verfügung hast - eine bessere Client-Maschine dazu nehmen, auf diesem den Windows Server 2003 installieren und anschließend die neue Domäne "Unternehmen.de" darauf erstellen.

 

Achte aber darauf, weder der NetBIOS-Name, noch der DNS-Name der Domäne sollte mit einer der bestehednen Domänen kolidieren. Denn wenn die Quell- sowie Ziel-Domäne den gleichen Domänennamen haben (sei es nun der NetBIOS oder DNS-Name der Domänen) so kann es ebenfalls zu Problemen kommen. Sogar schon beim erstellen der Vertrauensstellung.

[Volker Racho 10]

Hallo Yusuf!

 

Ich habe mich - nach Ansicht der Hardware - dafür entschieden einen neuen Server zu kaufen mit dem ich dann die Migration vornehmen kann. Sowohl die Domäne, die IP und der NetBIOS-Name werden ganz anders heissen, so dass Komplikationen dahingehend nicht zu erwarten sind.

 

 

Allerdings habe ich noch eine Zusatzfrage, wo ich doch gerade den Experten hier am Wickel habe:

 

Über VPN (2 MBit/s synchron) werden dann ja die einzelnen Einrichtungen mit der Verwaltung verbunden. Die VPN-Router sind dann von Lancom und werden von Externen eingerichtet.

 

Jetzt müssen wir aber die IP-Bereiche neu ordnen und ich möchte mich versichern, dass das was ich tue auch fuktioniert:

 

Alle Server & Clients sollen ja nun in die neue Domäne 'unternehmen.de' und gliedert sich in, sagen wir mal, für weitere Standorte.

 

Ich möchte die IP Bereiche wie folgt vergeben:

- Verwaltung: 192.168.0.*

- Einrichtung 1: 192.168.1.*

- Einrichtung 2: 192.168.2.*

- Einrichtung 3: 192.168.3.* ...

 

Die Server sollen jeweils eine *.9-er Nummer bekommen, also 192.168.0.9, die Router (intern) jeweils die *.1. Mehr als 200 Rechner/Netzgeräte pro Einrichtung sind bestimmt nicht zu erwarten. Durch die Router und das VPN getunnelt sind die Bereiche transparent, d.h. im gesamten Netz sichtbar, richtig?

 

Und sehe ich das - inshalla es alles klappt wie geplant - dann so in der AD (u.a. des Verwaltunsgservers) so aus?

 

- AD-Standorte & Dienste

-- unternehmen.de

--- Sites

--- Verwaltung (192.168.0.*/255.255.255.0)

---- Client 1 (192.168.0.2/255.25.255.0)

...

--- Einrichtung 1 (192.168.1.*/255.255.255.0)

---- Client 2 (192.168.1.2/255.255.255.0)

...

--- Einrichtung 2 (192.168.2.*/255.255.255.0)

...

 

 

Danke für Deine Hilfe!

MD

[Daim 12]

Ich habe mich - nach Ansicht der Hardware - dafür entschieden einen neuen Server zu kaufen mit dem ich dann die Migration vornehmen kann. Sowohl die Domäne, die IP und der NetBIOS-Name werden ganz anders heissen, so dass Komplikationen dahingehend nicht zu erwarten sind.

 

Gute Entscheidung.

 

 

Allerdings habe ich noch eine Zusatzfrage, wo ich doch gerade den Experten hier am Wickel habe:

 

Wo ist hier der Experte? ;) .

 

 

Über VPN (2 MBit/s synchron) werden dann ja die einzelnen Einrichtungen mit der Verwaltung verbunden.

Die VPN-Router sind dann von Lancom und werden von Externen eingerichtet.

 

Das ist bei vielen Kunden so eingerichtet. Sprich, die interne EDV stöpselt nur noch ihr LAN in den Router.

Ab dem Router, betreut alles der Provider. Das halte ich für eine gute Lösung.

Somit kann man sich besser um andere Dinge kümmern und hat mehr Zeit für die Netzwerk-Administration.

 

 

Jetzt müssen wir aber die IP-Bereiche neu ordnen und ich möchte mich versichern, dass das was ich tue auch fuktioniert:

 

Auch wenn ich jetzt wie ein Korinthen... klinge. Du kennst das OSI-Modell?

Die Applikation kommt auf der höchsten Ebene, nämlich in der 7. Schicht.

Wie du die untersten 6 Schichten zustande bekommst (hauptsächlich die Schichten 1 bis 4), ist dem Rest egal.

Was soviel bedeutet, wenn das VPN sowie das Routing steht, dazwischen keine Firewall oder der Routeretwas blockt, dann klappt das.

 

 

Durch die Router und das VPN getunnelt sind die Bereiche transparent, d.h. im gesamten Netz sichtbar, richtig?

 

Im Prinzip, ja.

 

 

- inshalla -

 

Du meinst insallah (für unsere nicht südländischen Freunde, das bedeutet "hoffentlich") ;) .

 

 

- AD-Standorte & Dienste

-- unternehmen.de

--- Sites

--- Verwaltung (192.168.0.*/255.255.255.0)

---- Client 1 (192.168.0.2/255.25.255.0)

 

Im Snap-In "Standorte und Dienste" tauchen aber die Clients nicht auf.

Dort gilt es aber für jeden physikalsichen Standort, ein AD-Standort zu erstellen und die jeweiligen DC-Icons,

an iher entsperchenden DCs zu verschieben.

 

Die Benutzer- sowie Client Verwaltung könntest du dann mit OUs abbilden.

Somit kannst du die interne Struktur des Unternehmens, durch Organisationseinheiten (OUs) abbilden.

Die AD-Replikation wird durch AD-Standorte gesteuert.

 

Du bist auf dem richtigen Weg ;) .

[Volker Racho 10]

Hi Yusuf!

 

Experte = Du.

Ja, wir waren erst am überlegen, ob wir die Router-Betreuung auch selber machen wollen, aber die kostet uns "nur" 40 EUR im Monat und wir haben eine 24/7-Hotline, Überwachung usw. ink. Dafür können wir uns dann um wichtigere Sachen kümmern.

 

DAS ISO-OSI-Modell ist schon klar und verstanden, aber zwischen Theorie und Praxis gibt es mehr als sich unsere Schulweisheit erträumen lässt. Z.B. habe ich gesagt bekommen, ich solle nicht 'unternehmen.de' als Domänen-Name nehmen, da dies ggf. Probleme mit der DNS-Auflösung bringen würde. Ich will halt nur sicher gehen.

Eine große Firewall gibt's nur für den zentralen Internetzugang.

 

Sorry, mein Ausländisch ist etwas verrostet.

 

Die Clientverwaltung wird völlig neu mit OUs (Finanzbuchhaltung, Personalbuchhaltung, Clients von Einrichtung 1 usw.) abgebildet, ja. Und für die gibt's dann später mal die etsprechenden GPOs.

 

 

Okay, ich glaube, jetzt ist alles (erstmal) geklärt.

Dir vielen, herzlichen Dank für Deine Hilfe!

 

MassDestruction

[Daim 12]

Experte = Du.

 

Boahh... Danke für die Blumen :cool: .

 

Ja, wir waren erst am überlegen, ob wir die Router-Betreuung auch selber machen wollen, aber die kostet uns "nur" 40 EUR im Monat und wir haben eine 24/7-Hotline, Überwachung usw. ink. Dafür können wir uns dann um wichtigere Sachen kümmern

.

 

Das ist die Beste Entscheidung die du hättest treffen können.

 

 

DAS ISO-OSI-Modell ist schon klar und verstanden, aber zwischen Theorie und Praxis gibt es mehr als sich unsere Schulweisheit erträumen lässt.

 

Das zwischen Theorie und Praxis Weltern liegen können stimmt zwar, aber wenn man das Prinzip des OSI-Modells wirklich verstanden hat und das Grundverständnis verstanden+kapiert ist (Gruß an die Papier-MCSEler), dass klärt sich einiegs von selbst bzw. dann lässt sich vieles sehr sehr viel einfacher bewältigen. Sein es beim Designen von Netzwerken oder aber auch beim Troubleshooting. Aber das weißt du sicherlich auch selbst, ich wollte es nur nochmals erwähnt haben, auch für die adneren die hier mitlesen ;) .

 

 

Z.B. habe ich gesagt bekommen, ich solle nicht 'unternehmen.de' als Domänen-Name nehmen, da dies ggf. Probleme mit der DNS-Auflösung bringen würde.

 

Ja, ich behaupte mal, die Wahl des Domänen-Namen, sei es der NetBIOS- und/oder DNS-Name der Domäne, ist eines der schwierigsten Aufagen beim erstellen einer neuen Struktur.

 

Was du überhaupt nicht wählen solltest (um nicht zu sagen muss, man kann es zwar technisch zum laufen bekommen, aber Zukunftsicher ist es nicht), ist ein sogenannter "single-label" DNS-Domänen-Name. Dieser würde lediglich aus einem Wort bestehen, wie z.B. "FIRMA". Der NetBIOS-Name kann/darf ruhig einfach sein (z.B. FIRMA).

 

Bei einem single-label DNS-Domänen-Namen kann man das ganze auch so zum laufen bringen:

Information about configuring Windows for domains with single-label DNS names

 

Aber idealerweise wählt man einen ordnungsgemäßen FQDN.

 

Für die Wahl des Domänen-Namens, gibt es mehrere Varianten:

 

1. Der Active Directory-Name lautet so wie die Internetdomain.

Also wenn euer Web-Auftritt http://www.contoso.de lauten würde, könnte auch der interne DNS-Domänen-Name so lauten. Du müsstest in deinem internen DNS-Namen etwas mehr Arbeit investieren, in dem du mehrere Einträge in Form von A-Records erstllen müsstest etc.

 

2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt.

Bedeutet, wenn der Inet-Auftritt "Contoso.de" lautet, so wäre der AD-Name "intra.contoso.com". Diese Variante, wäre auch meine empfohlene. Damit ist beides (intern-extern) klar voneinander getrennt.

 

3. Der Active Directory-Name ist ein anderer als die Inet-Domain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn damit könnten Probleme mit Apple-PCs auftreten. Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.).

 

4. Oder der Webauftritt lautet "contoso.de" und die interne AD-Domäne lautet "contoso.net".

In diesem Fall sollten natürlich beide externen Domänen auf euch registriert sein.

 

5. Noch besser wäre die Top-Level-Domain AA, ZZ und die Bereiche QM–QZ und XA–XZ zu wählen.

Diese TLDs sind für die private Verwendung reserviert.

ISO 3166 - Wikipedia

 

 

Wie bereits oben geschrieben, ist mein Favorit die zweite Variante, gefolgt von der vierten (die ich bisher aber nie wählen musste ;) ).

 

 

Siehe auch:

Welcher Name ist der beste für eine AD-Domäne? - faq-o-matic.net

 

 

Eine große Firewall gibt's nur für den zentralen Internetzugang.

 

OK, so gehört sich das. Dabei vermute ich, gehen die Standorte über die Zentrale ins Internet. Hub-and-Spoke Topologie eben.

 

 

Sorry, mein Ausländisch ist etwas verrostet.

 

Es war ja fast richtig ;) .

 

 

... to be continued

[Daim 12]

Die Clientverwaltung wird völlig neu mit OUs (Finanzbuchhaltung, Personalbuchhaltung, Clients von Einrichtung 1 usw.) abgebildet, ja. Und für die gibt's dann später mal die etsprechenden GPOs.

 

Kleiner Tipp: Gestalte die Struktur so einfach wie möglich und soviel wie nötig.

Verschachtele nicht zu viele OUs oder Gruppen ineinadner, sonst wird es mit dem Überblick bzw. Fehlersuche schwierig.

 

 

Okay, ich glaube, jetzt ist alles (erstmal) geklärt.

 

Sorry, aber ich kann mir meinen Spruch einfach nicht verkneifen, wenn ich das Wort "glauben" lese.

Du weißt wer glaubt? Richtig, der Pfarrer ;) .

ITler "wissen".

 

 

Dir vielen, herzlichen Dank für Deine Hilfe!

 

Bitte, gern geschehen.

[Volker Racho 10]

Ich bin bei der ev. Kirche Chef ist Pfarrer) als Computerseelsorger angestellt, darf als schon rein aus beruflichen Dingen "glauben" vor "wissen" :p :D

 

Die OUs wollte ich nur nach Einrichtungen gliedern, dann noch nach Arbeitsbereichen. So sehe ich in der Übersicht gleich wo und welche Abteilung. Darunter wird nicht mehr unterteilt, wenn nicht unbedingt nötig.

 

Ich werde wohl auch 'intern.unternehmen.de' benutzen. also in unserem Fall 'intern.unternehmen-ort.de'. Das ist zwar lang, aber passt dann zum Rest. Und die Benutzer müssen es ja nicht eingeben oder auswählen. Wenn es nur eine Domäne gibt, werde ich es so einrichten, dass sie ohnehin nur noch Benutzername und Passwort eingeben müssen und immer automatisch in diese Domäne verbunden werden.

 

Dann kann's ja losgehen ...

Oh, Wochenende.

 

MD

[Daim 12]

Ich bin bei der ev. Kirche Chef ist Pfarrer) als Computerseelsorger angestellt, darf als schon rein aus beruflichen Dingen "glauben" vor "wissen" :p :D

 

OK, dass werde ich dann beim Papst hinterfragen :p .

 

Die OUs wollte ich nur nach Einrichtungen gliedern, dann noch nach Arbeitsbereichen. So sehe ich in der Übersicht gleich wo und welche Abteilung. Darunter wird nicht mehr unterteilt, wenn nicht unbedingt nötig.

 

OK.

 

Ich werde wohl auch 'intern.unternehmen.de' benutzen. also in unserem Fall 'intern.unternehmen-ort.de'. Das ist zwar lang, aber passt dann zum Rest.

 

Warum nimmst du nicht "intern.unternehmen.de" und nimmst noch das "-ort" dazu?

Wenn du nur "intern.unternehmen.de" nehmen würdest, wäre das neutraler gegenüber den anderen Standorten... find ich zumindest. Aber das kannst du gerne so machen, es spricht nichts dagegen.

 

Und die Benutzer müssen es ja nicht eingeben oder auswählen. Wenn es nur eine Domäne gibt, werde ich es so einrichten, dass sie ohnehin nur noch Benutzername und Passwort eingeben müssen und immer automatisch in diese Domäne verbunden werden.

 

Yepp, alles korrekt. Die Benutzer könnten sich auch mit dem User Principal Name (UPN) anmelden. Im Stil einer E-Mail Adresse, aber in den meisten Fällen reicht der Benutzername (sAMAccountName) völlig aus.

 

Dann kann's ja losgehen ...

 

Ich dachte du wärst schon fast fertig ;) .

Good Luck and Have Fun :cool: .

 

Oh, Wochenende.

 

... aber ein schönes wünsche ich.