Jump to content

Nimral

Abgemeldet
  • Gesamte Inhalte

    62
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

12 Neutral

Profile Fields

  • Member Title
    Newbie

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

  1. Danke für die Info. War selber nicht betroffen, auch keiner in meinem Umfeld, gut zu wissen, dass es Hoffnung gibt. Armin.
  2. @Nils, genauso ist es, und wer nun völlig verwirrt ist, kann folgendes Spielchen machen: - er erstellt ein Benutzerkonto, sagen wir mal "BackupUser" und gibt diesem - neben anderen Rechten welche die Software benötigt um als Dienst zu laufen - das Recht, Backups zu ziehen und wiederherzustellen. - dann schnappt er sich irgendein (gutes) Backup-Tool, und lässt es per Scheduler unter diesem Account ein Backup ziehen. Erkenntnis: es werden auch Dateien gesichert, bei denen BackupUser keinerlei Lese-Berechtigung hat, weder auf die Datei, noch das Verzeichnis. - dann löscht er die Originaldaten, und benützt das Backup Tool mit dem selben Account, um eine Rücksicherung zu machen. Erkenntnis: es werden auch Dateien wiederhergestellt, wo BackupUser weder auf die Datei, noch das Verzeichnis Schreibrechte hatte. Auch alle Berechtigungen, und die Ersteller/Besitzer ID werden wiederhergestellt. - dann meldet sich unser Tester mit dem Account BackupUser interaktiv an (würde wenn der Windows Security wirklich beherrscht erst mal feststellen, dass das nicht mal geht, weil sich ein richtig gemachter Service-Account nicht interaktiv anmelden darf), aber er gibt dem BackupUser sagen wir Mal User-Rechte (das was ein Account per Default sowieso bekommt, wenn man ihn anlegt ohne sich um die Details zu kümmern), dann geht die Anmeldung, und er versucht, die Dateien über die Windows Oberfläche einzusehen. Ergebnis: Zugriff verweigert. Und das selbst bei Dateien, die BackupUser gerade vorher mittels Restore selbst wiederhergestellt hat. Sinn der ganzen Aufwandes: Dienstkonten mit Administratorberechtigung waren früher mal gerne genutzte Angriffsvehikel bei Angriffen von innen, weil man mit ihnen ja alle Dateien abklappern konnte. Es ist in Windows möglich, Service-Accounts für Backup-Zwecke zu machen, die alle Dateien über ein Backup Tool sichern und rücksichern können, obwohl sie weder Mitglied der Administratoren-Gruppe sind, noch Lese- oder Schreibrechte auf die Dateien haben. Ein Techniker oder Klein-Admin, der für das Backup verantwortlich ist, kann durch Kenntnis des Passworts für diesen Account erst mal keine Streifzüge durch die IT Landschaft machen. Ich hatte das erwähnt um dem OP von vornherein den vorhersehbaren Fehlweg zu ersparen, dass er dem Backup zumindest Leserecht für alle Dateien geben möchte. Der OP ist meiner Meinung nach gerade da, wo wir älteren Hasen vor 20 Jahren auch mal waren, er muss nicht unbedingt unsere Lernkurve in den Niederungen der NTFS Berechtigungsvergabe nachfahren, und dabei seine User von ihren Daten trennen. Was uns vermutlich jedem einmal passiert ist - genau ein Mal :-) Armin.
  3. "Hysterisch bedingte" waren ab und zu auch dabei :-) Ich wollte erreichen, dass der OP dreimal nachdenkt, bevor die Häkchen bei "Rechte auch in Unterverzeichnisse ersetzen" setzt, und OK klickt. Armin.
  4. Was genau wird denn angefragt? Ob das eine gute Idee ist, ob man das darf, kann, soll, und was suchst Du? Argumente dafür, Argumente dagegen? Traditionell drehen sich Diskussionen um Cloudspeicher ergebnislos um einige sich widersprechende Fixpunkte, d.h. eine typische Pest-oder-Cholera Entscheidung steht an. Armin.
  5. Nimral

    Fehler bei Azure Backup

    Es könnte theoretisch ja sein, dass sich in Deinen Daten eine Datei befindet, an der sich Azure Backup verschluckt. Möglichkeiten gibts da viele, z.B. Dateien mit unzulässigen Namen, kaputte Dateien, usw. Es soll auch schon vorgekommen sein, dass sich Backup und Virenscanner um eine Datei zanken. Ich würde entweder das Logging einschalten Stichwort: TraceLogLevel Registry key, (siehe z.B. https://blogs.technet.microsoft.com/dpm/2015/05/20/an-in-depth-look-at-the-registry-settings-that-control-microsoft-dpm-2012/) oder - besser - ein Tool wie den Process-Monitor (freies Tool von Sysinternals) mit Filter auf Dateizugriffe von cbengine.exe mitlaufen lassen, und dann im Umfeld der letzten angefassten Datei suchen. Armin.
  6. Dieses Verhalten ist Standard bei Windows/NTFS, und kein Bug, und es ist so seit ich denken kann. - Das ist nicht Active Directory mit dem Du kämpfst, das sind NTFS Berechtigungen. - Admins haben - spitzfindig gesehen - auf NTFS Datenbestände rein technisch nicht mehr Rechte als User. Wenn nicht mindestens Leserecht vorliegt, kein Zugriff, basta. Wenn das Recht, Rechte zu vergeben (enthalten im Rechtesatz "Vollzugriff"), nicht vorliegt, auch für den Admin erst mal keine Möglichkeit, sich Rechte zu geben, Basta. Das einzige Recht, das den Admin auf NTFS wirklich mächtig macht ist, dass der Admin sich zum Besitzer von irgendwas machen dar, denn der Besitzer hat immer und unveränderbar das Recht, Rechte zu vergeben auf alles was er besitzt. Deswegen darf auch ein Admin Ordner und Dateien, auf denen er (oder die Gruppe Administratoren) formal keine Rechte hat, erst mal nicht anfassen. Er kann aber sein Recht "Besitz übernehmen" nützen, und sich zum Besitzer dieser Datenbestände machen, wonach er sich und anderen beliebige Rechte zuordnen kann. Administretoren erben den Großteil ihrer Zugriffsrechte, weil auf den meisten Ordnern, die man zwecks Datenspeicherung anlegt, das Recht Administratoren-Vollzugriff drauf ist, und später abgelegte Daten und Ordner erben das dann. Fehlt dieses Recht, wird den Administratoren erst einmal der Zugriff verweigert. Deises Verhalten tritt auf, wenn jemand die Gruppe "Administratoren" aus den Rechten des Vorgängerverzeichnisses entfernt, oder wenn dieses Recht - wie im Fall von Benutzer-Verzeichnissen - per Default nicht drauf ist. Heißt konkret: wer einen Datenbestand (den Basis-Ordner) anlegt, muss sich Gedanken darüber machen, ob er den Administratoren freien Zugang gewährt, oder ob er ihnen Prügel in die Beine wirft. - Backup hat übrigens das Recht, beliebige Dateien unabhängig vom Rechte-Satz zu lesen und zu schreiben, weshalb Du das Backup-Tool nicht berechtigen musst, auf alle Daten zugreifen zu dürfen. - Ich schätze konkret, Du hast Dich bisher mit NTFS Rechten und deren Vererbung sowie den Spezial-Accounts "Jeder" und "Ersteller/Besitzer" nicht groß beschäftigt. Ich empfehle dringend, das nachzuholen, bevor Du versuchst, die Rechtesätze von Datenbeständen mit Unterordnern zu korrigieren. Ein falscher Mausklick, und Du ruinierst eine über Jahre aufgebaute Rechtestruktur, und ein "Rückgängig" gibts nicht. - Wie Norbert schon schrieb, findest Du die Lösung auf dem Vorgängerordner, da neue Ordner beim Anlegen die Rechte von eben diesem übernehmen. Armin
  7. Zwei oder drei Gründe, warum PING bei augenschelinlich richtiger Konfig fehlgehen kann, fallen mir auf die Schnelle ein: - es ist, seltsamer Weise (und ob es bei aktuellen Modellen auch noch oft so ist weiß ich nicht) oft vorgekommen, dass sich die "entfernten" IP Adressen der Gateways PINGen ließen, obwohl das Routing eigentlich abgeschaltet war. Ich habe das immer wieder erlebt bei Routern, Firewalls und Multi-Homing Hosts. Ich spekuliere dass es damit zusammenhängt dass die Zuordnung von IP Paketen zu physikalischen Netzwerkkarten in höheren Protokollschichten möglicherweise etwas tricky zu programmieren war. Vielleicht dachte auch jemand irgendwann, das sei so ganz praktisch, aus irgendeinem Grund, z.B. um Problemen mit der DNS Auflösung des Gateways "dirty" aus dem Weg zu gehen, ode rum den Router aus allen Subnetzen unter der gleichen Adresse administrieren zu können. Jedenfalls war eine positive PING Antwort von einer entfernten Schnittstelle am selben Gerät kein sicherer Garant dafür, dass das Routing ein- und die Firewall für alle durchgeschaltet war. Finde jemanden, der sich mit der Konfiguration des Bintec auskennt, und der Dich schnell anleitet wie Du simples Routing einstellen und checken kannst. Ich suche bei gerätespezifischen Probleme gerne Kontakte im ip-phone-forum, und bintec wurde m.W. von Funkwerk geschluckt, da solltest Du auch ein User-Forum finden können. Jemand der das gleiche Gerät vor sich hat, tut sich leichter Dir zu helfen. - Es muss nicht unbedingt am Router liegen. Bei Windows Rechnern ist die eingebaute Firewall oft der Spielverderber. Es gibt da Regeln die alle Pakete verwerfen, die nicht aus dem selben IP Range stammen wie dem der betroffenen Maschine, die alle Pakete verwerfen die nict von einem Domänen-Mitglied stammen, usw, und seit IPSEc ist sowieso alles irgendwie ziemlich kompliziert. Das kann bei einem Test eine der beiden Maschinen betreffen oder auch beide, welche kannst Du mit PING nicht feststellen. Ich würde also mal testweise kurz auf beiden Maschinen die Firewall ausknipsen. oder Du wählst als PING-Ziel einen "dummen" Client, z.B. einen Drucker mit Netzwerkschnittstelle (Diagnoseblatt drucken und IP Konfig prüfen nicht vergessen). - bei Problemen mit dem Routing rate ich dazu, statt mit PING mit dem TRACERT (-d Parameter ist oft nützlich) Kommando zu arbeiten. Du machst das sowohl von der Konsole von A zu B als auch von B zu A, und vergleichst die Zwischenstationen. Es gibt manchmal durch Planungsfehler oder kleine Fehler in den Routing-Tabellen (z.B. ein Vertipper in einer Subnetzmaske) perverse Paketläufte, z.B. dass der Hin- und der Rückweg nicht gleich sind (Firewall sperrt die Pakete). Ich hatte auch schon mal eine Konfig wo versehentlich das Netz der einen Seite teilweise ein Subnetz der anderen Seite war (Irrtum bei der Berechnung der Subnetzmaske), die Seiteneffekte waren erstaunlich. und eine wo die Rück-Pakete einer Seite durch einen kleinen Konfigurationsfehler Richtung einer anderen Schnittstelle (Internet) abgebogen wurden. Tracert kann sowas sichtbar machen, PING nicht. Armin.
  8. Eigene physikalische Platten für das OS hat man traditionell aus (mindestens) drei Gründen gemacht, die sich gerade aufdrängen: - vor allem wenn der RAM Speicher mit zunehmender Nutzung des Servers langsam zur Neige geht, steigt der Druck auf die Platte, welche die Paging-Datei halten muss, überproportional an. - Dasselbe gilt, wenn eine Platte ausfällt und das RAID neu aufgebaut werden muss. Ein einzelnes großes dauert länger aufzubauen. Von separaten RAIDs für OS und Datenplatten versprach man sich also eine gewisse Risikostreung für den Ausfall/Recovery Fall. - Mehr Flexibilität. Das OS unabhängig von den Daten als selbständiger "Klotz" nehmen können konnte durchaus nützlich sein bei Tests, Migrationsszenarien, Ausfall-Recovery Szenarien, usw. - Ein gewisses Maß an zusätzlicher Betriebssicherheit. RAID Controller waren mal richtig komplexe Dinger. Durch Fehlbedienung der ebenso komplexen Steuersoftware, Firmwarefehler und andere unliebsame Effekte, die es nicht hätte geben dürfen aber trotzde gab, kam es durchaus vor, dass ein komplettes RAID auf einmal abgeschmiert ist. Deshalb war es sogar durchaus üblich, zwei RAID Controller im Server zu haben. Der Gedanke: triffts dann die OS Platten, kann man die noch intakten Datenplatten an einen anderen Server hängen. Trifft es die Datenplatten hat man ein intaktes OS um hochzufahren und Fehlersuche zu betreiben. Es gab aber nur extrem wenige Fälle, außerhalb von Labor- und Entwicklungsumgebungen, wo ich mich erinnern kann, dass damit im größeren Stil gearbeitet wurde. Eigentlich keinen. Im Labor wars dagegen oft nützlich. Trotzdem wurden Server fast immer so angeboten und auch bestellt. Inwiefern das damit zu tun hatte, dass man damit noch zwei von den sündteuren Serverplatten mehr anbieten konnte, mag ich nicht beurteilen, ebenso wenig inwiefern das angesichts der technischen Weiterentwicklung noch alles Sinn macht. Ich machs in manchen Umgebungen nach wie vor so, jedenfalls bei "universellen" Servern. Immerhin kann ich dadurch als Datenplatten über die Jahre ein wildes Sammelsurium an alten, neuen, schnellen, langsamen und SSD Speichern betreiben und damit jonglieren, ohne das Betriebssystem unnötig zu gefährden. Ich hätte aber auch ohne überleben können. Armin.
  9. Weiterer Grund: auf DCs knipst Microsoft den Schreibcache für die Systemplatte aus, und rät davon ab, ihn wieder anzuknipsen, aus Gründen der Datensicherheit bei Stromausfall. Nicht gut für Datenbank-Performance... Armin.
  10. Hm, wie gesagt, ich halte meinen Weg für vielversprechend, aber ich würe die Testimplementierung gerne dem OP überlassen ... wer den Nutzen hat, soll sich auch am Aufwand beteiligen. @lefg: hast Du irgendeinen Hinweis für mich, welche Fehlfunktionen *genau* zu erwarten sind, wenn man das Profilverzeichnis einfach löscht? Soweit mir geläufig, macht sich Windows schlimmstenfalls ein Neues unter einem anderen Namen, was ich für völlig unerheblich halte. Andere denkbare Querelen, wie Probleme mit den User-Policies, halte ich für nicht relevant, da das Demo-Konto um das es geht ja kein Domänen-Konto ist, sondern nur ein lokales Konto. "App-Gedönse" sagt mir derzeit nichts. @daabm: es geht dem OP um einen lokalen Account, und nicht um einen Domänen-Account. Ich finde das auch einen sehr guten Ansatz, weil er dadurch dem Problem, einen Domänen-Account umbasteln zu müssen, aus dem Weg geht. Dein Ansatz würde m.E. das einmal angelegte Profil des Demo-Accounts löschen, und damit das Problem der lahmen Anmeldung verursachen, was der OP ja nicht wollte. Außerdem hängt er an der Domäne, ich werde jetzt nicht nachsehen ob es diese Einstellungen für einen lokalen User Account überhaupt gibt, ich meine: nein. Nachdem ihr beide übereinstimmend sagt, dass das einfache Löschen des Profils (bzw. vergessen bei Neustart, was letztlich ja auf das Gleiche hinausläuft) "zu Problemen" führen könnte würde mich interessieren, welcher Art diese Probleme denn eurer Meinung nach sein würden, und ob es dazu irgendwo tiefer gehende Berichte gibt. Wie gesagt, ich halte meinen Ansatz für vielversprechend, macht wenig Aufwand und ich sehe - im Unterschied zu allen anderen Ansätzen - die Anforderungen des OP erfüllt mit wenigen Kompromissen und potentiellen Nebenwirkungen. Ich möchte ihn deswegen nicht ohne stichhaltige Infos beerdigen, mir aber auch den Aufwand, ein Proof of Concept zu bauen, sparen, das ist Sache des OP. Drum bin ich hier jetzt auch mal ruhig, bis sich der OP äußert, der ist schon seit längerem seltsam ruhig. Hat eventuell das Problem bereits gelöst, oder das Projektchen aufgegeben, dann wäre der Thread obsolet. Armin.
  11. Es ändert sich m.E deutlich was. Würd ich genauer hinschauen. Wartezeit beim Profilaufbau kommt aus zwei Richtungen. 1. Anmeldung: Default User Profile wird ins Benutzerprofil des Users kopiert, Profil initialisiert --> massenhaft Festplattenzugriffe, und das zu einer denkbar unglücklichen Zeit. Folge: die Festplattenwarteschlange geht minutenlang (15 Minuten sind nicht selten, bei schlecht gearteten Rechner, 3-5 Minuten normal) auf Anschlag, warten, nervig. Deshalb sind die 2., 3. 4. Anmeldung bereits deutlich angenehmer, es dauert aber meistens immer noch nervig lang - ineffiziente Systemarchitektur fordert eben ihren Preis. Bei Profil in der RAM Disk hast Du immerhin die vielen besonders aufwändigen Schreibvorgänge ins RAM gelegt und von der Festplatte weg --> der Profilaufbau geht bereits jetzt deutlich schneller. Prognose: Beschleunungung 1:3 oder mehr ist zu erwarten, wenn man eine herkömmliche Festplatte im Rechner hat. Die Wartezeit wird sich also in Grenzen halten, und deutlich geringer sein als wie wenn man das Profil auf der Festplatte löschen und jedes Mal beim Anmelden neu generieren würde. Was übrigens - für die Einsteiger ins Thema - bei Mandatory Profilen keineswegs der Fall ist. Deshalb die RAM Disk. Er könnte den Rechner übrigens auch auf mit einer SSD ausstatten, das hätte den Beschleuningungseffekt ebenfalls, wenn auch etwas geringer. Aber es geht ja um zwei Faktoren: Ladezeit UND automatisches löschen. Beide zusammen für annähernd lau gibt es nur mit RAM Disk. Ich würds gerne mal probieren. Sehen ob ich einen Effekt nicht bedacht habe. Armin.
  12. Lokal. Das Rücksetzen soll ja durch Neustart ausgelöst werden --> Server neu starten um den Demo-PC im Besprechungszimmer zu resetten kommt vermutlich nicht in Frage :-) RAM Disk wird m.E. natürlich funktionieren, wo ich Knackpunkte sehe habe ich ja schon geschrieben. Die mir bekannten RAM Disk Programme sind darauf ausgelegt, dass sie unter der Oberfläche des Users anlaufen, das wäre dann zu spät fürs Benutzerprofil, wie das mit Hintergrundbetrieb aussieht, weiß ich nicht. Sofern sich die RAM Disk automatisiert starten lässt (Kommandozeilen-Client), dürfte es kein Problem werden, sie mit einem Startup Script so früh zu starten, dass man ein Benutzerprofil darauf speichern kann. Dann ist allerdings noch die Frage (vielen Dank, Microsoft, für die wirklich flexibel einstellbare und hervorragend dokumentierte UAC ...) ob man mit einem anderen User Account an die RAM Disk herankommt. Und eigentlich müsste das "Mandatory Profile" doch auch unter Windows 10 funktionieren, eigentlich wäre das genau das was man einsetzen würde. Das ist - für die Einstelger ins Thema - NICHT gleichzusetzen mit Read-Only Attribut auf das Benutzerprofil-Verzeichnis setzen. Ich wollte aber nicht extra hergehen, und einen Windows 10 mit Mandatory Profile bauen, mir hängt das Thema Windows 10 so zum Hals heraus wie nur irgendwas ... Armin.
  13. Wireshark in Stellung bringen, nachsehen wenns wieder passiert. Bei Zugriffsversuchen von Clients müssten sich in den SMB Responses Fehlermeldungen finden lassen, die sollten weiter helfen. Alles andere ist bloß im Dunkeln stochern und auf einen Glückstreffer hoffen. Armin.
  14. Soweit ich das verstehe sollen dynamisch registrierte Clients gleichzeitig in zwei Zonen aufgelöst werden. Nicht dynamish eingetragene Hosts - also idR die Server - kann man sowieso per Hand in beide Zonen setzen. Eigentlich wäre die Antwort, nein, geht nicht. Eine Zone, klar, aber man kann DDNS meines Wissens nicht dazu bringen, einen Clientnamen in zwei Zonen zu setzen, jedenfalls nicht, ohne das (D)ynamisch von DDNS und DHCP über Bord zu werfen. Rein theoretisch, wenn man sehr verzweifelt ist, sehe ich allerdings schon eine Chance, und zwar über einen WINS Server und zwei DDNS-WINS Forward Lookups. In Kurz: man konfiguriert den DHCP so, dass er alle Namen (die bei WINS dann keine Domänen-Anhängsel haben) im WINS registriert, und konfiguriert DDNS so, dass er für beide Zonen in den WINS schaut, wenn er einen Namen nicht findet. Der Effekt ist für einen DDNS Client "client1.xx.ne/client1.yy.net",d er sagen wir mal auf xx.net eingestellt ist, folgender DNS Lookup auf client1.xx.net wird von DNS direkt beantwortet, da sichd er Client dort ganz regulär in der Zone befindet DNS Lookup auf client1.yy.net müsste von DNS mit Fehler abgelehnt werden, da sich der Client dort nicht in der Zone befindet. Auf Grund des WINS Forwards im DNS wird die Anfrage allerdings erst mal - ohne Domäne - an den WINS weitergereicht. Da "client1" dort vom DHCP eingetragen wurde, gibt der DNS für client1.yy.net die richtige IP Adresse zurück. in beide Zonen würde ich den Lookup setzen, weil ich mit einem Szenario (nNmensraum-Migration) rechne, wo die Clients so lagsam von yy.net nach xx.net "diffundieren" sollen. Clients die "nativ" bereits in xx.net wären, würden der Zone yy.net quasi verloren gehen, daher müsste man vermutlich auf beide Zonen einen Looklup setzen, um die quasi "fehlenden" Namen der jeweils anderen Zone zu ergänzen. Als Überbrückungslösung, z.B. während einer Umgestaltung von Namensräumen, könnte man so etwas eventuell gerade noch so als gute idee durchgehen lassen. Und ich habe sowas nie live betrieben -> testen, ich sehe aber keinen technischen Grund, wieso das nicht klappen sollte. Mich würde aber auch interessieren, aus welchem Dilemma Du Dich mit so einer riskanten Konfiguration befreien willst. Armin.
×
×
  • Neu erstellen...