Weingeist

Klar, Deine Netze sind eine "etwas" andere Dimension. Aber das einzelne Subnet für sich ist ja auch nicht gigantisch gross. ;) Ein RPC-Filter seitens Windows ist relativ trivial. Der Filter greift auf eine der untersten Eben der BFE. Um die random Ports muss man sich nicht kümmern. Windows weiss, welches Protokoll aktuell an welche RPC-Ports gebunden ist. Die Firewall müsste ja gar nicht so viele und aufwendige Rules haben, da man die "Freigabe" oder Blocks auch an AD-Gruppen binden kann. Ich sehe es in etwa so: Wenn z.B. auf den DC's Printservice und andere Dienste abschaltet werden weil es dafür bestehende Exploits gibt und sie nicht gebraucht werden, wieso verhindert man auf den Servern nicht auch einfach alles ein einkommenden RPC-Verkehr der nicht notwendig ist oder beschränkt ihn - sofern sinnvoll möglich auf gewisse Partner? Ist ja jetzt nicht so eine Weltmeisterübung wenn man mal weiss was überhaupt benötigt wird. Die meisten sind z.B. der Meinung, EFS sei kaum sinnvoll zu verwalten, wozu dann seine Remote-Anlaufstelle offen lassen wenn genau dafür Exploits existieren (Auch wenn dafür der Dienst laufen muss). Wenn gewisse Protokolle nur für den Austausch unter DC's/CA/DFS's/Admin-WS zuständig sind und für "normale" Clients irrelevant sind, könnte man die erlaubte Kommunikation für bestimmte Protokolle an bestimmte AD-Gruppen hängen. Der Aufwand wäre überschaubar und das Problem doch eigentlich an der Wurzel gepackt, eine Kommmunikation wird zum vornherein verhindert. Ein allfälliger Explit ist zahnlos. Die Logeinträge für untypische Kommunikationsaufnahmen hätte man ja auch grad gratis dazu. Muss ja nicht gleich Whitelisting für alles sein. Die ganzen PetitPotam wären - zumindest wenn ich die Artikel richtig interpretiere - eher nicht so erfolgreich gewesen mit einer handvoll RPC-Filtern, deren "Anlaufstelle" auf DC's/CA sowieso nicht gebraucht wird.

keep it simple versuche ich auch wenn irgendwie möglich durchzusetzen. Auch das mit den Berechtigungen sehe ich genau so, auch wenn es nicht immer ganz einfach durchzublicken ist, wo und wie man genau das Standardverhalten ändern muss. Das erstellen von Benutzern/Admin Workstations welche nur in ihrem möglichst kleinen Teil und möglichst nur dann wenn notwendig Zugriff haben/anmelden können, ist noch der einfachste/offensichtlichste Teil. Für die verlinkten RPC-Protokollle gibt es aber aktive Exploits und soweit ich das richtig verstanden habe, sind die Updates von MS nur die halbe Miete und die Wahrscheinlichkeit das ähnliche Exploits auftauchen relativ hoch. Macht es da nicht doch Sinn, die problematischen Protokolle ebenfalls auf die Admin-WS zu begrenzen oder gänzlich zu blockieren wenn sie nicht benötigt werden (z.B. Remote EFS)? Gerade was via RPC läuft ist durch die variablen Ports/maskierten Services doch einigermassen schwierig via FW auf einen bestimmten Port/Endgerät zu begrenzen. Ausser man biegt es von Variabel auf fix um, was dann auch nicht mehr Standardverhalten wäre. RPC selbst kann man ja lediglich zwischen den Clients verhindern ohne Ärger zu bekommen.

@Userle Also die verschachtelte Freigabe sollte nichts ausmachen. Habe ich (mühsamerweise) aus historischen Gründen ein paar wenige solcher Konstrukte in der Pflege. Da werden jeweils auch zwei Laufwerke verbunden. Diesbezüglich noch keine Probleme gehabt. Das genannte Problem mit Random-mässig nicht erreichbaren Netzlaufwerken kenne ich vor allem aus folgender Situation: - Netzwlauferk verbunden, aber nicht erreichbar - USB Stick eingesteckt und es hat den Buchstaben des Netzwlaufwerkes erhalten - wie auch immer das geht - Das hat dann auch die lustigsten, nicht reproduzierbaren Fehlerbilder verursacht weil es einmal so und einmal so funktioniert hat. Lösung war dann allerlei Reg-Hives zu killen (Suche nach dem Laufwerksbuchstaben). Aber eben, hat eigentlich nix mit an- und abmelden von anderen Usern zu tun, daher auch der erste Lösungsvorschlag mit dem expliziten trennen der Verbindung/sauberem rauslöschen allfälliger Überrest von systemweiten Verbindungen. Bei Netzdruckern ist der Ärger vergleichbar wenn die Verbindungen nicht auf Benutzerebene geschehen und deren Verbindungen werden ja recht ähnlich aufgebaut wie Netzlaufwerke. Das fiese ist aber, nicht immer gibt es Ärger. Manchmal tuts auch einfach. Einigermassen schwierig zu reproduzieren. Was mir grad noch einfällt, das Verhalten gibt es auch bei abgelaufenen Kerberos-Tickets und aktivierten aktuellen Sicherheitseinstellungen für SMB (kerberos statt NTLM). Sobald man Desktop kurz sperrt und sich wieder anmeldet, sind die Netzlauwerke wieder erreichbar. Das trifft dann insbesondere auch auf die User-Accounts zu, die man in die "Protected-Users" gelegt hat. Das ist dann aber zeitlich nachvollziehbar und auch nicht durch Prozesse von an- und abmelden von anderen User beeinflusst.

Wie gesagt GPO "Automatisch herunterladen und gemäss Zeitplan installieren." setzen und nicht nur den Zeitplan selbst. Wenn das nicht zieht, die GPO's tatsächlich auch ausgeführt werden bleibt Dir nur der beschwerliche Weg den ich beschrieben habe wenn Du das wirklich steuern möchtest. Testen musst Du es mit den aktuellen Versionen die Du einsetzt mit +- aktuellem Patchstand. z.B. manuelles installieren von März-Rollups sowie vorher .Net vom Februar aus dem Updatekatalog, dann einbinden in die Domäne und schauen ob und wie er die restlichen Updates zieht/installiert.

Kriegt man nicht so easy weg. Soweit ich das beurteilen kann, ist das auch ein Verhalten das bewusst so geschaffen wurde um ein Umdenken zu erzwingen. Ist das Oberchaos und sogar zwischen Builds und manchmal sogar Update-Rollups anders. Sprich jede Build bräuchte seine eigenen, spezifischen GPO's auf die es normal auch richtig reagiert. Generell kann man sagen, dass die Einstellungen mit den Verzögerungen nur ziehen - wenn sie denn ziehen -, wenn man ebenfalls folgendes konfiguriert: "Automatisch herunterladen und gemäss Zeitplan installieren." Auch "keine Verbindung mit Windows-Internetadressen herstellen" sollte man aktivieren, sonst kann die Übermittlungsoptimierung das auch umgehen. Gibt aber auch Builds, die dann auch vom WSUS nichts mehr holen (hat ja auch eine https-Adresse). Wie gesagt, das totale Desaster um den Admins wohl den Verleider anzuhängen, das konfigurieren zu wollen. Auf Server OS - sicher in 2022 - funktioniert mittlerweile das "nur Herunterladen aber manuell installieren" wieder. Wurde wohl aufgrund zu grossem Druck wieder geändert. Ansonsten kann bei einem Client OS gesagt werden: Irgendwie kriegt Windows die Updates immer und wenn es via der Fernwartung ist weil die Maschine durch den Hersteller eine Internetverbindung bekommen hat. 100% Gewissheit hat man nur bei abschalten von Windos Medical Service und fast noch wichtiger, dem entsprechenden Task im Taskplaner und die Deaktivierung der Übermittlungsoptimierung. UpdateDienst kann normal anbleiben. Dann z.Bsp. per Task den Service aktivieren wenn man installieren möchte. Dumm nur, das das Zeugs teilweise TI-Rights braucht die man nicht so ohne weiteres bekommt. --> Auf Industriemaschinen biege ich daher die relevanten Services auf eine eigene svchost.exe um (Hardlink) und aktiviere/Deaktiviere Updates via einer Firewallrule indem ich die Diensteigene svchost erlaube oder blockiere. Auf normalen Clients limtitiere ich die Verbindung auf den WSUS, somit kann er nicht ins Internet. Funktioniert 1A. Mit Firewall-Rules kann man auch mit minimalem Aufwand das Update zum gewünschtem Zeitpunkt angestossen werden ohne gross Services an und abzuschalten. Nur der Task des Medicalservices muss ausbleiben, der korrigiert sonst die svchost.exe wieder auf das original. Auf Servern/Industriemaschinen deaktiviere ich die Übermittlungsoptimierung vollständig und ziehe die Updates mit dem Powershell-Script rein (Get-WindowsUpdate) Lässt sich mit Tasks auch recht Dirty automatisieren ;)

Hallo zusammen, Habe mich mal etwas mit den RPC-Filter der Windows Firewall befasst. Habe zwar die Empfehlung für die Blockierung von Remote-EFS damals blind umgesetzt, aber eingehend damit beschäftigt bis anhin nicht. So wie es aussieht sind RPC-Angriffe einigermassen beliebt und effizient. Vielleicht auch weil es selten konfiguriert wird? 1. Frage: Hat sich jemand schonmal mit einem Whitelisting beschäftigt? Sprich alles an RPC zu blocken und nur das gewünschte zu gewünschten Empfängern zuzulassen? Oder einem Black-Listing? Also quasi je nach Client oder Servertyp? Gibt es Empfehlungen dazu? Habe zwar etwas recherchiert aber nix sinnvolles gefunden. Da es doch ein paar Protokolle gibt, wäre der Aufwand nicht ganz unerheblich. 2. Frage: Wie rollt man das am einfachsten aus? Per Start-Script oder geht das eleganter? "Rumpfuschen" in der Registry mit GPP braucht bei Firewall-Rules normal nen neustart. 3. Frage: Wie hoch ist der tatsächliche Nutzen? Bei PetitPotam scheint es ja jedenfalls die Attacke zu verhindern. Grüsse und Danke Dann noch etwas Lektüre zum Thema für die die es interessiert: Interessanter Beschrieb: https://www.akamai.com/blog/security/guide-rpc-filter#why Die technische Doku bei MS zu den Protokollen (für die GUIDs): https://learn.microsoft.com/en-us/openspecs/windows_protocols/MS-WINPROTLP/e36c976a-6263-42a8-b119-7a3cc41ddd2a Ein paar bekannte Attacken und wie man sie blockt/filtert: https://github.com/jsecurity101/MSRPC-to-ATTACK (Leider schon etwas älter? Keine Ahnung ob obsolet oder nicht) Etwas mehr Details: https://www.tiraniddo.dev/2021/08/how-windows-firewall-rpc-filter-works.html

*Hmpf* auch ein Artikel den ich übersehen habe. Irgendwie bin ich zu doof immer alles auf dem Radar zu haben. Gibts eigentlich irgendwo eine Auflistung über alle Massnahmen die von MS gepflegt wird inkl. aktuellem Status sowie die Umsetzungsphasen etc? Würde manches vereinfachen :-/ Generell kann man sagen: Je früher man aktiviert desto besser. Ich aktiviere meist nach dem TryAndError Prinzip. Schauen was allenfalls nicht mehr geht und darauf reagieren. Oder erst Audit, beheben und dann aktivieren. Grund: Wenn MS das ganze propagiert, mit Timelines versieht etc. ist der Exploit entweder gut bekannt und wird bereits ausgenutzt oder er ist es spätestens wenn MS so granulare Infos bereitstellt. Da wird dann das Verhalten von Windows entsprechend analysiert und darauf reagiert. Bezüglich diesem spezifisch dSHeuristics: Gibt es einen empfohlenen, möglichst "sicher" Wert den man eintragen sollte? Sobald ja der Wert vorhanden ist, müssen alle Flags gesetzt werden, zumindest bis zu dem Flag, den man braucht. Ist irgendwie nicht alles so trivial beschrieben bei MS was nun genau empfohlen wird. =)

Kommt auch etwas aufs interne KnowHow drauf an. Teamviewer ist halt sehr trivial im Management. Aus technischer Sicht gefällt mir nicht, dass die Applikation mittlerweile brutal aufgeblasen ist und somit auch sicher ein paar Löcher aufweist. Mir würde da würklich der primitive Bildschirm-Tastatur-Maus Transfer genügen. Die haben in der Pandemie aber soviel verdient, dass vielleicht auch etwas in die Code-Härtung geflossen ist. ;) Ich machs meistens so: Eine kleine Workstation für den externen DL die im Netz hängt (zum Beispiel mich). Die WS kann je nach Art des DS auch eine VM sein Darauf Teamviewer oder dem DL sein Remotetools installiert Die Workstation kommt entweder übers "normale" Netz oder via eigenem Mobilfunk-Router ins Internet. Letzteres hat den Vorteil, das auch Probleme mit dem Internet gelöst oder zumindest erkannt werden können. Der Kunde kann somit immer schauen was die DL so treiben. Schafft Vertrauen und Transparenz. Egal ob sie es verstehen was getrieben wird oder nicht. Damit die Verbindung eben nur auf Wunsch des Kunden erstellt werden kann und nicht permanent, verwende ich zwei Varianten. Manchmal auch kombiniert. ganz klassisch wie im Maschinenbereich üblich einen Schalter um z.B. die Stromversorgung des Routers oder des Switches zwischen Router und PC zu kappen zwei kleine Scripts (Achtung, keine änderungsrechte für Nicht-Admins!) die per Taskplaner mit höheren Rechten gestartet werden können - auch von Usern - welche die Zulassungsregeln für Teamviewer oder Remote-Tool des Herstellers innerhalb der Windows-Firewall aktivieren oder deaktivieren. Zwei Verknüpfungen auf den Desktop welche die Tasks starten können, fertig. In der Nacht läuft dann automatisch das Trennen-Script wenn es vergessen wurde. Für die elektrische Trennung Schlüsselschalter wenn täglich erlaubt, z.Bsp. ein Zentfenster mit einer 0815 Zeitschaltuhr ein PowerSwitch den man softwaremässig steuern kann (z.B. Net IO) z.Bsp. auch mit Scripts Ein Taster welcher den Schütz mittels Timer-Relay anzieht. Das Relay deaktiviert nach einer bestimmten Zeit dann den Schütz und somit die Stromversorgung. Löst das Problem der Leute, die den Schlüsselschalter aus bequemlichkeit immer auf 1 lassen. Kann man auch mit dem Schlüssel kombinieren. Ist für jeden verständlich, Taster leuchtet = Zugriff erlaubt, Taster leuchtet nicht, Zugriff nicht erlaubt). Die Abneigung gegen VPN ist bei mir ähnlich gross wie gegen WLAN. Wird nur getoppt durch betriebsfremde USB-Sticks. Ist mir schlicht zu komplex in der Absicherung und etwas mehr das ich pflegen müsste, ohne dass ich einen echten Mehrwert in den Umgebungen hätte die ich pflege. Dann mag ich halt einfach keine fremden Arbeitsstationen direkt im Netz mit denen ein DL auch bei anderen Kunden rumschwirrt. Die sollen möglichst mit internen Maschinen arbeiten. Mir fällt da immer die Story unseres Tierarztes ein, der meinte, seine Berufsgattung sei in der Regel hauptschuldig für die Verbreitung von Tierseuchen. Man geht von Stall zu Stall und vernachlässigt oft die Hygiene bewusst- weils mühsam ist - oder unbewusst und verteilt so munter die ganzen Viren, Bakterien und sonstigen Schädlinge. Danach wundert man sich, wie sich eine Seuche so schnell verbreiten konnte. Da war der Vergleich zu unserer Branche nicht weit. Im Maschinenbereich leider nicht ganz so einfach durchzusetzen wegen deren sehr spezifischen und sehr teuren Programmen. ;)

Gerade weil Du vorher anscheinend nicht im User-Kontext verbunden hast, kann das durchaus Ärger geben wenn die Verbindung nicht sauber gelöscht wurde oder wenn Du bei manchen im User-Kontext und bei anderen Systemweit verbindest. Versuch mal auf dem Laufwerk im Script zuerst aktiv einen unmap mit net use bevor du es erneut mappst. net use LW: /d Das komplette, saubere rauslöschen einer Systemweiten Verbindung ist übrigens manchmal nichtmal mit Admin-Rechten sondern nur mit System-Rechten möglich. Entweder das Script so laufen lassen oder eben in einer Konsole mit Systemrechten. (Psexec -i -s cmd.exe) Wenn es serverseitig ein Problem wäre, könntest Du das ebenfalls die Einträge der Freigaben in der Registry unter HKLM\CurrentControl\services\LanManServer\shares vergleichen. Also du Guten mit dem schlechten. Sehen die gleich aus, z.Bsp. die Anz Users oder Permissions, dann dürfte es am Client liegen.

Also ich verstehe nicht wirklich was Du genau tun musst, kannst oder sollst und was davon freiwillig ist und was nicht. Egal was die Aufgabe ist, alles in Verbindung mit Storage Spaces ist nicht 0815. Nicht böse gemeint, aber aktuell sehe ich tendenziell schon ein Begriffsproblem oder ein Unverständis bei Dir welche Technik für was zuständig ist. Somit ist es eigentlich auch umöglich zu sagen wie man Dir helfen soll. =) Unterstützugn kann ich Dir aber mal mit den Begrifflichkeiten und Hintergrundinfos geben, fange mal von vorne an: Storage Spaces: Ist ein hochentwickeltes, sehr Crash-Resistentes Software-RAID. Allerdings ist das ganze nicht mehr im klassischen Sinn basierend auf relativ starren Discs, sondern das Kernstück ist ein Datenblock/Stripe welcher je nach den gewünschter Performance (Anz Discs pro Stripe - 1 bis X coluns) und Sicherheitsanforderung (Anz. Kopien - 1 bis 3) über die Disc(s) verteilt wird. Wenn Du mehr dazu erfahren willst, kann z.Bsp. ein paar alte Threads von mir hier suchen. Müsste ein paar Jahre her sein. Storage Spaces Direct: Ist die Ausdehnung des Konzepts über mehrere Nodes hinweg. Soweit dürfte das klar sein. Das ist das Fundament, also die Speicherung und die Bereitstellung von Datenblöcken zu definierten Kriterien für ein Volume. Im Gegensatz zu einer Disc bzw. Disc-Set auf einem klassischen Hardware-Controller oder Einsteiger SAN welches das Performance/Sicherheitskozept im Voraus festlegt und darauf dann die Volumes erstellt werden. (Etwas vereinfacht gesagt) Der Denkfehler den viele machen ist, dass SOFS und Storage Spaces Direct das selbe sind bzw. zusammen verwendet werden müssen. Was aber so nicht stimmt. Storage Spaces Direct stellt "nur" die Plattform/Unterbau für die Datenblöcke/Volumes zu Verfügung, wer die Veröffentlichung des Volumes übernimmt, ist Storage Spaces Direct egal und zuständig dafür ist es auch nicht. Also das was normal die SAN macht. Ist quasi also auch schon etwas Hyperconverged zusammen mit einer Veröffentlichungs-Rolle (vergleichbar evtl. mit NetApp-Filer). Danach kommen also die verschiedenen Varianten wie ein solches Sammelsurium an organisierten Datenblöcken als Volume veröffentlicht werden und wer somit wie in der Lage ist, diese abzurufen, zu verändern, zu erstellen etc. Das erledigen dann die Cluster-Rollen welche für die Veröffentlichung zuständig sind. Die Cluster Rolle welche die Veröffentlichung übernimmt, schert sich aus klassischer Sicht nicht um das WIE die Daten dahinter abgesichert sind, sie schaut nur, dass sie das gleiche Volume/Blöcke im Fehlerfall des Hosts über einen anderen Host zu Verfügung stellen kann. Sind die Speicher-Blöcke nicht mehr verfügbar, hat sie zwar ihren Job erfüllt, aber es ist trotzdem down. Normal ist das die vollständigem SAN-Ausfall, bei Storage Spaces halt wenn alle Nodes down sind. Ein per NFS-Rolle/iSCSI Target oder "normalem" SMB-Fileserver zu Verfügung gestelltes Volume kann speichertechnisch über alle Nodes laufen, ist aber im Grunde punkto Zugriff ein klassisches Cluster im Aktiv/Passiv Modus. Also läuft der ganze Traffic eines Volumes über einen Node. Fällt dieser aus, übernimmt der nächste Node die Veröffentlichung der identischen Daten. Beim iSCSI Target wird das Volume als Block-Storage weitergegeben. Sprich das ganze File-Handling und somit auch die Pflege der Filetable wird weitergegeben and den Empfänger des Volumes. Ein Teil der Vorzüge von SP sind somit obsolet und man hätte wohl mehr Freude an einer klassischen SAN welche gleich Block-Storage veröffentlicht. Ein Scale-Out-Filse-Server (SOFS) läuft mit den neuesten SMB Erweiterungen, Anbindung an ESXi zum aktuellem Zeitpunkt deshalb nicht möglich. Wie bereits andere kommunziert haben. Dieses Konstrukt läuft im Active-Active Modus. Die Last/Zugriffe kann über mehrere Nodes verteilt werden. Das ganze produziert für jeden File-Zugriff aber einen deutlich höheren Overhead als z.Bsp. normales SMB oder NFS, daher wird es eben aktuell auch nur für vDiscs und Datenbanken empfohlen weil da verhältnissmässig wenig Open/Close/Berechtigungsanfragen/resize stattfinden. Im Grunde spricht aber nichts dagegen einen SOFS als normalen hochverfügbaren Fileserver einzusetzen, wenn alle Clients SMB 3.0 unterstützten und man auch sonst ein paar Dinge in Kauf nimmt, die schlicht noch nicht umgesetzt sind (Weiss ich grad nimmer auswendig, manches davon wie Dedupe geht schon, manches nicht). Dem Konstrukt ist eigentlich egal ob die Files 2TB oder 1MB gross sind. Aber der Zugriff wird tendenziell langsamer sein. Nicht zwingend die Übertragung selbst, sondern das drumherum. Das arbeiten mit einer Access-DB ist mit sicherheit langsamer, das speichern eines Worddokuments wird vermutlich total egal sein. Verschieben von ganzen Ordnerstrukturen mit tausenden Files verursacht eine ziemliche Last. Handling mit grossen Files ist aus Ausfalltechnischer Sicht und der damit einhergehenden Arbeit das ganze wieder online zu bringen, kaum zu toppen. Auch für normale Clients. Anmerkung: Ob SOFS Nicht-SP-Direct Volumes unterstützt kann ich nichtmal sagen, da nie probiert. Findet man aber sicher schnell raus in den Dokus oder mit Tests. Möglich das es notwendig ist, möglich, dass es unabhängig davon ist. Je nach dem wie eng die Layer verzahnt sind/entsprechende Prüfungen erfolgen. Ich tippe gefühlsmässig auf abhängig. Überlasse ich Dir nachzuforschen. Auch das Caching geschieht über verschiedene Ebenen. Write/Read mittels der Tiers auf Poolebene (nicht im eigentlichen Sinne ein Cache,aber irgendwie schon), dem RAM als Read welches Windows sowieso benutzt (allerdings eben wirklich nur für sehr kleine Files von ein paar KB, die grenze kann man mit dem überschreiben von Sektoren herausfinden, Daten nicht mehr da, aber Windows liest die Datei noch korrekt, zumindest spätestens bis zum Reboot), sowie den Cluster-Cache welches zur Zeit die einzige Möglichkeit ist, RAM als schnellen Read-Cache für grössere Files zu Verfügung zu stellen. Dieser ist allerdings Hostbezogen (Keine Ahnung wie das technisch genau funktioniert in Verbindung mit SOFS, da blicke ich nicht ganz durch, tippe darauf, dass einfach der Cache des Host für den Client zuständig ist, via jenen man gerade zugreift, was es ineffizent machen könnte. Wäre noch zu untersuchen/erforschen, heute vielleicht in Dokus). Genau dieser Umstand macht das "normale" Storage Spaces auf einem Single-Node mit Magnetplatten ultralahm. Weil eben der RAM-Cache durch die Cluster-Rolle zustande kommt. Man bräuchte also eine Single-Node-Cluster um davon zu profitieren. Oft kann man aber mit SSD und NVMe gut leben, weil deren Latenz tief genug ist (Daher empfehle ich auch immer Enterprise-HDD's zu nehmen. Diese haben normal eine relativ gute Durschnitts-Latenz, das macht das schreiben und lesen insbesondere mit mehreren Discs pro Stripe/anz Columns auch ohne Cache schnell, weil immer die aktuell langsamste zählt. HDD ist konstant lahm, da konstant hohe Latenz.). Die moderne Art der Verbindung zum SMB ist dann "SMB-Direct". Das lagert Lanspezifische CPU-Zyklen an hochspezifische LAN-Karten aus (RDMA). Notwendig ist das nicht, aber sehr vorteilhaft. Alles was in Verbindung mit Storage Spaces die Latenz senkt, hilft der Performance enorm. Salopp gesagt ist Storage Spaces aktuell auf Geideh und Verderb mit der Latenz verheiratet. Weil eben die Cache-Möglichkeiten aufgrund der Ausfallsicherheit im Vergleich zu klassischen SAN's mit Batterie/Kondi Puffer des RAM's eher Stiefmütterlich sind. Ist diese tief, rennt es, ist sie hoch, lahmt es. Möglicherweise hat hier Intel Optan RAM Abhilfe geschaffen oder wird es in Zukunft (nachforschen, aber wäre prädestiniert dafür). ;) Mein persönliches Fazit Der grösste Showstopper von SP direct ist dem hochverfügbaren, sehr modernen Konzept geschuldet. Damit das ganze überhaupt einen Sinn macht und man aus der Komplexität auch einen Nutzen hat und eben nicht nur Komplexität entsteht die im Fehlerfall eben seinen Dienst versagt, sollte man mind. 4 Nodes betreiben und die Sache entsprechend verstehen. Ist also eine ziemliche Schlacht an Hardware für eine Minimalkonfig und wird erst mit der Skalierung besser. Um zu verstehen warum das so ist, muss man etwas tiefer in die Funktionsweise von Storage Spaces und ReFs tauchen. Die Lektüren sind bei MS aber deutlich besser als vor 10 Jahren, da durfte/musste man das meiste selber herausfinden. Auch warum es optimal 4 Discs/stripe-sets (columns in SP) und nicht wie für RAID 1 deren zwei für einen 2-way Mirror (obwohl es geht!) und deren 5 für einen 3-Way Mirror auf einem Single-Node. Auch möchte man eher nicht direkt einen SOFS für die Clients und gleichzeitig für die VMs auf den gleichen Maschinen. Da würde man die unterste Ebene der Infrastruktur direkt ins LAN stellen. Tut man aber mit den iSCSI Adaptern der SAN auch nicht. ;) So kommt man recht schnell zum Schluss, dass man produktiv entweder eine SAN nimmt oder sich sonst ein paar andere Gedanken machen muss, wenn man keine so grosse Infrastruktur unterhalten/finanzieren möchte (z.Bsp. Single Host mit Storage Spaces statt Hardware-RAID dafür ultraschnelles Recovery). Für den Spieltrieb gibts nicht viel cooleres als SP, zumindest für mich =) Was man beachten sollte beim Entscheid Mit Hyperconverged sind dann ein paar Spielereien möglich die entweder wirklich besser auf der Spielwiese bleiben oder wenigstens eine hervorragende Doku benötigen. Sonst lässt man es besser. Oft erfüllt ein deaktiviertes aber separat repliziertes DFS-Target für File-Services seinen Zweck genauso gut. Noch wichtiger ist, dass einem die Einfachheit der Assistenz-Konfiguration nicht über die Komplexität von Storage Spaces hinwegtäuschen soll. Eigentlich wie bei vielem, insbesondere bei Cluster. Die sind schneller am Ausfall beteiligt, statt dass sie davor schützen als einem Lieb ist wenn man die Infrastruktur vernachlässigt. Nur sind hier die Auswirkungen unter Umständen recht dramatisch, ähnlich einer sterbenden SAN. Mit dem Unterschied, dass die grossen Hersteller einen excellenten Support und Rep-Abteilung haben. Bei Storage Spaces sind die Experten sehr rar und sie zu finden ist ist auch schwierig. Ein paar Tips zur Umsetzung Insbesondere mit wenigen Discs/Hosts ist der Assistent tendenziell unbrauchbar (er macht stripes über zu viele Discs) und man muss selber via Powershell ran. Paradox, weil Grossumgebungen sicher mit Powershell erstellt werden. Man sollte recht genau wissen wie es funktioniert, sonst fällt einem Storage Spaces gerne auf die Füsse (wobei die Kontrollmechanismen von Windows 2022 heute viel besser sind als noch mit 2012). Wenn man aber genügend Zeit in die möglichen Fails investiert und versteht was SP daraus macht (speicher voll, strom weg, strom aller hosts weg, Festplatte kappen, Bad-Sectors erzwingen, DB-Write unter Last usw.), ist Storage Spaces ausfallsicherer als vermutlich jeder Hardware-Controller den man in eine 0815 Büchse steckt (von denen durfte ich in den letzten 10 Jahren so einige tauschen, für Magnet nehme ich die noch). Dann noch die fast vergessenen Ärgernisse die heute noch, wenn auch abgeschwächt bestehen: Der Tod von fast jedem Pool oder ReFs Volume ist übrigens Speicher der ausgeht. Das passiert schneller als einem Lieb ist und man geneigt ist anzunehmen, verursacht durch die Funktion die das Fileystem eigentlich schützen sollte. Insbesondere beim hantieren mit sehr grossen Files die verändert und wieder gespeichert werden, da immer erst die Daten neu geschrieben werden, dann die Metadaten aktualisiert und erst dann der Speicher der alten Kopie wieder freigegeben wird. Daher auch lieber gleichgrosse Platten verwenden, auch wenn man geneigt sein könnte einfach alles an Platten reinzuschieben was gerade so rumliegt. Da verliert man den Überblick über den effektiv freien Speicher für eine grosse Operation nicht. Das sollte man höchstens in grossen Pools und lieber single Hosts/testumgebungenm datengräber. Das "auffinden" von defekten Festplatten erfordert ein Gehäuse welchse auch beim richtigen Slot "leuchten" kann. Hat man das nicht, hilft nur eine Doku. Sonst endet es böse. ;) Ein (eigentlich sehr) wichtiger Bug war mit Version 2019 leider immer noch "schlimm", also nicht behoben. Nicht immer wird ein Mehrheitsentscheid erzwungen. Sprich hat man einen Three-Way Mirror, muss es nicht sein, das die zwei guten Sets das schlechte Set überstimmen. Sprich gibts im Set 1 einen unerkannten Bad Sector, heisst es leider nicht zwingend, dass SP dieses Set korrigiert und stattdessen den Wert der andern Zwei nimmt. Wovon man aber eigentlich ausgehen würde, wozu sonst mehrere Mirror und Prüfsummen. Gilt eigentlich auch beim 2-way, weil grundsätzlich sind meines Wissens Prüfsummen mit von der Party via den Metadaten, sprich SP wüsste eigentlich wenn ein Stripe inkosistent ist und könnte den Stripe von der Kopie lesen und diesen verwenden, wenn er OK ist. Die Wartungsjobs (Aufgabenplanung) erfüllen den Job zwar manchmal, aber dann ist es eventuell zu spät, da bereits gelesen und gecrashed. Manchmal erfüllen Sie ihn auch auch falsch. Wie es mit 2022 aussieht weiss ich nicht, produktiv vorgekommen ist es bei mir noch nicht nicht oder ich habe nichts davon bemerkt. Ist aber auch eher selten bei SSD's, wenn es vorkommt, ist sie meist eh am Ende. In der Testumgebung erzwingen war aber durchaus möglich. Mit 2022 habe ich die Tests noch nicht gemacht. Zum Schluss: Für das testen ist wichtig wie das OS die Discs erkennt/markiert. Als physische Discs oder eben als Shared Disc. Eine Shared Disc kann man nicht einem Storage Spaces Direct Pool hinzufügen. Eine Phyische-Disc nicht einer Cluster-Rolle für die Veröffentlichung der Daten. Notfalls muss man das für Testumgebungen umbiegen. Sorry wurde etwas länger, aber einkürzen bräuchte noch mehr Zeit, das überlasse ich Dir :-P

Genau, mich auch. So ohne den Rest Deiner Aussagen hätte ich glatt auf Replikations-Probleme bei mehr als einem DC getippt, allenfalls in Verbindung mit aktivem, manuellem Eingriff in die Aktualisierungs-Politik der Maschinenkennwörter. *hust*

@NorbertFe Jo mit Exchange sieht die Sache defintiv anders aus. Da bin ich gleicher Meinung. @daabm Hmm und wie kommt das tatsächlich zustande? Kann mir das Szenario irgendwie nur schwer vorstellen. Kam mir auch noch nie unter. Wenn der DC nicht mehr vertrauenswürdig ist, geht ja in der Domäne eh nix mehr, also von extern das Maschinenpasswort zurücksetzen wird dann wohl auch essig sein. Dann müsste eben das Backup her. Aber eben, ich kenne aktuell noch nicht mal die Sympthome die das hervorrufen wird. ;) Auf alle Fälle würde ich die Risiken durch ungewollten Wiederherstellungen z.Bsp. durch Snapshots deutlich höher gewichten. Totalschaden und Rückgriff auf Backup gibts dann wohl bei beiden Fällen. Ausser man nimmt sich unter Umständen viel Zeit. Gab ja grad wieder einen Fall hier im Forum von ungewollter Wiederherstellung. Bei einem wäre das nicht passiert. ;) Werde sobald ich mal etwas Spieltrieb habe, das Szenario mal austesten ob man wirklich nicht an die DB rankommt und das PW ersetzen kann oder die gängigen Powershell-Funktionen mangels Authentifizierung nicht funktinieren (was zu hoffen ist).

Welcher Build ist den dein Server 2022? Nakt ohne GPO's welche die aktuelle Umgebung absichert? Vielleicht sind ja bei neueren Builds standardmässig ein paar Sicherheitsfeatures aktiviert welche Dir den Brei verderben. Würde sicher eine Build vor November letzten Jahres nehmen für solche Übungen. Wobei verdorben ist er ja schon mit SMB 1.0 Eventuell brauchts bei aktuelleren Builds eine Änderung des Standardverhaltens, also explizites setzen von älteren, nicht mehr empfohlenen Einstellungen. Mit Get-SmbClientconfiguration bekommst in Powershell die Grundkonfig für SMB raus die könntest Du mit einer 2012er Maschine vergleichen. Das ganze "unnötige" Sicherheitsgedöhns mal abschalten und nach und nach wieder aktivieren und rausfinden was anbleiben kann und was nicht. Dann evtl. mal Logs für NTLM, Kerberos, Netlogon etwas eskalieren und schauen wie das OS authentifizieren möchte. Dann noch mein Standardtipp, Firewalllogs aktivieren und schauen was für Pakete zugelassen/abgelehnt werden. Sprich ob von vornherein etwas hakt. Die Uhrzeiten mit anderen Einträgen von System/Anwendung etc. abgleichen und man bekommt recht viel raus wos hängt. Die Auswertungen sind deutlich einfacher wenn möglichst viel Telemtrie abgedreht ist die irgendwohin verbinden möchte. Wenn alles nix hilft, die Security-Bulletins der letzten 2-3 Jahre checken und man bekommt recht viel raus was grad mühsam sein könnte mit alten Geräten. Einfach alles aktiv rückgängig machen mit Regsettings oder gpedit.msxc was so empfohlen wird. *rofl* Wieso tut man sich eigentlich freiwillig Samba an, wenn man doch Windows-Systeme einsetzt? Ich werde es nie verstehen und tue es auch heute nicht =)

Die Ansicht mit 3 bis 4x mehr als RAM ist etwas veraltet. Da war RAM noch enorm Mangelware. Am Ende kommt es darauf an, wozu das Pagefile effektiv dienen soll. Bei einem VDI-Client ist mir ziemlich egal ob er ein vollständiges Dump des RAM abspeichern kann oder nicht. Ein paar Minidumps und etwas Paging reicht eigentlich. Eigentlich soll Windows nur den Kernel auslagern, sonst hat die VM im Grunde zu wenig RAM. Siehe auch: https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/how-to-determine-the-appropriate-page-file-size-for-64-bit-versions-of-windows Von einem MS-Mitarbeiter wurde mir mal empfohlen, maximal 1'500 MB zu geben. Auch bei Server. Mehr würde Windows nicht sinnvoll selber verwalten können wenn es zum Paging kommt. Und für normale Dumps, auch mehrere, reiche das aus. Sollte mehr ausgelagert werden, sei die Maschine eh "tot" und somit einigermassen unbrauchbar. Nur für die vollständige Dump-Analyse brauche es mehr. Das heisst RAM + ca. 256M können man vorhalten (steht auch in der Dok so). An diese Empfehlung halte ich mich mittlerweile ~10 Jahre und erhöhe Speicher manuell für die Analyse wenn ein vollständiger Dump benötigt wird. In meinen Klein-Umgebungen funktioniert das bis jetzt einwandfrei. Meist bewegt sich die Pagefile um ein paar 100MB, entspricht also dem Kernel.

Habe ja doch einige Storage-Spaces Konstrukte im Einsatz und mittlerweile ~10 Jahre Erfahrung damit. Allerdings verwende ich für die Anbindung an VmWare NFS und nicht iSCSI. Machbar ist es auch mit iSCSI, nur hängt man mit iSCSI noch einen Layer Komplexität mit drauf weil nicht nur die MS-Systeme ein Filesystem unterhalten müssen, sondern auch VmWare. Je nach den Zielen die man verfolgt ist das kontraproduktiv. Bei Hyperconverged bringt es defintiv mehr Gefahr als Nutzen. Anbei aber mal die Antwort auf deine Frage: https://www.informaticar.net/create-two-node-storage-spaces-direct-s2d-in-hyper-v/ https://www.informaticar.net/create-iscsi-target-cluster-on-windows-server-2019/ https://www.informaticar.net/server-basics-11-create-shared-storage-in-windows-server-iscsi-target/ Die Frage ist halt wirklich, was man zu welchem Preis erreichen will. Preis jetzt nicht nur im Sinne der Kosten, sondern auch der Betriebs-Sicherheit. Da ich möglichst viel Komplexität vermeiden und die Dinge so einfach wie möglich halten möchte, verwende ich daher entweder eine SAN oder verzichte auf Host-Redundanz beim Speicher und somit die Cluster. MS als Hostspeicher würde ich dann erst wieder in Betracht ziehen, wenn man die doch relativ hohen Anforderungen erfüllen kann/möchte. Das wird dann aber kaum günstiger als eine SAN, dafür aber möglicherweise flexibler. Ist aber nicht mehr meine Welt. ;)

Die mitunter etwas aufwendige aber ebenfalls wirkungsvolle Methode ist das Auditing der Windows-Firewall/BFE einzuschalten und die Sicherheitsevents entsprechend auszuwerten. Oft ist es am einfachsten, wenn man einfach mal die Kommunikation blockiert, die Verbindungsversuche auswertet und dann nach und nach freigibt was notwendig ist und wieder schaut was blockiert wird oder welche Funktion nicht funktioniert etc. So erkennt man auch gut, ob Alternativmethoden, IP-Adressen etc. angefragt werden. Ist halt auch gut Handarbeit dabei, dafür bekommt man es auch recht granular raus bzw. kann ein Verhalten je nach dem auch provozieren.

Man kann die entsprechenden Policies (gpedit.msc) und/oder Regwerte auch mittels Script einpflanzen. Wenn einem das Deployment-Toolkit zu oversized ist. Die Fragerei wird man mit einer unattended.xml los. (Etwas suchen)

Woran scheiterst Du? Im Anhang eine kleine Fotostory. Im V5 siehst das Ergebnis. ohne Formel enhält zwar text aber keine Formel. Die anderen Texte (F) sind mit ="F" eingegeben.

Also entweder IstLeer oder IstFormel sollte funktionieren. Bei der bedingten Formel eine "Formel" eingeben. Dazu die linke obere Zelle des Feldes angeben. Also z.Bsp erstellst für A1 eine bedingt Formatierung. Als Methode gibst Du bei "Formel zur Ermittlung ...." die Funktion ein. =IstFormel(A1) nicht IstFormel($A$1) wie es Excel standardmässig macht. Danach ziehst das Feld A1 einfach weiter oder erweiterst den Formelbereich bei wird angewendet auf den gewünschten Bereich. Dann können die Formeln auch vorher schon dastehen. ;)

Mal ein Update wo ich noch Hilfe bräuchte: Aktuell kämpfe ich immer noch damit, dass der User-Manager Service via seiner svchost.exe in gesperrtem Zustand des Computers (User angemeldet, aber nicht am Platz), irgendwas mit NTLM authentifizieren möchte. In der Regel dauert es ein paar Stunden nach dem sperren. Anschliessend gibts folgende Sympthome: Anwendung der User Polices schlagen fehl (Computer scheinen zu ziehen, bin aber nicht 100% sicher, da schwierig zu prüfen) SMB-Verbindungen werden getrennt Es kommt beim Anmelden eine Info, dass die aktuellen Anmeldeinfos nicht aktuell sind und man sich an- und abmelden soll. Diese verschwindet aber rasch wieder. Meldet man sich wieder an, werden alle Verbindungen wieder mit Kerberos aufgebaut (Tokens werden wieder ausgestellt, nachprüfbar im Log). Das wäre nicht ultra-dramatisch, wenn ich nicht ein paar Anwendungen hätte, denen die Trennung gar nicht schmeckt. Braucht jedes mal ein Restart der Anwendung. Die alten Reg-Flags die das trennen verhindern, scheinen nicht mehr zu ziehen. Im Printerbereich/Scanner hoffe ich, dass Canon endlich nachzieht. Dann könnte ich ein paar Workarounds aufheben. Meine Anfragen werden immer mit dem Verweis auf die Sicherheitsangaben im Manual für SMB verwiesen. Jemand "Grösseres" mit mehr Einfluss hier oder anderen Infos? Laut meinem Distri bin ich immer noch der einzige der das überhaupt nachfragt und sie erhalten keine bessere Antwort von Canon als ich selbst. Kann ja eigentlich nicht sein. Kommt dann vielleicht wenn das enforcment erzwungend wird... Dann ein kleines Update zum Workaround den ich nun seit mehreren Monaten im produktiven Einsatz habe: DFSR-Variante zwecks Sync und reine Bordmittel. eigenes LAN für Maschinen mit NTLM und Lanport auf Relay wo möglich und die Kommunikation des Relay mittels Firewall auf die NTLM-Clients eingeschränkt. Alles an sonstigen Massnahmen aktiviert, was geht (Erst alles aktiviert, dann einzeln deaktiviert um herauszufinden was notwendig für die Funktion war) NTLM in der ganzen Domäne Deaktiviert und enforcement auf den DC's auf 2, für die OU mit dem Relay-Server NTLM Beschränkung aufgehoben. *1) Freigegebener Ordner auf dem Relay-Server in welchen die Maschinen (z.Bsp. Scanner) mit einem Service Account und NTLM-Auth schreiben dürfen DFSR welches diesen Ordner mit einem Ordner auf einem Filer synchronisiert der wiederum zugänglich ist Das Service-Konto für den SMB-Verkehr darf sich jeweils weder per RDP (eh gesperrt) noch lokal anmelden. Besitzt Lese/Schreibrechte für den Ordner. Für lokales Anmelden gibt es einen speziellen Admin Account für diese Maschine in der Domäne. Ansonsten hat er keine Rechte. Da mein Wissen eher breit als besonders tief ist in den einzelnen Gebieten, würde mich die Meinung von ein paar Profis interessieren, inwiefern solche Massnahmen ausreichenden Schutz bieten oder ob das nur Aufwand für wenig Schutz ist. 1*) Da nur der Relay-Server NTLM akzeptiert, schlagen alle Authentifizierungsversuche gegen Domain-Accounts fehl wenn sie mit NTLM getätigt werden. Man kann leider nach wie vor keine Remotemaschinen-Ausnahme definieren wenn SMB-Signing aktiviert wird. Daran haben auch die aktuellsten April-Updats nichts geändert (Server-Account und nicht der Initiator - also z.Bsp. der Scanner - wird gelogt). Das macht die Auwertung mühsam. Wer weiss Abhilfe? Leider hat dieser Workaround wohl ein Ablaufdatum, weil MS die Möglichkeit von Ausnahmen voraussichtlich im Oktober/November entfernen wird. Ich schätze der Termin wird verlängert, aber selbst wenn er nur mit Remote-Ausnahmen möglich bleiben würde, bringt das eigentlich nichts, weil er die Remote-Maschine nicht als solche behandelt. Der zweite Workaround mit der komplexeren Shared-Disc-Aktivierung-Deaktiverungs-Geschichte via zwei VM's ist je nach Art der Kommunikation (Einweg oder Zweiweg) einigermassen umständlich, wende ich aber nach wie vor an wo ich ein LAN-technisch strikte Trennung haben möchte. Aufgabenplanung mit Scripts für das Aktivieren/Deaktivieren der Disc um die MFT neu zu laden um zu erkennen ob die andere VM etwas geschrieben hat (sonst sind die Files nicht sichtbar) --> Gibts dafür auch nen einfcheren Weg wie nen WMI Befehl? Indexdienste auf die HDD deaktivieren um MFT-Beschädigung zu vermeiden Lockfile dessen anwesenheit man abfragt und verhindert das der Partner schreibt wenn er es gerade tut (wenn Zweiweg notwendig ist, ist aber trivialer wenn man mit zwei Festplatten arbeitet. Für jede "Schreibrichtung" eine. Alles halt recht hässliche Work-Arounds, weil die Industrieumgebungen leider nicht so schön aktuell zu halten sind wie die Büros, aber heute alles vernetzt sein muss.

Mir wurden die ständigen Änderungen irgendwann zuwieder. Ständig ging irgendwas des Deployments nicht mehr, was vorher ging. Heute habe ich ein umfangreiches Powershell-Script bzw. ein Basis-Script mit den gewünschten Parameter/Einstellungen welches auf dem Maschine verbleibt (habe eh wenige 0815 Maschinen) und wenn ich nen Wartungsstick/Discs (Bei VM's) von mir einstecke/verbinde, lädt es bei Ausführung die entsprechenden Funktionen nach. Manchmal brauchts einfach ein Upgrade des Parameter-Scripts wenn man neue Funktionen auf alten Installationen möchte. Das Script erstellt dann z.Bsp. Basic Firewall-Ruleset, deaktiviert Dienste, Aufgaben, konfiguriert Pagefile, IP-Dienste, evtl. fixe IP-Adressen, installiert gewählte 0815 Software, aktiviert dieses mit den entsprechenden Keys usw. je nach Art des Clients oder Servers den ich aufsetzen möchte. Den Rest erledigen dann die GPO's der jeweiligen Umgebung. Das ist insgesamt recht effinzient. Ein Script hat den Vorteil, dass es mit jeder neuen Idee welche MS grad hat, die Anpassungen trotzdem einfach funktionieren, weil MS die Rückwärtskompatibilität von Script-Code enorm hoch hält. Im Gegensatz zu den Deploymenttools (keine Ahnung wie das heute ist, habe seit ~10 Jahren keine Erfahrung mehr damit). Bis auf wenige Ausnahmen die man z.Bsp. Build-abhängig macht. Das Script läuft dann für XP oder W11 durch. Die neuen Befehle schreibe ich meist als Kommentar hin ab wann es geht. Wenn dann wirklich das letzte System von XP/7 in Rente ist (Juhui, mein letztes W95 ging vor kurzem in Rente), kommen dann die neuen Befehle rein. Oder wenn der alte Weg instabil ist (wie Netzwerkadapter mutieren) wirds ganz weggelassen bei unter Min-Version und nachgearbeitet. ;) Mir hat es das leben jedenfalls um ein vielfaches einfacher gemacht und habe es nie bereut von den Deployment-Tools auf Script zu wechseln. In grösseren Umgebungen wo dann wieder einzelne Leute oder gar Gruppen für das Rollout zuständig sind und auch viele exakt identische Maschinen auszurollen sind, macht es aber vermutlich wieder mehr Sinn mit den Veröffentlichtungstools zu arbeiten. Da ist dann das Verhältnis von ausgerollten Maschinen zum Anpassungsaufwand einer neuen Windows-Version nicht mehr so übel wie in kleineren Umgebungen.

Ist halt die Frage ob man die Tunnel wirklich zulassen möchte oder ob man nicht besser auf Sie verzichtet. Sicherheitstechnisch ist die Technik zumindest etwas fragwürdig (EDIT: Zumindest war sie es, ob das heute noch gilt, weiss ich ehrlich gesagt nicht). Schiessen ja eigentlich ein Loch durch die Firewall. Klar bei Standardkonfig spielt das nicht so eine Rolle, gehört man aber zu jenen die tatsächlich die Firewall anpassen und sonstige Massnahmen technisch, wird es undurchsichtig mit den Tunnels. Wie viel das tatsächlich ausmacht, kann ich nicht so gut beurteilen, aber hilfreich ist es kaum. Am Ende muss man Firewall-seitig aber drei Techniken im Auge haben statt eine oder zwei. Hat man Probleme wie Dein geschildertes Verhalten mit den Verzögerungen und ist diese App auf dem Laptop Standard, müsste man korrekterweise Windows zwingen, erst IPv4 zu verwenden und IPv6 nur, wenn IPv4 nicht vorhanden ist. Also das Standardverhalten umdrehen. Das ereicht man indem man die Priorität in der Prefix-Policy von IPv4 gegenüber IPv6 erhöht. Insbesondere vom Loopback. Ich persönlich fände das sauberer als IPv4 einfach durch den IPv6 Tunnel zu schicken. IPv6 wird dadurch nicht verhindert, sondern es wird einfach erst IPv4 versurcht. Dazu müsste man die Prefixpolicy anpassen. Möchte man die Tunnels loswerden und nur IPv4 und/oder IPv6 nativ zu verwenden, ist meine Erfahrung, dass es in heterogen Umgebungen schmerzfreier ist, IPv4 die höhere Priorität einzuräumen. Entweder mit deaktiviertem IPv6 oder eben aktiviert. Dazu muss man die Prefixpolicy anpassen.

Nur der Vollständigkeit halber, Computerkennwörter kann man doch neu setzen. Dürfte dann auch ohne Join funktionieren oder? Oder sind da noch andere caveeats? Script auf Netlogon und auf gehts. Auch wens natürlich immer noch mühsam bleibt. Vielleicht gehts sogar remote von einer anderen Maschine, habe ich noch nie probiert. In Powershell auf den Clients: Reset-ComputerMachinePassword -Server DCname -Credential Domäne\Benutzer Link bei MS: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1 @TO: Was kam eigentlich dabei raus? Hast wie empfohlen professionelle Hilfe geholt?

Mal wieder eure Antworten verpennt... Sorry. Natürlich nicht, möchte ja grundsätzlich herausfinden worans happert. Aber wens zu lange dauert oder eben die Leute nicht arbeiten können aber sollten, wird mit dem Hämmerchen der Reflex provoziert. Aber klar, wäre auch der Moment wo ich einen Spezi holen würde wenn es länger nicht bemerkt wurde und ich mit dem Vergleich einer funktionierenden Umgebung sowie der Netzhilfe nicht weiter komme. Aber das läuft ja wohl auch noch, macht einfach stellenweise Probleme, sonst hätte es nicht monatelang unbemerkt bleiben können. Aber mal ehrlich, wann musstest Du den letzten DC wegen vermurkstem AD wiederherstellen? Ich sicher über 15 Jahre nicht mehr. AD ist doch recht statisch, also wozu der ganze Aufwand und das Risiko (Snapshots, versehentliche Restores usw. ) bei vermutlich keiner Ausfall-Situation wo ein zweiter DC tatsächlich dazu geführt hätte, dass die Mitarbeiter ohne Intervention des Admins hätten weiterarbeiten können? Auch Fehler werden repliziert. Und wenn die Leute nicht arbeiten können, was jucken dann 5min Restore-Time für einen DC? Sonst spricht man auch immer vom Aufwand/Ertrag. Ich verstehe es nicht, würde es aber gerne verstehen. Zugriff auf Backup zählt nicht, die sollten ja optimalerweise eine eigene, unabhängige Struktur haben. Wie immer für die Situation: keine Fremdprogramme wie Exchange die in der DB rumschreiben, relativ statisches AD, Wartungsfenster vorhanden von normal 5-15min pro Monat für Updates wo keine Anmeldungen am DC möglich sind (Zeit für ColdCopy + Reboot). Wer bringt das schlagende Argument? Ich konnte noch keines erkennen. Ich weiss man macht es nicht, aber das ist kein Argument oder? Wenn ich blind und ignorant bin, schiebe ichs einfach aufs fortschreitende Alter, aber interessieren würds mich trotzdem =) HostCrash hat normal nichtmal Auwirkungen auf ein statisches AD. Restores gabs bei mir nur bei Update-Runden. --> Beispiel: Defekter ComponentStore aus verschiedenen Gründen/Ursachen (Festplattenplatz, Updatereihenfolge usw), verbocktes Update von MS oder selber ne Timeline verbockt ( NTLM etc). Der Aufwand für das Beheben eines Store-Defekts - sofern er möglich ist - steht selten im Verhältnis zu einem Restore, selbst ein Neuaufsetzen wäre vermutlich schneller. Aber vielleicht bin ich auch einfach zu langsam/ungeschickt. Oder niemand prüft den Store nach den Updates auf Beschädigungen Kann leider nicht folgen. Wie kann das auf nem einzelnen DC passieren bzw. Auswirkungen haben? Er hat doch immer auf sich selber Zugriff und kennt sein aktuelles Maschinen-PW. Oder meinst was ganz anderes? Falls ja, was genau und wie kann ich es provozieren zur Test-Behebung? Wenn er der einzige ist, was hindert mich am Image-Restore/CopyPaste des DC vom Stand Tag davor.

Sorry wurde etwas später. Eure Argumentation verstehe ich durchaus und habe es auch jahrelang so gehandhabt. Und in grösseren Umgebungen ist das ja auch kein Thema. Da ist aber auch der Rest der Umgebung fehlertolerant ausgelegt. Und ja, sie fressen fast kein Heu, insbesondere als VM nicht. Aber der Unterhalt ist eben doch da und die Lizenzkosten auch. Bei physischen Maschinen war das auch noch was anderes da nicht in Sekundenschnelle der alte wiederhergestellt werden konnte. Nur musste ich über die Jahre feststellen, dass wenn es zu einem Ausfall kam, noch nie AD an sich der Verursacher des Problems war, aber doch schon ab und wann Kopfzerbrechen verursacht hat nach einem Problem wo z.Bsp. die Hardware, der Mensch oder ein Update schuld war. Die Reparatur nahm immer einiges an Stunden und teilweise Nerven in Anspruch. Die Erfahrung fehlt ja dann etwas wenn man nicht täglich solche Probleme hat. Gleichzeitig hatte ich nie Probleme in Kleinstumgebungen mit einem Server, auch wenn die Putzfrau versehentlich den Stecker gezogen hat oder die USV über den Jordan ging. Einschalten und lief einfach wieder. Völlig schmerzfrei. Da habe ich dann irgendwann angefangen nur noch auf einen DC zu setzen wo es möglich war. Im Endeffekt muss so oder so der PDC - auch wenn es nur noch eine Rolle ist - online sein bei den Dingen die wirklich Ärger verursachen können (DFS-Ziele umlegen z.Bsp.). Klar ist ein Designfehler wenn PDC-Emulator-Rolle auf dem gleichen physischen Server liegt wie das aktive PDC-Ziel. Ist aber schnell passiert und ein Design-Fehler der sehr oft vorkommt, auch weil den Leuten Jahrelang eingetrichter wurde, dass es den PDC nicht mehr gibt. Komplett vergessen ging bei den ganzen Belehrungen jeweils, dass die Abhängigkeiten von seinen Funktionen aber durchaus immer noch vorhanden sind. Auch heute noch. Sprich am Fakt das er da sein muss hat sich wenig geändert, trotz aller Begriffs-befindlichkeiten auf die man aus diesem Grund besser verzichtet hätte. Die Wahrscheinlichkeit das bei einem Hardwareausfall also der PDC bzw. der DC mit der PDC-Emulator-Rolle betroffen ist, liegt im KMU-Bereich in der Regel bei 50%. Also bringt mir diese Fehlertoleranz wenig bis nix. Jede Rollenübertragung und korekte Überprüfung und Neuanlegunge eines DC's brauchen länger als ein Restore. ;) Ich sage nicht, dass es der Weisheit letzter Schluss ist und die Meinung muss auch nicht jeder teilen und wenn jemand mit einem schlagenden Gegenargument kommt, bin ich nie abgeneigt meine Meinung zu ändern, aber ich persönlich sehe heute im Gegensatz zu früher keine effektiven Vorteile in mehreren DC's in Kleinumgebungen mehr. (Edit: Wenn dann für die Infrastruktur --> Ticket-High-Jack Problematiken). Einfach weil ein Restore eine Sache von Sekunden/Minuten und nicht mehr von Stunden ist, weil der DC heute ein File und keine physische Maschine mehr ist. Möchte aber nochmals betonen, das gilt ausschliesslich solange man nicht Daten im AD ablegt, welche für die tägliche Arbeit benötigt werden und permanent im AD rumgeschrieben wird. Ich persönlich habe diese Zöpfe mittlerweile fast alle aus Sicherheits- oder Komplexitätsgründen abgeschnitten. Ich versuche heute alles möglichst einfach zu halten und die Komplexität auf den Unterbau zu schieben.