daabm

@MurdocX sehe ich das richtig, daß er specialize und oobesystem ignoriert hat? Aber ok, wenn man das zum ersten Mal macht, ist es auch echt ein Krampf - ich hab mit Vista damit angefangen, was hab ich am Anfang geflucht...

C:\Windows\PolicyDefinitions ist - und war schon immer - eine rein lokale Angelegenheit des Computers, da wurde nie was repliziert... Der "Access denied" ist bekannt, wenn Du das aktualisieren willst, hilft takeown. Die einfachere Variante ist der Central Store, nur wird der oft vergessen aktuell zu halten.

Ist doch irgenwie auch ein Vorteil - anwendungsintegrierter Infrastruktur-Check

Ja. Du stellst im Bios "Power Loss - Restart" ein, fährst normal runter. Und wenn Du hochfahren wiilst, schaltest die Steckdose aus und wieder ein...

Schick mir ne PN, wenn Du Detailfragen dazu hast. "Produktspezifische" Diskussionen gehören hier nicht wirklich hin...

Den Menüpunkt mußt noch separat einschalten in der Energieverwaltung. Und wo in deinem BIOS sich das versteckt, weiß der Board-Hersteller bzw. dessen Handbuch vmtl. am besten

Ah - dann hab ich das falsch verstanden, sorry Dann wäre RoyalTS eine prima geeignete Lösung: 1. File mit Verbindungsdefinitionen. In jeder Verbindung (bzw. dem Ordner, in dem sie liegt), ist das "Credential by name" definiert. Das File teilt man sich mit allen anderen Admins (liegt idealerweise daher auf nem Share). 2. Privates File mit der Credential-Definition (mit dem zu 1. passenden Namen). Das kann sogar auf dem gleichen Share liegen - kannst auf Wunsch verschlüsseln (AES256, Kennwort halt lang genug...) Öffnet man jetzt beide Files, findet RTS die Credentials und meldet Dich automatisch an. Nutzen wir hier für Duzende Admins und Hunderte Server, klappt prima. Das Credential-Management von RoyalTS finde ich persönlich echt gut gelöst. (Nein, ich werde nicht dafür bezahlt - ich find's einfach gut gelöst.)

Nein. DHCP ist nicht AD-integriert und nicht auf Delegation vorbereitet. Skripten oder damit leben... Zum Thema "skripten": Man kann auch ein primitives Txt-File im Browser prima darstellen, und das ist aus den DHCP-Daten in wenigen Minuten erstellt. Liegen kann das auch auf file:// - damit brauchst dann nicht mal mit IIS-Rechten rum machen, sondern kannst bei NTFS-ACLs bleiben, mit denen Du Dich hoffenltich auskennst. Und die Frage nach dem "Warum" ist IMMER gerechtfertigt - zu häufig stellt sich heraus, daß die hier gestellte Frage bereits zu einem vorgedachten Lösungsweg gehört, der auf's Holz führt.

Am besten mit passenden ACLs

Ich stelle mal grundsätzlich das Account Sharing in Frage - besser wären dedizierte Accounts. Mit RoyalTS läßt sich das recht elegant lösen über "Credential by name"... Ein Powershell-Interface haben sie auch mit drin

Das kannst laut sagen, daß man hinterher immer schlauer ist... Irritiert hat mich auch, daß die NTLM/Operational Logs nirgends Einträge von dem WDS-Client hatten - nur vom WSUS selber. Und NTLM Blocking in einer Enterprise Umgebung ist ein Abenteuer: SCVMM kann nicht ohne, Cluster auch nicht. (Beide können angeblich ab 2019.)

...Asche auf mein Haupt... Das läuft unter "how to shoot yourself in your foot". Ein Netzwerktrace brachte schließlich Erhellung - .129 ist der Client, .133 der WDS: Ist echt dämlich, wenn man https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain aktiviert, auf "deny all" setzt und das dann vergißt...

Im WDS-Log sehe ich als letztes: The Following Client completed TFTP Download: Client IP: 192.168.100.129 Filename: \Boot\x64\Images\boot.wim File Size: 567789943 Client Port: 8621 Server Port: 59884 Variable Window: true Entspricht auch meiner Erwartung - ich hab ja kein Problem mit PXE, sondern mit dem Zugriff auf den Deployment Share nach Eingabe von User und Kennwort (in allen mir bekannten Variationen von Domäne und User...). Die ACL von REMINST sieht auch plausibel aus: Share name REMINST Path D:\WDS Remark Windows Deployment Services Share Maximum users No limit Users WSUS01$ Caching Manual caching of documents Permission NT AUTHORITY\SYSTEM, FULL BUILTIN\Administrators, FULL NT AUTHORITY\Authenticated Users, READ NT SERVICE\WDSServer, FULL The command completed successfully. Und die Meldung sagt ja "Network path not found" - bei ACL-Fehlern würde das doch anders aussehen? Ich steh voll auf dem Schlauch... Ich glaube nicht, daß das ein Problem des WDS ist, sondern eher des Boot-Images, das der erstellt.

Siehe oben - mit NAT geht das nicht. Erstell nen neuen Switch, der direkt mit dem Netz verbindet, und häng Deine VM an den dran. Wenn das auch nicht geht, bin ich ratlos. Hier jedenfalls funktioniert das mit einem virtuellen DC auf einem Win10 Client prima - der wäre hinter NAT auch nur schwer erreichbar

Ja, ok - er ist noch da, aber keiner VM zugeordnet... Ignorier den einfach. Bei Server-OS kann man ihn entsorgen, bei Client anscheinend nicht.

Dann schmeiß den Default Switch einfach weg - hier isser auch fort...

"Extern" sieht doch gut aus. Probier's mal. Der Default Switch ist anscheinend #grütze, aber das ist ja nichts neues, daß Defaults Grütze sind. Edit: Für die doppelten Bilder brauchst Dich nicht entschuldigen, das ist ein Bug der Foren-Software, wenn man die per C&P direkt im Editor einfügt.

Hi Jan. - Zugriff auf Ordner Images: Ja. Dir /s zeigt mir den kompletten Inhalt von Reminst an, type auf einzelne Files geht auch (z.B. Templates\WdsSysprepTemplate.inf). - Kein unattended bisher. - WDSUtil im Anhang - das ist doch etwas lang wdsutil.txt

Du mußt doch nur nen Switch einrichten, der direkt mit dem LAN verbunden ist (bridged)... Edit: "Glaube ich zumindest"

Das aufgerufene Programm muß das unterstützen, sonst klappt es nicht.

@vader14641 Genau wie Du - nicht den Object Picker verwenden, sondern einfach reinschreiben

Ne. Ein lokaler Benutzer ist nie gut. Wir betreiben ca. 200k Clients und 50k Server, und außer dem Builtin Admin gibt es bei uns keine lokalen Benutzer. Auf fast allen Systemen hat der zudem ein unbekanntes Kennwort, kann also nicht mal verwendet werden... Ich weiß jetzt nicht genau, was ich Dir erklären könnte - Du klingst, als wenn Du erst mal Grundlagen bräuchtest. Und zwar viele.

Ich weiß jetzt nicht, wie dein "Default Switch" konfiguriert ist - wenn der NAT macht, wird das nix. Dem Browser ist das egal, SSL auch, dem IPSec nicht.

@BOfH_666 Der Ansatz ist valide, das funktioniert prinzipiell auch - scheitert aber vermutlich auch am Problem der Erkennung von "veraltet"...