Weingeist

Sofern dich das noch interessiert: Lizenztechnisch gibt es da keine Einschränkungen. Supported ist sicher Office LTSC auf Windows LTSC, egal ob Server oder Client. Das muss halt klassich per Device lizenziert werden. Office 365 ist dagegen so eine Sache. Offiziell schreiben die nicht supported auf den LTSC-Releases. Inoffiziell lauffähig mit Sicherheit 30 Monate ab release, also solange das normale Herbst-Build im Support ist. Dann gibts aber doch wieder offizielle Microsoft Artikel wo drin steht bis wann das trotzdem geht. Grund sind die ganzen RDS die es überall gibt. ;) Siehe z.B. https://learn.microsoft.com/en-us/microsoft-365-apps/deploy/deploy-microsoft-365-apps-remote-desktop-services MS wird zudem die Cash-Cow Office nicht beerdigen indem es Bedingungen so macht, dass es nicht mehr läuft. So wenig wie sie Office LTSC beerdigt. Sprich die Ausnahmen dürften noch eine Weile Bestand haben oder sogar erneuert werden. Office kommt in ein paar Tagen als LTSC.

Salut Zusammen, Kann mich mal jemand erleuchten ob es zwingend alle Varianten braucht oder nur die höchste Nummer 1.417.xx. 1.375.xxx 1.405.xxx 1.417.xxx Hintergrund meiner Frage: Es gab in der Vergangenheit Updates welche den Component-Store von Server 2022 zerschossen hat wenn die Updates der Unterschiedlichen Versionen im gleichen Atemzug installiert wurden. Auf diesen Maschinen war dann keine Bereinigung des Comonent-Store mehr möglich, sprich C: hat sich aufgebläht. Eine Reparatur schlug fehl, egal mit welcher Quelle. C war dann noch viel grösser aufgebläht. Also entweder so gelassen oder mit einem Inplace der gleichen Version gefixt. War ein Neustart zwischen 1.375 und 1.405 war die Installation kein Problem. Irgendwann so gefühlt nach einem Jahr hat MS dann mal ein (normales Monats CU) Update rausgebracht welches den Component Store tatsächlich wieder gefixt hat und Bereinigungen wieder möglich waren. Hatte schon jemand anderes diese Eigenart? Kann man die heute gefahrlos zusammen freigeben? Sollte man eine Version vor der anderen freigeben damit Installationsreihenfolge korrekt ist? Oder muss man sowieso nur die neueste freigeben und die anderen sind obsolet? Grüsse und Danke

Wie gesagt, ich würde einerseits die Kommunikation prüfen und auch die Einstellungen von Windows Update vergleichen und wens identisch ist, mal manuell mit dem Powershell-Script anstossen. Es muss etwas unterschiedlich sein, der Update-Client dürfte es nicht sein, aber irgend eine Einstellung. Möglich ist auch, dass ein Inplace die klassiche Update-Art verwendet und eine Neuinstallation die neuen kleinen Files und das Du nur eines von beidem in WSUS aktiviert hast. Daher Einstellungen vergleichen. Frisch aufgesetzt vs Inplace. Wenn Du alte Einstellungen drin hast, kann das problemlos eine neue Version der Update-Geschichte lahmlegen. Wenn bei W11 alles über UsoSvc läuft (weiss ich nicht, W11 noch nicht analysiert) und früher über wuauserv dann kann es auch sein, dass deine Firewall-Rules nicht mehr passen (Wenn Du Standard-Block-Out drin hast und neue Freigaben fehlen würden). Daher, FW-Logs aktivieren, dann siehst ob und wohin die Kommunikation geht. Ein paar Reg-Pfade zum vergleichen: HKLM\SOFTWARE\Microsoft\PolicyManager\default\Update HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate sowie die Wow64 Pendants Und ja Windows hat manchmal die Eigenart zu sagen, dass alles gut ist, obwohl gar keine Kommunikation möglich ist. Ich würde ja generell sagen mach alles neu, im kleinen mache ich das immer so. Aber bei so vielen würde ich da auch ein paar Stunden investieren. ;)

Bei einem Windows 11 Build dürfte es nicht an veraltetem Update Client liegen. Allerhöchstens an einem veralteten WSUS. Ist aber auch eher unwahrscheinlich. Synchronisiert der WSUS überhaupt die Windows 11-Updates? Sonst hilft nämlich alles nichts. Zum test könntest auch mal einen neuen Windows 11 aufsetzen und schauen ob der die Updates kriegt. Und da MS mit fast allen Builds irgendwas an den Update-Einstellungen rumschraubt und gleiche Einstellungen auf unterschiedlichen Builds teilweise unterschiedlich wirken, würde ich mal schauen ob Du einen aktuellen GPO-Satz mit aktuellen Einstellungen hast und verteilst. Oder mal nur den WSUS selber per GPO verteilen, keine sonstigen Einstellungen wie Internetadressen verhindern oder ähnliches. Am besten als FQDN und mit SSL. Das Powershell-Script von hier: https://woshub.com/pswindowsupdate-module/ nehme ich gerne um Industriemaschine up to date zu halten (Dienste deaktiviert). Das erzwingt eine Kommunikation zuverlässig und sofort. Wie auch immer es das anstellt. Zusätzlich könntest das Logging für die Windows-Firewall bzw. BFE aktivieren. Dann siehst ob etwas geblockt wird bzw. oder die Kommunikation an den falschen Ort gehen will. In Deinem Fall würde ich failure und success aktivieren. Zu guter letzte dann noch die Kommunikation mit Wireshark oder so prüfen. 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 Wenn Du exakt wissen möchtest welcher Dienst wohin möchte, musst den Update-Diensten wie bits, wuauserv und usosvc einen eigenen Hardlink auf die svchost.exe spendieren und im Dienst hinterlegen (z.B. svchost_bits.exe). Dann kannst gut analysieren. Die Exe erscheint dann auch im Sicherheitslog. Die Einträge erscheinen in Sicherheit. Am besten erstellst dann eine gefilterte Ansicht für die Eeignisse der BFE. Auch die Loggrösse würde ich auf mindestens 250 MB hochschrauben.

ReFs crasht grundsätzlich nicht einfach so, normal hat das eine gravierende Ursache und die musst Du herausfinden. Durch sein Design können sich die Sicherheitsfeatures die ein Crash des Fs verhindern sollen, aber je nach Situation nachteilig statt vorteilig auswirken. Also nur ein Reboot und dann wars Geschichte und vorher keine Probleme? Darf man fragen warum er dann einen Neustart braucht wenn man nichts gemacht hat? Crash? EventLog gab nix her? Dedupe aktiv oder nicht? Wenn das ein RAID 10 ist (Was für ein Controller? Pseudo oder richtiger?) Warum hat das OS und die Datendisc kein eigenes Volume? RAM-Probeleme könnte ich mir heute am ehesten noch vorstellen, dass es bei ReFs auch heute noch Ärger machen könnte. Zum Beispiel ein Memory-Leak oder ein RAM-Fehler. Bei ersterem Crasht normal irgendwann das OS. Erkennbar ist es daran, dass der effektiv "freie" RAM (Kontrolle z.B. mit dem Ressourcenmanager) immer kleiner wird und jener der bereinigt werden könnte, nicht bereinigt wird. Geschieht gerne mal bei langer Laufzeit. Ein abgeschossenes ReFs hatte ich deswegen aber nie. Richtige RAM-Fehler können insbesondere wenn sie nicht als solche erkannt werden, alle möglichen Auswirkungen haben. ReFs nutzt ziemlich exzessiv RAM wenn z.B. Dedupe aktiv ist. Fehlendes ECC ist dann ein Totschläger.

Schon etwas her aber.... Zu Deiner Frage: LTSC 2021 ist eine neue Version. Daher wird auch eine neue Lizenz benötigt. Wenn Du mindestens eine laufende SA auf ein Enterprise Produkt hattest, wird Dir auch die LTSC angezeigt. Das Upgrade ist also nur umsonst bei laufender SA bzw. Bestandteil von den Leistungen die Du gekauft hast. Etwas Hintergrundinfo: LTSC braucht eigentlich keine SA. Aber Du kommst quasi nicht zum Nutzungsrecht einer LTSC ohne SA. Zumindest ist mir spontan kein reines Upgrade ohne SA-Zusatz bekannt. Das geht nur mit einer "IoT LTSC" welche dann auch 10 Jahre statt nur 5 Jahre Support wie die "normale" LTSC geniesst. Durch den Ablauf der SA von einer Enterprise-Lizenz beschränkt sich das Nutzungsrecht auf die LTSC-Verison. Sprich Du darfst zwar die normale Enterprise Version nicht mehr benutzen, aber die zum Zeitpunkt des Auslaufs gültige LTSC Version nach wie vor. Einschränkung: Vorausgesetzt Du hast eine Kauf- und nicht eine reine Mietlizenz! Natürlich darfst Du auch vorher schon LTSC einsetzen.

Auch wenn als gelöst markiert, war das Volume durch 2022 erstellt worden oder hast Du es von einem älteren OS übernommen? Da habe ich mal von einem Szenario gelesen, dass dies in seltenen Fällen Probleme machen kann. Habe mich nicht näher damit befasst weil ich immer neu erstellt habe. Es würde mich aber brennend interessieren wie der exakte Werdegang war. Hatte schon ewig und retour kein zerschossenens ReFs mehr. Überhaupt braucht es dafür unter normalen Betriebsbedingungen sehr viel. Ganz am Anfang - so vor 10-12 Jahren - führte das Überlaufen eines Volumes zu einem solchen Szenario. Wobei das wenn ich mich richtig erinnere nicht durch das "normale" kopieren zustanden kam, sondern wenn eine Datei die grösser als der freie Platz war, abgeändert wurde. Mittlerweile gibt es da aber entsprechende Sicherheitsvorkehrungen.

Fals es noch hilft, ich finde Orgamax sehr gut geeignet solange man keine Produktion anbinden möchte. Aber das kann man eh mit allen 0815 Lösungen knicken. Eigentlich mit das beste was ich schon gesehen habe. Habe schon viele Jahre Erfahrungen mit denen in ein paar Umgebungen. Support ist bis anhin auch sehr gut und schnell. Die Kosten für die Module, Arbeitsplätze und verschiedene Mandanten sind allesamt äusserst überschaubar und den Preis wert. Kostet eigentlich immer alles etwa gleich viel. Von der Anschaffung bis hin zu den Anpassungen. Die Anpassungen werden üblicherweise nur einmalig bezahlt und bei Versionsupdates kostenlos angepasst sofern notwendig. Auf Wunsch machen sie auch noch Bezahllizenzen statt Miete. Nur Umsatzsteuerupdates erfordern zwingend ein Update. Selbst Automationen sind möglich. Mittels einem speziellen Dienst können Datenbankmanipulationen vorgenommen werden. Kann man nicht selbst erstellen nur sie selbst. Dafür stellen sie die Funktion auch bei Updates sicher. Ein Kunde nutzt das z.B. um automatisiert Warenbestände ausgleichen weil er bestimmte Funktionen nicht nutzen möchte weil es schneller von Hand ist aber anders schneller mit dem Computer. Aus Sicht des ITlers ist die Lösung etwas albacken im Hintergrund. Die Lösung nutzt zwar - wenn man möchte - eine zentrale Datenbank auf einem Server, viele Filter-Operationen werden aber dennoch auf dem Client durchgeführt. Sie profitiert wie so viele KMU-Lösungen von schneller Single-Core Leistung, zackigen Festplatten mit niedriger Latenz und ein möglichst latenzarmes und schnelles LAN. Aus meiner Sicht überwiegen aber die Vorteile bei weitem.

Dazu findet man sehr viele Threads. Auch hier. Würde mal die SuFu bemühen. Oft liegt es anf folgenden Problemen Die korrekten Updatekategorien sind nicht für die Synchronisierung freigeschaltet (Einstellungen im WSUS). Banalste Variante. Neusync fällig nach ändern. Computer zieht sich bereit selber die Updates von MS Online (gängiges verhalten, da MS in den letzten 10 Jahren gefühlt mit jeder Build die GPO-Auslegung der Update-Richtlinien geändert hat). Frage mich nicht mehr zu den exakten Details der einzelnen Builds. Short Answer: Entweder Du verabschiedest Dich vom Central Store oder verwendest einen einheitlichen Build welcher die GPO's allesamit identisch verabeitet. Ist ein Problem wenn die GPO im Central Store lagern und mit einem System gesetzt werden und man gar nicht erkennt, dass die Einstellungen unterschiedlich wären. Ist ein Problem wenn man wirkungsvoll verhindert hat, dass sich PC's von MS Online Updates ziehen können, der WSUS aufgrund "falscher" GPO aber gar nicht korrekt kontaktiert wird. Die Verbindung möchte als SSL aufgebaut werden aber der Server bietet kein SSL. Oder der falsche Port genommen. Oder die Firewall blockiert einen Teil der Kommunikation/Schlüsselaustausch Man nimmt unübliche Anpassungen vor welche vom "Windows Update Health Service" zurückgesetzt werden.

Genau. In Kleinumgebungen gibt es je nach Betrachtungsmeise für den Einen bessere Argumente. Für die Entscheidung ist m.E. eher Ausschlaggebend was AD für einen Zweck erfüllt. Reine Authentifzierung im Einschichtbetrieb oder eben auch Live-Daten von ERP/Exchange etc. Aber eben, dazu gibts genügend Diskussionsbeiträge im Forum Host in AD: Also für mich ist irgendwie die Aufnahme ins AD unlogisch, auch wenn es technisch machbar ist. Imho sollte die getrennt vom Rest sein. Sonst sind auch immer alle für saubere Trennung, warum hier nicht? Imho mit etwas vom wichtigsten. Ausser es ist wirklich eine eigene AD-Struktur für die Infrastruktur. *schulterzuck* Soweit irgendwie möglich heisst das für mich immer eine physische Trennung von Infrastruktur und produktivem Netz. Mindestens eigene physische Netzwerkkarte, eigene Switches, eigene Admin-Kiste(n). So brauchts ein VM zu Host Break. Diese Lücken sind äusserst selten. Dann ist die Versicherung ziemlich sicher auch ohne MFA zufrieden im Infrastrukturbereich.

Wieso genau sollte das nicht funktionierten? Ein Block funktioniert natürlich genauso selektiv wie eine Allow-Regel. Das Problem ist nur, dass man es nicht auf DNS-Namen machen kann. Der Ansatz der Windows-Firewall ist im Grunde so einfach wie effizient. Block gewinnt immer, insbesondere auch wenn sich Bereiche mit Allow-Regeln Überschneiden. Es gibt keine Reihefolge, es werden immer alle Regeln ausgewertet. Die einzige Ausnahme ist die generelle Standard-Block Regel. Die blockiert nur, wenn es vorgängig keine erlauben Regeln gab. Im Grunde gibt es mit diesem Ansatz nur einen echten Nachteil, es wird etwas mehr Rechenleistung verbraten als theoretisch nötig wäre. Dazu sei noch erwähnt: Die Filterung auf einzelne Windows-Dienste - insbesondere wenn sie über die svchost.exe laufen - werden immer öfter maskiert. Das heisst, die BFE erkennt auch nicht mehr, welcher Dienst nun für die Kommunikation zuständig ist. Dafür gibt es nur einen mir bekannten, hässlichen Workaround, der Dienst braucht seine eigene svchost.exe (Am besten als Hardlink, damit es Updatefest ist und nicht veraltete svchost.exe existieren können). Dabei ist wichtig, dass gruppierte Dienste auf die gleiche svchost.exe bzw. Hardlink verweisen sonst können sie nicht mehr miteinander kommunzieren. (Das gilt nur für die Dienste, die auch dann einen gemeinsamen Prozess haben, wenn das OS bei der Installation mind. 4GB RAM hatte). So kann man ihn dennoch selektiv freigeben. Nur ist das nicht Update-fest im Sinne von neuen Windows-Versionen/Reparaturen. Manche Wartungsdienste setzen zudem manuelle Änderungen an Pfad der svchost.exe zurück (z.B. Update Health Service). In Deinem Fall musst Du also die Standard-Regel block aktivieren und anschliessend - Für Zugriffe welche von z.B. Client auf diesen Server erfolgt: Eine In-Regel erstellen - Für Zugriffe welche von diesem Server auf andere Server erfolgt: Eine Out-Regel erstellen Der verlinkte Artikel von testperson trifft den Nagel auf den Kopf um eben wirklich selektiv Geräte und Benutzer zu definieren welche überhaupt erst eine Verbindung aufbauen dürfen. Was genau sie dann kommunzieren dürfen, geschieht über die Rules. Geht natürlich nur, solange eben Kerberos durchgängig verfügbar ist wo entsprechende Zugriffe erforderlich sind. Zusätzlich kann man noch RPC-Protokolle für beliebte Einfallstore sperren. Wie z.B. EFS, Druckerwarteschlange auf normalen Servern und Clients. Die Druckerwarteschlange braucht nur in der Funktion als Printserver Remote-Zugriff. Hier wird auch ein Vorteil sichtbar, wenn Drucker lokal installiert werden, man kann die externe Kommunikation bereits vollständig auf Protokollebene rausfiltern (auch wenn das oft lästig in der Pflege ist). Das verschafft unter Umständen Vorteile bezüglich der Verbreitung von Malware im Netzwerk und hilft möglicherweise, dass ein Problem möglichst auf einer Maschine bleibt.

Im Grunde gibt es ein paar Grundsätze und dann sollte es (wieder) funktionieren. Habe jetzt mehrere Umgebungen aktualisiert und eigentlich spielt es gar nicht so eine Rolle ob es RDS oder andere Maschinen sind. Bei RDS ist nur das Verhalten auffälliger weil ebene deutlich mehr Köche den Brei verderben können und oft auch tun. Das Problem ist übrigens kein reines 2019 oder 2022 Problem, auch 2012R2 oder neuere Windows Clients zeigten dieses Verhalten. Manchmal ist es schlicht Zufall das es tut bzw. sieht man die Logik dahinter nicht oder nicht auf Anhieb warum es tut oder eben nicht. Das wichtigste überhaupt: Verbinden ausschliesslichen über FQDN und nicht über den Computernamen oder gar die IP. Server.domain.suffix\Freigabe Hat man das einmal gemacht, ist das Kind im Grunde in den Brunnen gefallen. Warum ist das ein Problem? Verbindung via der IP-Adresse oder dem Computernamen werden mittels NTLM authentifziert und nicht via Kerberos. Das macht aber nicht nur bei deaktiviertem NTLM Ärger sondern eben auch wenn es noch aktiv ist. bei Netzwerkdruckern/Laufwerken kann das auch sonst reinpfuschen. Es gibt aber auch die andere Variante, trotz deaktiviertem NTLM findet eine Fallback statt und eine Verbindung kann aufgebaut werden. Aber nicht immer zuverlässig und meist grottenlahm. Wieso das geht, verschliesst sich mir. Wie verhindert man das effektiv? Keine Ahnung Was wenn der Ärger schon passiert ist oder die User eben selber verbinden? Mühsam Wie löst man es? Siehe unten =) Prävention: Verknüpfungen auf Printserver / Fileserver in die öffentlichen Dokumente ablegen. Logischerweise als FQDN Sprich ich spekuliere darauf, dass die Leute zu faul sind, selber etwas einzutippen. Das funktioniert hervorragend. Zusätzlich verbinde ich die normalerweise benötigten Drucker per Login-Script. Ob man das pflegen möchte ist jedem selbst überlassen. Meine Umgebungen sind klein, Arbeitsplätze meist fix und die GL jeweils faul, daher automatisiere ich das. Je grösser und je weniger fixe Arbeitsplätze desto aufwendiger. Aber auch mehr Manpower vorhanden. Netzwlaufwerke versuche ich zu vermeiden, ist in der Industrie aber nicht immer möglich weil Software nicht mit UNC klarkommt. Dann sollte man das Rendering dem Printserver überlassen. Ich deaktiviere Client Side Rendering für Netzwerkdrucker. Den Tipp mit den generischen Treiber kann ich bestätigen. Und mit richtigen Business-Druckern hat man generell viel weniger Ärger mit Printern. Angenommen man hat nun also den Ärger: Abhilfe bringt hier alle Druckerverbindungen in der Registry zu löschen. Systemweit wie User-basierte. Wo die Orte sind, findet man per Registry Suche nach einem alten Drucker bzw. dem Printservernamen raus. Manchmal auch via der IP(s). Auch die Anschlüsse der Drucker sollten/müssen auf die FQDN lauten. Diese werden ja oft nur einmalig erstellt, da hilft es dann nicht zwingend wenn man per FQDN verbinden möchte, der Anschluss aber als IP oder Computername hinterlegt ist. Hier liegt manchmal auch der Hund begraben wenn das vermischt wird. Wie auch immer das möglich ist, jede Kreativität konnte ich nicht nachstellen, aber so manches angetroffen und manches wohl auch durch mich verschuldet, insbesondere in älteren Umgebungen wo das FQDN-Thema noch nicht ganz so verbreitet war. Daher nach den IP-Adressen suchen und allfälige Anschlüsse rauswerfen wenn sie nicht schon andersweitig gelöscht wurden. - die Auflistungen unter HKLM\System\CurrentControlSet\Control\DeviceClasses die Einträge enthalten *##?#SWD#PRINTENUM#* - die Auflistungen unter User: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\UserSID\Printers\Connections\Printername - die Auflistung unter: HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\UserSID\Printers\Connections\ - \HKEY_USERS\.DEFAULT\Printers\ConvertUserDevModesCount - \HKEY_USERS\UserSID\Printers\ConvertUserDevModesCount Und dann gibts noch Herstellerabhängige Einträge. Die müssen manchmal auch möglichst alle raus. Vorgängig Treiber rauswerfen verhindert potentiellen Ärger bzw. stellt sicher, dass die Einträge wieder neu angelegt werden. Was mir mal aufgefallen ist, als alles nichts half (ältere Umgebung): Der Treiber muss wohl via einem Admin-Konto erstmalig auf die Maschine gelangt sein. Ist dem nicht so runterwerfen, Registry cleanen und den Drucker erstmalig mit einem Local-Admin verbinden. Auf alle Fälle habe ich es bis jetzt noch nicht erlebt, das man den Printserver oder das Printing mit V3-Treiber nicht wieder sauber zum laufen bekommen hat. Da meine Umgebungen immer recht überschaubar sind und das ganze sobald man weiss was man beachten muss, normal recht schnell durch ist, habe ich dazu noch kein Clean-Script geschrieben. Ist auch nicht immer ganz trivial wegen der vielen Orte wo das hin kann und GUID's die man allenfalls nicht kennt usw. Vielleicht hat ja mal jemand die Zeit und Musse dazu.

Och, das Netz ist voll von Ärger die NLA betreffen. Entweder schraubt MS da immer dran rum oder das Teil "erarbeitet" sich irgendwelche Werte auf deren Basis es dann zukünftige Reaktion macht. Oder es ändern sich Bedingungen die zu unterschiedlichem Verhalten führen. Ich sage ja, es wäre äusserst hilfreich wenn jemand eine Doku zu NLA besorgen könnte. Die Reihenfolge der Netzwerkadapter inklusive der ausgeblendeten spielt wohl auch irgend eine Rolle. Hatte es vor Jahren in einer Umgebung vollständig im Griff. Ohne jegliche Scripts, verzögerung des NLA-Starts etc. Dann kam das VMXNET3 Adapter Update welche alle Netzadapter gelöscht und neu installiert hat (inklusive neuer MAC's war "interessant"). Danach reagierte die Umgebung identisch wie alle anderen. Überreste vom alten Adapter verblieben damals in der Registry. Auch die Wartungsadapter von z.B. der Intel ME scheinen einen Einfluss zu haben. Wie auch immer, es bleibt für mich zu undurchsichtig. Daher habe ich es aufgegeben. Und das einzig zuverlässig ist das Deaktivieren/aktivieren der Netzadapter oder ein anderweitig angestossenens "Update" des Netztadapters wie das "aufwachen" oder sofern möglich "ipconfig /renew". Schön wärs wenn man ein Update bei fixen IP's anstossen könnte ohne den Adapter zu deaktivieren. Noch schöner wenn man das Verhalten schon vor dem Start beeinflussen könnte. Alle Maschinen die es nämlich von Haus auf können, haben z.B. die Computerrichtlinien-GPO's innerhalb 1-2 Sekunden verarbeitet, bei den anderen dauert es so 5-10 Sekunden. Gleicher Host, gleiche Hardware-Version, gleiche Netzwerkkarte.

Ob ein Cluster wirklicht läuft / funktioniert siehst Du erst, wenn man einen Failover oder geregelten Umzug macht/machen musst. Vorher geht man davon aus, das es so ist. Auf welcher Grundlage auch immer man das entscheidet. Um wie viele VM's gehts den überhaupt? Der VM ist der Unterbau ja grundsätzlich egal solange sie wieder die Ressourcen bekommt die sie benötigt. Warum nicht zwei Maschinen in das neue Cluster und alle VM's migrieren? Allenfalls kalt statt warm? Mit einem Cluster-Spezi? Kleiner Anhaltspunkt: Viele Tools die Maschinenübergreifend agieren funktionieren nicht richtig wenn man Remote-Registrierung oder Remote-Verwaltungsdienste nicht laufen oder entsprechende Firewall-Freigaben fehlen. Natürlich kann man auch pedantisch die Firewall-Regeln/laufende Dienste zwischen den Servern abgleichen. Auch DNS ist immer wieder ein Klassiker für sehr vieles das nicht richtig tut. Ansonsten: Aktiviere mal das Firewall-Auditing und erstelle eine gefilterten Ausgabe für Packet-Block im EventViewer. --> Wird in Security geloggt, dann siehst was nicht ankommt/rausgeht. Relevante Nummern: 5152, 5157 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 Die Protokollgrösse würde ich auf mindestens 64MB (65536) hoschrauben eher das Vierfache. Mit - tasklist /svc - netstat -a -b Kann herausgefunden werden welcher Prozess es betrifft der allenfalls Freigaben braucht.

NLA startet man aber nicht (mehr) ohne so weiteres durch. Ist mittlerweile ein geschützter Dienst bei neueren Builds. Den kannst nur mit taskkill und entsprechenden Berechtigungen zur Aufgabe zwingen. Starten tut er wieder selbst. Ob das aktuell immer noch so ist oder ob das wieder geändert wurde, habe ich schon ein weilchen nicht mehr getestet. Ansonsten hilft in der Regel folgendes vorgehen: Fixe IP: Adapter deaktivieren/aktivieren den man zum Update von NLA zwingen will Dynamische IP: ipconfig /renew reicht aus. Also auch für einfache Benutzer machbar. (allenfals Adapterspezifisch) oder eben auch Adapter Aktivieren/Deaktivieren. Letzteres seit geraumer Zeit nicht mehr 100% zuverlässig, warum, keine Ahnung. Meine Scripts mit Aktivieren/Deaktivieren funktionieren jedenfalls nicht mehr zuverlässig. Was wohl nachhaltig gegen NLA-Ärger hilft: Komplette Neuinstallation mit aktueller ISO und integrierten Updates von MS. Meine neueren Installationen machen jedenfalls keinen Ärger. Oder noch nicht Die ganzen Tipps bezüglich passive/active probing sind fast immer für die Tonne bei neueren Builds. Am besten funktionierts mit Werkseinstellungen und allenfalls angpassten Zielen für den Connectionstest etc. Was auf meiner Todo-Liste steht: Auswerten was bei ipconfig /renew oder aktivieren/deaktivieren alles an Registry Werten geändert wird. Allenfalls wird da irgend ein Counter hochgestuft welcher von NLA geprüft wird. Wo wir wieder beim triggern wären. Ich bin mir fast sicher, dass es irgend einen WMI-Befehl geben wird, welcher ein Update eines Netzadapters oder sonstigen Entscheidungsgrundlagen für den NLA anstossen kann. Gibts ja für fast alles. Das wäre dann zuverlässig. Ich selber habe leider zu wenig Ahnung von WMI um mich da durchzuwühlen. Allenfalls hat auch der NLA-service versteckte Befehle mit dem man ihn triggern könnte bis anhin bin ich aber nicht auf entsprechende Quellen gestossen. Vielleicht erbarmt sich ja mal jemand mit Connections zu MS um ein Paper zur genauen Funktionsweise von NLA zu erhalten und allenfals Trigger die man manuell anstossen könnte.

Du könntest auch einfach nen WSUS aufsetzen in dessen Netz Du neue Maschinen hängst. Da wirds dann ebenfalls nur einmal gezogen. Mache ich schon Jahre so für die ISO's die nicht von MS aktualisiert werden weil das für mich einfacher ist als ständig ISO's zu pflegen. Nachbearbeitung dann mit nem Script welches über alle Windows-Versionen hinweg funktioniert. Die Konstellation spart mir ne Menge Zeit, die Anpassung an neue Builds sind meist minimal. Für 1000 Clients sicher zu aufwändig, wenn immer wieder für eine oder auch verschiedene Firmen mit wenig Clients notwendig, ist das ziemlich praktisch. Die Anforderungen an die Kommunikation sind minimal. Allenfalls sogar mit Treibern *hust* (Dann ganz sicher mit richtigem SQL-Server und WAM-Script... Wäre zum testen. Mit Business-Notebooks wäre die Chance am grössten, dass aktuelle Treiber vorhanden sind.) Wäre dann das gewohnte "Gefühl" ohne viel Scripten und Imagepflege (die mich angurkt, es sind einfach zu viele). Ansonsten: Du tust Dir tatsächlich die Hersteller-Loads an? Puuuuh das wäre nichts für mich. Dafür habe ich kein Nerv. Die Kisten sind meist sooooooooo viel schneller ohne die ganze Hersteller-Bloatware. Zumal ich nirgendwo Pro haben möchte.

Mal ein kurzes Feedback zum aktuellen Stand. So theoretisch wurde mit dem Oktober bzw. November Update ja eine Menge "geforced" bezüglich NTLM-Deaktivierung. SMB Der Würg-Around mit einer Remote-Authentifizierung via NTLM gegen lokale Konten funktioniert zum aktuellen Zeitpunkt nach wie vor. Auch mit SMB-Hardening-Features. Theoretisch hätte das nicht mehr funktionieren sollen. Zumindest hat es nicht mehr funktioniert wenn man es selber NTLM deaktiviert hatte. Die GPO scheinen also noch zu ziehen. Aufbau: Zwei Maschinen die sich mit DFS-R einen Transfer-Ordner replizieren Maschine 1 (Filer): Verbindung zu DC, Maschine 2, allgemeines Netzwerk, NTLM durchwegs nicht erlaubt Maschine 2 (Relay): Verbindung auf einer Seite zu DC, Maschine 2 sowie dem Maschinennetz, NTLM erlaubt via GPO Da ich NTLM auf dem DC durchgängig geblockt habe (ohne Ausnahmen), scheitern Authentifizierungsversuche mit Domain-Konten gegen den DC via Relay wie gewünscht. Authentifizierung von lokalen Konten gegen das Relay funktioniert hingegen. Die CA Nun die scheint auch weiter zu funktionieren. Warum und wie auch immer die sich authentifizieren kann ohne das eine Ausnahme definiert werden muss. Ist mir immer noch ein Rätsel. Scheint eine hardcoded Ausnahme zu sein. Fazit: Scheint als sei das enforcement nicht durchgesetzt worden seitens MS. Das legen auch ein paar Internet-Recherchen nahe. Angeblich plant MS NTLM noch mindestens zwei Jahre zu unterstützen. Bis sie ihre eigenen Hardcoded-NTLM-Geschichten gelöst haben. Zu guter letzt soll Kerberos wohl aufgebohrt werden damit eine einseitige NTLM-ähnliche Authentifizierung ermöglicht wird. Wie auch immer das sicher gemacht wird. Habe ich mich noch nicht eingelesen. Auch ist wohl ein lokaler KDC auf jeder Maschine in Planung der NTLM auf lokaler Ebene ablösen soll. Naja, immerhin hat MS genügend Angst gemacht, dass man sich vermutlich endlich darum gekümmert hat das möglichst vollständig aktiv abzuschalten wo möglich. Zumindest mir gings so, auch wenn ich nicht 100% damit gerechnet habe weil Basis-Features wie die CA nicht ohne NTLM funktionieren und ein paar grössere Hersteller noch immer tiefenentspannt waren. Aber böse bin ich nicht... dachte die SMB-Relays seien schon dem Tod geweiht und ich müsste die mühsame - dafür sichere - shared disc Geschichte mit eigenem Lock-File weiter ausbauen.

@zahni hmm seltsam. Ich habe in allen Umgebungen immer max 50 Geräte und die WSUS DB dümpelt sehr oft so um die 9-10GB rum. Ist oft ein Eiertanz, total nervig. Daher viele wieder zurück auf intern gewechselt. Aber eben, ist etwas fragwürdig da nie ein CU gefragt wird und auch manuell keins installierbar ist. Aber oft halt einige Office/Windows Versionen. Clients wie Server. Industrie halt, da gibts meist alles irgendwie und irgendwo. Vielleicht sagt sich MS: Man kann bei internen DB eh nix via LAN abfragen, also unnötig. Wenn jemand auf die Maschine drauf kommt, ists eh gelaufen. Keine Ahnung. Die interne DB lässt sich schon länger mit den Tools administrieren nur sind manche Tweaks nicht machbar, sonst schiesst man die interne DB ab weil eine Überprüfung seitens MS fehlschlägt. In kleinen Umgebungen kann man damit aber leben. Die restlichen Tweaks von WAM reichen da aus.

Performance oder Sicherheitsgründe weil sie nicht wirklich Updates erhält? Die Express-Variante ist schon mit wenigen Clients recht schnell am Anschlag. Ist immer ein Riesentheater mit der DB-Grösse, man bewegt sich quasi immer am Limit wenn man nicht wirklich nur eine OS/Office Version hat. Kam eigentlich davon weg und habe (wieder) interne genommen nachdem ich vorher jahrelang Express genommen habe.

Kannst auch einfach schauen obs läuft... Nur weils noch nicht supported ist, heisst es nicht, dass es nicht läuft. Wenn Du Pech hast, gibts halt irgendwo Ärger. Kommt etwas auf die Anzahl Arbeitsplätze an die betroffen sind und wie sehr es den Betrieb stören würde, wenn es Ärger macht. In einem Callcenter würde ich das nicht machen, im Büro mit 10 Nasen schon. ;)

hahaha, spasseshalber schonmal versucht er weiss es natürlich nicht. Karl Klammer war wenigstens noch etwas lustig und nicht nur unnütz Naja ganz Unnütz ist dieser hier nicht, solange er nicht intelligent werden will. Sprich eigentlich würde ich ja vor allem die Option "Intelligentes Nachschlagen" und das Popup der Hilfe weghaben wollen weil ich das eh nur aus versehen anklicke und dann wieder schliessen muss.

Unabhängig von dem Sinn oder Usinn: Funktionen kann man auch deaktivieren. Das benötigte Stichwort ist: Fluent User Interface Control Identifiers Man erhält einen Download bei MS mit einem Excelfile pro Applikation. Jedes Control hat eine ID, diese kann man in den GPO's eintragen als blockiert. Die meisten sind Programmübergreifend, aber nicht alle. Ist manchmal nur etwas mühselig das Gewünschte zu finden. Hätte z.B. gerne die ID für "Was möchten Sie tun" und konte ihn noch nie auffinden.

@mwiederkehr Naja, im Grunde gibts das alles. Sofern Du dich mit den Prepare-Tools abmühst oder die entsprechenden Reg-Flags zum passenden Zeitpunkt manuell setzen tust... Ist halt immer wieder fällig oder aber du automatisierst es mit dem Wissen, dass es bei der nächsten Build wieder anders sein könnte. Wenn Du kein Bock hast immer die ISO's / XML anzupassen reicht es oft, wenn Du ein Script mit den entsprechenden Einstellungen in die ISO reinkopierst, im richtigen Moment mit Shift+F10 die Konsole öffnest und das Script ausführst. Das ist dann sogar fast immer Build und Server/Client OS übergreifend funktionsfähig. Je nach Option halt. Aber ja ich bin bei Dir, ich gehe davon aus, dass 99.9% aller Admins exakt die gleichen Einstellungen treffen würden was Deine angesprochenen Punkte betrifft. Ungefähr so wie mit der elenden Explorer-Ansicht die man seit gefühlt W95 mühsam in den Default-User bringen muss. Ab einer gewissen Grösse sind solche Scripte sicher zu mühsam. Aber im kleinen ist das oft einfacher als die ISO für jede OS-Art und jeden Kunden jedes mal anzupassen. Aber ja ich bin absolut bei Dir. Ich habe im Industriebereich auch schon Server statt Client OS eingesetzt. Insbesondere seit LTSC nur noch 5 Jahre hat. Die paar hunderter Differenz zwischen Pro+Upgrade mussten sie einfach schlucken. Dafür alles recht flexibel. Mittlerweile aber auch gerne IoT LTSC.

Geht irgendwie in die gleiche Richtung wie mit dem Edge... man drückt es mit Gewalt durch, auch wenn er deinstalliert wurde und stellt es dann so dar als wäre das von allen so gewollt Irgendwie traurig, dass man dies auch im Server-Bereich nötig hat Aber vielleicht waren es ja tatsächlich ein paar Grosskunden die das gewünscht haben damit sie weniger Arbeit haben. Wobei die wiederum die Tools und das Knowhow gehabt hätten das problemlos zu automatisieren. Ich tippe mal auf möglichst viele dazu animieren...

Eine solche Karte wie Du es vorhast einzusetzen würde ich grosse Abstand nehmen. Hat nichts verloren in einem Server. Eigentlich nichtmal in einem Privatsystem. Du hängst quasi Deine ganzen Produktiv-Daten an eine einzelne Karte von einem Günstig-Anbieter. Wenn Du etwas mehr Flexibilität als von HP, Dell etc. willst, kauf einfach von Supermicro. Da gibt es eigentlich alles was man möchte. Auch als Komplettsysteme, mittlerweile sogar mit Wartung. Ich mag deren Systeme weil man hochwertigste, flexible Single-CPU Systeme zusammenstellen kann wie das bei den anderen in der Vergangenheit nicht möglich war. Dazu noch ohne Vendor-Lock. Das Zubehör hat moderate Preise und nicht Faktor 2-3 mit Vendor Lock um es durchzusetzen. Nimm am besten U.2 Systeme mit direkter PCI Express Anbindung.