Powershell führt Befehl falsch aus

[MurdocX 953]

vor 4 Minuten schrieb testperson:

Get-WMIObject ist so PowerShell 2.0. ;) -> Get-CimInstance. :)

Erwischt   Dieses Neuland geht noch nicht so flüssig über die Finger... 

 

Auch möglich... 

Get-CimInstance -Namespace "root\Microsoft\Windows\SMB" -Class MSFT_SmbMapping

Um das Object anzulegen, musst du diesen Befehl (unten) nutzen. Dort ist auch die Methode "Create" enthalten. Über diese kannst du das Laufwerk mappen. Die Referenz zu "Create" findest du in meinem vorherigen Post.

$WmiObject = [wmiclass]"root\Microsoft\Windows\SMB:MSFT_SmbMapping"

$WmiObject.Create( Hier kommen die Übergabeparameter rein )

Aktualisiere vorher auf .Net 4.5 und WMF 5.1.

[daabm 1.366]

Jetzt habt Ihr den TO vmtl komplett überfordert

[MurdocX 953]

Wer freiwillig nach der WMI schreit... 

[Lupus1 0]

... 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.

 

 

[Cybquest 36]

Also ich würde vermuten, das hat damit zu tun:

Wenn man z.B. eine CMD mittels "Ausführen als" als anderer User ausführt, sieht man die ursprünglich gemappten Laufwerke nicht.

Wenn Du nun als Admin ein Laufwerk mappst, sieht das der andere User nicht, da das dann nur in der entspr. Session hängt.

 

… nur mal so als Vermutung in den Raum geworfen ;)