NilsK

Moin, ich gehe sogar noch weiter und sage: Der TO sollte über einen zweiten DC nachdenken. Ernsthaft: Bei 77 Usern ist ein DC viel zu wenig. Sobald es zweistellig wird, ist ein einzelner DC zu wenig. Warum, das siehst du ja jetzt. Die Logs, in denen sich sicher was findet, sind das System Log, das Application Log und unterhalb von "Dienst- und Anwendungsprotokolle" die Verzeichnisdienste (je nach Sprache auch "Directory Service"). Parallel kannst du in einem CMD-Fenster mit Adminrechten noch mal dies ausführen und uns sagen, welche Fehler dort gemeldet werden: dcdiag > C:\Pfad\dcdiag.txt Gruß, Nils

Moin, wie groß ist das Netzwerk? Wie du jetzt gerade siehst, kann ein einzelner DC zu wenig sein. Die Problemlage sollte sicher Spuren im Eventlog hinterlassen. Was sagt das denn dazu? Gruß, Nils

Moin, doch, es gibt solche Tools. Sind aber teuer, sehr teuer. Wir haben uns vor Jahren mal LinkFixer von LinkTek angesehen, es aber nie eingesetzt, weil die Kunden es nicht bezahlen wollten und es dann ganz magisch auch ohne ging. Gruß, Nils

Moin, auch diese Eigenschaft löst aber das Problem nicht, dass eine verschobene Datei (selbes Volume) ihren Zeitstempel behält. Es lässt sich an solchen Daten nun mal nicht zweifelsfrei ablesen, wann eine Datei in einem Ordner aufgetaucht ist. Gruß. Nils

Moin, https://en.wikipedia.org/wiki/List_of_RAM_drive_software Die Starwind-Software kenne ich nicht persönlich, aber zumindest ist der Hersteller seriös und leistungsfähig. Erfordert allerdings eine Registrierung. Gruß, Nils

Moin, die ActiveSync-Einbindung als solche lässt nicht zu, dass ein Admin der Firma an die privaten Daten des Telefons herankommt. Je nachdem, wie gut oder wie fehlerhaft die Einbindung auf dem Gerät softwareseitig gemacht ist, kann es aber passieren, dass ein RemoteWipe auch seine privaten Daten löscht. Sollte zwar heute eigentlich nicht mehr so sein, ist aber alles schon dagewesen. Gruß, Nils

Moin, hier bist du an einer Stelle, die sich mit einfachen Mitteln kaum sinnvoll lösen lässt. Man könnte jetzt darüber sinnieren, dass es einen Unterschied gibt, ob eine Datei an das Ziel kopiert wurde oder ob sie dorthin verschoben wurde (was hier vermutlich die Ursache ist). Danach wird man aber wahrscheinlich den nächsten Punkt finden. Die Mechanismen des "rohen" Dateisystems sind oft ungeeignet, um darauf Workflows von geschäftlicher Bedeutung abzubilden. Vielleicht ist hier ein grundsätzlich anderes Vorgehen empfehlenswert. Gruß, Nils

Moin, können wir bitte sachlich bleiben? Danke. Gruß, Nils

Moin, Das mit dem DHCP ist ... so mittelzuverlässig. Gruß, Nils

Moin, ein Skript, das das Konto und den DNS-Record löscht? Gruß, Nils

Moin, nein, wenn der Rechner nicht online ist, geschieht gar nichts. Einfach aus dem Grund, dass es der Client ist, der das Kennwort neu setzt. Ginge ja auch kaum anders. [Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht! | Aktives Verzeichnis Blog] https://blogs.technet.microsoft.com/deds/2009/01/20/wann-luft-ein-maschinenaccount-computerkonto-ab-gar-nicht/ Gruß, Nils PS. ... ach ja, Fabian ... der war auch schon lange nicht mehr hier.

Moin, wobei sich der Prozess ja leicht so erweitern ließe, dass beim Löschen des Computerkontos auch der DNS-Eintrag ausdrücklich gelöscht wird. Intuitiv erschiene mir das logischer und sinnvoller als ein Workaround mit dem Wiederverwenden des Kontos. Die Client-Installation hat ja auch lokal eine andere Identität (lokaler SID). Am Ende akademisch, wie du schon sagst. Wichtig ist, dass man seine Prozesse im Griff hat. Gruß, Nils

Moin, ich verstehe ehrlich gesagt den Grund der Frage nicht, weil mir das Ziel der Vorgänge unklar ist. Warum würde man in dem Szenario überhaupt das Computerkonto weiterverwenden? Es geht doch um Clients? In wie vielen Gruppen werden die schon Mitglied sein? Und "ziehen" muss der Client die GPOs sowieso, er wurde ja neu installiert. Gruß, Nils

Moin, wenn du die Domäne löschst, werden auch deren Informationen aus dem Global Catalog entfernt. Dann dürfte der Spuk ein Ende haben. Gruß, Nils

Moin, wozu das Ganze? Brauchst du die CA als solche oder nur Zertifikate? Falls es um die CA geht, dann mach es lieber richtig und installiere eine Windows-Root-CA und eine Windows-Sub-CA. Das ist am besten dokumentiert und du kannst sicher sein, dass das Nötige im CSR und den Zertifikaten steht. Falls du nur Zertifikate brauchst, dann nimm selbstsignierte oder bau dir was Kleines mit OpenSSL oder so. Gruß, Nils

Moin, Weg damit. Die Root aufzuräumen, wird geringer Aufwand sein. Gruß, Nils

Moin, auf die Schnelle habe ich leider keine Lösung für das CRL-Problem. Aber ein wichtiger Hinweis: Für dein Szenario ist das Sperren des Zertifikats i.d.R. nicht der richtige Weg bzw. das reicht nicht aus. Da eine Sperrliste immer eine Laufzeit hat, wird das Sperren eines Zertifikats immer eine längere Verzögerung bedeuten. Möchtest du einen Zertifikatsinhaber schnell aussperren (was hier ja das Szenario zu sein scheint), musst du das primär auf anderem Wege tun, also meist das Zugangskonto selbst sperren. Nur so sorgst du für eine schnelle Wirkung. Zu der Fehlermeldung gibt es eine Reihe von Fundstellen im Web, geh die mal durch. Manchmal sind es simple Dinge wie ein falscher Authentifizierungsmodus auf dem Webserver. Gruß, Nils

Moin, der Namenskontext ist hier der LDAP-Name der Domäne. Siehe das letzte Beispiel von "repadmin /removelingeringobjects /?". Gruß, Niös

Moin, ja, Microsofts Support arbeitet da wie viele andere Supportorganisationen. Anleitungen zur Ersteinrichtung bekommt man nicht. Manchmal ärgerlich, aber letztlich legitim. Welche Pfade stehen denn im Zertifikat für die Sperrliste? Ist auch ein OCSP-URL hinterlegt? Möglicherweise arbeitet die Abfrage aus der Serverkomponente anders als die von certutil. Gruß, Nils

Moin, Wenn du Anforderungen dieser Art hast, solltest du dir eine echte Softwareverteilung anschaffen. GPOs sind damit zu schnell überfordert. Gruß, Nils

Moin, Ist supported. Eine Quelle kann ich dir aber nicht nennen. Gruß, Nils

Moin, ich erwähne noch mal robocopy und dessen Auswahl-Syntax ... Gruß, Nils

Moin, aber nur wenn man Äpfel mit Birnen vergleicht. Office 365 ist ja eine ganze Menge mehr als ein Office-Paket und eine Exchange-Mailbox. Rein technisch betrachtet sollte es so gehen. Gruß, Nils

Moin, also ... wenn man ein Zertifikat mit Private Key verteilt, ist das schon mal ausgesprochen seltsam. Ein Private Key ist per definitionem privat, d.h. er hat einen (einen einzigen!) Rechner niemals zu verlassen. Verteilen eines Private Keys geht gar nicht. Wenn man dann aber auch noch das Kennwort dazu im Klartext in ein Skript packt, dann hebelt man jedes Fitzelchen Sicherheit aus, das sich mit dem Zertifikat vielleicht erzeugen ließe. Entweder liegt hier also ein gravierendes Missverständnis vor, wie man die Installation dieser Software durchführt. Oder der ganze Sicherheits-Ansatz ist so kaputt, dass man diese Software nicht einsetzen sollte. Gruß, Nils

Moin, ach der. Ja, auch der liefert nicht in jedem Fall Gold-Qualität. Gruß, Nils