Daim

Servus, du führst in einer "ruhigen Minute" (z.B. nach Feierabend oder am Wochenende) unter Start-Ausführen das DCPROMO aus und stufst den DC zum Mitgliedsserver herunter. Anschließend deinstallierst du das DNS, falls es installiert sein sollte und trägst in den TCP/IP-Einstellungen die anderen DCs als DNS-Server ein. Falls die Clients diesen DC als DNS-Server eingetragen haben, musst du das auch noch ändern (statisch oder im DHCP). Die Freigaben bleiben natürlich mit ihren Zugriffsberechtigungen alle samt erhalten.

Fein. Und für die Zukunft, zweifele NIE die Meldung des Systems an. ;) Und ein dreifaches HELAU aus Mainz. :cool:

Servus, mit dem folgenden Befehl bekommst du den "Prä-Windows 2000" (den sAMAccountName) Namen von Benutzern und Computern angezeigt: dsquery * -filter (objectclass=user) -attr samaccountname HELAU aus Mainz.

Genau so ist es. Freigabe- oder NTFS-Berechtigungen haben nichts direkt mit AD zu tun. Im AD wird nicht gespeichert mit welchen Rechten, auf welche Netzwerkressourcen die Gruppe Zugriff hat.

Servus, nein, nicht eine, sondern etliche. ;) Du könntest z.B. eine benutzerdefinierte gespeicherte Abfrage mit dem Filter "(objectcategory=group)" erstellen. Damit bekommst du alle Arten (GG, DL..) von Gruppen angezeigt. Yusufs Directory Blog - Gespeicherte Abfragen Oder mit Dsquery: dsquery group Du möchtest also wissen, wer auf welches Verzeichnis Zugriff hat. Da gibt es ebenfalls mehrere Möglichkeiten. Siehe: ShareEnum JSI Tip 9640. How do I print permissions on a folder tree using standard commands? FILEACL Main page SetACL - Windows permission management Showaccs Syntax: File and Storage Services How to use Xcacls.vbs to modify NTFS permissions

Ja, NEWSID funktioniert zwar und ist für eine Testumgebung auch in Ordnung, doch das Tool wird seitens Microsoft nicht supportet. In einer produktiven Umgebung solltest du SYSPREP anwenden. Null problemo.

Off-Topic:Also wenn du meinen Nachnamen BLIND geschrieben hast, bekommst du einen Lutscher von mir. ;)

Doch, glaube es neben dem Pfarrer ruhig. ;)

Ich wette du hast nach dem erstellen einer VM die VM kopiert und wolltest daraus einen DC bzw. eine Subdomäne erstellen. Das funktioniert wegen der SID nicht. Du musst SYSPREP anwenden oder installierst jede VM für sich neu.

Das wird jetzt schwer (bis unmöglich) dir von hier zu helfen, denn ich weiß nicht was alles bereits durchgeführt wurde. Aber da es sich um eine Testumgebung handelt, erstelle doch alles neu mit dem Wissen das du nun hast. Somit kannst du direkt das erlernte anwenden. ;) – Moment, du hast deine vorherige Antwort ergänzt, denn das ist das Problem: Du hast eine Maschine geimaget und das ist die Ursache des Problems. Daher solltest du SYSPREP anwenden um die SID zu anonymisieren, dann klappt das auch mit dem Nachbarn.

Die Meldung ist unmissverständlich deutlich. Der Name der Domäne muss bereits einmal vergeben worden sein und vielleicht hattest du es dann abgebrochen oder so. Kontrolliere in der Rootdomäne die MMC "Active Directory-Domänen und -Vertrauensstellungen" ob dort die Domäne erscheint. Überprüfe auch das DNS.

Genau so ist es. Ja. Wenn die Subdomäne erstellt wird, muss als DNS-Server der DC aus der übergeordneten Domäne eingetragen werden. Was würde unterbrochen werden? Denn wenn du die Subdomäne erstellt hast, kannst du in der Rootdomäne die im DNS eine Delegierung eben für die Subdomäne einrichten. So das die Subdomäne "ihre" Namensauflösung selber abwickelt. Wenn die Verbindung zur übergeordneten Domäne unterbrochen ist, funktioniert die Subdomäne für sich weiter. Korrekt, denn es ist ohnehin empfehlenswert in jeder Domäne zwei DCs zu betreiben.

Wenn das ALLES DOMÄNENNAMEN sind (ohne Computernamen), dann ist das korrekt.

Bitte drücke dich klarer aus. Du möchtest also die Subdomäne "bert.home.server.com" unterhalb von der Rootdomäne "server.com" erstellen? Das funktioniert nicht so wie du es bereits richtig erkannt hast, da ein Punkt weder im NetBIOS- noch im DNS-Namen enthalten sein darf. Du müsstest zuerst die Subdomäne ""home.server.com" erstellen und könntest erst dann, unterhalb von "home.server.com" die Subdomäne "bert.home.server.com" erstellen. Naming conventions in Active Directory for computers, domains, sites, and OUs

Du verwendest den falschen Begriff. "Anmelden" tut sich ein Benutzer an seinem Client. Du möchtest also mit DC03 die Subdomäne "home.server.com" erstellen. Ja, dass funktioniert selbstverständlich. Du musst dem DC03 nicht zwingend vorher das DNS-Suffix eintragen, dass passiert während du DCPROMO ausführst und die Subdomäne erstellst automatisch. Du vergibst dem DC03 nach der Betriebssysteminstallation seinen Computernamen und trägst ihm in seinen TCP/IP-Einstellungen seine IP-Adresse ein. Mehr brauchst du erstmal nicht tun. Wenn du anschließend das DCPROMO ausführst wählst du an der entsprechenden Stelle des Assistenten den Punkt "Domänencontroller für eine neue Domäne" und danach die Option "Untergeordnete Domäne in einer bestehenden Domänenstruktur" (unter Windows Server 2003) aus. Wenn allerdings der DC03 der erste "Windows Server 2008" wäre, musst du vorher das Schema aktualisieren.

Salve, coole Definierung. ;) Dein skizziertes Szenario stimmt vorne und hinten nicht. Angenommen der Computername eines DCs lautet "DCON01" und der DNS-Name der AD-Domäne "ad.domäne.tld", so lautet der FQDN des DCs "dcon01.ad.domäne.tld". Das primäre DNS-Suffix des DCs würde standardmäßig "ad.domäne.tld" lauten. Daher solltest du erneut dein Szenario klar und deutlich skizzieren. Warum machst du dir denn darüber von vornherein Gedanken? Denn von der technischen Umsetzung her, wird alles so wie es sein soll, während dem Erstellen einer AD-Domäne bzw. dem Hinzufügen eines weiteren DCs zur Domäne, automatisch konfiguriert. Du musst beim Hinzufügen eines zusätzlichen DCs zur Domäne, lediglich den Computernamen festlegen. Alles weitere erfolgt automatisch.

Dann fang mal an: Windows Server 2003 - Handbuch für die Bereitstellung: Entwerfen der Standorttopologie Download details: Windows Server 2003 Active Directory Branch Office Guide

Das kommt immer auf die Anforderung des Kunden an. Standorte sind unabhängig von der Domänenstruktur. Ein Standort kann mehr als eine Domäne enthalten und eine einzige Domäne kann sich über mehrere Standorte erstecken. Meistens geht der Trend aber zu einem "Ein-Domänenmodell" (in englisch: Single-Domain Forest). Da evtl. an jedem Standort ohnehin ein (File-) Server steht, könnte dieser zeitgleich auch DC sein. Der Server muss aber nicht gleichzeitig ein DC werden, denn wenn vernünftige VPN-Leitungen bestehen (was man heutzutage schwer annehmen sollte) können sich die Benutzer über die Leitung an den DCs in der Zentrale authentifizieren. Das hat aber den Nachteil, dass wenn zum Zeitpunkt der Anmeldung die VPN-Leitung down ist, sich die Benutzer nur mit ihren "cached Credentials" anmelden können und somit keinen Zugriff auf die Netzwerkressourcen hätten. Oftmals existiert nur eine Domäne, denn dieses erleichtert die Administration ungemein. So kann dann der Fileserver an dem Standort gleichzeitig DC sein, ohne das ein weiterer DC an dem Standort existieren muss. Denn in der Zentrale und an den anderen Standorten bestehen bereits weitere DCs der gleichen Domäne und diese halten die Domäne bei einem DC-Crash weiterhin "am Leben". Wie gesagt, es kommt immer auf die Anforderung an. Der Nachteil bei mehreren Domänen wäre: - 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 (vor Windows Server 2008). 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.

Salut, du hoffst, das eine aktuelle und funktionierende System State-Sicherung existiert. Genau aus diesem Grund ist es doch empfehlenswert in jeder Domäne mindestens zwei DCs zu installieren. Nur so kann die Domäne im Falle eines DC-Crashs vom anderen DC weiterhin aufrecht gehalten werden. Es müssen zwei DCs installiert werden. Jede Domäne enthält nur die Informationen seiner eigenen Domäne. Die DCs der Root-Domäne können nur DCs ihrer eigenen Domäne und nicht noch zusätzlich DCs der Subdomäne sein. Nein, keine Chance. Es müssen zwei DCs installiert werden.

Ich bin noch nicht zu einem wandelnden Orakel auf zwei Beinen mutiert, doch ich arbeite daran. ;) Schau hier nach: http://www.jasik.de/shutdown/stop_fehler.htm

Immer nur die Ruhe bewahren und nicht den Überblick verlieren. Im "Eifer des Gefechts" bewirkt ein kleiner Spaziergang an der frischen Luft oftmals Wunder. ;)

Das sieht schon Mal gut aus. Bevor du den alten DC ins Nirwana schickst, schalte ihn eine Zeit lang aus und stelle ihn so wie er ist in die Ecke. Denn wenn doch noch etwas fehlen sollte, kannst du es recht fix übernehmen. You are welcome. :cool:

Nein, nicht nur, sondern auch die einzelnen Dienste die es zu übernehmen gilt. Du sollst einfach an alles denken. ;)

Ja, dass LoginScript vereinfacht dir das Leben. Was alles vom alten auf den neuen DC übertragen werden sollte/muss, erfährst du hier, worauf ich bereits verwies. Das kannst du als Leitfaden nehmen. Yusufs Directory Blog - Den einzigen Domänencontroller austauschen

Aha... dann hatte ich mich doch zurecht aus dem Fenster gelehnt. :p Da könnte die Rolle noch während dem Herunterstufen des alten DCs automatisch verschoben werden. Yusufs Directory Blog - Die FSMO-Rollen mit DCPROMO verschieben Oder die Rolle wird dann im nachhinein "mit Gewalt" auf den neuen DC "geseized". Den passenden Link hatte ich dir bereits in meiner ersten Antwrt gepostet. Fakt ist, solange die Rolle des Schemamasters nicht zur Verfügung steht, können keine Schemaänderungen durchgeführt oder die Domäne aktualisiert werden.