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 »

… a w dzienniku zdarzeń w Application and Services Log >> Microsoft >> Windows >> Task Scheduler mam błąd:

Task Scheduler failed to start „\**********” task for user „***\************”. Additional Data: Error Value: 2147943785.

oraz

Task Scheduler failed to start Task Engine „”  process due to an error occurring in „LUAIsElevatedToken” . Command=”taskeng.exe” . Additional Data: Error Value: 2147943785.

i jeszcze:

Task Scheduler failed to log on „TaskScheduler:Task:{***********}” . Failure occurred in „LogonUser” . User Action: Ensure the credentials for the task are correctly specified. Additional Data: Error Value: 1385.

o przecież moje konto ma local admina, przekazałem swoje poświadczenia podczas tworzenia zadania w harmonogramie zadań, faktycznie chciałem żeby task startował jako administrator (elevated). Nazwa użytkownika i hasło są poprawne! O co chodzi?

Enigmatyczny błąd 2147943785 oznacza brak uprawnień, ale o jakie uprawnienie chodzi?

LogOn as Batch !!!

Niestety, na serwerze nie mam uprawnień do dodania wykorzystywanego konta do uprawnionych użytkowników w Local Security Policy bo ustawienie spływa z domeny 🙁

Ale jest obejście!

Można uruchomić skrypt jako użytkownik SYSTEM. System może wszystko, działa jako elevated i może się zalogować jako batch.