Weingeist

ooops, hast ja Recht... @TO: Ich würde den Kram auch einfach löschen bzw. gar nicht erst erstellen beim Setup. Normal ist es besser wenn Windows von Anfang an weiss, dass etwas nicht da oder da ist. Denke zwar nicht, dass es hier von Belang ist, aber man meiss ja nie.

Diese Lösung ist zwar OK aber eigentlich nur ein Teil des Problems. Manche Komponenten ignorieren den Reg-Entry und gehen trotzdem auf IPv6 und man hat interessante und unerklärliche Phänomene. Insbesondere wenn eben das Binding deaktiviert wird. Ansonsten fallen sie oft nicht auf, weil trotzdem via IPv6 kommunziert wird. Kann man leicht überprüfen wenn mit der Firewall IPv6 geblockt wird und das logging aktiviert. =) Wenn man keinen Ärger möchte und sicherstellen will das alles, z.bsp auch der Anmeldevorgang, das laden der GPP's via IPv4 läuft und Loopback ebenfalls zuverlässig IPv4 genutzt wird, muss man das Routing noch anpassen. Zum verändern netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4 netsh int ipv6 set prefixpolicy ::/96 55 3 netsh int ipv6 set prefixpolicy ::1/128 50 0 netsh int ipv6 set prefixpolicy ::/0 40 1 netsh int ipv6 set prefixpolicy 2002::/16 30 2 netsh int ipv6 set prefixpolicy 2001::/32 5 5 netsh int ipv6 set prefixpolicy fc00::/7 3 13 netsh int ipv6 set prefixpolicy 3ffe::/16 1 12 netsh int ipv6 set prefixpolicy fec0::/10 1 11 IPv6 deaktivieren inklusive tunnel ----------------------------------- netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled netsh interface ipv6 isatap set state state=disabled netsh interface teredo set state disabled Neuere OS auch mit Powershell: ------------------------------ Set-Net6to4configuration -state disabled Set-Netisatapconfiguration -state disabled Set-NetTeredoConfiguration -type disabled So kann man auch das Binding völlig problemlos rauskicken. Natürlich gibts dann noch die ganzen Dienste für Teredo und wie sie alle heissen usw. die man auch deaktivieren kann aber nicht zwingend muss. Auch den IPv6 Subdienst kann man deaktivieren, dann ist der Stack quasi wirklich lahmgelegt. Mache ich aber in der Regel nur bei Industriemaschinen. Das Zeug war übrigens mal das Standard-Verfahren gemäss MS um Exchange supported mit IPv4 zu betreiben obwohl eigentlich nur IPv6 supported ist. Musste dann durch einen MS-Spezialist extra geprüft und freigegeben werden. Seit ich das mal mitgeschnitten habe, mache ich das immer so. Funktioniert auch bei Server 2022 noch prächtig. Via Firewall kann man es dann prüfen und es gehen so tatsächlich keinerlei IPv6 Pakete mehr raus. Am besten macht man das via Script/Gegenscript um den Ursprungszustand easy wiederherzustellen. Updates pfuschen einem in der Regel darin auch nicht rum.

Die planen - oder tun es ja sogar bereits - die Speicher-Chips direkt auf die Platine zu löten statt als Einheit zu verbauen... Immer wieder interessant wie bei Herstellern das grüne Marketing so vollständig gegenteilig am Produkt wieder zu finden ist, je mehr darauf hingewiesen wird, desto weniger ist es am Produkt zu finden. Aber ist ja irgendwie überall so... =)

So wie ich das mal verstanden habe war das Absicht mit ganz hinten. Und zwar genau aufgrund des Platzproblems. Sprich wenn dieser aus geht, dann wird die Partitionsgrenze angeblich dynamisch verschoben. Sprich die Wiederherstellungsplatte wird beschnitten und auf C mehr Platz zu Verfügung gestellt. Ich habe keine Ahnung ob und wie gut das funktioniert, ich partitioniere die Platten in der Regel im Voraus und da gibt es sie dann nicht. Wenn die Kiste spinnt, dann setze ich meist neu auf oder hole ein Backup (bei VM's sowieso). Bei Notebooks ist dann meist die Festplatte defekt und dann brauche ich die Partition auch nicht, da schlichtweg eh nix mehr da ist bei SSD's. ;)

Die Indexierung ist in Windows mittlerweile leider auch Flickwerk. Da wird wegen Cortana dran rumgebastelt ohne Ende. Sprich es wird alles mögliche indexiert aber dafür funktioniert das was man eigentlich möchte und immer funktioniert hat, nicht mehr zuverlässig. ;) Deinstallation funktioniert immer, Reinstallation wird dagegen eventuell schwierig Aaaber: Oft hilft es, wenn einfach das aktuellste Outlook verwendet wird. Das wird noch am ehesten getestet, dass es reibungslos funktioniert. Weil mich das immer soviel Zeit gekostet hat und weil Exchange mühsam geworden ist, habe ich viele kleine Umgbungen auf Thunderbird und IMAP umgerüstet. Keinerlei Ärger, ist sowas von robust. Früher habe ich mich gerne mal mit zerschossenen PST rumgeschlagen bei grossen Postfächer, nicht funktionierender Suche usw. Einzig wirkliches Manko: Der Kalender/Terminplaner ist bei weitem nicht so gut wie Outlook. Zumindest nicht, wenn es benutzerübergreifend sein soll. Aber punkto E-Mail Arbeits-Qualität Übersicht schlägt es Outlook meiner Meinung nach locker. Auch wenn da vielleicht auch etwas Gewohnheit dabei ist.

Bei einer Firma mit einer internen Software die permanent gebraucht wird, habe ich es so gelöst, dass der Entwickler eine Funktion eingebaut hat, die beim beenden fragt, ob man sich gleich von Windows abmelden möchte oder nur sperren (standard). Funktioniert 1A. Ansonsten Alt + F4 beibringen. Kann man auch an den Bildschirm schreiben. Das haut immer zum abmelden bei RDP.

Das Menü scheint irgendwie mit den Energie-Presets/Power-Dienst zusammenhängen. Zumindest suggeriert das der "Ausschaltknopf" der bei VDI keine Einträge hat. Wäre so meine erste Anlaufstelle. Möglicherweise könnte man es daher mit einem speziellen Power-Schema beinflussen. Ob man sich die Mühe antun möchte? Wohl eher nicht. Das war schon in alten Windows-OS der totale Wahnsinn ein eigenes zu erstellen. Zumal es dann nicht gesichert ist, dass es auch tatsächlich so ist. ;)

Und vor X Jahren - müssten auch um die 20 sein - hat Bill Gates extra eine Abteilung geschaffen die sich alleine um die Patchqualität kümmert weil es ein permanentes Desaster war und die halbe IT-Welt keine Patches mehr eingespielt hat. Diese Abteilung wurde vor ein paar Jahren aufgelöst weil die "Insider" und die Telemetrie ja deren Job machen... Seither nimmt die Qualität gefühlt permanent weiter ab. Bis dahin war die Patchqualität eigentlich bis auf wenige meist spezifische Probleme doch viele Jahre excellent. Hatte so gut wie nie Probleme in meinen Umgebungen. Ansonsten bin ich auch der Meinung das man sich die Zeit nehmen muss sich zu informieren. Aber wennn es niemand machen würde, dann gibts auch keine Meldungen Ahja, die immer ewige Leier man könne doch auf Linux wechseln ist doch einfach Habakuk. Man hat keine echte Wahl sondern nur eine Pseudo-Wahl. Schlicht weil man nicht jede Software selber entwickeln kann. Besser wäre sie dann auch nicht. Schon gar nicht als kleine Firma. Der Markt bringt Software für die Breite auf Windows, speziell für die produktive Branche. So ist nunmal die Realität. Ob sie einem gefällt oder nicht. Aber eigentlich ist das noch nichtmal der springendste Punkt. Hersteller wie MS mit Produkten die eine solche Verbreitung haben, dermassen viele Menschen direkt oder indirekt von deren Funktion abhängig sind, haben auch eine sehr hohe gesellschaftliche Verantwortung. Insofern ist da auch ein sehr berechtigter Anspruch vorhanden, dass man möglichst viel für gute Produkte - bei Software heisst das nunmal auch gute Patches - tut. Den gleichen Anspruch darf bzw. muss man im Mobil-Bereich z.Bsp. auch an Google und Apple haben. Es werden Bankomaten mit deren Software betrieben, Maschinensteuerungen, Kraftwerke, ganze Bundesverwaltungen/Länder, Spitäler usw. Sprich eigentlich die ganze Gesellschaft hängt davon ab! Allerdings - da muss man die Konzerne etwas in Schutzt nehmen - wäre hier auch der Gesetzgeber gefragt, hier entsprechende Vorgaben zu machen. Ohne diese gilt nur das Max-Profit-Prinzip. Das heisst nunmal, vergraule die Kunden nur soweit, dass nicht zu viele abspringen.

Was man auch gerne vergisst ist die Tatsache, dass Windows mittlerweile verschiedensten Berechnungen an die GPU auslagert. Das hat deutlich zugenommen in den letzten paar Jahren. Ist zwar hilfreich für normale PC's/Notebooks, aber eben nicht mit Virtualisierung. Muss das durch die CPU via virtueller GPU erledigt werden, ist das nicht gerade hilfreich und der Performance abträglich. Sprich im Endeffekt braucht man für das gleiche plötzlich mehr CPU-Zyklen als auch schon. Wird zwar teilweise dadurch aufgefangen, dass diese Berechnungen auf dem zugreifenden Client passiert - Zumindest bei RDP - , aber wohl längst nicht alles. Erhöht man z.Bsp. auch noch die Auflösung an den zugreifenden Clients, wird das ganze nochmals verschärft. Auch sind immer mehr Dienste Userbasiert. Das verschlingt zusätzliche Ressourcen. Der vermehrte Einsatz von Video-Calls, Echtzeit-Audio und Home-Office macht alles noch schlimmer weil das priorisiert werden muss damit man keine unerwünschten Unterbrüche hat. Das pfuscht in die ganzen Verteilungsmechanismen rein. Bei anderen Prozessen spielt das keine Rolle bzw. ist ja erwünscht, sonst würde es nicht funktionieren. Die Priorisierung bremst den Rest aber dann irgendwann zu stark ein weil die notwendigen Zyklen nicht freigegeben werden. Dann gibts da auch noch ganz banale Dinge: Ist ja eigentlich fast schon etwas bekloppt was alleine ein Starmenüaufruf insgesamt für IOPS/CPU-Zyklen verursacht und wie lange da im Hintergrund Daten analysiert und gespeichert werden. Zu guter letzt ist die Telemetrie enormst ausgebaut worden. Was da im Hintergrund alles berechnet und gespeichert wird ist schon fast mehr als was ein 0815 User selber an IOPS/CPU Zyklen beim Arbeiten verursacht. Zumindest in VDI hilft das daher enorm, wenn man den Rotstift bei dem ganzen Krempel ordentlich ansetzt. Schätze mal, das tut es auch bei RDP. ;) Die Verwendung von SSD's/NVMe's wurde ja bereits genannt. Da wird dann aber mehr die virtuelle Netzwerkkarten zum Problem als die IOPS welches das OS verursacht. Sprich das was an Traffic über das Netz der VMs generiert wird. Wenn ein Client z.Bsp. eine grössere Video-Datei mit 500 MB/s kopiert, dann verursacht das eine enorme CPU-Last. Je nach Storage sowohl auf dem Host als auch innerhalb der VM. Ganz Krass von VM zu VM, sind dann zwei virtuelle Karten und Hostressourcen. Solange das Storage nicht hinterherkommt, 0 Problemo, schaufelt das IOs, dann wirds zum Problem. Sind die CPU's überbucht, wirds zum massiven Problem. Als Fazit würde ich sagen: Überbuchen sollte man möglichst vermeiden/tief behalten sobald man zeitkritische Prozesse wie Video/Audio hat. Da werden eine Menge der ausgefeilten Prozesse ausgehebelt weil die VM eben darauf angewiesen ist, dass sie die Ressourcen ohne Verzögerung bekommt. Sprich die notwendigen CPU-Zyklen möglichst exklusiv im Voraus reserviert werden. Ein Client ohne Video/Audio/unnötige Animationen etc. ist da anspruchsloser.

Naja, man muss Storage Spaces schon in den Grundzügen verstehen wie so ein Pool aufgebaut ist und Daten abgelegt werden, damit man A das richtige Grundamterial hat und B ein Volume korrekt einrichten kann. Sonst lässt man - wie eigentlich bei allem - lieber die Finger davon. Dann sind nämlich einzelne, isolierte Magneplatten ohne jegliches Raid egal ob Software oder Hardware die deutlich bessere Lösung. A nur eine Platte betroffen und B bekommt man mit Recovery-Tools meistens einen Grossteil wieder raus. Mit SSD ist da Essig, mit modernen Software-RAID wie SP unglaublich aufwändig. Insbesondere bei nicht identischen Festplattengrössen muss man die Zusammenhänge der Speicherung schon ziemlich gut verstehen. Macht eigentlich nur Sinn bei grösseren Pools. Der "Automat" macht dann die erstellung eher selten gut.

Kann mich da Evgenij nur anschliessen. Probleme sollte es normal keine geben, habe schon öfter Verbünde migriert. Bis dato kein Probleme gehabt. Auch mein bewusst herbeigeführten Fails unter Last wurden jeweils korrigiert. Storage-Spaces ist sehr robust von ein paar wenigen Szenarien abgesehen (mangelnder Speicherplatz sei an erster Stelle genannt, in verschiedenen Kombis, auch wenn mittlerweile deutlich entschärft). Würde mich übrigens noch zurückhalten mit der Migration eines Pools von 2012 R2 auf 2022, solltest Du das gleich in Betracht ziehen. Gibt da Meldungen, dass dies in die Hose gehen kann. Lieber neu aufbauen. Würde Dir noch drigend empfehlen mindestens auf Mirror oder besser 3-way Mirror zu gehen. Letzteres insbesondere bei grösseren Magnetplatten. Prinziptbedingt können insbesondere grössere Files über mehrere Platten verteilt sein. Sprich bei einem Ausfall kann ein schöner Teil an den Popo gehen. Ich zumindest habe noch andere Hobbies als in meiner Freizeit Daten wiederherzustellen. ;)

Diese ganzen NAS-Dinger haben so viele Lücken, die Geräte, Funktionen, Apps ändern dermassen schnell, die würde ich so oder so nie direkt ins Netz stellen. Ziemlich egal wie gut sie abgesichert sind. Jetzt mal ganz unabhängig von SMB ;)

Die Bevorzugung funktioniert nicht in jedem Fall zuverlässig wenn nur die Disabled Components gesetzt werden. Schlicht weil es wohl nicht alle Komponenten interessiert was da drin steht. Die versuchen es dann trotzdem erst mit IPv6 statt IPv4. Gibt unter Umständen ne Menge Ärger wenn du z.Bsp. die IPv6 Protokolle auf den Adaptern deaktivierst und DisabledComponents auf 255 stellst. Also in der Theorie ist IPv6 dann deaktiviert, in der Praxis nicht wirklich. Kannst mit dem Filter-Engine-Audit gut mitschnippseln. Die Prefix-Policy wird dagegen immer respektiert oder im mindestens für alle welche die DisabledComponents nicht auwerten. Gibt dann auch keine verworfene Pakete, selbst bei expliziter IPv6-Blockung in der Firewall. Soweit ich das damals richtig verstanden habe war das eine der Massnahmen, damit Exchange auch mit einer IPv4-Konfig abgenommen wurde. Aber eben, wann genau die Priorisierung in der Prefix-Policy notwendig ist, weiss ich nicht. Wenn man sie aber tätigt, hat man keinen Ärger nicht wenn man an IPv6 rumwerkelt. Auf alle Fälle kann man so auch heute noch im Netz nur IPv4 fahren wenn man das möchte. (Diskussionen hierzu können wir uns hier glaub sparen, gibts genügend Threads dazu)

Bei allen Manipulationen die IPv6 einschränken würde ich immer auch die Prios allgemein auf IPv4 bevorzugen ändern. Kann sonst gerne Side-Effects und irgendwelche Verzögerungen geben. Wenn man IPv6 nicht braucht und ganz deaktiviert ist das sogar Pflicht. netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4 netsh int ipv6 set prefixpolicy ::/96 55 3 netsh int ipv6 set prefixpolicy ::1/128 50 0 netsh int ipv6 set prefixpolicy ::/0 40 1 netsh int ipv6 set prefixpolicy 2002::/16 30 2 netsh int ipv6 set prefixpolicy 2001::/32 5 5 netsh int ipv6 set prefixpolicy fc00::/7 3 13 netsh int ipv6 set prefixpolicy 3ffe::/16 1 12 netsh int ipv6 set prefixpolicy fec0::/10 1 11

Nicht das es besondes schön wäre, aber Du könntest evtl. beim abmelden immer den üblichen Domain User eintragen. Die lokalen User werden ja sowieso gelistet. ;)

Ich teile Deine Argumentation grösstenteils, wenn auch nicht den Ton. Aber die Argumentation ist dabei das absolut kleinste Probleme. Einsehen tut das jeder. Hatte jedenfalls noch nie Mühe mit der Argumentation, auch vor über 10-15 Jahren nicht wo das im Industriebereich noch selten ein Thema war. Seit man es alle Tage in der Zeitung lesen kann und gestandene Mittelklassefirmen hops gingen, sowieso nicht mehr. Nur die Umsetzung empfinde ich alles andere als trivial. Wie stellst Du eine vollständige physische Isolation sicher? Also ich finde das in der Praxis enorm schwierig. Alleine die Fernwartung zu X verschiedenen Firmen oder der interne, notwendige Datenaustausch. An einer modernen Produktionszelle sind schon 5-10 Hersteller beteiligt. Die Anlagen laufen 24h, 7 Tage. Undenkbar ohne Fernwartung. Oder die Laptops/USB-Sticks der Techniker die einfach überall drinstecken? USB-Sticks kann man verbieten und ist auch durch. Laptops mit sämtlicher SPS-Software könnte man theoretisch selber vorhalten, aber das ist eine Never-Ending Story und eher die Kategorie der Grossbetriebe und auch auf diese muss dann ein Technier mittels Fernwartung drauf. Irgendwie muss auch der interne Datenaustausch hergestellt werden und die Aktualität der Daten sichergestellt sein. Mache ich das über einen Proxy oder über USB-Sticks, wo ist am Ende das Risiko grösser? Die Versionierung und Aktualität der Daten ist so schon ein Dauerbrenner, wenn das noch über zu viele Zwischenstationen muss, endet man innerhalb kürzester Zeit im Chaos. Das ist dann in der Risiko-Beurteilung ganz weit oben und die Schäden sind dann in der Summe auch schnell enorm hoch. Von daher meine Meinung: Gesagt ist bezüglich vollständiger Isolation der Produktionsumgebung immer sehr schnell viel. Die Umsetzung ist dann eine ganz andere Liga. Umöglich ist nichts, aber am Ende müssen die Leute tatsächlich auch noch arbeiten können. Der Uralte Krempel ist übrigens das kleinste Problem in der praktischen Umsetzung. Weil da kann fast alles anders gelöst werden. Das richtige Problem ist der moderne, hochintegrierte Kram. Und wenn er heute nicht das Problem ist, wird er es morgen. Und alles was man macht, macht man auf eigenes Risiko weil die Hersteller alles ablehnen. Bei Anlagen die in die Millionen gehen ist das ein Tanz auf der Klinge. Das sind dann Sofort-Real-Schäden und keine die möglicherweise kommen. Das dürfte in Zukunft ändern, sobald der Druck der Versicherungen und grossen Firmen zunimmt, aber Stand heute ist das bei weitem noch nicht durch und ein 0815 Kunde der eine handvoll Maschinen hat, interessiert die grossen Hersteller nicht die Bohne wenn es um Änderungen geht. Da geht erst etwas wenn Betriebe auf finanzieller Augenhöhe diskutieren. Bei KMU's heisst das, wenn die Leasinggesellschaft oder die Versicherung stellvertretend für die Kunden kämpft/Forderungen stellt. In der Beschaffung ist das noch nicht der Fall, bei einem Schaden teilweise schon. Selbst mit der Versicherunge/Leasing im Rücken wird dann gerne zu Tode prozessiert. DAS ist leider die Realität, auch wenn die Faktenlage zu 100% klar ist. Bis man recht bekommt dauert es dann ~10 Jahre oder mehr. Das muss man finanziell erstmal stemmen. Bei IT-Sicherheit ist die Sachlage dagegen selten 100% klar. Ansonsten: Ich finde die SMB1 Proxies haben auch innerhalb eines so gut wie möglich isolierten Netzes ihre Daseinsberechtigung. Warum soll man in einem SMB1 irgend in ein Produktionsnetz lassen, auch wenn für sich autonom? Sehe ich nicht ein. Der dürfte in der Pflege das kleinste Problem sein innerhalb einer solchen Kette. Andere Glieder sind da deutlich "sensibler".

Das mit dem Pflichtenheft kannste knicken. Habe ich schon unzählige Male versucht. Haben wir nicht, machen wir nicht, vielleicht in Zukunft. Die ändern keine Baureihe nur weil eine handvoll Kunden sich tatsächlich erfrecht, ihre Steuerungs-Philosophie in Frage zu stellen. Ist denen komplett egal und wenn es 10 Maschinen sind. Und warum? Weil eben 99% der Hersteller genauso so ticken. Da immer mehr vernetzte Produktionsbetriebe durch Ransomware an die Wand gefahren werden, ist da glücklicherweise schon endlich etwas in der Mache. Sobald Grosskunden das verlangen tut sich dann mal was. Nur sind die Maschinen da deutlich weniger lang im Einsatz als in kleineren Betrieben. Wenigstens ist Hardwaremässig mit PCI-Express sehr viel Rückwärtskompatibel. Sprich Karten können in neue PC's übernommen werden. Da Software auf Windowsi mmer weniger direkt auf Hardware zugreifen kann, sind sie auch nicht mehr so abhängig von den richtigen CPU's und Grakas. Also ein Tausch je länger je schmerzfreier und MS wirbelt die Werbetrommel ziemlich mächtig für IoT. ;) Der letzte von mir verwaltete W95 wurde vor 2 Monaten in Rente geschickt. War ein Roboter der noch aussah als käme er direkt aus der Fabrik. Irgendwie schon krank. Ein Mitarbeiter meinte wir hätten doch alle etwas an der Waffel als er den neuen und alten Roboter nebeneinander stehen hatten. Aber Teile gabs halt nur noch alte via Ebay. Einmal hatte ich schon das Mainboard von einem SMD-Zauberer wiederbeleben müssen. --> Ging 2 Monate bevor der neue Robi/Zelle kam an den Popo Dafür hab ich noch ein W98 am Start. Immerhin auf XP virtualisiert. Immer wieder geil wenn ich da mal was machen muss, 250MB OS und reagiert auf ner SATA Platte virtualisiert schneller als W10 auf einer Intel Optane mit >3.5 GHZ CPU. Und kann eigentlich auch alles inklusvie Word Excel, aber halt weniger Fancy. Einige male versucht die Software zu portieren. Nie gscheit hinbekommen wegen dem Parallel-Dongle. Neuere Software funktionierte nicht sinnvoll mit dem alten Spezialdrucker den es in dieser Art leider nicht mehr zu kaufen gibt aber tatsächlich noch neue Ersatzteile zu bekommen sind. Geht zwar quasi nie etwas kaputt, aber vor 5 Jahren musste doch etwas getauscht werden. Ist über 30 Jahre alt. @teletubbieland Cool, danke für den Link. Werde ich mir demnächst zu Gemüte führen. :)

Naja, aber sind ja auch Kosten die entstehen. Gekoppelt mit sinnvoller Bandbreite über das ganze Volumen damit man ein "Vor-Ort-Feeling" hat, kann das durchaus ein nicht zu vernachläsigender Kostenfaktor pro User sein. Summiert sich schon und sind halt versteckte Kosten. Also je nach Situation, ist der Einwurf nicht unbegründet und gehört durchaus in eine saubere Kostenaufstellung. Auch wenn grad alles in die Cloud muss. ;) Weils grad so schön zum super-duper-modern passt: Gard vor kurzem mit einem Kollegen von der cloud gehabt. Die mussten eine Reservierung und Zimmer-Einteil-Software ersetzen, weil die Software-Schmiede ihres alten Systems aufgekauft und der Support nach ein par Jahren eingestellt wurde. Die neue läuft nur noch in der Cloud, deren On Premise wurde auch gleich mit abgekündigt. Ist total lahmars***ig im Vergleich zu den alten PC's mit der alten Software vor Ort. Das Personal ist nur noch am stänkern, ein paar sind schon auf und davon (nicht die schlechtesten) und der Rest ist unzufrieden. Die Internetleitung wurde auch deutlich vergrössert (zu hohen Kosten) und trotzdem ist es bei weitem nicht wie "Vor-Ort". Den ersten Telefon-Netzausfall hatten sie auch schon. Da auch gleiche eine Mobilnetzstörung anstand und somit die Backup-Leitung auch tot war, ging gar nichts mehr. Und das nicht nur ein paar Stunden. Ein Riesenspass bei mehreren hundert Zimmer. Solche extremen Ausfälle hatten die in 20 Jahren nie. Vor lauter modern geht das wesentliche bachab, die Produktivität und Stabilität an der Front. Aber das ist ja eine andere Kostenrechnung. Macht Laune und Lust nach mehr.

Naja, meinst du dann würde sie "einfach" und "schnell" sein? Microsoft hat dazu tatsächlich einige gute Dokumente zu Härtungen. Hatten wir dazu nicht zuletzt schon ein Thread dazu worum dazu ging? Ich meinte jetzt nur bezüglich Beschneidung Dom-Accounts. Dass scheint zumindest mir unmöglich zu sein ;)

So richtig Straight ist das das nicht, hat auch ein paar Stolpersteine. Meines Wissens gibts keine Api die das direkt kann. Wenn doch, ich wäre empfänglich. =) Hatte ich mir mal vor ~15 Jahren mit VB die Zähne dran ausgebissen bis ich nen Code gefunden habe. Die Anwendung sollte AD-Gruppenzugehörigkeit nutzen für allerelei Bereichtigungen. Der Code war dann vereinfach gesagt eine Abfrage von AD mittels ADO über ein Service-Konto. Das Service-Konto war nötig weil ein normaler User nicht alle gewünschten Parameter auslesen durfte. Details weiss ich nicht mehr zu 100%, meine es war nötig für das auflösen der SID. -> Mitunter problematisch in einem Script wenn das PW im Klartext vorliegt. Eventuell wäre es denkbar eine Mini-Mini Anwendung zu schreiben wo dann der Krempel verschlüsselt ist und dann direkt per Kommandozeile geprüft wird. Habe ich mal mit VB6 gemacht, kann ich aber nicht auffinden. Habe den Code noch kurz überflogen, die Basis war von Joe Kaplan. Basiert auf den bereits genannten "TokenGroups". So richtig straight-forward ist es nicht, braucht schon ein paar Apis und ein paar Eigenheiten gibt es auch. Abfrage eines verfügbaren DC's, SID (Octet) in String umwandeln, einzelne Mitgliedschaften sind als String, mehrere als Array hinterlegt usw. Könnte das Modul zu Verfügung stellen fals gewünscht, dann kannst die notwendigen Befehle extrahieren. Dürfte vermutlich in VBS zu grossen Teilen auch zu verwenden sein. ;)

Nicht ganz trivial. Ist ja immer so eine Sache, insbesondere wenn das Geräte sind, die gar nicht ohne weiteres ersetzt werden können. Ideen habe ich schon, nur noch keine umgesetzt. Konnte bis jetzt jeweils auf ein anderes Protokoll ausweichen oder eine Insellösung machen. Insellösungen sind halt mühsam im Unterhalt. Die anderen Protokolle sind zwar nicht sicher, dafür aber ohne Windows-Credential-Klau =) Mein theoretischer Favorit wäre eine Art Linux-Proxy. Linux kann ja aus quasi allem Mount-Points machen. Die Idee wäre jetzt eine Freigabe auf einem aktuellen Windows Server direkt in eine SMB1 Freigabe zu mounten welche auf einem eigenen Netzwerkadapter bereitgestellt wird und eine direkte, dedizierte oder VLAN-getrennte LAN-Verbindung zum zugreifenden Client hat. Sprich der Zugriff läuft zwar über den Linux Server, zugegriffen wird aber indirekt in das Verzeichnis das mit aktuellem Protokoll an Linux angebunden ist. Leider kenne ich mich selber zu wenig aus mit Linux um das sinnvoll durchzutesten. Den Vortiel sehe ich darn, dass die Daten im Hauptnetz liegen würden. Wäre aber natürlich nur für einzelne Clients sinnvoll wie z.Bsp. Maschinen-Steuerungen Wenn die Daten bzw. deren Vertraulichkeit nicht unglaublich wichtig sind bzw. im Zugriff nicht mehr als nur über ein VLAN oder den zugreifenden Client beschränkt werden müssen, könntest auch eine VM nehmen die nicht in der Domäne ist. Allfällige Credentials die geklaut werden, nützen dann im eigentlichen Netz nichts.

Weil im Sinne von den Hipstern eine normale klassische Installation eh nur alter Quatsch ist. Mir perslönlich kommt das Konzept wirklich vor wie aus dem IT-Mittelalter. Oder wie eine gewachsene Access-Anwendungen, da muss die Frontend auch zu jedem User ins Verzeichnis mit Schreibrechten damit es +- Multi-User-Tauglich wird. Und Access wird einfach von allen komplett zerrissen Einen Vorteil sehe ich. Wenn der Kram dann mal richtig funktioniert, funktioniert vielleicht auch das Hot-Patching. Sprich es ist kein Neustart der Maschine/App für alle User zur gleichen Zeit fällig. Imho ist das Konzept um das zu erreichen aber falsch. Die hätten das auch einfach in den Neustart der App einbauen können. Mit VSS und Soft- oder Hardlink ist die Technologie dazu ja vorhanden. Und ne Menge Windows Apps haben sowieso so viele Speicherlöcher, dass ein Neustart ab und wann angebracht ist. ;) Ansonsten sehe ich nur konzeptionelle Nachteile. Oder wo liegt der Vorteil verschiedener Versionsstände auf der gleichen Maschine und nicht nur die Nutzerdaten pro User zu haben? Ist im Grunde auch ein Sicherheitsrisiko.

Alles super duper modern Workplace, unmanaged dafür möglichst viel Telemetrie zum Hersteller, alle 3 Monate neue Versionen, nen Haufen potentieller Sicherheitslücken... Nur das speditive Arbeiten kommt zu kurz. Quasi zurück ins Mittelalter mit neuen Kleidern. Mich gurkt nur an, dass ich für den ganzen Mehraufwand den "moderne-super-duper" Software benötigt auch noch viel mehr Geld bezahlen muss, dafür als Dankeschön das Patchmanagment und die bequeme Verwaltbarkeit früherer Jahre auf der Strecke bleibt und als I-Tüpfelchen oft auch noch fast unerträglich langsam wird ;)

Das ist eher der Standard als die Ausnahme... eine geht ins interne Netz um mit CAM, CAD, PP, Werkzeugvermessung etc. vernetzt zu sein und ein Anschluss geht ins offene Netz. Meist auf der Maschinensteuerung. Der Dritte ist dann Bedienpanel direkt ins Internet für Fernwartung der Bedienung sofern nicht machbar via internem Netz. Der direke Anschluss ins Internet für die Maschinensteuerung selbst - meist für das propritäre OS - ist dafür meistens mit einem Hardware-Kommunikationskarte und Schlüsselschalter ausgestattet. Aber selbst das wird teilweise weggespart. Der zweite Standard ist dann "keine Updates" und Windows 10 Pro für Bedienpanel/Kommunikation. Vor ein paar Jahren als schon längst EOL, W7 oder XP. Und nein, Alternativen gibt es da selten weil einfach pauschal alle so sind, mit sehr sehr wenigen Ausnahmen (Zeiss Messmaschinen sei hier zum Beispiel lobend erwähnt, die nutzen LTSC). Willkommen in der Welt der Industrie/Fertigung. Ahja, und 10 Jahre möchte man die Maschine ja mindestens einsetzen, dumm nur, wenn das OS schon fast EOL bei Verkauf ist

Sicher? Gibts auch ne Wegleitung? Domain Admin kann man ja nicht wirklich effektiv beschneiden bzw. kann er sich ja selbst beglücken. Nen Exploit gibts auch von Zeit zu Zeit. Ob es dann wirklich hilft die Kiste nicht in der Domain zu haben steht wieder auf einem anderen Blatt =) Allerdings wird es wohl je länger je mehr vorkommen das Kisten nicht Domain-Joined sind und Authentifizierung eher in Richtung Applikation geht. Zumindest wenn man so den Trend beobachtet mit eigenen Heimgeräten, oder sogar bei MS selbst mit Ihren Cloud-Geräterichtlinien etc. Man wird sehen. Dürfte die Verwaltung nicht unbedingt einfacher machen. =)