Vor kurzem habe ich mich dem Windows-Team in meinem Unternehmen angeschlossen und mit meinem Entwicklerhintergrund (Java, .NET und Web im Allgemeinen) war ich ziemlich schnell an PowerShell interessiert. Ich kann seinen Wert gegenüber einfachen alten Batch-Dateien, VB, sehen ... deshalb möchte ich seine Verwendung fördern und nach und nach Menschen dazu bringen, sie gegenüber dem Rest zu bevorzugen, es sei denn, es gibt einen Grund, dies nicht zu tun.
Die Bereitstellung von PowerShell scheint ziemlich einfach zu sein, da wir die entsprechenden Patches in WSUS leicht genehmigen und die Ausführungsrichtlinie über das Gruppenrichtlinienobjekt für die integrierten AD-Server konfigurieren können.
Meine Fragen betreffen mehr die Verteilung und Verwendung von PowerShell- und PowerShell-Modulen (z. B. PCSX, PowerShellPack, hausgemacht, ...).
Für diejenigen unter Ihnen, die PowerShell bereits in Ihrem Unternehmen bereitgestellt haben:
Haben Sie ein Standardpaket für PowerShell mit einer Reihe von Modulen, die Sie auf jedem Server bereitstellen? Wenn ja, wie stellen Sie dann neue Versionen der installierten Module bereit?
Haben Sie ein zentrales PowerShell-Repository erstellt, in dem Sie alle Ihre PowerShell-Module speichern? Wenn ja, ist dieses Repository global verfügbar oder können Sie auch sekundäre Repositorys synchronisieren?
Ich bin an Tools wie Maven, Ivy und andere Software zur Abhängigkeitsverwaltung gewöhnt, weshalb ich etwas enttäuscht bin, was PowerShell in dieser Hinsicht zu bieten hat.
Ich habe ein sehr gefunden netter Artikel über dieses Thema und werde wahrscheinlich den gleichen Weg gehen, wie es meinen Anforderungen entspricht.
Verwenden Sie WinRM? Verbinden Sie sich direkt von Arbeitsstationen oder haben Sie zentrale Verwaltungsserver? Haben Sie den Zugriff auf WinRM auf diese Verwaltungsserver beschränkt?
Verwenden Sie WinRM in einer nicht verwalteten Umgebung (Server nicht in einer AD-Domäne)? Wie konfigurierst du WinRM?
Wir haben eine Netzwerkzone, in der die Server nicht Teil einer AD-Domäne sind. Daher kann ich mich nicht auf die Kerberos-Authentifizierung für WinRM verlassen.
Global, was ist Ihre Erfahrung, sind Sie mit den Ergebnissen zufrieden?
Bearbeiten: Zu Frage 2 haben wir beschlossen, ein zentrales Repository einzurichten.
Die Idee wird sein, ein Haupt-Repository zu haben, das unter Versionskontrolle (GIT) steht und zu dem wir als einzige Schreibrechte haben werden.
Von diesem Repository werden wir die Module mit einem rsync-ähnlichen Werkzeug (in unserem Fall Robocopy) zu anderen sekundären Repositories kopieren (die nur lesbare Kopien sind). Nur diese Repositories sind für die Clients zugänglich (wir müssen nur den PSModulePath auf diesen Clients aktualisieren, um sicherzustellen, dass sie auf das Repository zugreifen können).
Wir werden auch unsere Releases inszenieren, daher werden im Repository mehrere Versionen verfügbar sein: Entwicklung, Integration und Produktion.
Lassen Sie uns jedes Problem nach Kategorie behandeln.
Evangelisation
Um das Interesse an PowerShell für Ihre Mitarbeiter zu wecken, würde ich vorschlagen, mit dem Automatismus zu beginnen. Finden Sie einen gemeinsamen Schwachpunkt, der relativ einfach zu implementieren ist (um schnell etwas vor Ihren Mitarbeitern zu finden) und automatisieren Sie ihn mit PowerShell. Dann erweitern Sie von dort.
Eine andere gute Idee ist es, einen "Script Club" in Ihrem Büro zu starten, wo Sie ein paar Schulungen durchführen und Ideen oder Probleme mit Skripten in PowerShell teilen. Sie können mit einmal alle paar Wochen beginnen und sehen, wie es geht. Bei meiner Arbeit haben wir einen Buchclub, in dem wir verschiedene technische Bücher über Testen, Design und Programmierung durchgehen, es funktioniert gut.
Verpackung
Bereitstellung
Derzeit gibt es einige Optionen für die Bereitstellung.
Fernzugriff
Als Bauingenieur habe ich relativ wenige Maschinen und die volle Kontrolle über sie. Also habe ich Remoting aktiviert. Sie müssten einige IT-Leute um besseren Rat bitten.
Tags und Links powershell powershell-remoting