Podsłuchiwanie IIS

By Grzegorz Tworek on Maj 17th, 2016

W zasadzie, to nie bardzo wiadomo, od której strony zacząć. Czy od IIS czy od ETW. Przyjmijmy tymczasowo, że ETW tylko wspomnę a kiedyś porządnie opiszę.

Continue Reading

Storage Replica czyli WVR

By TechNet Polska on Grudzień 11th, 2014

Redundancja to trudne słowo, ale nawet, jeżeli ktoś nie umie go wymówić, to wie, że w świecie IT jest niezwykle ważna. Do całego ogromnego portfolio rozwiązań dotykających tego tematu (tak pochodzących od Microsoft jak i od firm trzecich), dołącza w Windows 10 kolejne – tytułowa Storage Replica zwana dawniej Windows Volume Replication.

Continue Reading

Storage Replica czyli WVR

By Grzegorz Tworek [MVP] on Grudzień 10th, 2014

Redundancja to trudne słowo, ale nawet, jeżeli ktoś nie umie go wymówić, to wie, że w świecie IT jest niezwykle ważna. Do całego ogromnego portfolio rozwiązań dotykających tego tematu (tak pochodzących od Microsoft jak i od firm trzecich), dołącza w Windows 10 kolejne – tytułowa Storage Replica zwana dawniej Windows Volume Replication.

Continue Reading

JSLink

By TechNet Polska on Czerwiec 26th, 2014

Pisząc na tym blogu już prawie osiem lat, nigdy nawet nie dotknąłem tematu SharePointa. Na zaawansowanych zagadnieniach się nie znam a niezaawansowane… właśnie.

Continue Reading

JSLink

By TechNet Polska on Czerwiec 26th, 2014

Pisząc na tym blogu już prawie osiem lat, nigdy nawet nie dotknąłem tematu SharePointa. Na zaawansowanych zagadnieniach się nie znam a niezaawansowane… właśnie. To jest dla mnie prawdziwa siła tego narzędzia, że gdy ktoś zna stronę biznesową, to mając do dyspozycji konto na SharePoincie z kwestiami informatycznymi jakośtam sobie poradzi.

Continue Reading

TechEd i po TechEdzie

By TechNet Polska on Maj 28th, 2014

O TechEdzie pisałem na tym blogu wielokrotnie. Że największy, że najciekawszy, że fachowcy, że znajomi, że nowości… i co roku mógłbym to powtarzać i powtarzać. Bo TechEd TechedEm pozostaje i na razie nie zanosi się na istotną zmianę ani w formule ani w wartości dla uczestników.

Continue Reading

TechEd i po TechEdzie

By TechNet Polska on Maj 28th, 2014

O TechEdzie pisałem na tym blogu wielokrotnie. Że największy, że najciekawszy, że fachowcy, że znajomi, że nowości… i co roku mógłbym to powtarzać i powtarzać. Bo TechEd TechedEm pozostaje i na razie nie zanosi się na istotną zmianę ani w formule ani w wartości dla uczestników. Continue Reading

Wytęż wzrok…

By TechNet Polska on Kwiecień 30th, 2014

… i znajdź jeden istotny szczegół różniący dwa poniższe obrazki:

Continue Reading

Wytęż wzrok…

By TechNet Polska on Kwiecień 30th, 2014

… i znajdź jeden istotny szczegół różniący dwa poniższe obrazki:

 

Continue Reading

globalqueryblocklist

By TechNet Polska on Marzec 31st, 2014

Dawno dawno temu, w czasach Internet Explorera 4, grupa geniuszy z Inktomi, Microsoft, RealNetworks i Sun wpadła na świetny pomysł, polegający na tym, że administratorom można oszczędzić nieco pracy. Idea oczywiście jest wielce szczytna nawet, jeżeli oszczędność dotyczyła tak drobnego aspektu konfiguracji, jakim jest ustawienie proxy w przeglądarce. Pomysł został spisany, opublikowany jako draft, oznaczony, że wygasa w grudniu 1999 i zaimplementowany w Internet Explorerze 5.

Continue Reading

globalqueryblocklist

By TechNet Polska on Marzec 30th, 2014

Dawno dawno temu, w czasach Internet Explorera 4, grupa geniuszy z Inktomi, Microsoft, RealNetworks i Sun wpadła na świetny pomysł, polegający na tym, że administratorom można oszczędzić nieco pracy. Idea oczywiście jest wielce szczytna nawet, jeżeli oszczędność dotyczyła tak drobnego aspektu konfiguracji, jakim jest ustawienie proxy w przeglądarce. Pomysł został spisany, opublikowany jako draft, oznaczony, że wygasa w grudniu 1999 i zaimplementowany w Internet Explorerze 5.

Continue Reading

Niezabijalne procesy

By TechNet Polska on Luty 11th, 2014

Service Manager jest jednym z moich ulubionych mechanizmów w systemie. Wiem, że to może dziwnie brzmieć, ale gdybym musiał znaleźć przyczyny, to chyba po prostu zdążyłem się do niego przyzwyczaić. Poza drobnymi modyfikacjami, Service Manager praktycznie nie zmienił się odkąd zacząłem się interesować wnętrznościami systemu a kiedyś, dawno temu (przed Windows 2000 i pojawieniem się WMI) był praktycznie jedyną metodą "namówienia" zdalnego komputera do uruchomienia jakiegoś procesu.

Continue Reading

Niezabijalne procesy

By TechNet Polska on Luty 11th, 2014

Service Manager jest jednym z moich ulubionych mechanizmów w systemie. Wiem, że to może dziwnie brzmieć, ale gdybym musiał znaleźć przyczyny, to chyba po prostu zdążyłem się do niego przyzwyczaić. Poza drobnymi modyfikacjami, Service Manager praktycznie nie zmienił się odkąd zacząłem się interesować wnętrznościami systemu a kiedyś, dawno temu (przed Windows 2000 i pojawieniem się WMI) był praktycznie jedyną metodą "namówienia" zdalnego komputera do uruchomienia jakiegoś procesu.

Continue Reading

Desired State Configuration

By TechNet Polska on Styczeń 7th, 2014

Konfigurujesz świeżo zainstalowany serwer… Jest ciekawie? Za pierwszym razem raczej tak. Za drugim pewnie też, za to trochę sprawniej. Od trzeciego do dziesiątego dochodzisz do wniosku, że da się to dobrze zrobić z zamkniętymi oczami przy pomocy samych skrótów klawiaturowych. Oczywiście serwer jest potem w 100% zgodny z firmowymi regułami konfiguracji, ustawiony w jedyny słuszny sposób i w ogóle idealny. Brzmi fantastycznie, ale przy większej skali muszą pojawić się problemy. Na przykład dwudziesty siódmy serwer okazuje się skonfigurowany nieco inaczej, bo miałeś słabszy dzień, albo akurat rozlała się kawa i w zamieszaniu zdarzyło się przeskoczyć któryś ze standardowo wykonywanych etapów. Albo kolega administrator wykonał dokładnie te same działania, tylko na końcu serwer ma inną konfigurację.

Od kiedy mam do czynienia z produkcyjnymi serwerami Windows (czyli od połowy lat dziewięćdziesiątych), ciągle słyszę, jak Microsoft jasno mówi, że w takich sytuacjach powinniśmy skorzystać z dostępnych bezpłatnie, jedynych w swoim rodzaju, słusznych, skutecznych i w ogóle wspaniałych narzędzi do centralnego zarządzania konfiguracją. Mało tego! Sam o takich pięknych ideach wielokrotnie opowiadałem, na przykład na poświęconej dokładnie temu tematowi sesji na konferencji MTS 2009.

A jak to wygląda naprawdę? Mamy teoretycznie do dyspozycji dwa potężne narzędzia: skrypty i GPO. Teoretycznie wiemy jak ich używać. Teoretycznie da się wszystko nimi zrobić tak, że sam fakt dodania serwera do konkretnego OU sprawi, że wszystko, co powinno być na nim skonfigurowane, zadzieje się samo. Ale z ręką na sercu – kto tak ma w swoim środowisku? Nie, że jakieś kawałki, przymiarki albo proof of concept, tylko działające, w pełni automatyczne rozwiązanie konfigurujące serwery zgodnie z firmowymi politykami od początku do końca? A przecież mamy świetne narzędzia, możemy oszczędzić sporo żmudnej pracy i uniknąć błędów! Tylko jakoś w codziennej praktyce te narzędzia nie są aż tak fantastyczne, skoro nikt nie wyrywa się do ich stosowania…

Prawdopodobnie do takiego samego wniosku doszedł ktoś w Microsoft i zamiast jeszcze mocniej przekonywać "używajcie GPO", zaproponował zupełnie nowe rozwiązanie. Oparte oczywiście (takie czasy) o PowerShella, przyjaźniejsze dla administratora, strawne dla menedżera, zaprojektowane dla serwerów i dające się użyć w starszych wersjach systemu. Mowa o tytułowym Desired State Configuration.

DSC wprowadza nowe podejście bazujące na prostych tekstowych plikach konfiguracyjnych. Prostych, znaczy łatwych do stworzenia, łatwych do przerobienia w razie potrzeby i łatwych do zrozumienia dla menedżerów. Każdy z tych aspektów jest w praktyce równie istotny. Plik taki zaczyna się od słowa "Configuration" i zawiera sekcje odpowiedzialne za poszczególne aspekty konfiguracji. Na przykład:

Configuration test1
{
WindowsFeature IIS
{
  Ensure="Present"
  Name="Web-Server"
}
}

Po uruchomieniu takiego skryptu i wpisaniu "test1" otrzymamy plik folder z plikami z rozszerzeniem *.mof. Brzmi znajomo? W skrócie powiedzieć można, że jest to tekstowy plik zawierający opisaną wcześniej konfigurację w postaci strawnej dla automatycznego przetworzenia.

Samo przetworzenie uruchamia się cmdletem Start-DscConfiguration, którego parametrem powinna być lokalizacja folderu z plikami *.mof. Dodanie parametrów -Wait i -Verbose sprawi, że wszystko ładnie będzie widać.

Na razie, widać, że skomplikowaliśmy sobie skryptową instalację ról serwera. Trochę więcej entuzjazmu wzbudzić może świadomość, że oprócz ról serwera, do dyspozycji mamy całkiem przydatny zestaw parametrów, formalnie zwanych DSC Resources:

  • Archive – służący do rozpakowania archiwum w zadanej lokalizacji
  • Environment – zarządzający zmiennymi środowiskowymi
  • File – zarządzający plikami i folderami
  • Group – zarządzający lokalnymi grupami użytkowników
  • Log – rejestrujący działania DSC w Event Log
  • Package – zarządzający instalacją paczek (na przykład MSI)
  • WindowsProcess – zarządzający procesami na serwerze
  • Registry – odpowiadający za wpisy w rejestrze systemu
  • WindowsFeature – pozwalający instalować i usuwać role i funkcjonalności serwera
  • Script – umożliwiający uruchomienie na docelowym serwerze zadanego skryptu
  • Service – służący do zarządzania serwisami systemowymi
  • User – zarządzający lokalnymi kontami użytkowników

Podczas testów, warto przyjrzeć się tym parametrom dokładniej, ponieważ ich możliwości są zwykle dość rozbudowane. Serwisy systemowe można uruchamiać, zatrzymywać, tworzyć czy usuwać, użytkownikom można ustawiać hasła itp. Można również zdefiniować własne klasy zasobów DSC, jednak na pewno wymaga to na początek opanowania standardowych zasobów i na razie temat ten pominę.

Skrypty konfiguracyjne można oczywiście parametryzować, dostosowując je do funkcji serwera (na przykład dodając parametr, którym decydujemy czy w danym przypadku na serwerze ma być IIS czy nie) czy zmuszając do specyficznego działania na maszynie o zadanej nazwie.

Jak dotąd widać, dzięki DSC można nieco uprościć zarządzanie przez skrypty. Zamiast pisać skrypty służące do zarządzania każdym z wymienionych wyżej aspektów konfiguracji, można użyć pliku tekstowego z opisem pożądanego stanu i zaaplikować go na serwerze jednym prostym poleceniem. Jest to jakiś krok w dobrą stronę, głównie dlatego, że utrzymanie nadążającej za wymaganiami treści takiego pliku tekstowego jest prostsze niż utrzymywanie rozwiązań skryptowych. Ponadto, sens działania pliku konfiguracyjnego jest zrozumiały dla kogoś więcej niż tylko dla autora. Można polemizować czy lepsze są takie pliki czy prawdziwe skrypty, jednak jeżeli w prawdziwym środowisku skrypty konfigurujące serwery nie są szeroko stosowane, to cała dyskusja traci sens. Lepsze będzie działające DSC niż niedziałające skrypty.

Piękno DSC nie tkwi jednak wyłącznie w uproszczeniu opisu pożądanego stanu. Dzięki PowerShellowi możemy robić naprawdę ciekawe rzeczy:

  • Sprawdzić (Test-DscConfiguration), czy bieżąca konfiguracja jest zgodna ze zdefiniowanymi regułami (cmdlet zwraca True lub False, ale to wystarczy, żeby administrator wiedział czy powinien zareagować czy może spać spokojnie)
  • Zweryfikować (Get-DscConfiguration), jaki jest bieżący stan parametrów, którymi chcielibyśmy zarządzać. Operacja ta pozwala dowiedzieć się, dlaczego opisany wcześniej Test-DscConfiguration zwrócił False.
  • Sięgać do komputerów zdalnych i zarządzać konfiguracją albo poprzez pociągnięcie (pull) konfiguracji z centralnego repozytorium, albo poprzez wypchnięcie (push) ustawień z lokalnego komputera na nowy serwer.

Konfiguracja typu pull oznacza, że konfigurowany serwer okresowo (domyślnie co 30 minut) sprawdza czy plik z ustawieniami odpowiada temu, co dzieje się na serwerze. Może nadpisywać automatycznie już istniejący plik konfiguracyjny, jednak zależy to od ustawienia przez administratora. Konfiguracja serwera udostępniającego pliki nie jest trywialna, ponieważ wykorzystuje on specjalną rolę Windows PowerShell Desired State Configuration.

Mechanizmy DSC (DscLocalConfigurationManager) mogą reagować na różne sposoby. Domyślnie, (czyli w trybie ApplyAndMonitor), w przypadku wykrycia niezgodności, w Event Logu zapisywana jest odpowiednia informacja. Tryb działania przełączyć można jednak na ApplyAndAutoCorrect i wtedy niezgodności są automatycznie usuwane.

W efekcie, dostajemy do ręki nowy, interesujący mechanizm, który:

  • pozwala prosto zautomatyzować ustawianie ważnych dla nas parametrów serwera
  • sam sprawdza czy serwer jest zgodny z pożądanym stanem i mądrze reaguje na niezgodności
  • może działać w sposób scentralizowany, zarządzając zdalnymi serwerami

W skrócie: prawie jak GPO ale dla prawdziwych twardzieli.

Jeżeli w środowisku nie ma skutecznego scentralizowanego zarządzania konfiguracją i jeżeli ktokolwiek uważa, że jednak nie byłoby to zupełnie zbędne – zdecydowanie warto przyjrzeć się bliżej Desired State Configuration.

Autor: Grzegorz Tworek [MVP]

Driver Verifier

By TechNet Polska on Grudzień 13th, 2013

Kiedyś, mój ówczesny szef, przedstawiając mnie współpracownikom powiedział, że używam wyszukiwarek tylko po to, żeby znaleźć coś, co już na pewno opisałem na blogu. Pomijając już to, jak takie stwierdzenie łechce ego (czego dowodem jest, że je po latach pamiętam), to myślę, że tak naprawdę, takie podejście nie jest obce nikomu, kto prowadzi bloga dłużej niż kilka miesięcy. No bo o ile nowości na pewno nigdy opisywane wcześniej nie były, o tyle jakieśtam mniej lub bardziej zaawansowane szczegóły i szczególiki czasem tak długo ma się w głowie na liście "do opisania", że potem człowiek naprawdę mocno się dziwi, gdy chce znaleźć linka do swojego artykułu a tu okazuje się, że on nigdy nie powstał… Ja miałem tak wczoraj, gdy próbowałem znaleźć przepis na postępowanie w przypadku występowania BSOD z kodem 0x19 BAD_POOL_HEADER.

Błąd ten jest nietrywialny do przeanalizowania, ponieważ powstaje w sytuacji, gdy sterownik sięgnie do puli pamięci, której nagłówek został przez kogoś popsuty. Podstawowa analiza wskazuje więc "ofiarę" a nie winnego całej sytuacji.  Prawdziwym winnym jest ten, kto popsuł, a w momencie pojawienia się blue screena nie mamy żadnych wyraźnych śladów kto to był i kiedy to zrobił ani dlaczego. Biorąc pod uwagę, że prawie 80% blue screenów spowodowane jest przez sterowniki firm trzecich, możemy strzelać w ciemno i próbować aktualizować oprogramowanie do karty graficznej czy sieciowej, jednak nie ma to wiele wspólnego z rzetelnym naukowym podejściem do tematu. Analiza dumpa wiele nam nie da, bo wskaże ofiarę. Co więc pozostaje? Otóż trzeba złapać winnego na gorącym uczynku, w momencie, gdy próbuje modyfikować nie swoje obszary pamięci. Nie jest to aż takie trudne, ponieważ mamy do dyspozycji potężne narzędzie, które (z nie do końca dla mnie zrozumiałych powodów) leży i czeka na dysku każdego komputera wyposażonego w system Windows. Mowa o Driver Verifier.

Generalnie rzecz ujmując, Driver Verifier sprawia, że mechanizmy działające w jądrze systemu i współpracujące ze sterownikami zaczynają być nieco mniej ufne i szczegółowo przyglądają się każdej czynności. Czy aby na pewno sterownik zwalnia całą pamięć, gdy przestaje działać? Czy pracujący w trybie jądra sterownik nie sięga w brzydki sposób do pamięci w trybie użytkownika? Czy to, czego sterownik próbuje użyć jako uchwytu, faktycznie jest uchwytem?

Jedną z możliwości jądra jest na przykład takie alokowanie żądanych puli pamięci, aby nie dało się do nich wejść przypadkiem. Większość błędów związanych z zamazaniem przez źle napisany sterownik cudzych obszarów pamięci bierze się stąd, że sterownik taki, zapisując bajt po bajcie, w którymś momencie wyjdzie poza swój obszar. Jeżeli następny obszar należy do kogoś innego, to katastrofa gotowa a winnego po fakcie może być trudno wskazać. Zabezpieczenie przed tym nie jest bardzo złożone – wystarczy, zamiast umieszczać jeden blok pamięci za drugim, rozdzielić bloki obszarem ziemi niczyjej. Celowo nikt tam nie wejdzie a przypadkowy dostęp zostanie natychmiast zauważony i wywoła BSOD o numerze 0xCD PAGE_FAULT_BEYOND_END_OF_ALLOCATION. Jaki mamy efekt w przypadku opisanym na początku? Zamiast błędu 0x19 pojawia się błąd 0xCD. Nie brzmi to może szczególnie atrakcyjnie, bo w końcu blue screen to blue screen, ale różnica jest niezwykle istotna: identyfikujemy winnego a nie ofiarę! A to już nienajgorszy start do skutecznego wyeliminowania łobuza z naszego systemu.

Wróćmy do narzędzia. Ponieważ Driver Verifier stosowany bywa przez programistów do badania poprawności działania pisanych przez nich sterowników, jego funkcjonalność jest znacząco większa niż to, czego potrzebuje użytkownik walczący z trudnym BSOD. Dlatego, najlepiej podejść do niego z precyzyjną instrukcją:

  • Uruchomić aplikację verifier.exe. Leży w folderze system32 i musi być uruchamiana z uprawnieniami administratora.
  • Można użyć "Standard Settings" – ten zestaw ustaweń (opisany dokładnie w MSDN) pozwala na wykrycie typowych problemów i jest bardzo dobrym punktem wyjścia.
  • Korzystamy z opcji "Select driver names from a list"
  • Sortujemy sterowniki po kolumnie "Provider" i na początku i końcu listy zaznaczamy wszystkie te, które nie są dostarczone przez Microsoft. I tak nie powinniśmy weryfikować działania wszystkich sterowników na raz, a statystyki mówią, że znalezienie czegokolwiek jest znacząco bardziej prawdopodobne w kodzie firm trzecich.
  • Jeżeli w dumpie dają się znaleźć sterowniki (polecenie "lmof" w WinDbg może być tu pomocne), których nie ma na liście Verifiera, bo nie są w momencie jego uruchamiania załadowane, można je dodać manualnie.
  • Klikamy "Finish" i restartujemy komputer.

Wydajność komputera jest nieco ograniczona (dlatego praca z Verifierem stale aktywnym nie jest polecana) ale wszystko działa. A gdy zdarzy się błąd, dowiemy się o nim natychmiast a jego analiza nie powinna już być trudna. Po znalezieniu winnego i wyeliminowaniu problemu, należy ponownie uruchomić verifier.exe i korzystając z opcji "Delete existing settings" i restartu, przełączyć system w normalny tryb pracy.

Do pełni obrazu, dodałbym jeszcze kilka ważnych uwag końcowych:

  • Jeżeli chcemy się czegoś nowego nauczyć, pobawić Verifierem a uparcie nie pojawiają nam się BSODy, to polecam użycie aplikacji NotMyFault. Na maszynie wirtualnej a nie na produkcyjnym systemie! Nawet, jeżeli coś sobie popsujemy, to snapshoty pomogą nam oszczędzić sporo czasu. W przypadku NotMyFault, konieczne będzie weryfikowanie sterownika myfault.sys – jeżeli nie ma go na liście, to przycisk "Add currently not loaded driver(s) to the list…" w opcjach Verifiera na pewno się przyda.
  • Jeżeli mamy pecha, to "ratowniczy" blue screen pojawi się zanim będzie możliwe zalogowanie się do systemu. Żeby móc opanować system czy zainstalować zaktualizowany sterownik, musimy jednak jakoś Verifiera odpalić. Pomoże nam w tym Safe Mode, ale warto wiedzieć, że ten tryb potrafimy włączyć zanim pierwszy raz uruchomimy verifier.exe.
  • Uważajmy zanim komuś "życzliwemu" wyślemy nasz dump do analizy. Są w nim poufne informacje (na przykład hasła) i beztroskie publikowanie dumpów na forach niekoniecznie jest najlepszym podejściem.
  • Pamiętajmy, że przyczyną istotnej części BSOD są problemy sprzętowe. Niestety nie jest to proste do wykrycia i często tracimy wiele czasu na walkę z przedziwnymi objawami. Poszukując przyczyn kłopotów, nie wolno o sprzęcie zapominać.

A tak naprawdę, to nikomu nie życzę potrzeby używania takich narzędzi.

Autor: Grzegorz Tworek [MVP]

PS sprawdzając szybko czy zamiast pisać sam, nie znajdę gdzieś gotowego do polecenia przepisu na poradzenie sobie z BSOD 0x19 trafiłem na jeden wyjątkowo kuriozalny. Chyba nie polecam.