Posts Tagged by PowerShell
Definiowanie profili w Powershellu.
| 2012-05-17 | Posted by robertmandziarz under Polskie blogi IT, profile |
|
Porada opublikowana na portalu wss.pl:
Tagged: Powershell, profile, Windows 
Wyszukiwanie obiektów starszych niż “X” dni znajdujących się na zdalnym zasobie sieciowym.
| 2012-05-16 | Posted by robertmandziarz under konsola, Polskie blogi IT |
|
Inspiracją był temat założony na forum wss.pl: http://www.wss.pl/forum/watek/usuwanie-katalogow-starszych-niz-x-dni-wraz-z-zawartoscia,639367.
Dla przykładowego zasobu \\127.0.0.1\shared, możemy się za to zadanie zabrać na dwa sposoby:
1. Za pomocą Powershella.
Tutaj sprawa jest prosta i wygodna – jeśli mamy uprawnienia przydzielone na zasobie sieciowym to możemy użyć polecenia Get-ChildItem:
Get-ChildItem \\127.0.0.1\shared | `
?{ $_.CreationTime -le $(Get-Date).AddDays(X) }
Interesuje nas warunek filtrowania, tutaj wszystkie obiekty starsze lub równe (-le) niż “X” dni (AddDays(X)).
2. Użycie polecenia forfiles oraz net use.
Wykonujemy polecenia:
net use z: \\127.0.0.1\shared forfiles /D X /P z:\ /C "cmd /c echo @file" net use z: /delete
Druga metoda nie jest tak elastyczna, wkrada się też drobne oszustwo – forfiles jako parametr /D przyjmuje datę modyfikacji (lub liczbę dni) a nie stworzenia obiektu.
Tagged: konsola, Powershell, Windows 
Szybka kopia zapasowa baz danych SQL Server 2012 za pomocą Powershella
| 2012-05-12 | Posted by robertmandziarz under Polskie blogi IT |
|
Do wykonania kopii zapasowej wszystkich baz danych należy załadować moduł sqlps poleceniem:
Import-Module -Name sqlps
a następnie:
Get-ChildItem sqlserver:\sql\nazwa_serwera\nazwa_instancji\databases\ -Force | `
?{ $_.Name -ne "tempdb" } | Backup-SqlDatabase
Kilka uwag:
- Parametr -Force polecenia Get-ChildItem wymusza kopiowanie również baz systemowych.
- Backup bazy tempdb nie jest obsługiwany, w związku z czym baza ta musi być odfiltrowana z wyników polecenia Get-ChildItem.
Tagged: Powershell, SQL Server 
Powershell – szybkie sprawdzenie wolnego miejsca na dyskach
| 2012-05-09 | Posted by robertmandziarz under Polskie blogi IT |
|
Skrypt wykorzystujący połączenie powershell’a i WMI, który pozwala szybko sprawdzić ilość wolnego miejsca na dyskach:
"Nazwa komputera: $Env:computername"
"Data: $(Get-Date -uFormat "%Y-%m-%d_%H:%M")"
ForEach ( $i in (Get-WmiObject -Class Win32_LogicalDisk | `
?{ $_.DriveType -eq "3" })) {
$partycja = $i.DeviceID
$wolne = $i.FreeSpace
$rozmiar = $i.Size
"Nazwa: $partycja"
"Miejsce wolne: {0:#.00 GB}" -f ($wolne / 1GB)
"Miejsce calkowite: {0:#.00 GB}" -f ($rozmiar / 1GB)
"Procent wolnego miejsca: {0:#.00}" -f (($wolne/$rozmiar)*100)
}
Wynik przedstawia się następująco:
Tagged: Powershell, Windows 
40-tka wybiła, a jutro świętowanie ROCZNICY
| 2012-05-07 | Posted by Zygmunt B. under Polskie blogi IT, Relacje, Skrypty, WGUiSW |
|
To już miesiąc, jak stuknęła nam 40. !!!
A już jutro świętowanie. Oczywiście nie tej minionej 40, lecz 4 rocznicy powstania Grupy. Jeśli śledzicie informacje na stronie WGUiSW i Facebooku, to wiecie już, że z pewnością będzie ciekawie. Mnie niestety nie będzie 
( Liczę więc, że znajdą się osoby z aparatem, by uwiecznić to ważne dla nas wydarzenie, a może nawet zechce napisać kilka słów relacji dla grupy? 
Wróćmy jednak na razie do naszej czterdziestki. Spotkaniem kierował tym razem Łukasz Matuszewski. Program spotkania to… PowerShell, kontrola rodzicielska w wykonaniu Błażeja oraz…. NAGRODY, czyli podsumowanie cyklu Środy z certyfikatem. (agenda na stronie…)
PowerShell w dwóch podejściach. Najpierw Grzesiu Gałęzowski opowiadał o… gumowej kaczuszce A poważniej pokazał nam, że PowerShell może służyć np. do komponowania muzyki Co prawda osobiście wolę jednak muzykę z płyty CD (a przynajmniej porządnego – czyt. wysokiej jakości – mp3), ale wrażenie robi. Aż zaczynam się bać otwierać lodówkę, bo… jeszcze tam zobaczę PowerShella 
)
Niestety nie wszystko się udało Grzesiowi pokazać, gdyż dopadł nas problem z Internetem – tak bywa.
Po przerwie w konkury PowerShellowe stanął sam MVP w tym temacie – Bartosz Bielawski. Bartosz pokazał nam, że z kolejną wersją PowerShella możemy zrobić więcej, a przy tym łatwiej. Bardzo ciekawy wykład, w czasie którego namawiał między innymi do uczestnictwa w ScriptGames – coś w tym jest. Nie od dziś wiadomo, że najlepiej, najsprawniej się uczy wtedy, gdy mamy konkretne zadania do wykonania. Do tego zdrowa rywalizacja…. i w efekcie, jak twierdzi Bartosz, można zostać nawet MVP (podobno nie tak dawno nie przyszłoby mu do głowy, że jest to możliwe)
Tak zakończyła się przygoda z PowerShellem, ale oczywiście tylko w trakcie tego spotkania. Od dawna widać, że nie ma od niego ucieczki (tak jak od chmur)
Po kolejnej przerwie Błażej opowiedział jak być dobrym rodzicem. Bo dobry rodzic jednak kontroluje do czego jego dziecko ma dostęp np. w Internecie. Coraz więcej rodziców chce to robić – a nie wszyscy mają przecież przygotowanie informatyczne. Dlatego fajnie, że np. Windows 7, czy Windows 8 mają wbudowane mechanizmy znacznie ułatwiające taką kontrolę.
Okazuje się, że również producenci oprogramowania typu “antywirus” wprowadzają takie możliwości w swoich pakietach. Wprowadzają, bo badania wyraźnie wskazują, że klienci tego chcą. Błażej zapowiedział, że on na pewno będzie to robił )
Na koniec… podsumowanie prowadzonego przez Pawła Pławiaka cyklu “Środy z certyfikatem”. Poza statystyką (ilość spotkań, uczestników….) był też czas na nagrody. I tu okazało się, że (wow!!!) nagród jest więcej niż uczestniczących w losowaniu. Otóż wymóg w pełni poprawnych odpowiedzi z przynajmniej 6 spotkań, sprawił, że nikt nie odszedł bez nagrody. Fajnie, nie? Nagrody oczywiście losowała nasza Śnieżynka.
Było naprawdę fajnie, a przy tym zabawnie.
Na koniec pozostaje mi zaprosić (jeśli ktoś jeszcze ich nie widział) do obejrzenia galerii zdjęć z tego spotkania. I oczywiście na jutrzejsze ŚWIĘTOWANIE!
Tagged: PowerShell, relacje, WGUiSW 
Zmiany, zmiany, zmiany… ;)
| 2012-05-05 | Posted by Bartek Bielawski under Polskie blogi IT, prezentacje, ScriptingGames, SG2012, WGUiSW |
|
Wreszcie zakończył się kwiecień – miesiąc niezmiernie pracowity w moim wypadku. Jak wiecie w miesiącu tym toczyły się tegoroczne Scripting Games, w których miałem przyjemność uczestniczyć jako sędzia. A ponieważ staram się swoją robotę wykonywać jak najlepiej, do sędziowania przystąpiłem z pełną parą. Pod koniec nieco zabrakło mi energii, ale i tak przejrzałem i oceniłem ponad 1000 skryptów, większość (szczególnie rozbudowanych) testując. Starałem się też komentować wszystkie skrypty, które oceniłem poniżej oceny najwyższej, a i te “piątkowe” często opatrywałem stosownym komentarzem. Wszak czasem nawet jak jest bardzo dobrze, to można coś ulepszyć. 
Dodatkowo na bieżąco pisałem komentarze “ogólne” w postaci postów na moim angielskim blogu (by ludzie spoza PL również mogli zrozumieć OCB. Jak ktoś jest ciekawy, to najłatwiej je znaleźć w odpowiedniej kategorii.
Druga przyczyna sporego obciążenia to sesje: o sesji na WGUiSW pisałem już, dodatkowo dzięki inicjatywie i wsparciu Grześka Gałęzowskiego miałem przyjemność poopowiadać o ShowUI studentom (głównie) w Lublinie, w czasie odbywających się tam Lubelskich Dni Informatyki. Starałem się prezentację powiększyć, by tym razem nie skończyć przed czasem. Niestety – mimo moich zabiegów znów wyrobiłem się w 2/3 czasu, w sumie około 40 minut. Trudno jednoznacznie powiedzieć, czy się sesja podobała. Sam wiem, że nie obyło się bez błędów. Cóż, człowiek uczy się całe życie… 
Trzecia przyczyna wiązała się bezpośrednio z pracą, a raczej zaległościami, które “zawdzięczałem” chorobom moich pociech. Co prawda dało mi to czas na intensywne sędziowanie (z czego skrzętnie skorzystałem), ale jednak pewnych rzeczy zdalnie w pracy zrobić nie mogę.
Pora coś zmienić…
Jeśli ktoś zaglądał tu regularnie, to pewnie zauważył, że strona się ciapkę zmieniła. Cóż, uznałem, że pora nieco zainwestować w mojego bloga. Nie dlatego, że spodziewam się w najbliższym czasie jakichś zysków. Raczej po to, by wreszcie uczynić go czytelnym (nie napiszę ładniejszym, bo o gustach się nie dyskutuje ). Dodatkowo planuję projekt, który wymaga nieco przestrzeni na serwerze i możliwości zamieszania na blogu filmików. Planuję też zarejestrować jakąś domenę, by mój blog miał nieco bardziej… spersonalizowaną “tożsamość”. Skąd jednak filmiki? Od dłuższego czasu noszę się z pomysłem nagrywania króciutkich klipów (po polsku) dotyczących różnych aspektów pracy z Windows PowerShell. Teraz, dzięki darmowej licencji NFR na Camtasia’e i SnagIta, które uzyskałem od TechSmith, mogę plany zacząć wcielać w życie. Jeśli ktoś z Was jest zainteresowany wersją testową pierwszej części serii dotyczącej wyrażeń regularnych w PowerShellu – poproszę o kontakt, podeślę Wam URLkę i hasło. Publicznie udostępnię je dopiero jak będzie ich więcej/ będę w pełni zadowolony z jakości. Wiadomo, nawet najlepsze narzędzia (a Camtasia naprawdę jest wyśmienita) nie zrobią za człowieka wszystkiego. Dykcji na pewno poprawić nie umieją.
Podsumowanie
Dzisiejszy post jest raczej z tych krótkich i służyć ma temu, by dać znać, że nadal “dycham”. W najbliższym czasie pewnie skupię się nad wyżej wspomnianą serią filmów. Jestem też Wam i sobie dłużny jeden post w serii dotyczącej efektywnego PowerShella, o którym przypomniałem sobie przeglądając dziś wcześniejsze wpisy w trakcie testowania nowego css-a. Nie napisałem jeszcze o tym jak w prosty sposób przenosić się między trybem interaktywnym i skryptowym. Coś, co może się przydać każdemu, kto z PowerShellem “wojuje” dość regularnie. Lekki przedsmak…:
Zarządzanie kontem na Facebooku z wykorzystaniem MS PowerShell
| 2012-04-30 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim najnowszym artykułem opublikowanym na stronie www.wss.pl: ”Zarządzanie kontem na Facebooku z wykorzystaniem MS PowerShell”. http://www.wss.pl/baza-wiedzy/zarzadzanie-kontem-na-facebooku-z-wykorzystaniem-ms-powershell,2852
Dźwięki z PowerShella
| 2012-04-24 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim najnowszą poradą opublikowaną na stronie www.wss.pl: ”Dźwięki z PowerShella”. http://www.wss.pl/baza-wiedzy/porada-dzwieki-z-powershella,2829
PowerShell i Office 365
| 2012-04-23 | Posted by MKr under clouds, Polskie blogi IT |
|
Office 365 coraz częściej gości pod strzechami firm. Jak każdy inny system czy usługa wymaga pewnych czynności administracyjnych. Niektóre można wykonać z w okienka graficznego, inne można lub trzeba wypisać. O ile klikanie jest zwykle łatwiejsze, to na dłuższą metę wymaga zwykle więcej czasu w stosunku do komend wykonywanych z linii poleceń. Wymagania wstępne Można [...]
Podpinanie dedykowanej bazy danych do każdego zbioru witryn
| 2012-04-23 | Posted by Szymon Bochniak under baza zawartości, ograniczenia SharePointa, Polskie blogi IT, Porady, SharePoint Foundation 2010, SharePoint Server 2010, zbiór witryn |
|
Nie każdy wie, że SharePoint umożliwia uruchomienie osobnej bazy danych dla każdego zbioru witryn. Oczywiście domyślna konfiguracja pozwala na uruchomienie Web Aplikacji z dedykowaną bazą danych oraz możliwością dodawania do niej wielu zbiorów witryn. Dobrze jednak wiedzieć, że bazy danych zawartości możemy stworzyć dla każdego site collection.
(…)
Czytaj całośćPodpinanie dedykowanej bazy danych do każdego zbioru witryn (155 words)
© admin for SharePoint Blog, 2012. |
Permalink |
Nikt jeszcze nie skomentował tego wpisu |
Add to
del.icio.us
Post tags: baza zawartości, bazy danych, ograniczenia SharePointa, powershell, sharepoint foundation 2010, sharepoint server 2010, zbiór witryn
Lubelskie Dni Informatyki 2012
| 2012-04-22 | Posted by gsgalezowski under Lubelskie Dni Informatyki, Polskie blogi IT, zaproszenie |
|
Zapraszam na trzeci dzień IT Camp w Lublinie, poniżej agenda: IT Camp – Dzień Trzeci – Czwartek, 26 Kwietnia 2012 10:00 – 11:55 Rejestracja 12:00 – 12:15 Oficjalne rozpoczęcie dnia trzeciego 12:15 – 13:15 Wirtualizacja przyszłości – Windows 8 Mariusz Kędziora – Microsoft 13:30 – 14:30 Czy zarządzanie infrastrukturą IT musi być trudne ? jak [...]
App-V 5.0 Beta i PowerShell …
| 2012-04-11 | Posted by Joanna Subik under Polskie blogi IT, Wiirtualizacja |
|
Wirtualizacja to trend, wirtualizacja to buzzword, wirtualizacja to przyszłość. W myśl tej idei prezentuję Wam dzisiaj 2 nowinki.
1. Po pierwsze, kilka dni temu ukazała się nowa wersja (beta) Microsoft Application Virtualization 5.0, możliwy do pobrania z witryny Microsoft Connect. W nowej wersji:
- Zarządzanie wyniesione zostało do interfejsu webowego
- Zdecydowanie poprawiono łatwość użycia narzędzia w środowiskach VDI oraz jego wydajność
- Zniesione zostało ograniczenie maksymalnego rozmiaru paczki (przedtem max. rozmiar wynosił 4 GB)
- Usprawniono rozwiązywanie problemów z APP-V oraz diagnostykę potencjalnych punktów spornych – poprzez wydzielenie osobnego logu zdarzeń dla APP-V
- Zwiększona została ilość skryptów PowerShell, co pozwala na automatyzację powtarzalnych zadań oraz na integrację APP-V z już istniejącymi procesami….
….a skoro już jesteśmy przy temacie PowerShell, czas na 2 nowinkę.
2. Na blogu użytkownika JonJor została opublikowana bardzo interesująca lista wszystkich poleceń PowerShell służąca do obsługi Virtual Machine Managera. Zdecydowanie warto się z nią zapoznać, głównie we względu na ogromne możliwości jakie daje ten język skryptowy. Lista możliwa jest do pobrania w 3 formatach: docx, pdf, xps.
Office 365 Powershell – Zmiana daty wygasania hasła
| 2012-04-04 | Posted by Mateusz Świetlicki under Polskie blogi IT |
|
Scripting Games 2012–Odliczanie: 2…
| 2012-03-31 | Posted by Bartek Bielawski under Polskie blogi IT, prezentacje, ScriptingGames, SG2012, WGUiSW |
|
Ten weekend będzie mi się strasznie dłużył… Z dwóch powodów: w poniedziałek o godzinie 9 (o ile się nie “walnąłem” w przeliczeniach) pojawią się pierwsze zadania w Scripting Games. We wtorek o 18 (tu już bez konwertowania czasu, więc z pewnością absolutną niemalże) wystartuje 40-ste spotkanie WGUiSW, na którym będę miał zaszczyt (mam nadzieję, że również przyjemność) poopowiadać o najnowszej odsłonie mojego ulubionego produktu Microsoftu. Może jest w tym coś niezdrowego, ale naprawdę, chciałbym już mieć ten weekend za sobą. 
Zanim to jednak nastąpi – pora zamknąć mój mini-cykl, dziś:
2 kategorie, by każdy miał coś dla siebie
Wybór kategorii to sprawa mocno indywidualna. Oczywiście, można przesadzić w obie strony, w obu przypadkach może to być źródło niepotrzebnej frustracji. Co więc zrobić, by decyzję podjąć świadomie? Moim zdaniem trzeba ocenić:
- czy PowerShella znamy dobrze, czy wiemy o nim jedynie to, co “powie” nam o nim google?
- czy bardziej zależy nam na wyniku, czy nauce?
- czy potrzebujemy w nauce wyzwań, czy raczej sukcesów?
Każdy z tych punktów w dość oczywisty sposób popychać nas będzie w jedną, lub drugą stronę. W tym poście napisać zamierzam jedynie, dlaczego moim zdaniem warto czasem rozważyć udział w kategorii zaawansowanej, a czasem lepiej jednak skupić się na tej przeznaczonej dla początkujących.
2… Awansujemy
Moja rada: jeśli masz wątpliwości, to raczej powinieneś spróbować swoich sił w kategorii zaawansowanej. Dlaczego? Bo wątpliwości rodzić się będą wtedy, gdy patrząc na zadania z roku ubiegłego będziesz czuł, że w niższej kategorii po prostu nie mógłbyś w żaden sposób zyskać. Uczestników na ogół jest tam więcej, więc szanse zwycięstwa są mniejsze. Jeśli PowerShell to Twoja codzienność, to rozwiązanie znajdziesz bez trudu a skrypt (działający i z wodotryskami) napiszesz na kolanie, nawet bez otwierania PowerShella. Niczego się więc nie nauczysz. Oczywiście, gwarantuje to ukończenie kompletu skryptów, ale czy naprawdę o to chodzi?
Jeśli mam być szczery, to moim zdaniem ta kategoria jest również (w niektórych przypadkach) dobra dla osób, które PowerShella znają tak sobie. Ale tu warunek: odpowiednia osobowość. Jeśli nierealistyczne, wygórowane wymagania działają na Was stymulująco i sprawiają, że wchodzicie w tryb cyborga – to może być to naprawdę solidny “kopniak” dla Waszego rozwoju. Wiem coś o tym, takiego właśnie “kopa” otrzymałem dwa lata temu. I raczej nie mogę narzekać na to, gdzie mnie to doprowadziło.
Ostatni element: mimo wszystko prestiż. Rywalizując w tej kategorii będziesz konkurował z (przynajmniej teoretycznie) najlepszymi. Jeśli uzyskasz dobry wynik, to zyskasz pewien szacunek tych, którym nie udało się (z różnych przyczyn) ukończyć wszystkich skryptów. Dodatkowo na ogół grupa jest tu mniej liczna, trudniej więc “zniknąć w tłumie”, niezależnie od uzyskanego wyniku. Myślę, że warto czasem podjąć ryzyko, zwłaszcza jeśli jesteś osobą ambitną. Trudno czerpać satysfakcję z sukcesów, jeśli wynikają one z obniżania sobie poprzeczki.
1… Zaczynamy
Są jednak przypadki, kiedy kategoria dla początkujących ma sens. Jeśli na pisanie skryptów masz mało czasu, albo dopiero zaczynasz swoją przygodę z PowerShellem… By się uczyć i rozwijać, trzeba mieć odpowiednie podstawy. Bez podstaw efekt może być marny. I to zarówno wtedy, gdy brakujące ogniwo to czas, jak i wtedy, gdy braknie wiedzy. Trudno jest nauczyć się czegoś, jeśli zadania wywołują tylko frustrację i prowadzą do niezdrowej dysproporcji pomiędzy rzeczami ważnymi “obiektywnie”, a uczestnictwem w Scripting Games. Trudno jest też odpowiadać na pytania, których nie jesteśmy w stanie zrozumieć.
Druga potencjalna przyczyna to osobowość, która żywi się sukcesami, choćby najmniejszymi. Oczywiście, łatwiej o sukcesy w kategorii niższej. Jeśli więc nasz rozwój jest skuteczny tylko wtedy, gdy w danej dziedzinie odnosimy nieustannie sukcesy, to kategoria dla początkujących może nam ich dostarczać niemal codziennie przez pełne dwa tygodnie.
I wreszcie: jeśli PowerShell kojarzy Wam się raczej z narzuconą przez okoliczności męką (narzuconą przez nowe produkty wymagające jego znajomości, czy też zbliżający się powoli Windows 8), to raczej ta kategoria będzie dla Was korzystniejsza. I tak macie negatywny stosunek, a PowerShell, po przeskoczeniu pewnego poziomu, to jednak przyjemność. Skok na głęboką wodę kategorii zaawansowanej sprawi, że tylko utwierdzicie się w przekonaniu, że PowerShell nie jest dla Was. A to naprawdę świetne narzędzie, wystarczy tylko je oswoić. Udział w nim jako początkujący jest moim zdaniem świetnym sposobem, by właśnie tego dokonać. Pokochać go może nie pokochacie, ale przynajmniej przestanie Was “kąsać”.
Podsumowanie
Mam nadzieję, że troszkę pomogłem w podjęciu decyzji zarówno o udziale, jak i o samej kategorii, w której będzie startować. Jeśli macie jeszcze jakieś pytania – piszcie śmiało. Jeśli będę w stanie odpowiedzieć, na pewno to uczynię. I życzę powodzenia. 
Scripting Games 2012–Odliczanie: 4…
| 2012-03-29 | Posted by Bartek Bielawski under Początki, Polskie blogi IT, pomoc, ScriptingGames, SG2012 |
|
4 dni… tylko tyle zostało do rozpoczęcia Scripting Games. Już za kilkadziesiąt godzin ludzie z całego świata zaczną próbować swoich sił w zadaniach, które dla nich przygotował Ed Wilson. Poshcode zacznie wypełniać się tegorocznymi skryptami. Dla mnie był to zawsze szczególnie pracowity czas, w tym roku pewnie będzie to praca jeszcze intensywniejsza: czytanie, testowanie, ocenianie, komentowanie cudzych skryptów, jak sądzę, jest bardziej zasobożernym procesem, niż ich pisanie. Liczę jednak, że satysfakcja będzie proporcjonalnie większa. Zanim to jednak nastąpi – czas na przedostatnią odsłonę tego cyklu, który z założenia ma Was zachęcić do udziału Scripting Games. Dziś:
4 miejsca, gdzie znajdziecie pomoc
Pewnie jak co roku – niektóre zadania będą trudniejsze, niektóre – łatwiejsze. Dwa lata temu wszyscy mogliśmy widzieć to, co napisali inni. Od zeszłego roku – takiej możliwości uczestnicy nie mają. Dlatego dziś opiszę gdzie szukać pomocy w sytuacji, gdy jakiś element zadania stanie nam niby ość w gardle. Naturalnie, nikt za nas nie napisze rozwiązania. Ale jeśli gdzieś “utkniemy” to z całą pewnością możemy liczyć na pomoc innych. A gdzie tej pomocy szukać…?
4… Hey! Scripting Guys! Blog
Ed wkłada wiele pracy nie tylko w przygotowanie zadań, ale również w przygotowanie uczestników. Na jego blogu jest dedykowany pod tegoroczne Scripting Games “Study Guide”. To nie tylko źródło wiedzy, to również swoista wskazówka: czego można się spodziewać w ramach poszczególnych konkurencji. Dla osób “zielonych” w temacie ciekawym źródłem wiedzy (w dodatku świetnie napisanym) będą artykuły z udziałem Scripting Wife. Ponieważ żona Eda nie jest “geekiem”, jej punkt widzenia może służyć tym, którzy w PowerShellu stawiają pierwsze kroki. Do tego dwie serie zarejestrowanych webcastów (w sumie 10 godzin pełnych informacji dotyczących PowerShella). Nie wspominając o setkach innych artykułów: każdy z nich może zawierać informacje pomocne przy rozwiązywaniu zadań. Pomijając same Scripting Games, to chyba jedno z lepszych źródeł wiedzy o PowerShellu dostępnych online (i naturalnie za darmo). Polecam!
3… IRC
Usługa zapomniana i porzucona przez wielu, obca i niezrozumiała dla pozostałych. 
A jednak: na IRC istnieje miejsce, gdzie można spotkać miłośników PowerShella niemal codziennie, o dowolnej porze dnia i nocy. Ponieważ spotykają się tam ludzie z Europy, Ameryki, Australii, Azji, być może również Afryki (tu pewności nie mam) – można spodziewać się tam kogoś “aktywnego” o dowolnej porze dnia i nocy. Co jest dość istotne i pomocne: by tam się dostać nie trzeba instalować klienta irca: jeśli chcesz najpierw przekonać się, czy to w ogóle dla Ciebie możesz skorzystać z udostępnianej przez freenode wersji web – sam z niej korzystałem kilkakrotnie. Jestem tam częstym gościem, można tam też spotkać innych MVP, MCC lub po prostu entuzjastów PowerShella, którzy lubią rozmawiać o nim i dzielić się swoją wiedzą. Oczywiście, wiele tematów nie ma z nim nic wspólnego, w końcu to IRC… Nikt nie moderuje rozmów by zagwarantować, że wszystkie będą on-topic. Temat Scripting Games często tam wypływa. Można też czasem uzyskać pomoc odnośnie miejsca, gdzie umieszczane są skrypty: Joel (Jaykul), autor i właściciel poshcode.org, jest tam bardzo częstym gościem. Czy może raczej gospodarzem. 
2… Twitter
O wiele nowocześniejszy wynalazek do kontaktowania się z innymi ludźmi. Moim zdaniem – często zbyt ograniczony (lubię się rozpisać, więc 140 znaków w 9 przypadkach na 10 to dla mnie za mało). Plusem niewątpliwym jest fakt, że na Twitterze znajdziecie wielu ekspertów w zakresie PowerShella, którzy na IRCa nie zaglądają. Jeśli masz pytanie – wyślij je oznaczając tagiem #PowerShell – szansa, że uzyskasz odpowiedź jest bliska pewności. Scripting Games mają swój własny tag: #2012SG. To dwa sposoby, by uzyskać pomoc, gdy w czasie pisania skryptu napotkasz “ścianę”. Jeśli nie korzystałeś z Twittera to mogę śmiało zachęcić, wiele razy rozwiązywałem problemy/ szukałem tam rozwiązania. W zasadzie niezmiernie rzadko wysyłam informację o rzeczach nietechnicznych. Przyda się zarówno w trakcie Scripting Games, jak i po ich zakończeniu.
1… Google
Nie napiszę Bing, bo po prostu nie korzystam z niego. Z Google korzystam bardzo często rozwiązując problemy jakie napotykam w pracy. W czasie ostatnich Scripting Games również korzystałem z niego wielokrotnie. Nie wszystko można znaleźć w Get-Help, bo nie wszystko w Scripting Games skupia się na PowerShellu – czasem musimy dowiedzieć się nowych rzeczy o samym systemie Windows, o Active Directory, o platformie .NET, by stworzyć skrypt spełniający kryteria zadania. Jedna rada: jeśli traficie na coś nieoczywistego przy pomocy google – dla dobra własnego i wszystkich ludzi, którzy w przyszłości korzystać będą z Waszego skryptu, umieśćcie w nim komentarz z linkiem do strony, która pomogła Wam znaleźć rozwiązanie. Po co powtarzać googlowanie w przyszłości?
Podsumowanie
Nasz cykl powoli dobiega końca. Ostatnia część będzie poświęcona kategoriom, mam nadzieję, że pomoże ona niezdecydowanym podjąć jedyną słuszną decyzję.
Scripting Games 2012–Odliczanie: 6…
| 2012-03-27 | Posted by Bartek Bielawski under Polskie blogi IT, PowerScripting Podcast, prezentacje, ScriptingGames, SG2012, TechEd, WGUiSW |
|
Za tydzień Scripting Games będą już rozpoczęte, a ja pewnie będę zajęty sprawdzaniem tego, co napisali “sprinterzy”. 
Będę też zajęty przygotowaniami do prezentacji na 40-tym spotkaniu WGUiSW. Tym razem poopowiadam o PowerShellu v.Next, z silnym akcentem na te elementy nowej odsłony, które powinny ułatwić korzystanie z niego zarówno osobom znającym go już dość dobrze, jak i początkującym. Więcej szczegółów odnośnie spotkania na stronie grupy. Powiem Wam tylko, że będzie to mocno PowerShellowe spotkanie, bo przede mną ma jeszcze prezentację Grzegorz Gałęzowski. Już nie mogę się doczekać. 
A dziś…
6 Powodów, by uczestniczyć
Rozpisałem się poprzednio co w Scripting Games robić należy, a czego należy unikać. Ale co, jeśli ktoś w ogóle nie rozważa uczestnictwa? Cóż, jeśli ktoś lubi pisać skrypty, lubi obcować z PowerShellem – to troszkę mu się dziwię. Ale ponieważ mam świadomość, że czasem marchewka musi być nieco większa, to dziś wspomnę właśnie o marchewce. Wszystkie wymienione poniżej punkty, poza ostatnim może, wymagają tylko udziału w wybranych “eventach” – nikt nie ma obowiązku walczyć do ostatniego skryptu o główną nagrodę. Korzyść, moim zdaniem, płynąć będzie z uczestnictwa również w jednej “odsłonie”.
6… Nauka
Lubicie się uczyć? Jeśli nie, to chyba wybraliście zły zawód. 
Środowisko IT jest dynamiczne i wręcz wymusza ciągłe dokształcanie się. Ale nauka nie musi oznaczać czytania opasłych tomisk, czy nudnych (?) zewnętrznych szkoleń. Oczywiście zawsze można znaleźć lepsze książki, bardziej inspirujące szkolenia (polecam Almado w tym względzie…), ale czy nie lepiej po prostu połączyć naukę ze świetną zabawą? Scripting Games to swoisty trening mózgowych muskułów, który poniekąd zmusza nas by spojrzeć na swoje skrypty krytycznie, ale również – a może przede wszystkim – przyjrzeć się technologiom i problemom, z którymi nie mieliśmy okazji się wcześniej zetknąć. A ponieważ problemy w Scripting Games są raczej realistyczne i dotyczą naszej pracy – korzyść może być odczuwalna w przyszłości, gdy napotkamy problem uwzględniony w jednej z konkurencji (lub zbliżony) i z przyjemnością stwierdzimy, że “do tego to ja już mam skrypt”. Win-win.
5… Zabawa
Radość z udziału w Scripting Games płynie z kilku źródeł i w znacznym stopniu zależy od nastawienia. Jeśli lubicie pisać skrypty – to okazja by ich napisać 10 w tak krótkim czasie może być bardzo apetycznym “ciachem”. Inni będą czerpać przyjemność z rywalizacji. Jeszcze inni: z komentarzy i ocen wypieszczonego skryptu (choć tu oczywiście może być akurat na odwrót…) Jeszcze inni: z uczestnictwa w czymś dużym i możliwości “wypromowania” swojego nazwiska i pokazania światu jakości swoich skryptów. Uczestniczyłem w Scripting Games dwukrotnie, za każdym razem cieszył mnie każdy skrypt umieszczony na poshcode – część zadań była bardzo wymagająca i świadomość ich ukończenia daje niesamowitą satysfakcję.
4… Codzienne nagrody
Scripting Games, jak to już miało miejsce w latach ubiegłych, da Wam możliwość wygrania nagrody w losowaniu. Każdego dnia między osobami, które tego dnia opublikowały skrypty, losowane są fanty. Można wygrać co prawda tylko jeden z nich, ale każdy dodany skrypt zwiększa prawdopodobieństwo wygranej. Większość nagród związana jest z PowerShellem: książki, płatne wersje edytorów, narzędzia firm trzecich, szkolenia… Oczywiście, jeśli wyślecie tylko jeden skrypt – to wygranie nagrody wymaga odrobiny szczęścia. Jeśli komplet to jej nie wygranie – pecha.
3… Możliwość sprawdzenia się
Wiele osób ceni sobie w życiu wyzwania. Dla osób, które nie zetknęły się wcześniej z PowerShellem (poza kopi-pejst z google) wyzwaniem może być samodzielne rozwiązanie zadań kategorii początkujących. Jeśli ktoś pisuje skrypty regularnie, wyzwaniem może być napisanie kompletu w kategorii zaawansowanej w tak krótkim czasie. A zdarzają się zadania, które naprawdę wymagają masy pracy i czasu (a także wiedzy). W dodatku oceniany jest również “styl” co dla osób piszących skrypty jednorazowe może oznaczać kolejne wyzwanie: pisanie skryptów, które mogą przeczytać i zrozumieć inni. Lub oni sami po kilku miesiącach.
2… Nowe znajomości
Scripting Games to oczywiście – jak w każdej grze – rywalizacja. Ale ze względu na charakter tej rywalizacji służy ona poznawaniu innych ludzi. W czasie udziału poznałem wielu innych uczestników, lub osób stojących z boku i obserwujących całą imprezę. Ciekawe jest też poznawanie “umysłów” innych: przez porównanie rozwiązań problemów, które czasem bywają znacząco różne, uczymy się myśleć “poza pudełkiem”, co z pewnością wspomaga rozwój nie tylko w zakresie PowerShella. Nie można też wykluczyć zwycięstwa a wtedy okazji do poznania innych ludzi (czasem naprawdę wyjątkowych) będzie jeszcze więcej. Co prowadzi nas do powodu szóstego, zarezerwowanego dla tych, którzy “pójdą na całość” niezależnie od wybranej kategorii.
1… TechEd! Jeffrey Snover! PowerScripting Podcast!
Główne nagrody w Scripting Games są naprawdę wyjątkowe. TechEd to droga impreza, sam w życiu bym się chyba nie zdecydował by zapłacić za udział w niej z własnej kieszeni. Co prawda jest to doskonała okazja by poznać naprawdę wyjątkowych ludzi, ale jednak cena (przynajmniej dla mnie) jest zaporowa. Nawet cena lotu w obie strony za ocean wraz z kosztem hotelu w sumie sięga mniej-więcej połowie ceny udziału w tej konferencji. I jeśli wygrasz tę nagrodę i masz dość pieniędzy/ pracodawcę który weprze Cię w tej wyprawie – nie zastanawiaj się. Pamiętaj – nie pojedziesz tam jako szary uczestnik, lecz jako zwycięzca Scripting Games. To naprawdę robi wielką różnicę. Jeśli jednak na podróż z różnych powodów nie możesz sobie pozwolić, to zawsze zostaje nagroda, którą miałem okazję już cieszyć się dwukrotnie. Czy słyszałeś kiedykolwiek o PowerScripting Podcast? Jeśli nie, to zachęcam, by się nim zainteresować, to moim zdaniem jedno z najlepszych źródeł wiedzy o PowerShellu. Jednym ze stałych elementów jest wywiad z ludźmi z PowerShellowego światka. Takimi jak pomysłodawca, “ojciec” PowerShella, Jeffrey Snover. Albo Scripting Guy, Ed Wilson. Nagroda pocieszenia to uzupełnienie tej PowerShellowej układanki swoim nazwiskiem, swoim głosem. Wymaga to co prawda zerwania się z łóżka w środku nocy (podcast jest nagrywany wieczorem czasu amerykańskiego, więc około 3 w nocy naszego czasu), ale myślę że możliwość zadania pytań człowiekowi, który wymyślił PowerShella może być czymś wyjątkowym. Wszystko jest rejestrowane i zachowane dla potomnych…
Podsumowanie
Czas nam się kurczy, pozostaje już tylko wspomnieć o dwóch rzeczach: gdzie (moim zdaniem) najlepiej szukać pomocy oraz nieco szerzej poopowiadać o dwóch kategoriach i gdzie ewentualnie szukać wskazówek, w jakie kategorii powinniśmy spróbować swoich sił. Mam nadzieję, że dzisiejszy post przekonał wszystkich, że jeśli czas pozwala, to tylko wybór kategorii jest sprawą otwartą, udział jest oczywistą koniecznością.
Scripting Games 2012–Odliczanie: 8…
| 2012-03-25 | Posted by Bartek Bielawski under najlepsze praktyki, Polskie blogi IT, ScriptingGames, SG2012, zaawansowane funkcje |
|
Zegar tyka…
Już tylko 8 dni…
Dwa dni temu przedstawiłem moje propozycje: co moim zdaniem powinno się robić, by sędziowie byli zadowoleni z pisanych przez Was skryptów. Oczywiście, każdy sędzia jest nieco inny i co innego będzie miało dla niego znaczenie, ale sądzę, że lepiej wiedzieć czego się spodziewać, nawet jeśli gdzieś może się trafić Hiszpańska Inkwizycja. Jej nie spodziewa się nikt. 
O czym dziś będzie mowa, już wspominałem:
8 rzeczy, których należy unikać
Są pewne rzeczy, które na PowerShellowych “purystów” działają jak płachta na byka. Dziś zamierzam wymienić te, które mi osobiście wadzą najbardziej i które, z własnego doświadczenia jako uczestnika, najboleśniej odpokutowałem.
8… Write-Host.
O tym cmdlecie napisano już wiele. Problem z nim polega na tym, że często jest nadużywany do rzeczy, do których go nie stworzono. Można go czasem użyć, by wyświetlić na ekranie bajecznie kolorowe komunikaty o statusie (z tą bajecznością to niestety lekko przesadzam, jesteśmy zamknięci w 16-kolorowej klatce). Ale nigdy, przenigdy nie używajmy go do wyświetlania istotnych wyników. Taki wynik, jak sama nazwa cmdletu wskazuje, zostanie “pożarty” przez naszego hosta. Jeśli nasz skrypt/ funkcja mają komukolwiek posłużyć to nie mogą ograniczać się do jednego “ujścia”. Przekierowanie takiego wyniku gdziekolwiek (do innego polecenia, do pliku, na drukarkę) jest już praktycznie niemożliwe. Idealne ujścia dla informacji o statusie bieżącej operacji wewnątrz naszego skryptu, fatalne dla ostatecznego wyniku jego działania. A ponieważ niektórzy nabawili się przez to alergii na cmdlet w ogóle, proponuję status wyświetlać opcjonalnie (Write-Verbose/ Debug), lub używając poleceń Write-Progress (które mają tę przewagę, że łatwo je aktualizować nie zalewając użytkownika informacją).
7… Miksowanie typów na wylocie.
Pisałem, że na wyjściu naszej funkcji powinny znajdować się obiekty. Ale muszą to być obiekty jednego typu – mieszanie różnych typów zwykle kończy się fatalnie i powoduje nieoczekiwane rezultaty. Źródła “mieszania” są w zasadzie trzy głównie:
- osadzone w treści stringi. Ładnie wyglądają, ale niestety lądują w wyniku funkcji.
- korzystanie z metod .NET bez dbania o ich rezultat: często zwracają one jakieś liczby (indeks) lub wartości logiczne ($true/ $false)
- założenie, że funkcja zwraca tylko to, co znajduje się po “return”, wiąże się z poprzednimi dwoma…
Dla przykładu:
function Get-List { param ( [Object[]]$Member ) $Collection = New-Object System.Collections.ArrayList "Dodajemy elementy do kolekcji..." foreach ($Item in $Member) { $Collection.Add($Item) } , $Collection } $List = Get-List -Member Alfa, Beta, Gamma $List.Count
Wynik “powinien” być 1 (temu służy przecinek poprzedzający $Collection, w przeciwnym razie PowerShell “rozbije” nam kolekcję i zwróci zwykłą listę). Nie ma tu nawet jednego return, a mimo to wynik jest 5: mamy w wynikowej kolekcji stringa (nasz komunikat), liczby całkowite (rezultat użycia metody ‘Add’) i naszą kolekcję. Naturalnie, kolekcja nie ma nic wspólnego z ArrayList, ten typ jest tylko jednym z jej elementów. A wystarczyłoby:
- użyć Write-Host lub jeszcze lepiej: –Verbose, –Debug lub –Progress zamiast wrzucania zwykłego stringa
- przekierować metody .NET na $null, Out-Null, czy w inny sposób je “uciszyć”
- używać return tylko do tego, do czego w PowerShellu służy (wcześniejsze wyjście z funkcji w oparciu o jakiegoś ifa np.)
6… Pisanie własnej pomocy.
Intencje są słuszne (pomoc jest przydatna, pisałem już o tym dwa dni temu). Rozwiązanie – fatalne. Dodanie parametru ‘?’ do naszej funkcji nie jest konieczne od wersji drugiej PowerShella. Funkcja, która coś takiego obsłuży będzie i tak albo zbyt wylewna, albo zbyt powściągliwa. Nie da nam możliwości (łatwej) podania parametrów takich jak Full, czy Examples. Napracujemy się bardzo, a i tak nikt tego nie doceni. Dlaczego? Ponieważ jeśli ktoś nie używa narzędzi skutecznych i wbudowanych to udowadnia, że ich nie zna. A to nigdy nie świadczy na naszą korzyść. Zamiast obszernej funkcji – kilka linii komentarza. Prościej, czytelniej i skuteczniej.
5… Samodzielne walidowanie parametrów.
Znów: prawdopodobnie w 9 przypadkach na 10 skutek nieznajomości funkcji języka. PowerShell umożliwia nam walidowanie parametrów na wiele różnych sposobów, włącznie z walidowaniem przy pomocy własnego skryptu. Jeśli więc początek Twoich funkcji to banda ifów sprawdzających wartość parametrów, to prawdopodobnie robisz to źle. Jest tylko jeden przypadek, gdy taka walidacja ma sens: jeśli walidować musimy kilka parametrów jednocześnie ($Pensja –gt $Wydatki). Tego PowerShell nie umożliwia, musimy więc go wyręczyć. Ale to właśnie te 1 na 10 przypadków. A może nawet 1 na 100…?
Jeśli więc chcecie walidować parametry (a robić to warto, by nie doprowadzić do nieoczekiwanych rezultatów), polecam lekturę about_Functions_Advanced_Parameters. Można też sięgnąć do mojego starszego postu, gdzie wymieniam dostępne opcje. Tu – prosty przykład. Podajemy funkcji ścieżkę do pliku, który musi istnieć by funkcja zadziałała, korzystając więc z ValidateScript upewniamy się, że tak jest w istocie:
function Get-FileStatistic { param ( [ValidateScript( { Test-Path -Path $_ })] [string]$Path ) Get-Content $Path | Measure-Object -Word -Line -Character | Select-Object Words, Lines, Characters }
Przykład bardzo prosty ale obrazuje, jak niewiele trzeba, by nasz parametr miał sensowną wartość.
4… Aliasy, szczególnie mało czytelne.
Alias w konsoli to błogosławieństwo, w skrypcie – przekleństwo. Przede wszystkim może zmniejszyć jego czytelność. O ile aliasy takie jak ‘select’, ‘where’, czy ‘measure’ są dość powszechnie używane i zrozumiałe, o tyle rzadziej stosowane (sl?) mogą sprawić kłopot nawet osobom, które z PowerShellem pracują każdego dnia. Odradzam też powszechne skrótowce “%” i “?” – oczywiście, wiele osób zna je już dobrze, ale w skrypcie moim zdaniem są przeszkodą w jego łatwym odczytaniu i zrozumieniu. A jeśli ktoś posłuży się naszym skryptem jako inspiracją i zechce go zmodyfikować, to może się na nich “potknąć”. Pisząc skrypt nie musimy oszczędzać palców: piszemy go raz i później (przynajmniej z założenia) głównie korzystamy. Więc zysk jest iluzoryczny, lepiej jednak postarać się i użyć pełnej nazwy komendy. Jest też jeszcze jedno zagrożenie: polegamy w naszym skrypcie na istnieniu aliasu, który ktoś świadomie na swoim komputerze usunął. Wówczas użytkownik naszego skryptu może spędzić sporo czasu próbując ustalić, gdzie tkwi błąd. Na tyle dużo, że potencjalny sędzia uzna po prostu, że Wasz skrypt nie działa wcale. Po co ryzykować? 
3… Niezrozumiałe nazwy zmiennych.
Ocenianie skryptów czasem musi się ograniczyć do ich przejrzenia, testowanie wszystkich może się okazać niemożliwe. Używając nazw zmiennych, które trudno później śledzić (a, b, c, pc, pr) oszczędzacie nieco czasu w czasie pisania, ale praktycznie uniemożliwiacie rozumienie logiki “na pierwszy rzut oka”. Skrypt nie przyspieszy od nazwania zmiennej krótszą nazwą, a zarówno Wam, jak i osobom czytającym Wasz skrypt będzie łatwiej, jeśli zmienne będą miały sensowne nazwy. Oczywiście, zalecam nazwy angielskie… Nie dlatego, że nie lubię mowy ojczystej. Po prostu język angielski lepiej lub gorzej znamy (niemal) wszyscy, nikt więc nie będzie miał wątpliwości co kryje się pod zmienną “Path”. “Sciezka” może kogoś zbić z pantałyku…
2… Łamanie linii przy pomocy backticka.
W PowerShellu koniec linii na ogół tożsamy jest z końcem wyrażenia, czego skutkiem jest jego wykonanie. By tego uniknąć często w skryptach korzysta się ze znaku “odwołującego” tę właściwość końca linii, “`”. Osobiście odradzam tę technikę. Wystarczy że ktoś nieumyślnie wstawi spację tuż po tym znaku i działająca komenda nagle zaczyna sprawiać problemy. Zamiast tego proponuję łamać linie na znakach, które tego feleru nie mają:
- | –> czyli następna komenda w “rurce” ląduje w kolejnej linii
- ( –> czyli dalsza część prostego wyrażenia przenosi się do linii kolejnej
- { –> rozpoczynamy ScriptBlock w pierwszej linii, kontynuujemy w następnej
- , –> lista można w prosty sposób “rozrzucić” na kilka linii
Gorzej, gdy pojedyncza komenda ma tak wiele parametrów, że można albo mieć linię o szerokości 300 znaków, albo użyć backticka. W takiej sytuacji – polecam metodę nazywaną “splatting”:
# Podajemy wartość "na sztywno" ale mogłaby być parametrem... $ComputerName = '.' $Opcje = @{ LogName = 'System' Newest = 10 After = (Get-Date).AddDays(-1) EntryType = 'Error' Source = 'Service Control Manager' ComputerName = $ComputerName } Get-EventLog @Opcje | select Message, TimeGenerated
Pozwala ona też prosto “współdzielić” parametry między komendami, jeśli są jakieś punkty wspólne. Jest też wiele innych korzyści wynikających z korzystania ze splattingu. Korzyści z backticka nie ma w zasadzie żadnych, przynajmniej do łamania linii (w innych miejscach nie niesie ze sobą takich zagrożeń).
1… Komentowanie rzeczy oczywistych.
Komentarze w funkcjach to rzecz dobra, warto czasem opatrzyć jakieś nieoczywiste operacje komentarzem, by osoba przeglądająca skrypt wiedziała dlaczego postępujemy tak, a nie inaczej. Ale trzeba wystrzegać się pisania rzeczy trywialnych i oczywistych. Prosty przykład:
# Czytam zawartość pliku... $Content = Get-Content -Path $Path # Filtruje tylko te linie, które zawierają słowo "error" $Errors = $Content | where { $_ -match 'error' } # Zapisuje do pliku $OutPath Set-Content -Path $OutPath
Pomijając jakość samego kodu: czy choć jeden komentarz coś wnosi? Wyjaśnia logikę naszego działania? Informuje nas o czymś, czego nie da się wyczytać ze samej składni? Teraz porównajmy to z przykładem pozytywnym…:
# Używam -FilterXml: tylko 2008 R2 i nowsze pozwala na użycie HashTable. Get-WinEvent -FilterXml $SomeXML -ComputerName $Computer
I już nie przyjdzie mi do głowy pytanie: czemu nie użyto łatwiejszego do zbudowania –FilterHashTable… Skoro skrypt ma zadziałać na serwerze 2008, to nie można użyć parametru, którego ta wersja serwera nie akceptuje.
Podsumowanie.
Wiemy już czego unikać, co robić. Pytanie kolejne: po co w ogóle mam sobie zawracać tym głowę. Już pojutrze: 6 powodów, by uczestniczyć.
Scripting Games 2012–Odliczanie: 10…
| 2012-03-23 | Posted by Bartek Bielawski under najlepsze praktyki, Polskie blogi IT, ScriptingGames, SG2012, zaawansowane funkcje |
|
Za dziesięć dni rozpocznie się święto miłośników PowerShella – Scripting Games. Dwa tygodnie przepełnione pisaniem skryptów (uczestnicy) i ich czytaniem/ testowaniem (sędziowie). W tym roku mam zaszczyt znajdować się w tej drugiej kategorii, nie mam więc szans, by obronić tytuł z zeszłego roku. Aby więc laur zwycięzcy pozostał w kraju nad Wisłą postanowiłem się podzielić moimi spostrzeżeniami odnośnie Scripting Games. Przede wszystkim: wyedukować, czy raczej – podzielić się kilkoma uwagami, które mogą pomóc uniknąć błędów. Później: zachęcić, wszak każdy lubi, gdy jego wysiłek jest stosownie (wy)nagrodzony. Wreszcie: pomóc wybrać odpowiedni poziom. Ale po kolei. Dziś:
10 rzeczy, które powinno się robić.
Dla wielu spośród uczestników będą to banały, ale czasem lepiej pewne rzeczy powtórzyć, bo a nuż widelec komuś się to czy owo “zapomniało”…
10… Zaawansowane funkcje.
W kategorii “początkujących” może się to wydawać lekką przesadą. I naturalnie, nie ma sensu “pakować” w stosowne dekoracje kodu, który zajmuje jedną linię. Z drugiej strony [CmdletBinding()] to tylko 17 znaków, a dają nam sporo w zamian. Naprawdę, funkcja korzystająca z $args trąci myszką. PowerShell daje nam tę elastyczność, ale jeśli piszemy coś na konkurs, to lepiej pokazać, że znamy się na temacie. Kundelki są śliczne, ale na wystawę psów ich nikt (chyba?) nie prowadzi. Zaawansowana funkcja, to funkcja “rasowa”. W rękach wprawnego skrypciarza – medalowa wręcz. 
9… Obiekt na wyjściu.
Funkcja w PowerShellu zwraca obiekty. KROPKA. Jeśli napisałeś ostatnio funkcję, która robi coś innego – przepisz to zdanie 100 razy na tablicy. Jeśli funkcja nie zwraca obiektów, to jest jednorazowa. Jeśli zwróci obiekt – można ją wpleść w zgrabną rurkę i mieć z niej pożytek jeszcze wiele razy. Warto też przyjrzeć się parametrom, szczególnie w kategorii zaawansowanej. Jeśli jest sens, by jakiś parametr “pobierał” obiekty (lub też ich właściwości) z rurki – grzechem zaniedbania będzie pominięcie tego. Znów: troszkę się trzeba z tym “naklikać”, ale późniejsze użycie może się okazać po wielekroć przyjaźniejsze użytkownikowi.
8… Comment Based Help.
Jeśli piszesz funkcję i wymagasz, by wszyscy przejrzeli Twój skrypt by się dowiedzieć co robi (lub co gorsza: zakładasz, że na pewno odgadną co autor miał na myśli), to właśnie strzeliłeś komuś w stopę. Co gorsza: tym kimś możesz być Ty, za kilka miesięcy, o trzeciej nad ranem desperacko próbujący rozwiązać jakiś problem przy pomocy tej właśnie funkcji. Jak myślisz, co pomyślisz o tym leniu, któremu zabrakło energii, by funkcję wyposażyć w zrozumiałą i kompletną pomoc? Przecież to raptem kilka linii komentarza. W zasadzie podstawowy opis, do tego kilka przykładów – i pomoc gotowa. Get-Help to o wiele bardziej przyjazna metoda zapoznawania się z komendami w PowerShellu, niż notepad.
7… Write-Verbose i Write-Debug.
Mamy funkcję zaawansowaną (mamy, prawda?), więc skorzystajmy z tego, co ona nam oferuje. Robisz w funkcji coś “przełomowego”, gdzie potencjalnie może coś się nie udać? Daj szansę użytkownikowi wyświetlić informację, co próbujesz zrobić. Wyrzucenie informacji Verbose/ Debug zawierającej wartości zmiennych, parametrów, czy po prostu informujące o stopniu zaawansowania przydadzą się nie tylko w czasie testowania skryptu, ale również później, gdy nagle coś przestanie działać. Ponieważ domyślnie te informacje są ukryte, to nie zaśmiecamy nikomu konsoli. Dopiero gdy sam o to poprosi – robimy się wylewni. Złoty środek.
6… Obsługa błędów.
Błędy czasem można przewidzieć. Jeśli przewidujesz błąd – obsłuż go. Straszenie ludzi, że dzieje się coś złego, gdy w istocie dzieje się coś przewidywanego i naturalnego jest marnym pomysłem. Narzędzia zbyt hałaśliwe i zbyt “płochliwe” mogą zniechęcić każdego. Jeśli więc da się obsłużyć jakiś błąd – zróbmy to. I nie mam tu bynajmniej na myśli:
try { # kod naszej funkcji } catch {}
To nie obsługa błędów, to proszenie się o kłopoty. 
5… Testuj na “gołym” PowerShellu.
Maszyna miłośnika skryptów to często swoisty bazar. Moduły, funkcje, skrypty i profile pałętają się po całym twardym dysku i nigdy nie wiadomo, który akurat “wyręczy nas” przy definiowaniu elementów wykorzystywanych w naszym skrypcie. Problem polega na tym, że sędziowie skrypt będą raczej testować na innym komputerze i nagle skrypt zasypie ich stronami niezrozumiałych błędów. Jak tego uniknąć? powershell.exe –noprofile, to najlepsza możliwa odpowiedź. Najlepiej (na wszelki wypadek) uruchomić go ponownie tuż przed ostateczną kontrolą. Jeśli jak ja – od dawna macie na swoim komputerze PowerShella 3 – możecie zechcieć dorzucić tam też przełącznik “-version 2”. Chyba że faktycznie chcecie skrypt pisać pod wersję trzecią – pamiętajcie wtedy jednak o parametrze #requires. Pamiętajcie też: skrypt raz wrzucony na poshcode pozostanie niezmienny, zawsze więc przed opublikowaniem tam: testujemy, testujemy, testujemy.
4… KISS.
Prosto. Jeśli da się cmdletem – nie twórzmy klas w .NET. Jeśli da się parametrem – nie filtrujmy przy pomocy Where-Object. Dobry skrypt nie musi być długi, więcej nawet – często to właśnie te krótsze są o wiele lepsze, gdyż łatwiej je ogarnąć i zrozumieć ich logikę. Sam wiele razy popełniałem ten błąd, więc wiem co mówię. Nie dać się ponieść, skupić się na zadaniu, upraszczać by zwiększyć przejrzystość. Prosto do celu.
3… Stosować cmdlety, jeśli istnieją.
Troszkę wpisuję się to w ideę KISS, ale tu bardziej chodzi o nie odkrywanie na nowo koła. Pisanie funkcji, która zrobi to samo co istniejący cmdlet (tylko gorzej) mija się z celem. Po to Bozia dała nam Get-Command, byśmy mogli w razie czego poszukać gotowego narzędzia, które wykona za nas najcięższą robotę. Nikt nie nagrodzi nas za napisanie na nowo Get-Member, szczególnie gdy nasze zadanie dotyczy kompletnie innych rzeczy.
2… Brać sobie do serca komentarze/ artykuły sędziów.
Skrypt opatrzony przez sędziego komentarzem daje nam możliwość pracowania nad swoimi umiejętnościami. Zakładam oczywiście, że komentarz ma sens (co jest raczej regułą). Dodatkowo w zeszłym roku kilku sędziów w czasie trwania SG publikowało na swoich blogach wskazówki, które pomagały uniknąć błędów innych (przynajmniej w kolejnych zadaniach). W tym roku pewnie będzie podobnie. Te dwa źródła informacji mogą pomóc tu i teraz (przy kolejnych konkursowych skryptach) jak i w przyszłości (w czasie pisanie skryptów “produkcyjnych”).
1… Porównać swoje rozwiązanie z rozwiązaniami innych.
Takie porównanie pozwala często dostrzec rysy we własnej logice, oraz wskazać inne drogi (być może skuteczniejsze, bądź wydajniejsze) prowadzące do tego samego celu. Warto przyjrzeć się zarówno skryptom uznanym za najlepsze, jak i tym, które uzyskały noty najniższe: to pozwoli nam samodzielnie ocenić: na którym miejscu na skali znajdują się obecnie nasze umiejętności. Na koniec gier pojawiają się też rozwiązania ekspertów. I choć sam kilka razy nie do końca zgadzałem się z rozwiązaniami, które tam można było znaleźć, to dobrze jest móc porównać swoją pracę, z pracą ekspertów. Dzięki temu wyciśniemy z Scripting Games ostatnie soki.
Podsumowanie
Czas leci… Dziś przyjrzeliśmy się temu, co robić należy. Za dwa dni: 8 rzeczy, których należy unikać. Naturalnie, jeśli niebo nie zawali mi się na głowę.
40. spotkanie WGUiSW
| 2012-03-22 | Posted by gsgalezowski under Polskie blogi IT, WGUiSW, zaproszenie |
|
Zapraszam wszystkich zainteresowanych na 40 spotkanie grupy WGUiSW. AGENDA SPOTKANIA: Za kierownicy – Łukasz Matuszewski. 18.00 – 18.05 Powitanie 18.05 – 18.35 Facebook, Office 365 i Gumowa kaczuszka – automatyzacja i zarządzanie w środowisku PowerShell | Grzegorz Gałęzowski 18.35 – 18.45 Przerwa 18.45 – 19.30 PowerShell 3: łatwiej, mocniej, teraz | Bartosz Bielawski 19.30 – [...]
Sprawdzenie wersji komponentów integracyjnych z poziomu hosta za pomocą PowerShell w Hyper-V Windows Server 8
| 2012-03-21 | Posted by Dariusz Porowski under Integration Components, Jak to zrobić, Polskie blogi IT |
|
Wczoraj napisałem post Sprawdzenie wersji komponentów integracyjnych Hyper-V z poziomu gościa, w którym przedstawiłem jak sprawdzić wersję komponentów integracyjnych Hyper-V z poziomu gościa na dwa sposoby. Tym razem pokażę, jak to uczynić za pomocą PowerShell w Windows Server 8 Hyper-V z poziomu hosta.
Wystarczy wydać następujące polecenie:
Get-VM | Format-Table Name, IntegrationServicesVersion
W tym przypadku ograniczyłem się jedynie do wyświetlenia tabeli z dwoma kolumnami: nazwa maszyny wirtualnej oraz wersja komponentów integracyjnych. Tabela pokazuje wszystkie (w moim przypadku akurat jest jedna) maszyny wirtualne na hoście, na którym został wykonany cmdlet.
Zachęcam do zabaw z PowerShell. Poniżej kilka moich przykładów.:
To samo co w głównym przykładzie, ale na innym hoście (zdalnie):
Get-VM –ComputerName 'MyHVHost' | Format-Table Name, IntegrationServicesVersion
Przypisanie wersji komponentów integracyjnych konkretnej maszyny wirtualnej do zmiennej:
$MyVMIC = Get-VM –Name 'MyVM' | Select-Object IntegrationServicesVersion
To samo co powyżej, lecz na zdalnym hoscie Hyper-V:
$MyVMIC = Get-VM –Name 'MyVM' –ComputerName 'MyHVHost' | Select-Object IntegrationServicesVersion
Wyświetlenie zmiennej $MyVMIC z podaniem właściwości. Wtedy PowerShell, sam ładnie podzieli wersje na Major, Minor, Build oraz Revision 
Write-Output $MyVMIC.IntegrationServicesVersion
UWAGA! Aby “zbadać” wersję komponentów integracyjnych na Hyper-V w Windows Server 8, maszyny wirtualne muszą być uruchomione!
Formatowanie wyników w PowerShell
| 2012-03-20 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim najnowszą poradą opublikowaną na stronie www.wss.pl: „Formatowanie wyników w PowerShell”. Formatowanie wyników w PowerShell
PowerShell dla opornych, czyli Show-Command
| 2012-03-19 | Posted by Dariusz Porowski under Jak to zrobić, Polskie blogi IT, Show-Command |
|
Firma Microsoft od jakiegoś czasu w każdy swój nowopowstały produkt stara się opakować w komandlety PowerShell. Nie ukrywam, że mnie się ten pomysł podoba. Dlaczego? Bo PowerShell jest power 
Nadchodzący Windows 8 jest również dopakowany nowymi cmdletami. Jednym z nich jest Show-Command. Co to takiego, ze poświęcam temu jednemu cmdletowi aż cały post? Otóż jest to cmdlet, który powstał dla osób, które mają bariery w nauce PowerShell i przestawienia się w pełni na niego (to jest moja definicja tego cmdletu). Ok, do rzeczy…
Jak uruchomię ten cmdlet to pokaże się okienko GUI z dostanymi cmdletami w systemie. Mogę dzięki temu przejrzeć sobie listę i wyszukać coś czego potencjalnie mogę użyć. Łatwo można się domyślić czego się oczekuję, ze względu na budowę cmdletów PowerShell: Czasownik-Rzeczownik.
Show-Command
Zakładając, że wiem jaki cmdlet potrzebuję to mogę połączyć Show-Command z moim cmdletem (np. Get-VM). Wtedy zostanie wyświetlone okienko GUI z parametrami mojego cmdletu.
Show-Command Get-VM
Teraz po wypełnieniu potrzebnych dla mnie pól z parametrami mogę zrobić dwie operacje. Jedną z nich jest Copy. Wtedy zostanie skopiowana do schowka składnia wybranego cmdletu wraz z parametrami.
Drugą opcją jest Run. Po wybraniu tej opcji, cmdlet zostanie bezpośrednio przekazany cmdlet do powłoki PowerShell i wykonany.
Małym minusem wg mnie jest to, że mógł by się on najpierw pokazać w postaci “pisanej”, a nie zwracać tylko wynik – ale to już takie moje czepianie się lekko na siłę 
Miłej zabawy z Show-Command. Mnie się podoba 
PowerShell–efektywnie(j), część 9
| 2012-03-17 | Posted by Bartek Bielawski under formatowanie, moduły, najlepsze praktyki, Początki, Polskie blogi IT |
|
Dziś wracamy do tematu modułów w PowerShellu. Uznałem, że jeśli teraz nie przysiądę i nie dokończę tego cyklu – to nie zrobię tego w najbliższej, dającej się przewidzieć przyszłości. Poprzednio opisałem podstawy tworzenia modułów, dziś – pora na manifest i pliki definiującej typy i format ich wyświetlania.
Manifest to prościutki skrypt PowerShella. W zasadzie zawiera on jedną tablicę skrótów z kluczami odpowiadającymi właściwościom/ ustawieniom modułu. Korzystamy przy tym z rozszerzenia .psd1, które wykorzystywane jest w zasadzie tylko w tym celu.
Nasz manifest
Manifest najprościej jest stworzyć przy pomocy polecenia New-ModuleManifest. Polecenie to spyta nas w zasadzie o wszystkie elementy, które do stworzenia manifestu są niezbędne. Większość kluczy ma dość jednoznaczne nazwy, zatrzymać się chciałbym w zasadzie przy dwóch: TypesToProcess i FormatsToProcess.
Oba klucze przyjmują tablicę stringów, w której zawrzeć możemy ścieżkę do wszystkich plików .ps1xml dotyczących naszego modułu. Pliki te służą definiowaniu dla istniejącego typu (czy to typu “prawdziwego”, czy też “wirtualnego”, stworzonego przez nas na potrzeby modułu) dodatkowych właściwości i metod (TypesToProcess) oraz sposobów wyświetlania (FormatsToProcess). Pliki .ps1xml to całkowicie odrębny temat, w dodatku dość obszerny. W wielkim skrócie można napisać, że są to pliki XML o zdefiniowanym schemacie, dzięki którym możemy “centralnie” przeprowadzać operacje podobne do tych, które wykonujemy przy pomocy poleceń takich jak Format-Table, czy Add-Member.
Manifest pozwoli nam powiązać te pliki z naszym modułem, dzięki czemu obiekty tworzone przy jego pomocy będą wyglądać tak, jak my sobie tego zażyczymy. By jednak obiekty przez nas generowane wyróżnić z tłumu innych, zwłaszcza jeśli nie chcemy dodawać “prawdziwego” typu poleceniem Add-Type, musimy skorzystać z jednej, dość prostej techniki, by nasze obiekty miały stosowną “metkę”.
Pseudo-typ i pliki PS1XML.
Skuteczne korzystanie z plików typów/ formatów wymaga od nas trzech rzeczy. Po pierwsze: funkcje tworzące nasz wymarzony obiekt muszą go odpowiednio “oznakować”:
function Get-Foo { param ( [Parameter(ValueFromPipeline = $true)] [string]$Bar ) process { $Out = New-Object PSObject -Property @{ One = 1 Two = $Bar } $Out.PSTypeNames.Insert(0, 'Typ.Wymarzony' ) $Out } }
Druga rzecz, to dodać ten wirtualny typ do naszych plików PS1XML w odpowiednim miejscu, zarówno w pliku opisującym formatki:
<Configuration>
<ViewDefinitions>
<View>
<Name>Wymarzony.FT</Name>
<ViewSelectedBy>
<TypeName>Typ.Wymarzony</TypeName>
</ViewSelectedBy>
… jak i pliku opisującym rozszerzenia naszego typu:
<?xml version="1.0" encoding="utf-8" ?>
<Types>
<Type>
<Name>Typ.Wymarzony</Name>
<Members>
Jak widać nie wymagało to wielkiej pracy, a efekt jest zwykle zadowalający. Zamiast dość losowego wyniku i obiektu bez żadnych “specjalnych” właściwości i metod możemy uzyskać zwierza, który wyświetlany będzie w sposób dla nas wygodny i będzie gotowy wykonać dla nas wybrane przez nas zadania:
To wszystko można oczywiście zrobić również bez modułu, ale moduł czyni te operacje o wiele prostszymi i daje nam (przy pomocy pliku manifestu) bardzo dokładną kontrolę.
$Env:PSModulePath czyli o instalacji modułu
Moduły można, jak widać na załączonym zrzucie ekranu, importować bez większego trudu z dowolnego miejsca na dysku. Istnieje jednak zmienna środowiskowa, która definiuje kilka folderów, z których import będzie o wiele prostszy. PSModulePath przypomina nieco zmienną PATH: ma identyczną składnię, lista folderów jest rozdzielona średnikami:
Poprawna struktura:
Ponieważ zdarzyć się może, że zrobimy literówkę w nazwie pliku lub folderu (a raczej ze względu na to, że sam kiedyś zmarnowałem sporo czasu próbując ustalić, czemu jeden z moich modułów nie działał poprawnie) stworzyłem wieki temu funkcję, która sprawdzi poprawność tych nazw i jeśli się na to zdecydujemy – błędy te naprawi. Na tym kończę serię dotyczącą efektywnego PowerShella. Troszkę się zeszło… 
Komandlety PowerShell dla Hyper-V w Windows Server 8
| 2012-03-15 | Posted by Dariusz Porowski under Jak to zrobić, Polskie blogi IT |
|
W dotychczasowych wersjach Hyper-V dostępnych w Widnows Server 2008 oraz Widnows Server 2008 R2 nie było komandletów PowerShell dla Hyper-V – przynajmniej dostępnych oficjalnie z pudełka prosto od producenta. Jak ktoś chciał to mógł skorzystać z nieoficjalnej otwartej biblioteki PowerShell management Library for Hyper-V i cieszyć się komandletami PowerShell dla Hyper-V, które w rzeczywistości tylko mapowały klasy wirtualizacyjne Windows Management Instrumentation (WMI).
Sytuacja zmienia się w Hyper-V w Windows Server 8 – są oficjalne komandlety PowerShell dla Hyper-V. Na chwilę obecną jest ich 162 i można zrobić nimi praktycznie wszystkie zadanie administracyjne oraz konfigurację Hyper-V. Oczywiście komandlety oparte są o PowerShell w wersji 3.
Spora ilość komandletów PowerShell dla Hyper-V jest już częściowo udokumentowana na stronach TechNet pod tym adresem: http://technet.microsoft.com/en-us/library/hh848559.aspx
Aby wyświetlić wszystkie komandlaty PowerShell dla Hyper-V, użyj polecenia Get-Command:
Get-Command -Module Hyper-V
Aby ograniczyć się do komandletów z określonym słowem klucz (np. network) w rzeczowniku, użyj parametru -Noun:
Get-Command -Module Hyper-V -Noun *network*
Aby ograniczyć się do komandletów z określonym słowem klucz (np. Get) w czasowniku, użyj parametru -Verb:
Get-Command -Module Hyper-V -Verb Get
Aby zobaczyć podstawową pomoc dotyczącą użycia konkretnego komandletu (np. Get-VMNetworkAdapter), daj na koniec parametr “znak zapytania” -?:
Get-VMNetworkAdapter -?
Aby zobaczyć rozszerzoną pomoc dotyczącą użycia konkretnego komandletu (np. Get-VMNetworkAdapter), użyj polecenia Get-Help z parametrem -Full:
Get-Help Get-VMNetworkAdapter -Full
Microsoft Script Explorer for Windows PowerShell Beta
| 2012-03-14 | Posted by piotrpawlik under Exchange Server, modules, Polskie blogi IT, PowerShell ISE, scripts, snippets, Techniczne |
|
Dobra robota Microsoft! Microsoft udostępnił narzędzie Microsoft Script Explorer for Windows PowerShell, które umożliwia przeszukiwanie zasobów TechNet Script Center Repository, PoshCode, Bing Search Repository, czy też zasobów sieciowych pod kątem skryptów, przystawek, modułów i przewodników krok po kroku dla języka PowerShell. Ciekawe jest to, że narzędzie pozwala wyszukiwać pod kątem produktów, na przykład Exchange Server i radzi sobie całkiem nieźle. U mnie na pewno zagości na stałe.
Microsoft Script Explorer for Windows PowerShell (pre-release)
PowerShell – formatowanie daty, a dodatkowe operacje
| 2012-03-08 | Posted by JeZZoo under Get-Date, Polskie blogi IT, Skrypty |
|
PowerShell ma tę niewdzięczną wadę, że jeśli sformatujemy sobie Get-Date za pomocą parametrów -format albo -uformat to na wyjściu nie otrzymamy już obiektu typu data ale string. Jeśli chodzi o operacje na takim obiekcie to tracimy w tym momencie jakiekolwiek związane … Czytaj dalej
Wyłącznie IPv6 powershell’em
| 2012-02-20 | Posted by Łukasz Kałużny under Client, network, Polskie blogi IT, Tips and tricks, windows server 2008r2 |
|
Wyłączenie IPV6 w windowsie jedną linijką:
New-ItemProperty “HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\” -Name “DisabledComponents” -Value 0xffffffff -PropertyType “DWord”
Managed Service Accounts
| 2012-02-20 | Posted by TechNet Polska under Grzegorz Tworek, IT Pro blogerzy, konfiguracja, Polskie blogi IT, procesy i usługi, Zarządzanie środowiskiem |
|
Jednym z najważniejszych pojęć w przypadku bezpieczeństwa systemów Windows jest "kontekst". Pojęcie to ma podstawy w obowiązującym w całym systemie założeniu, że jeżeli coś się dzieje, to musi istnieć możliwość określenia kto to zrobił i dlaczego. Dlatego proces zawsze ma "swojego" użytkownika, dzięki któremu wiadomo ile mu wolno i na którego rachunek zapisywane są wykonane działania.
Dla procesów użytkownika sprawa jest dość oczywista. Użytkownik X uruchamia notepad.exe i proces ten może otworzyć te pliki, do których użytkownik X ma dostęp. Jeżeli włączone jest rejestrowanie dostępu do plików – do dziennika zdarzeń trafi informacja, że do pliku sięgnął użytkownik X. Ciekawiej jednak robi się w sytuacji, gdy w systemie coś "dzieje się samo" i to system a nie żywy użytkownik inicjuje działania. Przykładem mogą być usługi systemowe (services). Tam, gdzie mają one postać procesu muszą mieć swojego użytkownika. Zazwyczaj jest to specjalny użytkownik "SYSTEM", który ma ogromne uprawnienia na danym komputerze, ale sięgając gdzieś przez sieć – już niekoniecznie. Fakt, że konto SYSTEM jest równocześnie potężne i ograniczone sprawia, że nie zawsze nadaje się ono do usług systemowych mających mniej standardowe zadania. Dobra praktyka w takim przypadku nakazywała utworzenie specjalnego, serwisowego użytkownika w Active Directory i uruchamianie usługi w kontekście jego konta. Mimo, że podejście to wielu lat jest powszechnie stosowane, ma jedną bardzo istotną wadę: konto serwisowe jest tak naprawdę zwykłym kontem użytkownika, a jego hasło ma kluczowe znaczenie dla działania usługi.
- Po pierwsze: niezgodność hasła na komputerze z hasłem w AD uniemożliwi działanie usługi.
- Po drugie: odczytanie hasła usługi jest technicznie możliwe (polecam doskonały artykuł Michała Grzegorzewskiego).
- Po trzecie: hasła powinny być okresowo zmieniane, aby zapewnić ich skuteczność.
W efekcie, poprawne zarządzanie kontami usług wymaga ogromnej dyscypliny a ewentualne pomyłki mogą spowodować niedostępność ważnych usług zapewnianych przez system informatyczny przedsiębiorstwa.
Dlatego, w Windows Server 2008 R2 wprowadzony został nowy mechanizm Managed Service Accounts. Z punktu widzenia komputera uruchamiającego usługę jest to możliwe do wykorzystania konto, podczas gdy po stronie Active Directory zamiast użytkownika (obiektu User) przechowywany jest obiekt typu msDS-ManagedServiceAccount.
Aby wszystko działało, koniecznie jest poinformowanie komputera, że ma używać takiego konta dla swoich usług oraz utworzenie samego obiektu w Active Directory. Od strony komputera uruchamiającego usługę wymagania są proste: Windows 7 / 2008 R2 lub nowszy. Od strony domeny można niby użyć nawet poziomu funkcjonalnego 2003, ale dopiero na 2008 R2 cały mechanizm rozwija skrzydła i w pełni automatycznie zarządza hasłami i SPNami.
Zakładam, że usługę już mamy. Teraz, żeby użyć MSA, należy wykonać następujące działania:
- Założyć MSA w Active Directory. Najlepiej przez PowerShella z modułem do zarządzania Active Directory, używając cmdlet New-ADServiceAccount. Nazwa obiektu powinna być taka jak nazwa serwisu, czyli w moim przypadku GTSvc. Domyślny kontener to specjalnie w tym celu istniejący "Managed Service Accounts".
- Przygotować hostujący usługę serwer do użycia MSA. PowerShellem można to zrobić instalując moduły do AD i używając cmdletu Install-ADServiceAccount. Pominięcie tego kroku uniemożliwi start usługi.
- Skonfigurować serwis tak, aby używał konta nazwa_domeny\nazwa_msa$ i nie podawać żadnego hasła.
Gotowe. Można uruchomić serwis i podejrzeć na przykład Process Explorerem, że nie jest związany z żadnym użytkownikiem. 
Na koniec jedna ważna uwaga dotycząca ogólnie serwisów a nie samego mechanizmu MSA. Jeżeli użytkownik ma prawa zapisu do folderu, w którym znajdują się binaria serwisu (plik exe), może zmienić nazwę oryginalnego pliku i wgrać swój. Przy najbliższym restarcie serwisu (najpóźniej przy okazji restartu systemu) zostanie uruchomiony plik użytkownika i może narobić sporo złych rzeczy łącznie z przejęciem pełnej kontroli nad serwerem. Dlatego, przechowując binaria serwisów w niestandardowych miejscach należy bardzo dokładnie zweryfikować uprawnienia do folderów. MSA może pozwolić na ograniczenie skutków ataku (na pewno jest bezpieczniej niż z kontem SYSTEM) ale to dalej może być więcej niż prawowity administrator ma ochotę pozwolić.
Autor: Grzegorz Tworek [MVP]
2012 Windows PowerShell Scripting Games
| 2012-02-19 | Posted by Bartek Bielawski under Początki, Polskie blogi IT, ScriptingGames, SG2012 |
|
Jeśli ktoś jeszcze o tym nie słyszał: już wkrótce rozpocznie się kolejna edycja Scripting Games. Kolejna okazja dla każdego miłośnika PowerShella (przyszłego, bądź obecnego) by zmierzyć się z zadaniami wymyślonymi przez “The Scripting Guy(s)!”, Eda Wilsona.
Tak jak w zeszłym roku: zadania podzielone będą na dwie kategorie. Kategoria dla początkujących ma być znów – faktycznie – dla początkujących (czytaj: zadania, z którymi przeciętny użytkownik PowerShella powinien sobie poradzić w jednej linii kodu). Kategoria dla zaawansowanych, moim skromnym zdaniem, nadaje się dla wszystkich, którzy już z PowerShellem jakiś czas pracują. Oczywiście, mogą się wtedy trafić konkurencje, w których nie uda się znaleźć rozwiązania – ale przynajmniej będzie satysfakcja, gdy jednak zadanie rozwiązać się uda.
Zadań w obu kategoriach będzie 10. Będą one ogłaszane każdego dnia roboczego przez dwa tygodnie. Na każde z zadań przeznaczony jest tydzień, więc okresy przeznaczone na wykonanie poszczególnych zadań nachodzą na siebie. Wszystkie skrypty należy umieszczać na specjalnie do tego celu przygotowanej stronie w ramach poshcode.org (prawdopodobny adres: 2012sg.poshcode.org). Skryptu raz umieszczonego nie da się modyfikować. Nie da się też wysłać kilku skryptów w ramach jednej kategorii. Dobrze jest więc kilka razy przetestować skrypt, zanim go umieścimy na stronie. Skrypty innych uczestników możemy zobaczyć dopiero wtedy, gdy skończy się okres przeznaczony na ich umieszczanie – nie można więc wrzucać cudzych skryptów jako własne.
Do udziału zachęcam wszystkich – trzeba naturalnie poświęcić nieco czasu, by “sklecić” skrypt, ale ryzykujecie w zasadzie niewiele:
- szarpanie ego, gdy ktoś zbeszta Was za użycie write-host, lub coś równie “niehigienicznego”
- czas, który moglibyście spędzić na czymś przyjemniejszym
- … więcej grzechów nie pamiętam
Co możecie zyskać?
- wiedzę
- kilka skryptów, które być może uda się (po drobnych modyfikacjach) użyć w pracy – i piszę to z autopsji
- wiedzę
- radość z konkurowania z innymi
- nagrody (zarówno za osiągnięcia, jak i losowe, za sam udział)
- wiedzę
- informację zwrotną o Waszych skryptach, zarówno od sędziów, jak i innych osób (komentarze będzie mógł do skryptów dodawać każdy)
Jak widać bilans zysków i strat wypada dość jednostronnie. 
Osobiście nie mogę się doczekać początku Scripting Games (2-go kwietnia 2012). Tym razem “przeskoczyłem” na drugą stronę ogrodzenia i nie będę uczestniczył, tylko oceniał. 
W zeszłym roku, gdy drepcząc nerwowo w miejscu oczekiwał na ostateczny wynik, spędziłem nieco czasu komentując skrypty napisane przez innych, dlatego też cieszę się na tę zamianę ról. Dodatkowo nie ryzykuję detronizacji. Choć to akurat nie było aż tak istotne. Czas oddać wspólnocie to, z czego sam czerpałem garściami przez ostatnie dwa lata…
Na koniec kilka linków:
2012 Windows PowerShell Scripting Games: All Links on One Page – strona, która należy dodać do ulubionych i na której będzie można odnaleźć wszystko to, co istotne
Grab the 2012 Scripting Games Badge! – stąd możecie pobrać “Dr Scripto” i ozdobić nim (kwestia gustu…) swój blog, kierując ludzi do w/w strony. Jak widać ja już to zrobiłem.
2012 Scripting Games Study Guide: A Resource for Learning PowerShell – tu znajdziecie informacje o tym, jaką wiedzę dobrze jest przyswoić przed rozpoczęciem Scripting Games, by później “trzaskać” zadania bez większego wysiłku. Zwykle wymienione tam bloki tematyczne znajdują później swoje odzwierciedlenie w zlecanych zadaniach.
Jeśli macie jakieś dodatkowe pytania – chętnie odpowiem, lub przekażę pytanie organizatorowi konkursu. Od 2 kwietnia zaczynam wypatrywać Waszych skryptów.
IT Camp Rzeszów: Budowanie wysoko wydajnej infrastruktury wirtualnej
| 2012-02-15 | Posted by gsgalezowski under Polskie blogi IT, Sesja, vGuru, zaproszenie |
|
Zapraszam wszystkich na mój występ w ramach vGuru Speaker – „Wprowadzenie do modułu Hyper-V dla Powershell”. 2012-02-22 14:30:00 – 2012-02-22 15:00:00, Sesja poświęcona zagadnieniom wykorzystania narzędzia PowerShell 2.0 w zarządzaniu środowiskiem Hyper-V. Dodatkowe informacje i rejestracja dostępna pod adresem: IT Camp Rzeszów.
PowerShell Server, czyli SSH dla PowerShell
| 2012-02-15 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim najnowszym artykułem opublikowanym na stronie www.wss.pl: „PowerShell Server, czyli SSH dla PowerShell”. PowerShell Server, czyli SSH dla PowerShell
Porada: PowerShell i hierarchiczna struktura systemu
| 2012-02-14 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moją poradą opublikowaną na stronie www.wss.pl: „Porada: PowerShell i hierarchiczna struktura systemu”. Porada: PowerShell i hierarchiczna struktura systemu
Porada: PowerShell jako konwerter miar.
| 2012-02-08 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moją poradą opublikowaną na stronie www.wss.pl: „Porada: PowerShell jako konwerter miar”. Porada: PowerShell jako konwerter miar
Porada: PowerShell – zdalny dostęp w grupie roboczej.
| 2012-02-08 | Posted by gsgalezowski under Polskie blogi IT, Workgroup |
|
Zapraszam wszystkich do zapoznania się z moją poradą opublikowaną na stronie www.wss.pl: „Porada: PowerShell – zdalny dostęp w grupie roboczej”. Porada: PowerShell – zdalny dostęp w grupie roboczej
Windows PowerShell Web Access
| 2012-02-01 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim artykułem: „Windows PowerShell Web Access”. Windows PowerShell Web Access
Dodawanie użytkownika domenowego do grupy lokalnych administratorów
| 2012-02-01 | Posted by Joanna Subik under Polskie blogi IT |
|
Temat jaki jest – każdy widzi. Pytanie pojawia się, jak szybko i sprawnie poradzić sobie z tematem, gdy do grupy lokalnych Administratorów trzeba dodać użytkownika na….50…100 serwerach? I to już zaraz natychmiast, bo Wasz ukochany management budzi sie po pół roku błogiego nieróbstwa i nagle mówi: backupujemy!!!! Monitorujemy!!! I agenci muszą być!!! I wszystko ma być proaktywne, zarządzane, ładnie wyglądające, a do tego jeszcze narysować piękny wykres i mailem w papierowej kopercie wysłać! Najlepiej przyniesionym na srebrnej tacy przez piękną panią asystentkę…
Wracając do tematu: metod jest dużo. Najwygodniej chyba skryptem, prawda? Poniżej kawałek kodu w PowerShellu, który pozwoli Wam, moi Drodzy Czytelnicy dodać użytkownika/grupę domenową do dowolnej liczby serwerów.
Należy w skrypcie podać nazwę swojej domeny, zapisać go jako plik z rozrzeszeniem ps1. Następnie zrzucić do pliku listę komputerów, na których zmiana zostanie dokonana. Z konsoli powershelowej/cmd proszę uruchomić następnie wspomniany skrypt, podać nazwę użytkownika, który ma zostać dodany oraz ścieżkę do pliku z listą komputerów. I gotowe.
function ListAdministrators($Group)
{
$members= $Group.psbase.invoke("Members") | %{$_.GetType().InvokeMember("Name", ‘GetProperty’, $null, $_, $null)}
$members
}
function Ping-Server {
Param([string]$srv)
$pingresult = Get-WmiObject Win32_PingStatus -Filter "Address=’$srv’"
if($pingresult.StatusCode -eq 0) {$true} else {$false}
}
if ($args.Length -ne 2) {
Write-Host "`tUsage: "
Write-Host "`t`t d:\script.ps1 netbackupsql d:\computers.txt"
Write-Host "`t`tExample: .\AddToLocalAdmin.ps1 netbackupsql d:\computers.txt"
return
}
#Your domain, change this
$domain = "Twoja_DOMENA"
#Get the user to add
$username = $args[0]
#File to read computer list from
$strComputers = Get-content $args[1]
foreach ($strComputer in $strComputers)
{
if (Ping-Server($strComputer)) {
$computer = [ADSI]("WinNT://" + $strComputer + ",computer")
$Group = $computer.psbase.children.find("administrators")
# This will list what’s currently in Administrator Group so you can verify the result
write-host -foregroundcolor green "====== $strComputer BEFORE ====="
ListAdministrators $Group
write-host -foregroundcolor green "====== BEFORE ====="
# Even though we are adding the AD account
# It is being added to the local computer and so we will need to use WinNT: provider
$Group.Add("WinNT://" + $domain + "/" + $username)
write-host -foregroundcolor green "====== $strComputer AFTER ====="
ListAdministrators $Group
write-host -foregroundcolor green "====== AFTER ====="
}
else
{
write-host -foregroundcolor red "$strComputer is not pingable"
}
}
Wynik działania skryptu:
Skrypt nie jest odkrywczy i w założeniu nie miał taki być. Ale dobrze wiedzieć, gdzie go szukać, że działa poprawnie i spełnia podstawowe założenia funkcjonalne.
WGUiSW Idol i IT Professional.
| 2012-01-30 | Posted by Bartek Bielawski under IT-professional, Polskie blogi IT, WGUiSW |
|
Dziś postanowiłem wreszcie napisać parę słów o tym, co działo się w ostatnim czasie. Grudzień – to oczywiście czas świąt. Dla mnie święta to czas podróży: w zasadzie każdego dnia przemieszczaliśmy się z miejsca na miejsce. Potem wróciliśmy z Ładniejszą Połową do Warszawy, a maluchy zostały u dziadków. Cel? Prosty – przygotowania. Emi szykowała się do spotkania z promotorem. Ja – do występu w ramach WGUiSW Idola. Dzięki pomocy Darka Porowskiego miałem sporo materiału do przemyśleń, starałem się jak najwięcej “wyciągnąć” z książek, które mi pożyczył i informacji, którymi się ze mną podzielił. Efekt? Żonka była zachwycona, a to przecież najważniejsze. 
Sam bawiłem się doskonale w trakcie prezentacji. Tego, że dotyczyła PowerShella mówić chyba nie muszę. Nadmienię tylko, że skupiłem się na dodawaniu GUI do skryptów, ze szczególnym uwzględnieniem mojego ulubionego ostatnio narzędzia – ShowUI. Zamieszczam prezentację, ale ponieważ odrobiłem lekcję dotyczącą tego, co w prezentacji znaleźć się nie powinno – to sam plik pptx wiele Wam nie da… Więc jeśli w spotkaniu nie uczestniczyliście? Cóż, pozostaje Wam trzymać kciuki bym konkurs wygrał (wątpię, ale w końcu wszystko się może zdarzyć) i przybyć na Windows Community Launch Główna nagroda to właśnie prelekcja w trakcie tego wydarzenia. BTW: ciekaw jestem – ile osób załapało o co chodzi w tym slajdzie (obrazkowi temu na slajdzie w zasadzie nie towarzyszyło nic, poza logo samej akcji i logo grupy):
Druga rzecz, która w ostatnim czasie pochłania sporo mojego czasu to rzecz nowa w moim życiu – i nie ukrywam, bardzo ekscytująca. Zostałem bowiem zaproszony do współpracy z miesięcznikiem “IT Professional”. Jest to dość ciekawa pozycja na rynku wydawniczym w Polsce – jej grupą docelową są bowiem czynni zawodowo specjaliści IT. Moja działka to (czy to nie nudne?) Windows PowerShell. A ponieważ artykuły z założenia mają być praktyczne – to opisuję dla tego czasopisma skrypty, które w ostatnim czasie zdarzyło mi się sklecić. Oczywiście, przed publikacją staram się je najpierw dopieścić, następnie odpowiednio przedstawić i wyjaśnić: co, czemu, gdzie i dlaczego. Właśnie w tym tygodniu, tuż po powrocie z ferii, znalazłem w skrzynce pierwszy numer pisma, w którym można znaleźć moje nazwisko:
Myślę, że będzie co pokazywać wnukom… 
Mam tylko nadzieję, że pomysły na skrypty nie wyczerpią się przedwcześnie… i że druga strona jest równie zadowolona ze współpracy ze mną, co ja ze współpracy z tym czasopismem. A że samo pismo jest ciekawe, to dla samego choćby egzemplarza autorskiego – warto się było pochylić nad swoimi pisanymi na kolanie skryptami i nieco je podrasować. Choć oczywiście czasu wolnego mi z tego tytułu nie przybyło… 
Obiecuję jednak w najbliższym czasie wrócić do modułów w PowerShellu. Mam nadzieję, że ktoś dotrwa…
Super user account – Konfiguracja object cache w SharePoint Server 2010
| 2012-01-12 | Posted by Szymon Bochniak under Polskie blogi IT, Porady, SharePoint Server 2010 |
|
Natrafienie na poniższy komunikat w logach serwera SharePoint oznacza brak skonfigurowanych użytkowników odpowiedzialnych za obsługę Object Cache:
Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.
To configure the account use the following command ‘stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl’. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.
Additional Data:
Current default super user account: SHAREPOINT\systems
(…)
Czytaj całośćSuper user account – Konfiguracja object cache w SharePoint Server 2010 (208 words)
© admin for SharePoint Blog, 2012. |
Permalink |
2 komentarzy |
Add to
del.icio.us
Post tags: powershell, sharepoint server 2010
Netcmdlets dla PowerShell
| 2012-01-06 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim artykułem, na temat dodatku Netcmdlets dla PowerShell. Netcmdlets
powershell gpo again
| 2011-12-23 | Posted by voytas under Polskie blogi IT |
|
if you want to display GPOs sorted by modification date:
Get-GPO -All | sort -Property modificationtime -descending | % {"`""+$_.displayname+"`""+" "+$_.modificationtime+"`n"}
if you want see:
Get-GPO -All | ? {(($_).creationtime).date -ge ((get-date).adddays(-3)).date}
before it do:
import-module grouppolicy
Powershell – efektywniej, część 8.
| 2011-12-17 | Posted by Bartek Bielawski under moduły, najlepsze praktyki, Polskie blogi IT |
|
Zgodnie z obietnicą – w tej części zajmę się modułami. Czym są moduły w PowerShellu? Moduł to rozszerzenie. Może to być zarówno rozszerzenie binarne – w formie skompilowanej biblioteki dll, jak i skryptowe – w najbardziej podstawowej formie plik zawierający odpowiedni kod PowerShella z rozszerzeniem .psm1. Nas oczywiście interesować będzie moduł skryptowy.
Po co?
Czemu moglibyśmy chcieć stworzyć moduł? Moduły nadają się świetnie do zmieniania środowiska, pozwalają zebrać funkcje/ zmienne/ aliasy związane z jakimś zagadnieniem (np. obsługa lokalnych kont na stacjach roboczych; obsługa AD w danym, lokalnym OU). Moduł sprawdza się lepiej niż wrzucanie wszystkiego do profilu – dzięki temu kod staje się bardziej przenośny, a jeśli chcemy zmienić coś w zestawie funkcji dotyczących konkretnej technologii/ zagadnienia, to nie musimy ich szukać na piechotkę. Moduł pozwala też oddzielić elementy “prywatne” od “publicznych”. Ta izolacja pozwala uniknąć sytuacji, gdy dwa narzędzia będą ze sobą walczyć o jakąś zmienną. W ilu skryptach używamy gdzieś zmiennych typu $i, albo $sum(a)? No cóż, moduły mogą pracować w swoim wewnętrznym zakresie z dowolnymi, kolidującymi zmiennymi. Jeśli moduły nie “wypluwają” ich na zewnątrz (dojdziemy do tego jak to zrobić, domyślnie żadna zmienna nie wychodzi poza moduł) – do kolizji zmiennych nigdy nie dojdzie. Nie da się tego powiedzieć o dotsourcingu – tam zawartość skryptu wpada do naszego głównego zakresu, przez co możemy czasem wylać dziecko z kąpielą.
To wszystko?
Moduł to jednak dużo, dużo więcej. Kompletny moduł, oprócz tworzenia zestawu funkcji potrafi również:
- zmieniać sposób wyświetlania obiektów
- dodawać do istniejących/ definiowanych typów właściwości i metody skryptowe
- tworzyć wielojęzyczną pomoc do naszego modułu
- odpowiednio opisać metadane modułu (autora, wersję) – do tego służy manifest
Pierwsze dwa punkty realizowane są przy pomocy plików XML o specjalnej strukturze. Wszystkie pliki tego typu muszą mieć rozszerzenie .ps1xml. Ich stosowanie to jednak całkiem osobny temat. Poza tym takie modyfikacje przydają się zwykle w bardziej zaawansowanych modułach.
Pomoc dla modułu też raczej nie ma większego sensu jeśli tworzymy moduł w miarę prosty. Prosty moduł to zestaw funkcji, a funkcje można łatwo opisać posługując się pomocą w komentarzach. Oczywiście taka pomoc nie będzie wielojęzyczna, ale w przypadku, gdy z modułu nie będzie korzystało wielu ludzi – język nie jest istotną kwestią.
Ostatni punkt, czyli manifest, można w zasadzie zastosować do każdego modułu. Pomaga on śledzić wersje modułu, co z czasem może okazać się przydatne (gdy np. pracujemy na kilku komputerach i zechcemy moduł uaktualnić), informację o autorze, opis modułu… A ponieważ jego tworzenie nie jest bardzo skomplikowane (służy do tego cmdlet New-ModuleManifest), nic nie stoi na przeszkodzie, by moduł (nawet najprostszy) w taki manifest wyposażyć.
Tworzymy moduł: krok 1
Pierwszy krok to zebranie wszystkich funkcji, które nasz moduł ma udostępniać i zapisanie ich w pliku z odpowiednim rozszerzeniem. Taki moduł zwykle można od razu zacząć używać (wystarczy go zaimportować: Import-Module). Jeśli jednak chcemy by nasz moduł zawierał również funkcje pomocnicze (które nie powinny być widoczne na zewnątrz) bądź dodawał do sesji zmienne i aliasy (domyślnie wszystkie aliasy i zmienne definiowane w module nie są eksportowane poza moduł), musimy pójść krok dalej. Podstawowa metoda to wyeksportowanie “ręcznie” funkcji, zmiennych i aliasów. Trzeba jednak pamiętać, że eksportując dowolny element w ten sposób wyłączamy domyślny mechanizm eksportujący wszystkie funkcje z modułu. Popatrzmy na konkretny przykład, trzy proste moduły, bardzo podobne do siebie:
function Get-Foo { Write-Host foo } function pomoc { Write-Host Pomagam } New-Alias -Name foo -Value Get-Foo $Foo = 'Bar'
Taki moduł udostępnia zarówno funkcję Get-Foo (która ma być widoczna) jak i funkcję pomoc – która w naszym przykładzie jest pomocnicza. Co jeśli dodamy Export-ModuleMember i zapomnimy o funkcjach…:
function Get-Foo { Write-Host foo } function pomoc { Write-Host Pomagam } New-Alias -Name foo -Value Get-Foo $Foo = 'Bar' Export-ModuleMember -Alias foo -Variable Foo
Alias ‘foo’ zadziała, ale skutkiem będzie błąd (funkcja Get-Foo nie będzie zdefiniowana, więc użyć się jej bezpośrednio nie da). Działać poprawnie będzie w zasadzie tylko zmienna $Foo. Prawidłowe użycie cmdletu Export-ModuleMember:
function Get-Foo { Write-Host foo } function pomoc { Write-Host Pomagam } New-Alias -Name foo -Value Get-Foo $Foo = 'Bar' Export-ModuleMember -Function Get-Foo -Alias foo -Variable Foo
Po zaimportowaniu tego modułu widoczna będzie tylko potrzebna nam funkcja (Get-Foo), alias, który do niej prowadzi (foo) oraz zmienna, którą chcemy zdefiniować ($Foo).
Tworzymy moduł: krok 2.
Zainicjowaliśmy więc moduł. Jak go testować? Import-Module działa jednorazowo, jeśli moduł w sesji już funkcjonuje – ponowny import nie da żadnego rezultatu. Na etapie tworzenia bardzo przydatny może się okazać parametr –Force – pozwala on zaimportować moduł wielokrotnie, dzięki czemu wprowadzone zmiany będą widoczne. Na etapie “produkcji” warto jest po każdej poważniejszej zmianie dokonać importu by przekonać się, czy nasz moduł nie przestał działać.
Warto też na tym etapie zastanowić się nad skutecznym mechanizmem, który polecenia i zmienne eksportowane z naszego modułu pozwoli wyróżnić. Prefiks ułatwi zarówno używanie modułu, jak i eksport poleceń/ zmiennych. Dlaczego? Otóż polecenie Export-ModuleMember obsługuje symbole wieloznaczne. Zamiast więc pojedynczo eksportować polecenia i zmienne – możemy na końcu modułu użyć:
Export-ModuleMember -Function *-Prefiks* -Variable Prefiks* -Alias *
Naturalnie, prefiks to raczej 2-3 literki. 
Gdzie zaś ułatwienie użytkowania? O ile prościej jest (posługując się TABem np.) dopełniać polecenie Get-Prefiks[TAB] zamiast przypominania sobie za każdym razem, jakich rzeczowników użyliśmy w naszych funkcjach? Get-Command –Module NaszModuł nieco sprawę upraszcza, ale nie wydaje mi się to najefektywniejszą metodą.
Co dalej?
W kolejnej części zamierzam opisać dokładniej manifest modułu i to, co on nam daje. Oprócz tego zamierzam napisać jak moduły przygotować do dystrybucji i jak “instalować” je, by zamiast składni: Import-Module .\Nazwa.psm1 móc skorzystać ze składni: Import-Module Nazwa. To w zasadzie drobiazg, ale myślę że warto o nim wspomnieć, na wypadek gdyby ktoś tego jednak nie wiedział…
$FormatEnumerationLimit – zmiana limitu wyświetlanych wartości dla parametru
| 2011-12-15 | Posted by pawp81 under Polskie blogi IT |
|
Powershell domyślnie wyświetla tylko 16 wartości parametru. Np jeśli analizujemy wiadomości za pomocą Message Tracking Log wśród odbiorców maila możemy domyślnie zobaczyć do 16 adresów. Podobnie po wykonaniu polecania Get-OwaVirtualDirectory -server ServerName | fl AllowedFileType powershell wyświetli tylko 16 pierwszych rozszerzeń plików.
Jeśli chcemy zobaczyć wszystkie wartości wystarczy, że wykonamy polecenie:
$FormatEnumerationLimit=-1
A następnie jeszcze raz:
Get-OwaVirtualDirectory -server ServerName | fl AllowedFileType
Kurs programowania w PowerShell cz.8
| 2011-12-13 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim artykułem, który jest kontynuacją kursu programowania w języku skryptowym PowerShell. Artykuł ma na celu zapoznanie czytelnika z podstawami poruszania się w powłoce oraz poleceniami wbudowanymi w PowerShell. Kurs PowerShell
Kurs programowania w PowerShell cz.7
| 2011-12-07 | Posted by gsgalezowski under Polskie blogi IT |
|
Zapraszam wszystkich do zapoznania się z moim artykułem, który jest kontynuacją kursu programowania w języku skryptowym PowerShell. Artykuł ma na celu zapoznanie czytelnika z podstawami poruszania się w powłoce oraz poleceniami wbudowanymi w PowerShell. Kurs PowerShell
PowerShell – efektywniej, część 7.
| 2011-11-29 | Posted by Bartek Bielawski under najlepsze praktyki, Polskie blogi IT, pomoc, zaawansowane funkcje |
|
Minął prawie miesiąc od ostatniego wpisu… dla mnie był to miesiąc wyjątkowo długi. Kończymy powoli wdrażanie Windows 7 w naszej firmie, a wiadomo jak to jest – końcówki zwykle są najgorsze, szczególnie gdy innych spraw również nie można odłożyć na później. Skutek jest taki jak widać – blog musiał nieco poczekać… Dziś zamknąć zamierzam kwestie związane z zaawansowanymi funkcjami/ skryptami. Nasza zaawansowana (choć niezbyt funkcjonalna) ma już niemal wszystko. Brakuje tylko jednego – pomocy. W przypadku cmdletów pomoc jest tworzona przy pomocy plików maml. Pisanie ich na piechotę nie należy do wdzięcznych czynności, można to sobie znacznie uprościć korzystając z narzędzia Cmdlet Help Editor. Pisząc zaawansowane funkcje mamy zadanie znacznie uproszczone. W zasadzie całość sprowadza się do umieszczenia odpowiednio sformatowanego komentarza w odpowiednim miejscu. Zasady przypominają nieco regulamin dotyczący spalonego w piłce nożnej: niby wszystko jest proste, ale jak się zacznie wyjaśniać komuś, robi się coraz mniej “prosto”. 
W zasadzie budowanie pomocy sprowadza się do dodania komentarza w formacie:
<#
.Nagłówek
Treść
.Dwuczłonowy Nagłówek
Treść
#>
Dokładny opis wszystkich elementów znajduje się w pomocy (about_comment_based_help), ja wspomnę o najistotniejszych (moim zdaniem):
- Synopsis – krótki opis naszej funkcji
- Description – opis obszerniejszy, bardziej szczegółowy
- Example – przykłady, każdy przykład umieszczamy w osobnej sekcji Example a sekcji takich możemy definiować ile chcemy (nawet jeśli istnieje jakiś limit, to trudno będzie do niego “dobić”
- Notes – dodatkowe informacje, które nie pojawią się w widoku domyślnym
- Parameter MojParametr – opis konkretnego parametru
Ale to dopiero początek, dalej zaczyna się cała litania innych warunków, po kolei więc:
- można użyć zarówno komentarzy blokowych (<# #>), “tradycyjnych” (# jako pierwszy znak w linii) oraz mieszanki obu
- komentarz do funkcji można umieścić “w ciele”, lub tuż nad słowem kluczowym “function”
- umieszczając pomoc nad funkcją, możemy zostawić maksymalnie jedną linię pustą pomiędzy końcem komentarza a początkiem funkcji.
- umieszczając pomoc w ciele funkcji, musimy pamiętać by umieścić go przed blokiem param () i [CmdletBinding()]
- w przypadku pomocy do skryptu – musimy umieścić komentarz na jego początku lub końcu
- jeśli chcemy dodać linie #requires na początku skryptu – musimy odseparować ją pustą linią od bloku zawierającego pomoc
- umieszczenie pomocy na końcu skryptu i podpis elektroniczny wzajemnie się wykluczają (niedopatrzenie ) – podpis jest komentarzem, więc automatycznie blok pomocy nie jest ostatni i przestaje być obsługiwany
- jeśli chcemy pomoc skryptu umieścić na jego początku musimy zadbać o to, by pomoc nie “przykleiła” nam się do pierwszej funkcji znajdującej się w skrypcie
- jakakolwiek literówka w nagłówkach pomocy (n.p.: .Synosis) automatycznie sprawi, że pomoc się nie pojawi w ogóle
- każdy nagłówek musi być w osobnej linii, sekcja musi zaczynać się w linii następnej i kończyć w linii poprzedzającej następny nagłówek
- komentarz musi stanowić jedną całość – jeśli będą przerwy między częściami, brana pod uwagę będzie tylko ta część, której położenie zgadza się z zasadami wymienionymi powyżej
- opis parametrów można umieszczać zarówno tuż nad nimi, jak i w treści “głównej” pomocy
Jak widać – miejsc na potencjalne pomyłki nie brakuje. Próbowałem sobie wyłapywanie błędów (szczególnie literówek) ułatwić jakiś czas temu (dokładnie w czasie Scripting Games 2010) – wtedy też napisałem prostą funkcję, która miała mi w wyłapywanie błędów pomóc. Bazuje ona na wyrażeniach regularnych i pewnie wymagałaby poprawek – pisałem ją w czasach gdy o tych ostatnich wiedziałem zdecydowanie mniej niż teraz. Ale na pewno może się ona przydać od czasu do czasu, by wyłapać najbardziej bagatelne błędy…
Tyle zasady. A jak najlepiej budować taką pomoc? Synopsis i Description to moim zdaniem absolutne minimum. Dobrze jest też umieścić choć kilka przykładów użycia naszej funkcji. Odnośnie parametrów – preferuję umieszczania pomocy do nich bezpośrednio na nimi, w bloku param. Dzięki temu, moim zdaniem, łatwo tę pomoc “wyłapać” w czasie modyfikowania skryptu/ funkcji. A i dodając nowy parametr możemy od razu wzbogacić go o odpowiednią pomoc. Wyjątkiem będą tu parametry dodawane w zaawansowanych funkcjach automatycznie, jak WhatIf, Confirm, Debug i Verbose.
Pozostałe elementy pomocy używam niezmiernie rzadko. Możliwości jest sporo, więc najlepiej korzystać z nich z głową, by nie przesadzić… Jak pomoc będzie zbyt przeładowana – nikomu nie będzie się chciało jej czytać.
Na koniec nasza funkcja, tym razem już odpowiednio uzbrojona w system pomocy:
function Get-Foo { <# .Synopsis Wyświetla literki i cyferki. .Description Funkcja wyświetla literki i cyferki, w zależnosci od potrzeb. Liczby są formatowane jako waluta (C4), procenty (P4) i zwykłe liczby (N4). W przypadku słów nie jest używane żadne specjalne formatowanie. .Example Get-Foo Slowo Slowo to moje slowo Wyświetla wybrany string. .Example Get-Foo -Liczba .24 -Format P4 Moja liczba: 24.0000 % Wyświetla liczbę sformatowaną w wybrany sposób. .Parameter WhatIf Dodawany automatycznie. Pomoc do niego możemy umieścić jedynie w taki sposób. .Parameter Confirm I tu podobnie... #> [CmdletBinding( SupportsShouldProcess = $true, ConfirmImpact = 'Medium', DefaultParameterSetName = 'Domyslny' )] param ( # Liczba, którą chcemy wyświetlić. [Parameter( Mandatory = $true, HelpMessage = 'Pomocy!', ValueFromPipeline = $true, Position = 0, ParameterSetName = 'Liczby' )] [double]$Liczba, # Pojedyncze słowo, które chcemy wyświetlić. [Parameter( Mandatory = $true, HelpMessage = 'Pomocy!', ValueFromPipelineByPropertyName = $true, Position = 0, ParameterSetName = 'Domyslny' )] [ValidatePattern('^\w+$')] [string]$Slowo, # Format, który zostanie użyty do wyświetlenia podanej liczby. [Parameter( Position = 1, ParameterSetName = 'Liczby', Mandatory = $true, HelpMessage = 'Pomozcie mi!' )] [ValidateSet('P4','N4','C4')] [string]$Format ) begin { Write-Verbose "Format: $Format" Write-Verbose "Liczba: $Liczba" Write-Verbose "Slowo: $Slowo" if ($Format) { Write-Debug "Wygląda na to, że używamy liczby." } } process { if ($psCmdlet.ShouldProcess( "Cel: $Slowo $Liczba", "Operacja: Wyświetl" )) { switch ($psCmdlet.ParameterSetName) { Domyslny { "{0} to moje slowo" -f $Slowo } Liczby { "Moja liczba: {0:$Format}" -f $Liczba } } } } }
W następnej części zamierzam zająć się modułami. Ponieważ temat ten jest dość obszerny, nie wykluczone że rozbiję go na kilka wpisów. Byleby tylko czasu i zapału na pisanie nie zabrakło…
Execution policy w Powershell x86 i x64
| 2011-11-10 | Posted by JeZZoo under ExecutionPolicy, Polskie blogi IT, Skrypty, x64, x86 |
|
Jedną z pierwszych czynności, które administrator zaprzyjaźniony już z PS wykonuje na swoim systemie to zmiana ExecutionPolicy na takie, które pozwolą wykonywać skrypty. Jakie zdziwienie było moje zdziwienie, kiedy zaraz po takiej zmianie przy próbie wykonania skryptu pojawił mi się … Czytaj dalej
PowerShell–efektywniej, część 6.
| 2011-11-06 | Posted by Bartek Bielawski under najlepsze praktyki, Początki, Polskie blogi IT, Skrypty, zaawansowane funkcje |
|
W poprzedniej części opisałem składnię, dzięki której funkcja zmienia się w funkcję zaawansowaną. Dziś skupię się na tym, co z tego wynika przy używaniu takiej funkcji.
Debug i Verbose
W wielu językach – zarówno programowania jak i skryptowych – pierwszą metodą sprawdzania co poszło nie tak jest wyświetlanie na ekran informacji, które mogą pomóc ustalić, gdzie popełniliśmy błąd. To generuje dwa problemy:
- nie usunięte komunikaty pojawiają się w najmniej odpowiednim momencie
- ponowne “włączenie” komunikatów po ich usunięciu jest niemożliwe
PowerShell ma bardzo przydatną właściwość: generuje nieco więcej strumieni niż domyślne wyjście standardowe i wyjście błędów: mamy dodatkowo ostrzeżenia, informacje rozszerzone (verbose) i komunikaty pomagające debugować (debug). Komunikaty verbose i debug można z powodzeniem pozostawić (jeśli są cenzuralne 
) a w razie potrzeby – włączyć na żądanie. W funkcjach zwykłych wymagałoby to zmiany $DebugPreference i $VerbosePreference na poziomie sesji. Funkcje zaawansowane dają nam możliwość użycia po prostu jednego z parametrów: –Debug lub –Verbose. Dzięki temu automagicznie zmienia się wartość odpowiedniej zmiennej i wszystkie komunikaty pojawiają się w odpowiednich strumieniach. Dodajmy więc komunikaty dotyczące zawartości naszych parametrów:
Write-Verbose "Format: $Format" Write-Verbose "Liczba: $Liczba" Write-Verbose "Slowo: $Slowo" if ($Format) { Write-Debug "Wygląda na to, że używamy liczby." }
Begin, Process, End
Funkcja w PowerShellu może mieć trzy odseparowane części, co ułatwia zdecydowanie pracę w potokach i dzięki czemu każda funkcja może działać podobnie jak prawdziwy cmdlet (jeśli chodzi o funkcjonalność, nie o wydajność). Mamy więc:
- begin gdzie można zainicjować połączenia, zdefiniować funkcje pomocnicze, przetworzyć zmienne podawane “w linii”
- process stanowiący serce funkcji działającej w rurce: tu możemy sięgnąć do parametrów pobieranych z poprzedniej komendy i przekazać informację dalej
- end który sprząta na koniec: zabija połączenia, czyści pamięć ze zbędnych elementów
Jeśli zamierzamy korzystać tylko z parametrów podawanych w linii – nasza funkcja może mieć jedno, zbiorcze “ciało”. Jeśli jednak chcemy skorzystać z pipe’a – absolutnym minimum jest dodanie części process, pozostałe dwie pozostają wówczas opcjonalne. Begin ma sens wtedy, gdy potrzebujemy pewną operację przeprowadzić dokładnie raz na początku, a wykonywanie jej dla każdego elementu wpadającego w rurkę jest stratą czasu, czy wręcz może doprowadzić do nieoczekiwanych rezultatów. End działa podobnie – tylko operacja musi mieć miejsce dokładnie raz na końcu. Cała reszta – powinna trafić do bloku process. Zaawansowane funkcje tracą wiele jeśli pozbawimy ich tej troistości.
PSCmdlet
Zaawansowane funkcja ma jeszcze jedną wielką zaletę: w jej wnętrzu dostępna jest automatyczna zmienna ($PSCmdlet), która w zasadzie daje nam dostęp do tych samych metod i właściwości, jakie ma programista piszący cmdlet w C# lub VB.NET. Na blogu zespołu PowerShell jakiś czas temu opublikowana była prosta funkcja, która pozwala zajrzeć do wnętrza tej zmiennej, sprowadza się to właściwie do:
function Test-PSCmdlet { [CmdletBinding()] param() $p = $PSCmdlet function prompt { "Test-PSCmdlet> " } $host.EnterNestedPrompt() }
Dzięki temu możemy poeksperymentować ze zmienną $p (która jest kopią $PSCdmlet). W praktyce na ogół wykorzystuje się dwa jej elementy:
- właściwość ParameterSetName – pozwala ustalić, który zestaw parametrów jest wykorzystywany
- metody ShouldProcess i ShouldContinue – pozwalają zastosować parametry WhatIf oraz Confirm.
Ponieważ budowana przez nas zaawansowana funkcja wspiera ShouldProcess (a więc metody Shoud* będą w niej dostępne), oraz założyliśmy kilka różnych zestawów parametrów, więc wykorzystamy i jedno, i drugie:
process { if ($psCmdlet.ShouldProcess( "Cel: $Slowo $Liczba", "Operacja: Wyświetl" )) { switch ($psCmdlet.ParameterSetName) { Domyslny { "{0} to moje slowo" -f $Slowo } Liczby { "Moja liczba: {0:$Format}" -f $Liczba } } } }
Ponieważ część parametrów zamierzamy opcjonalnie pobierać z rurki – możemy do nich sięgać dopiero w bloku process. Jeśli mamy dwa zestawy parametrów na ogół wystarczy zwykły if – jeśli zestawów jest więcej, opcjonalnym rozwiązaniem może okazać się switch. Jak widać operacja przeprowadzana nie jest specjalnie niebezpieczna, ale czasem jednak funkcja napisana przez nas może nieść z sobą pewne ryzyko – warto wtedy wiedzieć jak zaimplementować parametry –WhatIf i –Confirm.
I tym optymistycznym akcentem kończę temat zaawansowanych funkcji. Jeszcze tylko nasza zaawansowana funkcja w pełnej krasie:
function Get-Foo { [CmdletBinding( SupportsShouldProcess = $true, ConfirmImpact = 'High', DefaultParameterSetName = 'Domyslny' )] param ( [Parameter( Mandatory = $true, HelpMessage = 'Pomocy!', ValueFromPipeline = $true, Position = 0, ParameterSetName = 'Liczby' )] [double]$Liczba, [Parameter( Mandatory = $true, HelpMessage = 'Pomocy!', ValueFromPipelineByPropertyName = $true, Position = 0, ParameterSetName = 'Domyslny' )] [ValidatePattern('^\w+$')] [string]$Slowo, [Parameter( Position = 1, ParameterSetName = 'Liczby', Mandatory = $true, HelpMessage = 'Pomozcie mi!' )] [ValidateSet('P4','N4','C4')] [string]$Format ) begin { Write-Verbose "Format: $Format" Write-Verbose "Liczba: $Liczba" Write-Verbose "Slowo: $Slowo" if ($Format) { Write-Debug "Wygląda na to, że używamy liczby." } } process { if ($psCmdlet.ShouldProcess( "Cel: $Slowo $Liczba", "Operacja: Wyświetl" )) { switch ($psCmdlet.ParameterSetName) { Domyslny { "{0} to moje slowo" -f $Slowo } Liczby { "Moja liczba: {0:$Format}" -f $Liczba } } } } }
Następną część zamierzam poświęcić kolejnej funkcjonalności, przydatnej zarówno w funkcjach (również zaawansowanych) jak i w skryptach: pomocy generowanej w oparciu o komentarze.
GPO – jak szybko podpiąć polisę pod wiele site’ów?
| 2011-10-31 | Posted by Konrad Sagala under Polskie blogi IT |
|
Ostatnio musiałem szybko podlinkować nową polisę GPO dotyczącą specyficznych ustawień do dużej ilości lokalizacji AD. Jak to można zrobić szybko? Oczywiście odpowiedź najprostsza – Active Directory. W środowisku z aktualną wersją Windows nie jest to trudne. Można sięgnąć do grupy poleceń PowerShell dotyczących GPO – http://technet.microsoft.com/en-us/library/ee461027.aspx
W moim przypadku musiałem dla zdefiniowanej polisy przypiąć ją do wielu lokalizacji, chociaż dla różnych OU składnia wyglądałaby identycznie. Po pierwsze musiałem wyeksportować listę site’ów (jak na rysunku) z konsoli AD Sites and Services do pliku csv.
Następnie do utworzonej listy dodałem kolumnę z wartością Distinguished name (w Excelu dodanie kolumny i na podstawie nazwy site’u wygenerowanie kolumny z distingushed name).
Nagłówek pliku csv wyglądał tak jak poniżej (tylko kolumna DN została dodana przeze mnie, pozostałe są automatycznie eksportowane z konsoli):
Name;DN;Location;Type;Description
Następnie prościutka pętla w Powershellu i po kłopocie:
Import-Module grouppolicy
$allsites = Import-Csv -Path "C:\scripts\sitelist.csv" -Delimiter ";"
foreach ($site in $allsites)
{
New-GPLink -name AV -target $site.DN -LinkEnabled Yes
}
< $BlogFeedsVertical$>
< $BlogItemFeedLinks$>
GPO – jak szybko podpiąć polisę pod wiele site’ów?
| 2011-10-31 | Posted by Konrad Sagala under Polskie blogi IT |
|
Ostatnio musiałem szybko podlinkować nową polisę GPO dotyczącą specyficznych ustawień do dużej ilości lokalizacji AD. Jak to można zrobić szybko? Oczywiście odpowiedź najprostsza – Active Directory. W środowisku z aktualną wersją Windows nie jest to trudne. Można sięgnąć do grupy poleceń PowerShell dotyczących GPO – http://technet.microsoft.com/en-us/library/ee461027.aspx
W moim przypadku musiałem dla zdefiniowanej polisy przypiąć ją do wielu lokalizacji, chociaż dla różnych OU składnia wyglądałaby identycznie. Po pierwsze musiałem wyeksportować listę site’ów (jak na rysunku) z konsoli AD Sites and Services do pliku csv.
Następnie do utworzonej listy dodałem kolumnę z wartością Distinguished name (w Excelu dodanie kolumny i na podstawie nazwy site’u wygenerowanie kolumny z distingushed name).
Nagłówek pliku csv wyglądał tak jak poniżej (tylko kolumna DN została dodana przeze mnie, pozostałe są automatycznie eksportowane z konsoli):
Name;DN;Location;Type;Description
Następnie prościutka pętla w Powershellu i po kłopocie:
Import-Module grouppolicy
$allsites = Import-Csv -Path "C:\scripts\sitelist.csv" -Delimiter ";"
foreach ($site in $allsites)
{
New-GPLink -name AV -target $site.DN -LinkEnabled Yes
}
< $BlogFeedsVertical$>
< $BlogItemFeedLinks$>
Szybkie sprawdzenie powershellem rozmieszczenia maszyn na klastrze Hyper-V zarządzanym VMM
| 2011-10-31 | Posted by Łukasz Kałużny under Polskie blogi IT, Virtual Machine Manager |
|
Uruchamiamy powershell i dodajmy przystawkę VMM poleceniem:
Add-PSSnapin Microsoft.SystemCenter.VirtualMachineManager
Ustawiamy nazwy serwer VMM oraz klastra Hyper-V który nas interesuje:
$VMMServerName = "vmm.lab.local" $HVClusterName = "hvcluster.lab.local"
Poleceniem Get-VMHostCluster pobieramy informacje o interesującym nas klastrze:
$HVCluster = Get-VMHostCluster -Name $HVClusterName -VMMServer $VMMServerName
Poniższym kodem przechodzimy po kolei przez każdy node klastra i listujemy maszyny wirtualne znajdujące się na nim:
foreach($HVNode in $HVCluster.Nodes)
{
$HVNode.VMs | Select Name, VMHost
}
Skrypt w całej okazałości:
Add-PSSnapin Microsoft.SystemCenter.VirtualMachineManager
$VMMServerName = "vmm.lab.local"
$HVClusterName = "hvcluster.lab.local"
$HVCluster = Get-VMHostCluster -Name $HVClusterName -VMMServer $VMMServerName
foreach($HVNode in $HVCluster.Nodes)
{
$HVNode.VMs | Select Name, VMHost
}
Tak wygląda przykładowy wynik skryptu:
Name VMHost ---- ------ VM-HUB hv1.lab.local VM-TS-1-1 hv1.lab.local VM-TS-1-2 hv1.lab.local VM-TS-1-3 hv1.lab.local VM-TS-1-4 hv2.lab.local VM-TS-2-1 hv2.lab.local VM-TS-2-2 hv2.lab.local REMOTEAPP hv2.lab.local
W przypadku usunięcia “-Name $HVClusterName” ze skryptu będą wylistowane wszystkie maszyny z klastrów zarządzanych przez VMM.
PowerShell – efektywnie(j), część 5.
| 2011-10-25 | Posted by Bartek Bielawski under najlepsze praktyki, Polskie blogi IT, Skrypty, zaawansowane funkcje |
|
W wersji drugiej PowerShell został dość mocno rozbudowany o nowe możliwości: zdalne uruchamianie kodu, praca w tle, moduły… Sam język też zyskał bardzo wiele, przede wszystkim – zaawansowane funkcje. Czy może raczej: zaawansowane scriptblocki. Jest bowiem prawdą, że niezależnie od tego jak nasz blok skryptu jest zapisany: w postaci funkcji w pamięci, w postaci zmiennej typu [ScriptBlock] czy też w postaci pliku z rozszerzeniem ps1 – może on w każdej z tych postaci być zaawansowany. Tą część cyklu zamierzam poświęcić w całości temu, w czym objawia się to “zaawansowanie” i jak je wykorzystać.
Spytaj PowerShella.
Parafrazując mój ulubiony zespół punk-rockowy: “Spytaj PowerShella, on ci prawdę powie, spytaj PowerShella – on ci wskaże drogę”. W tym wypadku pytanie brzmieć powinno: get-help about_functions_advanced*, pytanie pomocnicze: get-help about_functions_CmdletBindingAttribute. Postaram się opisać najważniejsze cechy funkcji zaawansowanych w tym artykule w tym, oraz następnym artykule, ale na pewno coś mi umknie. PowerShell (przynajmniej z założenia) powinien dostarczyć nam komplet informacji. Zacznijmy więc od początku. Zbudujmy od zera zaawansowaną funkcję. Nie będzie ani troszkę funkcjonalna, ale za to bardzo, bardzo zaawansowana. 
CmdletBinding
Od tego wszystko się zaczyna. PowerShell jest domyślny, więc w wielu sytuacjach ten element może się okazać zbędny. Jednak warto od niego zaczynać każdą funkcję. Nic to nie kosztuje, a daje kilka korzyści. Należy jednak pamiętać, że konstrukcja ta wymaga posiadania bloku param (może on być pusty) i może być rozbudowana o kilka opcji:
- SupportsShouldProcess – jeśli chcemy by nasza funkcja rozumiała –WhatIf i –Confirm, dopuszczalne wartości: $true, $false
- ConfirmImpact – jeśli zależy nam na tym, by pytanie o zgodę pojawiało się częściej, lub zawsze, dopuszczalne wartości: High, Medium, Low
- DefaultParameterSetName – jeśli definiujemy kilka zestawów parametrów i chcemy mieć pewność, że jeden z nich będzie używany domyślnie, dopuszczalne wartości: nazwy wszystkich użytych zestawów parametrów
W 9/10 przypadków [CmdletBinding()] w zupełności wystarczy, dobrze jednak wiedzieć, że to nie wszystko co ma do zaoferowania ta konstrukcja. Nasza funkcja oczywiście zalicza się do tych 10%, wszystko-w-sobie-mających:
function Get-Foo { [CmdletBinding( SupportsShouldProcess = $true, ConfirmImpact = 'High', DefaultParameterSetName = 'Domyslny' )] param (
Parameter
Wchodzimy do bloku definiowania parametrów i zaczynamy je zdobić. [Parameter()] to podstawa: pozwala nam zdefiniować parametry niezbędne (Mandatory), uzupełnić parametry o pomoc (HelpMessage), zdecydować czy będą “konsumować” rurkę i jak będą to robić (ValueFromPipeline, ValueFromPipelineByPropertyName), jaką pozycję mogą zajmować (Position), który zestaw parametrów opisujemy (ParameterSetName) i wreszcie – że parametr połknie całą resztą argumentów, do których nikt inny się nie przyznaje (ValueFromRemainingArguments). Należy pamiętać, że jeśli mamy kilka zestawów parametrów a opisywany parametr ma pojawiać się tylko w niektórych – to trzeba to wyraźnie zdefiniować (kilka bloków [Parameter()]). Jeśli parametr pojawia się wszędzie i wszędzie ma zachowywać się identycznie – wystarczy jedna deklaracja. My zdefiniujemy sobie dwa zestawy parametrów: liczba wraz z odpowiednim formatowaniem, lub po prostu słowo:
param ( [Parameter( Mandatory = $true, HelpMessage = 'Pomocy!', ValueFromPipeline = $true, Position = 0, ParameterSetName = 'Liczby' )] [double]$Liczba, [Parameter( Mandatory = $true, HelpMessage = 'Pomocy!', ValueFromPipelineByPropertyName = $true, Position = 0, ParameterSetName = 'Domyslny' )] [ValidatePattern('^\w+$')] [string]$Slowo, [Parameter( Position = 1, ParameterSetName = 'Liczby', Mandatory = $true, HelpMessage = 'Pomozcie mi!' )] [ValidateSet('P4','N4','C4')] [string]$Format )
Jak widać – można mieć dwa parametry o tej samej pozycji. O tym, który zostanie wykorzystany, decyduje zestaw parametrów: domyślnie nawet liczba zostanie potraktowana jako string. Jeśli jednak dodamy –Format (występujący tylko w zestawie z liczbami) PowerShell spróbuje pozycyjny parametr przerobić na [double]:
Jest wyjątek od tej reguły: jeśli typ będzie idealnie pasował do oczekiwanego (1.123123) to PowerShell wybierze ten zestaw, który pobiera zmienną danego typu.
Walidacja na wejściu
Kolejny efekt pisania funkcji jako zaawansowanej to możliwość walidacji tego, co użytkownik próbuje do funkcji wrzucić. Zgodnie z regułą GIGO (nie wiem czy polska wersja, choć bardziej dosadna, nie oddaje bardziej powagi sytuacji) – walidacja wejścia ma sens i należy jej używać zawsze wtedy, gdy zła informacja na wejściu może spowodować nieoczekiwane (na ogół bolesne) rezultaty. Sposobów walidacji mamy kilka:
- zestaw do wyboru: ValidateSet
- odpowiednia ilość elementów: ValidateCount
- odpowiednia matryca z wyrażeń regularnych: ValidatePattern
- odpowiednia długość: ValidateLength
- odpowiedni zakres wartośći: ValidateRange
- nie jest ‘zerowy’: ValidateNotNull
- nie jest ‘zerowy’ ani pusty: ValidateNotNullOrEmpty
- i najbardziej elastyczny: ValidateScript
Wszystkie te elementy ograniczają nasz element, jednak jeśli nasz argument jest wymagany (Mandatory) czasem konieczne może się okazać przymknięcie oka na pewne niedoskonałości (zwłaszcza jeśli element wpada nam z “rurki”):
- zezwól na wartości zerowe: AllowNull
- zezwól na pusty string: AllowEmptyString
- zezwól na puste kolekcje: AllowEmptyCollection
Jak widać jest w czym wybierać. Mój ulubiony to ValidateScript, który akceptuje parametr jeśli wynik skryptu będzie $true, odrzuci – jeśli wynik będzie $false, albo wyskoczy nam jakiś wyjątek. Dzięki temu i komendzie ‘throw’ możemy uczynić komunikat o błędzie bardziej zrozumiałym (zwłaszcza jeśli lokalizacja do języka narodowego nadal nie istnieje ).
Aliasy dla parametrów.
Aliasy mają dwa główne cele:
- umożliwienie wykorzystania w naszej funkcji różnych właściwości obiektów (ComputerName, Name, Nazwa)
- ułatwienie pracy z komendą “interaktywnie” (CN, NK)
Wydaje mi się, że druga ewentualność jest dość jasna. Co do pierwszej: jeśli zdarzy się, że jakaś komenda wyrzuca z siebie obiekty o właściwości Foo, która nam odpowiada a inna wyrzuca obiekty o właściwości Bar, która niczym się nie różni od Foo, to mamy idealnego kandydata na alias. Nazywając parametr Foo i nadając mu alias Bar zyskamy możliwość pobierania obiektów z obu komend. Wielokrotnie stosowałem tę metodę by móc “połykać” obiekty dotyczące komputerów i przypisywać wartość właściwości Name parametrowi ComputerName. Bez aliasów byłoby to trudne, lub wręcz niemożliwe…
I w ten oto sposób zamknęliśmy blok param () – przed nami wszystko to, co kryje się w automatycznie tworzonej w zaawansowanych funkcjach zmiennej $psCmdlet oraz kilka słów o Write-* w funkcji zaawansowanej. Zamierzam też wspomnieć, po co i gdzie używać konstrukcji begin, process i end. I choć wielka trójca była już dostępna w PowerShellu w wersji 1, to nie sposób pominąć tego tematu przy omawianiu zaawansowanych funkcji.
PowerShell – efektywnie(j), część 4.
| 2011-10-23 | Posted by Bartek Bielawski under najlepsze praktyki, Początki, Polskie blogi IT, Skrypty, zaawansowane funkcje |
|
Troszkę to trwało nim udało mi się przysiąść do tego artykułu. Przyczyna jest prozaiczna: temat jest dość obszerny i nie wiem jak go ugryźć. Pisanie skryptów w PowerShellu nie wymaga wielkiego wysiłku, ale jeśli chcemy by nasz skrypt był przydatny dla innych i dla nas za pół roku – trzeba się nieco przyłożyć w czasie jego tworzenia. Uznałem jednak, że rzecz sama się nie zrobi. W najgorszym wypadku po prostu rozpiszę się nieco bardziej niż zwykle (ha, ha, ha… 
)
Od czego zacząć?
W zasadzie pierwsze pytanie jakie powinniśmy sobie zadać powinno brzmieć: czy chcemy napisać coś, co wykona serię operacji i da nam na koniec jakiś wynik (skrypt) czy bardziej interesuje nas biblioteka narzędzi (moduł). Dalej jest już prościej: dzielimy zadanie na proste czynności (funkcje), które następnie połączymy w całość. I o ile w przypadku modułów sprawa wydaje się “czysta” i dość naturalna, o tyle w wypadku skryptów musimy zwalczyć pokusę umieszczenia operacji w jednym, wielki worze.
Kod wielokrotnego użycia
Skrypty lubią rosnąć niby hydra: dodajemy do nich kolejne funkcjonalności, jednocześnie nie specjalnie dbając o to, by kod można było później wykorzystać. To moim zdaniem spory błąd: utrudnia ponowne wykorzystanie napisanego kodu w innym narzędziu, czyni narzędzie dość statycznym i dość silnie uwiązanym do wykorzystanej technologii. Może prosty przykład, by pokazać o co mi chodzi…
Naturalna kolej rzeczy: nasz skrypt może przyjąć jako parametr samą listę (przekazaną przez rurkę), OU w AD, plik txt/ csv z listą komputerów itd. Na wyjściu – podamy ścieżkę do pliku .csv w którym dane zostaną zapisane. To co się dzieje w środku zależy już od nas. Możemy więc albo zrobić to w formie funkcji, które następnie ustawimy w jednej “rurce” i uzyskamy pożądanych efekt. Albo wszystko zrobić za jednym zamachem, bez dziabania kodu na poszczególne fragmenty. Co tracimy?
- przejrzystość kodu (logika się “zlewa”)
- utrudnienia przy wymianie komponentu
- rozwiązując podobny problem musimy praktycznie kopiować cały skrypt, albo zacząć pisanie od początku
Problem, jaki może się pojawić, to konieczność zdefiniowania funkcji zanim ich użyjemy. Jak to w prosty sposób rozwiązać? Mój ulubiony trik to definiowanie na początku funkcji, która ma za zadanie tylko opisać zakładaną logikę – czy inaczej – szkic tego co chciałbym osiągnąć. Na ogół wygląda to tak:
#requires -version 2.0 <# Pomoc do skryptu #> function Invoke-Main { param ( $Parametr = $Script:Parametr, $DrugiParametr = $Script:DrugiParametr, $Path = $Script:Path ) Get-Foo -Parametr $Parametr | Test-Foo | ConvertTo-Bar -Drugi $DrugiParametr | Export-Csv -Path $Path } <# Tu definiujemy: * Get-Foo * Test-Foo * ConvertTo-Bar #> Invoke-Main
Jak widać – definicje funkcji następują przed jej wywołaniem (które ma miejsce na samym końcu skryptu) ale sposób ich wywołania znany jest od początku (zdefiniowany w pierwszej funkcji w skrypcie). Jeśli zechcę kiedyś zmienić finalny obiekt na ‘Boo’ zamiast funkcji ConvertTo-Bar zdefiniuję ConvertTo-Boo, zmienię nieco Invoke-Main i już – skrypt gotowy do użycia.
Funkcja w rurce – awansujemy.
Patrząc na składnię moich hipotetycznych funkcji od razu widać jedną rzecz: wszystkie “klocki” radzą sobie w rurce. To podstawa: pisząc funkcję niezdolną do pracy w środku pipe’a strzelamy sobie w stopę. By jednak współpraca przebiegała bezboleśnie – należy z całą pewnością przyzwyczaić się do pisania zaawansowanych funkcji. Wymagają one nieco dekoracji na wstępie, ale wartość dodaną trudno moim zdaniem przecenić. Druga rzecz, która być może w skryptach nie jest tak cenna, ale w modułach moim zdaniem absolutnie niezbędna: pomoc do funkcji. Wymaga to maciupeńkich nakładów pracy (odpowiednio skomponowany komentarz) a oszczędza konieczności czytania definicji funkcji za każdym razem. Myślę, że sam temat zaawansowanych funkcji jest zbyt obszerny, by go streścić tutaj, zostawię więc to na piątą część cyklu. Na rozbudzenie apetytu: malutka funkcja, która wykorzystuje część możliwości, które dają zaawansowane funkcje:
function Test-IsAlive { [CmdletBinding()] param ( [Parameter( ValueFromPipelineByPropertyName = $true, Mandatory = $true, HelpMessage = 'Nazwa komputera, ktory testujemy' )] [ValidatePattern('(?# Bez spacji w nazwach komputerow!)^\S+$')] [Alias('Name','CN','Nazwa')] [string]$ComputerName, [Parameter(ValueFromPipeline = $true)] [Alias('IO')] [PSObject]$InputObject ) process { Write-Verbose "Testuje komputer: $ComputerName" if (Test-Connection -ComputerName $ComputerName -Quiet -Count 1) { if (!$InputObject) { Write-Verbose 'Nic na wejsciu, tworzymy sami.' $InputObject = New-Object PSObject -Property @{ ComputerName = $ComputerName } } $InputObject | Add-Member NoteProperty IsAlive $true -PassThru } } }
Skutek? Mogę przez tą funkcję przepuścić dowolny obiekt, który posiada właściwość ComputerName, Name, Nazwa lub CN i jeśli właściwość ta nie zawiera spacji (ValidatePattern, z komentarzem, by nie straszyć ludzi niezrozumiałym regexpem) i da się ją “pingnąć” (preferowane więc będą obiekty pobrane z AD, lub innego zawierającego nazwę komputera) to na wyjściu dostanę ten sam obiekt “wzbogacony” o właściwość IsAlive. Jeśli spróbuję uruchomić funkcję bez parametru – poprosi mnie ona o wartość ComputerName. I rzecz nie bez znaczenia: dodanie wtrąceń typu Write-Verbose/ Debug działa bez potrzeby implementacji. [CmdletBinding()] daje mi te opcje za darmo. Mogę więc uruchomić funkcję z parametrem –Debug lub –Verbose i dowiedzieć się więcej o tym, co dzieje się w środku.
Wejście – wyjście.
Skrypty mają to do siebie, że czasem wolelibyśmy nie musieć pamiętać co do nich trzeba włożyć, oraz co byśmy chcieli z nich wyjąć. Z drugiej strony – czasem jednak chcemy mieć wpływ na to, co się stanie… PowerShell pozwala pogodzić te dwie sprzeczności. Rozwiązanie to wyciągnąć jak najwięcej elementów na zewnątrz skryptu (w postaci parametrów) i jednocześnie przypisać im wartość domyślną (by nie być zmuszonym podawać ich za każdym razem). Z wyjściem jest gorzej – optymalne rozwiązanie to parametr typu [switch], który na wyjściu da nam “żywe” obiekty. To co z nimi zrobimy dalej będzie zależeć już tylko od nas. I wilk syty, i owca cała.
SharePoint 2010 i PowerShell
| 2011-10-16 | Posted by Joanna Subik under Polskie blogi IT |
|
Na stronach TechNet SharePoint pojawiło się kapitalne narzędzie dla osób, które chcąc nie chcąc muszą pracować z powłoką PowerShellową produktów SharePoint oraz Office 365. Jest to Windows PowerShell Command Builder (niestety tylko dla SharePoint 2010 oraz Office 365). Aplikacja w sposób niemalże łopatologiczny pozwala na konstruowanie składni poleceń poprzez wybieranie jego odpowiednich składowych części. Wyboru dokonujemy poprzez wskazanie odpowiedniej czynności (czasownika), powiązanego z nią obiektu (rzeczownika) oraz wpisanie w oknie dialogowym określonych parametrów charakterystycznych dla danego polecenia. Całość komendy zostaje umieszczona na “Design surface”, skąd można ją skopiować do schowka i uruchomić w zarządzanych przez administratora środowisku. Ze szczegółami można zapoznać się w dokumentach dostępnych do pobrania na Microsoft Download Center.
Zdecydowanie polecam zapoznać się z opisywanym narzędziem!
Pomoc w funkcjach i skryptach PowerShell
| 2011-10-09 | Posted by JeZZoo under Get-Help, inline help, Polskie blogi IT, script library, Skrypty |
|
Tworzenie funkcji czy skryptów, szczególnie tych bardziej złożonych wymaga stworzenia dokumentacji, tak, aby późniejsze uruchomienie nie sprawiało problemów lub nie wymagało szukania w kodzie sposobu wywołania, np. parametrów wejściowych. Przydatne jest to szczególnie, jeśli tworzymy skrypty lub biblioteki funkcji, z … Czytaj dalej
PowerShell – efektywnie(j), część 3.
| 2011-10-08 | Posted by Bartek Bielawski under konsola, najlepsze praktyki, Polskie blogi IT |
|
W trzeciej części jeszcze troszkę popastwię się nad konsolową pracą z PowerShellem. Opiszę kilka trików, które mogą nam pomóc oszczędzić nieco czasu i w miarę szybko dojść do pożądanych rezultatów.
Komentarze
Wydawać się może, że w interaktywnej pracy komentarze są zbędne. I faktycznie, raczej nie ma sensu korzystać z nich w celach dla których zostały stworzone. Czasem jednak zdarzy się, że zaczniemy pisać jakąś komendę (np. przenosimy komputer w AD do odpowiedniego kontenera). Mamy już niemal gotową rurkę, gdy zdajemy sobie sprawę, że nie pamiętamy całej ścieżki. Do wyboru mamy:
- [Esc], sprawdzamy, piszemy od początku
- [Home], wstawiamy #, [Enter], sprawdzamy, strzała w górę, usuwamy #, kończymy.
I choć drugie zdanie jest dłuższe – to jednak zwykle to jednak pierwsza opcja jest bardziej czasochłonna. Zwłaszcza, że w międzyczasie może zadzwonić telefon, szef wpadnie z niezapowiedzianą wizytą, pamięć nam się zresetuje… a Get-History zwykle nie zapomina. A przynajmniej nie od razu.
Drugi sposób twórczego wykorzystania komentarzy: w PowerShellu komentarz blokowy może znaleźć się dosłownie wszędzie, przetestujcie sami:
ls <# czyli dir #> -r <# czyli -Recurse #> -fi <# znaczy filtr #> *.ps1 -EA 0
Oczywiście, to samo mogłoby się znaleźć w jednej linii i nadal by działało. Jakie to może mieć praktyczne zastosowanie? Powiedzmy, że napisaliśmy jakiś zagmatwany filtr do Where-Object, który nie daje żadnych rezultatów… Wystarczy czasem “wyłączyć” na moment jego fragment (odpowiednio zamykając go w <# #>) i sprawdzić, która część nie daje oczekiwanego efektu. W ostateczności można wyłączyć Where-Object a całość przepuścić przez Get-Member by upewnić się, czy nie pozajączkowała nam się nazwa właściwości.
Historia
Wspominałem już o jednym z trików związanych z historią. Jest ich więcej, ale sama historia domyślnie jest dość krótka: $MaximumHistoryCount, która za długość historii odpowiada, domyślnie ma wartość 64. Zwykle zwiększam ją do wartości maksymalnej.
Gdy już mamy jakąś historię istnieje kilka opcji, by z niej skorzystać. Przede wszystkim możemy użyć kombinacji # z tabulatorem. #Numer przywoła komendę o danym ID. #Ciąg Znaków przywoła wszystkie komendy, które pasują do wzorca (ciąg znaków nie musi znajdować się na początku).
Można też uruchomić polecenie bezpośrednio z historii. Invoke-History pobiera polecenie o podany –Id i wykonuje je ponownie. By jednak efektywnie z niego korzystać dobrze jest wiedzieć jakie id miało każde z wykonanych wcześniej poleceń. Bardzo w tym pomaga odpowiednio przygotowany prompt (mój typ to dzieło Jaykula, o którym wspominałem w cyklu o profilach).
ScriptBlock jako argument
Gdy to pierwszy raz zobaczyłem, najzwyczajnie w świecie powaliło mnie z nóg. Otóż jeśli jakieś polecenie potrafi pobierać informacje z rurki, to możemy “nakarmić” je scriptblokiem. Oczywiście – jeśli scriptblock to nasze możliwości właśnie stały się niemal nieograniczone. Zwykle jednak nie jest nam potrzebny 20-linijkowy skrypt, starcza lekki retusz obiektu wpadającego z innego polecenia. Jest jeden warunek: musi być to pobieranie z rurki imienne, nie na podstawie typu (oczywiście nie wadzi jeśli możliwe są oba rozwiązania). Prosty przykład:
ls *.ps1 | Rename-Item -NewName { $_.BaseName + '.psm1' } -WhatIf
I nagle wszystkie skrypty w bieżącym katalogu zmieniły(by) się w moduły. Inne zastosowania to już kwestia naszej kreatywności. Akurat ten przykład (ze zmianą nazw plików) jest moim ulubionym.
Podsumowanie
Praca w konsoli jest tym przyjemniejsza, im swobodniej się w niej poruszamy. Myślę, że warto poświęcić nieco czasu na jej wybór, dostosowanie, zapoznać się z jej możliwościami (i ograniczeniami). Później odpowiednio ją dopasować “pod siebie” przy pomocy profilu i/ lub modułów.
W kolejnych kilku częściach tego cyklu zajmę się funkcjami, skryptami, modułami… Pewnie rozwlecze się to na kilka łaaadnych artykułów, bo to temat-rzeka. Do konsoli wrócę jeszcze na koniec, gdy opiszę wędrówkę z konsoli do skryptu i z powrotem.
PowerShell – efektywnie(j), część 2.
| 2011-10-04 | Posted by Bartek Bielawski under konsola, najlepsze praktyki, Początki, Polskie blogi IT |
|
W części pierwszej tego cyklu opisałem ogólnie to, jak moim zdaniem praca w PowerShellu różni się w zależności od naszej aktualnej aktywności. Skupiłem się na różnicach między trybem pracy interaktywnej i trybem tworzenia skryptów. Dziś, zgodnie z obietnicą, poznęcam się nieco nad pracą w konsoli.
Badacz
PowerShell daje nam możliwości, których próżno szukać w VBS. Trudno je też znaleźć w cmd, choć temu ostatniemu nieco bliżej do interaktywnej natury PowerShella. W VBS byliśmy skazani na pisanie od zera, sklejanie skryptów z klocków, żmudne testy bez prostej możliwości wglądu w działanie skryptu. PowerShell pozwala każdy obiekt zbadać, obejrzeć, obrócić, przeskanować, rozłożyć na czynniki pierwsze. Nie korzystając z tych możliwości ograniczamy sobie pole działania. Wielu rzeczy o PowerShellu dowiadywałem się po prostu klepiąc TABem na różnych obiektach. Get-Member też zwykle służy pomocą. To wszystko sprawia, że PowerShell jest wręcz stworzony do zgłębiania świata .NET. Swoją drogą to dumam, czy programistom zdarza się uruchamiać PowerShella tylko po to, by sobie szybciutko pogmerać w jakimś skompilowany kodzie…
Oprócz tego możemy pracując obserwować cały czas rezultaty i nasze zachowanie dostosowywać do wyników. Jeśli jakaś metoda wyrzuca błąd – możemy sprawdzić jej definicję, zmodyfikować, uruchomić ponownie… aż do skutku.
Z pewną taką nieśmiałością…
Pisałem już o tym chyba kiedyś, ale ta cecha PowerShella niezmiennie mnie zachwyca. Pięknie o tym mówi w czasie swoich prezentacji o PowerShellu Jeffrey Snover. Spróbuję przetłumaczyć Odwieczny dylemat administratora:
Czy ta komenda jest poprawna? Czy jeśli ją wykonam, to stracę pracę? Czy przez moją pomyłkę Buffy i Puffy nie pójdą na studia? Może lepiej sprawdzą Co Jeśli…
-WhatIf i –Confirm – dwa parametry, które pewnie nie raz uratują adminowi jego cztery litery, lub przynajmniej pozwolą uniknąć 16-godzinnej dniówki. Korzystać z nich można, należy. Co więcej – korzystanie z –Confirm można w prosty (stosunkowo) sposób wymusić: wystarczy ustawić $ConfirmPreference na odpowiednio niską wartość. Domyślnie jest High (czyli tylko komendy z ConfirmImpact równym High będą wymuszać potwierdzenie). Ustawienie tego parametru na ‘Low’ może sprawić, że PowerShell będzie nas pytał o niemal wszystko. WhatIf też można wymusić ($WhatIfPrerence = 1) ale to chyba już przesada… Zamiast coś robić, będziemy tylko dostawać informację co by było gdyby… Za to raczej nam nikt nie zapłaci. A odwrócić to można tylko używając składni:
Komenda –WhatIf:$false
Niezbyt przyjazne, jeśli mam być szczery…
Klocki lego
Pisanie pełnej, “wypasionej” komendy od zera to troszkę jak malowanie obrazu bez szkiców… PowerShell to idealny szkicownik: możemy wykonać jakąś “rurkę”, sprawdzić czy rezultat nas zadowala, dodać kolejną komendę do potoku, sprawdzić. Zapisać w zmiennej, sprawdzić zawartość, przepuścić ją przez foreach ()… I tak, krok po kroku, dojść od koncepcji do pełnego rozwiązania. Czasem oczywiście nie jest to konieczne: łatwiej nam będzie zmodyfikować coś, co już kiedyś w pocie czoła stworzyliśmy. Ale na początku lepiej właśnie posłużyć się techniką “małych kroczków”. PowerShell, przez swoją interaktywność oraz fakt, że składnia w skrypcie niczym się nie różni od tej pisanej w konsoli, daje nam taką możliwość. Warto z niej skorzystać by nie napracować się nad jakimś skryptem tylko po to, by na koniec odkryć, że obiekt który zapowiadał się obiecująco kompletnie nie nadaje się do rozwiązania postawionego przed nami problemu. Budując rozwiązanie stopniowo unikniemy takich frustrujących i zniechęcających przygód.
Krótkie podsumowanie
Na dziś kończę. W następnej części skupię się na “trikach”, które często w konsoli wykorzystuję. Większość z nich opisałem w moim gościnnym artykule na blogu Hey, Scripting Guy! Część jednak dość lakonicznie, tu postaram się nieco bardziej rozpisać…
PowerShell MVP!
| 2011-10-01 | Posted by Bartek Bielawski under Polskie blogi IT |
|
Dziś w mojej skrzynce mailowej znalazłem maila od support@mvpaward.com. O tym, że będę nominowany dowiedziałem się już w czasie TechEd. Kiedy Aleksandar o tym wspomniał, sądziłem, że po prostu stara się być miły… Potem przyszła prośba o wypełnienie kwestionariusza z informacjami o mojej aktywności w ostatnim roku. I czekanie…
Wiedziałem, że decyzja zostanie ogłoszona dziś. Mail nie był więc dla mnie zakoczeniem. Jego treść – zdecydowanie tak.
Nadal nie mogę w to uwierzyć, ale to nie żart. Bartek Bielawski, PowerShell MVP. Szok. I dodatkowa motywacja, by wiedzą na temat tej technologii dzielić się z innymi. Dziękuję wszystkim, którzy się do tego przyczynili. Tym bardziej nie mogę doczekać się PowerShell Deep Dive, na który pojadę jako “najmłodszy w rodzinie”. Jak wrócę na ziemię obięcuję kontynuować cykl o efektynym PowerShellu. Dziś już się raczej nie uda…
PowerShell – efektywnie(j), część 1.
| 2011-09-24 | Posted by Bartek Bielawski under najlepsze praktyki, Początki, Polskie blogi IT |
|
Wszystkie narzędzia używane przez człowieka mają swoje ograniczenia. Wkręt można wbić młotkiem, ale śrubokręt zwykle daje lepszy rezultat. Tak samo naturalnie jest z PowerShellem: można walić nim jak młotem, można subtelnie trafiać idealnie w problem. W tej serii postaram się opisać to, co moim zdaniem może pracę w PowerShellu usprawnić, uprościć i dostosować do poziomu, na którym obecnie pracujemy.
Wyróżniłbym dwa skrajne poziomy, wraz z pewnym obszarem pośrednim:
Innymi zasadami kierowałbym się w każdym z tych obszarów. Dlaczego? Bo życie należy sobie ułatwiać. Na początek postaram się w skrócie przedstawić różnice pomiędzy oboma trybami (tryb pośredni pozostawię sobie na deser) a następnie zagłębie się w to, co moim zdaniem może uczynić pracę na obu poziomach bardziej efektywną, czasem również efektówną.
Aliasy
Pracując interaktywnie korzystamy z aliasów: po to zostały stworzone. W skrypcie – każdy alias to potencjalne źródło problemów, błędów i dodatkowo – element pogarszający czytelność skryptu. Przykład z życia wzięty: doskonały moduł ShowUI w jednym z przykładowych skryptów korzysta z aliasu “ps”. Długo musiałem dochodzić do tego, czemu ten konkretny przykład u mnie nie działał. Przyczyna? Usuwam w profilu w/w alias, mam dysk PS:, do niego odpowiednią funkcję, która działa podobnie do a:, c:, d: – alias mi uniemożliwiał szybkie dopełnianie nazwy tabem, więc go usunąłem. Skrypt, mimo że napisany poprawnie, stracił swą funkcjonalność.
Pisałem o czytelności… Dla początkującego użytkownika PowerShella taki kod będzie mało czytelny…:
h|?{$_.Id-gt5}|%{ $_.CommandLine-replace'^.(\w+)','$1'}
Przykładów dowodzących zasadności używania aliasów w shellu jest pewnie jeszcze więcej. Wystarczy porównać:
# Z aliasami... ls -r -fo -ea 0 -fi *.ps1 # I bez.
Aliasy są też bardzo przydatne, jeśli używacie czasem narzędzi nie przesiadujących w Waszej ścieżce: można albo dodać kolejny folder do $env:PATH, albo stworzyć alias, który będzie uruchamiał potrzebne narzędzie.
Profile
Pracując interaktywnie bez profilu tracimy czas – wiele funkcji i narzędzi definiujemy za każdym razem, zamiast zapisać je raz i później po prostu używać. Profil może za nas załadować wtyczki i moduły, może dodać wykorzystywane przez nas często zmienne, stworzyć dyski – możliwości jest bardzo wiele.
Skrypty dla odmiany powinny być kompletnie niezależne od profilu. Skrypt, jeśli jest napisany z głową, powinien sprawdzić czy wszystkie niezbędne do jego działania elementy są już w środowisku. Do testów najlepiej użyć możliwości, jakie daje powershell.exe – ma on parametr –noprofile, który świetnie nadaje się do uruchamiania “środowiska testowego” dla skryptów.
Host i UAC
Pracując interaktywnie korzystajmy raczej z hosta, który daje nam największy komfort. Dobrze poświęcić nieco czasu, “sprawdzić” dostępne opcje – w tym również opcje komercyjne (na ogół dostępne są wersje trial). Nie ma rozwiązania idealnego dla wszystkich, dlatego najlepiej “posmakować” dostępnych opcji i wybrać taką, w której będziemy się czuć najlepiej. Dodatkowo warto rozważyć ustawienie wybranego hosta tak, by uruchamiał się z “odpowiednimi” uprawnieniami. Osobiście uważam UAC za świetny wynalazek, nawet na serwerach go nie wyłączam. Ale póki PowerShell nie ma możliwości w prosty sposób “przeskoczyć” na wyższy poziom w trakcie pracy – wolę go od razu na tym wyższym poziomie uruchamiać.
Skrypty dla odmiany powinny “umieć się zachować”. Naturalnie, są takie, których użycie w innym hoście niż ten, w którym go tworzono, po prostu nie ma sensu. Ale jeśli skrypt nie jest z hostem bezpośrednio “powiązany” – dajmy użytkownikowi wybór. To oznacza, że powinniśmy przetestować nasz skrypt w kilku hostach, absolutne moim zdaniem minimum to PowerShell.exe i PowerShell ISE. Jeśli zaś chodzi o UAC – skrypt powinien wiedzieć, co będzie mu potrzebne. Powinien uprawnienia sprawdzić. I jeśli mu czegoś brakuje – uprzedzić użytkownika zanim spróbuje coś zmodyfikować.
Formalizm
Pracując interaktywnie tworzymy czasem krótkie funkcje, bloki skryptu, tymczasowe narzędzia. Ponieważ stworzyliśmy je przed chwilką – nie ma sensu ich dokumentować. Get-Help raczej na nich nie użyjemy. Nie ma też raczej powodu nadmiernie rozbudowywać blok przyjmujący parametry – wszelkie walidacje nie mają większego sensu, wiemy jak wygląda nasza funkcja, więc znamy jej ograniczenia, wiemy z jakimi założeniami została stworzona.
Skrypt dla odmiany powinien być dobrze udokumentowany. Korzystajmy z tego wszystkiego, co daje nam środowisko: pomoc w komentarzach, walidacja parametrów, zmienne z usztywnionymi typami, informacje typu warning, debug, verbose – to wszystko ułatwi nam modyfikowanie skryptu w przyszłości i używanie go bez konieczności otwierania go w edytorze za każdym razem. Koszt takiej operacji w wypadku skryptów używanych od czasu do czasu szybko się zwróci. A ewentualna rozbudowa o dodatkowe funkcje nie przyprawi nas o ból głowy.
Co dalej?
Ten wpis zaczyna pewien cykl. Dalej zagłębię się nieco bardziej w obu skrajnościach, na koniec zaś postaram się napisać, jak w prosty sposób można “przeskoczyć” z poziomu interaktywnego do skryptowego. Druga część będzie w całości poświęcona pracy interaktywnej w PowerShellu.
Exchange 2010 – The WinRM client received an HTTP server error status (500)
| 2011-09-13 | Posted by Mateusz Świetlicki under Polskie blogi IT |
|
Natknąłem się ostatnio znów na problem z serwerem Exchange 2010 stojącym na wirtualnym WS2008R2. Przy próbie połączenia z konsolą exchange wyświetlał się komunikat błędu:
Connecting to remote server failed with the following error message : The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.
Rozwiązanie okazuje się dość proste, wystarczy wywołać 2 komendy PowerShella:
Import-Module ServerManager Add-WindowsFeature WinRM-IIS-Ext
Które zainstalują WinRM IIS Extensions.
PowerShellowy backup urządzeń sieciowych, czyli SSH w Powershell
| 2011-09-09 | Posted by JeZZoo under CSV, Narzędzia, Polskie blogi IT, remote execution, router, script library, Skrypty |
|
Konfigi z urządzeń sieciowych wymagają backupu jak wszystko inne. Wiadomo, jeden switch pada, to bierzemy następny, podmieniamy, ładujemy konfig i powinno działać. Tylko co, jeśli od ostatniego zrzutu minęło pół roku, a my zdążyliśmy zmienić połowę konfiguracji… Dlatego warto to … Czytaj dalej
Dodawanie użytkowników z odpowiednimi parametrami przez PowerShell
| 2011-09-06 | Posted by kicekpicek under Komputery i Internet, Polskie blogi IT |
|
Ostatnio przyszło mi postawić stronę internetową, która udostępnia interfejs do tego, aby dodać użytkownika do Active Directory, wrzucić do odpowiedniego (wcześniej ustalonego) kontenera OU, włączyć konto i uniemożliwić zmianę hasła użytkownikowi.
Skrypt, jaki to umożliwia (bazujący na cmdletach Quest):
Add-PSSnapin Quest.ActiveRoles.ADManagement
New-QADUser -name NAZWAUSERA -ParentContainer ‘CN=Users,DC=moja,DC=domena,DC=pl’ -samAccountName NAZWAUSERA -UserPrincipalName NAZWAUSERA -UserPassword ‘HASŁOUSERA’ | Enable-QADUser | Set-QADUser -PasswordNeverExpires $true -UserMustChangePassword $false | Add-QADPermission -Account SELF,Everyone -ExtendedRight "User-Change-Password" -Deny -ApplyTo ThisObjectOnly
Takie wpisy tworzą użytkownika NAZWAUSERA z hasłem HASŁOUSERA, włączają to konto oraz wyłączają możliwość zmiany hasła, ustawiając hasło na trwałe (niewygasające).
Do zmiany hasła użytkownik dostaje inny interfejs, gdzie wpisuje tylko swój login i nowe hasło. Skrypt “z tyłu”:
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-QADUser -sAMAccountName ‘NAZWAUSERA‘ | Set-QADUser -userPassword ‘HASŁOUSERA‘
W moim przypadku inny mechanizm chroni dostęp do tej witryny (wcześniej) – dla użytkownika pojawia się tylko miejsce na wpisanie nowego hasła.
Co, jeśli potrzeba zresetować hasła wszystkim w ramach danego OU? Zresetować – ustawić to samo dla wszystkich i wymusić zmianę przy najbliższym logowaniu albo tylko wymusić zmianę przy najbliższej okazji?
Wykorzystując cmdlety Quest:
Add-PSSnapin Quest.ActiveRoles.ADManagement
$OU = "DOMENA.COM/OUZmianyHasla"
get-QADUser -SearchRoot $OU | set-QADUser -userpassword "tYmcz4sow3Has!0"
ForEach-Object { get-QADUser -searchroot $OU | Set-QADUser -UserMustChangePassword $true}
Powyższe linie w PowerShell: aktywują cmdlety Quest, ustawiają zmienną OU, wszystkim użytkownikom z OU zmieniają hasło a następnie wymuszają zmianę hasła przy najbliższym logowaniu.
Jeśli z jakichś powodów musimy wymusić tylko zmianę haseł, z powyższego usuwamy linię trzecią.
Bez wykorzystania cmdletów Quest, za to w CMD a nie w powershell:
dsquery user OU=OUZmianyHasla,DC=DOMENA,DC=COM | dsmod user -pwd tYmcz4sow3Has!0 -mustchpwd yes
Na podstawie:
http://wss.pl/frmThread.aspx?tid=111070&pid=616149#616149
+ Własna walka (zakładanie i zmiana hasła pojedynczej osoby)
PowerShell – przydatne narzędzia
| 2011-08-10 | Posted by JeZZoo under Narzędzia, plugin, Polskie blogi IT, PowerGUI, PowerShell ISE, PowerShell-jak zacząć?, PowerWF, produkty Microsoft, Quest Software, Skrypty |
|
Do pracy z PowerShell wystarczy konsola. Dodając do tego Notatnik możemy już pisać skrypty. Wykorzystując możliwość korzystania z bibliotek i odwoływania się do .NET możemy z PowerShellem zrobić już prawie wszystko. Jednak nakłąd pracy będzie spory. Dodatkowo sporo drzwi zostało … Czytaj dalej
Nowy SQL Server – DENALI – CTP3 – to co najważniejsze….
| 2011-07-21 | Posted by Łukasz under Apollo, Crescent, CTP, Juneau, MDS, Polskie blogi IT, PowerPivot, RBS, TSQL |
|
Wakacje, dużo spraw osobistych i duże projekty zawodowe spowodowały to drobne opóźnienie. 12 lipca ( tak naprawdę w nocy z 12 na 13 lipca naszego czasu link był sprawny) udostępniono najnowszą wersje testową serwera baz danych firmy Microsoft SQL Server o nazwie kodowej DENALI. Świadomie nie nazywam go ani wersją 2011 ani 2012 bo tak naprawdę nie wiadomo, jaką nazwę dostanie ta najnowsza wersja serwera z całą pewnością aktualny build jest 11.0.1440.19.
Wersja CTP3, bo o takiej właśnie jest mowa została przygotowana w kilku językach, ale niestety nie polskim (miedzy innymi chiński, francuski, japońskim). Ja osobiście i tak pewnie do testów wolałbym zainstalować wersje angielską, więc nie stanowi to problemu.
Co nowego posiada Denali? Z całą pewnością dużo szczegółów niebawem znaleźć będzie można na moich blogach SQLResearch.com i PowerPivot’s Blog, a także na stronach polskiego TechNet, gdzie znajduje się już kilka artykułów poświęconych właśnie wersji Denali (wówczas była to wersja CTP1)
· Denali – Co nowego nie tylko dla deweloperów? – część 1
· Denali – Co nowego nie tylko dla deweloperów? – część 2
· Denali – Co nowego nie tylko dla deweloperów? – część 3
· Denali – Co nowego nie tylko dla deweloperów? – część 4
Poza tymi tematami opisanymi w artykułach można znaleźć wiele ciekawych rzeczy, między innymi
- Nowości w typie Spatial
- HADR (SQL Server High Avability)
- Nowe Xtended Events
- Nowe narzędzia – project Juneau
- Wiele nowości w obszarze Business Intelligence (project Crescent, alerty w reporting Services, nowe możliwości PowerPivot, vertipaq w Analysis Services, columnstore – project Apollo, zmiany w Integration Services)
Zmian i tzw ficzerów jest naprawdę wiele. O wszystkich a przynajmniej większości, które testuje już od dłuższego czasu postaram się opowiedzieć w postach na moich blogach.
SQL Server to bardzo potężny system z szeregiem powiązanych wielu rozwiązań większość jest wraz z wersją instalacyjną dołączona, ale część z nich należy pobrać oddzielnie.
Ważna uwaga przed instalacją najnowszego CTP. Należy dokładnie usunąć wszystkie elementy dotyczące wcześniejszych CTP (CTP1 i CTP2).
I tak po kolei (na razie nie opisuje, ale niebawem o wszystkim po troszku):
SQL Server DENALI CTP3 gdzie znajdują się obie wersje 32 i 64 bitowa. Jest również dostępna wersje SQL Server Express DENALI CTP3.
Narzędzia SQL Server Developer Tools o kodowej nazwie Juneau
Oczywiście niezbędna przykładowa baza danych AdventureWorks2008R2
Ważna uwaga jak ją podłączyć do naszego serwera:
CREATE DATABASE AdventureWorks2008R2
ON (FILENAME = ‘<drive>:\<właściwa ścieżka>\AdventureWorks2008R2_Data.mdf’)
FOR ATTACH_REBUILD_LOG ;
Oto zbiór większości elementów które mogą się przydać:
ADD-IN do Excela – SQL Server Master Data Services Add-In for Microsoft Excel CTP3.
Microsoft SQL Server Denali Native Client CTP3 w wersji x86 i x64
Microsoft SQL Server Denali Upgrade Advisor CTP3 w wersji x86 i x64
Microsoft Windows PowerShell Extensions for SQL Server Denali CTP3 w wersji x86 i x64
Microsoft SQL Server Report Builder dla SQL Server DENALI CTP3.
PowerPivot dla Excela w wersji SQl Server DENALI CTP3 .
Reporting Services w wersji SQL Server DENALI CTP3 dla SharePoint 2010
Microsoft SQL Server Denali Transact-SQL Language Service CTP 3 w wersji X86 oraz x64
Microsoft SQL Server Denali Semantic Language Statistics CTP 3
Microsoft SQL Server Denali Transact-SQL ScriptDom CTP 3 w wersji x86 i x64
Microsoft SQL Server Denali Transact-SQL Compiler Service CTP 3 w wersji x86 i x64
Microsoft SQL Server Denali Data-Tier Application Framework CTP 3 w wersji x86 i x64
Microsoft System CLR Types for SQL Server Denali CTP 3 w wersji x86 i x64
Microsoft SQL Server Denali Remote Blob Store CTP 3 w wersji x86 i x64
Microsoft SQL Server Denali ADOMD.NET CTP 3 w wersji x86 i x64
Microsoft SQL Server Denali Shared Management Objects CTP 3 w wersji x86 i x64
Microsoft SQL Server Denali Analysis Management Objects CTP 3 w wersji x86 i x64
Microsoft Analysis Services OLE DB Provider for Microsoft SQL Server code name ‘Denali’ CTP 3 w wersji x86 i x64
Microsoft SQL Server® Service Broker External Activator for SQL Server Denali CTP 3 w wersji x86 i x64
Microsoft SQL Server StreamInsight v1.2
*gdyby któryś link nie zadziałał proszę o info
Powodzenia i miłych SQL Server Researcha!
Żeby ułatwić poznawanie nowej wersji SQL Server umieszczę również na blogu post o instalacji nowej pomocy do SQL Server DENALI (CTP3).
Biblioteka własnych funkcji w PowerShell
| 2011-04-30 | Posted by JeZZoo under Polskie blogi IT, PowerShell-jak zacząć?, produkty Microsoft, script library, Skrypty |
|
Jeśli częściej posługujemy się PowerShellem to w pewnym momencie dochodzimy do etapu, gdzie mamy sporą ilość gotowców porozrzucanych po różnych plikach. Jeśli wykonujemy powtarzające się czynności, które wymagają większej ilości kodu również powstaje spore repozytorium, które za każdym razem trzeba … Czytaj dalej
Get-ScriptDirectory czyli gdzie jesteś skrypcie
| 2011-04-30 | Posted by JeZZoo under invocation, Polskie blogi IT, PowerShell-jak zacząć?, produkty Microsoft, script library, Sieci |
|
Jeśli postanowiliśmy podzielić nasz skrypt na więcej plików, np sięgamy do biblioteki gotowych funkcji, którą wcześniej przygotowaliśmy okazuje się, że odwołanie za pomocą „.” do bieżącego katalogu nie zadziała do końca tak jak się spodziewaliśmy. W tym przypadku naszym bieżącym … Czytaj dalej
SharePoint 2010 i PowerShell użyteczne skrypty
| 2010-08-02 | Posted by Mateusz Świetlicki under Polskie blogi IT |
|
W nowym SharePoint 2010 sryptowe zarządzanie zostało przeniesione z STSADM do coraz popularniejszego PowerShella.
Add-PSSnapin Microsoft.SharePoint.PowerShell
Get-SPFarm
<user_documents>/WindowsPowerShell/Microsoft.PowerShell_profile.ps1
$12HivesDir = "${env:CommonProgramFiles}\Microsoft Shared\web server extensions\14\" [System.Reflection.Assembly]::LoadFrom("$12HivesDir\ISAPI\Microsoft.SharePoint.dll") $devSite = New-Object -TypeName "Microsoft.SharePoint.SPSite" -ArgumentList "http://192.168.0.201/Repozytorium"; $devWeb = $devSite.OpenWeb(); $zadania = $devweb.GetList(“http://192.168.0.201/Repozytorium/Lists/Zadania")</a> $types = @() $dtypes = @() foreach($ctype in $zadania.ContentTypes) { $types += $ctype.name } $opisy = $devweb.GetList(http://192.168.0.201/Repozytorium/Lists/Opisy%20wiadomoci) foreach($ctype in $opisy.items) { $dtypes += $ctype.name } foreach($ctype in $types) { if($dtypes -notcontains $ctype) { Write-Host "Dodaje element: ", $ctype $item = $opisy.AddItem() $item.item("Typ zadania") = $ctype $item.Update() } }
Powershell – pobieranie IOPS i latency z LUN
| 2010-02-02 | Posted by jfelinski under LUN, Polskie blogi IT, Praktyka, Problemy, vcenter, vsphere |
|
Dzisiaj, w ramach rozrywki i debugowania problemów z wydajnością wyskrobałem takiego potwora :
$samplePeriod = 300
$msg = Connect-VIServer -Server SERVER -User administrator -Password PASSWORD
$VMhosts = Get-Cluster | Get-VMHost
$objs = @()
$start = Get-Date "2010-02-02 08:00:00"
$end = Get-Date "2010-02-02 10:00:00"
$maxSamples = 100000;
foreach ($VMhost in $VMhosts)
{
$luns = (Get-ScsiLun -VmHost $VMhost)
foreach($lun in $luns)
{
$Nreads = Get-Stat -Entity $VMhost -Stat disk.numberRead.summation -IntervalMins 5 -MaxSamples $maxSamples -start $start -finish $end | where {$_.Instance -eq $lun.canonicalName} | Measure-Object Value -Average -Maximum -Minimum
$Nwrites = Get-Stat -Entity $VMhost -Stat disk.numberWrite.summation -IntervalMins 5 -MaxSamples $maxSamples -start $start -finish $end| where {$_.Instance -eq $lun.canonicalName} | Measure-Object Value -Average -Maximum -Minimum
$Nrlatency = Get-Stat -Entity $VMhost -Stat disk.deviceReadLatency.average -IntervalMins 5 -MaxSamples $maxSamples -start $start -finish $end | where {$_.Instance -eq $lun.canonicalName} | Measure-Object Value -Average -Maximum -Minimum
$Nwlatency = Get-Stat -Entity $VMhost -Stat disk.deviceWriteLatency.average -IntervalMins 5 -MaxSamples $maxSamples -start $start -finish $end| where {$_.Instance -eq $lun.canonicalName} | Measure-Object Value -Average -Maximum -Minimum
$myobj = "" | select "Hostname","Lun","IOPS Average","IOPS Max","Read latency Average","Write latency Average","Write latency Maximum","Read latency Maximum"
$myobj."Hostname" = $VMhost
$myobj."Lun" = $lun.canonicalName
$myobj."IOPS Average" = [Math]::Round(($Nreads.average+$Nwrites.average)/$samplePeriod,0)
$myobj."IOPS Max" = [Math]::Round(($Nreads.maximum+$Nwrites.maximum)/$samplePeriod,0)
$myobj."Read latency Average" = $Nrlatency.average
$myobj."Read latency Maximum" = $Nrlatency.maximum
$myobj."Write latency Average" = $Nwlatency.average
$myobj."Write latency Maximum" = $Nwlatency.maximum
$objs += $myobj
}
}
$objs | Export-Csv -NoTypeInformation ‘LunIOPS.csv’
Nie jest może piękny ale wystarczy do znalezienia LUN’a który pracuje grubo ponad swoje możliwości. Generalnie w wyniku dostaniemy tabelkę z opisem każdego LUN i wskaźników za dany okres
| Hostname | Lun | IOPS Average | IOPS Max | Read latency Average | Write latency Average | Write latency Maximum | Read latency Maximum |
| XXXXX.net | naa.6006016087001f00d4df746f057dde11 | 64 | 349 | 2.08 | 0 | 0 | 6 |
Jak odinstalować rolę Mailbox w Exchange 2007
| 2009-02-01 | Posted by Tomasz_Sochacki under Exchange 2007, How To, Polskie blogi IT |
|
Jak odinstalować rolę “Mailbox” w Exchange 2007? Wystarczy uruchomić komendę: setup /m:uninstall /r:mailbox Gdzie plik setup jest dostępny na płycie instalacyjnej Exchange Server 2007