Daim

Servus, nicht wirklich. Yusuf`s Directory - Blog - Die Grenzen des Active Directory Eigentlich nicht. Wenn aber die AD-Datenbank selbst korrupt ist, dann schon. Nicht "auf einmal", sondern ad muss der Administrator schon etwas tun. Z.B. das sich der Benutzer eben nur an bestimmten Clients anmelden darf. Prüfe mal die Konsistenz der AD-Datenbank: Yusuf`s Directory - Blog - Die Active Directory-Datenbank reparieren Des Weiteren solltest du DCDIAG auf dem DC ausführen und einen Blick in das Eventlog werfen.

Nicht im geringsten. Bevor du aber den Windows Server 2008 Server zum DC stufst und in dem Zusammenhang das ADPREP ausführst, kontrolliere die Ausgangssituation. Führe das DCDIAG sowie NetDIAG, aus den Windows Support Tools, auf dem FSMO-Rolleninhaber durch. Kontrolliere auch die Replikation und überprüfe das Eventlog. Genau. Allerdings sollte auf jedem DC das DNS installiert werden, wobei sich die FLZ im AD befinden sollte. Yusuf`s Directory - Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Ahh... ok, jetzt ist es klar. In der DFS-Verwaltung steht aber in den Eigenschaften der einzelnen DCs, der Mitgliedschaftsstatus auf "Aktiviert"? Wie sieht denn im Ereignisprotokoll, das DFS-Replikations Log, dass du unter den "Anwendungs- und Dienstprotokollen" findest, aus? Tauchen hier Fehler auf? Wenn du magst, kannst du noch einen Blick in das DFSR-Log, dass du unter "%windir%\debug\dfsr0000x.log" findest, reinwerfen.

Servus, wenn du den DC, so wie es Nils erwähnte, im LAN installierst und anschließend an den Standort verschickst, solltest du unbedingt darauf achten, im DNS die Einträge zu bereinigen. Natürlich nur, wenn es für diesen Standort einen eigenen AD-Standort gibt. Wenn du das DNS anschließend nicht bereinigst könnte es vorkommen, dass sich Clients aus der Zentrale versuchen, sich an dem entfernten DC zu authentifizieren. Das führt wiederum zu verzögerten Anmeldungen. Siehe: Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben Eine andere Möglichkeit wäre, du installierst den neuen DC vor Ort an dem Standort, mit der Install from Media (IFM) Funktion. Dazu benötigst du eine, idealerweise aktuelle System State Sicherung und kannst damit während dem Ausführen von DCPROMO die Sicherung als Basis für die AD-Informationen verwenden. Anschließend werden nur noch die Änderungen die seit der Sicherung stattgefunden haben repliziert. Die IFM-Option ist gerade für entfernte Standorte mit einer eher geringen Anbindung gedacht. Siehe: Yusuf`s Directory - Blog - Domänencontroller-Installation von einer Sicherung

OK, ich verstehe nur Bahnhof. Let us try in english. Write your question in english please.

Hallo, ich bin mir nicht sicher ob ich dich richtig verstanden habe. Ein Mitarbeiter ist aus dem Unternehmen ausgeschieden und du möchtest den Benutzer löschen und möchtest dabei auch, dass das Benutzerkonto aus den Gruppen in denen es Mitglied ist entfernt wird? Falls ich das so richtig verstanden habe, dann brauchst du lediglich das Benutzerkonto zu löschen. Denn dadurch wird das Benutzerkonto auch aus den Gruppen entfernt.

Servus, du sprichst von DFS. Habt ihr es bei euch denn so konfiguriert, dass die SYSVOL-Replikation, durch das DFS-R durchgeführt wird? Siehe auch: Ask the Directory Services Team : Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style Denn "out-of-the-Box" wird weiterhin das SYSVOL-Verzeichnis unter Windows Server 2008 noch durch den File Replication Service repliziert (in Abhängigkeit vom DFL und ob es sich um eine neue oder migrierte Domäne handelt). Demzufolge müssten (sofern durch das FRS repliziert wird) im Dateireplikationsprotokoll Fehler auftauchen, die es auszuwerten gilt. Führe auch das DCDIAG auf SERVICE durch. Nachtrag: Ob das SYSVOL-Verzeichnis durch das FRS oder DFS-R repliziert wird hängt auch davon ab, ob eine neue Domäne mit dem Domänenfunktionsmodus "Windows Server 2008" erstellt wird. Denn dann, wird über DFS-R repliziert. Wird aber von Windows 2000/2003 auf Windows 2008 migriert, so müsste auch das SYSVOL von FRS auf DFS-R migriert werden, falls gewünscht.

Servus, wenn es sich um einen Memberserver handelt, dann kannst du direkt die zweite R2-CD in den Server einlegen und aktualisierst das System auf R2. Handelt es sich dabei aber um einen DC, so musst du vorher das ADPREP /FORESTPREP von der zweiten R2-CD ausführen. Die Voraussetzungen um auf R2 zu aktualisieren, wären: - Das Service Pack 1 für den Windows Server 2003 muss installiert sein. - Die zweite R2-CD muss von der R2 Version vorhanden sein. - Der Windows Server 2003 R2 Produkt-Key muss vorhanden sein (was eine gültige Lizenz voraussetzt, die du ja schon hast) Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Servus, wenn du jetzt von einem Windows Server 2008 sprichst, dann kann auf diesem erst die Exchange-Version 2007 mit SP1 und die SQL-Version 2005 mit SP2 installiert werden. Windows Server 2008: Supported Microsoft Applications

Ich habe mich zwar nicht eindeutig ausgedrückt, aber du auch nicht ganz. ;) Wie baut denn der Client eine Verbindung zum DC auf? Nämlich durch den sicheren Kanal, für den er das Computerkontokennwort benötigt. :p

Tach, ja ja ja, dass habe ich aber mit Absicht so geschrieben. Denn in einer SBS-Umgebung die meistens nur an einem Standort existiert, mit maximal 75 Benutzern/Clients und dabei mehr als zwei DCs... halte ich wiederum für oversized. Daher hatte ich bewußt "ein weiterer" geschrieben. Wobei natürlich technisch gesehen mehrere DCs existieren können.

Vergiß es. Der einzigst supportete Weg ist NTDSUTIL oder eben das Snap-In. Alles andere wäre ebenfalls nicht supportet und so würdest du ein neues Problem schaffen. Dann erstelle, so wie Nils es bereits erwähnte, einen DC entweder auf einer physikalischen Maschine oder eine VM, diesmal im Virtual Server.

Salut, XP-Fan hat recht. Natürlich kann in einer SBS-Umgebung ein weiterer DC existieren. Siehe: Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS)

Das darfst du in der IT-Welt nie zugeben bzw. nie aussprechen. Man muss immer Ausreden parat haben, die sich verdammt cool anhören. :p Ohh haa... das ist natürlich sehr ungeschickt. Achte in der Zukunft darauf. Ich sage immer, SYSVOL-Probleme sind eklige Probleme. Im nachhinein ist das klar. Wie soll sich denn der neue DC das SYSVOL replizieren, wenn auf dem UrsprungsDC nichts geht. Uii... ein Unix-Admin. Dann gibt es zusätzlich einen extra Bonbon für die Windows-Welt. :p Schön das es nun wieder läuft.

Servus, installiere dir die Exchange-Verwaltungstools: Installieren der Exchange-Systemverwaltungstools Edit: To late.. ;)

Kein Problem. Ich wußte, dass das Problem nicht mit ein-zwei Sätzen erledigt wäre, daher habe ich dich hierher verwiesen. So haben dann auch alle etwas davon und können Tipps geben. ;) Na das wurde aber auch mal Zeit. ;) Du hast jetzt einen kleinen Ausschnitt davon gepostet, der soweit in Ordnung ist. Wenn der Rest genauso aussieht und kein Eintrag mit FAILED existiert ist das schon mal ok. OK, dann hängt das Problem "nur" am SYSVOL-Verzeichnis. Du hast also die beiden Registry-Keys D2 und D4 gesetzt und nichts hat sich getan? Im Eventlog stehen garantiert jede Menge Fehler, gehe diesen auch auf der Seite EventID.Net - Troubleshooting information for Windows event logs nach.

Salut, oder eben das Schema-SnapIn. Denn der Schema-Master lässt sich ohnehin so oder so (Transfer oder seize), über die GUI verschieben.

Servus Frank, so trifft man sich wieder. ;) Bekommen denn die Clients den neuen DC auch als DNS-Server mitgeteilt? Dann ist ja bereits beim Heraufstufen etwas schief gelaufen. Wurde denn der DCPROMO-Vorgang ERFOLGREICH abgeschlossen? Du könntest mal das DCPROMOUI.LOG kontrollieren. Yusuf`s Directory - Blog - Debug Protokollierung Im Eventlog müsste ja "Karneval in Rio" sein. Der DC kann sich nicht im AD als DC bekannt geben. Kontrolliere ob z.B. der Anmeldedienst gestartet ist. Die Ausgabe von NLTEST sieht aber korrekt aus. Letztenendes ist dein Problem, dass das SYSVOL-Verzeichnis fehlt und evtl. der NETLOGON-Dienst nicht läuft. Trotz alledem solltest du noch weiter den DC überprüfen, in dem du z.B. kontrollierst ob das userAccountControl-Attribut in den Eigenschaften des DCs den Wert 532480 enthält. Halte dich dazu an diesen Artikel: Domain controller is not functioning correctly Des Weiteren überprüfe auch diesen Artikel: Troubleshooting missing SYSVOL and NETLOGON shares on Windows 2000 domain controllers

Korrekt.

Aloha, hast du gerade viel zu tun? Denn du warst mal aktivier on Board. ;) Sag doch sowas nicht. Wo soll der denn sein, im Supermarkt? Wenn du tatsächlich einen treffen solltest sag ihm, ich hätte auch eine Frage an ihn, nämlich, wie die Lottozahlen von nächster Woche lauten. :) Genau. Ein Netzwerk hat nicht nur ein Sicherheitsschloss was die Sicherheit anbetrifft, sondern mehrere und eins davon, sollte bereits an der Eingangstür zu dem Gebäude hängen. Kann jeder einfach (vielleicht auch noch unbemerkt) das Gebäude betreten? Ein weiteres Sicherheitsschloss wäre das Thema Social Engineering usw. Die Sicherheit des Netzwerks ist nicht nur die Firewall die das Netz gegenüber den bösen Gefahren aus dem Internet schützen soll. Wie sieht es aber mit den internen Gefahren aus. Denke nicht nur an Firmen die lediglich hier in Deutschland angesiedelt sind. Denke auch an Enterprise-Unternehmen mit weltweiten Strukturen, wo sich Standorte mitten im Urwald befinden etc. Idealerweise sollte sich, alles was durch Kennwörter geschützt werden soll, das Kennwort regelmäßig ändern. Denn die Sicherheit eines Netzes ist sehr vielschichtig. Natürlich wird nicht alles so heiß gegessen wie es gekocht wird, aber manch anderer glaubt auch das er mit einem DHCP-Server Angreifer abschrecken könnte. Es gibt aber auch Situationen, in denen das ändern des Computerkontokennworts zu einem Problem werden kann, wie z.B. beim Einsatz von PC-Wächter etc. Fakt ist, dass Computerkontokennwort dient zur Absicherung der Datenkommunikation zwischen Client und Server (sicherer Kanal). Und das ist eben ein nicht unwichtiger Punkt. Glaubst du das man davon erfahren würde? Welche Firma würde das preis geben oder wieviele Firmen haben das erst garnicht bemerkt etc. Du könntest auch Fragen, in welchen Firmen bereits ein DC geklauft wurde. Das wirst du genauso wenig erfahren oder wenn, dann nur durch Zufall. Wie gesagt, damit wäre ein Schloss was die Sicherheits des Netzwerks anbetrifft, bereits offen. Das machst du aber auch deswegen, weil du die VMs vermutlich in einer Testumgebung verwendest die auch mal längere Tage ausgeschaltet sind. Eine produktive VM wird sicherlich in der Firma nicht länger als 30 Tage ausgeschaltet sein oder wenn es das wäre, ist es nicht kritisch. Daher kannst du das in deiner Testumgebung gerne tun.

Salut, "Failed to Open the Group Policy Object" Error Message Occurs When You Try to Open a Policy As a Domain Administrator

Hola, nein. Ja, kannst du. Im Attribut pwdlastset in den Eigenschaften eines jeden Computerkontos. Dort ist ein Integer Wert hinterlegt, den du dann noch umrechnen musst, z.B. so: w32tm /ntte <Wert>. Ja, beeinflussen kannst du es per Richtlinie. Aus Sicherheitsgründen solltest du es aber nicht deaktivieren bzw. sooo hoch den Wert setzen. Computerkonfiguration - Windows-Einstellungen - Sicherheitseinstellungen - Lokale Richtlinien - Sicherheitsoptionen - "Domänenmitglied: Maximalalter von Computerkontenkennwörtern".

Günaydin, (<-- Guten Morgen) sehe ich genauso. Jeder der schon einmal mit SYSVOL-Problemen zu tun hatte, weiß wie unangenehm diese Probleme sind. Dabei ist nicht alles was man in der IT machen kann... sinnvoll.

Servus, in dem du im Snap-In "Active Directory-Benutzer und -Computer" unter Ansicht die "Erweiterten Funktionen" aktivierst und dann in den Eigenschaften des Benutzerkontos, im Reiter Sicherheit unten auf Erweitert klickst. Dort kontrollierst du dann den Reiter Besitzer.

Servus, wenn du die Boardsuche beansprucht hättest, würdest du nur so von hilfreichen Tipps erschlagen werden. Siehe: Microsoft Corporation