Jump to content

Empfohlene Beiträge

Guten Tag,

ich bin neu hier und komme auch gleich mit einem merkwürdigen Verhalten der Powershell, vielleicht hat jemand eine Lösung:

In der Powershell-ISE funktioniert folgendes:

 

                    $Drive = New-PSDrive -Name "J"  -Root "\\localhost\c$" -PSProvider FileSystem  -Persist   -ea Continue -Verbose

 

... d.h. das neue Laufwerk "J" erscheint als PSDRIVE und im Explorer von Windows ("net use" zeigt das Laufwerk als "O.K" an)

Derselbe Befehl, ausgeführt in der einfachen Powershell (Kommando-Shell) funktioniert auch, führt man aber ein Script mit derselben

Befehlszeile aus, funktioniert es nicht, keine Fehlermeldung. "Get-ExecutionPolicy" liefert "bypass" oder "unrestricted".

Meine Frage: Warum verhält sich die Powershell mal so und mal anders ?

Es ist ein System mit WIN7-64bit, Powershell 5.0

danke,

Gruß

Lupus

 

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

kann es sein, dass das Skript nicht mit den nötigen Rechten ausgeführt wird? Eine Verbindung zu Admin-Shares wie C$ erfordern Administratorrechte auf dem Zielsystem.

 

Gruß, Nils

 

  • Danke 1

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo !  

Danke für Eure schnelle Rekation, die Antworten wie folgt:

 

Ich bin über das Verhalten gestolpert und führe das Script testweise auf localhost mit der benannten administrativen Freigabe aus.

Eigentlich soll es via Taskscheduler auf mehreren Clienten mit WIN7 ausgeführt werden.

Und offenbar macht es einen Unterschied, wie die Zeile 

 

                              $Drive = New-PSDrive -Name "J"  -Root "\\localhost\c$" -PSProvider FileSystem  -Persist   -ea Continue -Verbose

 

gestartet wird (manuell oder per Script).

 

Ich habe bei der Powershell auch mal den Parameter "Trustlevel" abgefragt (Standardbenutzer), aber ich möchte ja nicht alle Sicherheitsmerkmale auf Null

bringen, damit ein Script läuft. 

Und  - es gibt keine Fehlermeldung, obwohl das Laufwerk mal nicht angelegt wird ...

 

 

-Lupus

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

hier (Windows 10 v1809) funktioniert es mit Localhost auch als Skript. Anscheinend sind bei Localhost keine Adminrechte (mehr) für die Admin-Freigabe nötig. Ich meine, dass das früher nicht so war.

 

Du willst in der Praxis doch wohl auch kaum die lokale administrative Freigabe mappen, oder? Teste das Skript mal so, wie es tatsächlich laufen soll.

 

Gruß, Nils

 

bearbeitet von NilsK

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Warum willst du C$ als anderes Laufwerk verbinden? 

Ich bin bei Nils. Das Skript wird nicht die nötigen Rechte haben, um sich mit einem administrativen Share zu verbinden.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hi Nils,

vielen Dank,

ich werde Deinen Tip mal umsetzen. Ist halt nur frustrierend, an so einem (dämlichen) Problem hängen zu bleiben und da viel Zeit mit der Fehlersuche zu verlieren.

Da hätte man eben auch gerne ein Erfolgserlebnis und die Ursache gefunden ...

Grüße

Lupus1

 

 

Hi tesso,

 

ja eben, aber ich vermisse halt´ eine klare Rückmeldung vom System, was da nicht o.k. sein soll, mit dem Kommando.

-Lupus

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Wenn Du in Deinem richtigen Script nicht irgendwelche Credentials mitgeben musst, kannst Du doch dieses ganze Laufwerks-Geraffel überhaupt nicht. Benutze einfach den UNC-Pfad und gut ist!?  ;-)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo an alle,

das Script wird als "scheduled-task" per Powershell so angelegt, dass es bei "logon" eines Users ausgeführt wird.

Die Ausgabe  von "NET USE" ist aber:

                                                              Nicht verfgb K:        \\IP.IP.IP.IP\ORDNERNAME  Microsoft Windows Network

                                                             ==================================================

(Anmerkung: IP-Daten unkennlich gemacht)

Das heisst also, dass das Script das Netzwerklaufwerk anlegt, das gibt auch meine logdatei her:

14.02.2019 13:59:15 lege jetz Netzwerklaufwerk an:
14.02.2019 13:59:15 Rückmeldung:  K  
14.02.2019 13:59:15 Neues Drive erzeugt: K
14.02.2019 13:59:15#232

 

Wobei "Nicht verfgb K: " eben bedeutet, dass das Laufwerk nicht da ist. Und das verstehe ich nicht. Wenn ich das Script manuell ausführe,

klappt es.

 

Was kann ich tun ?

-Lupus

 

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo BOfh... Olaf,

 

Ja, Laufwerksbuchstabe wäre gut, sonst muss ich Änderungen machen, die sich überall durchziehen, wie wäre Deine Lösung ?

-Lupus

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo Olaf,

ich habe den Fehler weiter eingegrenzt, villeicht auch für andere interessant:

 

1.

Starte ich mein script mittels eines BATCH-Files in der Autostart wie folgt:

 

                                              powershell -file c:\tmp_ps\mount_drive.ps1

 

... dann funktioniert es und das Laufwerk erscheint als Windows-Laufwerk.

 

Starte ich es über  Aufgabenplanung -> Aufgabenplanungsbibliothek -> MS -> windows -> PowerShell -> ScheduledJobs ...

dann geht es nicht. Das heisst, das Script startet schon wie gewollt bei der Anmeldung, aber das Laufwerk ist dann wieder nicht bereit:

 

                                "Nicht verfgb K: "

 

Also liegt der Unterschied in der Art und Weise, wie das Script gestartet wird. Dabei verstehe ich dieses  "Nicht verfgb K: "

einfach nicht. Selbst wenn ich das mounten von "K" um 30 s. verzögere, alle Netzwerkverbindung also vorhasnden sind, ändert sich nichts.

Wer kann das erklären ???

 

-Lupus

 

 

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden

Werbepartner:



×