Akademia Windows 7 - Część 7: Rozwiązywanie problemów

Autor: Łukasz Foks

Opublikowano: 13 listopada 2009

Zawartość strony

	Problem Steps Recorder (PSR)
	Windows Troubleshooting Platform
	Dlaczego warto się zainteresować WTP?
	Elementy architektury WTP
	Uruchamianie paczek przez PowerShell i linię komend
	Czas na start, czyli szybki kurs tworzenia paczki
	Garść uwag końcowych

Komputery stały się nieodłącznym narzędziem współczesnego pracownika. Gdy ma problemy z systemem lub komputerem natychmiast spada efektywność jego pracy. Specjaliści IT i eksperci pracujący w działach pomocy technicznej muszą mieć sprawdzone sposoby na szybkie usuwanie usterek. W Windows 7 zaimplementowano szereg narzędzi, które ułatwią użytkownikowi rozwiązywanie problemów, nawet bez kontaktowania się z działem Help Desk. W siódmej części Akademii Windows 7 omówione zostaną najistotniejsze: narzędzie Problem Steps Recorder oraz platforma Windows Troubleshooting Platform.

Problem Steps Recorder (PSR)

Jednym z najważniejszych wyzwań działów pomocy technicznej jest szybkie i profesjonalnie działanie w przypadku zgłoszenia przez użytkownika usterki. Aby zdiagnozować przyczynę problemu, musimy poznać okoliczności oraz szczegóły techniczne związane z jego wystąpieniem. Większość osób, które zgłaszają usterkę, nie ma dużej wiedzy w zakresie IT, dlatego będzie im trudno rzeczowo odpowiedzieć na pytania działu wsparcia. Z pomocą przychodzi Problem Steps Recorder (PSR) w Windows 7, aplikacja umożliwiająca rejestrowanie kroków, które wykonał użytkownik, dzięki funkcji tworzenia zrzutów ekranu każdego etapu, a następnie zapisu w postaci czytelnego raportu.

Aby uruchomić Problem Steps Recorder, trzeba w pasku wyszukiwania menu Start wprowadzić psr.exe. Po chwili prezentowany jest interfejs graficzny programu.

Rysunek 1: Interfejs graficzny.

Jak widać, PSR ma bardzo skromny, ale intuicyjny interfejs, co gwarantuje, że użytkownicy nie będą mieli problemu z jego obsługą i nie będziemy musieli organizować wewnętrznych szkoleń w zakresie podstaw jego użytkowania. Wyróżnić można cztery główne przyciski: Start Record (rozpoczęcie nagrywania), Stop Record (zatrzymanie trwającego nagrania), Add Comment (dodawanie komentarza do aktualnego etapu) oraz przycisk z białym znakiem zapytania na niebieskim tle (dostęp do zasobów pomocy oraz uruchomienie okna ustawień). Interfejs podczas nagrywania wyświetla również stoper, który wskazuje czas nagrania. Po zainicjowaniu nagrywania interfejs wygląda następująco:

Rysunek 2: Inicjacja nagrywania.

Użytkownik ma do dyspozycji przycisk pauzy/wznowienia zapisu oraz przycisk z ikoną tarczy, który służy do poszerzania uprawnień, jeżeli któryś etap działania będzie tego wymagał podczas rejestrowania problemu. W rzeczywistości opcja ta uruchamia na nowo Problem Steps Recorder w kontekście użytkownika o uprawnieniach administratora, co wiąże się z przerwaniem sesji działania programu.

Problem Steps Recorder zapewnia dostosowanie ustawień programu w opcjach interfejsu graficznego.

Rysunek 3: Ustawienia programu.

W sekcji Output Location można określić miejsce zapisu raportu z aktualnego nagrania (w postaci pliku ZIP). W opcjach w Screen Capture wskazuje się, czy i ile ostatnich zrzutów ekranu ma być zapisywanych w tworzonym raporcie.

Korzystanie z aplikacji ułatwiają skróty klawiszowe przypisane do opcji. Wszystkie wymienione zostały w tabeli:

Skrót	Wyjaśnienie
Alt + A	rozpoczynanie sesji
Alt + U	wstrzymywanie sesji
Alt + S	wznawianie wstrzymanej sesji
Alt + O	zatrzymywanie sesji
Alt + C	dodawanie komentarza
Alt + M	uruchomienie jako administrator
Alt + G	opcje programu
F1	pomoc

Po zakończeniu nagrywania tworzony jest raport w postaci pliku mht z zarejestrowaną zawartością. Składają się na nią: zrzuty ekranu z komentarzami (powstającymi automatycznie bądź dodanymi przez użytkownika), te same zrzuty, lecz wyświetlane w formie dynamicznego pokazu slajdów krok po kroku, oraz szczegółowe dane o czynnościach, które wykonał użytkownik, i aplikacjach, które uruchomił, zapisane w formie tekstu –m.in. informacje o wersji aplikacji i jej twórcy, a także nazwy kontrolek interfejsu, których używał użytkownik.

Problem Steps Recorder nie tylko może być konfigurowany z poziomu graficznego interfejsu użytkownika, ale też kontrolowany za pomocą wiersza polecenia. Korzystając z wiersza polecenia, uzyskujemy dostęp do opcji, które są nieosiągalne w przypadku stosowania graficznej wersji narzędzia. W tym celu należy uruchomić linię komend, a następnie przejść do katalogu \Windows\System32, gdzie znajduje się aplikacja psr.exe.

W tabeli poniżej wymieniono najważniejsze opcje i opisano ich działanie.

Opcja	Wartość	Wyjaśnienie
/start	nie dotyczy	rozpoczyna sesję
/stop	nie dotyczy	zatrzymuje sesję
/output	ścieżka	określa lokalizację zapisu
/sc	0;1	określa czy mają być zapisywane zrzuty wykonywanych kroków (0 – nie; 1 – tak)
/maxsc	wartość liczbowa	określa ile ostatnich zrzutów ma być zapisanych
/gui	0; 1	określa czy podczas nagrywania sesji ma być wyświetlany interfejs graficzny
/sketch	0; 1	określa czy mają być tworzone szkice w przypadku wyłączenia opcji tworzenia zrzutów ekranu (0 – nie; 1 – tak)
/slides	0; 1	określa czy raport ma zawierać opcje wyświetlania zrzutów ekranu w formie pokazu slajdów (0 – nie; 1 – tak)
/arcetl	0; 1	określa czy w archiwum ZIP ma się znaleźć raport w formacie etl
/arcxml	0; 1	określa czy w archiwum ZIP ma się znaleźć raport w formacie xml
/arcmht	0; 1	określa czy w archiwum ZIP ma się znaleźć raport w formacie mht (domyślnie nawet bez konfiguracji tej opcji)

 

Do początku strony

Windows Troubleshooting Platform

Windows Troubleshooting Platform (WTP) to zespół elementów składających się na rozwiązanie, które umożliwia użytkownikom pokonywanie problemów systemowych bez kontaktowania się z działem wsparcia, tylko dzięki zastosowaniu tzw. paczek, graficznych kreatorów, które korzystają ze skryptów powłoki PowerShell. W systemie już po instalacji jest około 20 paczek, które rozwiązują prawie 100 problemów. WTP pozwala zautomatyzować proces usuwania usterek – użytkownik uruchamia kreator, paczkę, która wykorzystuje skrypty PowerShell wykrywające i diagnozujące problem, a następnie proponujące rozwiązanie i wreszcie likwidujące usterkę. Platforma jest w pełni rozszerzalna, można nie tylko wykorzystywać standardowe paczki, ale tworzyć własne. Służy do tego narzędzie Windows Troubleshooting Pack Designer znajdujące się w zestawie Windows Software Development Kit, które wykorzystując interfejs, ułatwia proces tworzenia, umożliwia opisanie nowego kreatora oraz integruje się z edytorem PowerShell Integrated Scripting Environment.

Aby uzyskać dostęp do standardowych paczek, należy uruchomić Action Center, a następnie wskazać Troubleshooting. Otworzy się okno, w którym zaprezentowanych jest pięć głównych kategorii tematycznych, co widać na zrzucie ekranu:

Rysunek 4: Pięć głównych kategorii tematycznych.

Firma Microsoft oferuje usługę Windows Online Troubleshooting, która w trybie online wyszukuje nowe paczki do rozwiązywania problemów i aktualizuje listę, jeżeli je odnajdzie. Aby wyświetlić pełną listę paczek, trzeba wybrać łącze View all znajdujące się w lewym panelu (program sprawdzi czy dostępne są nowe kreatory w trybie online). Jeżeli w środowisku wymaga się, aby paczki były dostarczane tylko z innych działów firmy, zaleca się wyłączenie dostępu do usługi Windows Online Troubleshooting. Dokonamy tego, konfigurując politykę zaprezentowaną na zrzucie ekranu:

Rysunek 5: Wyłączenie dostępu do usługi Windows Online Troubleshooting.

Polityka znajduje się w **Computer Configuration – Administrative Templates – System – Troubleshooting and Diagnostics – Scripted Diagnostics –**Troubleshooting: Allow users to access online troubleshooting content on Microsoft servers from the Troubleshooting Control Panel (via the Windows Online Troubleshooting Service – WOTS).

Do początku strony

Dlaczego warto się zainteresować WTP?

Windows Troubleshooting Platform dzięki ogromnym możliwościom ma szansę zrewolucjonizować podejście do rozwiązywania problemów, szczególnie w firmach, które nie opracowały własnego zautomatyzowanego procesu troubleshootingu.

Najbardziej potrzebne elementy: wsparcie, przykładowe paczki, wcześniej omówiona usługa Windows Online Troubleshooting, już są w systemie – to jego pierwsza zaleta. Kolejną jest możliwość opracowywania własnych paczek, gdyż w zestawie Software Development Kit (SDK) dla Windows 7 udostępniono aplikację Windows Troubleshooting Pack Designer zapewniającą tworzenie niestandardowych paczek. To graficzne narzędzie ułatwiające budowanie paczek, przeznaczone dla administratorów i programistów znających powłokę skryptową PowerShell.

Trzecim atutem jest bezpieczeństwo platformy. Nie należy się obawiać Windows Troubleshooting Platform, jako kolejnej płaszczyzny, która może się stać celem ataków. Każda paczka jest sygnowana podpisem cyfrowym wydawcy sprawdzanym przed uruchomieniem za pomocą potęgi zasad grupy – jeżeli jest zaufany będzie można z niej skorzystać, jeżeli nie –operacja otwarcia paczki zostanie natychmiast przerwana. Konfiguracja tej funkcji odbywa się przez włączenie poniższej polityki zasad grupy:

Rysunek 6: Konfiguracja bezpieczeństwa.

Znajduje się ona w węźle konfiguracji komputera, w Administrative Templates – System – Troubleshooting and Diagnostics – Scripted Diagnostics – Configure Security Policy for Scripted Diagnostics.

I ostatni powód, dla którego warto zainteresować się Windows Troubleshooting Platform: korzystanie z możliwości platformy jest łatwe. Zarówno dla użytkownika, który uruchamia paczkę, jak i dla tego, który będzie ją budował i wdrażał. Interfejs jest jednolity, łącza do paczek dodano do tematów systemowej pomocy, stworzono specjalne centrum rozwiązywania problemów w Panelu Sterowania, paczki zostały opisane w taki sposób, aby były łatwo dostępne również na pasku wyszukiwania w menu Start. Również osoby, które znają podstawy PowerShell, powinny docenić prostotę obsługi WTP. Stworzenie własnej paczki nie wymaga szczególnego nakładu pracy (dzięki Windows Troubleshooting Pack Designer) ani wiedzy w zakresie pisania skryptów. O łatwości korzystania z Windows Troubleshooting Platform świadczy też sposób wdrażania paczek. Są one w rzeczywistości plikami .diagcab, które szybko mogą zostać przekazane do stacji docelowych, np. przez mechanizm preferencji zasad grupy. Dział pomocy technicznej powinien również pomyśleć o utworzeniu witryny intranetowej, na której umieszczane będą Troubleshooting Packs.

Jeżeli w naszym przedsiębiorstwie została wdrożona autorska metoda rozwiązywania problemów, a zechcemy zrezygnować z benefitów oferowanych przez Windows Troubleshooting Platform, musimy sięgnąć do polityki znajdującej się w węźle Computer Configuration – Administrative Templates – System – Troubleshooting and Diagnostics – Scripted Diagnostics – Troubleshooting: Allow users to access and run Troubleshooting Wizards, której włączenie uniemożliwi użytkownikom uruchamianie plików .diagcab oraz dostęp do odpowiedniego zestawu narzędzi w Panelu Sterowania.

Do początku strony

Elementy architektury WTP

Windows Troubleshooting Platform to zaawansowana platforma opracowana z myślą o automatyzacji segmentu działań IT nazywanego rozwiązywaniem problemów. Aby przedstawić architekturę platformy, należałoby posłużyć się złożonym schematem oraz równie skomplikowanym opisem jego elementów. Ponieważ specjalistów IT szczególnie interesują elementy składające się na funkcjonalną sferę technologii, przyjmiemy schemat opisu, który będzie opierał się na konkretnym elemencie, nie zaś na architekturze w powszechnym rozumieniu tego słowa.

Pierwszym, absolutnie najważniejszym elementem jest paczka służąca do rozwiązywania problemów, która błędnie bywa nazywana kreatorem do rozwiązywania problemów (o którym dalej). Troubleshooting Pack to zbiór skryptów PowerShell oraz metadanych w formacie XML (tzw. manifest). W każdej paczce muszą się znaleźć minimum trzy rodzaje skryptów PowerShell (rodzaje skryptów charakteryzują konkretny etap działania). Pierwszy rodzaj to skrypty wykrywające konfiguracje uznane za główny problem (w celu jego rozwiązania została napisana paczka). Paczka do rozwiązywania problemów może być przeznaczona nie tylko dla jednego rodzaju problemów, ale również dla zbioru problemów w danym rozwiązaniu bądź funkcji. W tym przypadku dla każdego „głównego” problemu musi zostać napisany osobny skrypt weryfikujący. Gdy dany problem zostanie wykryty, do akcji wchodzą skrypty rozwiązujące, odpowiedzialne za dostosowanie konfiguracji do wzorcowej, określonej przez autora paczki. Skrypty rozwiązujące mogą również być wykorzystywane do prezentowania użytkownikowi instrukcji zawierającej kroki, które musi wykonać, aby rozwiązać problem. Ostatnim rodzajem są skrypty weryfikujące, które sprawdzają, czy oczekiwana konfiguracja została zastosowana i wygląda na zgodną z oczekiwaniami (są opcjonalne, ich obecność nie jest wymagana, aby zamknąć proces opracowywania paczki). Jak można było się na podstawie wcześniejszego opisu domyślić, Windows Troubleshooting Platform zapewnia tworzenie i wdrażanie własnych paczek.

Do uruchamiania skryptów służy silnik Windows Troubleshooting Platform, lecz następuje ono w utworzonym środowisku wykonawczym PowerShell, nawiasem mówiąc działającym w osobnym procesie. Silnik to drugi element platformy – odpowiada za całą komunikację między systemem a użytkownikiem. Do środowiska uruchomieniowego PowerShell przypisany jest zbiór czterech cmdletów związanych z poprawnością funkcjonowania paczki.

Ostatnim elementem paczki jest interfejs do rozwiązywania problemów. Może to być interfejs graficzny, jednolity dla wszystkich paczek, co gwarantuje platforma. Ma on za zadanie wyświetlenie informacji o paczce (nazwy, opisu, wydawcy) na podstawie manifestu, później zaś utrzymanie komunikacji między użytkownikiem a silnikiem WTP i finalnie skryptami (z których zwracane są opisy i wyniki działania skryptów). Kolejnym interfejsem jest PowerShell, w którym możemy wyszukiwać/uruchamiać i testować paczki. W tym celu opracowano specjalne cmdlety umożliwiające wykonywanie paczek oraz udzielanie dostępu do dodatkowych opcji, np. tworzenia plików odpowiedzi dla zautomatyzowanych uruchomień Troubleshooting Pack na komputerach zdalnych.

Po zakończeniu działania paczki do rozwiązywania problemów tworzone są dwa rodzaje raportów: podstawowy (zawierający dane o wykonanych działaniach, w tym, co zostało wykryte i naprawione) oraz raport analizy (z danymi z raportu podstawowego oraz dodatkowymi informacjami przydatnymi programistom). Aby uzyskać dostęp do raportu podstawowego, w oknie paczki, po zakończeniu czynności naprawczych, należy wskazać opcję View detailed information, która wygeneruje raport.

Rysunek 7: Generowanie raportu.

Jeżeli oczekujemy dodatkowych informacji, sięgamy po raport analizy. W tym celu przechodzimy do Panelu Sterowania, następnie do zakładki Troubleshooting i w lewym panelu wybieramy opcję View history. Jeżeli paczka, której używaliśmy, wymagała rozszerzonych uprawnień, musimy wskazać opcję Include troubleshooters that were run as an administrator. Później z listy elementów wybieramy szukaną paczkę, a z menu kontekstowego – Open file location. W wyświetlonym oknie Eksplolatora Windows wskazujemy raport, który nas interesuje (ze słowem debugreport w nazwie pliku).

Do początku strony

Uruchamianie paczek przez PowerShell i linię komend

Mimo że zapewne większość przypadków uruchamiania paczek zostanie dokonanych przez interfejs graficzny, należy przyjrzeć się sposobom wykorzystania w tym celu powłoki skryptowej PowerShell. Firma Microsoft zapewniła odpowiednie cmdlety: Get-troubleshootingpack oraz Invoke-troubleshootingpack, które będą podstawą działań administratorów.

Jak wcześniej zaznaczono, paczki można uruchamiać bezpośrednio z linii komend za pomocą narzędzia Microsoft Support Diagnostic Tool (MSDT.exe). Ma ono dwie zasadnicze opcje: –path (wskazanie folderu zawierającego paczkę) oraz –cab (wskazanie konkretnego pliku CAB paczki). Na przykład uruchomienie Troubleshooting Pack dla interfejsu Aero nastąpi w wyniku zastosowania tego oto polecenia:

Rysunek 8: Uruchomienie Troubleshooting Pack dla interfejsu Aero.

Ponieważ funkcje MSDT.exe ograniczają się do uruchamiania paczek, na tym zakończymy opis tego narzędzia.

Nim zaczniemy poznawać Windows Troubleshooting Pack, musimy zaimportować moduł, stosując polecenie import-module troubleshootingpack.

Uwaga! Należy uruchomić powłokę skryptową PowerShell w kontekście rozszerzonych uprawnień, inaczej wykonywanie paczek nie będzie możliwe.

Pierwszym istotnym cmdletem jest Get-troubleshootingpack, który stosuje się do uzyskiwania informacji o danej paczce. Zapewnia on również tworzenie plików odpowiedzi, które można później wykorzystać do zautomatyzowanego uruchamiania paczek, np. na zdalnych stacjach. Wszystkie standardowo dostępne paczki znajdują się w folderze Systemroot\Diagnostics\System. Skorzystamy z cmdletu Get-childitem do wylistowania wszystkich katalogów z paczkami:

Rysunek 9: Wylistowanie wszystkich katalogów z paczkami.

Następnie odwołamy się do preferowanego troubleshhotingpack, tym razem stosując zapowiedziany Get-troubleshootingpack:

Rysunek 10: Preferowany troubleshhotingpack.

Wykonanie tego polecenia spowoduje wyświetlenie podstawowych informacji o paczce. Aby uruchomić ją w trybie PowerShell, trzeba odwołać się do cmdletu invoke-troubleshootingpack w następujący sposób:

Rysunek 11: Wyświetlenie podstawowych informacji o paczce - polecenie.

Rysunek 12: Wyświetlenie podstawowych informacji o paczce - wynik polecenia.

W efekcie nastąpi wykonanie tych samych zadań, które pojawiłyby się w trybie interfejsu graficznego.

Get-troubleshootingpack umożliwia tworzenie plików odpowiedzi xml. Aby taki plik utworzyć dla danej paczki, należy użyć polecenia:

Rysunek 13: Utworzenie pliku odpowiedzi xml.

Następnie administrator musi odpowiedzieć na serię pytań, które zostaną zachowane w pliku odpowiedzi zapisanym w określonej lokalizacji.

Rysunek 14: Seria pytań.

W jednym z podanych przykładów wykorzystaliśmy cmdlet invoke-troubleshootingpack, który odpowiada za inicjację paczki i udostępnia funkcję podpinania pliku odpowiedzi oraz generowania zestawu raportów we wskazanym przez administratora miejscu.

Dla tego przykładu stworzymy zmienną $audio, która będzie odwołaniem do Get-troubleshootingpack –path C:\Windows\Diagnostics\System\Audio. Następnie należy odszukać lokalizację, w której zapisany został plik odpowiedzi dla tej paczki, i umieścić ją w składni następującego polecenia:

Rysunek 15: Stworzenie zmiennej $audio.

W składni użyliśmy dodatkowych dwóch opcji: –unattend oraz –result. Pierwsza wymusza na cmdlecie invoke-troubleshootingpack działanie w trybie nienadzorowanym (w oparciu o wskazany plik odpowiedzi), druga opcja wskazuje miejsce, w którym zostaną zapisane raporty.

Do początku strony

Czas na start, czyli szybki kurs tworzenia paczki

Aby rozpocząć tworzenie własnej paczki, należy ze stron Centrum Pobierania Microsoft uzyskać Software Development Kit (SDK) dla Windows 7, w którego skład wchodzi narzędzie Windows Troubleshooting Pack Designer przeznaczone do tworzenia własnych, niestandardowych rozwiązań wykorzystujących potencjał Windows Troubleshooting Platform.

Po pobraniu i instalacji zestawu SDK dłuższą chwilę należy poświęcić na przemyślenie struktury paczki. Musimy odpowiedzieć na kilka pytań: jaki jest główny problem? jak wygląda lista głównych problemów? co powinny robić skrypty? ile skryptów potrzebujemy? jak napisać te skrypty? Trzeba poznać schemat działania każdej paczki:

Rysunek 16: Schemat działania każdej paczki.

Dla każdego etapu trzeba opracować osobne skrypty – pierwszy będzie sprawdzał występowanie problemu (bądź kilku problemów głównych), drugi – usuwał problem (bądź kilka) wykryty na pierwszym etapie. Oczywiście może istnieć kilka skryptów rozwiązujących jeden, główny problem. Ostatnim skryptem będzie ten sprawdzający, czy problem już nie występuje. Po zakończeniu tworzenia skryptów zalecane jest ponowne zbudowanie planowanej struktury paczki. Takie działanie pozwoli wybrać odpowiednią nazwę dla paczki, co jest istotne szczególnie dla użytkownika końcowego.

Dla przykładu stworzymy paczkę, która będzie sprawdzać, czy w systemie działa usługa Desktop Window Manager Session Manager, podstawa funkcjonowania interfejsu Aero. Dodamy również funkcję, która umożliwi wykrycie, czy działa usługa Themes. Do dzieła!

	1. Uruchamiamy narzędzie Windows Troubleshooting Pack Designer (Start – All programs – Microsoft Windows SDK v.7.0 – Tools – Windows Troubleshooting Pack Designer). Rysunek 17: Windows Troubleshooting Pack Designer.
	2. Tworzymy nowy projekt przez Project – New. Nadajemy nazwę paczce i wskazujemy preferowaną lokalizację zapisu. Rysunek 18: Nowy projekt.
	3. W oknie Complete the projects properties wpisujemy nazwę i opis projektu oraz dodajemy link do naszej polityki zachowania prywatności bądź witryny firmy. Rysunek 19: Okno "Complete the projects properties".
	4. W lewym panelu klikamy na łącze Add New Root Cause w celu dodania głównego problemu.
	5. Dodajemy ID (które będziemy wykorzystywać w skryptach), nazwę oraz opis głównego problemu. Rysunek 20: Sekcja "Root Cause".
	6. Klikamy na opcję Next. W nowym oknie określamy, czy wymagane jest rozszerzenie uprawnień oraz interakcja z użytkownikiem uruchamiającym paczkę (w przykładowym scenariuszu będzie to Yes w pierwszym przypadku oraz No w drugim). Rysunek 21: Sekcja "Troubleshooter".
	7. W kolejnym etapie podajemy dane przypisane do etapu rozwiązania problemu – nazwę i opis problemu oraz dodatkowe opcje związane ze skryptem. Rysunek 22: Sekcja "Resolver".
	8. Na kolejnej stronie decydujemy, że nie chcemy używać skryptu weryfikującego. Następnie przechodzimy do edycji skryptów: wykrywającego i naprawiającego (opcje Edit (...), które uruchomią środowisko PowerShell ISE).
	9. Dodajemy kolejną przyczynę główną problemu, dla którego budujemy kreator, tym razem związany z usługą Themes (Actions – Add New Root Cause). Powtarzamy wszystkie kroki, odpowiednio zmieniając nazwę usługi. Drzewo projektu powinno wyglądać tak: Rysunek 23: Project Explorer.
	10. Po zakończeniu opracowywania etapów wykonywania paczki możemy przystąpić do kompilacji (Build – Build Pack). Nastąpi opracowanie przez program pliku paczki, pojawi się również komunikat z informacją o konieczności zastosowania podpisu cyfrowego. Klikamy OK, aby wygenerować przykładowy, testowy podpis. Rysunek 24: Instalowanie certyfikatu.
	11. Po chwili pojawi się komunikat z informacją o pozytywnym zakończeniu pracy nad paczką. Możemy ją uruchomić, wykorzystując łącze Launch Troubleshooting Pack. Po chwili paczka zostanie uruchomiona. Pozostaje ją przetestować! Rysunek 25: Uruchomienie paczki. Paczka jest gotowa do działania. Aby zobaczyć listę wyjątków, które zostały zarejestrowane podczas jej działania, trzeba sięgnąć do raportu analizy (zgodnie z instrukcjami przedstawionymi wcześniej).

Do początku strony

Garść uwag końcowych

Windows 7 wprowadza wiele nowych funkcji w wielu aspektach i dziedzinach systemu operacyjnego. Problem Steps Recorder oraz Windows Troubleshooting Platform to te dwie, które powinny szczególnie zainteresować pracowników działów pomocy technicznej. Z pewnością docenią oni wpływ tych technik na jakość i wygodę wykonywania codziennych obowiązków. Problem Steps Recorder umożliwa użytkownikowi zarejestrowanie zestawu zrzutów ekranu składających się na opis problemu w imię zasady „jeden obraz – tysiąc słów”. Windows Troubleshooting Platform to zaawansowane rozwiązanie, które wykorzystuje potęgę powłoki skryptowej PowerShell. Dzięki opracowaniu, wdrożeniu i stosowaniu tzw. paczek do rozwiązywania problemów współczesne przedsiębiorstwo ma szansę zdecydowanie zmniejszyć liczbę żądań kierowanych do działów Help Desk.

Łukasz Foks (MCTS, MCITP) Pasjonat technologii Microsoft. W swoim portfolio posiada kilkadziesiąt artykułów i porad technicznych związanych z systemami Microsoft Windows. Zastępca redaktora naczelnego największego portalu technicznego o serwerowych rozwiązaniach Microsoft - http://wss.pl, z którym związany jest już od kilku lat. Aktywnie udziela się również prowadząc liczne prezentacje oraz wspierając Warszawską Grupę Użytkowników i Specjalistów Windows od początku jej istnienia, będąc współtwórcą tej grupy. Szczególnie preferowanymi obszarami tematycznymi są Windows Desktop Experience oraz Windows Deployment.

Do początku strony

---