Server 2019 WDS: Client bringt "Netzwerkpfad nicht gefunden"

[daabm 1.366]

Hallo zusammen.

Hab heute nen 2019 WDS installiert (standalone, kein DHCP mit drauf, eigener Server). Alles soweit smooth, Boot- und OS-Images per Assistent hinzugefügt (Win10 1909), PXE-Boot klappt auch. Nur fragt das Setup dann irgendwann nach Credentials für den Deployment Share (REMINST) und meldet dann:

 

Ich kann den Share aber in einer Commandline erfolgreich verbinden und habe dann auch - mit dem gleichen User, den ich in der Setup-Abfrage verwende - Zugriff auf alles...

 

MDT ist noch nicht am Start, ist alles plain WDS. Und im X:\Windows\Panther\SetupAct.Log finde ich nichts, was mich wirklich auf Ideen zur Lösungsfindung bringen würde - da steht dann auch nur der Fehlercode 0x80070035 - Network path not found. IP-Config ist IMHO auch in Ordnung:

 

Was mache ich falsch?

 

Danke und Gruß und schönen 1. Mai!

Martin

 

[MurdocX 957]

Nach dem eingeben der Credentials, werden normalerweise die Images aufgelistet. Heißt, er greift über das eigene Share auf seine Images zu. Könntest du bitte mal kontrollieren, ob das Share "REMINST" vorhanden und auf den richtigen WDS Ordner verlinkt ist.

 

OK, überlesen, dass dein Share ja vorhanden ist ..

 

Folgende Fragen hätte ich:

- Kommst du über die Cmd auf und in den Ordner Images?

- Hast du eine Unattendet.xml für das Setup-Image gemacht? Falls ja, bitte mal posten.

- Gerne auch ein 

WDSUTIL /Get-Server /Show:All /Detailed

 

bearbeitet 1. Mai 2020 von MurdocX

[daabm 1.366]

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

[MurdocX 957]

Stelle bitte mal das Client-Logging an. Die Ergebnisse findest du im Eventlog unter "Microsoft-Windows-Deployment-Services-Diagnostics/Operational"

Ich hab zwar gerade keinen Server 2019 am Start, hab aber Abweichungen bei den Berechtigungen auf dem Image gesehen.

 

So sehen meine Berechtigungen auf dem Share aus:

bearbeitet 1. Mai 2020 von MurdocX

[daabm 1.366]

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.

[Weingeist 159]

Normal kommen Netzwerkpfad-Fehler wenn das Share mit einem anderen Benutzer verbunden wurde als man darauf zugreifen möchte. Habe ich zwar nicht im Context mit WDS aber mit Scripts schon oft genug erlebt. Eventuell verbindest Du mit dem normalen User, es wird aber mit dem privilegierten Admin-Account ausgeführ. Oder anders rum. Dem fehlt dann das Share. Manche Windows-Prozesse laufen auch als Trusted Installer oder System und das Share wird mit Admin verbunden.

 

Weiss nicht ob das hier geht, aber eventuell wäre ein Mount-Point möglich? Der dürfte unabhängig vom User sein. EDIT: mklink oder so war das glaub.

bearbeitet 2. Mai 2020 von Weingeist

[daabm 1.366]

...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...

 

[MurdocX 957]

Aii.. Lustigerweise hatte ich mal kurz einen Gedankengang der in die Richtung ging, lässt sich aber im Nachhinein auch immer leicht sagen  In einem Post hattest du dich mal über die eingerichteten AD-Sicherheitseinstellungen ausgelassen. Btw. wollte ich Dich dazu eh auch noch was fragen.

[daabm 1.366]

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.)