Skrypty powershellowe są często używane do automatyzacji instalacji oprogramowania na serwerach. Podczas tej instalacji często spotyka się 3 główne kroki:

1. Przygotowanie instalacji, np sprawdzenie czy są obecne inne wymagane komponenty, czy jest wystarczająca ilość miejsca na dysku, czy są odpowienie foldery itp. Na tym etapie również często przekoiowujemy na serwer binaria instalacyjne

2. Właściwa instalacja programu – zazwyczaj uruchomienie batch-a instalacyjnego lub programu setup.exe z odpowienimi parametrami

3. Czynności poinstalacyjne, jak np.: usunięcie plików instalacyjnych, uruchomienie usług, konfiguracja zainstalowanego programu itp.

O ile przejście od kroku pierwszego do drugiego jest proste, bo po wykonaniu wszystkich zadań z kroku 1 przechodzisz po prostu do kroku 2, o tyle moment w którym należy wykonać krok 3 nie jest już taki oczywisty. Krok ten należy wykonać dopiero po zakończeniu pracy instalatora, który nie jest twoim skryptem, ale raczej zewnętrznym programem.

I tu przychodzi z pomocą parametr -Wait, który można używać wraz z poleceniem Start-Process:

Start-Process -FilePath "notepad.exe" -PassThru -Wait

Powyższa instrukcja uruchamia notatnik, ale skrypt zatrzyma się do momentu zakończenia naotatnika. Gdyby to polecenie uruchamiać bez przełącznika -Wait, to proces notatnika również się uruchomi, ale zaraz potem, mimo tego, że notatnik nadal działa, skrypt będzie kontynuwał pracę.  Czytaj dalej »

Zatrzymany SQL Agent – pestka! Start service i po sprawie… Ale co to? Agent nie startuje. Cała sytuacja ma miejsce na clustrze, a w logach zbyt wiele śladów znaleźć nie można:

Cluster resource 'SQL Server Agent’ in clustered service or application '******’ failed.

StartResourceService: Failed to start SQLSERVERAGENT service.  CurrentState: 1

OnlineThread: ResUtilsStartResourceService failed (status 435)

OnlineThread: Error 435 bringing resource online.

Niestety SQLAgent.OUT jest pusty.  Jedno z rozwiązań, kiedy nie wiadomo o co chodzi, jest próba uruchomienia usługi jako administrator. Ponieważ w tym przypadku Agent uruchomił się bez problemu, to przyczyną musi być brak uprawnień. Zazwyczaj chodzi np o brakujące prawo LogOnAsService. Te uprawnienia były jednak nadane. Co pomogło? Czytaj dalej »

Masz skrypt. Skrypt używa modułu. Podczas instalacji skryptu plik skryptu i moduł zostaną umieszczone w tym samym katalogu. Jak to zrobić, żeby w początkowych linijkach skryptu zidentyfikować w jakim jesteśmy katalogu i załadować z niego moduł?

Proste

import-module .\MyModule.psm1

Nie zadziała, bo .\ oznacza katalog bieżący, który nie musi być zgodny z katalogiem, w którym znajduje się skrypt. Z pomocą przychodzi jednak zmienna $MyInvocation:

$scriptDir = Split-path $MyInvocation.InvocationName -Parent
$modulePath = Join-Path $scriptDir 'MyModule.psm1' 


Import-Module $modulePath

Pierwsza linijka pozwala pobiera ścieżkę do skryptu i wycina z niej tylko katalog.

Druga linijka łaczy nazwę tego katalogu z nazwą modułu

Trzecia linijka ładuje ten moduł.

Właśnie wróciłem z ferii zimowych. Dzieci podrosły, same pstrykają zdjęcia, kolejna rola ojca została przejęta przez potomków… Pod koniec jednak trzeba jakoś scalić te paręset zdjęć i podzielić tematycznie…

Pliki miały nazwy w postaci yyyyMMdd hh:mm:ss.jpg (yyyy – rok, MM – miesiąc itd.). Chciałbym przenieść pliki z różnych aparatów do tego samego folderu, ale jeśli zdjęcia były wykonane w tej samej sekundzie, to mam problem, bo ich nazwy są takie same. Rozwiązanie, które mnie zadowoli, to dodanie do plików suffixu np. „TA” – Tato, „MA” – Mama itp. Czemy by nie skorzystać ze złożonego na szybko skryptu:

$dir = 'C:\Users\rafal\Desktop\Tata'

$suffix = '_TA'

$files = Get-ChildItem $dir

foreach($file in $files)

{

     $fileName = $file.BaseName + $suffix

     $extension = $file.Extension

     $newName = "$fileName$extension"

     Rename-Item -Path $file.FullName -NewName $newName

     echo "$newName"

}

Jak już skończyłem, to okazało się, że taką funkcjonalność ma mój program graficzny…

Szkolenie Powershell dla administratora Windows jest do końca marca 2016 dostępne w obniżonej cenie, około 15 €.

W celu aktywowania zniżki podczas zakupu kliknij „Redeem a coupon” i wpisz „FERIE”.

Na Udemy jest też dostępne szkolenie wprowadzające do SQL. Celem szkolenia jest wprowadzenie w SQL, w tym:

• Uproszczona instalacja SQL Server
• Instalacja przykładowej bazy danych
• Korzystanie z SQL Server Management Studio (SSMS)
• Korzystanie z SQL Configuration Manager
• Korzystanie z solucji i projektów w SSMS
• Przegląd pojęć związanych z relacyjną bazą danych
• Wprowadzenie do SQL Azure.

Szkolenie jest dostępne za darmo. Kolejne szkolenia na ten temat też niedługo się pojawią. Zapraszam!

Załóżmy, że masz skrypt. Prawie gotowy. Postanawiasz go trochę przerobic i zmieniasz nazwy kilku zmiennych. Sprawdzasz, skrypt wydaje się działać. Super!

Jednak w pewnym momencie… dziwne błędy… tak jakby zmienne nie miały wartości, czy coś!!!

Bardzo częsta przyczyna takiej sytuacji to… skleroza. Nie zauważyłeś, że zmienna jednak w skrypcie jeszcze gdzieś występuje, albo może wpisując nazwę zmiennej zrobiłeś drobną literówkę.

Proponuję następujące rozwiązanie. Dodaj na początku skryptu:

Set-StrictMode -Version Latest

Spowoduje to, że ilekroć odwołasz się do niezdefiniowanej zmiennej (np takiej zapomnianej podczas zmian lub z przekręconą nazwą) to skrypt wysypie się z błędem. Powiesz jak to? Opcja ma być fajna bo będzie błąd!? Tak! Bo zobacz jaki to fajny błąd:

The variable '$SQLUser’ cannot be retrieved because it has not been set.

Aaa…. czyli już wiadomo o co chodzi. Błędem jest to, ż echcesz użyć zmiennej, której wcześniej nie nadałeś wartości. Taki błąd łatwiej naprawić, niż szukać „a dlaczego to nie udało mi się zalogować do serwera SQL…”.

Opcja -version latest powoduje, że sprawdzane są zmienne użyte w różnych sytuacjach (np w napisach). Domyślnie Powershell nie krzyczy na autora, jeżeli używa niezainicjowanych zmiennych, co jest całkiem fajne na początkowym etapie nauki PowerShella. W przytczonym przykładzie działanie opcji Set-StrictMode pomogło mi wychwycić kilka błędów, które z czasem na pewno by się na mnie zemściły.

No dobra. Do włączenia remotingu na serwerze lokalnym służy polecenie

Enable-PSRemoting

Niestety to polecenie nie ma parametru -ComputerName, aby włączyć remoting na systemie zdalnym 🙁

Na szkoleniu Powershell dla administratorów Windows pokazuję, że jeśli chcesz włączyć remoting na maszynie zdalnej, to powinieneś wykorzystać zasady grupy i stosując te zasady do serwerów konfigurować je do włączenia lub wyłączenia remotingu. A co jeśli w firmie konfiguracją domeny zajmuje się ktoś inny!? Nie masz z nim kontaktu, a nawet jeśli masz to nie masz mocy przekonania kolegów o tym, że potrzebujesz włączenia remotingu. Hmmm….

Do zdalneo uruchomienia polecenia można się też posłużyć poleceniem Invoke-WMIMethod. Gdyby tak tej komencie przesłać instrukcję:

powershell.exe -command „{Enable-PSRemoting -Force}”

to cel byłby osiągnięty! Tylko jest jeden problem… Invoke-WMIMethod uruchomi polecenie nie dołączając tokenu administratora (nie jako administrator – elevated). Tymczasem Enable-PSRemoting musi być uruchamiane jako administrator!

Trzeba pokombinować. Jest metoda, która pozwala na sytemie zdalnym uruchmić polecenie jako administrator. Możesz utworzyć zadanie w harmonogramie zadań, do uruchomienia na koncie system i natychmiast to zadanie uruchomić. W zadaniu możesz zdefiniować do uruchomienia właśnie powershella włączającego Remoting!

Takie rozwiązanie proponuje książka Windows Powershell Cookboook. Oto i ono po moich małych przeróbkach Enable-PSRemotingRemotely.txt. A tu parę słów komentarza: Czytaj dalej »