10
Win 10 "net use" Serverscript funktioniert nicht
Hallo zusammen,
Wir setzen in unserer bisherigen Infrastruktur ein CMD-Script mit "net use" Befehlen für die Einbindung von freigegebenen Ordnern als Netzlaufwerke ein. Es handelt sich um eine Umgebung mit einer AD auf einem Windows Sver 2008 Standard und einer Hand voll Win7 Pro x64 Clients --> funktioniert tadellos.
Demnächst steht die Umstellung auf neue Serverinfrastruktur mit Windows Server 2016 und Windows 10 Pro an.
Nun haben wir für Test von Clientsoftware einige Clients auf Windows 10 hochgerüstet (neue Cleaninstallationen). Das bisher verwendete cmd-Script bindet die freigegebenen Ressourcen nicht mehr ein. es wird Benutzername und Kennwort abgefragt. Nach einer Eingabe wird der Fehler 86 (falsches Netzwerkkennwort) angezeigt. Diesen Fehler konnte ich lösen in dem ich mittels secpol.msc unter Adminrechten die Richtlinie für Netzwerksicherheit: LAN Manager-Authentifizierungsebene angepasst habe --> siehe: Systemfehler 86 Netzwerkkennwort falsch
Das Script wird nun ohne Fehler abgearbeitet. Erstaunlich ist nur das kein einziges Netzlaufwerk angezeigt wird. Hat jemand eine Idee hierzu?
Als Ergänzung: nutze ich den "net use" Befehl im CMD-Prompt händisch, sprich die Befehlszeile einfach eintippe (identisch zum Serverscript), so wird das Netzlaufwerk eingebunden und angezeigt.
Das Problem taucht einzig und allein bei Verwendung eines Windows 10 x64 (Builds: 1709 / 1703 / 1607) auf. Der W10 Client hat ansonsten alle erforderlichen Rechte sowohl als lokaler Admin als auch in der Domäne gemäss seiner Gruppenzuordnung.
Grüsse
Wir setzen in unserer bisherigen Infrastruktur ein CMD-Script mit "net use" Befehlen für die Einbindung von freigegebenen Ordnern als Netzlaufwerke ein. Es handelt sich um eine Umgebung mit einer AD auf einem Windows Sver 2008 Standard und einer Hand voll Win7 Pro x64 Clients --> funktioniert tadellos.
Demnächst steht die Umstellung auf neue Serverinfrastruktur mit Windows Server 2016 und Windows 10 Pro an.
Nun haben wir für Test von Clientsoftware einige Clients auf Windows 10 hochgerüstet (neue Cleaninstallationen). Das bisher verwendete cmd-Script bindet die freigegebenen Ressourcen nicht mehr ein. es wird Benutzername und Kennwort abgefragt. Nach einer Eingabe wird der Fehler 86 (falsches Netzwerkkennwort) angezeigt. Diesen Fehler konnte ich lösen in dem ich mittels secpol.msc unter Adminrechten die Richtlinie für Netzwerksicherheit: LAN Manager-Authentifizierungsebene angepasst habe --> siehe: Systemfehler 86 Netzwerkkennwort falsch
Das Script wird nun ohne Fehler abgearbeitet. Erstaunlich ist nur das kein einziges Netzlaufwerk angezeigt wird. Hat jemand eine Idee hierzu?
Als Ergänzung: nutze ich den "net use" Befehl im CMD-Prompt händisch, sprich die Befehlszeile einfach eintippe (identisch zum Serverscript), so wird das Netzlaufwerk eingebunden und angezeigt.
Das Problem taucht einzig und allein bei Verwendung eines Windows 10 x64 (Builds: 1709 / 1703 / 1607) auf. Der W10 Client hat ansonsten alle erforderlichen Rechte sowohl als lokaler Admin als auch in der Domäne gemäss seiner Gruppenzuordnung.
Grüsse
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 373515
Url: https://administrator.de/contentid/373515
Printed on: April 24, 2024 at 03:04 o'clock
10 Comments
Latest comment
Hey,
lass das mit dem CMD-Script besser, das kann man auch mit GPP´s lösen seit 2008 wenn ich mich grad nicht täusche.
Viele Grüße
lass das mit dem CMD-Script besser, das kann man auch mit GPP´s lösen seit 2008 wenn ich mich grad nicht täusche.
Viele Grüße
Danke für das Feedback, das werden wir in der neuen Serverumgebung auch so relisieren. Jedoch beantwortet das keineswegs wieso das cmd-Script auf Win10 nicht so funktioniert wie es sollte.
Moin,
wir wird das Script an die Clients gebunden - sprich wo wird das wann über welchen Weg ausgeführt?
Gruß
wir wird das Script an die Clients gebunden - sprich wo wird das wann über welchen Weg ausgeführt?
Gruß
In welchem Kontext wird das Script denn ausgeführt?
Geb mal nach dem Script im cmd einfach nur "net use" ein und schau ob die Verbindung da sichtbar ist. Wenn ja, wurde das Script zwar ausgeführt, aber im falschen weil Admin Kontext. Da sieht der User dann das Laufwerk nicht
Geb mal nach dem Script im cmd einfach nur "net use" ein und schau ob die Verbindung da sichtbar ist. Wenn ja, wurde das Script zwar ausgeführt, aber im falschen weil Admin Kontext. Da sieht der User dann das Laufwerk nicht
Moin,
was ist denn bitte ein "Serverscript"?
Wenn ein Login-Script laufen lassen willst, dann muss das im Benutzerkontext geschehen. Also entweder im AD Objekt des User eingetragen sein, oder per GPO an die OU des Users oder per GPO mit aktivierter Loopback-Verarbeitung an die OU des Computer-Objekts.
lg,
Slainte
was ist denn bitte ein "Serverscript"?
Wenn ein Login-Script laufen lassen willst, dann muss das im Benutzerkontext geschehen. Also entweder im AD Objekt des User eingetragen sein, oder per GPO an die OU des Users oder per GPO mit aktivierter Loopback-Verarbeitung an die OU des Computer-Objekts.
lg,
Slainte
Aloha, danke für eure Rückmeldungen...
@SlainteMhath & @Kraemer: Das Script wird per GPO der User OU beim Anmelden eines Clients gestartet. Sprich: Gruppenrichtlinien --> Benutzerkonfig --> Richtlinien --> Windows-Einstellungen --> Skripts --> Anmelden
@SeaStorm: Die Eingbae von net use zeigt gar keine verbundenen Laufwerke an (Danke für den Tipp, auf die Idee bin ich mal wieder nicht gekommen)
Edit: Ich habe das Verhalten noch mit einem anderen Domänenbenutzer getestet (neuer User) --> Resultat dasselbe ... Die GPO ist letztendlich auch dieselbe.
@SlainteMhath & @Kraemer: Das Script wird per GPO der User OU beim Anmelden eines Clients gestartet. Sprich: Gruppenrichtlinien --> Benutzerkonfig --> Richtlinien --> Windows-Einstellungen --> Skripts --> Anmelden
@SeaStorm: Die Eingbae von net use zeigt gar keine verbundenen Laufwerke an (Danke für den Tipp, auf die Idee bin ich mal wieder nicht gekommen)
Edit: Ich habe das Verhalten noch mit einem anderen Domänenbenutzer getestet (neuer User) --> Resultat dasselbe ... Die GPO ist letztendlich auch dieselbe.
wie wäre es mal von script-gebundenem einbinden Abstand zu nehmen und das per GPPs zu erledigen?
Wird in der neuen Umgebung auch so erfolgen ... ist ja letztendlich viel einfacher. Dennoch ging es mir in diesem Thread darum dem Problem von "net use" in Kombination mit Windows 10 auf die Schliche zu kommen.
dann lass uns mal am Inhalt des Scripts teilhaben. Evtl. kann man dann mehr sagen
Ohne das Skript jetzt zu kennen, bei Windows 10 gibt es noch einen anderen Stolperstein, nennt sich UNC-Hardening https://blogs.technet.microsoft.com/leesteve/2017/08/09/demystifying-the ...
Kurz zusammengefasst: Bei Windows 10 ist UNC-Hardening standardmäßig aktiviert, was zur Folge hat, dass alle Start-/Logon-Skripte, die unter <\\dc\netlogon> liegen, nicht mehr ausgeführt werden.
Wenn dein Skript unter netlogon liegt, bleibt dir nur das Deaktivieren von UNC-Hardening. Oder du verabschiedest dich von der Fossil-Skripterei und machst es über GPOs.
Kurz zusammengefasst: Bei Windows 10 ist UNC-Hardening standardmäßig aktiviert, was zur Folge hat, dass alle Start-/Logon-Skripte, die unter <\\dc\netlogon> liegen, nicht mehr ausgeführt werden.
Wenn dein Skript unter netlogon liegt, bleibt dir nur das Deaktivieren von UNC-Hardening. Oder du verabschiedest dich von der Fossil-Skripterei und machst es über GPOs.
