Application Compatibility Toolkit 5.5 od środka

Autor: Chris Corio i Chris Jackson

Opublikowano: 14 października 2009

Zawartość strony

	Application Compatibility Manager
	Narzędzia oceny zgodności
	Baza danych ACT
	Synchronizacja online
	Standard User Analyzer
	Interfejs użytkownika Standard User Analyzer
	Internet Explorer Compatibility Test Tool
	Podsumowanie

 

Narzędzia Application Compatibility Toolkit (ACT) ułatwiają ustalanie, czy używane aplikacje są zgodne z nową wersją systemu Windows przed jej wdrożeniem. Mogą też pomóc w określeniu, jak aktualizacja systemu operacyjnego wpłynie na te aplikacje. Istnieje już wiele artykułów i dokumentów technicznych na temat korzystania z ACT 5.5. W tym artykule chcemy sięgnąć głębiej i przeanalizować sposób działania każdego z tych narzędzi. Rozpoczniemy od tego, które większość użytkowników najlepiej kojarzy z tym zestawem: Application Compatibility Manager.

Application Compatibility Manager

Narzędzie Application Compatibility Manager udostępnia ramy dla gromadzenia informacji na temat środowiska produkcyjnego, porządkuje analizę danych i pomaga w sterowaniu procesem testowania. Przyjrzyjmy się temu narzędziu, aby lepiej zrozumieć jego działanie.

Pakiety wdrożenia testowego (MSI) Pakiety zbierania danych ACT 5.5 są rozpowszechniane jako pliki MSI, jeśli jednak wnikliwie przeanalizujemy MSI, odkryjemy, że w rzeczywistości plik ten nie wykonuje zbyt wiele pracy. Zamiast tego wypakowuje plik wykonywalny, który realizuje instalację. Rysunek 1 ukazuje drzewo procesów dla typowego przebiegu instalacji.

Rysunek 1: Drzewo instalacji Agent Framework.

Trzecie wystąpienie msiexec.exe, pokazane kolorem czerwonym, jest tym, na które chcemy zwrócić uwagę: jest wywoływane w celu odinstalowania oryginalnego MSI. Zasadniczo MSI wypakowuje plik .exe (pokazany jako plik .tmp), po czym odinstalowuje zewnętrzny MSI. Później instalowany jest drugi MSI (wywoływany przez msiexec). W jednym z testów wdrożeniowy MSI zakończył instalowanie o 1:19:46, zaś odinstalował się o 1:19:50. Tak więc MSI ukazuje się jako zainstalowany przez zaledwie cztery sekundy! W konsekwencji podczas rozpowszechniania pakietów zbierania danych nie ma sensu sprawdzać instalacji MSI w celu ustalenia, czy należy zainstalować go na komputerze docelowym, gdyż najprawdopodobniej go nie znajdziemy. Trzeba szukać innych dowodów, że dysponujemy zainstalowanymi agentami na każdej stacji roboczej.

Na przykład, choć rozpowszechniany MSI będzie miał nowo wygenerowany kod produktu za każdym razem, wewnętrzny MSI zawsze będzie miał ten sam kod (DC93B45B-D4F5-4FFE-9B47-042BD6FA8CC5) i można użyć tego faktu jako dowodu, że pakiet zbierania danych został zainstalowany (jakkolwiek nie będzie można sprawdzić który, gdyż wszystkie pakiety zbierania danych ACT zostawiają ten ślad). Zauważmy, że nie jest zalecane odinstalowywanie pakietu gromadzenia danych przy użyciu tego wpisu MSI; zalecaną metodę usuwania pakietu gromadzenia danych ACT omówimy w kolejnej części artykułu.

Afsetup.exe wykonuje większość pracy i trzeba zwrócić uwagę na ten element na wypadek wystąpienia jakichkolwiek problemów podczas wdrażania agenta. Usunięcie Agent Framework umożliwia polecenie:

%program files%\Microsoft Agent Framework\Agent Framework\afsetup.exe /uninstall

Agent Framework ACT 5.5 Agent Framework udostępnia strukturę zbierania danych z wielkich zbiorów komputerów w całym przedsiębiorstwie. Główny cel agenta to bycie niezauważalnym i nadającym się do rozpowszechnienia w środowisku produkcyjnym. W rezultacie działanie poszczególnych agentów zostało starannie zoptymalizowane pod kątem wydajności (co można dostrzec w niektórych decyzjach projektowych podjętych podczas ich tworzenia).

Sama struktura jest bardzo prosta. Po zainstalowaniu Agent Framework można znaleźć jego pliki w katalogu %program files%\Microsoft Agent Framework. Uruchamiany jest jako usługa (actdcsvc.exe), co pozwala na zaplanowanie uruchamiania agentów. Plik XML zlokalizowany w podkatalogu Agent Framework\Data konfiguruje uruchamianie agentów zgodnie z określonym harmonogramem. Pliki wykonywalne agentów znajdują się w podkatalogu Agent Framework\Agents.

Agenci nie są niczym innym niż wykonywalnymi plikami – usługa Agent Framework po prostu zarządza harmonogramem i uruchamia odpowiednie pliki wykonywalne zgodnie z ustawieniami zawartymi w instalacji i konfiguracyjnym XML. Rysunek 2 ukazuje przykładowe drzewo procesów dla pierwszych pięciu minut działania typowej instalacji Agent Framework.

Rysunek 2: Drzewo procesów Agent Framework.

Tak więc, mamy do czynienia z prostą usługą, która tylko steruje harmonogramem i uruchamia agentów. To oni wykonują zasadniczą pracę, zatem przyjrzyjmy się im bliżej.

ACT 5.5 Inventory Agent, collect.exe, jest jednym z najważniejszych. Mówiąc w skrócie, agent ten przeszukuje systemy klienckie i kompiluje spis aplikacji. Z punktu widzenia danych wymaganych dla planowania projektu zgodności aplikacji (nazwa aplikacji wraz z nazwą producenta, wersją i wreszcie informacjami o wsparciu) Inventory Agent działa doskonale w porównaniu z innymi narzędziami rejestrowania oprogramowania.

To, co jeszcze szczególnie pomocne, to nie jak dobrze agent przeszukuje system w poszukiwaniu śladów aplikacji (co omówimy dalej), ale jak skutecznie następnie czyści te dane przed ich przekazaniem dalej. Narzędzie tworzy szereg „kubełków”, po czym konsoliduje wszystkie dowody odkryte podczas przeszukiwania, usuwa duplikaty, spłaszcza strukturę i kategoryzuje informacje. Agent wyszukuje ślady w licznych lokalizacjach w celu wyszukania zainstalowanych aplikacji.

Przeszukiwanie MSI Database wykorzystuje składnik MsiEnumComponents API do wyliczenia wszystkich aplikacji zainstalowanych przy użyciu Windows Installer.

Przeszukiwanie programów z listy dodaj/usuń otwiera obydwa klucze HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Uninstall oraz HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\Uninstall i gromadzi dane ze wszystkich zawartych w nich podkluczy.

Przeszukiwanie Windows Shell wykonywane jest poprzez wyliczenie zawartości klucza HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders, a także HKEY_USERS\<…>\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders dla każdego użytkownika posiadającego profil na danym komputerze. Następnie agent wyszukuje wszystkie pliki i łącza zawarte w tych katalogach i ich podkatalogach (jednak pomijając pulpit, który u wielu użytkowników jest „miejscem parkingowym” dla plików wykonywalnych, pobieranych z sieci Web, aby zmniejszyć zbędny „szum”). Takie wyszukiwanie pozwala zlokalizować oprogramowanie, które na przykład nie zarejestrowało się w menu Add/Remove Programs, ale utworzyło skrót w menu Start.

Przeszukiwanie ścieżek aplikacji wylicza wszystkie podklucze zawarte w kluczu rejestru HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths, odnajdując wszystkie aplikacje, które zarejestrowały się w celu uzyskania specyficznej dla programu ścieżki aplikacji.

Przeszukiwanie zmiennej środowiskowej path wyszukuje pliki wykonywalne zawarte w każdym katalogu (ale nie w ich podkatalogach) wskazywane przez zmienne dowolnego użytkownika. Najpierw wyszukiwane są pliki wykonywalne zlokalizowane w ścieżkach zwracanych przez wywołanie ExpandEnvironmentStrings (które zwraca zarówno systemowe zmienne środowiskowe, jak i zmienne bieżącego użytkownika), a następnie przeglądana jest zawartość kluczy HKEY_USERS\<…>\Environment dla wszystkich innych użytkowników. Pozwala to narzędziu gromadzącemu informacje odnaleźć aplikacje (zazwyczaj programy trybu wiersza polecenia) zainstalowane poprzez zwykłe umieszczenie pliku w systemie plików i następnie dodanie ścieżki do zmiennej środowiskowej path.

Przeszukiwanie obsługi rozszerzeń plików sprawdza każde zarejestrowane rozszerzenie nazwy pliku i przechwytuje programy zarejestrowane do obsługi tych rozszerzeń. Narzędzie najpierw otwiera klucz HKEY_LOCAL_MACHINE\Software\Classes i wylicza wszystkie wpisy, które rozpoczynają się od kropki (.), jako że są to rozszerzenia nazw plików. Dla każdego odnalezionego wpisu agent wylicza identyfikatory programów i lokalizuje podklucze shell\open\command dla każdego z nich, aby znaleźć pliki wykonywalne. Następnie wykonuje tę samą pracę dla każdego użytkownika, wyliczając zawartość klucza HKEY_USERS\<…>\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts. Takie działanie pozwala agentowi znaleźć program, w którego przypadku instalacja polegała jedynie na skopiowaniu binariów i rejestracji jako obsługi dla wybranego rozszerzenia plików.

Przeszukiwanie kluczy run/runonce sprawdza zawartość następujących kluczy rejestru w celu zlokalizowania plików wykonywalnych, które mogą reprezentować aplikacje:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVerison\RunOnceEx

Zbadanie tych kluczy rejestru pozwala agentowi znaleźć oprogramowanie, uruchamiane przy każdym starcie systemu, ale może nie zostawiać innych śladów, które program zbierający dane mógłby znaleźć.

Przeszukiwanie Service Control Manager odpytuje najpierw Service Control Manager (przy użyciu EnumServiceStatus API), a następnie każdą usługę w poszukiwaniu szczegółów (przy użyciu QueryServiceConfig API). Tą metodą agent może znaleźć oprogramowanie, którego instalator ręcznie umieścił pliki wykonywalne gdzieś w systemie plików i ustawił klucze w celu zarejestrowania usługi.

Przeszukiwanie Windows Components sprawdza występowanie opcjonalnych komponentów instalowanych z systemem Windows w celu przechwycenia także tych aplikacji. Agent wykonuje to poprzez odczytanie sysocmgr.inf (w katalogu %windir%\inf) i wyliczenie wybranych komponentów opcjonalnych. Pozwala to na odnalezienie oprogramowania, które zwykle nie występuje w standardowej instalacji Windows.

 Do początku strony

Narzędzia oceny zgodności

Wprawdzie znajomość oprogramowania, które jest zainstalowane na komputerach w całym przedsiębiorstwie jest zwykle najistotniejszą rzeczą przy realizacji projektu sprawdzania zgodności, jednak Agent Framework umożliwia również uzyskanie dodatkowych danych z komputerów, na których agenci zostali zainstalowani. Agenci oceny zgodności (compatibility evaluator) dołączeni do ACT zostali zoptymalizowani pod kątem wydajności w celu możliwości ich stosowania w środowisku produkcyjnym i w związku z tym gromadzą ograniczoną liczbę danych. Warto przejrzeć zgromadzone informacje i przeprowadzić dowód poprawności, aby ocenić wartość danych, zanim zainwestuje się w masowe wdrożenie narzędzi oceny zgodności.

UAC Compatibility Evaluator Agent UAC Compatibility Evaluator (uacce.exe) instaluje niestandardową bazę danych podkładek (uacce.sdb) oraz niestandardowe podkładki (uacdetct.dll) w celu ustalenia, czy aplikacja może być uruchamiana w trybie standardowego użytkownika (lub w trybie chronionym administratora) w systemach Windows Vista lub Windows 7 (podkładki (shims) stanowią niewielkie cząstki kodu aplikacji wstawiane pomiędzy aplikację a system Windows i służą zazwyczaj do rozwiązywania problemów zgodności, ale w tym wypadku wykorzystywane są do wykrywania takich problemów). Podkładki te są stosowane do procesów uruchomionych w systemie poprzez ustawienie warstwy zgodności dla explorer.exe; zmienna środowiskowa COMPAT_LAYER jest modyfikowana, aby zawierała UACCEDetection, warstwę zdefiniowaną w niestandardowej bazie SDB. Ponieważ procesy potomne dziedziczą warstwy, każdy proces utworzony przy użyciu Explorera będzie miał zastosowane te podkładki.

Co robią te podkładki? Podkładka FileOperations przechwytuje wywołania do API lcreat, CopyFile, CopyFileEx, CreateFile, DeleteFile, MoveFile, MoveFileEx, MoveFileWithProgress, ReplaceFile, LZOpenFile, EncryptFile, DecryptFile oraz DuplicateEncryptionInfoFile. Dla każdego wywołania sprawdza, czy ACL ogranicza dostęp lub czy plik znajduje się w specjalnej ścieżce (na wypadek, gdyby złagodzono listy kontroli dostępu).

Sprawdzenie ACL jest wykonywane poprzez przejęcie istniejącej ACL, usunięcie wpisów i przywilejów administracyjnych, po czym przez wywołanie AccessCheck wobec zasobu w celu ustalenia, czy powiedzie się ono dla użytkownika niebędącego administratorem. Sprawdzenie ścieżek specjalnych ustala, czy ścieżka jest katalogiem głównym lub jednym z katalogów %program files%, %system% lub %windows%. Wszystkie niepowodzenia są rejestrowane.

Podkładka RegistryOperations przechwytuje wywołania API RegCreateKey, RegCreateKeyEx, RegDeleteKey, RegDeleteKeyEx, RegDeleteValue, RegOpenCurrentUser, RegOpenKey, RegOpenKeyEx, RegCloseKey, RegOpenUserClassesRoot, RegReplaceKey, RegRestoreKey, RegSetValue, RegSetValueEx oraz RegUnloadKey. Dla każdego wywołania do przechwyconego API podkładka sprawdza, czy ACL odmówi dostępu standardowemu użytkownikowi. Technika sprawdzenia ACL jest identyczna jak używana przy operacjach na plikach – poprzez „obcięcie” żetonu dostępu i wywołanie AccessCheck. Niepowodzenia są rejestrowane.

Podkładka ProfileOperations przechwytuje wywołania API WritePrivateProfileSection, WritePrivateProfileString, WritePrivateProfileStruct, WriteProfileSection oraz WriteProfileString. Dla każdego wywołania podkładka sprawdza, czy plik inicjujący jest zamapowany przy użyciu mechanizmu mapowania. Jeśli nie, podkładka weryfikuje uprawnienia wobec pliku tak samo jak podkładka FileOperations (gdyż niemapowany plik ini jest taki sam jak każdy inny plik), przy czym niepowodzenia są rejestrowane.

Podkładka RestrictedNamespace przechwytuje wywołania do API CreateFileMapping. Jeśli nazwa obiektu zawiera przestrzeń nazw Global\ albo Session\, rejestrowane jest niepowodzenie.

Podkładka ElevatedRunLevel przechwytuje wywołania do API CreateProcess, CreateProcessAsUser, CreateProcessWithLogon oraz CreateProcessWithToken. Wszystkie przechwycone API sprawdzają docelowy plik wykonywalny w celu skontrolowania, czy funkcja wykrywania instalacji Windows wyzwoli zdarzenie podniesienia uprawnień (co zwraca ERROR_ELEVATION_REQUIRED przy korzystaniu z API CreateProcess). Ponadto podkładka sprawdza tożsamości elementów docelowych dla tych API, które zmieniają poświadczenia użytkownika w celu ustalenia, czy są to konta administracyjne.

Jeśli przyjrzymy się uważnie, jak działa mechanizm wykrywania, zauważymy, że przyjęto założenie, że użytkownik korzysta z podniesionych uprawnień w trakcie pracy agentów. Ponieważ agenci zostali zaprojektowani do działania w systemach produkcyjnych, można założyć, że aplikacja już została uruchomiona. Jeśli zaś działa i mogłyby się pojawić problemy z mechanizmem kontroli dostępu użytkownika (UAC), prawdopodobnie została uruchomiona przez administratora!

Windows Vista/Windows 7 Compatibility Evaluator Agent Windows Vista/Windows 7 Compatibility Evaluator jest w rzeczywistości podzielony na dwa oddzielne pliki wykonywalne, gdyż jedna część pracy może zostać zrealizowana statycznie, zaś druga wymaga monitorowania i analizy podczas działania.

Agent GINA Session 0 (ginasession0.exe) wykonuje proste sprawdzenie rejestru. Przegląda klucz HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL w celu sprawdzenia, czy na komputerze zainstalowano niestandardową wersję GINA. Ponadto wylicza usługi, wyszukując w rejestrze wartość typu w celu sprawdzenia, czy ustawiony jest bit 0x100 (flaga SERVICE_INTERACTIVE_PROCESS). Wszystkie niepowodzenia są rejestrowane.

Podobnie jak UAC Compatibility Evaluator, Deprecation Agent (dep.exe) instaluje niestandardową bazę podkładek (dep.sdb albo win2kagents.sdb w systemie Windows 2000) oraz niestandardowe podkładki (depdetct.dll), po czym ustawia zmienną środowiskową __COMPAT_LAYER dla programu Explorer.exe, aby zawierała DeprecationAgentLayer. Gwarantuje to, że każdy proces uruchomiony poprzez Explorera zostanie przechwycony (warto zauważyć, że baza podkładek wyklucza specyficzne binaria, o których wiadomo, że ulegną awarii, gdy wykryją, że zostały przechwycone).

Czego szuka Deprecation Agent? Przyjrzyjmy się podkładkom, których używa.

Podkładka DllLoadOperations przechwytuje wywołania LoadLibrary oraz LoadLibraryEx i porównuje przekazaną nazwę biblioteki z listą odrzuconych (niekompatybilnych) plików DLL. Lista ta jest przechowywana w pliku DepManifest.csv, który można znaleźć w katalogu %program files%\Microsoft Agent Framework\Agent Framework\Agents\DEP. Używane są wpisy, które w pierwszej kolumnie mają wartość DllType.

Podkładka ExeLoadOperations przechwytuje wywołania API CreateProcess, CreateProcessAsUser, CreateProcessWithLogon, CreateProcessWithToken, ShellExecute, ShellExecuteEx oraz WinExec, sprawdzając nazwę przekazywanego pliku wykonywalnego z listą odrzuconych plików, również przechowywaną w DepManifest.csv (wpisy zawierające ExeType w pierwszej kolumnie).

Podkładka RegistryLoadOperations przechwytuje wywołania API RegCreateKey, RegCreateKeyEx, RegCloseKey, RegDeleteKey, RegDeleteKeyEx, RegDeleteValue, RegOpenCurrentUser, RegOpenKey, RegOpenKeyEx, RegOpenUserClassesRoot, RegReplaceKey, RegRestoreKey, RegSetValue, RegSetValueEx oraz RegUnloadKey, porównując nazwę przekazywanego klucz rejestru z listą przechowywaną (ponownie) w pliku DepManifest.csv – tym razem z wartością w pierwszej kolumnie wynoszącą RegType.

Podkładka ApiLoadOperations bezpośrednio maskuje określone API, które zostały odrzucone, rejestrując fakt, że aplikacja próbowała je wywołać. Dla systemu Windows Vista istnieje tylko jedno takie API: StiCreateInstanceA zawarte w sti.dll (co wiąże się z zupełnie inną historią; zobacz https://blogs.msdn.com/tomarcher/archive/2006/03/22/windows-vista-sti-and-a-story-about-customer-service.aspx.)

Ważną rzeczą, na którą należy zwrócić uwagę, jest to, że funkcjonowanie tego agenta zależy od działania na niskim poziomie: fakt, że coś zostało wywołane, zostanie zarejestrowane tylko wtedy, gdy da się to wywołać.

Update Compatibility Evaluator Agent Update Compatibility Evaluator umożliwia ustalenie, których binariów Windows używa określona aplikacja, co pozwala na bardziej precyzyjne testy podczas publikowania kolejnych aktualizacji Windows. Agent działa poprzez zainstalowanie sterownika trybu jądra (fdrtrace.sys), który implementuje pułapki systemu plików i rejestru w celu zapisywania aktywności generowanej przez aplikacje. Wykorzystuje do tego usługę (uiaservice.exe) oraz plik wykonywalny (uiaconvert.exe) do interpretowania danych i znajdowania powiązań z aplikacjami ustaleniu dostępu do binariów Windows.

Bucketizer Agent Agent Bucketizer mapuje dane zgromadzone przez agentów oceny zgodności na spis zawartości komputera w celu skategoryzowania wykrytych problemów na „kubełki”, odpowiadające poszczególnym aplikacjom.

Compressor Agent Jak można się domyślić z nazwy, celem tego agenta jest kompresowanie plików, które mają być załadowane do wskazanego udziału plikowego, w plik CAB, aby oszczędzić niezbędne pasmo sieciowe.

Uploader Agent Agent ten jest odpowiedzialny za przesyłanie danych zgromadzonych przez innych agentów do wskazanego udziału plikowego. Działanie tego agenta jest stosunkowo proste – kopiowanie danych zgromadzonych lokalnie do wskazanej lokalizacji. Jeśli lokalizacja ta jest nieosiągalna, agent odczeka pięć sekund przed ponowną próbą. W razie trzykrotnego niepowodzenia agent przerywa działanie.

Ważną nową cechą ACT 5.5 jest fakt, że pakiety danych (Data Collection Packages) mogą zostać „oznakowane” – skonfigurowane tak, że wszystkie dzienniki załadowane w określonym pakiecie danych będą miały przypisany wybrany znacznik. Pozwala to na łatwiejsze poradzenie sobie z niektórymi sytuacjami, takimi jak dogłębne zrozumienie, jakie oprogramowanie jest używane w każdej badanej grupie (wcześniej było to trudne do zmierzenia w razie nakładających się aplikacji) lub konsolidowanie danych pochodzących z wielu grup lub organizacji.

Log Processing Service Log Processing Service jest uruchamiany jako usługa (actdcsvc.exe). Jeśli nazwa ta wydaje się znajoma, to tak właśnie jest – jest to ta sama usługa ramowa, omówiona wcześniej! W tym wypadku uruchamia ona następujących agentów:

• Decompressor (decompressor.exe) – agent ten jest dopełnieniem agenta Compressor używanego na stacjach roboczych, na których gromadzone są dane; rozpakowuje pliki XML wygenerowane na klientach z plików CAB używanych do przesyłania. Po zakończeniu ekstrakcji agent nasłuchujący (Listener) wykrywa zmianę i może rozpocząć kolejną fazę.
• Agent Listener (listener.exe) monitoruje wskazany katalog pod kątem zmian. W momencie wykrycia zmiany (pojawienia się nowych plików) wysyła wywołanie RPC do agenta kolejkowania (Queuing).
• Agent Queuer (queuer.exe) ustawia porty nasłuchujące na wywołanie RPC od agenta Listener. Po odebraniu wywołania przetwarza plik i przesyła go do bazy danych. Agent przenosi następnie plik XML z głównego, nieskompresowanego folderu do folderu Processed, o ile przetwarzanie zakończyło się sukcesem. W przeciwnym wypadku pliki przenoszone są do folderu Failed. Gdy przetwarzanie dziennika się nie powiedzie, można ponownie przenieść go do głównego katalogu monitorowanego udziału, aby spróbować ponownie, i całkiem często ponowna próba się udaje.

Dość często podnoszone pytanie brzmi: czy należy przechowywać te przetworzone pliki? Ponieważ dane są już w bazie danych, technicznie rzecz biorąc nie są już potrzebne i zazwyczaj można je bezpiecznie usunąć. Jednak pliki te mogą być przydatne, jeśli zaszłaby konieczność odbudowy bazy danych albo skonsolidowania dwóch różnych baz. Warto więc rozważyć przyszłe potrzeby, zanim dane te zostaną usunięte.

 Do początku strony

Baza danych ACT

Narzędzie Application Compatibility Manager może wydawać się najbardziej magiczne, ale to baza danych ACT jest tym miejscem, w którym znajdują się wszystkie dane. Baza ta zawiera wiele tabel. Wprawdzie jej schemat nie został udokumentowany, jest jednak bardzo prosty (ale niestety ulega zmianom w każdej nowej wersji ACT ). Do ważnych tabel należą Applications, Machines, Devices oraz Issues; służą one do uporządkowania wszystkich informacji zwracanych przez poszczególnych agentów i przetworzonych przez usługę Log Processing.

Aplikacje są przypisywane do danych przy użyciu unikatowego identyfikatora (Application ID), generowanego na podstawie nazwy, wersji, producenta i języka (name, version, vendor, language – NVVL) aplikacji.

Bazę danych ACT można utrzymywać w środowisku Microsoft SQL Server 2005 lub wydaniu późniejszym, w tym w wersjach Express (SQL Server 2000 nie jest już wspierany). Application Compatibility Manager tworzy bazę danych w trakcie wstępnej fazy konfiguracyjnej (Enterprise Configuration). Skrypt służący do utworzenia bazy danych przechowywany jest w pliku %allusersprofile%\Microsoft\Application Compatibility Toolkit 5\CreateDB.sql.

Kluczowym aspektem ACM jest jego zdolność do generowania raportów. Można je tworzyć poprzez filtrowania bazy danych ACT przy użyciu kontrolki budowy kwerend w ACM, która jest wyświetlana po kliknięciu Toggle Filter. Filtrowanie może się odbywać na podstawie kryteriów odnoszących się do jednostek zawartych w bazie ACT, przy czym można łączyć warunki relacjami AND lub OR. Raport można zapisać jako plik .adq – jest to plik XML definiujący użyte filtry. Plik .adq jest przenośnym formatem, który nie zawiera danych ani nie jest zależny od określonego zbioru danych.

 Do początku strony

Synchronizacja online

Podczas wykonywania synchronizacji online ACT wykorzystuje publiczną usługę sieci Web. We wcześniejszych wersjach ACT przesyłane były unikatowe identyfikatory aplikacji całego wykorzystywanego oprogramowania, jednak teraz można ukryć wybrane dane zgodności. Przy stosowaniu ACT 5.5, jeśli zdecydujemy się nie udostępniać informacji o aplikacjach, ACT nie wysyła Application ID (co oznacza jednak również, że nie otrzymamy danych zwrotnych).

Dane społeczności pochodzą z bazy Microsoft Compatibility Exchange i zawierają dane certyfikacji logo oraz dane wspólne (głosy innych użytkowników). Odrębny system wykorzystuje witryna windows.com/compatibility, przy czym dane te pochodzą z niezależnych (ręcznych) badań stanu zgodności komercyjnie dostępnego oprogramowania. ACT 5.5 jest pierwszą wersją ACT, która również uwzględni te dane, co zapewni dostęp do znacznie większej liczby informacji o zgodności oprogramowania, niż było to wcześniej możliwe.

 Do początku strony

Standard User Analyzer

Narzędzie Standard User Analyzer (SUA) składa się z kilku plików binarnych służących do monitorowania i analizowania wykonywanych aplikacji i zgłaszania wątpliwości występujących podczas testów. Podstawowy interfejs użytkownika SUA UI pozwala określić aplikację, która ma być analizowana, a także wybrać warunki uruchamiania tej aplikacji. SUA następnie wykorzysta narzędzie Application Verifier jako platformę monitorowania aplikacji. Po wykonaniu monitorowania wykonania aplikacji SUA wyświetla zgromadzone dane w interfejsie użytkownika, gdzie użytkownik może się zapoznać z wykrytymi problemami, a nawet utworzyć pakiety naprawcze, które włączają się w infrastrukturę zgodności aplikacji systemu Windows

Application Verifier Application Verifier jest narzędziem udostępniającym projektantom metody do monitorowania wykonania aplikacji. SUA wykorzystuje Application Verifier do śledzenia zachowań aplikacji, które wymagają przywilejów administracyjnych, poprzez śledzenie wykorzystania określonych API.

Application Verifier wykorzystuje model wtyczek (podczas tworzenia tego artykułu model ów nie jest jeszcze udokumentowany do publicznego wykorzystania), w którym określone biblioteki DLL mogą zostać zarejestrowane i wykorzystane do monitorowania wskazanej apliakcji (wtyczki są konfigurowane za pośrednictwem klucza rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\{ApplicationVerifierGlobalSettings}). Biblioteka wykorzystywana przez SUA do monitorowania aplikacji to vfLuaPriv2.dll, umieszczana w katalogu %windir%\System32 podczas instalacji. Biblioteka vfLuaPriv2.dll zastępuje vfLuaPriv.dll instalowaną przez Application Verifier.

Gdy SUA uruchamia aplikację w celu przetestowania, najpierw sprawdza, czy Application Verifier jest zainstalowany w danym systemie i monituje użytkownika o wykonanie instalacji, jeśli to konieczne. Następnie SUA wykorzystuje interfejs wiersza polecenia narzędzia Application Verifier do zarejestrowania aplikacji. Na przykład, jeśli monitorowanym programem ma być notepad.exe, SUA wywoła polecenie:

appverif.exe -enable luapriv -for "notepad.exe"

Application Verifier dopasowuje ciąg „luapriv” do nazwy określonej dla vfLuaPriv2.dll.

Konfigurowanie aplikacji przez SUA powoduje również, że Application Verifier będzie monitorował każdy proce potomny utworzony przez tę aplikację. Application Verifier tworzy oddzielny plik dziennika dla każdego procesu, ale SUA łączy te pliki w pojedynczy, skonsolidowany raport. SUA umożliwia również zapisanie zbioru dzienników w pliku .cab w celu ich przeglądania na innym komputerze.

 Do początku strony

Interfejs użytkownika Standard User Analyzer

SUA może testować aplikację w jednym z trzech różnych kontekstów: uruchamiając aplikację przy użyciu żetonu bieżącego użytkownika, z tym żetonem, ale z wyłączeniem wirtualizacji plików i rejestru, albo przy podniesionych uprawnieniach. W każdym wypadku SUA uruchomi proces o podwyższonych uprawnieniach SUAnalyzerSrv.exe, gdyż Application Verifier wymaga podniesionych uprawnień do wykonania konfiguracji. Rysunek 3 ukazuje typowe drzewo procesów dla testowania programu notepad.exe.

Rysunek 3: Testowanie Notepad.exe.

SUAnalyzerSrv.exe oraz AppVerif.exe zawsze będą uruchamiane z uprawnieniami administracyjnymi, aby móc przygotować środowisko dla testowanej aplikacji. Następnie SUA uruchomi notepad.exe we wskazanym kontekście zabezpieczeń i będzie czekał na zakończenie wykonywania aplikacji i procesów potomnych. Później SUA agreguje i przetwarza dzienniki narzędzia Application Verifier, po czym wyświetla rezultaty w interfejsie użytkownika.

Wyniki SUA podzielone są na kategorie wydarzeń i dotyczą różnych obszarów: File (system plików), Registry (rejestr), INI, Token (żeton dostępu), Privilege (przywileje), Name Space (przestrzeń nazw), Other Objects (inne obiekty) oraz Process (Proces). Kategorie te odpowiadają zakładkom w górnej części interfejsu SUA i pozwalają skupić się na różnych zagadnieniach podczas testowania aplikacji.

Zakładki File i Registry ukazują operacje na plikach lub w rejestrze, które wymagają uprawnień administracyjnych. Wtyczka luapriv Application Verifier monitoruje zachowanie odpowiednich API, takich jak CreateFile lub CreateRegistryKey, pod kątem przypadków, gdy ich użycie wymagałoby przywilejów administratora. W niektórych sytuacjach funkcja przekierowania plików i rejestru UAC w systemie Windows Vista mogłaby pozwolić na pomyślne wykonanie takich operacji.

Każda zakładka pokazana w interfejsie gromadzi wyniki monitorowania przez luapriv zachowania pewnego zbioru API. Na przykład zakładka INI koncentruje się na problemach związanych z użyciem API WriteProfile, oryginalnie wykorzystywanego w aplikacjach 16-bitowych. Dokładne omówienie każdej zakładki dostępne jest w pliku SUAnalyzer.rtf dołączonym do instalacji SUA. Możliwe jest rozwinięcie każdego zdarzenia w poszczególnych zakładkach w celu wyświetlenia szczegółowych informacji, łącznie ze śledzeniem stosu w momencie wystąpienia zdarzenia.

Po przejrzeniu wyników testu aplikacji SUA umożliwia przetestowanie i utworzenie pakietu naprawczego. Pakiet taki jest plikiem MSI, który rejestruje w systemie bazę danych kompatybilności aplikacji i może użyć narzędzia loosen.exe (dołączonego do SUA) w celu dopasowania list kontroli dostępu plików lub rejestru. Pakiety te można następnie wdrożyć w całym środowisku.

 Do początku strony

Internet Explorer Compatibility Test Tool

Narzędzie Internet Explorer Compatibility Test Tool wykorzystuje Internet Explorer Compatibility Evaluator (iece.exe). W wersji ACT 5.0 można było zainstalować narzędzie oceniające jako fragment pakietu gromadzenia danych, ale ponieważ to gromadzenie wymagało, aby badana przeglądarka była już zainstalowana, zostało ono usunięte w wersji ACT 5.5 (jakby nie patrzeć – odkrycie, że coś nie działa po zainstalowaniu tego czegoś nie jest optymalne; większość ludzi wolałaby odkryć problemy, zanim wdrożą nową przeglądarkę!).

Narzędzie Internet Explorer Compatibility Evaluator jest bardzo proste – wszystko, co musi zrobić, to modyfikacja rejestru, aby włączyć rejestrowanie w programie Internet Explorer. Ponieważ to sama przeglądarka zapewnia mechanizmy wykrywania, wierność i szczegółowość danych są bardzo wysokie. Szczegółowe informacje o zdarzeniach, które Internet Explorer może wykrywać (wraz z zaleceniami naprawczymi dla każdego wypadku) zawiera dokument Internet Explorer Application Compatibility.

Internet Explorer rejestruje swoje informacje w systemowych dziennikach zdarzeń (Event Log), zaś narzędzie testowe gromadzi dane z rejestru i konsoliduje je ze sobą. Informacje te można analizować bezpośrednio w tym narzędziu albo załadować zdarzenia do skonsolidowanej bazy danych ACT. W tym drugim przypadku Internet Explorer Compatibility Evaluator uruchomi takich samych agentów jak używane w pakiecie gromadzenia danych: najpierw collect.exe, następnie bucketizer.exe i na koniec compressor.exe, po którego wykonaniu pojawi się monit o wskazanie lokalizacji do zapisania pliku CAB.

 Do początku strony

Podsumowanie

Na tym kończy się krótka wycieczka po szczegółach narzędzia Application Compatibility Toolkit 5.5. Produkt ten udostępnia szereg użytecznych narzędzi, które powinny pomóc w migracji do systemu Windows Vista lub Windows 7, zaś dzięki lepszemu zrozumieniu, co każde z nich robi, można lepiej ocenić potencjał każdego narzędzia i poświęcić mu odpowiednią uwagę.

O autorze

Chris Jackson jest liderem technicznym zespołu Windows Application Experience SWAT w firmie Microsoft. Pracował z klientami korporacyjnymi na całym świecie, pomagając im wykryć przyczyny i zneutralizować skutki problemów zgodności, jak również zapewniając szkolenia i instrukcje na temat zagadnień kompatybilności aplikacji Windows. Prowadzi własny blog, dostępny pod adresem https://blogs.msdn.com/cjacks.

Chris Corio przez ponad pięć lat był członkiem zespołu Windows Security w firmie Microsoft. Jego główne zainteresowania to technologie zabezpieczeń aplikacji oraz techniki zarządzania służące zabezpieczaniu systemu Windows. Można się z nim porozumieć poprzez adres winsecurity@chriscorio.com.

Do początku strony

---