daabm

Zum Glück muß ich das nicht verstehen... Aber ok.

Ich würde ja sagen "Windows 7 Umgebung abschalten". Support ist beendet...

Oha - kann mich mal jemand aufschlauen? Ich kannte das so, daß ein Hostkey für das zu aktivierende OS aktiviert werden muß auf dem KMS...

....und ist der Key SICHER ein KMS-Key?

Du könntest Dich auch mal näher mit der desktop.ini beschäftigen - https://docs.microsoft.com/en-us/windows/win32/shell/how-to-customize-folders-with-desktop-ini

Der Explorer zeigt an, was in der desktop.ini steht - die realen Pfade siehst Du nur in der Adressleiste oder auf der Befehlszeile.

Du kannst statt der vielen Screenshots auch einfach den PE-Abschnitt aus deinem Unattend.xml posten - das erhöht für uns die Lesbarkeit ungemein. Mit den Screenshots komme ich eher durcheinander Und ich würde die Partitionierung NIE durch das unattend machen lassen. Entweder durch ein eingebundenes Skript im WPEInit oder von Hand, aber nicht durch unattend. Das haben sie nämlich IMHO besch**** implementiert. Bei uns lief's am Ende darauf raus, daß unser Deployment Agent in das PE-Image intergiert ist und dort dann direkt als erste Sequenz die Partitionierung per Skript bekommt.

Die 30 Sekunden wären ein typischer Timeout - von was auch immer. Netzwerktrace am Client schon gemacht?

Nachdem noch keiner sonst geantwortet hatte: Mir wäre nicht bekannt, daß man die Brennfunktion redirecten könnte - "Brennen" ist in dem Sinne keine Laufwerksfunktion, die von der Redirection unterstützt wird. Bestimmt gibt es netzwerkfähige Lösungen dafür, aber die Ursprungsfrage für mich wäre: WARUM muss der User brennen? Was ist das Ziel dieser produzierten Scheibe? Und wie könnte man das anders lösen?

Bitmasken sind heutzutage nicht mehr sooo bekannt - man hat ja Speicher ohne Ende, da kann man doch alles auch individuell speichern

Wenn Du in verschiedenen Netzen steckst, dann hast Du auch verschiedene IPs (lokal und remote). Über die kannst Du die FW-Regeln wunderbar filtern (Registerkarte "Bereich"), funktioniert deutlich zuverlässiger als diese albernen Profile.

@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