NilsK

Moin, Wenn man das Szenario nicht kennt, ist es schwierig, einen zielführenden Hinweis zu geben. Du könntest schauen, ob du beim Server den Button zum Neustarten auf dem Login-Bildschirm einblenden kannst. Das sollte sich per Policy einstellen lassen: http://www.winfaq.de/faq_html/Content/tip0000/onlinefaq.php?h=tip0173.htm Gruß, Nils

Moin, Du hast nicht dein Ziel beschreiben, sondern nur die Details wiederholt, die schon bekannt sind. Wozu brauchst du diesen Account? Gruß, Nils

Moin, schön, dass du eine Lösung hast. Wenn du uns nächstes Mal sagst, was denn eigentlich die Anforderung hinter deiner Frage ist, können wir dir wahrscheinlich mit passenderen Vorschlägen helfen. Gruß, Nils

Moin, ja, das entspricht ja dem, was wir gesagt haben und auch dem, was in dem verlinkten Artikel steht. Wo siehst du jetzt einen Widerspruch? Gruß, Nils PS. du meinst "fragmentiert". ;)

Moin, das klingt erst mal nach einem Sperrkonflikt. Du könntest dir mit sp_who oder im Management Studio mal ansehen, wer noch mit der Datenbank verbunden ist. Vielleicht ist in einer der Sessions ein Lock auf die Tabelle oder Teile davon gesetzt. Gruß, Nils

Moin, da hast du natürlich völlig recht. Für mich klang die Anfrage des TO nach dem ersten Einstieg in so ein Thema, aber möglicherweise steckt ja mehr dahinter. Ich deklariere meine vorige Antwort also um, sie ist nur für einfache Fälle gültig. Für höhere Anforderungen sollte man auf eine moderne indirekte Architektur setzen, wie von @mwiederkehr skizziert. Gruß, Nils

Moin, Typischerweise geht das so: bei der Installation der Software gibt man an, welches der Datenbankserver ist. Hier erfolgt dann einmalig eine Anmeldung mit passenden Rechten, um die Datenbank anzulegen. Wenn dann ein Anwender mit der Software arbeitet, zeigt ihm diese ein Anmeldefenster, mit dem er sich mit seinen eigenen Account bei der Datenbank anmeldet. Die Software speichert also normalerweise nur, um welchen Server es geht. In vielen Frameworks zur Softwareentwicklung sind die Funktionen für sowas auch schon vorhanden. Gruß, Nils

Moin, die Hintergrundfragen habe ich hier mal ausführlicher beleuchtet: [SQL Server: Wie Datenablage, Backup und Recovery funktionieren | faq-o-matic.net] https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

Moin, Wenn man regelmäßig richtige Backups macht, wächst das Log normalerweise gar nicht so groß an. Aber im Wesentlichen ist die Antwort Ja. https://www.faq-o-matic.net/2014/08/27/sql-server-transaktionsprotokoll-verkleinern/ Gruß, Nils

Moin, die Tage hab ich einen prima Spruch von Olaf Schubert gehört: Wenn zwei Leute loslassen, ist es besser, als wenn du anfasst. Gruß, Nils

Moin, um wie viele Dateien geht es (-zig, hunderte, tausende)? Wie viele unterschiedliche Ordner sind zu erwarten? Soll das einmalig sein oder mehrfach/regelmäßig? Falls es sich wirklich lohnt, das per Skript zu machen, sollte man es per PowerShell tun. Mit Batch wird man sich da ziemlich einen abbrechen. Gruß, Nils

Moin, Dazu wird dir ein Anwalt was sagen können. Hierzulande darf das auch niemand sonst. Intuitiv würde ich sagen: hängt vom Vertrag ab, den ihr abschließt. Gruß, Nils

Moin, man könnte aber auch einfach einen ausgemusterten, aber funktionierenden PC hernehmen. Gruß, Nils

Moin, der beschriebene Workaround manipuliert die Angabe, welcher User als letzter angemeldet war. Das ist exakt ein User, nicht mehrere. Dein Skript würde diesen Eintrag setzen und ihn dann dreimal überschreiben, sodass in deinem Beispiel nur "User4" dort stände. Was dir vorschwebt, ist nicht umsetzbar. Gruß, Nils

Moin, danke für die Rückmeldung. Es war uns eine Ehre. Gruß, Nils

Moin, dann kann man sie ignorieren. Das AD startet einfach vor dem DNS-Server, dann laufen die Anfragen ein paar Momente ins Leere. Ließe sich beheben, wenn du einen zweiten DC/DNS hättest, was bei dem kleinen Netz aber vielleicht übertrieben wäre. Also sind wir durch. Gruß, Nils

Moin, wenn ich es richtig verstehe, tritt das Phänomen nur bei dem einen Server auf, bei anderen Rechnern nicht. Weitere Fehler scheint es auf dem Server auch nicht zu geben. Ist es denn so wichtig, dass dieser Vorgang auf diesem Server beim ersten Mal geht? Oder ließe sich das auch einfach anders machen? Ich meine, das ist ja auch irgendwann eine Frage der Effizienz. Gruß, Nils

Moin, und der DC und alle Server und Clients haben ausschließlich den DC als DNS-Server eingetragen? Die Fehlermeldungen stammen aus dem laufenden Betrieb, d.h. nicht direkt nach dem Neustart des DCs? Gruß, Nils

Moin, diese Information solltest du gleich geben. Bei der ersten Erwähnung klang es, als würde das grundsätzlich nicht funktionieren. Hier ist das Problem also sehr wahrscheinlich bei dem einen Client bzw. dem einen Computerkonto zu suchen, nicht allgemein. Insbesondere den Verdacht, das AD sei irgendwie inkonsistent, können wir getrost begraben (oder zumindest in den Warteraum schieben - es ist ausgesprochen unwahrscheinlich). Und, hast du die Stunde jetzt investiert? Gruß, Nils

Mom, Wir lange würde es denn dauern, das "große" GPO neu zusammen zu klicken? Eine halbe Stunde? Eine ganze? Gruß, Nils

Moin, Wenn neue GPOs funktionieren, würde ich bei nur sechs Objekten insgesamt nicht mehr lange fackeln ... Gruß, Nils

Moin, Bitte gewöhne dir an, mit Schlussfolgerungen zurückhaltender zu sein. Wie sicherst du deine DC-VM? Sinnvoller wäre, du würdest das AD per System State sichern, das hilft dir dann auch, wenn es gar nicht darum geht, den DC wiederherzustellen. In diesem Moment etwa würde dir eine separate AD-Sicherung wahrscheinlich mehr helfen als ein ganzer DC. Ist momentan aber Essig, es gibt ja kein Backup. Wir gesagt, ich kann das jetzt nicht mehr in der Tiefe supporten. Was ich jetzt prüfen würde: - sind wirklich die GPO-Dateien noch da oder nur die Ordner? -kannst du die GPOs zum Bearbeiten öffnen? - wenn du ein neues GPO anlegst, funktioniert dies dann auf dem Client? - wenn du von einem bestehenden GPO den Link entfernst und es dann neu verknüpfst, geht es dann? - wenn du einen Client aus der Domäne nimmst und neu hinzufügst, geht es dann? (Alternativ einen ganz neuen Client, etwa eine neue VM.) Gruß, Nils

Moin, nur damit wir uns richtig verstehen: Was genau hast du da nachgesehen? Um wie viele Clients handelt es sich denn? Und um wie viele GPOs? Für weitergehenden Support fehlt mir im Moment die Zeit. Meine Einschätzung ist aber: Du hast gar kein großes Problem, nur ein lästiges. Ein Backup deines AD hast du jetzt doch hoffentlich eingerichtet, oder? Gruß, Nils

Moin, das ist mir schon klar. Die Frage ist aber: gibt es außer den GPO-Sachen noch weitere Fehler oder Probleme auf dem DC? Wenn ja, welche genau? Was ist denn mit dem DC passiert? Ist das so? Wäre eher untypisch. Hattest du denn auch die Fehlermeldung, die in dem Artikel genannt wird? Dahinter liegt eine eher mystische Vorstellung von der Replikation, die oft anzutreffen ist. "Schäden auf einem DC" replizieren sich aber nicht. Das AD repliziert Daten, sehr vorhersagbar. Künftig sei also empfohlen, dass du dir früher Unterstützung suchst, statt einfach was auszuprobieren. So, jetzt nähern wir uns mal dem Problem. Sind denn die Gruppenrichtlinienobjekte im AD und auf dem DC vorhanden? Das prüfst du einerseits in der GPMC (gpmc.msc aufrufen) und zum anderen im Dateisystem im SYSVOL (%logonserver%\sysvol\%userdnsdomain%\Policies aufrufen). Sind die erwarteten Objekte da? Die weiteren Eventlog-Meldungen kannst du erst mal ignorieren. An den Time Service und die DFS-Replikation solltest du später mal ran, aber erst mal schauen wir, was mit den GPOs los ist. Gruß, Nils

Moin, willkommen an Board! Auch wenn dein Problem dich stresst (was ich verstehe), solltest du dich um genaue Beschreibungen bemühen. Es wird sonst unnötig umständlich. Welches sind diese "extremen Probleme"? Weiter unten gibst du an, dass eigentlich alles geht, bis auf die GPOs. Ist da nun noch mehr im Busch oder nicht? Der DSRM ist im Wesentlichen dafür da, das AD aus einem Backup wiederherzustellen. Da du das offenbar nicht getan hast, was hast du denn dort genau gemacht? Von solchen Schnellschüssen solltest du künftig Abstand nehmen. Einen neuen DC hinzuzufügen, ist erst mal OK, aber den alten zu entfernen, solange noch Probleme bestehen, war u.U. voreilig. Eine Lüge wäre ja eine absichtliche Fehlinformation. Ich glaube nicht, dass Windows dich anlügen will, sondern denke eher, dass es aus seiner Sicht Recht hat. Die Frage wäre also eher, warum Windows versucht, den SPN zu registrieren, wenn er doch anscheinend da ist - und warum das fehlschlägt. Da der SPN ja aber anscheinend da ist, kann man dieses Problem vermutlich zunächst ignorieren. Zu den anderen Events müsstest du bitte mal angeben, was dort steht. Hier wird niemand die IDs im Kopf haben. Was führt dich zu dieser Aussage? Was versuchst du genau, und was passiert dann? Weiter oben schreibst du, dass die Clients die GPOs sehr wohl erhalten, aber nicht anwenden. Hier müssten wir jetzt also erst mal klären, was denn genau das Problem ist. Auch diese Schlussfolgerung scheint mir etwas voreilig zu sein. Wenn der Dienst dort nicht auftaucht, dann hat er keine Berechtigungen. Und damit könnte das Problem durchaus das sein, das in dem Artikel beschrieben wird. Wenn es auch weiterhin nicht geht, müsste man noch mal prüfen, was du dort denn genau gemacht hast; an der Stelle kann man durchaus auch unabsichtlich falsch vorgehen. Also schau doch mal, ob du die fehlenden Informationen nachliefern kannst. Gruß, Nils