NilsK

Moin, Ich werfe noch mal Fehler in der Zeitsynchronisation in den Raum. Das kann auch zu sowas führen. Ansonsten wäre es aber gut, wenn wir nicht weiter stochern. Was sagen die Ereignisprotokolle? Scheitert es immer auf denselben Clients? Werden die anderen Einstellungen der GPOs angewendet? Wo ist das GPO verlinkt und wo sind die Benutzerkonten gespeichert? Du sagst, für den Admin funktioniert es, aber dein Screenshot oben zeigt die Ergebnisse für den Admin, wo es ja nicht klappt. Was denn nun? Gruß, Nils

Moin, wirkt denn dein GPO überhaupt auf den Benutzer "Administrator"? Gruß, Nils

Moin, jupp. Das ist der Effekt, den ich in meinem oben bereits zitierten Artikel in dem Abschnitt "Immer rein - kost ja nix!?" beschrieben habe. Aber weil Evgenij ja zu Recht auf die Grenzen dieser simplen Betrachtungen hinweist: Beide hier zitierten Artikel sind über zehn Jahre alt. Sie treffen im Grundsatz immer noch zu, berücksichtigen aber nicht, was sich im Detail in den letzten Jahren getan hat. Und sie sind ausdrücklich nicht für SLA-, Enterprise- oder Spezialanforderungen gedacht. Gruß, Nils

Moin, man muss bei dem Thema immer unterscheiden, von welchen Umgebungen man spricht. Natürlich kann sich CPU-Überbuchung negativ auswirken, sie kann aber auch völlig irrelevant sein. Meine These ist: In vielen realen Umgebungen ist sie irrelevant. Da braucht man sich um die CPU-Last keine Sorgen zu machen. Auf dieser Perspektive beruht meine oft zitierte Darstellung auf faq-o-matic.net. Wohlgemerkt: In vielen Umgebungen, nicht in allen. Es gibt Anwendungen, die CPU-intensiv sind. Da gelten die simplen Betrachtungen dann nicht mehr, da muss man großzügiger dimensionieren oder mit größerem Aufwand messen und entwerfen. Das ist so wie bei allen simplen Betrachtungen - sie gelten eben nur in simplen Fällen. Trotzdem ist mir meine "Passt-schon"-Haltung wichtig, weil ich im Mittelstand und in kleinen Umgebungen oft beobachte, dass sich Admins viel zu viele Sorgen machen, ihre Systeme viel zu groß dimensionieren und viel zu viel Geld, Energie, CO2 usw. aufwenden, wo es gar nicht nötig ist. Immerhin war eine wichtige Idee bei der Virtualisierung mal, Ressourcenverschwendung zu reduzieren. Bezogen auf die Eingangsfrage und deren konkretes Szenario: Das wird kein Problem darstellen. Sollte es tatsächlich in beiden VMs Tasks geben, die gleichzeitig alle vier vCPUs voll und dauerhaft auslasten, dann wird es sich ggf. negativ bemerkbar machen. Sonst nicht. Gruß, Nils

Moin, ich wage mal zu behaupten, dass für irgendwelche konkreten Empfehlungen hier bei weitem nicht genügend Informationen vorliegen. @Hajo2004 es klingt so, als seien viele Rahmenbedingungen mit dem Kunden noch gar nicht geklärt. Das ist aber unabdingbar, bevor man überhaupt anfangen kann, konzeptionelle Ideen zu entwickeln. Wenn der Kunde z.B. gar nicht über SCCM verfügt, dann dürften Beschaffung und Einrichtung bei so einer Umgebung für so ein Vorhaben viel zu teuer und langwierig sein. Gruß, Nils

Moin, oder um es einfach mal positiv und deutlich auszudrücken: Da liegt ein Missverständnis vor. SMTP Auth wird nicht abgeschaltet. Die angekündigte Änderung bezieht sich auf den Web-Zugriff. Gruß, Nils

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