Weingeist

Gut möglich, dass es das ist. So ganz habe ich die Thematik/Logik hinter den SSU nicht verstanden. Manchmal muss das SSU vom gleichen Monat vorher installiert sein, manchmal darf es das nicht. ;) In der Vergangenheit war es bei mir oft so, dass es zielführender war, erst die Updates zu installieren und dann die SSU obwohl es genau anders rum kommuniziert wurde. Vor W10 habe ich den Stack wegen manchen Update-Probleme meistens ein paar Monate gar nicht installiert und 1 oder 2x pro Jahr aktualisiert. Bei Maschinen-Steuerungen eigentlich gar nie solange die Updates trotzdem eingespielt werden konnten. Später habe ich dann einfach immer das SSU vom Vormonat oder zwei Monate vorher freigegeben. Seit die Updates kombiniert sind, geht das natürlich nicht mehr. Klappt es mal nicht, was aktuell vielleicht 1x pro Jahr vorkommmt, dann trenne ich das Update aus dem Update-Katalog auf und versuche es separat, das klappt dann in der Regel (manchmal muss vorher 1-2x neu gestartet werden, Windows muss sich evtl. teilweise erst sammeln ). Seltsamerweise sind nicht immer die gleichen Clients betroffen die rumzicken.

Würde ich mir in diesem Fall jetzt keine Sorgen machen bei einer reinen Browser-Anwendung... Doku erstellen und gut ist. Allerdings sind 0815 Windows-PC's relativ pflegeleicht für so eine Anwendung. Da sie nicht viel können müssen, auch ziemlich kostengünstig. Einfache Fat Clients kosten ja nicht mehr als Thin-Clients/Terminals.

Für die Ursachenfindung bleibt Dir nichts anderes übrig als Systematisch zu analyisieren bevor sie sich weghängt. Und/Oder erweitertes logging usw. Arbeitsspeicherauslastung prüfen ob der Kram jeweils freigegeben wird oder nicht usw. Da gibts so viel Möglichkeiten was schief laufen kann... Netz durchforsten mit den ersten Events die geworfen werden usw.

Ein untattended.xml zu erstellen mit ein paar Änderungen ist nicht wirklich schwierig. Wenn es Dir dennoch zu aufwändig ist, einfach da wo Du die Disk auswählen musst mit Shift + F10 in die CMD und mit diskpart alle Partitionen selbst erstellen. Ist jetzt auch nicht die Hexerei, ist aber je nach dem eine mühsame Tippslerei. Oder aber Du erstellst ein kleines Script oder ein Textfile für Copypaste der GUID's. Für BIOS ohne Wiederherstellungsdisk ist das zum Beispiel easy: - select disk 0 - create partition primary - active - format fs=ntfs quick --> danach eifach die die Platte auswählen bei der Installation und man hat ausschliesslich die Windows-Partition. Selbstredend, dass dies nicht gleichermassen easy für UEFI ist. Anbei etwas Lektüre: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11 https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-partition_information_gpt Im Grunde musst alle Partitionen von Hand erstellen die entweder zwingend für die Funktion von Windows sind oder Du deren Funktion haben möchtest. Ganz ehrlich, für UEFI ist einfacher mit Automation. ;)

NTFS-Errors klingen gerne mal nach sterbendem Storage oder Storage mit zu hoher Latenz z.B. aufgrund eines Rebuilds oder schlichtweg überfordertem Storage aufgrund Sicherung etc. was dann die VM in Bedrängnis bringt. Abhilfe: Storage Checken, eventuell Disk-Timeout innerhalb der VM erhöhen. Allgemeines aufhängen nach Zeit ist auch gerne mal ein Fehler mit dem Arbeitsspeicher. Also entweder eine Software welche sich nicht sauber entlädt und so irgendwann in die Kiste in die Knie zwingt oder aber ein defekter Riegel. Abhilfe: Z.Bsp. mal auf nen anderen Host schieben sofern möglich und beobachten ob die Probleme identisch bleiben. Ansonsten wenn Du keine NTFS Error auf den Servern selbst hast sondern nur auf den Broker und die nicht direkt nach dem durchstarten sondern mit starker Verzögerung kommen, kannst auch testweise einfach mal jede Nacht durchstarten lassen, sofern das Arbeitsfenster diese zulässt.

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. ;)