NilsK

Moin, sehr gern und vielen Dank für die Rückmeldung. Gruß, Nils

Moin, und zum Weiterlesen: [Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/ (da steht genau dein Thema drin) [Benutzerkontensteuerung (UAC) richtig einsetzen | faq-o-matic.net] https://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ Gruß, Nils

Moin, deine Suchmaschine ist kaputt? [Uninstall an existing instance of SQL Server (Setup) - SQL Server | Microsoft Learn] https://learn.microsoft.com/en-us/sql/sql-server/install/uninstall-an-existing-instance-of-sql-server-setup Im Wesentlichen: Deinstallieren. SQL Server greift nicht so tief ins System ein wie ein Virenscanner und braucht daher keinen großen Aufwand. Gruß, Nils

Moin, meiner Kenntnis nach entfernt rd nicht nur den Inhalt, sondern eben den Ordner selbst. Du hättet danach also kein temp-Verzeichnis mehr. Das ist ja nicht das, was du willst. Vermutlich kommt da auch die Fehlermeldung im Screenshot her. Man findet im Web Skripte, die nach dem Löschen das Verzeichnis einfach wieder neu erzeugen. Ob das ein brauchbarer Weg ist, weiß ich nicht. In den Umgebungen, in denen ich damit zu tun hatte, wurde das automatische Löschen meist nach kurzer Zeit wieder aufgegeben, weil es zu viele Nebenwirkungen hatte. Gruß, Nils

Moin, falls das Skript der Originaltext ist, könnte es daran liegen, dass es das Kommando "re" in der Shell nicht gibt. Und falls du "rd" meinst, versuchst du erstens das Falsche (du willst ja den Inhalt löschen, nicht das Verzeichnis selbst) und verhinderst es dadurch, dass du in der Zeile vorher in das Verzeichnis gewechselt bist. Gruß, Nils

Moin, du Glücklicher! Gruß, Nils

Moin, nein, kein Urlaubsflieger, sondern eine Metapher, weil Evgenij und ich uns immer um das Thema "CPU in Virtualisierungshosts" kabbeln. Der Flieger steht hier für die CPU-Ressourcen, die bei Überbuchung halt irgendwann am Ende sein können. Und es geht nicht um einen File-Cluster, sondern um Hyper-V. Steht im ersten Post. Gruß, Nils

Moin, ge-nau. Endlich siehst du es ein. Gruß, Ni"wie, der Flieger ist voll?"ls

Moin, ein Storage, das zu 80 Prozent gefüllt ist, muss aber ohnehin erweitert oder erneuert werden. Der Cluster macht das unabdingbar, nötig wäre es auch ohne. Das ist ja eine Grundeigenschaft solcher Systeme, die sehr gern ignoriert wird: Man wird die nie auslasten, man braucht immer einen erheblichen Anteil an Reserve. Egal ob es um Storage geht, um ein RZ, um RAM, um <hier Element einsetzen>. Gruß, Nils

Moin, wenn sowas auftritt, hast du sowieso ein Problem. Dann ist entweder die Umgebung in einem Zustand, in dem man gar nicht über "Protected Users" nachdenken muss, oder es ist ein Recovery-Fall, wo man auch nicht darüber nachdenken muss, weil nur noch der DSRM hilft, wie Norbert schon sagt. Gruß, Nils

Moin, was uns zur Mother of all Consulting-Antworten führt: Kommt drauf an. Gruß, Nils

Moin, "Full Ack" zu Evgenijs Darstellung. Und ergänzend: Aus dem Gesagten folgt, dass das Konstrukt in den meisten Umgebungen nur für einen Teil der privilegierten Konten taugt. Das wiederum hat zur Folge, dass man in solchen Umgebungen die Privilegien gut auf Konten (bzw. eher: auf Rollen) aufteilen sollte, damit der Schutz funktionieren kann. In a nutshell: Wenn die Fälle a, b oder c aus Evgenijs Liste vorkommen, dann sollten diese nicht an Konten gebunden werden, die sonst auch sehr hohe Privilegien haben. Auf die Weise könnte man dann die Accounts, die a, b und c nicht brauchen, über die Gruppe schützen. Ob das in einer bestimmten Umgebung umsetzbar ist, ist dann zu prüfen. Gruß, Nils

Moin, Wow, Reader's Digest für Nerds. Vielen Dank. Gruß, Nils

Moin, also sprechen wir nicht von 10 GB (das hatte ich für eine Dateigröße gehalten), sondern von 10 Gbit. Was spricht gegen einen Client mit einer 10-Gbit-Karte? Für den Zweck braucht man ja keinen "Host". Immerhin ist USB ja auch alles andere als eine Servertechnik. Gruß, Nils

Moin, wenn es "hin und wieder" ist, was spricht dagegen, die USB-Platten an deinen Client anzuschließen und von dort aus zu kopieren? Gruß, Nils

Moin, zum Weiterlesen an dieser Stelle vielleicht hilfreich: [Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net] https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ sowie noch weiter ausgreifend: [Windows-Gruppen richtig nutzen | faq-o-matic.net] https://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Und nie-nie-niemals den Assistenten nutzen. Gruß, Nils

Moin, mit dem IIS machen sie Geld in großem Stil. Mit SMTP als Einzeldienst geht das nicht, da kann man eigentlich nur Dinge verkehrt machen. Da würde ich mir also keine allzu großen Hoffnungen machen. Gruß, Nils

Moin, Ah, okay. Dann nehme ich alles zurück und behaupte das Gegenteil. Gruß, Nils

Moin, Das passt jetzt aber nur sehr begrenzt zum Thema, weil ein Startscript vor der Anmeldung läuft und daher gar keine Gruppen ausgewertet werden können. Gruß, Nils

Moin, was ist denn das Ziel des Netzlaufwerks? Ist das eine einzelne Freigabe, in der die Ordner dann "physisch" liegen? Oder ist es ein DFS-Ordner und die Unterordner sind Links auf separate Freigaben, die woanders liegen? Gruß, Nils

Moin, ah, siehste, gut, mal etwas zu suchen. Also anscheinend ein Performanceproblem und eine Besonderheit im VSS-Algorithmus, die in solchen Situationen den Platz innerhalb der Reserve "gewaltsam" freigibt, wenn die Allokation von zusätzlichem Speicher zu lange dauert. Wusste ich auch noch nicht. Es gilt wie so oft: VSS ist ein Komfortfeature, kein Restore-Feature. Gruß, Nils

Moin, das Grundprinzip ist schon so. Aber deine Angaben lassen jetzt eben nur Vermutungen zu. Eine davon ist, dass jemand gelöscht hat. Ins Eventlog hast du schon geschaut? Veeam hast du kontrolliert, ob da nicht "uneigentlich" etwas geändert wurde? Ich kenne Veeam nicht in diesem Detailgrad, aber da es natürlich mit Schattenkopien zu tun hat, kann es an dem Phänomen auch beteiligt sein. Daher wäre es schon relevant, ob da was geändert wurde. Einfach so von selbst wird es ja sein Verhalten nicht ändern - also entweder eine Konfigurationsänderung oder ein Fehler. In letzterem Fall könnte man mal schauen, ob es weitere Spuren gibt, etwa in Logs. Gruß, Nils

Moin, und passt jetzt nur so mittelgut zusammen. Zusammengefasst hast du eine Vermutung, dass was nicht stimmt, aber keinen Beleg dafür - richtig? Dann könnte es mit der Fehlersuche jetzt schwierig werden. Könnte es sein, dass jemand die Kopien ausdrücklich gelöscht hat? Gruß, Nils

Moin, deine Angaben sind jetzt nicht besonders umfassend. Wie spielt Veeam denn bei dem Dateiserver rein? Hast du an der Veeam-Konfiguration etwas geändert? Gruß, Nils

Moin, das ist ja auch kein DOS. Gruß, Nils