Weingeist

Wenn man keine spezielle Technolgie nutzt sondern lediglich auf bestimmte bestehende Desktop-VM's direkt per RDP zugreift meines Wissens nicht. Müsste in Enterprise + SA enthalten sein (bis 4 VM's oder so, ähnlich wie bei VDA). Problematisch wird es laut meinem Wissensstand - auch wenn das Gespräch auch wieder ein Moment her ist - erst, wenn spezifische Funktionen von MS für Automatisierung, Loadbalancing, Zugriffsart, Veröffentlichung usw. genutzt werden. Also das was auch bei ServerOS oft genutzt wird. So war zumindest damals die Ansage. Diese Funktionalität wird bei anderen Anbietern wie VmWare meist ebenfalls separat bezahlt, daher möchte wohl MS auch nen Schnippsel davon haben wenn ihr Zeugs genutzt wird.

Naja, nicht ganz. Es gibt ja noch die Hauptuser-Klausel. Nur korreliert das mit dem Konsolidierungskonzept das man mit VDI verfolgt weil es den Hauptuser nur in Verbindung mit "persönlich" zugeteilter Hardware gibt. Eigentlich geht folgendes. Immer aus Arbeiter, nicht Admin-Sicht - User hat Windows PC und greift auf Server OS zum arbeiten zu: mindestens RDS-CAL - User hat Windows PC und greift auf Desktop OS auf Server zu (Typisch VDI): Windows Client der zugreift muss Enterprise + SA haben, RDS CAL nicht notwendig - User hat ThinClient oder sonstiges und greift auf Server OS zu: RDS CAL und manche behaupten auch VDA (wurde mir so nicht bestätigt) - User hat ThinClient oder sonstiges und greift auf Desktop OS zu: VDA - User hat ThinClient oder sonstige und greift auf Desktop OS zu und von da baut er eine TS-Session zu einem Server OS auf: VDA + RDS - User greift irgendwie auf seinen persönliche Hardware zu: Keine zusätzlichen Kosten (Hauptuser-Recht), egal wie der Zugriff erfolgt - Hardware ist eine reproduzierbare, definierte Kette mit mehreren, abwechselden, nicht gleichzeitigen Benutzern (z.Bsp. Workstation im Rack, Extender für Bildschirm etc., kein Verteiler) : Keine RDS CAL notwendig, keine SA notwendig, sobald der Kram flexibel auf Endpunkte verteilt wird, wird eine RDS CAL notwendig (sa bin ich nicht sicher, habe den zustand bis dato nirgends) Für Office als Kauflizenz gilt: Jedes End-Gerät von welchem aus der Zugriff erfolgt, muss lizenziert sein. Es gibt wiederum ein Hauptuser-Recht, das zählt aber wie bei Windows nur bei persönlicher Hardware! Sprich es ist mit VDI fast unmöglich das sinnvoll mit Kauflizenzen zu lizenzieren wenn die User X Endgeräte haben. Und auch das nur mit den VL-Lizenzen. Es sei denn, sie haben ihre persönliche Hardware auf welche sie zugreifen und durchlizenziert ist. Bei Miete kann man das einfach pro User bezahlen und hat eine gewisse Anzahl Gerät zugute kann also auch +- bereitstellen wie man möchte. lizenzdoc möge mich zbsp. korrigieren wenn dem nicht so ist, aber auf diese Zusammenfassung kam ich mal mit einem MS-Mitarbeiter sowie einem Lizenzspezi nach gefühlt stundenlangem Gespräch. Schriftlich wollte er mir leider gar nichts geben. Die User-Cal (ich würde immer UserCAL nehmen statt Device CAL in der heutigen Zeit) die immer notwendig ist für Serverzugriffe jeglicher Art, ist natürlich auch quasi immer notwendig. Irgend ein Server mit dem man direkt oder indirekt zu tun hat ist ja immer da. Lästig wird es, wenn die Zugriffe eben unterschiedlicher Natur sind oder von unterschiedlichen Geräten. Manchmal auf Server OS und manchmal auf Desktop OS. Da heisst es dann doppelt lizenzieren, VDA + RDS oder Enterprise+SA+RDS je nach Gerät. Irgendwann ist dann die persönliche Hardware halt vielleicht doch günstiger als Konsolidieren und selbst wenn diese im Rack steht. MS scheint zumindest gewillt zu sein, mit den Mietlizenzen Ordnung schaffen zu wollen und das ganze für die heutigen Umgebungen zu vereinfachen indem einfach Office und Windows pro User gelöst werden kann. Schade ist nur, dass alles mit Preisaufschlägen einhergeht.

Aber der Benutzer macht nur nen Doppelklick auf dem Desktop und es läuft wieder, Du kriegst weniger Telefonate und vor allem: Es wird so neu verbunden wie es eigentlich sollte, via DSF und nicht direkt via Serverfreigabe. Wie gesagt, Netzlaufwerke sind Diven, die werden quasi nicht einfach so aktualisiert. Die sollte man immer trennen und neu verbinden. Zum Beispiel beim anmelden. Die GPO soll auch trennen und neu verbinden und nicht einfach nur schauen ob da und wenn nicht, neu verbinden (ich wiederhole mich). Oder VPN-verbinden im gleichen Script wie Trennen/verbinden, oder auf nen Trigger mit nem Task wenn Verbindung steht. Deren Möglichkeiten gibt es viele. Ich mag die 0815 Variante, User hat auf Desktop nen Link zum Script der ihm das Laufwerk auf Wunsch neu verbindet. Simpel und Effizient.

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist. --> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren. 1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen. 2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut 3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut 4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden) Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;) Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht. Ich denke der Workaround mit einem Script welches das Laufwerk trennt und neu verbindet, sollte funktionieren. Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen. Mögliches Problem: - Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll. - Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter) - Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert. -->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken) - Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky) - Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt. EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834 Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

Technisch gesehen ist die erste Windows 10 ein 6.4. Also 4. Version von Vista. Das war sogar lange in den Build-Nummern erkennbar. Bis TP3 oder 4. Das stimmte nicht mit dem gigantischen Marketingen-Brimborium überein also hat man kuzerhand 10.0 für den Release daraus gemacht. Mittlerweile wäre die Zahl nach dem Komma aber deutlich höher. Nun macht man das Gegeteil und änderte während X Jahren die erste Nummer nach dem Komma gar nicht obwohl es immer ein neues Windows und nicht nur ein Update war. Wie Windows heisst und wie es vermarktet wird, dafür ist hauptsächlich das Marketing sowie die Strategie-Abteilung von MS zuständig. Bis 2012R2 war dem Marketing egal was die technische Version war. Jetzt fliesst sogar das mit ein. Was diese entscheiden ist wiederum abhängig davon, wo man am meisten Potential für Einnahmen sieht. Deren Ansichten können sich deshalb ändern. ;)

Das ist eben nicht wirklich korrekt. Windows spricht standardmässig priorisiert IPv6 und IPv4 wenn IPv6 nicht funktioniert. Nimmt man die Prio weg, spricht es priorisiert IPv4, solange es verfügbar ist. Wenn nicht versucht es die Kommunikation mit IPv6. Ist das eingeschränkt (Komponenten deaktiviert etc.) dann versucht es Windows meistens gar nicht erst. Das Chaos verursacht dann 6to4/Teredo. Deine Aussage beweist es ja: Ein Level X kann IPv6 durch MS supprted abschalten, auch wenn es dadurch grundsätzlich auch nicht zu 100% aus ist. Welches Level aktuell dafür benötigt wird, ist mir nicht bekannt. Aber es ist wohl immer noch supported möglich. Meist dürfte MS aber den support ablehnen wenn man keine triftigen Gründe hat. Ich blocke IPv6 meist auch in der Windows-Firwall. In der Filter-Engine sieht man nach korrekter IPv4 Priorisierung/IPv6 Deaktivierung dann sehr gut wo Windows tatsächlich noch versucht hat trotz allem per IPv6 zu kommunzieren. Das ist ab und wann mal ein Loopback, mehr nicht. Und auch diese sind sehr selten. Wird die Priorisierung nicht gemacht, dann massenhaft geblockten Traffic und lausige Performance. Mit dem Gegenteil, IPv4 abzuschalten hatte ich dagegen Massenhaft Ärger, mehr Verwaltungsaufwand und und und. Irgendwann dreht das vielleicht, solange das aber anders rum ist, schalte ich IPv6 ab weil ich keine Lust auf doppelte Arbeit habe.

Sage ich ja auch, plump deaktivieren gibt Ärger. Entweder richtig mit allem Pipapo oder eben bleiben lassen. Entweder IPv6 korrekt durchkonfigurieren und alles doppelspurig fahren oder eben soweit möglich abschalten. Hauptproblematik ist die Priorisierung. Insbesondere des Loopbacks. Ist auch der häufigste Fehler den viele machen. Da werden meist nur die Komponenten und die Protokolle der Adapter deaktiviert. MS testet durchaus auch mit reinen IPv4. Auch wenn mein aktuelles Interna ein paar Jahr her ist, denke ich, dass das noch immer gültig ist. Bei Grossfirmen war es sogar möglich, reines IPv4 als supported absegnen zu lassen. Es muss im Grunde auch total wurscht sein, weil die Kommunikation gemäss dem Schwerpukt bzw. Prefixpolicy des IP-Stacks von Windows erfolgt. Die Programme selbst benutzen den Stack nur. Am Stack vorbei geht meines wissens nach nichts. Standardmässig ist einfach IPv6 priorisiert, wodurch es zu massenhaft Verzögerungen kommt, wenn es nicht richtig deaktiviert wird. (Auch wenn es nicht zu 100% inaktiv ist) Bei Problemen ist es einfach so, das MS eventuell das aktivieren von IPv6 erforderlich macht. Egal ob es Hand und Fuss hat oder nicht. Das erreicht man z.Bsp. mittels Script + Reboot.

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/