NilsK

Moin, nö, works as designed. Das Schreibschutz-Attribut verhindert, dass Inhalte der Datei geändert werden. Das dürfte auch funktionieren. Ein Löschen der Datei verhindert man damit nicht, hat man auch noch nie. Du müsstest also mit Berechtigungen arbeiten. Gruß, Nils

Moin, also was denn nun? Ist das ein eigenes Volume auf dem RAID, das in Windows als separates Laufwerk angezeigt wird, parallel zu dem Laufwerk, wo das System startet? Oder ein nicht zugewiesener Speicherbereich hinter einer Partition auf demselben Laufwerk wie die C-Partition? Gruß, Nils

Moin, schon neu gestartet? Vielleicht hängen noch Updates. Warum partitionierst du überhaupt? Das versucht man eigentlich eher zu vermeiden. Gruß, Nils

Moin, erteile auf der übergeordneten Freigabe nur das Recht "Ändern", nicht "Vollzugriff". Dann können Benutzer die Berechtigungen auf keinen Fall ändern, auch wenn sie Besitzer sind. [Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net] http://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/ Dort insbesondere ganz unten unter "Die eine Ausnahme". Gruß, Nils

Moin, oha, konfigurierst du immer einfach so an Diensten herum? :nene: "Netzwerkdienst" wäre ein gültiger Wert. Dafür brauchst du kein Kennwort. Das ist ein Konto, um einen Dienst mit möglichst wenigen Rechten auszustatten. Ich habe keinen solchen Dienst parat, um abzugucken. Auf keinen Fall einfach mal so irgendwo einen Domänen-Admin eintragen! Schon "Local System" ist oft völlig überberechtigt. Gruß, Nils

Moin, http://www.sqlcoffee.com/Troubleshooting005.htm Dementsprechend wäre das normal. Gruß, Nils

Moin, oh, tatsächlich, dein Code scheint auch zu funktionieren. Ich hätte angenommen, dass das bei Multivalue-Feldern logisch nicht hinhaut. Wenn du nur die Namen haben willst, dann häng noch | ft name -HideTableHeaders an. Gruß, Nils

Moin, wenn du nachträglich wesentliche Parameter deiner Frage änderst, passen natürlich die Antworten nicht mehr ... es macht einen großen Unterschied, ob du die eigene oder eine andere Domäne abfragst. Mein Codebeispiel filtert überhaupt nicht. Es geht mit dem Holzhammer hin und liest einmal alle AD-User und zum anderen alle Mitglieder der Gruppe aus. Diese beiden Objekte vergleicht es. Einen Filter "ist nicht Mitglied" gibt es nicht. Was die Codezeile anbelangt, nach der du fragst: Nein, eigentlich müsste recht schnell der normale Prompt wieder erscheinen. Vermutlich hast du den Code aus dem Browser kopiert, dabei gehen manchmal die falschen Sonderzeichen rüber. Tipp das Kommando mal manuell ein, dann sollte es gehen. Gruß, Nils

Moin, Folgendes scheint zu funktionieren: $Members = (Get-ADGroup 'Meine Gruppe' -Properties member).member $Users = Get-ADUser -Filter * Compare-Object -ReferenceObject $Users -DifferenceObject $Members | Where-Object {$_.SideIndicator -eq '<='} Könnte allerdings bei einer sehr großen Domäne viel RAM brauchen. Gruß, Nils

Moin, das können wir für deine Situation schlicht nicht beantworten. Aber da, so wie du es beschreibst, kein großes OS nötig ist, haben wir ja die Thinclient-Lösung vorgeschlagen. Die würde exakt deine Anforderungen erfüllen. Du wirst Windows 10 nicht so "vernageln" können, wie es dir vorschwebt. Von den Kosten mal ganz abgesehen. Also als letzter Vorschlag: Installiert einen weiteren Terminalserver für Office und Firefox. Thinclients können Applikationen von mehr als einem Server nutzen. Gruß, Nils

Moin, daher ja unser Vorschlag: Die Sekretärin bekommt keinen PC, sondern nur einen Thinclient. Der verbindet sich mit dem Terminalserver, wo die Sekretärin das Haushaltsprogramm, Office und den Browser zur Verfügung hat uns sonst nichts. Eigentlich passt das wie die Faust aufs Auge. Gruß, Nils

Moin, und was spricht gegen ADMT? Gruß, Nils

Moin, was und wie wird denn da migriert? Wäre es nicht evtl. einfacher, die Gruppen direkt zu migrieren, statt sie zu exportieren und neu zu erzeugen? Gruß, Nils

Moin, ja. Gruß, Nils

Moin, das ist aber ein Problem der Tools, nicht von NTFS. Leider sind die Bordmittel an der Stelle ja nicht wirklich besser geworden. Gruß, Nils

Moin, ich kann es nicht belegen, aber ich meine, dass das nicht zutrifft. Soweit ich weiß, war das Berechtigungssystem inkl. Vererbung schon in der NTFS-Version 1 enthalten (kam mit NT 3.1, also der ersten Version), und tatsächlich werden die ACLs auch nicht pro Objekt gespeichert. sondern in einer Art verteilten Datenbankstruktur. Ich habe aber leider nicht genug Zeit, das nachzurecherchieren. EDIT: Jetzt habe ich doch eine Quelle gefunden: http://www.pcguide.com/ref/hdd/file/ntfs/secInherit-c.html Die Darstellung dort untermauert deine Aussage teilweise: Demnach hatte NTFS 1.1 (NT4; vermutlich auch 1.0, aber das steht da nicht) nur statische Vererbung (wurde nur beim Erzeugen einer Datei einmalig gesetzt), und dynamische Vererbung kam mit NTFS 2.0 (Windows 2000 bzw. NT SP4) dazu. In der Tat erinnere ich mich, dass das SP4 damals einiges änderte und dass man auf NT-Rechnern SP4 brauchte, wenn man auf Windows-2000-NTFS-Partitionen zugreifen wollte. Allerdings ist das hier nur funktional beschrieben, die Datenstrukturen sind, meine ich mich zu erinnern, technisch nicht ganz so simpel, wie dort angedeutet wird. Wobei man aus dem Text durchaus rauslesen kann, dass die Berechtigungen eben nicht für jedes Objekt gespeichert sind, sondern bei jedem Zugriff geprüft werden müssen. Ist aber am Ende auch egal. Ändert nämlich nichts am Problem. :D Gruß, Nils

Moin, ja, die Anforderung trifft man bisweilen an. Mein Stand ist, dass es da keine wirklich schöne Lösung gibt. Der Client-Workaround (der je nach Windows-Version mal funktioniert, mal nicht) setzt voraus, dass die User Berechtigungen ändern dürfen. Ist das nicht gegeben, dann greift die Logik des Dateisystems (bzw. es bleibt dabei). Es gibt wohl Leute, die regelmäßig Skripte abfeuern, um die Berechtigungen zurückzusetzen. Das ist aber keine schöne Lösung, weil sehr ressourcenintensiv und nicht zuverlässig. Manchen Kunden reicht es in der Praxis auch, es so hinzunehmen, wie es ist, und in nötigen Fällen (die dort eher selten auftreten) manuell zu korrigieren. Gruß, Nils

Moin, das einzige, was ich für Berechtigungen empfehlen kann, ist SetACL von Helge Klein. Für einzelne Aufgaben auch der große Bruder SetACL Studio, der mittlerweile kostenlos ist. Gruß, Nils

Moin, ja. Sinnvollerweise läuft der Copyjob direkt auf dem Windows-Server, nicht auf einem dritten System, damit die Daten nicht zweimal durchs Netz müssen. Während des Kopiervorgangs sollte der Virenscanner abgeschaltet sein und vor dem Zugriff durch die User dann alles scannen. Gruß, Nils

Moin, angesichts der Anforderungen würde ich wie Norbert auch zu einem Terminalserverkonzept mit Thin Clients raten. Anders wird das sehr viel Aufwand und ist schnell im nicht supporteten (und nicht zuverlässigen) Bereich. Gruß, Nils

Moin, solange du nicht angibst, um was für ein Storage-Gerät es sich handelt, wird niemand was Erhellendes dazu sagen können. Gruß, Nils

Moin, ich hoffe, dass du die Firewall nach der Ersteinrichtung nicht deaktiviert lässt. Wenn sie aber abgeschaltet ist, blockiert Windows zumindest auf Netzwerkebene nichts. Das Problem dürfte dann woanders liegen. Bei SQL Server gibt es beispielsweise eine separate Konfiguration, bei der man den Remotezugang erst einschalten muss. Vielleicht hat Oracle sowas ja auch. Gruß, Nils

Moin, eine Websuche nach "active directory remove orphaned domain" sollte erst mal ausreichend Annäherung geben. Alles Weitere wäre aus meiner Sicht nicht für ein Forum geeignet. Gruß, Nils

Moin, niemand streitet ein Risiko ab. Aber zwischen "Risiko" und "Schaden" besteht nun mal ebenso ein Unterschied wie zwischen "Wahrscheinlichkeit" (oder wenn du willst: likelihood) und "Tatsache" (fact). Es ist durchaus möglich, dass das System kompromittiert ist. Der Beschreibung nach ist aber zunächst nicht zu erwarten, dass der Server etwa direkt vom Internet aus erreichbar ist. Ebenso gibt es keine Hinweise, dass jemand interne Angriffe ausgeführt hat - was auch sein könnte, aber nun mal wenig wahrscheinlich ist. Genau wie wir sonst in diesem Forum uns oft weigern, aufgrund vager Vermutungen irgendwelche Empfehlungen auszusprechen, sollten wir es in diesem Fall doch wohl auch tun. Und, um noch mal drauf hinzuweisen: Es hat hier auch niemand empfohlen, das System weiterzunutzen. Auch in der IT-Security führen Angst-Argumentationen ohne Belege nicht in eine sinnvolle Richtung. Gruß, Nils

Moin, ja. Und Fehlermeldungen usw. Ferner wäre der genaue Zustand von Interesse. Beispiel: "im AD ... wird der Name alpha.zz angezeigt" - was heißt "im AD"? Sonst läuft es darauf hinaus, aufs Geratewohl in der AD-Konfig herumzumachen, was wenig zielführend ist. Zudem wäre vor irgendwelchen weiteren Aktionen zu prüfen, ob nicht insgesamt evtl. eine Fehlkonfiguration vorliegt, die zu beheben ist. Ob das Ganze sinnvoll in einem Forum bearbeitet werden kann, ist auch fraglich. Es geht hier um das Rückgrat des Unternehmens - da sind professionelle Methoden wohl sinnvoller. Gruß, Nils