Weingeist

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

Stimmt. OOps.... Falsch gelesen Aber da dürfte das gleiche gelten. Manuell in DNS registrieren damit die Namens-Auflösung funktioniert. Und auf einer Maschine manuell installieren ist ja jetzt auch nicht so dramatisch. Finde ich. Firewall aufmachen ist jendenfalls kaum zielführend für ein System das aus Sicherheitsgründen aus der Domäne raus ist. Da sollte eher nur genau das aktiviert sein, was effektiv zwingend gebraucht wird. =)

@Dukel Naja ich denke erhofft sich ein Sicherheitsplus wenn der Antivirenserver nicht mit Domänenkonten komprimittiert werden kann. Gab ja in letzter Zeit einige solcher positivien Meldungen insbesondere z.Bsp. für Backup-Ziele die ausserhalb der Domäne in einer Workgroup lagen die dann z.Bsp. nicht von vollständig von Ransomware verschlüsselt wurden weil kein Zugriff via den üblichen Domänen-Konten erfolgen konnte. Aber solche Maschinen müssen dann auch entsprechend abgeschottet werden damit es wirklich einen Vorteil hat. @sd2019 Was meinst Du mit "Der Client wird über die Gerätesuche nicht gefunden"? Heisst das die Antivirenlösungen findet die Clients nicht? Der Hinweis mit DNS ist eher ein "Muss" wie ein "Soll". Du brauchst eine funktionierende Namensauflösung wenn deine Antiviren-Lösung nicht rein IP-Adressen basiert ist. Den Antivirenserver musst also im internen DNS-Server auch als Host eintragen. Der Antivirenserver muss die Hostst/Clients ebenfalls mit dem internen DNS-Server in der Domäne die IP-Adressen auflösen können. Insbesondere wenn alte Techniken zum Namensauflösung abgedreht wurden und auch abgedreht werden sollten. Aber eben: Fragt sich was überhaupt die Antiviren-Lösung auf dem Server bereitstellen muss, was hin und her muss und warum der Server die Clients finden muss und nicht der Client sich melden soll und dann eingetragen wird. --> Meine erste Anlaufstelle wäre hier der Hersteller der Lösung. Insbesondere bei Sicherheitstools hast selten eine Verbesserung sondern eher eine Verschlechterung der Sicherheits-Situtation wenn Du nicht Herstellerangaben befolgst.

Nope Nope, das Ding ist nur eine effektive und korrekte Auflistung Deiner Drucker. Im Grunde das gleiche wie die "neue" Geräteauflistung wo Du Deinen Ärger hast. Einfach eine die eben auch funktioniert. Also einfach einen neuen Ordner irgendwo erstellen und den Punkt sowie die GUID hinten anhängen. Ist dann quasi ein Ordner-Link, ähnlich den Elementen in der Systemsteuerung. Öffnests dann diesen leeren Ordner, dann siehst Du Deine effektiv installierten Drucker, egal ob sie in der Geräteauflistung korrekt angezeigt werden oder nicht. Du siehst Sie so wie es auch verbunden wurde. Wenn jetzt Deine Drucker auch da nicht so benamselt sind wie Du es gerne hättest, dann hast Du deine Drucker vermutlich nicht gleich benannt wie in der Freigabe. Dann verbindest Du zwar über die Freigabenamen, aber angezeigt wird Dir der effektive Druckername den Du auf dem Server vergeben hast. Ich bin jetzt gar nicht sicher, aber ich meine das war vor langer Zeit mal anders und früher wurde der Freigabename angezeigt, ist aber mehr ein Gefühl wie wirklich gewusst =) Im Grunde kann Dir die Geräteauflistung deshalb total egal sein, wird aktuell noch nirgendwo verwendet soweit mir bekannt. Ist ein rein optisches/kosmetishes Problem. Das was Sunny meint ist die "neue" Funktion von Windows 10 wo Windows glaubt besser zu wissen was Dein Standarddrucker sein soll als Du selbst. In 99% der Fälle völlig unbrauchbar. Kannst per GPO abdrehen. Ich hoffe der PrintNightmare Bug bringt endlich mal den dringend nötigen Fokus auf die Printer und daraus ergibt sich mal ein schlaues Treibermodell... die Hoffung stirbt zuletzt =)

Normal gibt es seitens Windows Kontakte zu Akamai, Updates für den Defender, time-sync, Telemetrie etc. Sind insgesamt ziemlich viele Verbindungen. Wirklich etwas herunterladen tut meines Wissens aber nur der Defender. Die anderen laden eher hoch.

Die Geräte-Auflistung unter Windows 10 ist im Grunde unbrauchbar. Zwar nicht alleine die Schuld von MS, aber MS greift für die Auflistung auch nicht richtig auf die korrekte Liste zu bzw. wertet sie falsch aus. Die einzig wirklich zuverlässige Auflistung bekommst indem du einen neuen leeren Ordner erstellts mit beliebigen Namen, gefolgt von einem Punkt und der GUID dieser Systemfunktion. Im Grunde ist es die alte Auflistung aus der Vor-Vista-Zeit. Die Programme und selbst Office greifen zum Glück noch auf die alte Auflistung zu. Will heissen: Erweiterte Drucker.{2227A280-3AEA-1069-A2DE-08002B30309D} Ich erstelle jeweils auf dem Netlogon Share einen solchen Ordner, dann muss ich nicht lange danach suchen. Greift immer auf die Daten des Systems zu auf welchem man sich befindet und nicht wo der Ordner gespeichert ist. ;) In dieser Auflistung kannst auch mehrere Drucker markieren und gesammelt zuverlässig rauswerfen und neu verbinden. Zusammen mit aktuellen Treibern von guten Business-Geräten und die andere Auflistung ist im Normalfall wieder "repariert". EDIT: Wenn auch in den Programmen die Drucker falsch angzeigt werden dürfte es mühsamer werden. Dann dürfte etwas generell verkonfiguriert sein.