Weingeist

Ist das geil, grad köstlich amüsiert... Die spinnen die Röm.... äh Redmonder Witzig ist: Das ist nur in der Englischen Version vom VLSC so, die EVAL kann das Nicht *hahahah*

@NorbertFe Die WINS-Schwäche ging ja mal völlig an mir vorbei *autsch* Danke für den Link! Im Text wird von Replikation gesprochen und die Reproduktion des Problems zeigt ebenfalls Einträge bei der Replikation. Kommt das nur zum tragen wenn WINS repliziert wird oder auch bein einem Single-Server? @TO: Also ich kann Dir nur ebenfalls mit Nachdruck empfehlen SMB1 nicht zu aktivieren. Das wird bereits fleissig ausgenutzt durhc Malware.

Diese Lizenz ist nur für Zugriff von Nicht-Windows-PC's gedacht/erforderlich und lassen sich eigentlich nicht auf Windows-Clients anwenden. Für Windows Client PC's die auf Windows Client VM's auf eine physische Maschine ohne Hauptbenutzer (*) zugreifen, braucht man auf der zugreifenden Maschine eine laufende SA für W10. Damit das möglich ist, heisst das Upgrade auf Enterprise oder eben eine neumodische Subscription pro User/Gerät. Oder eben ein Nicht-Windows-Gerät unter VDA. Die installierte Version auf dem Server selber braucht dafür keine Lizenz. Ansonsten sind (Nicht-administrative) Remote-Zugriffe im Grunde nicht erlaubt. Spassig wenn man zu Hause ein PC (Upgrade + SA), in der Firma ein ZeroClient (VDA) und Unterwegs ein Tablet (VDA) hat und sowohl auf Server und Client OS zugreift. Sind dann pauschal die RDS-User Cal für das Server OS sowie 2x VDA In der Vergangenheit wurden mir bei einem Audit aber auch schon RDS-Lizenzen als erlaubte Zugriffsart durchgewunken. Pauschal für Client und Server-Zugriff. Obwohl eigentlich gar nicht so richtig für Clients vorgesehen. Allerdings musste ich RDS-Lizenzen auch schon zusätzlich für die User/zugreifenden Geräte lizenzieren weil auf Workstations im Rack nicht mit definierten Endgeräten/Benutzer gearbeitet wurde sondern diese über einen Broker liefen. Ich vermute RDS wird oder wurde stillschweigend - oder im Nicht-Vorgesehen-Fall auch vorgeschrieben - als Lizenzierung für einen Remote-Zugriff geduldet. Da RDS aber eine Kauf-Lizenz ist, tendieren sie heute dazu einem in eines der neuen Subscription-Pläne Modelle zu drücken wo dann meines Wissens alles abgedeckt ist. Dann brauchts auch die Duldung nicht mehr. Auf alle Fälle begreifen die ihren Jungle den sie da fabriziert haben ja selber teilweise nicht mehr. Total beknackt. Sinnvoller wäre hier eine Gebühr pro Mitarbeiter/User wie sie aktuell ja gerade am umsetzen sind bzw. man teilweise schon so kaufen bzw. eben nur mieten kann. Sprich RDS - von mir aus auch unter SA - für alle Remote-Zugriff akzeptieren. Aber das wäre wohl zu einfach und einfach ist im Hause MS nicht mehr erwünscht (WSUS ist auch zu einfach) (*) Hauptbenutzer gibts nur wenn Maschine keinen gemeinschaftlichen Zweck hat. Sämtliche Server fallen somit raus, auch wenn nur einer hauptsächlich darauf arbeiten würde.

Update: Da dies ja selten Systeme sind die unter enormer Last stehen wo ein Single-Host-System überhaupt in Frage kommt bzw. problemlos ein Fenster gefunden wird wo wenig bis nix los ist, hält ESXi auch ein Update + Reboot der Storage-VM aus. NFS ist da nicht wirklich kritisch. Der Reboot dauert mit potenten SSD's/NVMe's keine Minute. Aber selbst wenn es etwas länger dauert ist das für die paar IO's absolut kein Problem. Timeout setzt man ja allgemein höher als mit physischen Maschinen. Der "normale" IO Stau bei ausgelasteten Maschinen im grossen Umfeld dürfte da deutlich höher ausfallen. ;) Drehe die VM's aber Firewall-technisch sowieso komplett zu. Netzwerkadapter ist nur im Wartungsnetz. Haben also keinen Zugang ins normale produktive Netz. Wenn es mal nicht passt, bekommen sie halt kein Update. An der Base-Filter-Engine sowie Firewall wird seitens MS sehr selten innerhalb des gleichen Builds gepatched, weil das eines der wenigen Dienste sind, die MS wirklich komplett durchcheckt bevor sie freigegeben werden. Wie gesagt, wenn es um Hochverfügbarkeit geht, ist das sowieso der komplett falsche Ansatz und eine völlig andere Preisklasse. Das Prinzip mit der Storage VM ist gut für ein erweitertes Single-Host-Prinzip. Sprich alles auf ein oder zwei Maschinen und Sicherung auf die Platten der jeweils anderen Maschinen + evtl. lokal (Auch hier der Vorteil von NFS, kann komplett mit Windows Bordmitteln erledigt werden wenn gewünscht und Kosten gespart werden soll). Klar hätte ich auch lieber überall eine super performante SAN, wenn möglich noch gesynct, aber das ist bei meinen Systemen aber so gut wie immer ausserhalb des Budgets und eigentlich auch der Notwendigkeit. Aber so kann ich halt auch bei kleinst-Umgebungen eine +- saubere Dienstrennung machen und auf schnelle und zuverlässige Speicher setzen. Das hilft mir mehr die laufenden Kosten tief zu halten und das ich keine ungeplanten Einsätze habe. Mein Recovery-Zeiten mit ~300-500MB/s bei VMDK's sind auf alle Fälle zackig. Und das Fenster macht man ja bekanntlich für den Worst-Case, also z.Bsp. Ausfall der Backplane. ;) Mir macht beim dem Prinzip nur die Ransomware-Problematik Sorgen. Bei ner SAN hat man Hardware Snapshots die im schlechtesten Fall dem Stand eines Strom-Crashes entsprechen wenn wirklich unabhängig vom Netz (da keine Agents). Da muss ich das Konzept um etwas zusätzliches erweitern das Kostentechnisch nicht überbordet und einfach in der Handhabung ist.

https://www.diskpart.com/articles/ssd-read-only-mode-7201.html Vielleicht hilfts. Ansonsten Kiste mit ner Setup-CD starten und dazu zwingen... Letzte Option mit Hex Editor Bootbereich manipulieren (glaube kaum das notwendig). Möglicherweise hat die SSD auch einen Schuss. Gut möglich wenn länger Stromlos. Manchmal klappts mit Reformatieren, manchmal nicht. Manche "erholen" sich auch wieder.

Immer wieder interessant wie etwas andere Ansätze erstmal verschrien werden bevor man sie genau prüft. Im Endeffekt ist es genau gleich gelöst wie es VmWare vor ein paar Jahren mit der Storage-Appliance gemacht hat oder wie es andere Anbieter nach wie vor als Alternative zu vSAN machen. Nur mit dem Unterschied, dass die Appliance Windows ist, welches nachweisbar sehr robust ist. Sowohl NTFS als auch ReFs und auch Storage Spaces. Alles bewährt und funktionstüchtig. Ob nun explizit dafür zertifiziert oder nicht. Da ist im Grunde nichts komplexes daran. Es wurden auch jahrelang MS-Cluster, Exchange etc. auf VmWare betrieben obwohl MS den Segen extrem lange nicht offiziell dazu gab. Einfach weil es funktioniert hat und keinen Grund gab warum es nicht hätte funktionieren sollen. Schlicht weil es Software war, die nunmal funktioniert hat. Und Cluster sind komplexitätstechnisch in jeder Hinsicht eine andere Liga als eine Storage-Appliance! Zumal die darunter liegende Hardware die ich verwende jeweils für VmWare zertifiziert ist. Hatte noch nie ein Problem mit dem VmWare Support und nahme ihn bezüglich View/Horizon schon öfter in Anspruch. Ist klar das dies nichts für grössere Umgebungen ist. Aber für ein oder zwei Server funktioniert das gut. Sehr gut sogar. Die perfekte Aufstellung mit SAN oder deren zwei, Dual-Switches auf Storage und LAN Seite etc. kann da gar nicht sinnvoll finanziert werden, schon gar nicht in der gleichen Performance. Und wenn dies Ausfallsicherheit gebraucht wird, dann wird es auch finanziert und ist nicht mehr mein Gebiet. Da ich immer gleiche Basis-System nehme und nur hochwertiges Material verbaue, habe ich die Systeme mit meinen Ersatz-Teilen wenn es eilt schneller wieder oben als die Hardware-Lieferanten selber die Teile am nächsten Tag liefern. Und wenn nicht so zeitkritisch, dann auch mal ohne Vertrag. Wäre dann Pech wenn mein Ersatz genau in dem Moment nicht vorhanden ist. Dauert es halt ein bis zwei Tage bis Ersatz da ist. Windows Storage Spaces in Verbindung mit NFS traue ich jedenfalls mehr zu als fast allen Appliances die für den gleichen Zweck verkauft werden und teilweise zertifiziert sind. Einfach weil MS im Storage-Bereich sehr wenig Murks abliefert. Zumal ich mir mal fast eine Woche Zeit genommen habe um alle mir erdenklichen Szenarien für Ausfälle in Zusammenhang mit Storage Spaces in x-facher Ausführung zu simulieren. Selbst das Software-RAID aus der Windows-XP Zeit hat excellent funktioniert wenn man sich zwei kleinen Eigenheiten bewusst war. Ich habe unter XP/2003 produktiv mit Software-RAID gearbeitet wenn das Budget Hardware nicht zuliess und noch richtig Geld kostete als Software-RAID noch mindestens 10 Jahre vollständig verschrien war. Performance war ein graus, aber zuverlässig waren diese immer. Aber eben, jeder wie er mag. Ich sage immer es gibt verschiedene Wege nach Rom, nur die Ausrüstung sollte passen.

@jberlin: Na klar muss ich das selber supporten. Mache ich seit vielen Jahren. Anfangs nur für mich, dann nur VDI, später dann auch Server. Weil es einfach zu gut und unproblematisch lief. Windows Server mit durchgereichten Platten>Storage Spaces (Software RAID)>NTFS>NFS>ESXi. Bis dato hatte ich nur noch nichts zu supporten bzw. nur am Anfang weil ESXi plötzlich APD auf NFS geschoben hat unter starker Auslastung. War aber ein generelles NFS-Problem welches per Patch von VmWare gefixt wurde. Weil ich das selber getestet habe. ReFs kriegte ich nicht wirklich in die Knie und hat sich jeweils korrekt selber repariert - auch bei direkten Sektormanipulationen der Platten, On und Offline - . Festplatten ziehen, weiterschreiben, wieder rein. Strom weg etc. Nur vollaufen war und ist vermutlich immer noch ein Problem. Aber auch VMFS ist davon wenig bis gar nicht begeistert. VMFS hat selber auch gar keine lokale RAID-Funktionalität wie die Storage Spaces. Das verteilte vSAN habe ich noch nie auf Herz und Nieren geprüft. Ebensowenig wie Storage Spaces Direct. Beide nur angetestet. Bei beiden ist mir die Materialschlacht zu gross. ;) Bezüglich limitierender Faktor: Bei meinen älteren Systemen war das jeweils die CPU-Leistung. Da wird enorm viel für die virtuelle Netzwerkkarte verbraucht. Beim aktuellen Testsystem mit AMD Epyc habe ich den limitierenden Faktor noch nicht gefunden aber auch erst Quick/Dirty aufgesetzt. Entweder wird nicht alle CPU-Leistung für die Netzwerkkarte freigegeben oder die NVMe's sind zu lahm. Und ich sage ja im Titel bereits: NFS mittels Storage VM... Gründe habe ich genannt. Ich sage ja, es ist Gebastel. Aber eines das excellent funktioniert. Für mich. Wer das auf Testsystemen auch machen möchte, kann es tun. Wer es nicht möchte, lässte es einfach bleiben. ;) Ein Recovery von einer VM mit 25GB ist in knapp einer Minute durch. Läuft also zackig.

Hallo zusammen, Für alle die NFS nutzen, da scheint nun mit 2022 endlich eine NFS Freigabe auf ReFs Volumes möglich zu sein. Darauf warte ich seit es Storage Spaces und ReFs gibt - also rund 9 Jahre Scheinbar wurde die Zuordnungstabelle bei Windows-NFS auf 64bit erweitert oder ein Parser implementiert (noch keine Info dazu gefunden) Interessant ist das für die Nutzung von Windows als Storage VM unter VmWare ESXi. Mir ist klar, das ist absolute Nische und manche sehen es als Gebastel, aber es hat für mich eben einige Vorzüge weshalb ich das in Kauf nehme dafür aber in den oberen Schichten 0815 habe. Da es zudem einfach zu Verwalten, nachzuvollziehen und zudem sehr extrem crashresistend ist (Stromausfälle, Festplattendefekte etc. ), ist es für mich mehr als verschmerzbar. Braucht nur etwas mehr CPU-Power bei hoher IO Last (für die virtuelle LAN-Karte der Storage VM), aber das ist eh selten das Problem in Kleinumgebungen. - Windows und nicht Linux (KnowHow, einfache Anbindung von Zusatzsoftware, Backup, Rechteverwaltung etc.) - Nutzung der Volumes auch auf anderen Servern, zbsp. als Backup-Ziel jedoch ohne das Windows weiss wo die Disk liegt sondern eben der HyperVisor (Einfacher Umzug der Volumes etc.) - sehr robustes Dedupe auf Storage-Level - Ausschalten von VMFS als Dateisystem das deutlich weniger Crahsresistent als ReFs/Ntfs ist und für RAID entweder Controller oder teure vSAN benötigt - Keine teure SAN oder eher lausige NAS für Shared Storage und trotzdem Verwendung von hochwertiger Hardware möglich - Lokales High-Speed Software RAID möglich (mit SSD/NVMe) - extrem schnelles Recovery (Hauptproblem beim günstigen SAN's) - Ultraschneller Datenaustausch zwischen Server und Clients die auf VDI basieren (selbst lausig programmierte Server/Client Software wird dank der extrem niedrigen Latenz rasend schnell, KMU-Chefs freut das, die stört eh jede Gedenksekunde ) Man kann natürlich auch gleich HyperV nutzen, aber manchmal braucht es VmWare und ich persönlich mag die Administration von ESXi deutlich lieber als von HyperV. Zudem setze ich gerne Horizon View sowie Teradici-Software ein und benötige öfter mal einen Lizenzserver der nur unter einer Linux-Appliance unter ESXi supported wird.

Also meine Erfahrung ist: Jeder kleine Betrieb kann sich einen kleinen, guten Server + USV leisten. Zählt nicht so als Ausrede. Und sonst halt mal ein Gebrauchtgerät. Mache ich öfter mal bei USV'so. Die guten Online-Teile laufen entweder ewig oder gehen innerhalb 3-4 Jahren hops. Ist so meine Erfahrung. Von NAS als Primärspeicher halte ich lieber Abstand. Bei DC's auf so einem Gerät kringeln sich mir alle Zehennägel auf, aber jeder wie er mag. Zur Kernfrage: Alles was Windows-Kernnetz basiert ist, würde ich auch im kleinen per Namen laufen lassen. Wartungsnetze kann man gut auf IP's halten. Schlicht weil sonst wieder eine Namensauflösungs-Infrastruktur aufrecht erhalten werden muss. Ist je nach dem Overkill.

Genau so sieht es leider im Grundsatz aus aus. Klar, dass das bei 500 Clients nicht praktikabel ist. Möglicherweise kann man das ja mit WSUS oder einem Task mit erweiterten Rechten und/oder Kombi mit GPO erschlagen. Beim anmelden eines Users wird dann z.Bsp. der Task mit erhöhten Privilegien ausgeführt welcher sich pro Drucker- bzw. Treibertyp auf einen Dummy-Printer verbindet der sonst nicht verwendet wird und anschliessend die Verbindung wieder kappt. Dummy-Printer damit nicht erwünschte Printer gekappt werden. Dann ist der Driver auf dem Client. Vielleicht gehts auch eleganter mit einer Softwareverteilung wie WSUS oder etwas "besserem". Nunja, so ist es aber. Die Lücke ist weder mit den härtesten empfohlenen Einstellungen komplett geschlossen und schon gar nicht wenn man es wieder ermöglicht. Kann man drehen und wenden wie man möchte. Mögicherweise ist es aber dennoch etwas besser wie vorher. MS kann nicht einfach alles verbieten was gut wäre. Da gibts immer etwas Vorlaufzeit sonst laufen die Firmen sturm. Bei einschneidenden Massnahmen hat man fast immer 6 Monate bis 1 Jahr zeit das umzusetzen.

Eigentlich tust Du das ja. Ist ja gerade das Ziel, das Nicht-Admins die Treiber nicht installieren können. Prinzipiell Du musst einfach schauen, dass Du die Treiber schon vorher auf die Kisten verteilst, dann kann ein User den Drucker auch verbinden. Ist mit einem gewissen Aufwand verbunden. Wie genau das praktikabel geht, weiss ich auch noch nicht. Aber meine Anzahl Maschinen pro Umgebung sind auch relativ beschränkt, insofern verschmerzbar sich kurz auf jede Kiste zu verbinden.

Sehe ich durchaus auch so Der Printer-Stack ist das Muterbeispiel von völlig vergeigter Modernisierung. Alles bunt gemischt von neuen und alten Zöpfen. Solange es läuft, gut, wens nicht tut, sucht man sich nen Ast. Auch Sicherheitstechnisch dürfte es ebenso eine Sysiphusarbeit sein, dieses Gebastel vernünftig zu machen wie die Kombi von alter und neuer Technik.

Und warum willst Du das nicht auch hier so machen? Den potentziellen Ärger ist das eigentlich nicht wert. Zumindest nicht im kleinen wo kein entsprechendes Personal mit spezialisiertem Wissen verfügbar ist wenn es nachher unerklärliche Probleme gibt. Da ist das Wissen eher breit gestreut aber wenig spezialisiert auf jedes einzelne Gebiet. Ich behaupte jetzt einfach, dazu gehörst Du auch Ich persönlich starte daher immer von der grünen Wiese bezüglich OS-Installation bei Upgrades. Da kann ich diese Fehlerquelle zum vornherein ausschliessen.

Ist jetzt vielleicht fies, aber wenn es nicht klappt ist die Frage welchen Wert Du gesetzt hast. Ist das Gegenteil von dem was du in der GUI auswählen kannst. Windows verwaltet (GPO Disabled) = gut gemeint, bewirkt aber das Desaster. Enabled setzt das Verahlten auf "von früher". Allerdings gibt es noch anderen möglich Ärger. Wenn Die Netzwerkdrucker per Script getrennt und neu verbunden werden, wechselt auch der Standarddrucker unter Umständen auf etwas altes. Dann muss man ihn explizit wieder setzen. Ich meine den Ärger hatte ich auch wenn ich per GPO gesetzt habe statt Script (ist aber viel zu lange her wo ich dies letztes mal versucht habe). Ah und Nebenbei, Word und ich meine auch Excel ignorieren das gerne mal wenn sie geöffnet sind. Da musst dann explizit auch deren Prüfung abschalten, die haben seit 2007 einen eigenen Printer-Stack. Total beknackt für die Automatisierung. EDIT2: Ahja, das Setting ist übrigens User-basiert. Nicht Computer wie man meinen könnte. Direkter Reg-Eintrag: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\LegacyDefaultPrinterMode=1

MS ist bestrebt einen schönen Anteil für die Vollbeschäftigung beizutragen. Dieser Spass hat bestimmt bereits sehr viele Stunden an Arbeit für das Gemeinwohl gebracht

Die Migration mit USMT hat tatsächlich auf einer CAD Maschine mit CAM, Simus und all Ihren anderen Plugins, Einstellungen etc. in ein soviel neueres W10 Build geklappt? Ohne Side Effects?!? Also jetzt bin ich mal wirklich baff. Bis dato habe ich dem Tool wenig Vertrauen geschenkt obwohl ich bei Office-Maschinen schon positives gehört habe, aber eher aus Prinzip weil das mit der Updaterei ja auch nicht immer klappt. Aber 0815 Office-Systeme sind ja auch ne ganz andere Liga... Wenn das wirklich so schmerzfrei ist, muss ich das wohl auch mal ausprobieren...

Hauptproblem an WSUS ist, dass es zu bewährt, zu gut, zu einfach und am allerschlimmsten keine relevanten Zusatzumsätze generiert. *rofl*

Umständlich ist das nicht, im Gegenteil. Reine Gewohnheitssache. Aktiviert man das Block-Out nicht, kann man den Rest auch gleich bleiben lassen (etwas grob gesagt). Die Filter-Engine von Windows ist wirklich top und wirkungsvoll, es läuft erstmal alles über sie. Meines erachtens sollte man sich mit Ihr beschäftigen und die fehlenden Regeln die es innerhalb einer Domäne braucht selber erstellen.

Mit Nvidia kommt ein ganzer Rattenschwanz an Kosten hinterher! Und man ist immer etwas auf dem Schleudersitz ob es auch in Zukunft noch gut funktioniert. VmWare hat hier die Latte nochmals angehoben mit einem zusätzlichen Layer damit sogar VM's über Hosts verschoben werden können. Man muss sich da einfach im klaren sein, dass es Nischenprodukte sind und dementsprechend behandelt werden. Gibt zwar aktuell doch einige Bestrebungen in dieses Richtung, weil eben viele Software - leider auch Windows - mittlerweile an die Graka auslagert und somit VDI den Stecker zieht weil es eben via CPU zu ineffizient ist. Auch ist das ganze hochkomplex. Man muss schon sehr viele Kosten einsparen können damit sich das überhaupt irgendwie rechnet! Auf alle Fälle muss man sich schon gut überlegen ob man vielleicht nicht doch einfach eine physische Maschinen nehmen will, ihr einen Extender spendieren möchte damit die teure Hardware ins Rack wandert und die Maschine z.Bsp. mit 10 Gbit und kurzen Kabelwegen ans Netz kann. Der User freut sich dann über ein gutes Arbeitsklima. Kein Lärm, keine schlechte Luft. Sehr gut funktioniert hier Teradici. Aber auch andere Extender-Lösungen sind denkbar. Die Komplexität ist deutlich tiefer und wenn das PCI-Passtrough spinnt, sind nicht gleiche alle User dieses Host betroffen. Allerdings hat das durchreichen schon auch gewisse Vorzüge. Ich nutze das sehr gerne für meine eigene Umgebung. Vorteile sind super niedrige Latenz da alles hostintern ablaufen kann, und trotzdem habe ich Graka-Hardwarebeschleunigung für meine eigene Maschine. 1A für Testumgebungen. Die besten Erfahrungen - allerdings kenne ich mich diesbezüglich nur mit VmWare aus - habe ich mit AMD-Karten + einer Teradici Host-Card gemacht. Nvidia verhindert das ihre normalen Karten durchgereicht werden indem sie irgendwas verbiegen damit sie ihren teuren, spezialisierten Karten verkaufen können. Der Arbeitsplatz braucht dann einen Teradici-Zero-Client, einen SoftClient auf einem ThinClient oder FatClient. Die Teradici-Host-Card kannst ebenfals durchreichen zwecks USB-Funktionalität. Geht aber auch über einen USB-to-Ethernet Adapter wenn Du durchgereichte Geräte sparen willst. Ist halt etwas Gefrickel, läuft aber soweit stabil. ;)

Nope, Du bist echt auf dem falschen Dampfer. Das ist eben genau das was nicht funktioniert ;) Du musst In der Hauptebene der erweiterten Windows Firewall mit rechter Maustaste rein und in allen Profilen standardmässig Verkehr nach aussen blockieren. Das heisst dann auch, dass Du für alles was eben durch soll, eine Freigaberegel erstellen musst. Und da MS es seit Jahren verpasst hat, da alles reinzuschieben was reingehört, ist das mitunter ziemlich nervig wenn man nicht mit Pauschalfreigaben hantieren möchte. (Edit: Wird aber immer besser mit fast jedem neuen W10 Build ;) ) Was dann geblockt wird, erfährst Du wenn du das Auditing der Windowsfirewall aktivierst. Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Sprachübergreifend: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable https://docs.microsoft.com/de-de/windows/win32/fwp/auditing-and-logging?redirectedfrom=MSDN Ich setze jeweils noch die Loggrösse für Sicherheit rauf. Mit - tasklist /svc - netstat -a -b Kann herausgefunden werden welcher Prozess es betrifft auditpol.exe /list /category /v = GUID erhalten

Nope, Du musst in den Einstellungen der Windows Firewall selbst Outgoing standardmässig blockieren und dann das mit einer Regel freigeben was Du möchtest. Sprich es ist dann einfach alles blockiert und nur das frei was Du frei haben möchtest. Ich finde das eigentlich ziemlich gut wenn man sich daran gewöhnt hat. Klar hat auch Schattenseiten, aber das haben alle Varianten ;)

Naja, wenn Du Outgoing standardmässig blockieren aktivierst, dann kannst ja einfach die gewünschten IP's freigeben und das Thema ist erledigt. Eventuell noch mit Authentifizierung auf Netzwerkebene. Ist einfach eine etwas andere herangehensweise aber nicht per se schlechter, nur ungewohnt. EDIT: Die Standardregeln für die Freigabe von 445 natürlich erst noch deaktivieren oder eben abändern. EDIT2: Ich denke mwiederkehr meinte das gleiche mit der Standardregel. Wenn ich das richtig im Kopf habe, ist für SMB keine Systemregel hinterlegt, sollte also nicht über die Hintertür dennoch freigegeben werden.

Mich persönlich wundert das überhaupt nicht. Die grossen Anbieter analysieren ja mittlerweile komplett alles und wie fast alles hat das zwei Seiten, Schutz und Überwachung

Och ich denke das ist alles ziemlich gezielt um möglichst sämtliche "Steuerungs-Wünsche" im Keim zu ersticken und auf 0815 Deployment zu setzen. Sieht man ja überall. Für alle die was anderes wollen, werden möglichst viele Steine in den Garten geworfen damit es möglichst mühsam ist und höchstens noch Grossbetriebe und Freaks nutzen. Der nächste Office LTSC Build Office 2021 oder 2022 (wie auch immer sie ihn nennen) ist jedenfalls auch der Click2run Käse... Edit: Top ist ja, der wird dann nur ein Jahr länger supported sein wie 2016/2019 [SPOILER]Hach wäre das Adminleben einfach mit Windows 7, Office 2003 oder 2010 + dem Componentstore von mind. 8.1 + ein paar Features wie Storage Spaces. Da funktionieren Startmenüs simpel, Firewallregeln sind easy usw. Sprich User wird nicht abgelenkt und ich habe weniger Arbeit[/SPOILER]

Wohl eher um dem Admin Arbeit zu generieren... Meine Meinung dazu: Hauptsächliche Marketing um unterdimensionierte Hardware zu benutzen. Am Ende führt nichts daran vorbei, dass man die physische Leistung für die Spitzenlast bereitstellen muss. Tut man das nicht, dann läuft man irgendwann in Ärger. Entweder man lebt damit, teilt generell weniger zu damit nur auf einer Ebene ausgelagert wird oder stellt halt mehr zu Verfügung. Gilt eigentlich bei allem, IOPS, Latenz, Single-Core Potenz, Dedupe usw. Aber das weisst Du im Grunde ja sicher auch, man verdängt es höchstens ab und an