Lupus1

... nana - heute ist Samstag, die Sonne scheint, daher kein Grund, sich mit WMI /CIM usw. zu quälen. 

vielen Dank Euch für diese Hinweise dazu, werde ich mal ausführen, bei Gelegenheit.

Ich weiss nicht, soll ich es wagen, erneut Verständnisfragen zu stellen ?

Es ginge dann um die Unterschiede beim Ausführen von "New-Psdrive", je nachdem,  welcher User angemeldet wird /ist

und warum ein "scheduled-Job" zwar das Script mit o.g. "NEW-PSDRIVE" ausführt, jedoch das Windows-Laufwerk mal erscheint, 

mal aber nicht und das ohne Fehlermeldung, trotzdem im Script und bei der Scheduled-task" die Credentials des Administrators mitgegeben wurden. (O.K. ich weiss, dass man Laufwerke per GPO zuweist usw. usw.  - ist aber nicht mein Thema hier)

-L.

vor 3 Stunden schrieb MurdocX:

Dafür ist auch der Befehl: New-SmbMapping zuständig.... 

 

Für mehr Infos:

get-help New-SmbMapping -Examples

Hi,

ja, danke für den Hinweis. Mir schwante schon was in der Richtung. Aber leider nicht bei Windows 7. Deshalb such ich nach einer WMI- oder .NET-Lösung.

Man gönnt sich ja sonst nichts.

L.

 

 

Hallo,

abschliessend möchte ich für Eure Mitteilungen danken. Alles sehr hilfreich ...

Meine Frage drehte sich um die Verwendung des Powershell-commandlets "New-Psdrive", zum Zwecke des "Mappens"  als Windows-Laufwerk

und zwar so, dass der User dieses im Explorer sehen kann. Vielleicht hätte ich das am Anfang klarer ausdrücken müssen, aber da wusste ich noch nicht,

dass "New-PsDrive" dafür nicht das richtige Kommando ist. Verwirrend ist eben, dass es mal funktioniert und mal nicht; dass das Commandlet ausgeführt wird,

trotzdem aber kein sichtbares Laufwerk erscheint usw. usw.

Wahrscheinlich kommt man mit solchen Problemen gar nicht in Berührung, wenn man alles über GPO usw. administriert - war hier aber nicht mein Ansatz

und ich bin hier auch im "Scripting Forum", oder ?

Wieder was gelernt. Ab Windows8 / Server2012 gibt es ohnehin neue Commandlets.

-L.

vor 6 Minuten schrieb wolfrP:

Wenn du genau wissen willst, was dein Skript als Task macht, füg

Start-Transcript -Path ".\transcript.txt" -NoClobber

ein, dann hast du deine Consolenausgabe in einer Datei

Hallo Wolfpr,

vielen dank, das ist ja mal ein konstruktiver Beitrag. Ich sollte vielleicht anfügen, dass ich kein Powershell-Profi bin, aber daran arbeite ...

(Ironiemodus aus)

-L.

Hallo,

erst einmal vielen Dank, finde ich gut, dass Ihr Euch hier meldet.

script 1:

=====

# trigger für Job: Bei User-Logon, alle User:

$Trigger = New-JobTrigger -AtLogOn -User *

# Scriptblock mit der Aufgabe gemäß Trigger:

$Sopt = New-ScheduledJobOption -RunElevated

Register-ScheduledJob -Name mountdoz    -FilePath c:\tmp_ps\mount_drive.ps1 -Trigger $Trigger -ScheduledJobOption $Sopt

Mit o.g. Script wird ein Job im Taskplaner erstellt, Script2 startet dann bei logon

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

script2: (Auszug)

===========

 $Drive = New-PSDrive -Name $Drivename   $PS1SharePath -PSProvider FileSystem -Persist -Credential $Cred -ea Continue -Verbose

Hier wird das Laufwerk,  auf z.B. "\\server\freigabeverzeichnis"  mit dem Admin-Credential für das Zielsystem "gemountet".

Das klappt unter lokalem Admin-Account, aber nicht per Taskscheduler bei LOGON.

Grüsse

L.

Hi,

also auch mit UNC-Pfad dasselbe Ergebnis: "Nicht verfügbar ..."

-L.

P.S.

Wäre ja schön, wenn die Karre laufen würde, wäre ich der letzte, der lieber schiebte.

Hi Olaf,

sorry, melde mich wieder, wenn ich es probiert habe !

-L.

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

Hallo BOfh... Olaf,

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

-Lupus

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

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

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

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