NilsK

Moin, ja, steht doch da: "Diesen Ordner, Unterordner und Dateien". Klapp das Dropdown bei "Anwenden auf" mal auf, dann siehst du den Unterschied, den wir meinen. Gruß, Nils

Moin, In dem Fall dürfte sich IDENTITY doch ohnehin verbieten ... wie sollen verteilte Datenbanken für eine Eindeutigkeit sorgen? Nach meiner Erfahrung werdet ihr sowas kaum befriedigend lösen können, ohne es von Grund auf anzugehen. Gruß, Nils

Moin, jetzt verwirrst du mich endgültig. Vielleicht solltest du noch mal einen Schritt zurücktreten und klären, was du genau vorhast. Da scheinen mir Dinge durcheinander zu gehen. Wenn es nur darum geht, die Werte aus der Quelltabelle beizubehalten, muss die Zieltabelle ja keine Identity-Eigenschaft haben, dann ist das eben eine einfache Wertespalte. Oder übersehe ich da was? Im Detail werde ich dir allerdings auch nicht weiterhelfen können, weil ich kein Developer bin. Gruß, Nils

Moin, ich verstehe die Frage nicht ganz. KeepIdentity sorgt doch, wenn ich es richtig verstehe, dafür, dass beim Bulk-Load die Identity-Spalte der Tabelle von der Quelle übernommen wird. Damit ist das dann eine Eigenschaft der Zieltabelle. Die verschwindet dann natürlich nicht von selbst. Eine Identity-Spalte nachträglich zu ändern, ist nicht ganz einfach, geht aber. Die Frage wäre aber, warum man das tut. Das berührt dann das Datenmodell und sollte gut durchdacht sein. Wäre es evtl. möglich, das Bulk-Copy ohne die Option auszuführen? Gruß, Nils

Moin, "eher vorsichtig umgehen" ist bezogen auf die Physik auch sicher richtig bei Festplatten. Man spielt damit nicht Basketball. Wenn es aber im Betrieb Bedarf gibt, "eher vorsichtig" zu sein, weil der Datenträger sich auffällig verhält, dann rettet man die Daten darauf woanders hin und nimmt das Ding sofort außer Betrieb. Das würde ich privat nicht anders halten als dienstlich. Gruß, Nils PS. Updates zu dem Thema sind aus meiner Sicht unnötig. Dazu gibt es nicht mehr zu sagen. Erkenntnisse sind nicht zu erwarten.

Moin, es klingt in deiner Beschreibung ziemlich deutlich so, dass man das eben nicht sagen kann. Gruß, Nils

Moin, Lecker, Popcorn. Gruß, Nils

Moin, Ich verstehe immer noch nicht, was du mit "überschreiben" meinst. Es klingt allerdings, als sei das Dokument ziemlich vergurkt. Ich fürchte, das kriegen wir hier in einem Forum nicht so beschrieben, dass du damit weiter kommst. Vielleicht ist es am einfachsten, wenn du den Text deines Dokuments in ein neues, leeres Dokument kopierst und dort sowohl das Inhaltsverzeichnis als auch die Kopf-und Fußzeile neu einrichtest. Gruß, Nils

Moin, Was genau meinst du mit ? Gruß, Nils

Moin, Hast du der VM denn vor dem Herunterfahren gesagt, dass du den Snapshot entfernen willst? Gruß, Nils PS. So wichtig ist es dann doch, dass du nach über zwei Monaten mal wieder nachsiehst?

Moin, deshalb schrieb ich das ja. Gruß, Nils

Moin, an dem Hinweis ist was dran, denn Verschlüsselung wird oft missverstanden und noch öfter falsch gemacht. In diesem Fall müsste die Verschlüsselung ja so definiert sein, dass der Angreifer die Daten nicht entschlüsseln kann. Reine Offline-Verschlüsselung (wie wir sie z.B. von Bitlocker oder vom Smartphone kennen) nützt hier nichts, denn wenn die Daten offline wären, käme der Trojaner ja sowieso nicht ran, und wenn sie online sind, besteht normaler Zugriff auf die entschlüsselten Daten. Wenn der Schlüssel nur dem Backup-User zugänglich ist, dann könnte das zumindest vom Schutz der Daten her passen (je nachdem, wie man es dann im Detail macht), aber dann besteht eine hohe Abhängigkeit von diesem User und von dem Speicherort des Schlüssels. Vor allem aber müsste man sich fragen, warum die Verschlüsselung der Backup-Daten verhindern sollte, dass diese Backup-Daten zerstört werden (ob nun gelöscht oder noch mal verschlüsselt, ist ja egal). Und das scheint mir hier der eigentliche Knackpunkt zu sein. Verschlüsselung ist in aller Regel ein nicht-triviales Thema, auch wenn sich das Schlagwort leicht in die Runde werfen lässt. Gruß, Nils

Moin, sowas kann man per Backup und Restore durchaus machen und z.B. über den SQL Server Agent automatisieren. Das hätte den Vorteil, dass man nicht viel Infrastruktur braucht und nicht viel kaputt gehen kann. Der Ablauf wäre recht simpel: Auf dem Produktionsserver einen Task anlegen, der zu bestimmten Uhrzeiten ein Full Backup in eine Datei erzeugt. Diese Datei auf den Auswertungsserver kopieren. Dort einen Task anlegen, der die Datenbank wiederherstellt und dabei die alte Fassung löscht oder überschreibt. Dabei sollte man prüfen, dass dadurch das Backup-System der Produktionsdatenbank nicht durcheinander gerät. Wenn man da mit Differential Backups oder Log Backups arbeitet, muss man die Logik neu bauen. Oder mit einem Copy Only Backup arbeiten, das genau für solche Zwecke gedacht ist. Gruß, Nils

Moin, schon, aber der Fairness halber muss man dazu sagen, dass man das Verfahren kennen muss, um es anzuwenden. Es steht nirgends dabei. Gruß, Nils PS. wäre mal was für faq-o-matic.net, oder?

Moin, das Skript löscht nicht alles, sondern nur das, was älter ist als der Wert unter $days. Der ist mit 2 vorbelegt, was ich je nach Szenario recht knapp finde. Wie weit du mit deinen Logs in die Vergangenheit schauen können willst, müsstest du dir selbst überlegen. Dabei mag auch eine Rolle spielen, ob es überhaupt jemanden gibt, der die Logs interpretieren kann. Gruß, Nils

Moin, dann wird man da wohl auf der logischen Ebene drangehen müssen. Gruß, Nils

Moin, was Norbert meint, ist vor allem: An dieser Stelle ist ein Forum nicht mehr der geeignete Ort. Das muss man sich in Ruhe und im Zusammenhang ansehen. Zum Beispiel kann es durchaus sein, dass DC2 mehr Fehler meldet, weil er nicht die erwarteten Reaktionen von DC1 bekommt. Um das zu identifizieren, braucht man aber Zeit. Die muss ein externer Dienstleister natürlich auch erst mal organisiert kriegen. Gruß, Nils

Moin, verstehe ich richtig, dass du dies hier suchst? [ALTER DATABASE compatibility level (Transact-SQL) - SQL Server | Microsoft Learn] https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-ver16 Gruß, Nils

Moin @schmalz, wir verstehen deinen Frust, aber lasse ihn bitte nicht an denen aus, die dir zu helfen versuchen. Gruß, Nils

Moin, man könnte dir leichter helfen, wenn du mehr Details angäbest. Wir haben keine Ahnung, wie du denn die AD-Gruppe in die lokalen Admins aufnimmst. Wir wissen nicht, was "es funktioniert nicht" genau heißt. Es ist jedenfalls völlig normal, dass geänderte Gruppenmitgliedschaften sich erst auswirken, wenn man sich neu anmeldet. Je nach Mechanismus können auch Neustarts erforderlich sein, wenn es etwa Gruppen angeht, die Computerkonten betreffen. An dieser Stelle hat sich aber zwischen Windows 10 und Windows 11 nichts geändert. Gruß, Nils

Moin, das kann nicht sein. Dann liegt da was anderes im Busch. Wenn du die Adminrecht indirekt vergibst, also per AD-Gruppe, was ist dann bei einem angemeldeten User, der diese Mitgliedschaft hat/haben sollte, im CMD-Fenster die Ausgabe von whoami /groups | find /i "admin" Gruß, Nils

Moin, gibt es den SA-Benefit an dieser Stelle noch, auf den Daniel Melanchthon vor vielen Jahren hingewiesen hat? [Hyper-V Replica: Wie lizenziert man das? | faq-o-matic.net] https://www.faq-o-matic.net/2014/05/12/hyper-v-replica-wie-lizenziert-man-das/ Falls nein, müsste ich den Artikel mal entfernen. Gruß, Nils

Moin, danke für das Feedback. Vermutlich hätte Windows 7 die Meldung des Controllers auf einem physischen Rechner direkt verarbeiten können. In der VM ist der Hypervisor dazwischen, daher kommt das beim Gast-OS nicht an. (Spekulation, kann auch anders sein.) Gruß, Nils

Moin, was du da beschreibst, ist längst nicht alles auf ein USN Rollback zurückzuführen. Da funktioniert offenbar noch mehr nicht. Dann brauchst du dir um USN Rollback auch nicht ganz so viele Sorgen zu machen. Ich würde jetzt zunächst koordiniert versuchen, die vorhandenen Probleme und Fehler einzuordnen und schauen, ob sich die jeweils lösen lassen. Vermutlich sind das zusätzliche Folgen des Ausfalls. Nur wenn das nicht weiterhilft, würde ich prüfen, ob einer der DCs weg muss. Falls ja, einen neuen in die Domäne installieren. Wenn der sich ordentlich repliziert und dann funktioniert, den zu entfernenden DC entfernen. Viel näher kann man das jetzt nicht beschreiben, dazu müsste man es sich vor Ort ansehen, das ist dann nichts für ein Forum. Was das mögliche USN Rollback angeht: Wie gesagt, unwahrscheinlich bei dir. Ob es überhaupt aufgetreten ist, kannst du im Eventlog prüfen: Event-ID 2103 zeigt an, wenn das AD einen USN Rollback erkannt hat. Falls ja, muss das auch erst mal kein Problem sein, das ist es nur, wenn tatsächlich auf beiden DCs Änderungen am selben Objekt erfolgt sind. In dem Fall sollte aber der DC, der in der Meldung als Problem genannt wird, herabgestuft werden. Nicht einfach versuchen, die Replikation wieder einzuschalten. Gruß, Nils

Moin, das ist ja auch beim Hersteller so dokumentiert. Man findet da ne ganze Menge dazu im Web. Gruß, Nils