Nimral

Danke für die Info. War selber nicht betroffen, auch keiner in meinem Umfeld, gut zu wissen, dass es Hoffnung gibt. Armin.

... und? Wie ist es ausgegangen?

@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.

"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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Lass hören was wird, interessiert mich, ob man die Dateien wirklich wieder entschlüsseln kann ...

Stochern im Dunkeln bringt Dich nicht wirklich weiter. 80244019 ist eine Universalmeldung, sowas wie "irgendwas ist irgendwo schief gegangen, und mehr weiß ich auch nicht". Ich mach das dann normalerweise so, dass ich mit den entsprechenden Patch als Datei von Microsoft herunterlade, und sie direkt und mit eingeschaltetem Logging vom Windows Installer ausführen lasse. Im Installer Log finden sich dann idR brauchbare Hinweise. Armin.

... und selbst wenn Du es sauber bekommst, wirst Du Dich bei jeder Fehlfunktion der nächsten 18 Jahre fragen, ob das nicht eine Nebenwirkung der "Reparatur" sein könnte, und keiner wird Dir eine Antwort geben können. Wenn das Vertrauen zerstört ist, soll man sich trennen. Ich stimme zu: kopiere Deine Daten, soweit sie noch zu retten sind, runter, und dann mach ihn platt. Oder, wenn Du an wichtige Daten nicht mehr rankommst, warte auf den Fix der da eventuell kommt. Um den Rechner wieder nützen zu können würde ich ihm in diesem Fall eine andere Festplatte spendieren, und die eventuell "irgendwann" wiederherstellbare auf Lager legen. Armin.

Mit "Profilordner" meine ich den im Benutzer-Manager einzutragenden Pfad zum Benutzer-Profil, der dann das gesamte Profil, incl. Appdata, Temp und natürlich auch die sichtbaren Ordner für Dokumente usw. umfasst. - Was sagst Du zu meiner Idee mit der RAM-Disk? - Wie würdest Du das Problem besser lösen, wenn nicht mit einer RAM-Disk? Armin.

Mir ist erst mal nicht ganz klar, was die Virtualisierung damit zu tun hat. Und ich halte PING für ein ganz schlechtes Testtool für sowas. 23 aus 87000 PING Paketen verloren schaut auch nicht sonderlich bedrohlich aus, ich würde das bei einem ausgedehnten Netz für durchaus normal halten. Wenn Du außerdem unter Windows mit PING getestet hast besteht das Testpaket aus gewaltigen 32 Bytes + Overhead, also so gut wie nichts, zumindest den -l 1400 Parameter solltest Du schon benützen, um ein halbwegs vernünftiges Paket zu generieren. Aber selbst dann ist es immer noch ein ICMP Paket, und nicht TCP oder UDP, also nur bedingt vergleichbar mit den Paketen die echte Nutzdaten befördern. Mein Rat wäre, die Fehlersuchstrategie zu ändern. Netzwerkpakete gehen nicht einfach so verloren, weil sie durch Löcher aus den Kabeln fallen oder unterwegs von Kupferwürmern gefressen werden. Sie werden entweder nicht weitergeleitet (defekte/überlastete Netzwerkkomponente) oder zerstört und von der nächsten aktiven Komponente mit Checksummenfehlern oder Über/Unterlänge Fehlern ausgefiltert. Das Wissen darüber führen alle managementfähigen Switche in ihren Port-Statistiken, hier musst Du zu suchen beginnen, und hier siehst Du dann auch ob es auffällige Häufungen an bestimmten Ports gibt. Wenn Du dann immer noch das Gefühl hast, das sin Deinem Netz etwas nicht stimmt, sehen wir weiter, immerhin mit ersten Hinweisen wo man hinschauen müsste. Das ist dann auch der Punkt, wo manche zu ahnen beginnen, wieso ich die billigen, nicht management-fähigen Switches in die tiefsten Höllen wünsche, obwohl sie doch soooo billig und soooo praktisch sind. Sie können solche Probleme verursachen, bleiben aber im Netz weitgehend unsichtbar --> entweder man weiß, wo sie stehen, und selbst dann kann man nicht in sie hineinschauen, oder man sucht sich einen Wolf und findet die Ursache nie. Armin.

Ich würde da mal etwas besonnen zu Werke gehen. Sind wirklich *nur* die Zertifikate der Virenscanner-Hersteller betroffen? Ich wage daran schon mal zu zweifeln. Ein Schädling hätte m.E. keinen Vorteil davon, die Zertifikate der Virenscanner-Hersteller zu manipulieren. Was würde er dadurch erreichen, außer dass er sich selbst sofort verrät? Und wie und was genau sollte er überhaupt machen, schließlich kann man ein fremdes Zertifikat nicht einfach so nach eigenem Gutdünken durch ein anderes ersetzen, und dadurch irgendwelche Vorteile erlangen. Ich würde eher nach anderen, viel trivialeren Ursachen suchen. Etwa eine verstellte Systemuhr, eine unterbrochene Zertifikatskette, eine ungültige/fehlende CRL Liste, sowas in der Art. Untersuche die kaputten Zertifikate mit den diversen Zertifikats-Checkern, und entscheide, sobald Du weißt, was mit ihnen los ist. Und ja, neu Aufsetzen kann man immer, man lernt nur nichts dazu dadurch. Abgesehen davon kann man, wenn man sich darauf nicht vorbereitet hat, Schäden verursachen, die an die eines Virus leicht heranreichen. Alle Treiber verfügbar? Auch für die Peripherie? Installationscodes aller installierten Kauf-Software vorhanden? Gespeicherte Passwörter aus dem Browser gesichert? Alle Daten identifiziert und weggesichert, die nicht bequemer Weise unter "eigene Dokumente" zu finden sind? Meine Erfahrung: bis der Rechner wieder so ist wie vorher, dauerts länger als man denkt, irgendwas fehlt immer, ich würde Windows daher nicht einfach so neu aufsetzen, solange nicht klar ist, ob wirklich ein Virenschaden vorliegt. Armin.

Der Browser war und ist ein extem zickig Stück Software, er stolpert über so ziemlich jede auch noch so kleine Unregelmäßigkeit im Netz. Dazu gehören (ohne Anspruch auf Vollständigkeit) Rechner mit mehreren Netzwerkkarten (auch virtuelle), Mischkonfigurationen aus Rechnern mit IPV4 und IPV6, nicht ganz koschere WINS und DNS Einträge, allgemein Geräte die Broadcasts filtern (machen z.B. WLAN Router mehr oder weniger gut), die Windows Firewall. und nicht nur das. Ergänzend zu dem was schon gesagt wurde ist es nämlich so, dass die Wahlen zum Browser nicht fair verlaufen: höhere Windows Version schlägt niedrigere Windows Version, Domain-Controller schlägt Sever, Server schlägt Workstation, Ultimate schlägt Pro und Pro schlägt Home, bei Unentschieden gewinnt der Client der länger läuft, Windows-ähnliche Kistchen (z.B. NAS mit SMB) plappern auch noch dazwischen, vermutlich auch die Fritzbox wenn man das Windows Sharing anmacht. Und was wenig bekannt ist: ein neu eingeschalteter Rechner initiiert beim Hochfahren aktiv Neuwahlen, d.h. er würfelt das ganze Kartenhaus durcheinander. Und auf Grund der Zeitverzögerungen für Announcements und Synchronisation der Master- und Backup Browser (ja, die gibts auch noch ...) sieht man den Erfolg einer bestimmten Maßnahme erst bis zu einer Dreiviertelstunde später. Kurz, nach zahllosen endlosen Sessions mit Wireshark und Browmon (Tool aus dem alten Resoucre Kit) habe ich es irgendwann aufgegeben, hinter dem Browser herzuhecheln. War auch sinnlos, zumal man einen als aktuellen Verursacher des aktuellen Problems identifizierten Server mit zwei Netzwerkkarten ja nicht einfach so ausknipsen kann, nur damit es der Browser leichter hat. Dazu kamen dann noch diverse Bugs, dass die Übertragung der Netzwerklisten z.B. Schwierigkeiten bekam, wenn so viele Computer im Netz waren, dass ein Netzwerkpaket zur Übertragung der Liste nicht mehr ausreichte, es wurden dann zufällig ganze Blöcke von Computernamen an- und ausgeknipst. Fazit: selbst wenn es Dir in einem bestimmten Augenblick gelingt, den Browser stabil zu bekommen, reicht bereits das Ein- oder Ausschalten eines Clients oder Servers und das ganze Zeugs klappt wieder in sich zusammen. Schade um die Zeit. Das wäre der eine Ast, soweit ich mich erinnere hat Microsoft doch neuerdings über UPNP noch eine weitere Parallelwelt geschaffen? Ich habs pragmatisch gelöst. Die wichtigen Server kann man manuell in die Netzwerkumgebung aller Clients setzen, dazu genügt es, den Ordner "Nethood" mit simplen Links zu betanken, was wiederum - sofern man über keine Softwareverteilung verfügt - ein Login-Script machen kann, oder man machts manuell, kein Problem da sich die Serverlandschaft ja selten ändert. Die Server sind dann immer sichtbar, die User glücklich, und ob die übrigen Clients gerade mal sichtbar sind oder nicht - wen interessiert das. Zugreifen kann man ja, wie Du schon bemerkt hast, trotdzem, und als Vehikel um den Zustand eines Clients (ein/aus) festzustellen ist der Browser wegen seiner enormen Zeitverzögerungen und seiner architekturbedingten Unzuverlässigkeit ohnehin nicht zu gebrauchen. Wozu einen Gaul reiten wollen, der meiner Meinung nach bereits tot geboren wurde? Armin.

Nur so weil ich grad aus Interesse diesen Thread durchgelesen habe: als ich noch jung war, hätte ich versucht, dieses Problem mit einer RAM Disk anzugehen. Gibts als Freeware auch für Windows 10. Bringt schnellen Profilaufbau, würde keinerlei seltsame Risiken und Nebenwirkungen für die eingesetzte Software bedeuten (außer dass sie möglicherweise viel, viel schneller wird), und löscht sich selbst bei Shutdown, wonach beim nächsten Start wieder das Default-Profil aktiv wäre. Den Profilpfad kann man pro User einstellen, das wäre also machbar. Fallstricke? vermutlich viele, da Anforderung nicht Mainstream. Einrichtung und Betrieb mit Hintergrundkonto könnten eventuell etwas tricky sein, und auch der "Soft" Shutdown von Windows 10, der das Löschen verhindern könnte. Halte ich allerdings alles für machbar und den Ansatz für vielversprechend. @Jan: nicht vielversprechend, bzw. riskant. Ein guter Teil der gängigen Software wird unglaublich zickig, wenn sie nicht in die Profilordner schreiben kann. Ich bin mir auch recht sicher, dass auch die Windows Shell da nicht ohne Mucken mitmachen wird. Armin.

Nur als Tipp, ich möchte da im Moment keine Zeit versenken um das zu verifizieren: es gab früher die Möglichkeit, per GPO, notfalls auch per Registry, eine "Alternative Shell" einzustellen, also ein Programm, das nach dem Login an Stelle des normalen Windows Explorer (der auch für die Windows Shell zuständig war) angestartet wird. Es gab auch einige "Alternative Shells" die man probieren konnte. Alternative Shell - das könnte aber auch der Remote-Desktop Client mstsc.exe sein. Dann würde Windows nach dem Login das Terminal starten, und sonst nichts, auch keine Oberfläche und keine Taskleiste. Es gab allerdings einige Nebenwirkungen. Erstens musste man auch den Task-Manager abdrehen, weil sonst der advanced User sich seinen Explorer einfach per "neuer Task" starten konnte, und das war nur eine von vielen Möglichkeiten, sich doch eine Shell zu ergaunern. Zweitens beendete sich Windows nicht, wenn man das alternative Shell Programm beendete, sondern kippte den Benutzer auf einem leeren Bildschirm ab. Kann man argumentieren, dass man den Benutzer durchaus beibringen kann, den Computer durch einen kurzen Druck auf den "Aus" Knopf herunterzufahren, oder einen kleinen Task in den Hintergrund setzen, der beim Beenden von mstsc.exe einen logout oder shutdown auslöst. Erster Check wäre allerdings, ob es die Einstellung "alternative Shell" für Windows 10 überhaupt noch gibt. Armin.

Windows kann m.W. bei einer Mehrfachmarkierung nur ein einziges Programm starten. Man kann also durchaus mehrere Dateien mit verschiedenen Endungen markieren und öffnen, allerdings nur sofern sie alle auf das selbe Programm registriert sind. Zu helfen gibts da leider nichts, das war bereits bei Windows 7 auch schon so. Abhilfe mit vertretbarem Aufwand und Hobby-Mitteln wäre aber ziemlich einfach möglich, erfordert aber das Zwischenschalten eines eigenen Programms, auf welches Du alle betroffenen Endungen registrierst. Man könnte es eine "Weiche" nennen. Das Programm entscheidet dann seinerseits an Hand der Endungen der übergebenen Dateien, welches "richtige" Programm für die Datei zuständig ist, und startet es, und übergibt die zu öffnende Datei als Parameter. Richtig gut würde das aber auch nicht, weil sich die Icons der Dateien immer nach dem Programm richten, auf welches sie registriert sind. Ein Lösungsansatz mit Nebenwirkungen, Word uen Excel Dokumente würde ihre gewohnten Icons verlieren. Ich würde daher andere Lösungsansätze verfolgen, zB diesen: Du machst das Weichen-Programm und positionierst es an einer prominenten Stelle auf dem Desktop. Jetzt könntest Du die Dateien per drag and drop auf die Weiche ziehen, und diese würde wie schon vorhin angedacht die Endungen auswerten und die Verteilung übernehmen. Vorteil: Du musst die Endungen nicht auf das "Weichenprogramm" umstellen, die Icons werden also nicht angetastet, und auch sonst bekommst Du keinerlei unliebsame Nebenwirkungen. Und die Weiche könnte - weil ihr icon keine Rolle mehr spielt - aus einer simplen 10 Zeilen Batch Datei bestehen ... Jep, ich glaube, so wird mit vertretbarem Aufwand ein Schuh draus, so würde ich es machen. Armin.