Rozwiązywanie problemów z wykonywaniem skryptów programu PowerShell w systemie Windows Server 2008 R2

Rozwiązywanie problemów z ograniczeniami wykonywania skryptów programu PowerShell

Podczas pracy z systemem Windows Server 2008 R2 użytkownicy mogą napotkać błąd wskazujący, że w systemie wyłączone jest wykonywanie skryptów PowerShell. Ten problem może wystąpić podczas próby uruchomienia skryptu za pośrednictwem cmd.exe, nawet po ustawieniu zasad wykonywania na Bez ograniczeń.

Pomimo potwierdzenia, że ​​zasada wykonywania jest ustawiona na Nieograniczone, skrypty mogą nadal nie działać, powodując frustrację i utrudniając postęp. W tym przewodniku omówiono typowe przyczyny tego problemu i przedstawiono kroki zapewniające pomyślne wykonanie skryptu.

Zrozumienie i wdrożenie zasad wykonywania skryptów w PowerShell

Dostarczone skrypty mają na celu rozwiązanie problemu wyłączania wykonywania skryptów PowerShell w systemie Windows Server 2008 R2. Pierwszy skrypt ustawia zasady wykonywania na **Bypass** dla bieżącej sesji PowerShell przy użyciu **Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force**. To polecenie umożliwia tymczasowe uruchamianie wszystkich skryptów bez ograniczeń. Następnie skrypt przechodzi do katalogu zawierającego skrypt **Management_Install.ps1** i wykonuje go przy użyciu **powershell .Management_Install.ps1**. Takie podejście gwarantuje, że zmiana zasad wykonywania będzie tylko tymczasowa i nie wpłynie na ogólny stan bezpieczeństwa systemu.

Drugi skrypt, plik wsadowy, również ustawia politykę wykonywania na **Bypass**, ale robi to z wiersza poleceń. Aby to osiągnąć, używa **powershell -Command "Set-ExecutionPolicy Bypass -Scope Process -Force"**. Po zmianie zasad wykonywania skrypt przechodzi do katalogu skryptów i uruchamia skrypt PowerShell przy użyciu **powershell -File .Management_Install.ps1**. Skrypt wsadowy kończy się poleceniem **pauza**, które utrzymuje okno wiersza poleceń otwarte, umożliwiając użytkownikowi wyświetlenie wszelkich komunikatów wyjściowych lub komunikatów o błędach. Metoda ta jest przydatna do automatyzacji procesu i integracji go z większymi procesami wsadowymi.

Podpisywanie skryptów i bezpieczeństwo w PowerShell

Trzeci przykład skryptu pokazuje, jak podpisać skrypt PowerShell, aby zachować zgodność z bardziej rygorystycznymi zasadami wykonywania. Najpierw tworzony jest certyfikat z podpisem własnym przy użyciu **New-SelfSignedCertificate**. Certyfikat ten można następnie wyeksportować za pomocą **Export-Certificate** i zaimportować do zaufanych baz certyfikatów za pomocą **Import-Certificate**. Importując certyfikat do sklepów **TrustedPublisher** i **Root**, system będzie ufał skryptom podpisanym tym certyfikatem. Skrypt **Management_Install.ps1** jest następnie podpisywany przy użyciu **Set-AuthenticodeSignature**.

Podpisywanie skryptów gwarantuje, że w systemie mogą być wykonywane tylko zaufane skrypty, zapewniając dodatkową warstwę bezpieczeństwa. To podejście jest szczególnie przydatne w środowiskach o rygorystycznych wymaganiach bezpieczeństwa, gdzie zasady wykonywania są ustawione na **AllSigned** lub **RemoteSigned**. Podpisując skrypt, administratorzy mogą mieć pewność, że skrypty nie zostały zmodyfikowane i pochodzą z zaufanego źródła, ograniczając w ten sposób potencjalne ryzyko bezpieczeństwa. Metoda ta łączy bezpieczeństwo z funkcjonalnością, pozwalając na uruchomienie niezbędnych skryptów przy zachowaniu integralności systemu.

# Ensure the script execution policy is set to Bypass
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

# Navigate to the script directory
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"

# Execute the PowerShell script
powershell .\Management_Install.ps1

@echo off

:: Set PowerShell execution policy to Bypass
powershell -Command "Set-ExecutionPolicy Bypass -Scope Process -Force"

:: Navigate to the script directory
cd "C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\Install\Scripts"

:: Run the PowerShell script
powershell -File .\Management_Install.ps1

pause

# Sample script content
Write-Output "Executing Management Install Script"

# Save this script as Management_Install.ps1

# To sign the script, follow these steps:
# 1. Create a self-signed certificate (if you don't have one)
$cert = New-SelfSignedCertificate -DnsName "PowerShellLocalCert" -CertStoreLocation "Cert:\LocalMachine\My"

# 2. Export the certificate to a file
Export-Certificate -Cert $cert -FilePath "C:\PowerShellLocalCert.cer"

# 3. Import the certificate to Trusted Publishers and Trusted Root Certification Authorities
Import-Certificate -FilePath "C:\PowerShellLocalCert.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPublisher"
Import-Certificate -FilePath "C:\PowerShellLocalCert.cer" -CertStoreLocation "Cert:\LocalMachine\Root"

# 4. Sign the script with the certificate
Set-AuthenticodeSignature -FilePath .\Management_Install.ps1 -Certificate $cert

Zapewnienie zgodności z zasadami wykonywania skryptów i bezpieczeństwa systemu

Podczas zarządzania systemem Windows Server 2008 R2 istotne jest zrozumienie różnych zasad wykonywania dostępnych w programie PowerShell i ich wpływu na wykonywanie skryptów. Zasady wykonywania programu PowerShell mają na celu zapobieganie wykonywaniu potencjalnie szkodliwych skryptów. Cztery główne zasady to **Ograniczone**, **AllSigned**, **RemoteSigned** i **Bez ograniczeń**. **Ograniczone** to zasada domyślna, która nie pozwala na uruchamianie żadnych skryptów. **AllSigned** wymaga podpisu wszystkich skryptów i plików konfiguracyjnych przez zaufanego wydawcę. **RemoteSigned** wymaga, aby wszystkie skrypty i pliki konfiguracyjne pobrane z Internetu były podpisane przez zaufanego wydawcę, ale pozwala na uruchamianie lokalnie utworzonych skryptów bez podpisu.

Zrozumienie tych zasad pomaga administratorom wybrać odpowiedni poziom bezpieczeństwa dla ich środowiska. W scenariuszach, w których skrypty muszą być wykonywane regularnie, ustawienie zasady na **Bez ograniczeń** może być ryzykowne, ponieważ umożliwia uruchamianie wszystkich skryptów bez żadnych ograniczeń. Zamiast tego administratorzy powinni rozważyć użycie **RemoteSigned** lub **AllSigned**, aby zrównoważyć bezpieczeństwo i funkcjonalność. Podpisując skrypty i zarządzając certyfikatami, administratorzy mogą mieć pewność, że w ich systemach działają wyłącznie zaufane skrypty, zmniejszając ryzyko uruchomienia złośliwego kodu.