daabm

Dualcore mit 4 GB RAM und nur 30 User? Das kann nicht sein... Wir lassen in Domänen mit über 1.000 Benutzern gerade mal 2 DCs mit dieser Ausstattung laufen, und das ist noch überdimensioniert. Dein Problem muß meiner Meinung nach andere Ursachen haben :)

Doch, kann man. Er kann es allerdings rückgängig machen - dafür ist er ja Domänen-Admin. Ein Admin kann sich immer über alle Restriktionen hinwegsetzen. Er muß aber wissen, wie es geht. Und wenn Deine Domain Controller physisch gesichert sind, wird es schwieriger :D

Oder man macht es per for-Schleife oder Powershell rekursiv und faßt jeden Ordner einzeln an. Aber "neu machen" ist besser - das klingt nämlich nach dem krassen Gegensatz von "K.I.S.S." :)

Process Monitor hilft fast immer - Filter auf "Access denied".

So ähnlich wie Norbert sehe ich das auch - das ist ein Problem der Subnetzmasken. Wenn die Zieladresse nicht im eigenen Subnetz liegt, wird der Router (das Default GW) bemüht. "tracerte" und "pathping" verraten Dir das ganz schnell, auch ohne Netzmaskenrechner :)

Ok, danke für den Tip - das mit dem Zurückschreiben hatte ich vergessen :)

Du möchtest "Webanmeldeinformationen" ausblenden oder was genau? Wäre mir nicht bekannt, daß das geht - entweder ganz oder gar nicht :)

Die NLA von RDP authentifiziert Dich nicht erst "auf dem Zielcomputer", sondern schon auf dem TS-Client. Das geht also mit "Anmelden an" nicht. Was Du suchst, sind Sicherheiteinstellungen - Zuweisen von Benutzerrechten: "Lokal anmelden zulassen" und "Lokal anmelden verweigern".

Nein, mußt Du nicht. Du mußt nur "Deine" Policy über die Default Domain Policy schieben. Sonst wird sie nämlich wieder überschrieben - die Verarbeitung erfolgt von unten nach oben.Steht bestimmt irgendwo in den beiden Links, die Sunny schon gepostet hat. Oder in einem der anderen Howtos von Mark. @Zahni: In die DDP und DDCP packe ich zumindest gar nix - ich mach mir eine eigene (ggf. halt als Kopie davon), schiebt die drüber und ändere dann da. Motivation dafür sind die statischen GUIDs der beiden und DCGPOFIX. Aber das ist natürlich keine in Stein gemeißelte Regel, sondern nur ein Erfahrungswert :)

Du läßt "wünsch Dir was" mit Dir spielen. Das funktioniert nicht - zumindest nicht bei Euch, da Ihr offensichtlich keinen Security-Beauftragten und vermutlich auch keine interne Revision habt. In dem Fall heißt es dann nämlich "So isses"... Soll heißen: Entweder Du hast die Cojones und stellst die Fakten klar. Oder halt nicht. Voraussetzung dafür ist natürlich, daß Du einen klaren Plan und eine strukturierte Administrationsweise hast. Also zurück zum Thema - such nach "Pass the hash" in Verbindung mit Cached Credentials. Domain Admins melden sich auf Domain Controllern an, sonst nirgends. Server-Admins melden sich auf Member Servern an, sonst nirgends. Client Admins melden sich auf Clients an, sonst nirgends. Und als Info aus der Praxis: Auf allen unseren Servern gibt es keine lokalen Benutzer (jepp - nirgends). Domain Admins können sich nur auf Servern anmelden, nicht auf Clients ("nur auf DCs" kommt demnächst). Für alle Serverfunktionen gibt es entsprechende Domänengruppen, die auf dieser Serverfunktion lokaler Admin sind. Für Clients ebenso. Nicht-"Server-Admins" können sich an Servern nicht anmelden (Ausnahme natürlich RDS). Auf Servern ist Cached Credentials = 0, auf Clients (wegen Offline-Anmeldung) = 1. Für Dich kann ich nicht sprechen. Ich hab vor 20 Jahren mein Hobby zum Beruf gemacht und es nie bereut. Engagement war dabei nie fehl am Platz und hat sich langfristig immer ausgezahlt. Du solltest darüber vielleicht noch mal nachdenken... Siehe Norbert :( Viele Anteile Deiner Beiträge gehören eigentlich ins OT.

Für mich tut's das hier ganz prima: https://gallery.technet.microsoft.com/scriptcenter/Enhanced-Script-Logging-27615f85

Irrtum. Der soll die Domäne (= das AD) administrieren können. Sonst gar nix. Vor allem hat er auf Membern (Server und Workstations) nix verloren - such mal ein wenig nach "Pass the hash", in Verbindung mit Cached Credentials ist das eine ernst zu nehmende Bedrohung! Irrtum. Was ist, wenn Dir was passiert? Liegt irgendwo in einem Tresor ein Umschlag mit User und Kennwort? Oder gibt es zwei vertrauenswürdige Instanzen, die jeweils die Hälfte davon kennen? Wenn Du beides mit "Nein" beantwortest, sitzt Deine Firma auf einer tickenden Zeitbombe. BTW: Die Formulierung klingt für mich ein wenig nach "Security by obscurity" :) Irrtum. In einem gut verwalteten AD gibt es außer "Guest" und "Administrator" keine lokalen Konten. Und ein SQL-Server nutzt niemals nur die SQL-Authentifizierung (idealerweise nutzt er sie gar nicht). Das ist zwar möglicherweise die Schuld der Dienstleister, aber Ihr habt es ihnen ermöglicht.

Ok, soweit so gut. Dann behebe den Fehler - und nutze SYSVOL und NETLOGON nicht mehr als Softwareverteilpunkt. Dafür ist es nicht gedacht und nicht geeignet. Wird Dir bei Deinem dcpromo-Problem aber auch nicht helfen. So aus dem Bauch: Ein Experte von außen wäre nicht die schlechteste Wahl...

Das einzige, was mir in dem Zusammenhang einfällt, ist diese Sicherheitseinstellung: Geräte: Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschränken Aber wenn es mit einem "aktuellen" RDP-CLient geht, würde ich eher die Thin Clients aktualisieren/austauschen.

...ich geb auf. Dein Input ist zu sparsam, und Du verstehst das Prinzip von AD nicht - entweder es ist gesund (alle DCs sind gesund), oder es ist krank. Und wenn es krank ist, dann geht halt manches nicht, und manches funktioniert nicht wie man wünscht. Viel Spaß noch...

...es gibt keine "optionalen" Domain Controller. Entweder ein Server ist DC oder er ist es eben nicht. Der unterste - ist das der, den Du runterstufen wolltest?

BTT... Norbert, wenn die Domäne noch "aus W2K kommt", dann ist die TSL nur ein Aspekt. Hatte letzthin eine Diskussion mit unserem PFE darüber - die Replikation auf Attribut-Ebene oder (bei mehrwertigen Attributen) auf Elementebene wäre ein weiterer. Und da waren noch so ein paar NTDS-interne Sachen, die ich leider wieder vergessen habe :( DocData, der TO schrieb von genau einem Server, der zu migirieren sei. Daraus wiederum schloß ich (wohl fälschlich), daß das ein Domain Controller sei und die ganze Domäne eher klein ist. Sonst wäre es nicht nur ein DC. @inet: Wenn das nur ein Member Server ist, dann ist alles, was ich bisher gesagt habe, hinfällig. Aber dazu hast Du von Deiner gesamten Domänenstruktur bisher zu wenig verraten :)

Keine Ursache - ein kaputter DC ist solange kein Problem, solange es noch weitere DCs gibt :)

Dann kommt jetzt Schritt 2: Eventlog "Directory Service" auf allen 3 DCs - Fehler oder Warnungen? Und "repadmin /replsummary".

Genau: https://technet.microsoft.com/library/cc753437.aspx Wobei: Wie groß ist die Domäne? Wenn das überschaubar ist, wäre es eine Alternative, die mit 2012R2 neu aufzusetzen und die bestehenden Computer und Benutzer mit ADMT zu migrieren. Ein AD, das initial mit W2K aufgesetzt wurde, hat ein paar Eigenschaften anders als spätere Generationen - auswendig hab ich das zwar nicht mehr im Kopf, aber IMHO wurde z.B. die Tombstone Lifetime geändert.

Und manchmal - aber nur selten - hat man ganz viel Glück und kann das Problem ändern :D

Sicher, daß das alles 3 wirklich DCs sind? Auf jedem mal ausführen: "dsquery server" und "netdom query dc"... Der erste scheint von den anderen beiden jedenfalls nix zu wissen :)

Na dann - Augen zu und durch: DC01 ausschalten, Metadata Cleanup, neu machen - so wie ich oben schon geschrieben hatte :)

Was steht denn so im Directory Service Eventlog auf den beiden Servern an Fehlern und Warnungen? Ansonsten bei USN-Rollback: srv-dc01 ausschalten, dann Metadata Cleanup auf srv-dc durchführen (alle Reste von srv-dc01 in DHCP, DNS, Sites und Services sowie Benutzer und Computer beseitigen - und alles, was Du vielleicht sonst noch so an Leichen findest :D ). FSMO-Rollen auf srv-dc seizen (warum habt Ihr die verteilt?) Dann srv-dc01 neu aufsetzen. Dürfte keine 2 Stunden dauern - Kopf hoch :)

Firefox hat seinen eigenen Zertifikatsspeicher (wie auch Java), der interessiert sich nicht dafür, was im Windows-Store an CAs drin steht :)