6
PowerShell-Module allen verfügbar machen: Profile? Firmeneigenes Repository?
Guten Morgen Administratoren,
ich entwickle hauptsächlich PowerShell-Module mit sinnvollen Funktionen für unser Team. Da einige sporadisch gebraucht werden, würde ich diese Module gerne den Kollegen auf unseren Admin-Servern zur Verfügung stellen. Nun sind aber nicht alle soo fit in PowerShell um Module zu importieren oder gleich unser Template zu nutzen (da ist es zwar eingebunden, für manche Abfragen aber wiederum zu komplex).
Ausgangssituation: Mehrere Benutzer, mehrere Admin-Server. Mehrere PowerShell-Module sollen allen zur Verfügung stehen (idealerweise ohne jegliches zutun).
Nun habe ich gesehen, dass ich mit Profilen arbeiten könnte oder ein eigenes Repository erstellen könnte, in denen die Module dann liegen.
Wie handhabt ihr so etwas, bzw. was würde hier am meisten Sinn machen?
Danke und Grüße
LKD
ich entwickle hauptsächlich PowerShell-Module mit sinnvollen Funktionen für unser Team. Da einige sporadisch gebraucht werden, würde ich diese Module gerne den Kollegen auf unseren Admin-Servern zur Verfügung stellen. Nun sind aber nicht alle soo fit in PowerShell um Module zu importieren oder gleich unser Template zu nutzen (da ist es zwar eingebunden, für manche Abfragen aber wiederum zu komplex).
Ausgangssituation: Mehrere Benutzer, mehrere Admin-Server. Mehrere PowerShell-Module sollen allen zur Verfügung stehen (idealerweise ohne jegliches zutun).
Nun habe ich gesehen, dass ich mit Profilen arbeiten könnte oder ein eigenes Repository erstellen könnte, in denen die Module dann liegen.
Wie handhabt ihr so etwas, bzw. was würde hier am meisten Sinn machen?
Danke und Grüße
LKD
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: 482019
Url: https://administrator.de/contentid/482019
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
6 Kommentare
Neuester Kommentar
Wir machen das über die Erweiterung der Environment Variable PSModulePath und legen die Module auf nen UNC Pfad
http://network-nick.blogspot.com/2015/08/import-powershell-module-from- ...
http://network-nick.blogspot.com/2015/08/import-powershell-module-from- ...
Hallo LKD,
wenn das Modul für alle Benutzer verfügbar sein soll, dann kannst du das Modul auch einfach unter C:\Program Files\WindowsPowerShell\Modules auf jedem Adminserver ablegen. Das hätte den Vorteil, dass die Module auch für geplante Aufgaben zur Verfügung stehen, die unter dem Systemaccount laufen (d.h. keinen Zugriff aufs Netzwerk haben).
Gruß
Daniel
wenn das Modul für alle Benutzer verfügbar sein soll, dann kannst du das Modul auch einfach unter C:\Program Files\WindowsPowerShell\Modules auf jedem Adminserver ablegen. Das hätte den Vorteil, dass die Module auch für geplante Aufgaben zur Verfügung stehen, die unter dem Systemaccount laufen (d.h. keinen Zugriff aufs Netzwerk haben).
Gruß
Daniel
Zitat von @dwaldmannDE:
Hallo LKD,
wenn das Modul für alle Benutzer verfügbar sein soll, dann kannst du das Modul auch einfach unter C:\Program Files\WindowsPowerShell\Modules auf jedem Adminserver ablegen. Das hätte den Vorteil, dass die Module auch für geplante Aufgaben zur Verfügung stehen, die unter dem Systemaccount laufen (d.h. keinen Zugriff aufs Netzwerk haben).
Kann man, hat aber auf der einen Seite den Nachteil das bei Updates an den Modulen die Module aktualisiert werden müssen. Geht zwar per GPP oder Skript, muss dann aber auf jeder Station ausgeführt werden, statt es nur einmal zentral zu ändern.Hallo LKD,
wenn das Modul für alle Benutzer verfügbar sein soll, dann kannst du das Modul auch einfach unter C:\Program Files\WindowsPowerShell\Modules auf jedem Adminserver ablegen. Das hätte den Vorteil, dass die Module auch für geplante Aufgaben zur Verfügung stehen, die unter dem Systemaccount laufen (d.h. keinen Zugriff aufs Netzwerk haben).
Hat halt alles seine Vor- und Nachteile, da muss man selbst abwägen.
Hallo Routerboard,
das ist natürlich richtig. Wenn sich was an einem der Module ändert, dann muss die Änderung überall verteilt werden. Lässt sich beispielsweise ganz einfach mit einem Script lösen. Die Lösung mit dem UNC-Pfad ist ja nicht schlecht, Ich wollte nur noch eine Alternative aufzeigen. Es kommt ja auch immer auf die persönliche Vorliebe des Admins an.
Gruß
Daniel
das ist natürlich richtig. Wenn sich was an einem der Module ändert, dann muss die Änderung überall verteilt werden. Lässt sich beispielsweise ganz einfach mit einem Script lösen. Die Lösung mit dem UNC-Pfad ist ja nicht schlecht, Ich wollte nur noch eine Alternative aufzeigen. Es kommt ja auch immer auf die persönliche Vorliebe des Admins an.
Gruß
Daniel
Ich würde ein eigenes Repository anlegen (Ist eigentlich nur ein Share) - auf das du schreibrechte hast, und alle anderen nur Leserechte. So kannst du schön die Module zentral verwalten, Updates einspielen etc.
Die Kollegen bekommen ins Profil nur einen EInzeiler, der alle Module aus dem Repository lädt, fertig.
Die Kollegen bekommen ins Profil nur einen EInzeiler, der alle Module aus dem Repository lädt, fertig.
Vielen Dank für all die Antworten. Ich bin mit den Profilen super klar gekommen und funktioniert genau so, wie ich mir das vorstelle.
Danke und Grüße
LKD
Danke und Grüße
LKD
