17
Loginsskript per GPO wird auf Windows 7 Rechnern nicht immer ausgeführt
Hallo Zusammen,
bei manchen Windows 7 Rechnern werden bei bestimmten Domänenbenutzern die Netzlaufwerke nicht verbunden, d.h. das Loginskript wird nicht ausgeführt. Das Problem scheint immer dann aufzutreten, wenn ich den Domänenbenutzer auf dem Client in eine lokale Gruppe wie z.B. Hauptbenutzer aufnehme.
Per gporesult kann ich jedoch feststellen, dass die Richtlinie "Loginskript" für den angemeldeten Benutzer ausgeführt wurde. Wenn ich dann auf dem Client manuell zum Pfad des Loginskripts navigiere und es manuell starte, werden die Netzlaufwerke problemlos verbunden.
Zusatzinformationen:
- Server: Windows 2008
- Client: Windows 7 64bit
- Skripts werden in der Gruppenrichtlinie unter "Benutzereinstellungen / Windows-Einstellungen / Skripts (Anmelden/Abmelden) / Anmelden" zugewiesen
- Zuweisung des Skriptes über folgende Methode laut gruppenrichtlinien.de:
1. Anlegen und Testen des Skripts, Speichern an beliebigem Speicherort. Das Skript darf nicht im Unicode-Format gespeichert werden, sondern als ASCII- oder ANSI-Datei!
2. Öffnen des Skript-Eintrags in der Gruppenrichtlinie, Doppelklick auf "Starten", "Herunterfahren", "Anmelden" oder "Abmelden".
3. Klick auf den Button "Dateien anzeigen". Es öffnet sich ein Explorer-Fenster.
4. In dieses Explorer-Fenster muss die unter 1. gespeicherte Datei kopiert werden. Das Ordnerfenster kann dann geschlossen werden.
5. Über den Button "Hinzufügen" im Skript-Fenster den Dateinamen (ohne Pfad) des unter 4. kopierten Skripts angeben.
6. OK bestätigen.
Hat jemand eine Idee an was das liegen könnte?
bei manchen Windows 7 Rechnern werden bei bestimmten Domänenbenutzern die Netzlaufwerke nicht verbunden, d.h. das Loginskript wird nicht ausgeführt. Das Problem scheint immer dann aufzutreten, wenn ich den Domänenbenutzer auf dem Client in eine lokale Gruppe wie z.B. Hauptbenutzer aufnehme.
Per gporesult kann ich jedoch feststellen, dass die Richtlinie "Loginskript" für den angemeldeten Benutzer ausgeführt wurde. Wenn ich dann auf dem Client manuell zum Pfad des Loginskripts navigiere und es manuell starte, werden die Netzlaufwerke problemlos verbunden.
Zusatzinformationen:
- Server: Windows 2008
- Client: Windows 7 64bit
- Skripts werden in der Gruppenrichtlinie unter "Benutzereinstellungen / Windows-Einstellungen / Skripts (Anmelden/Abmelden) / Anmelden" zugewiesen
- Zuweisung des Skriptes über folgende Methode laut gruppenrichtlinien.de:
1. Anlegen und Testen des Skripts, Speichern an beliebigem Speicherort. Das Skript darf nicht im Unicode-Format gespeichert werden, sondern als ASCII- oder ANSI-Datei!
2. Öffnen des Skript-Eintrags in der Gruppenrichtlinie, Doppelklick auf "Starten", "Herunterfahren", "Anmelden" oder "Abmelden".
3. Klick auf den Button "Dateien anzeigen". Es öffnet sich ein Explorer-Fenster.
4. In dieses Explorer-Fenster muss die unter 1. gespeicherte Datei kopiert werden. Das Ordnerfenster kann dann geschlossen werden.
5. Über den Button "Hinzufügen" im Skript-Fenster den Dateinamen (ohne Pfad) des unter 4. kopierten Skripts angeben.
6. OK bestätigen.
Hat jemand eine Idee an was das liegen könnte?
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: 178451
Url: https://administrator.de/contentid/178451
Printed on: April 16, 2024 at 21:04 o'clock
17 Comments
Latest comment
Hallo alleine,
Hauptbenutzer ist nur noch zwecks Kompatibilität mit Windows XP vorhanden. Unter Windows 7 solltest du als Gruppe entweder Benutzer oder Administrator wählen
Gruß,
Peter
Hauptbenutzer ist nur noch zwecks Kompatibilität mit Windows XP vorhanden. Unter Windows 7 solltest du als Gruppe entweder Benutzer oder Administrator wählen
Wenn ich dann auf dem Client manuell zum Pfad des Loginskripts navigiere und es manuell starte, werden die Netzlaufwerke problemlos verbunden.
Und warum nicht im Skript selbst einen Haltepunkt "Pause" einbauen und das Skript sichtbar ausführen lassen (GPO einstellung)? Dann siehst du es ganz genau warum das Skript beim Anmelden des Benutzers nicht das tut was du erwartest. Oder leitest du ergebisse deines Skripts in eine Log Datei...Hat jemand eine Idee an was das liegen könnte?
Du weisst doch ganz genau das wir dein Skript nicht kennen. Wie sollen wir dir dann sagen was darin evtl. falsch istGruß,
Peter
Moin
versuchs erst mal mit einer Grundkonfiguration. Unter Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung die Option "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten"
Vielleciht wird der Bernutzer mit zwischengespeicherten Informationen angemeldet und das Netzwerk ist noch garnicht bereit.
Gruß
Hubert
versuchs erst mal mit einer Grundkonfiguration. Unter Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung die Option "Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten"
Vielleciht wird der Bernutzer mit zwischengespeicherten Informationen angemeldet und das Netzwerk ist noch garnicht bereit.
Gruß
Hubert
@peter
1.) Man lernt bekanntlich nie aus ;D ...daran könnte es eventuell liegen. Was dagegen spricht ist, dass ich meine, das Problem auch schon mit einem Benutzer gehabt zu haben, den ich am Client noch nie in eine lokale Gruppe aufgenommen habe.
2.) Pause habe ich auch schon getestet, hat leider nie das Skript angezeigt. Vermutlich liegt es daran, dass es vor der Benutzeranmledung ausgeführt wird. Die Idee mit der Logdatei werde ich mal testen.
3.) Das Skript sieht wie folgt aus (vieleicht liegts auch an den DFS-Shares???):
net use J: /delete
net use L: /delete
goto %username%
:vorname.nachname
net use J: \\server02\WINDVSW1 /persistent:no
net use L: \\domäne\01\Verwaltung /persistent:no
goto end:
:END
@Hubert
Habe ich bereits aktiv.
1.) Man lernt bekanntlich nie aus ;D ...daran könnte es eventuell liegen. Was dagegen spricht ist, dass ich meine, das Problem auch schon mit einem Benutzer gehabt zu haben, den ich am Client noch nie in eine lokale Gruppe aufgenommen habe.
2.) Pause habe ich auch schon getestet, hat leider nie das Skript angezeigt. Vermutlich liegt es daran, dass es vor der Benutzeranmledung ausgeführt wird. Die Idee mit der Logdatei werde ich mal testen.
3.) Das Skript sieht wie folgt aus (vieleicht liegts auch an den DFS-Shares???):
net use J: /delete
net use L: /delete
goto %username%
:vorname.nachname
net use J: \\server02\WINDVSW1 /persistent:no
net use L: \\domäne\01\Verwaltung /persistent:no
goto end:
:END
@Hubert
Habe ich bereits aktiv.
Hallo,
Was du meinst ist irrelevant. Nur Fakten zählen. Stelle sicher das deine Meinung zum Fakt wird und wir reden darüber weiter.
Gruß,
Peter
Was du meinst ist irrelevant. Nur Fakten zählen. Stelle sicher das deine Meinung zum Fakt wird und wir reden darüber weiter.
Problem auch schon mit einem Benutzer gehabt zu haben, den ich am Client noch nie in eine lokale Gruppe aufgenommen habe.
Und was soll das beweisen? Nichts. Schaffe fakten.2.) Pause habe ich auch schon getestet, hat leider nie das Skript angezeigt.
Ja woran das wohl liegt? Skripte sichtbar ausgeführt (GPO)? Dazu sagst du uns nichts.Vermutlich liegt es daran,
Vermutungen helfen dir und uns nicht. Das ist keine Quizsendung hier.dass es vor der Benutzeranmledung ausgeführt wird.
Und wie kommst jetzt auf diese Idee? Du hast uns doch unmissverständlich gesagt das es sich um ein- Skripts werden in der Gruppenrichtlinie unter "Benutzereinstellungen / Windows-Einstellungen / Skripts (Anmelden/Abmelden) / Anmelden" zugewiesen
Benutzer Login Skript handelt. Jetzt auf einmal nicht mehr? Ein Startup Skript wird noch vor dem Benutzer ausgeführt. Aber davon sagst du nichts.3.) Das Skript sieht wie folgt aus (vieleicht liegts auch an den DFS-Shares???):
Warum, Laufen die nicht richtig? Habt ihr damit Probleme? Welche Laufwerke werden denn grundsätzlich nicht gemappt (wenn der Fehler auftritt)? Was passiert wenn der %UserName% nicht im Skript drin steht?Gruß,
Peter
Hi,
ein Skript welches _vor_ der Benutzeranmeldung ausgeführt wird ist dann kein Benutzerskript mehr.
Versuche doch einfach das Skript nicht über die GPO sondern über den Benutzer starten zu lassen. Sprich du gehst in das AD, dort auf den jeweiligen Benutzer und öffnest die Eigenschaften. Dann kannst du im Reiter Profil ein Anmeldeskript hinterlegen. Das Skript muss jedoch im NETLOGON Verzeichnis liegen.
Hast du das @echo off aus dem Skript herausgenommen? Sonst wird dir auch nix angezeigt.
Prüfe bitte ob der PC über eine Gigabit Netzwerkkarte verfügt und poste hier den Hersteller. Es gibt manchmal Probleme damit, genaueres kann ich dir dann sagen wenn ich den Hersteller weiß.
ein Skript welches _vor_ der Benutzeranmeldung ausgeführt wird ist dann kein Benutzerskript mehr.
Versuche doch einfach das Skript nicht über die GPO sondern über den Benutzer starten zu lassen. Sprich du gehst in das AD, dort auf den jeweiligen Benutzer und öffnest die Eigenschaften. Dann kannst du im Reiter Profil ein Anmeldeskript hinterlegen. Das Skript muss jedoch im NETLOGON Verzeichnis liegen.
2.) Pause habe ich auch schon getestet, hat leider nie das Skript angezeigt. Vermutlich liegt es daran, dass es vor der Benutzeranmledung ausgeführt wird. Die Idee mit der Logdatei werde ich mal testen.
Hast du das @echo off aus dem Skript herausgenommen? Sonst wird dir auch nix angezeigt.
Prüfe bitte ob der PC über eine Gigabit Netzwerkkarte verfügt und poste hier den Hersteller. Es gibt manchmal Probleme damit, genaueres kann ich dir dann sagen wenn ich den Hersteller weiß.
@Pjordorf
- Solange ich es nicht weis kann ich nur vernuten. Wenn ich's wüsste, würde ich hier keine Fragen stellen.
- Wie ich das Skript aufrufe habe ich ja Eingangs detailliert beschrieben. Wie auch immer man es nennt, dadurch sollte es ja eindeutig sein. (Anmelden = Login, oder nicht???).
- Habe keine Probleme mit DFS. Wenn das Problem auftritt, werden alle Laufwerke nicht gemappt. Es ist als ob das Skript nicht ausgeführt wird. Ohne %UserName% habe ich es noch nicht getestet. Lasse jetz aber die Variable inklusive Ausführungszeit lokal protokollieren, um zu sehen, ob überhaupt etwas ausgeführt wird.
@Komabaer
- Sollte man ein Login-Skript sehen, wenn es per GPO ausgeführt wird? Ist das nicht nur bei der "alten" Vorgehensweise direkt über den Benutzer so?
- @echo off ist und war noch nie drinnen, deswegen vermute ich ja, dass Login-Skripts über GPO nicht angezeigt werden.
- Gigabit ist (noch) nicht im Einsatz. Das wird ja ein Spaß, wenn wir bald umstellen :D
- Solange ich es nicht weis kann ich nur vernuten. Wenn ich's wüsste, würde ich hier keine Fragen stellen.
- Wie ich das Skript aufrufe habe ich ja Eingangs detailliert beschrieben. Wie auch immer man es nennt, dadurch sollte es ja eindeutig sein. (Anmelden = Login, oder nicht???).
- Habe keine Probleme mit DFS. Wenn das Problem auftritt, werden alle Laufwerke nicht gemappt. Es ist als ob das Skript nicht ausgeführt wird. Ohne %UserName% habe ich es noch nicht getestet. Lasse jetz aber die Variable inklusive Ausführungszeit lokal protokollieren, um zu sehen, ob überhaupt etwas ausgeführt wird.
@Komabaer
- Sollte man ein Login-Skript sehen, wenn es per GPO ausgeführt wird? Ist das nicht nur bei der "alten" Vorgehensweise direkt über den Benutzer so?
- @echo off ist und war noch nie drinnen, deswegen vermute ich ja, dass Login-Skripts über GPO nicht angezeigt werden.
- Gigabit ist (noch) nicht im Einsatz. Das wird ja ein Spaß, wenn wir bald umstellen :D
Neue Infos zu dem Test mit der Protokollierung:
Skript:
echo Datum=%date% >> d:\Log.txt
echo Zeit=%time% >> d:\Log.txt
echo Benutzer=%username% >> d:\Log.txt
net use J: /delete >> d:\Log.txt
net use L: /delete >> d:\Log.txt
goto %username%
:vorname.nachname
net use J: \\server02\WINDVSW1 /persistent:no >> d:\Log.txt
net use L: \\domäne\01\Verwaltung /persistent:no >> d:\Log.txt
goto end:
:END
Logdatei:
Datum=09.01.2012
Zeit= 9:18:39,22
Benutzer=vorname.nachname
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Sieht eigentlich alles sehr gut aus. ABER leider wird kein einziges Netzlaufwerk im Explorer angezeigt.
Skript:
echo Datum=%date% >> d:\Log.txt
echo Zeit=%time% >> d:\Log.txt
echo Benutzer=%username% >> d:\Log.txt
net use J: /delete >> d:\Log.txt
net use L: /delete >> d:\Log.txt
goto %username%
:vorname.nachname
net use J: \\server02\WINDVSW1 /persistent:no >> d:\Log.txt
net use L: \\domäne\01\Verwaltung /persistent:no >> d:\Log.txt
goto end:
:END
Logdatei:
Datum=09.01.2012
Zeit= 9:18:39,22
Benutzer=vorname.nachname
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Sieht eigentlich alles sehr gut aus. ABER leider wird kein einziges Netzlaufwerk im Explorer angezeigt.
Hallo,
und
Gruß,
Peter
Zitat von @sebastiana:
@Pjordorf
- Solange ich es nicht weis kann ich nur vernuten. Wenn ich's wüsste, würde ich hier keine Fragen stellen.
Es sind nur etwas viele vermutungen und wenige fakten@Pjordorf
- Solange ich es nicht weis kann ich nur vernuten. Wenn ich's wüsste, würde ich hier keine Fragen stellen.
- Wie ich das Skript aufrufe habe ich ja Eingangs detailliert beschrieben. Wie auch immer man es nennt, dadurch sollte es ja eindeutig sein. (Anmelden = Login, oder nicht???).
Ja. Aber du bist es der hinterher deine eigenen Behauptungen in frage stellst und andere begriffe verwendest. Nicht wir. Siehe deindass es vor der Benutzeranmledung ausgeführt wird.
Entweder ist ein Benutzerskript oder es ist keins. Es gibt kein Skript dazwischen.- Habe keine Probleme mit DFS.
Auch dieser Zweifel kam direkt von dir, nicht von uns.(vieleicht liegts auch an den DFS-Shares???):
Es ist als ob das Skript nicht ausgeführt wird.
OK.Ohne %UserName% habe ich es noch nicht getestet.
Wird auch nicht nötig sein.Lasse jetz aber die Variable inklusive Ausführungszeit lokal protokollieren, um zu sehen, ob überhaupt etwas ausgeführt wird.
OK.- Sollte man ein Login-Skript sehen, wenn es per GPO ausgeführt wird?
Wenn du es so willst, ja. Dazu hast du schon zweimal den hinwies bekommen.und das Skript sichtbar ausführen lassen (GPO einstellung
2.) Pause habe ich auch schon getestet, hat leider nie das Skript angezeigt.
Ja woran das wohl liegt? Skripte sichtbar ausgeführt (GPO)? Dazu sagst du uns nichts.Ist das nicht nur bei der "alten" Vorgehensweise direkt über den Benutzer so?
Nein. Wenn der Benutzer sich schon angemeldet hat wird natürlich alles was du in einer CMD ausführst auch sichtbar dargestellt. Beim Anmelden ist der benutzerdesktop so ja noch nicht verfügbar. Dazu bitte in der GPO "Skripte sichtbar ausführen" einstellen, dann siehst du es auch. da wirkt dann auch die Pause!- @echo off ist und war noch nie drinnen, deswegen vermute ich ja, dass Login-Skripts über GPO nicht angezeigt werden.
Warum reitest du permanet auf etwas herum wo dir schon mehrmals der Rat gegeben wurde "Skripte sichtbar ausführen" per GPO einzustellen?- Gigabit ist (noch) nicht im Einsatz. Das wird ja ein Spaß, wenn wir bald umstellen :D
Sollte mit deinem Problem 0 zu tun haben. Da kommen die Fehler dann halst schneller hoch Gruß,
Peter
Hallo,
das verwenden von Code tags ist hier sehr hilfreich. Ändere das doch bitte noch ab. Siehe Formatierungshilfe.
Dein
wird also vermutlich nie angesprungen, da das Sprungziel nicht existiert. Prüfe das mal.
Ein
kann dir etwas mehr helfen weil du dann siehst welcher Befehl dir die Antworten gibt.
Gruppenrichtlinien, Benutzerkonfiguration, Administrative Vorlagen, System, Skripts - "Anmeldeskripts sichtbar ausführen".
Gruß,
Peter
das verwenden von Code tags ist hier sehr hilfreich. Ändere das doch bitte noch ab. Siehe Formatierungshilfe.
Benutzer=vorname.nachname
Bis hierhin OK.Der Befehl wurde erfolgreich ausgefhrt.
Von wo kommt diese Antwort? Vermutlich von der Zeilenet use J: /delete >> d:\Log.txt
</code)
> Der Befehl wurde erfolgreich ausgefhrt.
Und diese von der nächsten Zeile.
net use L: /delete >> d:\Log.txtDein
goto %username% Ein
echo Loesche alle mappings>>d:\log.txt
net use * /delete >>d:\log.txt
echo Mappings geloescht>>d:\log.txt
echo Gehe zur Sprungmarke %UserName%>>d:\log.txt
.
.
.
:vorname.nachname
echo Habe Sprungmarke vorname.nachmname gefunden>>d:\log.txt
.
.
.
echo Bin am ende des Skripts angelangt>>d:\log.txtGruppenrichtlinien, Benutzerkonfiguration, Administrative Vorlagen, System, Skripts - "Anmeldeskripts sichtbar ausführen".
Gruß,
Peter
Zitat von @Pjordorf:
> - Wie ich das Skript aufrufe habe ich ja Eingangs detailliert beschrieben. Wie auch immer man es nennt, dadurch sollte es ja
eindeutig sein. (Anmelden = Login, oder nicht???).
Ja. Aber du bist es der hinterher deine eigenen Behauptungen in frage stellst und andere begriffe verwendest. Nicht wir. Siehe
dein
> dass es vor der Benutzeranmledung ausgeführt wird.
Entweder ist ein Benutzerskript oder es ist keins. Es gibt kein Skript dazwischen.
> - Wie ich das Skript aufrufe habe ich ja Eingangs detailliert beschrieben. Wie auch immer man es nennt, dadurch sollte es ja
eindeutig sein. (Anmelden = Login, oder nicht???).
Ja. Aber du bist es der hinterher deine eigenen Behauptungen in frage stellst und andere begriffe verwendest. Nicht wir. Siehe
dein
> dass es vor der Benutzeranmledung ausgeführt wird.
Entweder ist ein Benutzerskript oder es ist keins. Es gibt kein Skript dazwischen.
Es sei denn, mann kann nicht lesen und schließt daraus, dass es wohl noch ein Skript dazwischen gibt. 0
> Ist das nicht nur bei der "alten" Vorgehensweise direkt über den Benutzer so?
Nein. Wenn der Benutzer sich schon angemeldet hat wird natürlich alles was du in einer CMD ausführst auch sichtbar
dargestellt. Beim Anmelden ist der benutzerdesktop so ja noch nicht verfügbar. Dazu bitte in der GPO "Skripte sichtbar
ausführen" einstellen, dann siehst du es auch. da wirkt dann auch die Pause!
Nein. Wenn der Benutzer sich schon angemeldet hat wird natürlich alles was du in einer CMD ausführst auch sichtbar
dargestellt. Beim Anmelden ist der benutzerdesktop so ja noch nicht verfügbar. Dazu bitte in der GPO "Skripte sichtbar
ausführen" einstellen, dann siehst du es auch. da wirkt dann auch die Pause!
Wer lesen kann ist klar im Vorteil. Habe es nun aktiviert :D
Dein
wird also vermutlich nie angesprungen, da das Sprungziel nicht existiert. Prüfe das mal.
> goto %username%
> Doch wird angesprungen und auch erfolgreich ausgeführt. Hatte hier im Forum lediglich vergessen das ">> c:\log.txt" bei "/delete" rauszunehmen.
Das aktuelle Skript:
echo Datum=%date% >> d:\log.txt
echo Zeit=%time% >> d:\log.txt
echo Benutzer=%username% >> d:\log.txt
echo loesche alle Mappings >> d:\log.txt
net use * /delete >> d:\log.txt
echo Mappings gelöscht >> d:\log.txt
echo gehe zur Sprungmarke >> d:\log.txt
goto %username% >> d:\log.txt
:vorname.nachname
echo habe Sprungmarke ABC gefunden >> d:\log.txt
net use L: \\domäne\share1 /persistent:no >> d:\log.txt
net use K: \\domäne\share2 /persistent:no >> d:\log.txt
net use M: \\domäne\share3 /persistent:no >> d:\log.txt
net use O: \\domäne\share4 /persistent:no >> d:\log.txt
net use U: \\domäne\share5 /persistent:no >> d:\log.txt
net use S: \\domäne\share6 /persistent:no >> d:\log.txt
PAUSE
goto end:
:END
echo Ende des Skripts >> d:\log.txtUnd so sieht die Logdatei aus:
Datum=09.01.2012
Zeit=14:12:57,98
Benutzer=vorname.nachname
loesche alle Mappings
Es sind keine Eintr„ge in der Liste.
Mappings gelöscht
gehe zur Sprungmarke
habe Sprungmarke ABC gefunden
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Der Befehl wurde erfolgreich ausgefhrt.
Ende des Skripts Alle Laufwerksverbindungen werden scheinbar erfolgreich ausgeführt. Im Explorer wird jedoch kein einziges angezeigt. Wenn ich nun die gleichen "net use" Zeilen in der Kommandozeile von Hand ausführe sind die Netzlaufwerke auf einmal da.
Hallo,
Wo genau liegt das Skript was abgearbeitet wird?
Wo genau hast du diesess Skript in deiner GPO eingetragen?
Gibt es noch andere Skripts welche danach laufen?
Setz mal ein "net use" vor dem Pause in deinem Skript und schau was dann im CMD Fenster drin steht.
Gruß,
Peter
Zitat von @sebastiana:
Alle Laufwerksverbindungen werden scheinbar erfolgreich ausgeführt. Im Explorer wird jedoch kein einziges angezeigt.
Der Pause wird auch korrekt abgearbeitet, sprich das nun geöffnete CMD Fenster wartet auf einen Tastendruck?Alle Laufwerksverbindungen werden scheinbar erfolgreich ausgeführt. Im Explorer wird jedoch kein einziges angezeigt.
Wo genau liegt das Skript was abgearbeitet wird?
Wo genau hast du diesess Skript in deiner GPO eingetragen?
Gibt es noch andere Skripts welche danach laufen?
Setz mal ein "net use" vor dem Pause in deinem Skript und schau was dann im CMD Fenster drin steht.
Wenn ich nun die gleichen "net use" Zeilen in der Kommandozeile von Hand ausführe sind die Netzlaufwerke auf einmal da.
Auch wenn du das Skript aus dem genauen Speicherort wie du es verlinkt hast dort startest?Gruß,
Peter
Zitat von @Pjordorf:
Der Pause wird auch korrekt abgearbeitet, sprich das nun geöffnete CMD Fenster wartet auf einen Tastendruck?
JaDer Pause wird auch korrekt abgearbeitet, sprich das nun geöffnete CMD Fenster wartet auf einen Tastendruck?
Wo genau liegt das Skript was abgearbeitet wird?
\\domäne.local\SysVol\domäne.local\Policies\{B50830C8-10CA-4985-BA5A-8B98926AF344}\User\Scripts\LogonWo genau hast du diesess Skript in deiner GPO eingetragen?
Benutzerkonfig\Richlinien\Windows-Einstellungen\Skripts\AnmeldenGibt es noch andere Skripts welche danach laufen?
Nein.Setz mal ein "net use" vor dem Pause in deinem Skript und schau was dann im CMD Fenster drin steht.
Alle Netzlaufwerke stehen richtig als verbunden drin.> Wenn ich nun die gleichen "net use" Zeilen in der Kommandozeile von Hand ausführe sind die Netzlaufwerke auf
einmal da.
Auch wenn du das Skript aus dem genauen Speicherort wie du es verlinkt hast dort startest?
Ja.einmal da.
Auch wenn du das Skript aus dem genauen Speicherort wie du es verlinkt hast dort startest?
Gruß Sebastian
Hi Sebastian,
kannst du ausschließen, dass es damit zusammenhängt:
UAC richtig einsetzen (weiter unten bei 'Anmeldeskripte und Netzlaufwerke').
Das habe ich schon sehr oft gesehen, dass es genau dies war. Und es betraf immer ausschließlich Netzlaufwerke.
kannst du ausschließen, dass es damit zusammenhängt:
UAC richtig einsetzen (weiter unten bei 'Anmeldeskripte und Netzlaufwerke').
Das habe ich schon sehr oft gesehen, dass es genau dies war. Und es betraf immer ausschließlich Netzlaufwerke.
Hallo Goscho,
kann ich (noch) nicht ausschließen. Werde mich durch den Beitrag kämpfen...
kann ich (noch) nicht ausschließen. Werde mich durch den Beitrag kämpfen...
Zitat von @goscho:
Hi Sebastian,
kannst du ausschließen, dass es damit zusammenhängt:
[http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ UAC richtig einsetzen (weiter unten bei
'Anmeldeskripte und Netzlaufwerke')].
Das habe ich schon sehr oft gesehen, dass es genau dies war. Und es betraf immer ausschließlich Netzlaufwerke.
Hi Sebastian,
kannst du ausschließen, dass es damit zusammenhängt:
[http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ UAC richtig einsetzen (weiter unten bei
'Anmeldeskripte und Netzlaufwerke')].
Das habe ich schon sehr oft gesehen, dass es genau dies war. Und es betraf immer ausschließlich Netzlaufwerke.
Genau das war das Problem, vielen Dank!
Sobald ich den Benutzer aus der Gruppe Domänenadmins herausnehme oder UAC deaktiviere sind die Netzlaufwerke da.
Es kann doch nicht sein, dass man als Domänenadmin (der nicht "Administrator" heißt) keine Netzlaufwerke mehr per Skript verbinden kann!?
Das Workaround im Skript einen automatischen Task zu erstellen, der die Netzlaufwerke ein paar Minuten verzögert verbindet, kan doch nur ein Witz sein?
Gruß Sebastian
Hallo,
Klasse wenns jetzt geht.
Welchen Grund gibt es einen Domänenbenutzer in der Gruppe Domänenadmins zu haben und mit diesem seine Tagesarbeit zu tun? Was ausser Bequemlichkeit kann es noch geben?
Deine Fragen am schluß zeigen das du den Link gar nicht richtig gelesen / verstanden hast und dir die auswirkungen und sicherheitsrisiken gar nicht bewusst sind. Ist Windows 7 dann für euch das richtige Betriebssystem? Deine Domänenadmins fallen dann auch bei Exchange in den AdminSDHolder und haben dann auch massive probleme mit Send As. Siehe auch hier. Nur so zum lesen und verstehen
Gruß,
Peter
PS: Du verzeihst uns das wir nicht davon ausgegangen sind das deine Benutzer als Domänenadmins arbeiten?
Klasse wenns jetzt geht.
Sobald ich den Benutzer aus der Gruppe Domänenadmins herausnehme
Benutzer sollten niemals Administratoren sein. Und schon gar nicht als ein Domänenadmin agieren. Da ist grundsätzliches mit deinen Benutzerrechten falsch.oder UAC deaktiviere
Auch das ist ein NoGo.Es kann doch nicht sein, dass man als Domänenadmin (der nicht "Administrator" heißt) keine Netzlaufwerke mehr per Skript verbinden kann!?
Natürlich kann ein Domänenadmin Netzlaufwerke per Skript verbinden. Es gibt ja auch noch das Loginskript im Netlogon, Autostart und viele andere. Aber braucht er es zur Administration einer Domäne auch? Eher extrem selten und auch nur mehr zum testen, oder?Das Workaround im Skript einen automatischen Task zu erstellen, der die Netzlaufwerke ein paar Minuten verzögert verbindet, kan doch nur ein Witz sein?
Nein kein Witz und auch nur als allerletzten Ausweg.Welchen Grund gibt es einen Domänenbenutzer in der Gruppe Domänenadmins zu haben und mit diesem seine Tagesarbeit zu tun? Was ausser Bequemlichkeit kann es noch geben?
Deine Fragen am schluß zeigen das du den Link gar nicht richtig gelesen / verstanden hast und dir die auswirkungen und sicherheitsrisiken gar nicht bewusst sind. Ist Windows 7 dann für euch das richtige Betriebssystem? Deine Domänenadmins fallen dann auch bei Exchange in den AdminSDHolder und haben dann auch massive probleme mit Send As. Siehe auch hier. Nur so zum lesen und verstehen
Gruß,
Peter
PS: Du verzeihst uns das wir nicht davon ausgegangen sind das deine Benutzer als Domänenadmins arbeiten?
> Sobald ich den Benutzer aus der Gruppe Domänenadmins herausnehme
Benutzer sollten niemals Administratoren sein. Und schon gar nicht als ein Domänenadmin agieren. Da ist grundsätzliches
mit deinen Benutzerrechten falsch.
Es ging hier nicht um normale Benutzer sondern um Administratoren, die nicht "Administrator" heißen. Sory wenn da was durcheinander kam. Eingangs hatte ich das Problem nämlich auch mit nicht Domänenadmins, das lag aber vermutlich an der Art und Weise wie das Loginskript in der GPO eingebuden wurde. Danach habe ich dann zum Testen diesen ominösen Domänenadminuser verwendet, da hier das vermeintlich gleiche Problem ja immer noch und weiterhin auftrat. Erst als ich die Lösung des Problems kannte, war mir dann klar, dass es nur noch die Domänenadmins die nicht Administrator heißen betroffen hat.Benutzer sollten niemals Administratoren sein. Und schon gar nicht als ein Domänenadmin agieren. Da ist grundsätzliches
mit deinen Benutzerrechten falsch.
> Es kann doch nicht sein, dass man als Domänenadmin (der nicht "Administrator" heißt) keine Netzlaufwerke
mehr per Skript verbinden kann!?
Natürlich kann ein Domänenadmin Netzlaufwerke per Skript verbinden. Es gibt ja auch noch das Loginskript im Netlogon,
Autostart und viele andere. Aber braucht er es zur Administration einer Domäne auch? Eher extrem selten und auch nur mehr zum
testen, oder?
Ja das gute alte Netlogon habe ich vor Wut ganz vergessen ;)mehr per Skript verbinden kann!?
Natürlich kann ein Domänenadmin Netzlaufwerke per Skript verbinden. Es gibt ja auch noch das Loginskript im Netlogon,
Autostart und viele andere. Aber braucht er es zur Administration einer Domäne auch? Eher extrem selten und auch nur mehr zum
testen, oder?
Deine Fragen am schluß zeigen das du den
Link gar nicht richtig gelesen / verstanden
hast und dir die auswirkungen und sicherheitsrisiken gar nicht bewusst sind. Ist Windows 7 dann für euch das richtige
Betriebssystem? Deine Domänenadmins fallen dann auch bei Exchange in den AdminSDHolder und haben dann auch massive probleme
mit Send As. Siehe auch hier. Nur so zum lesen und verstehen
Link gar nicht richtig gelesen / verstanden
hast und dir die auswirkungen und sicherheitsrisiken gar nicht bewusst sind. Ist Windows 7 dann für euch das richtige
Betriebssystem? Deine Domänenadmins fallen dann auch bei Exchange in den AdminSDHolder und haben dann auch massive probleme
mit Send As. Siehe auch hier. Nur so zum lesen und verstehen
Ich habe den Artikel sehr wohl gelesen. Bisher bin ich es gewohnt, dass nicht alle Administratoren mit dem Benutzernamen "Administrator" ihre Arbeit verrichten sondern durchaus einen abweichenden Benutzernamen haben können. Die UAC ist an sich eine feine Sache, jedoch sollte es nicht zu solchen Fehlern kommen, dass zunächst net use ausgeführt wird, dann die Rechte weggenommen werden und der Explorer die Netzlaufwerke nicht mehr anzeigen kann. Zumindest müsste hier die tolle Frage kommen, ob man das zulassen möchte.
PS: Du verzeihst uns das wir nicht davon ausgegangen sind das deine Benutzer als Domänenadmins arbeiten?
PS: machen sie doch gar nicht 
Gruß Sebastian
