Weingeist

Obwohl MurdocX grundsätzlich Recht hat - insbesondere auch wegen dem Mangel an Know-How - gibt es wenig sinnvolle Argumente für IPv6 UND Ipv4 in einem internen Netz. Für den Umsetzungsdienst Teredo schon gar nicht. Da man intern selten einen Mangel an IPv4 Adressen haben dürfte, gibt es eigentlich auch keinen Grund zwei Infrastrukturen zu pflegen. Insbesondere Firewall-Technisch ist das mühsam, da gibt eine doch schon genug zu tun. Windows kann aktuell immer noch beides. Dürfte auch noch lange so bleiben, weil einfach viel zu viele reine IPv4 Geräte unterwegs sind. Insbesondere in der Industrie. IPv4 wird also dringend gebraucht. Aber wozu beides pflegen? Wozu intern überhaupt IPv6 wenn IPv4 insgesamt pflegeleichter und weniger komplex ist? Ich persönlich sehe das nicht ein. Gibt mehr Arbeit, mehr Fehlerpotential und ist mühsamer in der Fehlersuche und mehr tippseln muss ich meistens auch. Zumal es eine gewisse Tendenz zum Wildwuchs mit zusätzlichen IPs auf Adaptern zu geben scheint. Ausser man "soll" und es ist die Zukunft, konnte mir auf alle Fälle noch niemand stichhaltige Gründe nennen warum ich mir tatsächlich den Mehraufwand mit IPv6 antun sollte. Sobald Cloud-Services von MS genutzt werden, könnte das unter Umständen notwendig werden. Sofern eben die Umsetzung z.Bsp. via Router nicht genügt. =) Aber eben, jeder hat da seine eigene Sichtweise drauf. Manchmal ist das alte für manche einfach gut genug und man schlägt sich erst damit rum wenn es eben notwendig wird. Aber: Die Deaktivierung muss auch "durchgängig" sein. Registry-Deaktivierung, Netzadapter-Protokoll Deaktivierung, Loopbackkonfiguration, IPv4 Priorisierung, evtl. aktiv IPv6 in Firewall blocken, evtl. Subdienst IPv6 deaktivieren usw. Ansonsten gibt es sehr schnell Performance-Probleme oder es tut nix mehr.

Als erstes: Es ist für User A meines erachtens nicht möglich zu erkennen ob ein User B die gleichen Daten auf einem anderen DFS-Ziel bearbeitet. Mehrere DFS-Ziele + mehrere Leute die auf gleichen Zielen die gleichen Daten bearbeiten = Immer Ärger. Das sind eigentlich Szenarien die es nicht geben dürfte. =) Mir kommt bis jetzt kein sinnvoller Anwendungszweck für mehrere aktive Ziele - wo auch aktiv darauf gearbeitet wird - in den Sinn der weniger Probleme macht als er löst. Je nach dem muss man sich überlegen: 1. Warum bearbeiten überhaupt mehrere Leute die gleichen Dokumente? Zuständigkeitsprobleme? Irgendwelche Samme-Excel-Files oder ähnliches? Wird einfach von jedem grad bearbeitet was er für gut hält? 2. Gibt es bessere Ansätze für 1. --> Kommunikation, eine Datenbank, Dokumentenmanagementsystem, Aktive Freigabe zur Bearbeitung, Einführung von Versionierung, Zuständigkeit definieren (ein DMS kann auch "manuell" sein bei einer kleinen Firma) etc. 3. Wozu überhaupt mehrere aktive DFS-Ziele auf denen gearbeitet wird? Performancegründe? Kann man das ersetzen mit z.Bsp. Ordnerstrukturen die an Standort A aktiv sind und andere Standort B sofern benötigt. Zugriffe auf das "falsche" Ziel - weil an einem anderen Ort - sind dann halt langsamer. 4. Bei der heutigen Verfügbarkeit von guten Ferzugriffstools kann man auch überlegen ob man überhaupt zwei Standorte mit wichtigen aktiven Infrastrukturen braucht. Eventuell ist es sinnvoller auf einen Desktop am Hauptstandort zu arbeiten. 5. Will man wirklich DC + Files auf der gleichen Maschine haben? Ein DC mit 20-30GB ist Ratz Fatz wiederhergestellt, ein ganzer Fileserver nicht. Der Vorteil von DFS ist ja gerade, dass man z.Bsp. den DC im Fehlerfall schnell wiederherstellen kann und die Files dann über eine weitere Quelle direkt zu Verfügung hat. Ohne DC läuft nix, ohne Fileserver schon. Bei DFS ist auch immer zu bedenken das es immer drei Parteien gibt. Der DC der die Rolle des PDC hat (Der Korrekheit halber er ist nur Emulator) + die jeweiligen Ordnerziele. Fällt der PDC + das aktive DFS-Ziel aus, kann nicht mehr umgeschaltet werden. Ist also der PDC die gleiche Maschine, wie das aktive Ziel, kann auf die Freigabe nicht zugegriffen und auch nicht auf ein vielleicht noch verfügbares Ziel zugegriffen werden. Die Freigabe ist weg und das DFS-Konstrukt erfüllt nicht mehr seinen Zweck. Deshalb sollte der DC mit der PDC-Rolle auch nicht aktive DFS-Ziele haben.

Ich sage ja, schmeiss alles mal raus - auch alles was du in der Registry findest - und starte neu. Sicherstellen das es nicht mehr da ist. Dann verbinde es neu mit der FQDN und schau ob es dann Neustart-Fest ist oder nicht. Oder eben allfällige Logon-Scripts und/oder GPO's anpassen oder deaktivieren. Dann gibts noch den hübschen Bug mit der Netzwerkerkennung. Sprich wenn er das Netz nicht erkennt (Sanduhr dreht und dreht und ....). Da hilft dann Netzadapter aktivieren/ deaktivieren bzw. neustart des Dienstes nla. (Oft hilft es ihn auf Automatisch verzögert einzustellen) Ahja, ob Du was mit den Firewalllogs und Wireshark versucht hast, hast noch nicht beschrieben.

Das war bis vor kurzem auch mit den Veeam-Repos so... Plätzlich kamen Meldungen rein das da alles automatisiert geleert wurde. Im Grunde dürfte es eine Frage der (neuerlichen) Verbreitung von LTO-Loadern sein ob das zum Risiko wird oder nicht. Macht das wieder Schule, dürften auch die kriminellen sich darauf einschiessen.

Tach, sind die Teile nur in der Geräte-Auflistung weg oder aber auch in den Druck-Dialogen der Programme? Bei letzterem fällt mir auch nix ein, hatte ich so noch nicht bzw. nur bei Netzwerkdruckern und nicht inkl. Systemdrucker. Ersteres ist fast schon "üblich", auch wenn es die letzten 2-3 Jahre besser wurde. Ist zwar nicht Windows direkt schuld, aber mässige Treiber verursachen gerne mal ein "Schnupfen" die dann die saubere Auflistung grad ganz oder teilweise verhindern. Ich habe zwar keine Ahnung was an der "richtigen" Auflistung nicht gut sein soll, aber MS ist da ziemlich am herummischeln und doppelspurig fahren. Drucker kann man über das mmc.exe Plugin "Druckverwaltung" exportieren und importieren. Funktioniert prinzipiell sehr gut. Inklusive Treiber etc.

@Nobbyaushb Veeam kann ja auch Software WORM. Allerdings bleibt eben das Problem, das Tapes im Loader dann nicht von der untersten Firmware des Tap-Loaders sondern eben von der Software Veeam vor Überschreibung geschützt ist. Ein physikalisch gelocktes Band wir nicht mehr beschrieben, sprich das wird von der Firmware des Loaders verhindert. Zwecks gutem Ransomware-Schutz wäre es nun eben Vorteilhaft, das mit dem Lock leerer Platz doch beschrieben werden könnte. Vielleicht bin ich da etwas paranoid, aber eben, geleerte Archive gibts ja wohl öfter als man denkt, also wieso auch nicht geleerte Bänder-Archive in Loadern wenn sich Tape wieder vermehrt durchsetzt.

Ich meine bei normalen, wiederverwendbaren Bändern. Die lassen sich ja weder löschen noch ändern wenn der Schreibschutz gesetzt ist. Auch nicht der leere Platz. Sprich es ist nicht WORM auf "Wunsch" möglich. Entweder ist alles möglich oder nichts wenn der Lock gesetzt oder nicht gesetzt ist.

Haha, das ist klar =) Cool wäre wenn der Schreibschutz eines Bandes nur das Löschen/Überschreiben/ändern verhindert, nicht jedoch das beschreiben von leerem Platz.

Naja, die Zahlen gehen ja stark in die Höhe und die Angriffe werden immer ausgefeilter/automatisierter. Ich kenn das halt von früher. Das mit dem Tape-Wechseln ist einfach ka**e wenn das nicht ein Admin macht und der ist im kleinen nunmal selten vor Ort. Bezüglich Worm: Ich stellte mir halt etwas "Halb-Wormiges" vor. Also ein Änderungs und Lösschutz auf Hardwareebene aber ohne Neuschreibschutz auf leerem Platz. Weiss nicht wie das aktuell gehandhabt wird wenn das normale Band gelockt wird. Habe schon länger keine Bänder mehr im Einsatz, aber aus aktuellem Anlass halt wieder in den Vordergrund gerückt. Wäre total easy so Full + Increments vorzuhalten bzw. am liebsten nur jeweils ein aktuelles Delta zum Full. Quasi perfekt für kleine Umgebungen 8er oder 24er loader, 1-2 Tapes pro Wochentag und gut ist. Nach dem Patchday oder wenn viele Daten geändert werden halt nen neues Full auf neue Sätze.

@NorbertFe Bezüglich Tape attackieren: Naja, ich meine jetzt weniger die Tapes die nicht mehr im Wechsler sind, sondern jene die noch drinn sind. Ist ja mühsam das Zeug jeden Tag aus dem Loader zu nehmen. Lässt man sie drinn, können die Tapes ja theoretisch geleert werden. Es werden ja bereits Veeam-Repos automatisiert geleert... Die Linux-Hardened Repos bis dato noch nicht. @mwiederkehr Das meine ich ja, möglichst komplett abschotten. Ist halt wirklich die Frage ob ein Backupserver wirklich per SMB komplett abgeschottet werden kann. Irgendwie müssen ja die Daten geschrieben werden. Keine Ahnung ob das ohne Hin und her Kommunikation möglich ist. Zudem spricht ESXi NFS und NFS ist tendenziell dümmer als SMB. Sonst kann ja theoretisch ein Löschvorgang passieren sobald ein Host kompromitiert wurde.

hach, fixe IPs haben schon ein paar angenehme Side-Effects. Gerade wenn man nicht vor Ort ist. Insbesondere bei Geräten und nach Stromausfällen. Bei Clients hats auch einen Vorzug: Wenn man gerne mit der internen Firewall arbeitet, kann man so auch easy mit expliziten IP-basierten Regeln arbeiten weil Adapter-basiert in Windows nicht möglich ist. Das konnte nur ISA/TMG. Die Pflege der fixen IP's ist in kleinen Netzten schlicht zu easy als darauf zu verzichten. Neue Clients/Geräte lasse ich erst nen Lease ziehen, dann wird umgestellt auf fix und die Reservierung eingetragen. Doppelt gemoppelt. Hat sich bewährt. Dauert nur ne Minute die beim ersten Stromausfall wieder drinn ist. Nur bei Windows selbst bin ich meist zu faul neben der Res auch fix einzutragen. Aber windows kann das meist auch ab wenn kein dhcp da ist. Aber eben, das ist nur für kleine Netze gut. Bei grösseren ist eh alles etwas aufwändiger und teilweise auch nicht mehr relevant. Das Leben ist mit Windows in vielerlei Hinsicht sehr viel einfacher als mit anderen Systemen. Manches halt auch komplizierter. Irgend einen Tod muss man immer sterben. Auch in Windows ist das meiste mit einem Reboot der jeweiligen Dienste zu lösen. Manchmal ist ein Server-Reboot der bei entsprechender Hardware in 1-2min durch ist auch einfach schneller als grossartig zu suchen. Völlig unnötig sich darüber aufzuregen =) Edit: Und sehr sehr oft liegt das Problem eh nicht bei Windows selbst sondern bei grottigen Treibern und Software die den Arbeitsspeicher nicht sauber leerräumt.

Das mit dem "im Rahmen" ist bei zeitkritischen Dingen wie Sensordaten, Sound etc. immer so eine Sache wenn es in "normale" IP-Pakete gepackt wird, in der richtigen Reihenfolge ankommen muss und nicht mit entsprechenden Protokollen priorisiert separat an allem vorbei läuft. Das ist halt relativ schwierig mit RDS/VDI über das normale LAN. Selbst die Provider kriegen das nicht immer sinnvoll hin, auch wenn die Sound-Streams nur ein paar KB's sind.

Schon ne Woche her aber Thema ist ja überall aktuell ;) Bin auch noch an einem neuen Standardverfahren am austüpfteln für kleinere Umgebungen. Gar nicht so easy wenn man auf Cloud verzichten möchte und den Faktor Mensch bezüglich Zuverlässigkeit auch möglichst dezimieren möchte. Ein paar Vorschläge, evtl. auch kombiniert: - Das bereits genannte Hardened Repository auf einer Linux-Kiste für das Repo (Scheint ziemlich gut zu sein, zumindest bis jemand das Linux knackt) - LTO-Tapes --> Evtl. mit nem Loader und einem Band pro Tag (Sind die Daten wirklich geschützt? Könnten ja theoretisch auch gelöscht werden wenn man zugriff auf die Kiste hat) - LTO-Tapes mit WORM --> Vermutlich der sicherste weg, aber ein (sehr) teurer Spass wenn man immer neue Tapes braucht. =) - Kleine SAN mit Snapshots als Backup-Rep --> ziemlich sicher aber auch ziemlich teuer. Man kann Snapshots ziehen, sollte das Rep unbrauchbar werden, kann ein snapshot wiederhergestellt werden --> Volume läuft bei Ransomware evtl. rasch voll, snapshot nicht konsistent - Windows mit NFS als Backupvolume (statt SMB), alles per interner oder separater Firewall blockieren ausser eben NFS. Mit eigenem oder keinem AD. VSS-Snapshots die man z.Bsp. nach Abschluss der Backups konsinstent oder auch inkonistent ziehen und nochmals wegkopieren kann, intern und/oder separte Maschine. Man hat aktuelle Versionsstände und ist theoretisch nicht anfällig auf gängige Windows-Sicherheitslücken. Dafür hat man aber den Komfort bezüglich Verwaltung, Tape-Anbindung, RAID-Controller, Storage-Spaces etc. Nur mit dem NFS-Protokoll/Port Windows an sich anzugreifen dürfte vermutlich schwierig sein. Dürfte für alle Nicht-Linuxer eventuell ein ganz guter und auch eher kostengünstiger Weg sein. Dahinter könnte man dann z.Bsp. eine kleine Testinfrastruktur/Virtual Lab haben wo man Kopien/Snapshots anstartet. Vielleicht ein Handy-LAN-Adapter für den Remotezugriff den man per Hardwareschalter zu oder abschaltet für ein Fernwartungstool.

Ist auch gerne mal Ressourcenabhängig - Reservierte Ressourcen machen weniger Ärger - Überlastetes LAN macht SEHR gerne Ärger - LAN mit mieser Qualität - nicht Quantität - macht SEHR gerne Ärger (Paketloss ist hier das Stichwort) - Maschinen mit eher hoher Auslastungen machen gerne mal Ärger - abgespeckte Maschinen machen deutlich weniger Ärger (Alles abdrehen was unnötig aufzeichnet, Telemetrie etc. Hilft allgemein bei VDI. Sprich alle unnötigen IOPS/Cycles weg) - Alles was energiesparen auf USB-Basis ist, harmoniert nicht mit Sound und auch sonst vielem (etwas pauschal, weil mancherort funktionierts aber hilft halt oft doch bei Ärger) Das ganze Telemetrie-Geraffel könnte ich mir gut vorstellen, dass es nach grösseren Update-Runden wieder Probleme macht. Kommt ja immer wieder was neues dazu und die Kisten sind dann oft fleissiger am aufzeichnen und der Ärger ist ja sehr oft nach Update-Runden. Habe das aber schon länger nicht mehr analysiert. Das Problem gibt es auch sehr gerne wenn Sound per USB angebunden ist, da Sound ähnlich wie manche Industrie- und Laborgeräte oder auch Kameras mit "insochronus Transfer Mode" übertragen. Quasi die Nordwand in Sachen USB-Übertragung. Wie genau die Durchreichung in RDS-Sessions genau funktioniert weiss ich jetzt nicht da schon länger nicht mehr gemacht, bei PCoIP geht das via USB. Daran scheitern auch viele USB-LAN Server (Silex kanns zum Beispiel). Mittlerweile schau ich, dass entweder der zugreifende Client selbst Audio/Video erledigt oder ich den Sound/Kamera mit einem USB-LAN-Server direkt in die VM bringen kann. Keine Lust mehr auf das ewige hin und her. Das hat bis jetzt am zuverlässigsten funktioniert und ich habe meine Ruhe. Wiederkehrende Probleme schalte ich gerne komplett aus und gehe Ihnen aus dem Weg.

Wie die vorredner schon sagten. Nimm eines mit aktivem Stromanschluss ODER ein Ethernet-USB-Teil. Bei mir und auch anderen haben sich bei Ethernet-USB die Silex Teile bestens bewährt, auch bei den exotischen USB-Befehlen die oft nicht gescheit funktionieren. Ab 3m USB Kabel würde ich nur noch Top-Material nehmen. Holt dich sonst früher oder später wieder ein. Hier haben sich Oehlbach mit Vollschirmung und Goldkontakten im Industriebereich bewährt. Edit: Ahja, die oehlbach funktionieren auch gerne mal bis 10m. Try and Error, evtl. Spannung messen. Problematisch ist ja der Spannungsabfall. Je billiger die Kabel gemacht sind, desto höher der Spannungsabfall. Bei den billigen hats manchmal nichtmal mehr wirklich Kupfer drinn und dann auch noch nur ein zwei Litzen pro Leiter. Ganz übel. Kleine Anekdote dazu: Habe mich vor ca. nem Jahr viele Stunden mit einem Messgerät mit USB-Kamera rumgeschlagen. War ca. 1m internes Kabel und 3m externes Kabel. Der Kram hat zwei Jahre funktioniert, dann plötzlich nicht mehr zuverlässig und irgendwann waren die Abstände wo es nicht zuverlässig war von Tagen auf 1h geschrumpft. Hersteller meinte bezüglich Fehler etc. dass vermutlich die Kamera defekt sei. Könne aber testweise auch neue Kabel versuchen. Gesagt getan, hat nicht funktioniert. Die Steuer-Maschine war ein teures Server-Modell, also nichts billiges und hat auch genug Saft am USB-Port gebracht. Die Kabel durch Oehlbach ersetzt - interne wie extern - und Tada hat es wieder funktioniert. Läuft seither störungsfrei. Wären die Teile von Anfang an drin gewesen, hätte das sehr viele Stunden sowohl beim Hersteller als auch bei uns erspart. Die total 4 Kabel waren vielleich 100 Euro bei einer Messmaschine von 30k. Naja, er war happy, weil er die Fehler doch schon ein paar mal bei anderen auch hatte und sie es sich nicht so ganz erklären konnten. Seither ersetze ich auch interne Kabel durch teure Kabel. Leider haben manche ***en noch spezifische Stecker die sonst niemand hat. Da kann ich teilweise jährlich ein neues Kabel besorgen weil deren ganze Serie für die Tonne ist. (Bekomme sie immerhin umsonst)

Ist doch ein aktuelles Problem das vom Mai Update verursacht wurde, wenn ich mich richtig erinnere. Gibt glaub noch keinen Patch. Noch ein Artikel dazu: https://www.windowslatest.com/2021/05/14/latest-windows-10-update-issue-is-trashing-audio-quality/

Hmm da würde mir spontan noch der Lösungsansatz einfallen, den manche Hersteller und z.Bsp. auch MS bei ihren Server-Appliances gehen. Vergabe von lokalen Rechten an Computer-Ressourcen nur an lokale Gruppen und nicht an AD-Gruppen. 1. Lokale Gruppen auf den PC's welche die eigentlichen Rechte auf den lokalen Maschinen erhalten (Edit: Also App-Locker Freigabe) 2. die Lokalen Gruppen werden mit AD-Gruppen/Personen gefüttert, zbsp. per GPO Der Vorteil liegt darin, dass die Gruppen auch beim Start bereits von Anfang an vorhanden sind und mit den AD-SID's gefüttert sind. Nur bei Änderungen der Zugehörigkeit könnte es Verzögerungen geben, nicht aber auf die Einstellungen von AppLockr an sich. Die Gruppen kann man z.Bsp. mit einem Script erstellen. Gibt halt etwas mehr Einrichtungsaufwand, dafür ist es auch unabhänig von AD und funktioniert auch mit lokalen Usern/Gruppen welcher dann dieser Gruppe angehören --> Kann mir gut vorstellen, dass es für dieses Szenario auch hilfreich ist. Selbst wenn die Aktualisierung der Gruppenzugehörigkeit dennoch notwendig sein könnte. Gehe auch sonst gerne diesen Weg, weil er im Fehlerfall eine vom Netzwerk unabhängige Debug-Variante ermöglicht. Zudem wird wohl das AD entlastet, weil weniger Abfragen raus gehen. Kann unter Umständen bei Remote-Arbeitsplätzen vorteile bieten (kann ich aber zu wenig sagen, reine Vermutung, nicht recheriert, meinen AD-Server ist eh immer langweilig).

Edge neu macht auch Probleme? Edge früher war noch ein MS-Produkt

Was ich nicht verstehe, wozu die Mühe mit Chrome wenn Edge - mittlerweile auch Chrome - Bestandteil vom OS ist? Bei Firefox würde ichs ja verstehen ;)

@zahni Jetzt wo du es sagst, im Freundeskreis kämpfen die öfter mit Connection-Problemen zu Lautsprecher/Auto und ähnlichem via Spotify. Und Spotify finde ich tatsächlich eine sehr coole App. wäre so die einzige App die für mich Nice-To-Have wäre. Interessant wäre zu wissen ob Verbindungsproblemen an Android-Bibliotheken oder den Herstellern liegt. So richtige Experimental-Handys sind eh nichts für mich. Ich bin ja funktionell recht anspruchslos, aber das was ich brauche muss halt stabil laufen. Sonst habe ich dann lieber ein 0815 Phone das mir nen WLAN-Hotspot macht (so wie aktuell mit dem Punkt MP02). Das die Chance auf problemlose Funktion bei iPhone grösser ist, glaube ich gerne. Eigentlich finde ich die Telefone ja sogar richtig gut und die Update-Philosphie ist auch ordentlich. China-Phone: Olée olé, naja bei reinen China-Herstellern verspüre ich sowieso eine "leichte" Abneigung, würde ich nicht kaufen @Sunny61 Mit LOS meinst Du Lineage OS oder? Finde es macht zumindest den anschei als würde die durchaus weiterentwickeln. Also ich habe mich mal etwas durchgewühlt und versuche etwas zusammenzufass bzw. versuche es zumindest (ohne anspruch auf vollständigkeit 100%ig richtigkeit, nur der Eindruck der mir entstanden ist, mir wichtig ist). Volla - Telefon + OS: - scheint eine sinnvolle Alternative zu sein, Trägerschaft Europäisch - Technik ist nicht Topmodern. Brauchen tu ich das aber eh nicht (Einziger caveeat: Hersteller Gigaset... ) - eigenes Bedienkonzept - ich finde das unnötig und verzögert für kleine Hersteller nur einen Rollout von Updates? - Apps aus Google-Playstore möglich ohne Google-Playstore zu haben - Ist mir persönlich etwas gross geraten, dafür Akku gross, fixierung rein auf ihre Geräte LineageOS: - Klingt vernünftig, scheint +- rein Stock AOSP zu sein, also ohne unnötigen Ballast - reines OS, evtl. etwas gewurstel selber alles zu machen - So im Grundsatz wohl der vernünftigste Ansatz aber halt einiges an Eigeninitiative - beschränkte Anzahl unterstützte Phones, eher ältere Modelle wegen moderner Bootloader, moderne Pixels werden aber unterstützt - Treiber je nach dem besser oder eben nicht (insbesondere Kamera) - Apps aus Google-Playstore möglich ohne jedoch Google-Playstore zu haben - Keine eigene Hardware, dafür auch ältere unterstützt, also auch kleinere Phones möglich wie das Galaxy S5 /E/ + Fairphone oder andere Hardware - Ableger von LineageOS mit Nachbildung der beliebtesten Apps von Google ohne jedoch Googledienste zu verwenden. - Nachbildung der Apps von Google erfordert ein Cloud-Konto bei der Firma, wie sicher die Daten da sind ist schwierig zu beurteilen. Kleine Firma, kleines Budget. Dafür hoch integriert ins Telefon (mehr Komfort als es mit Lineage möglich ist) - Zusammen mit einem Fairphone eine ziemlich gute Alternative finde ich, da Nachhaltigkeit - also auch die lange Verwendung - gewährleistet ist. Somit auch Updates. GrapheneOS + Pixel - Auch ein AOSP Ableger - Unterstützt offiziell nur Pixel-Phones, dafür auch Verified Boot weil Bootloader kein Rooting benötigt - Angeblich von Haus auf sehr sicher, aber wenig Komfort - Bietet was mir bei den anderen fehlt oder ich nicht bemerkt habe: Entzug von spezifischen Rechten für Kamera, Netzwerk, Sensoren etc. für Apps. - Trägerschaft müsste im Grund auf Kohle aus sein - irgendwie nicht ganz transparent - aber gegen normal Geld verdienen habe ich rein gar nichts SailfishOS - Klingt soweit auch OK, wenn auch weniger gut als obige - Trägerschaft scheint russisch zu sein... =) EDIT Ganz vergessen: iPhone - lange Update-Verfügbarkeit - Hardware vom gleichen Hersteller - tut in der Regel einfach - keine Apps ohne Apple-ID Sind jetzt doch etwas viele Varianten um alle selber ausuzuprobieren Ich tendiere aktuell in richtung LineageOS oder GrapheneOS weil mehr oder weniger kein Krempel installiert ist. Bei den Geräten entweder auf etwas älteres wie Galaxy S5, ein Pixel oder ein Fairphone. Beim Pixel ist die Qualität der Treiber vermutlich am besten und die Kamera macht wohl auch super Fotos. Google schaut garantiert, dass ihr Krempel funktioniert. Auch ist Bootloader freischalten ohne rooting möglich. Auch wenn die Chance grösser sein dürfte, dass da von Google zusätzlich was eingebaut wurde für die Identifikation. Aber naja, so paranoid bin ich dann am Ende vielleicht doch nicht Ich denke ich versuche LineageOS und wens mich nervt das Graphene und wenn das auch nix ist, kommt ein Volla =) Nochmals Danke für die Inputs

@zahni das sehe ich auch so. Aber ich bin nicht im Grundsatz gegen die OS oder die Hersteller selbst. Nur das Übermitteln von persönlichen Daten an die Hersteller geht mir gegen den Strich. Also Standortdaten, Sensordaten, Adressbücher, Nachrichten, Browser-ID, Geräte-ID für Apps usw. Ich würde mich ja mit ein paar hundert Euro pro Jahr "auskaufen" / die Updates bezahlen, aber die Möglichkeit gibt es ja nicht. ;) @Esta etc. Gigaset Zu diesem Hersteller erspare ich mir jeglichen Komemmentar.. =) Shift-Phone klingt ok. Wenn auch AOSP nicht standardmässig verfügbar sondern nur über ein beta Programm für welches man sich registrieren muss. Volla klingt ok. so langsam wird die Liste ordentlich. Danke an Alle! @BOfH_666 Ich vermute die AOSP-Versionen sind gar nicht so verkehrt. Zumindest habe ich so gut wie keinerlei Datennutzung auf dem minimalistischen Punkt MP02 das mit AOSP läuft. Mal sehen ob das so bleibt.

Solche Probleme hat man immer wieder mit den Stromsparfunktionen. Manchmal sind es USB-Geräte, dann die Grafikkarte, mal der Bildschirm, mal Firmware des BIOS. Ausser alles aktualisieren wie vorgeschlagen wurde, kannst nicht viel machen. Manchmal hilft es die beteiligten Prozesse abzuschiessen und neu zu starten. Der Bildschirm macht immer wieder mal Ärger. Solange der "dumm" und Analog war, hatte man die Probleme nicht, seit DVI und XP in verschiedensten Ausprägungen. Gerne wenn z.Bsp. der Bildschirm selber in den Standby geht und dies nicht durch das OS/Graka initiert wurde. Sprich Bildschirm geht in Standby, Windows will ihn später in Standby schicken, kriegt wohl keine "Antwort" und hängt irgendwo. Dann verschnupft sich Windows oder die Graka gerne mal. Hier hilft dann oft in den Einstellungen des Bildschirm selber die Stromspareinstellungen zu deaktivieren. Oder Windows bekommt den Bildschirm/Graka nicht mehr aus dem Standby hoch weil irgendwas blockiert. Manchmal kann man ihn "wecken" indem von einem anderen PC per RDP auf die Kiste verbunden wird. Der letzte Ausweg ist dann sämtliche Stromsparfunktionen abzuschalten oder die verursachenden Geräte immer zu trennen wenn man den Arbeitsplatz verlässt. BIOS und Windows.

Da war tatsächlich mal was. Sorry für die Verwirrung. Habs jetzt noch extra in meiner Linksammlung gesucht und tatsächlich auch gefunden olé olé. Lief damals noch unter Server 2003. Mit Server 2008 war aber Ende Gelände. Gab dann später mal nen Hotfix der die Funktion wieder brachte. Soweit ich mich erinnere war irgend ein Caveat damit verbunden, vielleicht fällts mir ja wieder ein was es war. Ist eine gefühlte Ewigkeit her.

Ja, vom zugreifenden Client. Dann wir das lokale Schema erzwungen. Und doch, eigentlich müsste das helfen. TS: OK, habe ich falsch interpretiert (Nur auf Clients) Eine Infektion kannst Du ausschliessen? Nur weil es immer die gleichen Systeme betrifft. Theoretisch könnte die Session ja bereits durch einen "Angriff" auf dem Server bestehen, diese wäre vorzugsweise auf Englisch (wer ausser wir Europäer hat schon qwertz und ä ö ü) und Du übernimmst mit Deiner Anmeldung diese bereits generierte Session. Theoretisch wäre dann auch die Tastur-Sprache vorgegeben, da es eine bestehende Session ist. Oder irgend ein automatisierter Ablauf generiert die Session oder die Session wird von einem Mobiltelefon oder sonstigem Device erstellt welche zum Beispiel im Hintergrund auf Englisch ist.

Bis jetzt habe ich das auch nur so gehört mit dem manuell setzen per Script. Dürfte im Grunde auch nicht anders machbar sein weil by Design so. Grundsätzlich anders ist dann die Liga von einem DMS mit wieder anderen Problemchen ;)