Daim

Wenn du den aletn nicht mehr als DC in der Domäne einsetzen möchtest, dann ist dieser ordnungsgemäß mit DCPROMO aus der Domäne zu entfernen. Mit "anderen Ort" meinst du einen anderen Standort? Ja, dass geht auch. Beachte: Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben

Servus, ersetze müssten durch liegen ;). Der OP muss nicht unbedingt mit ADSIEdit hantieren. Das kann man auch im Snap-In "Active Directory-Standorte und -Dienste" kontrollieren. Dort unter Services - NetServices. Aber es stimmt, die Daten werden in der Konfigurations-Partition im AD gespeichert.

Servus, ziehe dem Server ein rosanes Hemd an und eine rote Krawatte :p . Kannst du das bitte etwas erläutern, was du mit "umziehen" meinst?

Moin, suchst du etwa das hier: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Oder hier die Nr.9: Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Servus, ohh doch, da sehe ich sogar ein gewaltiges Problem! In der Bundesrepublik Deutschland gibt es bestehende Gesetze (Österreich und Schweiz ebenso). Man braucht dazu nicht zwingend einen Betriebsrat, da das Bundesdatenschutzgesetz (BDSG) vom Gesetzgeber gilt. Die betroffenen haben das Recht, selbst zu bestimmen was mit ihren Daten passiert und dazu gehört eine Protokollierung. Wenn du also "einfach" protokollierst, ist das ein Grund für eine fristlose Kündigung. Ich empfehle dieses zu lesen: Datenschutz - Wikipedia Das Thema ist ein "heißes" Pflaster!

Moin, in Form eines ADMs geht das. Auf dieser Seite die Nr. 9 ist das, was du suchst: Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Servus, yepp, hatte ich. Wenn z.B. ein Benutzer erstellt wird mit dem Benutzernamen "Müller", dann kann man sich z.B. auch als "Mueller" anmelden. Windows logon behavior if your user name contains characters that have accents or other diacritical marks Man sollte um sich keine Stolpersteine einzubauen, von vornherein Umlaute in der IT meiden. Ändern kannst du es so wie grizzly das bereits erwähnt hat durch einen Zwischenschritt oder statt das du eines "S" z.B. "B" eingibst und dann "ss".

Servus, ich hatte bisher mit Novell zwar nichts zu tun, aber da beide Systeme LDAP in der Version 3 unterstützen, sollte das kein größeres Problem darstellen. Die Benutzer dürftest du die Benutzer recht einfach in die Windows Domäne migrieren können. Schau dir diese Artikel dazu an: Migration von Novell NetWare zu Windows Server 2003 Comparing Microsoft Active Directory to Novell's NDS

Servus, nur mal zur Info: Irgendwann (so Gott will) wird Mr. Gruppenrichtlinien.de sein ADM-Tool mal fertig entwickelt haben. Das Tool heißt GPADDIT ---> GPaddit ... so mal in die Runde geworfen ;).

Servus, Vorsicht! Überwachungen sind mindestens in Deutschland Mitbestimmungspflichtig! Yusuf`s Directory - Blog - Dateizugriff überwachen

Servus Tom, schade das es nicht geklappt hat :( . Aber gerade das DNS ist ein Riesengebiet und das muss 100%ig sitzen. Denn das DNS gehört zum Grundbaustein einer Netzwerkadministration und wenn dieses Thema sitzt, hast du es in der Zukunft im täglichen Leben wesentlich leichter. Gerade die vielen Einsatzgebiete des DNS, was muss getan werden wenn ich einen Mail-Server einsetze? Für welche Gebiete bietet sich eine Stub-Zone an? usw. usf. Daher rate ich dir, bete das DNS hoch und runter, es bringt dir für die Zukunft nur Vorteile.

Aloha, das brauchst du nicht unbedingt. Exportiere auf dem "alten" Server folgenden Registry-Schlüssel und importiere diesen auf dem neuen: Start - Ausführen - Regedit - HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares Warum die SID? Nein, dass sieht recht vernünftig aus ;).

Nimm es mir bitte nicht übel, aber für dein erstes Konzept und dann gleich solch eine Herausforderung, halte ich für gefährlich. Die 15 Mann-Tage halte ich ebenfalls für sehr knapp bemessen. Gerade der Standort mit 6.000 Usern, muss äusserst ordentlich geplant werden. Die Infrastruktur muss richtig gewählt und eingesetzt werden. Ich kann nur sagen, sucht euch jemanden der in diesem Gebiet und vorallem dieser Größe, Erfahrung hat.

Das ist wirklich ein tolles Projekt, an dem man viiieell lernen kann. Boahh...Brutal. Habt ihr schon die 110 angerufen :D .

Prima, der Tag fängt gut an ;). Danke für die Rückmeldung.

Servus, du musst mir noch bitte das Ziel genauer definieren und auf die Begrifflichkeiten achten. Mit einer "Gesamtdomöne" ist wohl eine Gesamtstruktur gemeint, in der es das Ein-Domönen-Modell geben soll und die Standorte anstatt Sub-Domänen in OUs abgebildet werden? Hier meinst du wohl eine Gesamtsruktur mit einer Root-Domäne (die Leer sein kann) und die jeweilgen Standorte (insgesamt 160 ---> :shock: ) stellen eine Sub-Domäne dar. Das können sie so oder so. Sie verbinden sich mit dem Netzwerk und melden sich an ihrer Domäne an. Wenn die Leitung es her gibt, wird auch das Login-Skript ausgeführt und sie haben dann von überall Zugriff auf die Netzlaufwerke. Hier mal ein paar Punkte von mir: 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. Aber eins erscheint mir überflüssig, dass ihr für alle eurer 160 Standorte eine Sub-Domäne erstellt. Das ist mit Sicherheit zuviel des guten. Zumal eben noch dazu kommt, dass idealerweise jede Domäne zwei DCs haben sollte :shock: DAs ist wirklich eine große, schöne und herausfordernde Aufgabe. Seit bei der Planung bedacht und überlegt euch genau (anhand der Anzahl von Benutzern pro Standort), welches Design das ideale wäre. 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 (Link ist temporör): Welches Domänenmodell ist das Beste für Active Directory? - faq-o-matic.net

OK, dann überprüfe zur Sicherheit noch das DNS, dass der DC an seinem neuen Standort sich mit seinen neuen SRV-Records auch richtig eingetragen hat. Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben Wenn du einen anderen Ort findest als den, den du angegeben hast, sach bescheid ;). Ja, genau dort deaktiviert man das.

Hast du denn auch im Snap-In "Active Directory-Standorte und -Dienste" das DC-Icon für Standort B an seinen Standort auch verschoben? Das stimmt so nicht. Wenn kein durchgeroutetes Netzwerk existiert, würde ich die Überbrückung deaktivieren. Sonst kann evtl. genau das entstehen, was du nicht möchtest, dass eben Standort B mit C replizieren möchte.

Servus, ja das sieht gut aus. Ich erläutere das ganze etwas mal ;). Prinzipiell gilt, wenn möglich sollte jede Domäne zwei DCs haben. Somit ist die Domäne gegen einen DC-Crash "gesichert". Das schließt natürlich eine regelmäße Sicherung (vorallem des SYSTEM STATES) nicht aus. Zu allererst sollte ein /aktuelles/ sowie natürlich funktionierendes Backup der Daten und vom System State existieren. Du musst im ersten Schritt das Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur siche" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann musst Du die 5 FSMO Rollen auf den neuen DC noch verschieben: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Bevor Du den alten DC mit DCPROMO aus der Domäne nimmst, sichere noch das EFS-Zertifikat bzw. was noch zu beachten wäre siehe folgenden Artikel: Was muss ich tun, um den ersten DC zu deinstallieren? - faq-o-matic.net Die DHCP Datenbank kannst Du exportieren: How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running Windows Server 2003 WINS solltest Du ebenfalls installieren. Der WINS erleichtert Dir das tägliche Leben: Brauche ich noch WINS, wenn ich ein AD betreibe? - faq-o-matic.net Wie sollte WINS konfiguriert werden? - faq-o-matic.net Die Freigaben könntest Du ebenfalls exportieren..: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares ... oder Du benutzt das File Migration Toolkit (FSMT): Microsoft File Server Migration Toolkit Drucker kannst Du mit dem Print Migrator kopieren/verschieben: Download details: Windows Print Migrator 3.1 Vergiß nicht evtl. die Anmeldeskripte anzupassen. Die Daten kannst Du mit NTBACKUP Sichern und auf dem neuen wiederherstellen. Weiteres erfährst du von hier: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen

Keinen, denn das sind zwei verschiedene Dinge. Der Distinguished Name ist die Pfad-Angabe, wo sich ein Objekt befindet. Das war wohl der Fehler. Der Anmeldename Administrator@testdomain.de ist der UPN = User-Principal-Name (zu deutsch: Anmeldename in Form einer E-Mail Adresse). User-Principal-Name (Windows) Das Pendant dazu wäre der samAccountName oder bekannt unter "Prä-Windows 2000 Anmeldename". Dieser darf/kann nur 20 Zeichen haben und der UPN kann bis zu 256 Zeichen enthalten. SAM-Account-Name (Windows) Die Applikation wird wohl ein Benutzerkonto gebraucht haben um auf das AD zuzugreifen.

Nein, dass musst du und solltest du auch nicht. Die Verbindungs-Objekte sollten weiterhin vom KCC verwaltet/erstellt werden. In der Anzeige steht dann <automatisch generiert>. So ganz ist der Groschen aber noch nicht gefallen ;) (wobei kein Wunder bei diesem Thema). Diese Deaktivierung der Standortverknüpfungsbrücke sorgt dafür, dass das AD nicht mehr "wie es lustig ist" Verbindungen zu Standort X oder Standort Y erstellt. Der KCC geht dabei nach einem bestimmten Algorythmus vor. Abhängig von Ping Zeiten oder eingetragenen Kosten usw. Wenn also die Standortverknüpfungsbrücke deaktiviert ist, hält sich das AD explizit an deine erstellten Standortverknüpfungen. Standort A repliziert sich dann nur noch mit Standort B. Die Überflüssigen Verbindungs-Objekte die zum Zeitpunkt des deaktivierens der Standortverknüpfungsbrücke existieren, kannst du händisch löschen. Der KCC läuft ohnehin alle 15 Minuten und überprüft die Topologie. Doch, manuell erstellte Verbindungs-Objekte werden in der Anzeige mit einer GUID angezeigt. Dieses zeigt, dass sie händisch und nicht vom AD erstellt worden sind. Das bedeutet weiter, für diese Verbindung ist der Admin und nicht das AD zuständig. Es geht hier also um die Verwaltung bzw. Verantwortung der Verbindungs-Objekte. Wie gesagt, dass kannst (solltest) du ruhig so lassen (automatisch generiert).

Servus, ist auf dem DC das SP2 installiert und befindet sich eine Intel oder Broadcom NIC drin? Falls ja, dann: You Had Me At EHLO... : Windows 2003 Scalable Networking pack and its possible effects on Exchange [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "EnableTCPChimney"=dword:00000000 und [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "EnableRSS"=dword:00000000

Werden Änderungen in der Berechtigungsliste des AdminSDHolder - Objekts vorgenommen, werden diese für alle Mitglieder der Dienstadministratorgruppe übernommen. Daher stellt eine Änderung des AdminSDHolder - Objekts ein Sicherheitsrisiko dar und deshalb sollten diese (falls nötig), gut durchdacht worden sein. Falls Änderungen am AdminSDHolder - Objekt getätigt werden, wird dieses im Ereignisprotokoll der Domänencontroller aufgezeichnet, der in etwa wie folgt aussieht: Die Quelle lautet „Security“, als Kategorie wird „Verzeichnisdienstzugriff“ vermerkt, der Typ lautet „Erfolg“ und als „Ereignis - ID“ wird die „ID 565“ gespeichert. Dieses gilt es auf allen Domänencontrollern zu kontrollieren. Wenn eine nicht autorisierte Änderung am AdminSDHolder - Objekt vorgenommen wurde, kann diese aus dem Pfad CN=AdminSDHolder, CN=System, DC=<Domäne>, DC=DE der Domänenverzeichnispartition, wiederhergestellt werden. Falls es notwendig wäre, andere Rechte auf administrative Konten zu vergeben, kann man diese mit ADSIEdit aus den Windows Support Tools (die sich auf der Windows Server 2003-CD im Ordner Support befindet) ändern. Du kannst dir über den AdminSDHolder auch diese Artikel anschauen: Search The Knowledge Base

Servus, hmm... das riecht mir sehr nach dem AdminSDHolder-Prozess. In welchen Gruppen sind die Benutzerkonten denen du das delegieren möchtest Mitglied? Zur Erklärung: Das Active Directory enthält einen Schutz - Mechanismus, dass Benutzerkonten und Gruppen die Mitglieder von Dienstadministratorgruppen sind, speziell schützt. Der Domänencontroller, der die FSMO - Rolle des PDC - Emulators innehat, überprüft alle 60 Minuten, dass die DACLs dieser Konten mit der Berechtigungsliste eines speziellen AdminSDHolder - Objekts übereinstimmen. Hinweis: Wenn im folgenden Registry - Pfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters der Schlüssel "AdminSDProtectFrequency" nicht gesetzt ist (der standardmäßig nicht existiert), dann lautet das Überprüfungsintervall des PDC - Emulators 60 Minuten. Der Wert kann zwischen 1 Minute (60 Sekunden) und 2 Stunden (7200 Sekunden) liegen. Dieser Prozess soll verhindern, dass die Sicherheitsberechtigung an administrativen Konten geändert wird und somit zu viele Domänenadministratoren oder andere Anwender mit höheren Rechten, administrative Tätigkeiten ausführen können. Der Prozess geht dabei folgendermaßen vor: - Es prüft, welche Benutzerkonten direkt oder verschachtelt in einer der geschützten Gruppen sind und setzt dessen Attribute „adminCount“ auf den Wert von größer 0 - Alle Benutzerkonten, die einen Wert des Attributs „adminCount“ größer 0 haben, werden auf den Standardwert (der den Rechten des Objekts AdminSDHolder entspricht) zurückgesetzt. Das bedeutet, dass die Rechte die man auf der Registerkarte „Sicherheit“ des Benutzerkonto`s sieht, zurückgesetzt werden und auch für alle administrativen Konten gilt. - Der Standardwert basiert auf den Berechtigungen des Objektes CN=AdminSDHolder,CN=System,DC=<Domäne>,DC=<TLD> und dient als Vorlage für alle administrativen Konten. - Damit wird ebenfalls die Vererbung durch darüber liegende OUs deaktiviert Folgende Gruppen (samt den direkten oder verschachtelten Mitgliedern sowie Gruppen) ab Windows 2000, einschließlich Service Pack 3 werden durch den AdminSDHolder geschützt: - Organisations-Administratoren - Schema - Administratoren - Domänen - Administratoren - Administratoren Ab dem Service Pack 4 für Windows 2000 (oder mit installiertem Hotfix 327825 auch mit früherem SP) / Windows Server 2003 werden folgende Gruppen mitgeschützt: - Server - Operatoren - Sicherungs - Operatoren - Konten - Operatoren - Druck - Operatoren - Zertifikatherausgeber Zusätzlich werden die Benutzerkonten „Administrator“ und „KRBTGT“ ebenfalls vom AdminSDHolder Prozess geschützt sowie Benutzerkonten die in Verteilergruppen (auch verschachtelt) ebenfalls Mitglied einer der geschützten Gruppen sind. Die Operatoren - Konten (und nur diese) können von dem AdminSDHolder - Prozess ausgenommen werden. Dazu muss ein Hotfix installiert werden, der aus diesem Artikel angefordert werden kann Delegated permissions are not available and inheritance is automatically disabled. Dort ist auch erklärt, wie der Schutz für bestimmte Gruppen deaktiviert werden kann. Erkennt der PDC - Emulator eine Abweichung in der Berechtigungsliste (ausgehend von der Berechtigungsliste des AdminSDHolder), wird diese dahingehend geändert, um eine Übereinstimmung mit der Liste des AdminSDHolder`s zu erzielen. Wenn Benutzerkonten aus den geschützten Konten entfernt werden, bekommen sie nicht automatisch die Sicherheitseigenschaften angepasst, damit sie erneut die vererbten Berechtigungen akzeptieren. Diese Änderung muss manuell oder durch ein Script (ein Beispielscript befindet sich im oben angegebenen Artikel) erledigt werden. ...to be continued.

Servus, nein, hast du nicht. Der Distinguished Name des Administrator-Accounts ist standardmäßig CN=Administrator,CN=USERS,DC=Domäne,DC=TLD Du solltest der Hersteller der Applikation fragen, was gemeint ist.