8
Laufwerke werden an einigen Clients nach Windown 10 Upgrade nicht gemappt
Hallo,
Wir sind gerade beim Upgrade von Windows 7 Pro x64 auf Windows 10 Pro x64 (10.0.10586). Da tritt das Problem auf das bei einigen Clients die Netzwerklaufwerke nicht mehr gemappt werden.
Ausgangslage:
2x Win 2008 R2 Domänencontroller.
Per GPO wird ein Startscript (\\{FQDN}\SysVol\{FQDN}\scripts\common.cmd) auf Benutzerebene [Benutzerkonfiguration - Richtlinien - Windows-Einstellungen - Skripts (Anmelden/Abmelden) - Anmelden] ausgeführt.
In dieser common.cmd wird per call u.a. ein benutzerspezifisches Anmeldescript angestoßen mit dem die Netzlaufwerke gemappt werden:
net use * /del /y >NUL
net use X: \\SERVER\FREIGABE /PERSISTENT:YES >NUL
Dies funktioniert bis Windows 7 Pro einwandfrei, jedoch bei einigen Windows 10 Rechnern werden die Netzlaufwerke nicht mehr gemappt. Jetzt sind es ca. 4 von 12. Ich konnte noch keine Unterschiede festmachen.
Folgende Aktionen habe ich bereits gesetzt bzw. überprüft:
- GPO-Funktion "Anmeldescript gleichzeitig ausführen" (auf Benutzer und Computer).
- GPO-Funktion "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" und "Startscripts sichtbar ausführen".
- GPO-Funktion [Computerkonfiguration - Richtlinien - Administrative Vorlagen - System - Gruppenrichtlinie] die Einstellung "Wartezeit für Richtlinienverarbeitung beim Systemstart" auf 1 Sekunde gestellt.
- Rechner aus Domäne genommen und wieder hinzugefügt.
- Benutzerkontensteuerung deaktiviert.
- Meldet man sich testweise mit einem "funktionierenden" Benutzer an einen "nicht funktionierenden PC" an, klappt das Laufwerksmapping nicht. Meldet man sich mit einem "nicht funktionierenden" Benutzer an einem "funktionierenden" Rechner an, dann klappt das Laufwerksmapping. D.h. es muss am Client liegen und nicht am Benutzerkonto.
- Die GPO "Startscript_ausführen" wird laut Richtlinienergebnissatz (rsop.msc) angewendet. GPOLogviewer kommt auf das selbe Ergebnis.
- Ein Win10 Client der dieses Problem hatte funktionierte nach einem Downgrade auf Win7 wieder einwandfrei.
- Virenscanner als Fehlerquelle schließe ich aus, der muss ohnehin vor dem Upgrade deinstalliert werden.
- in der common.cmd das Laufwerkmapping an als erste auszuführende Aktion gesetzt.
- Durch die common.cmd werden ebenfalls per call zu 2 weiteren cmd´s noch jeweils ein xcopy-Jobs gestartet welche immer erfolgreich abgearbeitet werden.
- Ebenso erfolgreich werden Drucker gemappt. Es betrifft einzig Netzlaufwerke.
- Es macht keinen Unterschied wo die Netzwerkfreigaben liegen (Win2003, Win2008, NAS).
Unter folgenden Voraussetzungen klappt eine Laufwerksmapping:
- Wenn im AD in den Eigenschaften des Benutzerkontos unter "Profil" --> im Feld Anmeldescript die common.cmd eingetragen wird.
- Führt man die common.cmd oder die USERNAME.cmd manuell am Rechner aus dann werden die Laufwerke ebenfalls einwandfrei verbunden.
- Wenn das Anmeldescript direkt oder als Verknüpfung in den Autostart (shell:startup) gelegt wird.
Ein Laufwerksmapping per GPP ("Laufwerkzuordnungen") habe ich noch nicht probiert und möchte ich auch nicht machen. Die Freigaben sind in dieser Umgebung zu umfangreich und nahezu jeder User hat andere Netzlaufwerke. Dadurch geht die Übersicht verloren.
Hat wer eine Idee zur Diagnose des Problems?
Danke im Voraus.
Wir sind gerade beim Upgrade von Windows 7 Pro x64 auf Windows 10 Pro x64 (10.0.10586). Da tritt das Problem auf das bei einigen Clients die Netzwerklaufwerke nicht mehr gemappt werden.
Ausgangslage:
2x Win 2008 R2 Domänencontroller.
Per GPO wird ein Startscript (\\{FQDN}\SysVol\{FQDN}\scripts\common.cmd) auf Benutzerebene [Benutzerkonfiguration - Richtlinien - Windows-Einstellungen - Skripts (Anmelden/Abmelden) - Anmelden] ausgeführt.
In dieser common.cmd wird per call u.a. ein benutzerspezifisches Anmeldescript angestoßen mit dem die Netzlaufwerke gemappt werden:
net use * /del /y >NUL
net use X: \\SERVER\FREIGABE /PERSISTENT:YES >NUL
Dies funktioniert bis Windows 7 Pro einwandfrei, jedoch bei einigen Windows 10 Rechnern werden die Netzlaufwerke nicht mehr gemappt. Jetzt sind es ca. 4 von 12. Ich konnte noch keine Unterschiede festmachen.
Folgende Aktionen habe ich bereits gesetzt bzw. überprüft:
- GPO-Funktion "Anmeldescript gleichzeitig ausführen" (auf Benutzer und Computer).
- GPO-Funktion "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" und "Startscripts sichtbar ausführen".
- GPO-Funktion [Computerkonfiguration - Richtlinien - Administrative Vorlagen - System - Gruppenrichtlinie] die Einstellung "Wartezeit für Richtlinienverarbeitung beim Systemstart" auf 1 Sekunde gestellt.
- Rechner aus Domäne genommen und wieder hinzugefügt.
- Benutzerkontensteuerung deaktiviert.
- Meldet man sich testweise mit einem "funktionierenden" Benutzer an einen "nicht funktionierenden PC" an, klappt das Laufwerksmapping nicht. Meldet man sich mit einem "nicht funktionierenden" Benutzer an einem "funktionierenden" Rechner an, dann klappt das Laufwerksmapping. D.h. es muss am Client liegen und nicht am Benutzerkonto.
- Die GPO "Startscript_ausführen" wird laut Richtlinienergebnissatz (rsop.msc) angewendet. GPOLogviewer kommt auf das selbe Ergebnis.
- Ein Win10 Client der dieses Problem hatte funktionierte nach einem Downgrade auf Win7 wieder einwandfrei.
- Virenscanner als Fehlerquelle schließe ich aus, der muss ohnehin vor dem Upgrade deinstalliert werden.
- in der common.cmd das Laufwerkmapping an als erste auszuführende Aktion gesetzt.
- Durch die common.cmd werden ebenfalls per call zu 2 weiteren cmd´s noch jeweils ein xcopy-Jobs gestartet welche immer erfolgreich abgearbeitet werden.
- Ebenso erfolgreich werden Drucker gemappt. Es betrifft einzig Netzlaufwerke.
- Es macht keinen Unterschied wo die Netzwerkfreigaben liegen (Win2003, Win2008, NAS).
Unter folgenden Voraussetzungen klappt eine Laufwerksmapping:
- Wenn im AD in den Eigenschaften des Benutzerkontos unter "Profil" --> im Feld Anmeldescript die common.cmd eingetragen wird.
- Führt man die common.cmd oder die USERNAME.cmd manuell am Rechner aus dann werden die Laufwerke ebenfalls einwandfrei verbunden.
- Wenn das Anmeldescript direkt oder als Verknüpfung in den Autostart (shell:startup) gelegt wird.
Ein Laufwerksmapping per GPP ("Laufwerkzuordnungen") habe ich noch nicht probiert und möchte ich auch nicht machen. Die Freigaben sind in dieser Umgebung zu umfangreich und nahezu jeder User hat andere Netzlaufwerke. Dadurch geht die Übersicht verloren.
Hat wer eine Idee zur Diagnose des Problems?
Danke im Voraus.
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: 306772
Url: https://administrator.de/contentid/306772
Printed on: April 26, 2024 at 07:04 o'clock
8 Comments
Latest comment
Hi.
Drei einfache Tipps:
-Startskripte vs. Anmeldeskripte: Völlig verschiedene Dinge. Startskripte haben mit den Nutzern nichts zu tun. Die NLWs werden immer von Anmeldeskripten gemappt.
-Bei Win8.x und win10 wurde ein Logonskript Delay (Anmeldeskriptverzögerung) von 5 Minuten eingeführt, um Admins zu ärgern. Lösst den Client ein paar Millisekunden schneller anmelden, dafür aber 5 Min ohne seine Skripte. Stell' diese Verzögerung für weitere Tests mal aus per GPO: https://support.microsoft.com/en-us/kb/2895815
-die empfohlene Art ist ohne Skript und statt dessen mit GPP: https://blogs.technet.microsoft.com/askds/2009/01/07/using-group-policy- ... nutzen wir auf 10, alles bestens.
Drei einfache Tipps:
-Startskripte vs. Anmeldeskripte: Völlig verschiedene Dinge. Startskripte haben mit den Nutzern nichts zu tun. Die NLWs werden immer von Anmeldeskripten gemappt.
-Bei Win8.x und win10 wurde ein Logonskript Delay (Anmeldeskriptverzögerung) von 5 Minuten eingeführt, um Admins zu ärgern. Lösst den Client ein paar Millisekunden schneller anmelden, dafür aber 5 Min ohne seine Skripte. Stell' diese Verzögerung für weitere Tests mal aus per GPO: https://support.microsoft.com/en-us/kb/2895815
-die empfohlene Art ist ohne Skript und statt dessen mit GPP: https://blogs.technet.microsoft.com/askds/2009/01/07/using-group-policy- ... nutzen wir auf 10, alles bestens.
Servus,
ich hatte ein ähnliches Problem bei einem Windows 10 Client (Surface Pro4); da wir bis jetzt nur einen W10 Client haben, hab ich das bei mir folgendermaßen gelöst: klick
lg
ich hatte ein ähnliches Problem bei einem Windows 10 Client (Surface Pro4); da wir bis jetzt nur einen W10 Client haben, hab ich das bei mir folgendermaßen gelöst: klick
lg
Hi,
Ich gehe davon aus dass dies der äquivalente deutsche Schlüssel ist. Der Wert lässt sich bei mir jedoch nicht wie beschrieben auf "0" stellen. Es kommt eine Meldung das 1 (Sekunde) der Mindestwert ist. Weiters steht im Link beschrieben das die unkonfigurierte Wartezeit 5 Minuten beträgt. In meiner GPO-Beschreibung am Server stehen als Standardwert 30 Sekunden. Eine Erklärung könnte sein das ich einen 2008er DC habe (?).
Habe zwischenzeitlich noch ein paar Sachen probiert:
- Wenn ich mir testweise das Ergebnis jeder Befehlszeile vom Anmeldescript in eine Textdatei wegschrieben lasse, steht beim Laufwerksmapping "Befehl erfolgreich ausgeführt". Trotzdem kein Laufwerk im Explorer, auch nicht nach mehreren Minuten Wartezeit.
- Im User-Anmeldescript vor dem net use Befehl eine Wartezeit eingeführt ("timeout /t 20")
- Wenn ich das Anmeldescript einmalig manuell ausführe, ist es bei den nächsten Neustarts noch vorhanden. Erst wenn es manuell getrennt wird, ist es dauerhaft verschwunden. Ist auch nur ein Workaround und nicht die Lösung....
-Startskripte vs. Anmeldeskripte: Völlig verschiedene Dinge. Startskripte haben mit den Nutzern nichts zu tun. Die NLWs werden immer von Anmeldeskripten gemappt.
Ja, stimmt, mea culpa. Wir verwenden natürlich ein Anmeldescript - meine Namensgebung war falsch.-Bei Win8.x und win10 wurde ein Logonskript Delay (Anmeldeskriptverzögerung) von 5 Minuten eingeführt, um Admins zu ärgern. Lässt den Client ein paar Millisekunden schneller anmelden, dafür aber 5 Min ohne seine Skripte. Stell' diese Verzögerung für weitere Tests mal aus per GPO: https://support.microsoft.com/en-us/kb/2895815
Hatte ich bereits konfiguriert: [Computerkonfiguration - Richtlinien - Administrative Vorlagen - System - Gruppenrichtlinie] die Einstellung "Wartezeit für Richtlinienverarbeitung beim Systemstart" auf 1 Sekunde gestellt.Ich gehe davon aus dass dies der äquivalente deutsche Schlüssel ist. Der Wert lässt sich bei mir jedoch nicht wie beschrieben auf "0" stellen. Es kommt eine Meldung das 1 (Sekunde) der Mindestwert ist. Weiters steht im Link beschrieben das die unkonfigurierte Wartezeit 5 Minuten beträgt. In meiner GPO-Beschreibung am Server stehen als Standardwert 30 Sekunden. Eine Erklärung könnte sein das ich einen 2008er DC habe (?).
-die empfohlene Art ist ohne Skript und statt dessen mit GPP: https://blogs.technet.microsoft.com/askds/2009/01/07/using-group-policy- ... nutzen wir auf 10, alles bestens.
Stimmt, aber man hat keine Übersicht mehr welcher User welche Laufwerke verbunden bekommt. Möchte beim net use bleiben.Habe zwischenzeitlich noch ein paar Sachen probiert:
- Wenn ich mir testweise das Ergebnis jeder Befehlszeile vom Anmeldescript in eine Textdatei wegschrieben lasse, steht beim Laufwerksmapping "Befehl erfolgreich ausgeführt". Trotzdem kein Laufwerk im Explorer, auch nicht nach mehreren Minuten Wartezeit.
- Im User-Anmeldescript vor dem net use Befehl eine Wartezeit eingeführt ("timeout /t 20")
- Wenn ich das Anmeldescript einmalig manuell ausführe, ist es bei den nächsten Neustarts noch vorhanden. Erst wenn es manuell getrennt wird, ist es dauerhaft verschwunden. Ist auch nur ein Workaround und nicht die Lösung....
Hi,
That´s it !! Der Registrierungswert EnableLinkedConnections löst das Problem.
Jetzt ergeben die Beobachtungen und Ergebnisse auf gesetzte Aktionen einen Sinn
Danke an alle Beteiligten!
That´s it !! Der Registrierungswert EnableLinkedConnections löst das Problem.
Jetzt ergeben die Beobachtungen und Ergebnisse auf gesetzte Aktionen einen Sinn
Danke an alle Beteiligten!
Super! Dachte ichs mir doch ;)
Den Beitrag bitte auf gelöst setzten und Lösung(en) markieren
Den Beitrag bitte auf gelöst setzten und Lösung(en) markieren
Stimmt, aber man hat keine Übersicht mehr welcher User welche Laufwerke verbunden bekommt. Möchte beim net use bleiben.
Doch, natürlich. nicht weniger als vorher. In der GPP ist doch alles einsehbar, was Du konfigurierst.
Jaja, einsehbar schon. Aber es kommt darauf an was und wie man sehen will. In der GPP sehe ich zwar welche User das Laufwerk XYZ verbunden bekommen. Aber ich sehe keine Auflistung der Laufwerke pro User.
Und alle gefühlten 50 Laufwerke durchklicken und einen bestimmten User raussuchen... Nein, danke.
Und alle gefühlten 50 Laufwerke durchklicken und einen bestimmten User raussuchen... Nein, danke.
Du würdest (um es übersichtlich zu halten) mit Gruppen arbeiten.
Gruppe NLW_Verwaltung bekommt alle NLWs, die die Verwalter brauchen
Gruppe NLW_Ingenieure...
usw. (oder direkt nach Abteilungsgruppen, die es eh schon gibt).
Will man dann sehen, welche NLWs ein Nutzer bekommen müsste, schaut man nicht in die Policy, sondern ins Userobjekt auf dessen Gruppenmitgliedschaften.
Ich würde schwer von Skripten abraten, wenn man GPP benutzen kann. GPP wird besser gepflegt und getestet.
Gruppe NLW_Verwaltung bekommt alle NLWs, die die Verwalter brauchen
Gruppe NLW_Ingenieure...
usw. (oder direkt nach Abteilungsgruppen, die es eh schon gibt).
Will man dann sehen, welche NLWs ein Nutzer bekommen müsste, schaut man nicht in die Policy, sondern ins Userobjekt auf dessen Gruppenmitgliedschaften.
Ich würde schwer von Skripten abraten, wenn man GPP benutzen kann. GPP wird besser gepflegt und getestet.