Daim

Moin, versuche dich zuerst an diesem Artikel: Event ID 1083 Is Logged During Active Directory Replication Im zweiten Schritt, wenn nichts dagegen spricht, hebe den Domänen- bzw. Gesamtstrukturfunktionsmodus auf Windows Server 2003 hinauf. Dann kannst du in der Zukunft aber keine NT-BDCs bzw. 2000er DCs zur Domäne hinzufügen.

Kann man machen, muss man aber nicht. Wenn der lokale Admin das gleiche Kennwort wie der Domänen-Admin hat, kann direkt nach der OS-Installation das DCPROMO ausgeführt werden. Somit erspart man sich einen Schritt.

Na klar. Was machst du in einer produktiven Umgebung mit 200 Clients, wenn der einzige DC ausfällt? Wahrscheinlich erst einmal doof aus der Wäsche gucken. Daher ist es immer ratsam in jeder Domäne zwei DCs zu haben. In einer Umgebung mit nur 5 Clients wird sich keiner diesen Luxus von 2 DCs leisten können/wollen... das steht aber auf einem anderen Blatt. Womit denn nicht? So schwer ist das doch nicht... Hast du dir die bereits verlinkten Artikel auch durchgelesen? Wer ist server 3? Der 2003er DC? Wo hast du denn noch Probleme?

Bitte, soviel Zeit muss sein --> Yusuf ;) . Ist denn die FLZ AD-integriert gespeichert? Falls ja, steht auf dem zusätzlichen DC (wer immer das war, ich vermute der 2003er DC) in seinen TCP/IP-Einstellungen der 2000er DC als erster DNS-Server drin? Falls meine o.g. Punkte zutreffen, einfach Geduld haben oder den Netlogon Dienst neu starten. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Servus, auf beiden DCs solltest du auch das DNS installieren und die Forward Lookup Zone befindet sich idealerweise im AD. Dann erledigt die AD-Replikation automatisch für dich den Rest. Wenn du den gleichen Benutzer nicht zur gleichen Zeit auf beiden DCs erstellst, bekommst du vom System eine Warnung beim erstellen des Benutzers, dass bereits ein Benutzer-Objekt mit dem Namen existiert. Ansonsten geht das AD mit doppelt - zur gleichen Zeit - erstellten Objekten folgendermaßen vor: Yusuf`s Directory - Blog - Active Directory-Replikationskonflikt P.S. Im übrigen heißt es AD und nicht ADS. Ab Windows Server 2008 heißt es dann AD DS.

Servus, stimmen denn die IP-Informationen die der Client eingetragen hat auch? Bei langsamer Anmeldung ist der erste Verdächtige die DNS-Server Adresse. Steht in den TCP/IP-Einstellungen des Clients der SBS mit seiner echten IP-Adresse drin und nicht etwa ein externer DNS-Server (z.B. der DNS-Server vom ISP)? Da beim Hinzufügen des Domänen-Benutzers zur lokalen Admin-Gruppe (warum überhaupt? Das sollte nicht sein) sich die Domäne nicht auswählen lässt, ist das ein klares Indiz für ein DNS-Problem.

Servus, das sollte auch unter Windows 2000 funktionieren: Wie kann ich abfragen, welche Rechner welches Service Pack haben? - faq-o-matic.net

Servus, was ich für viel schlimmer halte, was sucht der ISA auf dem DC? Der ISA auf einem DC ist ein "No Go"! Das wäre quasi, wie wenn der Türsteher mitten auf der Tanzfläche steht.

Servus, 1. es heißt unter Windows 2000 sowie 2003 "AD". Ab Windows Server 2008 heißt es dann AD DS. 2. Wenn alle DCs sich an einem Standort befinden (Intra-Site), geht das nicht, da nach dem Änderungsbenachrichtigungsprinzip repliziert wird. Erst wenn es mehrere Standorte (Inter-Site) sind, kannst du im Snap-In "Standorte und -Dienste" in den Verbindungs-Objekten einstellen, wann wie oft repliziert werden soll. Dort kannst du zwar auch im Verbindungs-Objekt die Zeit einstellen, wann sich wie oft der DC mit seinem Replikationspartner, der am gleichen Standort (Intra-Site) steht einstellen, dass bedeutet aber nur, dass mit der dort eingestellten Zeit in jedemfall repliziert wird. Aber in erster Linie findet eine Replikation durch die Änderungsbenachrichtigung statt. Siehe auch: Yusuf`s Directory - Blog - Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren

Servus, nein, ein zusätzliches Tool zum verwalten der Rechte verwende ich keins. Du solltest auf alle Fälle die Benutzer in Gruppen zusammenfassen und in den Berechtigungen keine einzelnen Benutzer, sondern die Gruppen hinzufügen. DAs bedeutet, arbeite auf Berechtigungsebene ausschließlich mit Gruppen. Das erleichert dir in der Zukunft das tägliche Leben. Daher solltest du das A - G - DL - P Prinzip anwenden. Ich bin ein Freund davon, in der Freigabeberechtigung die Domänen-Benutzer mit Vollzugriff (bzw. Ändern) einzutragen (oder eben die gewünschte Gruppe auf das entsprechende Netzlaufwerk) und den tatsächlichen Zugriff, in den NTFS-Berechtigungen festzulegen. Yusuf`s Directory - Blog - Gruppen

Führe den Link (runterscrollen Bestpraxis: Default Domain Policy + Default Domain Controllers Policy) auf dem Windows 2000 DC in der Default Domain Policy sowie Default Domain Controllers Policy durch. Wenn du einen XP-Client in der Domäne hast, installiere dir die GPMC und barbeite die Policys von dem XP-Client, muss aber nicht sein. Das ich mit dem SMB-Signing richtig liege, bestätigt unter anderem dieser Artikel: http://support.microsoft.com/kb/281648/en-us

Bonjour, das Computerkonto-Kennwort unter NT wird standardmäßig alle 7 Tage geändert. Ab Windows 2000 sowie XP wird standardmäßig das Kennwort für das Computerkonto alle 30 Tage geändert. @onestone Neben dem was gysinma1 bereits angesprochen hat, ist das Alter des System States aus weiterer Hinsicht ebenfalls kritisch. Du sprichst von "etwa 8 Wochen alt". Nehmen wir an, die Gesamtstruktur wurde unter Windows Server 2003 (ohne SP1 sowie SP2) erstellt, so beträgt die Tombstone Lifetime standardmäßig 60 Tage. Das bedeutet, wenn dieses "etwa" doch mehr sein sollte, bekommst du ohnehin noch weitere Probleme.

Servus, der Domänen-Administrator einer Sub-Domäne kann jederzeit eine externe Vertrauensstellung erstellen. Eine Gesamtstrukturvertrauensstellung kann lediglich der Root Domänen-Administrator einrichten. Yusuf`s Directory - Blog - Vertrauensstellung zwischen zwei Gesamtstrukturen

Es macht in deinem Fall keinen Sinn, für die Aussenstelle eine Sub-Domäne zu erstellen. Ich tendiere immer zu dem Einen-Domänen Forest, aber das kommt immer auf die Gegebenheiten darauf an. 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. Lies dir auch diesen Artikel durch: Welches Domänenmodell ist das Beste für Active Directory? - faq-o-matic.net

Dann rate doch mal, was man im Snap-In "Active Directory-Standorte und -Dienste" konfigurieren kann? Richtig, genau das was du möchtest. Du erstellst für die Aussenstelle ein Standort- samt Subnetz-Objekt im AD und verschiebst den DC der Aussenstelle an diesen Standort. Danach erstellst du eine Standortverknüpfung und fügst die Zentrale sowie die Aussenstelle hinzu. Anschließend kannst du dann im Verbindungs-Objekt konfigurieren, wie oft an welchen Tagen repliziert werden soll. Auf dem DC sollte das DNS installiert und der globale Katalog aktiviert werden. Das ist das mindeste.

Servus, wie ein zusätzlicher DC konfiguriert werden sollte, entnimmst du bitte aus diesem Artikel: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Des Weiteren würde ich den zusätzlichen DC, mit der Funktion "Install from Media, kurz IFM) zum DC stufen. Dazu benötigst du von einem bestehenden DC dieser Domäne, die System State Sicherung und stufst den zusätzlichen DC (die IFM-Funktion funktioniert ausschließlich nur bei zusätzlichen DCs) mit Hilfe der Sicherung hoch. Das hat den Vorteil, dass der DC in der Aussenstelle dann nur noch die Änderungen replizieren muss, die seit der Sicherung erfolgt sind und somit bleibt das Replikationsaufkommen gering. Es ist aber zwingend notwendig, dass zum Zeitpunkt des hochstufen der zusätzliche DC, den bestehenden DC rereichen kann. Denn es ist eine Namensauflösung notwendig, sowie das erreichen des RID-Masters. Die IFM-Methode funktioniert aber ausschließlich unter Windows Server 2003. How to use the Install from Media feature to promote Windows Server 2003-based domain controllers Beachte den o.g. Link.

Sicher doch ;) Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern

Servus, bitte den folgenden Artikel genau lesen, alles prüfen und danach vorgehen. Dann verschwindet dieser lästige Fehler: Yusuf`s Directory - Blog - Dateireplikationsfehler mit der ID 13568

Servus, du kannst auch DSREVOKE verwenden.

Servus, zum Thema AD ist dieses Buch ganz gut: - Windows Server - Active Directory - Das Praxisbuch für Windows Server 2003 R2 Zur täglichen Arbeit ist dieses Handbuch nützlich: Amazon.de: Windows Server 2003 R2. Einrichtung, Verwaltung, Referenz. Mit 180-Tage-Testversion von Windows Server 2003 R2: Bücher: Eric Tierling Aber mit diesem Link, kommst du bereits auch sehr weit: Windows Server 2003 Active Directory-Betriebshandbuch: Inhaltsverzeichnis

Pff... meckern, aber ja nicht auf den Link klicken. Denn dort steht (im Beispiel des Taskplaners): sc config schedule displayname= "Task Scheduler"

Buenos tardes, das halte ich für keine gute Idee. Zur täglichen Arbeit, sollte jeder IT-Mitarbeiter einen ganz normalen Benutzer-Account haben. Erst wenn administrative Tätigkeiten durchgeführt werden müssen, sollten sie sich mit einem administrativen Konto anmelden. Dieses administrative Konto, sollte auch kein Domänen-Admin sein, sondern, die benötigten Rechte sollten idealerweise delegiert werden. Gruppenrichtlinien - Übersicht, FAQ und Tutorials Na das wäre ja noch schöner. Standardmäßig darf sich lediglich der "echte" Administrator und spezielle Operatoren anmelden. Du musst in der Default Domain Controllers Policy, folgende Richtlinie bearbeiten: Computerkonfiguration - Sicherheitseinstellungen - Lokale Richtlinien - Zuweisen von Benutzerrechten - Lokal Anmelden. Bzw. kontrolliere mal nebendran die "...verweigern" Richtlinie. Idealerweise bearbeitest du die Policy über die GPMC.

Off-Topic: Landesgenosse? Wohl auch noch "gerade um die Ecke". Aber du wohnst schon auf der richtigen Rhein-Seite, oder?

Sobald es nur annähernd um AD geht, gibt es kein Pardon :D . Nein, brauchst du nicht. Wegen mir musstest du es auch garnicht ausführen. Ich wollte nur mit dem Zaunpfahl winken (oder auch Erbsen zählen), mehr nicht ;) . P.S. Die Aussage: Ein DC hat keine lokale Benutzerdatenbank geht in Ordnung.

Bonjour, jaja... nennt mich nur Korinthen... aber ich kann es mir nicht verkneifen. Und wo liegt das Konto für den DSRM ;) .