Weingeist

Gibt leider nicht viele brauchbare Lösungen für dieses Problem. Software-Mässig funktioniert Teamviewer ganz annehmbar. Halt auf die IP-Adresse verbinden. Besser/Performanter ist eine Extender Lösung auf Glasfaser oder CAT-Kabel-Basis. Neben den klassischen Varianten aus dem Video-Bereich gibt es da z.Bsp. auch noch PCoIP. Letzteres ist etwas teuer geworden seit die Jungs sich massiv verkalkuliert haben mit ihrem letzten Hardware-Projekt. Die Firmware gibts nun nur noch mit teuren Abos. Gibt aber noch eine brauchbare Firmware die eigentlich genügt, die nix kostet. Für USB würde ich dann ein separates Extender-Modul mit eigenem Kabel legen, sonst ist die Leistung unterirdisch. ;) Ich mache das zum Beispiel jeweils mit den teuren CAD-Maschinen. Die hänge ich ins Rack und verbinde mittels PCoIP. So sind die ganzen Emissionen wie Lärm, trockene und lausige Luft aus dem Büro verbannt.

Auch wenn ich da wieder mal in der Unterzahl sein dürfte... ich sehe keinen Vorteil in den meisten kleinen Umgebungen zwei DC's zu betreiben. Ausgenommen, wenn mit AD-Daten tatschlich gearbeitet wird wie z.Bsp. Exchange oder wenn eben die Verfügbarkeit wirklich gebraucht wird. - DC ist in ein paar Minuten wiederhergstellt (wohl die Maschine die am schnellsten geht, da nur OS-Grösse von 12-18GB) - bei einem einzigen DC ist die Sicherung und Recovery-Art total egal (Cold z.Bsp. Kopie der heruntergefahren VM, Image, "AD-Konform") - Änderungen am AD sind in der Regel minimalst, wozu brauchts im Zweifelsfalle also einen Top aktuellen DC - Wartungsaufwand ist höher, Lizenzkosten etc. (Prüfung auf Replikation ob sie immer tut usw.) - Niemand interessiert die Downtime von ein paar Minuten bei Updates oder einem Tag für die Migration auf ein neues OS Auch redundantes DHCP sehe ich nicht als Vorteil. Bei kleinen Umgebungen verwende ich in der Regel sogar fixe IP's und DHCP nur für "wechselnde" oder mobile Geräte. Meiner Erfahrung nach ist das insgesamt stressfreier. Von all den komplexen und von MS teilweise eher spärlich gepflegten Dingen würde ich jeweils Abstand nehmen. Offline-Dateien, Server-Profile, Cluster usw. Keep it simple. Will man eine eher komplexe Technik dennoch verwenden, deren Eigenheiten beachten, Infos im Netz sammeln und sich überlegen wo und wie es Konflikte geben kann. Offline-Dateien die z.Bsp. nur von einer Person genutzt werden, deren Bearbeitung normal von einer Quelle her geschieht, dürfte selten bis nie Ärger machen. Sobald mehrere Quellen oder sogar unterschiedliche Personen an den Daten rumwerkeln ist dagegen Ärger vorprogrammiert. Sprich damit überhaupt ein Mehrwert und nicht ein Nachteil entsteht braucht es bei all den Dingen doch einiges auf Aufwand. Nicht nur bei der Inbetriebnahme. Ein Recovery ist in Kleinumgebungen oft einfach viel schneller als Stundenlanges nachforschen. Insbesondere bei reinen Infrastruktur-Maschinen wie AD. Ein Filer dagegen dauert länger. Daher lieber trennen. Und dennoch, normales Recovery bekommt man Hostintern z.Bsp. von SSD zu NVMe im GB/s Bereich hin. Nie war es einfacher KMU-Bedürfnisse quasi mit Brute-Force zu erschlagen. Für Desaster-Szenarien wie Brand/Hack etc. ist erfahrungsmäss auch ein oder mehrere Tage Unterbruch kein Weltuntergang. Aber das gilt es halt vorher zu klären wo die Bedürfnisse sind. Und Anmerkungen bezüglich Privat: Ich setze auch Private Umgebungen um wie bei einer Kleinfirma. Einfach weil ich kein Bock auf Ärger habe und mich lieber um anderes kümmere. Sonst lasse ich die Finger davon. Bin zu alt für Ärger der für ein paar hunderter verhindert werden kann. Aber Privat reicht möglicherweise wirklich ein Filer und ein DC aus. Printserver ganz weglassen ist auch ok, dürften ja überschaubere Anzahl Drucker sein die auch direkt auf den Clients installiert werden können. Mittels Export/Import ist das verteilen eines eingerichteten PC's auf ein paar andere PC's easy. Imho sinnvoll, wenn es nicht viele Automatisierungen, Papierfächer, Vorlagen etc. gibt. Wenn es dennoch einen geben soll, auf alle Fälle separat, nicht nur aus Gründen der Sicherheit sondern eben auch wegen der Updates. (Verlorene Einstellungen durch Treiberupdate usw.).

Mit zu viel Sparen schiesst man sich manchmal aber auch einfach unnötig selber ins Knie. Ich meine das gibt immer ne Menge unnötiger Arbeit und Zeit ist was auch viel kostet. Der (finanzielle) Aufwand für ne sparate Nic ist minimal. ;) Allerdings tippe ich eher auf die QNAP. Die Dinger machen mit iSCSI einfach viel zu oft Ärger. Was ich da alles schon erlebt habe geht auf keine Kuhhaut (egal ob unter Windows oder ESX). Ob nun Qnap oder der NIC-Treiber Schuld ist, ist nicht immer einfach zu eruieren. Ich mache das nicht mehr. Sind nunmal NAS und kein Block-Storage. Sprich sie funktionieren als NAS einfacher viel zuverlässiger, das ist ihre Domäne. Zudem ist das ganze robuster für Stromausfälle und dergleichen. Zumal das Recovery von einer iSCSI-QNAP schnell mal sehr sehr nervig werden kann. Kann ich auch ein Lied von singen. Aber ich kenne natürlich die Problematik wegen den Sicherungen. Wenn Du wirklich Block-Storage brauchst, könntest auch eine virtuelle Discs auf dem NAS anlegen. Ist immer noch zuverlässiger als iSCSI. ;)

Da Du das Problem der Windows-Firewall ansprichst, hast Du es schonmal mit einem Logging auf die BFE/Firewall versucht? Möglicherweise fehlen ein paar primäre Berechtigungen und die Kommunikation wird erst über einprogrammierte alternativ-wege freigegeben der etwas zu lange dauert. 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:disable /failure:enable Im Sicherheitslog findest Du dann was abgeht. Schauen, dass die Zeit vorher schon synchron war (Host) sonst ist evtl. essig mit dem Auffinden. Wen Dir zu viele Einträge sind, einfach eine gefilterte Ansicht erstellen. Log-File-Grösse von Sicherheit würde ich noch erhöhen, das Log füllt sich rasch =) Mit - tasklist /svc - netstat -a -b Kann herausgefunden werden welcher Prozess es effektiv betrifft. Wenn Du Glück hast, ist er noch aktiv nach dem Start. Einen Verdacht hätte ich auch noch parat. Und zwar den Netzwerkerkennungsdienst (NLA). Der verursacht verschiedensten Ärger insbesondere wenn via UNC auf einen Domänen-Ressource zugegriffen wird. Kann mir gut vorstellen, dass dies mit Profilen ebenso der Fall ist. Mit einer Verzögerung (Auto Delayed) des Dienstes kann man ihm manchmal den Ärger abgewöhnen. Habe aber auch Maschinen wo das nicht funktioniert. Insbesondere wenn Treiber aktualisiert wurden oder die ursprünglich erste Netzwerkkarte nicht mehr die primäre Netzwerkkarte ist (weil es sie zum Beispiel nicht mehr gibt), vorzugsweise wenn Hardware-Version einer VM geändert hat und somit die MAC. Da muss dann erst der Adapter deaktiviert/aktiviert werden. Super hässlicher Work-Around. Richtig lösen kann man es nur, wenn man alle alten Überreste aus der Registry bekommt/neu installiert. Ansonsten könntest versuchsweise mal direkt auf das Fileshare verbinden, da muss dann DFS nicht funktionieren. Ich weiss, nicht im Sinne des Erfinders, aber DFS ist teilweise auch von der Domänen-Erkennung abhängig. Meine Fileshares funktionieren auch nur wenn die korrekt war. Ob man das abgewöhnen kann, keine Ahnung. Scheint aber irgendwas geprüft zu werden. Habe ich aber nicht weiter verfolgt, da ohne den NLA eben auch anderes Zeug nicht richtig tut.

Wie wird den der freie Arbeitspeicher angezeigt im Ressourcenmonitor? frei, geändert, standby? Jener der im Standby ist, wird im Taskmanager z.Bsp. als frei angzeigt, nicht jedoch im Ressourcenmonitor. So 100% weiss ich nicht mehr wie er mir damals angzeigt wurde, müsste ich bei der Installation vorbeigehen. Ich meine der verwendete Speicher war Standby der nicht freigeschaufelt wurde. Der effektiv freie ging damals gegen 0 soweit ich mich erinnere und das schmeckte Windows irgendwann nicht mehr. Könnte im Grunde auch die NTFS-Timeouts erklären, darum reite ich drauf rum. Die VM würde anfangen im Page-File rumzuwursteln. Sprich Paging innerhalb der VM, Paging auf dem Host und dann geht nix mehr in der VM. Noch was anderes, RAM hat die RDS-VM exklusiv zu Verfügung? Host 4 nicht zufällig ohne Überbuchung oder viel Reserven und die anderen mit Überbuchung/wenige Reserven? (Geht das überhaupt bei HyperV? --> Sorry hab nur ESXi) Ansonsten bin ich dann auch eher ratlos. Mal die VM's zwischen den Hosts getauscht? Also VM von Host 4 auf 3 und anders rum? (Sorry hab jetzt nicht mehr alles gelesen)

Ominös muss die software nicht sein. Nur Ihren Speicher nicht sauber freigeben. Gerne ergibt sich das zum Beispiel wenn Software Office-Programme "integrieren", also auf deren Funktionalität zurückgreifen. Bei einer CAD-Software konnte ich das mal einigermassen zuverlässig auf die Office-Integration zurückverfolgen. Je mehr die gebraucht wurden, desto schneller ging die Maschine in die Knie. Bei jedem Start der CAD-Software wurde das Plugin/Bibliotheken neu geladen, bei der Schliessung aber nicht sauber entladen. Irgendwann war kein "richtig" freier RAM mehr verfügbar (war nur erkennbar mit dem Ressourcenmonitor) und die Kiste ging in die Knie. In einem anderen Fall wars ein ERP, welches Excel und Word-Funktionen eingebaut hatte. In beiden Fällen konnte mit einem Reboot Abhilfe geschaffen werden. Prozesse abschiessen und neu starten ging im Fall des ERP, das CAD bzw. der Lizenzdienst war weniger happy. Habe dann auch nicht allzulange gesucht, da Reboot zu einfach war. ;) Gibt aber auch andere Software die nicht sauber entlädt, Adobe ist hier auch so ein Fall. Ich vermute fast, die meisten die irgendwelche Schrott im Hintergrund laufen haben (Lizenzmanager, irgendwelche Inter-Programm-Kommunikation etc.) und mit den Hauptprogrammen kommunzieren, leiden verstärkt an solchen Problemen. Selbst die Windows CMD hat (evtl. hatte) solch ein Speicherleck. Schliesst du es per Kreuzchen und nicht per Exit-Befehl, dann wird sie nicht sauber entladen. Irgendwann ist kein RAM mehr da. Heute eher weniger ein Problem da es nur ein paar KB pro Sitzung sind. ;) Lange Red kurzer Sinn, wenn die RDS-Host wirklich über identische Installationen verfügen, klingt es schon etwas seltsam, dass einer davon nicht betroffen ist. Fragt sich, ob auf dem 4. Host ein anderes Nutzungsprofil herrscht. Sprich immer die gleichen User da drüber arbeiten die vielleicht bestimmte Programme nicht so oft brauchen, weniger surfen usw. Browser-Games und solche Spässe würde ich eh nicht dulden. Das braucht viel zuviel unnötige CPU. (Spiel selbst + Grafikbeschleunigung). Dafür kann man das private Handy nehmen. Betriebscomputer sind zum arbeiten da. Aber das ist nur meine Meinung. ;) Youtube, Home-Office etc. haben die Problematik diesbezüglich aber sowieso verschärft.

Damit ist das Probleme behoben? Also dann tippe ich auf eine Software welche sich nicht sauber entlädt. Was läuft denn da drauf ausser Office und Windows?

Hui, da war mal eine Antwort... Wie gesagt, da geht nur systematisches Vorgehen. Wenn Du Dinge an der Umgebung geändert hast mach sie als erstes rückängig. Wenn Du das Gefühl hast, es ist seit dem aktiven Teaming, hebe es doch einfach wieder auf und teste es Teaming kenne ich mich nicht wirklich sinnvoll aus, meine wenigen Gehversuche unter Windows waren immer von Ärger gekrönt. Ist aber doch einige Jahre her. In Zeiten von 10Gbit vermisse ich das halt nicht wirklich. Bin kein Fan der Netzwerkonfig unter HyperV, in ESXi ist das so absolut simpel gestrickt in der Konfig, dass ich mich mit HyperV nur sehr ungerne rumschlage (Einer DER Haupgründe warum ich ESXi statt HyperV verwende, einfach kein Bock auf allfällige Netzwerkproblemsuche und mich in die Eigenheiten einarbeiten)

Ist doch mit VM's eigentlich voll easy. Zusätzliche vDisc und lokal da drauf sichern. Zur Sicherheit kannst noch die vDisc ab und wann wegsichern. Wenn Du auf dem Ding noch Dedupe laufen lässt, kannst ne halbe Ewigkeit Daten sichern ohne wahnsinnig viel Platzbedarf. =) Anschliessend kannst ja zusätzlich mit dem Backupprogramm deiner wahl die vDiscs mit den Backups drauf sichern oder per Backup-Tasks die sicherungsfiles in ein Verzeichnis Deiner Wahl mit den Credentials Deiner Wahl wegkopieren. Mache das mit dem Umweg über eine zusätzliche vDisc bei Applikationsserver sehr gerne. Trivial, mit bordmitteln, viele Backupstände, wenig Speicherbedarf, schneller Restore. Vor allem bist mit allen Software-Herstellern immer im Grünen, da oft einer der wenigen Varianten innerhalb des Supports.

Stimmt, nicht gesehen... Beitrag war zuoberst

In solchen Dingen immer systematisch ausschliessen. Als erstes NB an einem anderen Netzwerkport einstecken wo ein Client dranhängt der keine Problem hat, sind die Probleme noch da, liegt es vermutlich nicht an der Leitung. Wird Dockingstation verwendet, zuerst ohne Dockingstation usw. Hat ein Client der sonst keine Probleme hat, an dieser Leitung Probleme. Liegt es an höchstwahrscheinlich an der Leitung. Der einfachste Test, Port von 1Gibt auf 100Mbit Gigabit drosseln. Wenn nicht möglich, einen 100er Switch dazwischen hängen. Sind die Probleme Weg, dann ist die Leitung oft unbrauchbar. War bei mir immer Fehlerquelle Nummer 1 sobald es Random mit einzelnen Quellen war. Insbesondere in älteren Gebäuden wo entweder Kabel durch zu kleine oder verwinkelte Leerohre gewürgt wurden oder schlicht noch alte Leitungen liegen. --> Leitung ausmessen lassen Auch ein Stück ungeschirmtes Kabel mit nem Verbindungsstecker dazwischen hängen hat schon geholfen --> Deutet auf irgendwelche Potentialprobleme hin, manchmal hilfts dann einfach einseitig den Schirm auf dem Patchpanel nicht anzuschliessen.

Ich frage mich immer bei solchen Dingen wie dem Credential-Guard immer, ob das tatsächlich so viel bringt. Eigentlich schafft man mit einem zusätzlichen HyperVisor in einem Client/Server, UEFI auf der Platte abseits der Kontrolle etc. doch auch unglaublich viel Komplexität mit viel Code und entsprechendem Fehlerpotential. Ich bin kein Spezialist in solchen Dingen, aber irgendwie hat das ganze Zeug jedenfalls einen faden Beigeschmack. Wo sich ein Angreifer dazwischenschaltet ist ja egal, wenn er sich Admin und/oder Systemrechte auf einem System aneignen kann - die Basis von fast jedem erfolgreichen Angriff - dann kann er sich doch auch immer zwischen die Kommunikation von egal was schalten und die "notwendigen" Dinge bekommen/manipulieren. Ein Bemerken/Aufspüren könnte noch schwieriger sein wenn er sich in solchen Bereichen einnistet. Oder sehe ich das falsch? Klar kurzfristig hilfts ja bestimmt, schlicht weil die meisten es nicht einsetzen und somit kein grösseres Interesse besteht weil man genügend andere attackieren kann. Aber mittel- bis langfristig? Oder habe ich das was nicht verstanden? Bezüglich der Admins-Workstation: Wenn eine ganze Umgebung in einem Cluster läuft, wie beim TO und auch in den meisten kleinen bis mittleren Umgebungen, hat man ja immer das Risiko, dass eine übernahme des HyperVisors auch T0-System wie AD komprimitiert. In der Regel hat man da ja nicht ausfallsichere Cluster für jede Stufe. Laufen also auf dem selben Host. Lohnt es sich dann überhaupt mehrere Admin-Workstations zu haben oder reicht nicht einfach eine aus? Admin-Workstation>Zugriff auf die VM's über dasVerwaltungsnetz mittels Hyper-Visor-Remote-Protokollen (Arbeits-VM für E-Mail, die Server an sich). Oder man verwendet zum surfen grad komplett andere physische Hardware. Sprich Zugriff nichtmal über ein Remote-Protokoll. Zumindest könnte man so die Admin-Workstation relativ gut insolieren, würde nur im Verwaltungs-Netz hängen. Für Fernzugriff müsste man sich noch etwas anderes einfallen lassen damit man von externe keine Passwörter eingeben muss, ist ja sonst wieder PillePalle.

Früher hatte ich immer Unternehmen.local, später ad.zz verwendet. Bei ad.zz traf das Problem deutlich weniger bis nicht auf. Wobei ich bei ad.zz auch die Freigabenamen jeweils möglichst kurz gehalten habe, was wieder ein paar Zeichen gab. Insofern waren es dann wohl 20-25 Zeichen. Aber eben, mit Azure, Zertifikaten etc. ist eine "sprechende" Adresse die einem gehört eher wieder "besser" bzw. ausschliesslich geeignet.

Vermutlich schon. Heute hat man doch den Kram eh unter SA oder? Vielleicht lehne ich mich jetzt aus dem Fenster, aber reine Machine/Machine Kommunikation müsste eigentlich CAL-frei sein. Hat ja nix mit der Arbeit an sich des User zu tun. Weder direkt noch indirekt. Aber sollen bitte die Super-Lizenz-Spezis hier abschliessend beantworten. ;)

Was noch nicht genannt wurde und ich in Vergangenheit schon ein paar mal drüber gestolpert bin: Die Probleme bei zu langen Domain-Namen. Ist super nervig in Verbindung mit DFS. Da zählt manchmal jedes Zeichen wenn die Leute allzu sprechende Namen in Ihrer Ordnerstruktur verwenden. Je weniger Zeichen die Domain hat, desto mehr steht für den Rest zu Verfügung, desto tiefer ist die Wahrscheinlichkeit, dass das Problem aufschlägt. MS hat es auch nach über 20 Jahren NTFS immer noch nicht geschafft, dass Ihr Code - allen voran der vom Explorer - durchgängig Pfadlängen über 255 Zeichen unterstützt. Dann gibt es noch ein weiteres Problem mit generischen Namen/TLD's die einem nicht gehören: Zertifikate. Siehe z.Bsp: https://cabforum.org/internal-names/ Tja, meine älteren Umgebungen sind/waren auch fast alle "falsch" mit dem kürzel zz oder local. Mir grauts immer vor den Umstellungen wegen DFS/Verknüpfungen in Dokumenten/CAD-Bibliotheken/Vorlagen etc. Ein paar mal habe ich das schon gemacht, es war jedes mal kein Spass. Weder für mich noch die MA's. Auch wenn es Stunden gegeben hat.

Wens klemmt, kannst eventuell auch gleich ne neue VM mit 22 hochziehen statt neu zu aktivieren. Dann ist wieder für ne Weile Ruhe ;)

Überbuchung ist übrigens im KMU Umfeld in der Regel deutlich problematischer als im grossen Umfeld. Grund: Die Anwendungen sind öfter nicht so optimiert wie im grössen Umfeld, sei es Datenbanken und deren Indexe, Clients die Videos abspielen, vielleicht Filer + Clients auf dem gleichen Host (ohne einbremsung der IO's, wird die volle CPU-Leistung für die LAN-Ports verbraten) usw. Alles Dinge die man im grösseren Umfeld in der Regel steuert, im kleinen aber entweder nicht kann (z.Bsp ESXi Essentials) oder schlicht zu aufwendig in der Pflege ist. ;) Auch sollte man eher viel MHZ statt viel Kerne haben. Grund: Viele KMU-Anwendungen sind Single Core basiert, Clients die man als VDI oder RDS laufen lässt profitieren enorm von hoher Single Core Leistung --> User Feeling --> KMU's sind meist Inhaber geführt = Computer soll gefälligst schnell sein, schnell heisst nicht insgesamt sondern genau dann wenn etwas gewünscht wird (Latenz) ;) Daher schaue ich immer das ich normal nicht mehr als 16 Kerne pro Host (Lizenzierung bzw. deren Kosten) und Taktrate von möglichst >3GHZ habe. Sprich das + an Leistung/Stromkosten ist oft deutlich günstiger als viele Stunden Optimierung auf welche man oft nichtmal einen Einfluss hat. Wie immer zu diesem Thema: Nur meine ganz persönliche Meinung.

Nicht nur Deutsch ist eine schwere Sprache *g*

Ironischerweise gibts beim Userfeeling mit am meisten Ärger mit dem Fileserver wenn da planlos vorgegangen wird (Verknüpfungen auf Dateien, Verknüpfungen innerhalb Datei z.Bsp. Excel in Word etc.). Aber wie die Vorredner schon sagten, loslegen und machen, vielleicht am Anfang und immer zwischendurch noch , soll auch helfen. Ne mal im Ernst, hole entweder Hilfe dazu oder übe vorher eingehend in einer Testumgebung. HowToos findet man bei MS und im weiten Netz.

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

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

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

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

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

ooops, hast ja Recht... @TO: Ich würde den Kram auch einfach löschen bzw. gar nicht erst erstellen beim Setup. Normal ist es besser wenn Windows von Anfang an weiss, dass etwas nicht da oder da ist. Denke zwar nicht, dass es hier von Belang ist, aber man meiss ja nie.