olc

Hi, grundsätzlich kann man es so wie von Norbert beschrieben durchführen. Ich hätte jedoch bei einem solchen Vorgehen immer ein wenig Bauchschmerzen in Bezug auf die Sicherheit. Egal ob Malware, SYSTEM-Dienste oder ähnliches - es kann immer Möglichkeiten geben, in den SYSTEM-Kontext zu kommen und damit die Rechte des Computers zu erlangen. Die Frage ist immer, wie sieht Deine Umgebung aus und gibt es solche Schlupflöcher -die dann natürlich grundsätzlich behoben werden sollten... Ich persönlich würde daher eher in Richtung der folgenden Varianten gehen (beispielhaft): 1. How to Use the Cusrmgr.exe Tool to Change Administrator Account Password on Multiple Computers 2. Hey, Scripting Guy! How Can I Change the Local Administrator Password on All My Computers? Viele Grüße olc

Hi Theo Dor, das ist korrekt - Vorteil der FIND bzw. FINDSTR Variante ist jedoch, daß auch Regular Expressions etc. genutzt werden können und einiges mehr. Das macht das ganze ein wenig flexibler. Viele Grüße olc

...na ja, das ist ja schon ein wenig umfangreicher. :D Wenn Du es als PowerShell Script machen würdest, könnten wir es zusammen machen. Wie gesagt könnte man es dann auch anderen zur Verfügung stellen. Überleg es Dir einfach mal - falls ja, gib einfach kurz bescheid. Wir können ja dann 1:1 sprechen. :) Viele Grüße Fabian

Hallo Kai, ja, die Seite ist meines Erachtens wirklich genial. Gibt eine Menge Artikel, die sehr gut sind. Ich habe einfach den RSS-Feed abonniert - so ca. jede Woche ist etwas neues da. :) Ask the Directory Services Team - RSS Feed Ein wirklich guter Artikel ist auch der hier: Ask the Directory Services Team : Which KB articles resolve the most Directory Services issues? Ansonsten ist das Filing Cabinet auch noch sehr gut, die hängen auch recht eng beieinander: The Filing Cabinet - RSS Feed Sind natürlich in beiden Fällen im weitesten Sinne nur AD-Themen, die dort behandelt werden. Aber bei ASKDS sind auf der linken Seite auch die Links zu anderen Blogs, die dann Netzwerk, Core Komponenten etc. behandeln. Alles in allem sehr empfehlenswert. Zum Thema "*.ini Datei": Laß uns doch mal ein PowerShell Script basteln, welches das erledigt. Können wir ja dann auf ServerHowTo einstellen, mit dem Verweis auf den o.g. Artikel. :) Viele Grüße Fabian

Hallo, anbei ein großartiger Artikel für alle, die sich auch immer wieder die Informationen zum Aktivieren des Debug Loggings verschiedener Active Directory Komponenten (und einiger angrenzenden Themen) zusammensuchen müssen ;) : Ask the Directory Services Team : Directory Services Debug Logging Primer Viele Grüße olc

Hallo Torsten, im Moment fällt mir kein mitgeliefertes Tool ein, es sei denn Du nutzt die PowerShell. Diese kannst Du unter XP / 2003 / Vista / 2008 installieren. Du kannst jedoch recht problemlos mit einer Pipe arbeiten und eine normale DIR Ausgabe an FIND weiterleiten (ohne die Klammern): dir <PFAD> | find "<Dateiname>" DIR liefert auch einige Parameter, die das Format der Ausgabe anpassen können. Was möchtest Du denn genau erreichen? Vielleicht gibt es einen anderen Weg. Viele Grüße olc

..."nur" ist gut gesagt. Im besten Fall ist der DC ein DC. ;) Aber klar, das läßt sich halt ab und an nicht anders regeln, besonders in kleineren Umgebungen - auch wenn es nicht optimal ist. Du mußt natürlich kein LL Format machen - wenn es "nur" die NTDS.DIT erwischt hat, ist es ein logischer Fehler der Datenbank, kein Fehler im Dateisystem oder auf Harddisk Ebene. Oftmals ist das jedoch nicht so einfach einzugrenzen - daher würde ich in den meisten Fällen auf "Nummer sicher" gehen. Schlichtweg um späteren Problemen vorzubeugen. Wie oben schon angesprochen: Sollte es vom Serverhersteller entsprechende Tools geben, kannst Du die Hardware ja einmal checken. Ansonsten gibt es auch Dritthersteller, die solche Tools bieten. Der Erfahrung nach schneiden die Hersteller Ihre eigene Software natürlich besser auf Ihre Geräte zu, als es Dritthersteller können. Viele Grüße olc

Hallo Andi, das ist ein berechtigter Einwand. :D Die Datenbank zu kopieren kann jedoch nicht funktionieren, daher der Hinweis. Du hättest den gleichen Effekt wie im Moment. Solltest Du Dich für die Neuinstallation entscheiden, stellt sich die Frage des DCPROMO /FORCEREMOVAL weiterhin nicht mehr. :) Möchtest Du den Server doch zumindest irgendwie wieder hinbekommen, kannst du folgendes Vorgehen wählen (siehe Vorgehen im unteren Drittel des Artikels): Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server Ich würde jedoch trotzdem empfehlen, den DC (ggf. danach) neu zu installieren und vorher ein Low Level Format der HDDs zu machen. Viele Grüße olc

...dann hast Du mit hoher Wahrscheinlichkeit die Ursache für das Problem gefunden. ;) Sind im SYSTEM-Eventlog unter Umständen auch NTFS Fehler zu finden? Wenn Du es wirklich sauber geradebiegen möchtest, solltest Du die HDDs / RAID-Sets Low Level formatieren und das Betriebssystem vor Schritt 5 des Posts oben neu aufsetzen. Viele Grüße olc

Hallo Andi, wie LukasB schon geschrieben hat, solltest Du vor den weiteren Aktionen zumindest prüfen, woran der Defekt lag. Ob es dann wirklich der Speicher ist, defekte HDDs / RAID-Sets oder Treiberprobleme etc. pp. läßt sich sicherlich herausfinden. Was für Hardware ist der Server? Namenhafter Hersteller? Falls ja, bringen die Hersteller meist Diagnosesoftware mit. Ansonsten ist Dein Vorgehen außer Punkt 1(!) korrekt. In groben Schritten würde ich wahrscheinlich so vorgehen: Ist der andere DC voll funktionstüchtig? Unbedingt prüfen. Prüfen, ob irgendwelche Abhängigkeiten vom defekten DC existieren (DNS, DHCP, WINS, LDAP, FSMO Rollen, GC etc.) und ggf. auf den anderen DC umziehen. Defekten DC mittels DCPROMO /FORCEREMOVAL entfernen. Metadata Cleanup für den defekten DC durchführen: How to remove data in Active Directory after an unsuccessful domain controller demotion Erneutes DCPROMO des (dann hoffentlich nicht mehr defekten ;) ) DCs. Ggf. solltest Du auch prüfen, ob das Betriebssystem des defekten DCs ein Problem hat - dann wäre eine Neuinstallation vor dem DCPROMO sinnvoll. Viele Grüße olc

Hallo Mirko, Sinn der Verschlüsselung ist in diesem Fall nicht, daß alle Benutzer den selben Schlüssel verwenden, sondern jeder Benutzer einen eigenen. Ich hatte am 14.03.2008 19:10 einige Fragen gestellt, die für die Beantwortung Deiner Frage wichtig sind. Vielleicht kannst Du dazu ja noch einmal ein paar Zeilen schreiben, unter Umständen kann man Dir dann auch eine Antwort geben. :) https://www.mcseboard.de/windows-forum-allgemein-28/cipher-exe-2-128939.html#post805067 Viele Grüße olc

Hallo tpk, Ok, das kann natürlich an vielen Dingen liegen. Wie genau wurde der Server denn "umgezogen"? Ja, das ist das, was ich oben angesprochen habe. Die MMC versucht den PDCe zu kontaktieren. Erreicht diese den Rollenhalter nicht, hast Du leider schlechte Karten. Ist wirklich nicht optimal... Das wundert mich. War denn der DC selbst zu diesem Zeitpunkt "funktionell"? Unter Umständen konnte der Client schlichtweg die Namespaceserver nicht von diesem abfragen. Wie oben kurz angemerkt wäre interessant, ob der DC "korrekt" in die neue Site genommen wurde oder ob es schlichtweg nicht vollkommen korrekt erfolgt ist. Bei falschen Vorgehen kann es zu diversen Problemen kommen. Wenn Du in der MMC keinen Zugriff auf die Stämme hast, kannst Du auch nicht neues anlegen. Oder hast Du es per Kommandozeilenprogramm versucht? siehe oben - halte ich nicht für ausgeschlossen, daß da das Problem zu suchen ist. Habe so ein Szenario noch nicht gesehen, von daher kann ich momentan leider auch nur spekulieren... Viele Grüße olc

Hallo Hey, zeig mal ein wenig Selbstbewußtsein. ;) Nein, war sicherlich kein Mist. Nur denke ich im Moment eher, daß es das Problem nicht löst. :) Dann fertige doch einmal ein Userenv Log von einem Gut- und einem Schlechtfall an und hoste die beiden Logdateien: How to enable user environment debug logging in retail builds of Windows AD-Replikation als auch FRS-Replikation? Was bedeutet das? Heißt das, die Clients verbinden sich immer auf den gleichen Logonserver (auch auf das SYSVOL? Siehe "dfsutil /pktinfo" Ausgabe). Ja, das wäre insofern interessant, ob bei Aktualisierung der GPOs auf dem Client diese dann korrekt angewendet werden. Im Grunde reicht auch ein "gpupdate". Ok, ist nur ein bestimmter Standort betroffen oder mehrere Standorte (falls es mehrere Standorte gibt)? Das wäre neben anderen Dingen wichtig zu wissen. Ok, das hat nichts mit den GPOs zu tun. Es werden also keine Userenv Fehler in den Eventlogs angezeigt, nein? Viele Grüße olc

Hallo derwUwu, ganz klar die Last auf dem DHCP Server. Man muß halt auf dem Schirm behalten, daß nicht erst zum Ablauf der Lease der DHCP Server kontaktiert wird, sondern jeweils nach der Hälfte der verbelibenden Lease Zeit. Da kommt schon etwas zusammen... ;) Außerdem kann es zu Problemen kommen, wenn ein DHCP Server einmal ausfallen sollte und kein Ersatz da ist. Wäre nicht so gut, wenn dann nach einigen Stunden schon die ersten Clients keine IP-Adressen mehr bekommen. ;) Der Netzwerktraffic ist sicherlich bei den heutigen Netzen eher vernachlässigbar. Viele Grüße olc

Hallo, Ja, so ist es. Die Werte werden in der Registrierung gespeichert - ist also im Normalfall nur ein einziges Mal pro System / Installation notwendig. Viele Grüße olc

Hi stronzo, dazu gibt es keine generische Aussage, da es immer auf die jeweilige Nutzung ankommt. Wenn beispielsweise die Laptops sehr oft außerhalb des Hauses für längere Zeit unterwegs sind, kann zumindest für die Notebooks eine kürzere Leasedauer interssant sein, um die nicht genutzten IPs freizugeben. Anders herum macht es bei normalen Clients, die immer im internen Netzwerk liegen, eher Sinn, längere Leases zu wählen. Mit dem Standardwert von 8 Tagen ist man meist recht gut bedient. Vielleicht kannst Du ein paar mehr Sätze Du den äußeren Umständen schreiben, dann kann man darauf näher eingehen. Viele Grüße olc

Hallo, nein, muß er nicht. Wie XP-Fan schon angemerkt hat, kann er auch von einem anderen, beliebigen Client auf die Freigabe zugreifen, wenn er die Benutzerdaten hat. Dazu ist keine Domänenmitgliedschaft o.ä. notwendig - und daher greift in diesem Fall die Anmeldebeschränkung natürlich nicht. Viele Grüße olc

Hallo Dynadrate, Wie meinst Du das? Im Normalfall werden die Berechtigungen auf dieser Ebene mittels Share-Permisions festgelegt, d.h. die NTFS Permissions bräuchten nicht angepaßt werden. Darunter liegen dann die entsprechenden Ziele, die eine Kombination aus Share- und NTFS Permissions nutzen - wie normale Freigaben auch. Oder verstehe ich Deine Aussage falsch? Na ja, ganz so einfach ist das nicht. ;) Es hat sich schon einiges in Bezug auf DFS-N verändert, so z.B. die Speicherung der pKTInfos in der AD, es hat sich im Zusammenspiel von Vista und Windows Server 2008 viel Gutes getan, wenn es um das Failover / Failback bei ausgefallenen Targets geht (und damit das Umschwenken von File-Locks auf geöffneten Dateien etc.), es wurden diverse Limits aufgehoben und einiges mehr. Viele Grüße olc

Hallo orkon, Hast Du von einer fehlerhaften Anmeldung ein Userenv Log? Sind die DCs im Sync, d.h. funktioniert die FRS / SYSVOL Replikation korrekt bzw. die AD-Replikation? Ist unter Umständen bei einer Anmeldung ohne die korrekten GPOs immer nur ein bestimmer Anmeldeserver vom Client genutzt worden? Wenn Du nach der fehlerhaften Anmeldung (ohne die korrekten GPOs) ein "gpupdate /force" setzt, werden die Policies dann angewendet? Werden die GPOs nach ca. 90 Minuten angewendet oder sind sie auch nach Stunden nicht auf dem Client aktiv? Sind immer die gleichen Benutzer bzw. Rechner betroffen oder variiert das Problem? Betrifft es alle GPOs oder nur die user- bzw. computerspezifischen Richtlinien? Sind in den Eventlogs Fehler zu finden? Viele Grüße olc

Hallo tpk, so weit, so gut. ;) Grundsätzlich fragt jeder Namespaceserver den PDCe jede Stunde nach Änderungen in Bezug auf die Namespace Umgebung ab. Erreicht er diesen nicht, kann es durchaus zu Problemen kommen - daher würde mich genau interessieren, was Du mit "DFS startete nicht mehr" meinst. Grundsätzlich würde mich verwundern, wenn der ganze Zugriff bei einem Ausfall des PDCe versagen würde. Das ollte meines Wissens nach nicht der Fall sein. Du kannst dieses Verhalten über den sogenannten "root scalability mode" ändern, der eigentlich dafür gedacht ist, den PDCe zu entlasten, siehe Microsoft Corporation . Ist diese Option gesetzt, wird der nächste DC (im Normalfall also einer der lokalen DCs) nach Änderungen abgefragt. Nichtsdestotrotz kann es beim Ausfall des PDCe zu Problemen mit DFS-N kommen, mindestens die DFS MMC macht Probleme. Aber der Betrieb sollte weiterhin grundsätzlich möglich sein. Zusätzlich sind natürlich einige andere Funktionen vom PDCe abhängig - so auch das Verhalten bei fehlerhafter Kennworteingabe oder nach Kennwortänderungen. Das ist nur ein Beispiel, bei dem der PDCe eine "Sonderrolle" übernimmt, es gibt *zig andere. Von daher ist in jedem Fall - abgesehen von der konkreten DFS-N Problematik - zu empfehlen, den PDCe verfügbar zu halten. Viele Grüße olc

Hallo, mh, ok. Wundert mich insofern, als daß ich das in der Vergangenheit teilweise so praktiziert habe. ;) Aber gut, das waren keine Terminalserver, sondern normale Clients und es blieb der Programme Ordner übrig. "Arbeitsplatz", "Verbinden mit" etc. läßt sich jedoch problemlos ausblenden, daher meine Aussage. Problematisch ist dabei jedoch, daß man per Doppelklick z.B. auf den "Programme"-Ordner o.ä. wieder den Explorer öffnen kann. Damit ist das ganze Vorhaben natürlich obsolet - insofern macht Dein Hinweis mit der alternativen Shell / dem alternativen Startmenü sicherlich Sinn und ist korrekt. Viele Grüße olc

Guten Abend, meines Wissens gibt es (momentan?) keine Möglichkeit, die Option 3 wirklich zu verwenden. Deshalb kannst Du auch mit dem Script "Scregedit.wsf" nur die Optionen 4 und 5 auswählen - wovon 5 dann auch nicht geht. :D Soll heißen: Wie XP-Fan schon schrieb - es gibt im Moment nur die Möglichkeit, die Updates automatisch herunterladen und installieren zu lassen. :( EDIT: Schau mal hier, das kam gerade auf die Schnelle bei einer kurzen Web-Suche heraus, faßt das noch einmal ein wenig ausführlicher zusammen: The things that are better left unspoken : (Automatically) Updating Server Core Viele Grüße olc

Hallo, kleine Ergänzung, zusätzlich zum Beitrag vom XP-Fan :) : Die Richtlinie greift meines Wissens auf die "interaktive Anmeldung" (interactive logon). Da Du auf ein Share nicht dem Security Prinzipal "interactive logon" zugreifst, sondern "Netzwerk" (network), greift die Einschränkung nicht. Viele Grüße olc

Guten Abend, nutzt Du die neuere Variante des Startmenüs? Was passiert, wenn Du die klassische Variante erzwingst? Viele Grüße olc

Hi, sorry Daim - aber ich glaube Du hast den gesamten Thread nicht korrekt gelesen. Denn sonst wären Deine Anmerkungen sicherlich nicht notwendig gewesen, denn es ist die ganze Zeit von Standorten und ggf. auch mehreren Domänen die Rede. In diesem Kontext gab es dann auch schon die oben stehenden Antworten. Aus dieser Perspektive ist die Aussage von JamesKirk (und auch meine Antworten darauf) korrekt. Viele Grüße olc