5
Powershell, CMDlets werden nicht geladen
Hallo allerseits,
da ihr mir bei meinem letzten Powershell so gut geholfen habt, möchte ich gerne noch mal euer geballtes Wissen in Anspruch nehmen
Ich habe ein Powershell-Script geschrieben, welches die Anmeldungen am Server ausliest. Um das zu machen muss ich das CMDLet über
Lasse ich den NSClient++ 0.3.8 standardmäßig unter dem Nutzer "lokales Systemkonto" laufen, kommt die folgende Meldung:
Lasse ich den NSClient++ 0.3.8 unter dem Nutzer "Administrator" laufen, funktioniert mein Script ohne Probleme. Das "Import-Module PSTerminalServices" funktioniert.
Fragen:
1. Wisst ihr unter welchem Account ich den NSClient laufen lassen kann, dass er nicht zuviele Rechte hat und trotzdem die Module lädt?
2. Wisst ihr wie trotz der starken Berechtigung des "lokales Systemkontos" das CMDlet reinladen kann?
3. Welche Berechtigungen sind den notwendig, damit das Laden der CMDLets klapp?
da ihr mir bei meinem letzten Powershell so gut geholfen habt, möchte ich gerne noch mal euer geballtes Wissen in Anspruch nehmen
Ich habe ein Powershell-Script geschrieben, welches die Anmeldungen am Server ausliest. Um das zu machen muss ich das CMDLet über
Import-Module PSTerminalServices
reinladen was auch während meiner Tests unter dem Nutzer "Administrator" funktioniert.Lasse ich den NSClient++ 0.3.8 standardmäßig unter dem Nutzer "lokales Systemkonto" laufen, kommt die folgende Meldung:
Das angegebene Modul wurde nicht geladen, da in keinem Modulverzeichnis eine gütige Moduldatei gefunden wurde.
Bei C:\Programme\NSClient++\scripts\check_ts-stempel-clients.ps1:9 Zeichen:14
+ CategoryInfo : ResourceUnavailable: (PSTerminalServices:String)
[Import-Module], FileNotFoundException
+ FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand
Bei C:\Programme\NSClient++\scripts\check_ts-stempel-clients.ps1:9 Zeichen:14
Import-Module <<<< PSTerminalServices
+ CategoryInfo : ResourceUnavailable: (PSTerminalServices:String)[Import-Module], FileNotFoundException
+ FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand
Lasse ich den NSClient++ 0.3.8 unter dem Nutzer "Administrator" laufen, funktioniert mein Script ohne Probleme. Das "Import-Module PSTerminalServices" funktioniert.
Fragen:
1. Wisst ihr unter welchem Account ich den NSClient laufen lassen kann, dass er nicht zuviele Rechte hat und trotzdem die Module lädt?
2. Wisst ihr wie trotz der starken Berechtigung des "lokales Systemkontos" das CMDlet reinladen kann?
3. Welche Berechtigungen sind den notwendig, damit das Laden der CMDLets klapp?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 154891
Url: https://administrator.de/forum/powershell-cmdlets-werden-nicht-geladen-154891.html
Ausgedruckt am: 23.12.2024 um 08:12 Uhr
5 Kommentare
Neuester Kommentar
was sacht den der schreiber des CMDLets?
irgend wo ist doch dafür bestimmt eine anleitung/readme oder sowas.
ich kenne und kann diese cmdlet nicht ausführen und testen da ich kein
terminalserver habe.
einfach auf der herstelelr seite mal schauen.
kann das helfen? http://lmgtfy.com/?q=NSClient++%20berechtigung
gruß michael
irgend wo ist doch dafür bestimmt eine anleitung/readme oder sowas.
ich kenne und kann diese cmdlet nicht ausführen und testen da ich kein
terminalserver habe.
einfach auf der herstelelr seite mal schauen.
kann das helfen? http://lmgtfy.com/?q=NSClient++%20berechtigung
gruß michael
Hallo Michael,
es geht nicht um den NSClient sondern um die Funktion in die Powershell weitere CMDLets hineinzuladen. Welche Berechtigungen werden mindestens dafür benötigt?
es geht nicht um den NSClient sondern um die Funktion in die Powershell weitere CMDLets hineinzuladen. Welche Berechtigungen werden mindestens dafür benötigt?
Hallo,
Module kann afaik jeder Nutzer importieren, da sie ja jeweils auch nur für seine Sitzung gültig sind. Mir fallen spontan zwei Gründe ein, warum es bei einem Nutzer vielleicht nicht geht, beim anderen schon:
1. NTFS-Berechtigungen
2. Suche im falschen Pfad
Mit Get-Module bekommst du afaik die in der Admin-Session geladenen/verfügbaren Module inkl. Pfad aufgelistet. Prüfe mal, ob der andere Nutzer hier überhaupt Zugriff hat. Wenn ja: Import-Module durchsucht afaik die Verzeichnisse in der Umgebungsvariable PSModulePath. Prüfe, ob er beim eingeschränkten Nutzer passt ($env:PSModulePath).
Gruß
Filipp
Module kann afaik jeder Nutzer importieren, da sie ja jeweils auch nur für seine Sitzung gültig sind. Mir fallen spontan zwei Gründe ein, warum es bei einem Nutzer vielleicht nicht geht, beim anderen schon:
1. NTFS-Berechtigungen
2. Suche im falschen Pfad
Mit Get-Module bekommst du afaik die in der Admin-Session geladenen/verfügbaren Module inkl. Pfad aufgelistet. Prüfe mal, ob der andere Nutzer hier überhaupt Zugriff hat. Wenn ja: Import-Module durchsucht afaik die Verzeichnisse in der Umgebungsvariable PSModulePath. Prüfe, ob er beim eingeschränkten Nutzer passt ($env:PSModulePath).
Gruß
Filipp
Hallo
Ich habe genau das gleiche Problem:
Powershell - Import-Module FailoverClusters als Lokaler System User(Service)
Beim Service kann auch der User Administrator eingetragen werden und es funktioniert nicht.
Die Umgebungsvariable $env:PSModulePath verweist zu den Modulen
Gruss
Stefan
Ich habe genau das gleiche Problem:
Powershell - Import-Module FailoverClusters als Lokaler System User(Service)
Beim Service kann auch der User Administrator eingetragen werden und es funktioniert nicht.
Die Umgebungsvariable $env:PSModulePath verweist zu den Modulen
Gruss
Stefan
Das Probelm des Ganzen sache war, das Powershell als ChildProzess auch 32bit verwendet(für den Import wird 64bit gebraucht).
Folgendes funktioniert nicht:
Powershell über folgende Konsole ausführen und es Funktioniert :
Folgendes funktioniert nicht:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Powershell über folgende Konsole ausführen und es Funktioniert :
C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe
