10
Powershell LoginScript: Laufwerke werden nicht verbunden
Hallo zusammen,
ich habe eine kurriose Situation mit meinem Powershell Loginscript:
Das Script wird benötigt, da mit dem Script neben dem normalen Laufwerksmapping noch enige andre Dinge umgesetzt werden, die sich über GPOs nicht realisieren lassen.
Das Script wird über eine GPO aufgerufen:
im Script selber werden die Laufwerke
$objWshNet.MapNetworkDrive($Buchstabe, "\\$Server\$Freigabe")
Verbunden.
Am Ende des Scripts schreibe ich mir die Ausgabe von Get-PSDrive einmal weg.
in 90% der Anmeldungen funktioniert das Ausführen und Verbinden des Scriptes.
In meiner Frage geht es um die 10% bei denen es nicht funktioniert:
In den übrigen 10% wird das Script ausgeführt (ich sehe das das Script eine Logdatei geschrieben hat) und die Ausgabe von Get-PSDrive (wird am Ende des Scriptes mit in das Log geschrieben) sieht auch wie folgt aus:
Wenn ich jetzt aber als User mit den Explorer ansehe, habe ich keine Netzlaufwerke
Auch Get-PSDrive liefert nur noch C und D zurück, obwohl 5 Sekunden vorher im Log des Scriptes alle auftauchten.
Wenn der User jetzt das Powershell Script manuell ausführt (rechtsklick > mit Powershell ausführen) werden die Laufwerke verbunden.
Das ganze lässt sich sogar noch dahingehend steigern, dass wenn man eine kleine Batch Datei hat, die auch nur das Powershell Script aufruft und die Batchdatei beim User als Logoscript einträgt es auch zuverlässig funktioniert.
Was bei den Test noch aufgefallen ist, es ist nicht Rechner und auch nicht User abhängig. Es kann sein, das es an Rechner A mit dem User A funktioniert und am Rechner A mit User B nicht. Am Rechner B funktionieren es dann sowohl bei User A und auch bei User B am Rechner C funktioniert es dann mit User A nicht aber dafür mit User B.
Wenn eine Konstellation auftritt, funktioniert es dann aber permanent nicht.
Bei allen Clients handelt es sich um aktuelle Windows 10 64 Bit Clients die alle in der Selben Domäne sind und in der selben OU liegen. Auch die User haben die Selben GPOs
Hat jemand eine Idee, wodran es liegen könnte?
Mir fällt dabei aus, das wenn das Script über das Feld Logonscript beim User im AD (über eine kleine Batch Datei aufgerufen wird) das Script an sich zu sehen ist. Wenn es über die GPO aufgerufen wird dann nicht.
Vielen Dank.
ich habe eine kurriose Situation mit meinem Powershell Loginscript:
Das Script wird benötigt, da mit dem Script neben dem normalen Laufwerksmapping noch enige andre Dinge umgesetzt werden, die sich über GPOs nicht realisieren lassen.
Das Script wird über eine GPO aufgerufen:
im Script selber werden die Laufwerke
$objWshNet.MapNetworkDrive($Buchstabe, "\\$Server\$Freigabe")
Verbunden.
Am Ende des Scripts schreibe ich mir die Ausgabe von Get-PSDrive einmal weg.
in 90% der Anmeldungen funktioniert das Ausführen und Verbinden des Scriptes.
In meiner Frage geht es um die 10% bei denen es nicht funktioniert:
In den übrigen 10% wird das Script ausgeführt (ich sehe das das Script eine Logdatei geschrieben hat) und die Ausgabe von Get-PSDrive (wird am Ende des Scriptes mit in das Log geschrieben) sieht auch wie folgt aus:
C Microsoft.PowerShell.Core\FileSystem
D Microsoft.PowerShell.Core\FileSystem
R Microsoft.PowerShell.Core\FileSystem \\SERVER\FREIGABE1
S Microsoft.PowerShell.Core\FileSystem \\SERVER\FREIGABE2
X Microsoft.PowerShell.Core\FileSystem \\SERVER\FREIGABE3
Y Microsoft.PowerShell.Core\FileSystem \\SERVER\FREIGABE4
Z Microsoft.PowerShell.Core\FileSystem \\SERVER\FREIGABE5Wenn ich jetzt aber als User mit den Explorer ansehe, habe ich keine Netzlaufwerke
Auch Get-PSDrive liefert nur noch C und D zurück, obwohl 5 Sekunden vorher im Log des Scriptes alle auftauchten.
Wenn der User jetzt das Powershell Script manuell ausführt (rechtsklick > mit Powershell ausführen) werden die Laufwerke verbunden.
Das ganze lässt sich sogar noch dahingehend steigern, dass wenn man eine kleine Batch Datei hat, die auch nur das Powershell Script aufruft und die Batchdatei beim User als Logoscript einträgt es auch zuverlässig funktioniert.
Was bei den Test noch aufgefallen ist, es ist nicht Rechner und auch nicht User abhängig. Es kann sein, das es an Rechner A mit dem User A funktioniert und am Rechner A mit User B nicht. Am Rechner B funktionieren es dann sowohl bei User A und auch bei User B am Rechner C funktioniert es dann mit User A nicht aber dafür mit User B.
Wenn eine Konstellation auftritt, funktioniert es dann aber permanent nicht.
Bei allen Clients handelt es sich um aktuelle Windows 10 64 Bit Clients die alle in der Selben Domäne sind und in der selben OU liegen. Auch die User haben die Selben GPOs
Hat jemand eine Idee, wodran es liegen könnte?
Mir fällt dabei aus, das wenn das Script über das Feld Logonscript beim User im AD (über eine kleine Batch Datei aufgerufen wird) das Script an sich zu sehen ist. Wenn es über die GPO aufgerufen wird dann nicht.
Vielen Dank.
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: 464336
Url: https://administrator.de/contentid/464336
Printed on: April 19, 2024 at 17:04 o'clock
10 Comments
Latest comment
Hi.
Es war schon häufig zu lesen, dass Logonskripte Netzlaufwerke nicht 100% zuverlässig verbinden, während group policy preferences dies 100%ig tun.
Könntest Du nicht GPP benutzen und deine Zusatzaktionen per Skript erledigen lassen?
Es war schon häufig zu lesen, dass Logonskripte Netzlaufwerke nicht 100% zuverlässig verbinden, während group policy preferences dies 100%ig tun.
Könntest Du nicht GPP benutzen und deine Zusatzaktionen per Skript erledigen lassen?
Hallo,
leider nein. Das ist keine Möglichkeit.
Es bestehen Abhängigkeiten, die ich mit GPO nicht prüfen kann.
leider nein. Das ist keine Möglichkeit.
Es bestehen Abhängigkeiten, die ich mit GPO nicht prüfen kann.
dann musst du ein Delay einbauen oder besser noch prüfen ob die Netzwerverbindung schon verfügbar ist oder solange warten bis und dann deine Laufwerke verbinden.
Hallo,
vielen Dank für den Tipp,
aber genau das mache ich mittlerweile im Script.
Und wie oben beschrieben. Laut Script sind die Laufwerke auch da (siehe ausgabe Get-PSDrive), nur sehe ich die als Anwender halt nicht. Meine Vermutung ist, das es etwas mit dem Aufruf des Scriptes über die GPO zu tun hat
vielen Dank für den Tipp,
aber genau das mache ich mittlerweile im Script.
Und wie oben beschrieben. Laut Script sind die Laufwerke auch da (siehe ausgabe Get-PSDrive), nur sehe ich die als Anwender halt nicht. Meine Vermutung ist, das es etwas mit dem Aufruf des Scriptes über die GPO zu tun hat
Aber auch die Abhängigkeiten lassen sich im den GPO‘s einbauen. Bei verschiedenen System- oder Benutzer-Variablen angefangen, über verschiedene Laufwerksmappings für verschiedene Standorte/OUs/Sicherheitsgruppen bis hin zu WMI Abfragen, die auch nichts anderes machen, als das in Deinen PowerShell Scripts.
Wenn Du die Abhängigkeiten beschreibst, könnte man nach der besten Lösung schauen.
Wenn Du die Abhängigkeiten beschreibst, könnte man nach der besten Lösung schauen.
Es mag sicher lich angehen, das es irgendwie geht, aber der Aufwand wäre nicht zu verhältnissmäßig. Dabei geht es unteranderen darum, ob gewisse Programmabhängigkeiten etc. vorhanden sind.
Darum soll es hier auch absolut nicht gehen. Mir geht es darum, warum die Laufwerke augenscheinlich mit dem Powershell Script verbunden werden, für den User aber nicht sichtbar sind.
In zwischen, kann ich noch folgendes zu diesem Problem berichtet:
Ich habe das Script temporär einmal so erweitert, das ich nach dem Verbinden eine CMD öffnet. In dieser Zeit wartet das Powershell Script, bis die CMD geschlossen wird.
Also habe ich einmal die CMD, die über das Script gestartet (links) wird und einmal eine CMD die ich als User geöffnet habe (rechts).
In beiden habe ich den Befehl net use abgesetzt.
In der CMD, die über das Script geöffnet wurde, sehe ich eine Netzwerkverbidnung, in der als User nicht
Die Ausgabe echo %username% liefert bei beiden meinen Benutzername zurück.
Im Explorer sehe ich das Laufwerk genau wie in der "manuell" gestartetet CMD nicht.
Es wirkt so, als würde das Anmeldescript in einer Art "Paralelluniversum" laufen...
Kann das evtl jemand erklären bzw. hat eine Idee, wie ich das umgehen kann?
Darum soll es hier auch absolut nicht gehen. Mir geht es darum, warum die Laufwerke augenscheinlich mit dem Powershell Script verbunden werden, für den User aber nicht sichtbar sind.
In zwischen, kann ich noch folgendes zu diesem Problem berichtet:
Ich habe das Script temporär einmal so erweitert, das ich nach dem Verbinden eine CMD öffnet. In dieser Zeit wartet das Powershell Script, bis die CMD geschlossen wird.
Also habe ich einmal die CMD, die über das Script gestartet (links) wird und einmal eine CMD die ich als User geöffnet habe (rechts).
In der CMD, die über das Script geöffnet wurde, sehe ich eine Netzwerkverbidnung, in der als User nicht
Die Ausgabe echo %username% liefert bei beiden meinen Benutzername zurück.
Im Explorer sehe ich das Laufwerk genau wie in der "manuell" gestartetet CMD nicht.
Es wirkt so, als würde das Anmeldescript in einer Art "Paralelluniversum" laufen...
Kann das evtl jemand erklären bzw. hat eine Idee, wie ich das umgehen kann?
Dein Screenshot zeigt doch, dass Du eine Shell elevated ("Administrator" in der Titelleiste) geöffnet hast, und die andere nicht. Das erklärt es.
genau das habe ich auch gesehen. Wenn man das bedenkt, findet man auch das Muster. Es trifft die User, an den Rechner wo sie Lokale Admin Rechte haben.
Es sieht so aus, als ob die Scripte, wenn Admin Rechte vorhanden sind für den Benutzer, mit Admin Rechten auch ausgeführt werden. Hat jemand eine Idee, ob man das umgehen kann und die Scripte immer ohne Admin Rechte ausgeführt werden.
An einem Rechner habe ich es getestet. Der Testbenutzer hat Lokal Admin Rechte > funktioniert nicht
Die Admin Rechte werden entzogen > funktioneirt.
Es sieht so aus, als ob die Scripte, wenn Admin Rechte vorhanden sind für den Benutzer, mit Admin Rechten auch ausgeführt werden. Hat jemand eine Idee, ob man das umgehen kann und die Scripte immer ohne Admin Rechte ausgeführt werden.
An einem Rechner habe ich es getestet. Der Testbenutzer hat Lokal Admin Rechte > funktioniert nicht
Die Admin Rechte werden entzogen > funktioneirt.
Wir sehen dein Skript nicht, aber kann es wohl sein, dass Du im Skript elevation anforderst? Wenn ja, wozu?
Nein leider nicht. Ich habe zum testen das Script auf ein Minimum (eine ziele die eine CMD aufruft) gekürzt und komme wieder zu dem selben Ergebnis.
Da ich das Problem so eingegrenzt werden konnte und das Problem nur die Administratoren trifft, sieht für meinen Fall die Lösung so aus, das die Hand voll User das Script über die „alte Variante“ zugeordnet bekommt und über die Variable im Benutzer aufgerufen wird.
Da ich das Problem so eingegrenzt werden konnte und das Problem nur die Administratoren trifft, sieht für meinen Fall die Lösung so aus, das die Hand voll User das Script über die „alte Variante“ zugeordnet bekommt und über die Variable im Benutzer aufgerufen wird.
