Category: How To
Błąd MSI 2769
| 2011-12-12 | Posted by Krzysiek under Błędy-MSI, How To, Polskie blogi IT |
|
Błąd "MSI 2769" jest dość często spotykanym błędęm, występującym podczas instalacji, reperacji lub deinstalacji pakietów wykonanych w "Microsoft Visual Studio" i bazujących na technologii ".Net Framework". Elementami powodującymi powstawanie tego błędu są najczęściej błędnie napisane klasy lub akcje ("Custom actions").
W poniższym opisie posłużono się pakietem opartym na klasie "ProjectInstaller" oraz jej komponentach "ServiceProcessInstaller" i "ServiceInstaller".
Instalacja oraz deinstalacjia pakietu przebiega bezproblemowo jednak podczas reperacji generowany jest "błąd 1001", informujący o tym, że serwis jest już zainstalowany w systemie i nie wymaga ponownej instalacji.
Rys.1. Błąd reperacji pakietu
"Błąd 1001" ma swoje odzwierciedlenie w tabeli "Error" bazy danych pakietu-msi.
Rys.2. Tabela "Error" w edytorze ORCA
Błędy o numeracji od 1000 do 1999 są błedami wewnętrznymi Windows Installera i są obsługiwane przez wpisy w tabeli "Errors", natomiast o numeracji od 2500 do 3000 są błędami wywołania akcji ("Custom actions") i bardzo często mają krytyczny wpływ na instalację pakietu.
Wpis w tabeli "Errors" nie mówi nam za wiele i aby znaleźć prawdziwe źródło odpowiedzialne za powstały błąd, należy zajrzeć do logu instalacyjnego (szukamy więc informacji o błędzie 1001).
MSI (s) (80:FC) [14:14:45:888]: Generating random cookie.
MSI (s) (80:FC) [14:14:45:904]: Created Custom Action Server with PID 1288 (0×508).
MSI (s) (80:F0) [14:14:45:966]: Running as a service.
MSI (s) (80:04) [14:14:45:966]: Hello, I'm your 32bit Elevated custom action server.
MSI (s) (80:F4) [14:15:55:524]: Leaked MSIHANDLE (9) of type 790531 for thread 1660
MSI (s) (80:F4) [14:15:55:524]: Note: 1: 2769 2: _09A1EA63_58DC_4827_BFA4_44059F3467B0.install 3: 1
MSI (c) (B4:C8) [14:14:46:435]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg Fehler 1001. Error 1001. Der angegebene Dienst ist bereits vorhanden
DEBUG: Error 2769: Custom Action _09A1EA63_58DC_4827_BFA4_44059F3467B0.installdid not close 1 MSIHANDLEs.
Bei der Installation dieses Pakets ist ein unerwarteter Fehler aufgetreten. Es liegt eventuell ein das Paket betreffendes Problem vor. Der Fehlercode ist 2769. Argumente: _09A1EA63_58DC_4827_BFA4_44059F3467B0.install, 1,
MSI (s) (80:98) [14:15:55:524]: User policy value 'DisableRollback' is 0
MSI (s) (80:98) [14:15:55:524]: Machine policy value 'DisableRollback' is 0
Aktion beendet um 14:15:55: InstallExecute. Rückgabewert 3.
Jak można zauważyć podczas reperacji produktu w logu instalacyjnym zapisywany jest błąd o numerze "2769", którego źródłem jest akcja "_09A1EA63_58DC_4827_BFA4_44059F3467B0.install"
DEBUG: Error 2769: Custom Action _09A1EA63_58DC_4827_BFA4_44059F3467B0.installdid not close 1 MSIHANDLEs.
Aby stwierdzić czy serwis jest instalowany w standardowy sposób czy przy pomocy akcji ("Custom actions") przechodzimy do tabel "ServiceInstall" i "ServiceControl" i sprawdzamy ich zawartość. Obie tabele są puste, co oznacza, że serwis jest instalowany przy pomocy akcji. W tabeli "CustomActions" znajdziemy wszystkie akcje odpowiedzialne za instalację /deinstalację serwisu (zaczynają sie od podkreślnika)
Rys.3. Zawartość tabeli "CustomAction"
Natomiast w tabeli "InstallExecuteSequence" znajdziemy sekwencje, którym przypisane są kolejno poszczególne akcje. Odszukujemy naszą "akcję" i sprawdzamy zawartość rekordu "Condition":
Rys.4. Zawartość tabeli "InstallExecuteSequence"
Mamy tu następujący zapis "$C__A86DDC61F5864695A26A870927B7E6A3>2", z którego wynika, że akcja jest wykonywana gdy, komponent "C__A86DDC61F5864695A26A870927B7E6A3" ($ wskazuje na komponent), zawierający plik "StartAppsEWX.exe", jest dostępny w systemie lub uruchamiany bezpośrednio ze źródła instalacji (wartość > 2, oznacza, że może przyjmować stany 3 i 4).
Poniższa tabela zawiera możliwe stany dla komponentów i "ficzerów" stosowane przy definiowaniu kondycji.
| Stan (State) | Wartość (Value) | Znaczenie (Meaning) |
|---|---|---|
| INSTALLSTATE_UNKNOWN | -1 | Akcja nie będzie wykonywana na komponencie lub „ficzerze”. |
| INSTALLSTATE_ADVERTISED | 1 | Tylko w przypadku istnienia zaanonsowanych „ficzerów”. Stan niedostępny dla komponentów. |
| INSTALLSTATE_ABSENT | 2 | „Ficzer” lub komponent nie istnieje. |
| INSTALLSTATE_LOCAL | 3 | „Ficzer” lub komponent znajduje się na lokalnym komputerze. |
| INSTALLSTATE_SOURCE | 4 | „Ficzer” lub komponent jest uruchamiany z plików źródłowych. |
Rozwiązanie
1. Otwieramy pakiet do edycji w programie Orca i tworzymy transformację (menu "Transform" -> "New Transform")
2. Przechodzimy do tabeli "CustomAction" i usuwamy wszystkie akcje powiązane z naszym serwisem
Rys.5. Zawartość tabeli "CustomAction" po modyfikacjach
3. Analogicznie postępujemy w tabeli "InstallExecuteSequence"
Rys.6. Zawartość tabeli "InstallExecuteSequence" po modyfikacjach
4. Następnie w tabeli "ServiceInstall" uzupełniamy następujace rekordy
| Nazwa rekordu | Wartość | Opis |
|---|---|---|
| ServiceInstall | App | Główny klucz (Primary key) tabeli – dowolna nazwa |
| Name | app | Nazwa serwisu |
| DisplayName | App Client Service | Nazwa serwisu używana do identyfikacji przez inne programy |
| ServiceType | 16 | Typ serwisu, wartość „16″ oznacza 32-bitowy serwis, który jest uruchamiany we własnym procesie |
| StartType | 2 | Flaga identyfikujaca w jaki sposób uruchamiany jest serwis. Wartość „2″ oznacza, że serwis jest uruchamiany przy starcie systemu |
| ErrorControl | 1 | Określa sposób obsługi błędu, podczas uruchamiania serwisu. Wartość „1″ oznacza , że informacja o napotkanym błądzie zapisywana jest do logu systemowego. Dodatkowo wyświetlany jest komunikat z treścią błędu i kontynuowana jest operacja uruchomienia serwisu. |
| Component_ | C__A86DDC61F5864695A26A870927B7E6A3 | Wskaźnik do komponentu |
| Description | App Service | Opis serwisu |
Rys.7. Zawartość tabeli "ServiceInstall" po wprowadzeniu danych
5. W tabeli "ServiceControl" uzupełniamy kolejno następujące rekordy
| Nazwa rekordu | Wartość | Opis |
|---|---|---|
| ServiceControl | app | Główny klucz (Primary key) tabeli – dowolna nazwa |
| Name | app | Nazwa serwisu |
| Event | 160 | Operacje wykonywane na serwisie podczas instalacji\deinstalacji produktu (wartość „160″ oznacza, że serwis jest zatrzymywany i usuwany podczas deinstalacji) |
| Wait | 0 | Wartość „0″ wymusza pause na instalatorze, aż do momentu kiedy SCM (Service Control Manager) powiadomi o tym, że serwis jest w stanie oczekiwania na kolejne instrukcje. |
| Component_ | C__A86DDC61F5864695A26A870927B7E6A3 | Wskaźnik do komponentu |
Rys.8. Zawartość tabeli "ServiceConrol" po wprowadzeniu danych
6. Zapisujemy transformację (menu "Transform" -> "Generate Transform…") i testujemy instalację, reperację oraz deinstalację pakietu.
Błąd „The procedure entry point GetProcessImageFileNameW could not be located in the dynamic link library PSAPI.DLL” podczas instalacji Oracle Client 10g
| 2011-10-04 | Posted by Krzysiek under How To, Polskie blogi IT |
|
"The procedure entry point GetProcessImageFileNameW could not be located in the dynamic link library PSAPI.DLL". Z komunikatu
Rys.1. Błąd "The procedure entry point GetProcessImageFileNameW could not be located in the dynamic link library PSAPI.DLL"
Biblioteka dynamiczna "PSAPI.DLL" jest częścia składową sytemów Windows ("%WinDir%\System32"). Podczas instalacji Oracle, nie jest jednak wykorzystywana, gdyż instalator Oracle korzysta z własnej, która jest kopiowana do tymczasowej lokalizacji. Po wystartowaniu "setup.exe" część instalacji jest wypakowywana pod „%LOCALAPPDATA%\Temp\OraInstall2011-08-05_12-51-28PM”. Nazwa katalogu jest generowana automatycznie i zależna od dnia i godziny instalacji. Plik "PSAPI.DLL" wykorzystywany podczas instalacji jest w wersji "5.0.1849.1", co stanowi sporą różnicę z dostępnym lokalnie.
Rys.2. Wersja pliku "PSAPI.DLL" wykorzystywana przez instalator Oracle
Plik "PSAPI.DLL" wchodzący w skład Windows 7 ("%WinDir%\System32") – 6.1.7600.16385 (wersja zależna od zainstalowanych poprawek).
Rys.3. Wersja pliku "PSAPI.DLL" wchodząca w skład Windows 7
Jak można tu zauważyć, jest to problem z niekompatybilnoścą wersji biblioteki dynamicznej "PSAPI.DLL". Najprostszym rozwiązaniem byłoby nadpisanie jej podczas instalacji produktu. Jest to niestety niemożliwe, gdyż plik ten jest odrazu wypakowywany do tymczasowego katalogu i każdy plik już tam istniejący jest przez niego nadpisywany. Drugim problemem jest to, że zaraz po wypakowaniu plik ten jest w użyciu przez co niemożliwe jest jego nadpisanie.
Jedynym rozsądnym rozwiązaniem jest tu podminienie go w plikach źródłowych instalatora. Plik "PSAPI.DLL" znajduje się w postaci skompresowanej w pliku "RunningProcessQuery.jar" w katalogu ".\Client\stage\Queries\RunningProcessQuery\1.5.2\1" instalatora. Jako że plik ".jar" jest archiwem ".zip", możliwe jest podmienienie go w pliku źródłowym. Możemy to wykonać np. przy użyciu darmowego archiwizera "7zip". Wykonamy to w następujący sposób:
- kopiujemy plik "RunningProcessQuery.jar" do dowolnej lokalizacji, gdzie otwieramy go przy pomocy "7zip"
-
Rys.4. Podmieniona bilioteka dynamiczna "PSAPI.dll"
-
Transformacja (.mst) może nadpisać wpisy rejestru uaktualnione przez plik (.msp) podczas instalacji typu (.msi + .mst + .msp)
| 2010-11-19 | Posted by Krzysiek under How To, Polskie blogi IT, Windows Installer |
|
Plik aktualizacyjny typu "patch" (.msp) może, niepoprawnie uaktualnić wpisy w rejestrze w przypadku, gdy główny produkt jest instalowany wraz z plikiem transformacji (.mst). Jest to związane z kolejnością wykonywania poszczególnych zadań przez usługę "Windows Installera". Tranasformacja (.mst) instalowana wraz z głównym produktem (.msi), jest zawsze dodawana w końcowej fazie procesu instalacji. W wyniku tej przypadłości, wpisy w rejestrze zaktualizowane przez plik (.msp), są ponownie nadpisywane przez plik transformacji (.mst).
Przykład:
msiexec /i <plik.msi> TRANSFORMS=<plik.mst> PATCH=<plik.msp>
Przy instalacji typu ".msi + .mst + .msp" nie można używać przełącznika "/i" razem z "/p". Należy go zastąpić przez "property" PATCH.
Przykładowe scenariusze instalacji oraz kolejność modyfikowania wpisów rejestru:
1. Instalacji typu .msi
Podczas instalacji (plik .msi) do rejestru zapisywane są tylko wpisy z tabeli "Registry" pliku (.msi).
2. Instalacja typu .msi + .mst
Podczas instalacji wpisy rejestru są modyfikowane przez wpisy z tabeli "Registry" pliku transformacji (.mst).
3. Instalacja typu .msi + .mst + .msp
Podczas instalacji wpisy rejestru, które miały być zmienione przez plik aktualizacji (.msp), są nadpisywane przez zawartość tabeli "Registry" pliku transformacji (.mst ).
Rozwiązanie:
Problem nadpisywania wartości rejestru można rozwiązać na dwa sposoby. Pierwszy z nich polega na aktualizacji głównego pliku (.msi) przy pomocy pliku (.msp) i późniejszym dopasowaniu transformacji, tak aby wpisy w rejestrze miały poprawne wartości.
msiexec /a <plik.msi> /p <plik.msp>
Drugi sposób polega na utworzeniu pliku aktualizacyjnego (.msp) zawierającego również elementy pliku transformacji (.mst). W efekcie końcowym główny plik instalacjny (.msi) instalowany jest tylko z plikiem aktualizacyjnym (.msp).
msiexec /i <plik.msi> PATCH=<plik.msp>
Użycie „unwise.exe” i „unwise32.exe” przy automatycznej deinstalacji oprogramowania
| 2010-11-11 | Posted by Krzysiek under How To, Polskie blogi IT |
|
Pliki "unwise.exe" lub "unwise32.exe" (tzw. deinstalatory) są elementami pakietu wykonanego w "WiseScript". Instalatory oprogramowania wykonane w tym języku mają zazwyczaj rozszerzenie typu ".exe" i są w pełni dostosowane do automatycznej instalacji bez interakcji ze strony użytkownika. Podczas instalacji pliki "unwise.exe" lub "unwise32.exe" kopiowane są do katalogu instalacyjnego aplikacji lub do katalogu Windows. W trakcie tego procesu tworzony jest plik "INSTALL.LOG" zawierający całą logikę instalacji. W celu odinstalowania pakietu w trybie ukrytym i automatycznym musimy skorzystać z następującej komendy.
"<ścieżka_do_katalogu>\unwise.exe" /S /A "<ścieżka_do_katalogu>\INSTALL.LOG"
lub
"<ścieżka_do_katalogu>\unwise32.exe" /S /A "<ścieżka_do_katalogu>\INSTALL.LOG"
przykład:
"%ProgramFiles%\Test\unwise.exe" /S /A "%ProgramFiles%\Test\INSTALL.LOG"
W powyższym przykładzie wykonana została automatyczna (przełącznik /A) i ukryta (przełącznik /S) deinstalacja oprogramowania w oparciu o plik "INSTALL.LOG". Deinstalator "unwise.exe\unwise32.exe" posiada również szereg innych ciekawych opcji, które zostały opisane poniżej:
/A – tryb automatyczny (automatic mode) wraz z graficznym interfejsem. Użytkownik nie musi wykonywać dodatkowych czynności, całość przebiega automatycznie. Wyjatkiem jest tu deinstalacja współdzielonych plików (np. plików dll znajdujących się w katalogu "%WinDir%\System32"), podczas której użytkownik jest proszony o wskazanie czy plik ma być odinstalowany czy nie.
/R – tryb powrotu instalacji do punktu startowego (rollback mode).
/S – tryb cichy (silent mode). Deinstalacja pakietu przebiega całkowicie w tle, bez interfejsu graficznego oraz komunikatów wymagających interakcji ze strony użytkownika.
/U – usuwa okno z możliwością wyboru metody deinstalacji pakietu ("Custom", "Automatic", "Repair").
/Z – usuwa puste katalogi, również ten w kórym się aktualnie znajduje.
Błąd MSI 1334 i 2602 przy aktualizacji plików instalacyjnych Adobe Acrobat Professional 9.0 do wersji 9.3.4
| 2010-10-13 | Posted by Krzysiek under Błędy-MSI, How To, Polskie blogi IT, Windows Installer |
|
Kilka dni temu aktualizując "Adobe Acrobat Professional" z wersji 9.0 do aktualnej oznaczonej numerem 9.3.4 napotkałem na dwa bardzo ciekawe błędy "MSI". Poniżej zaprezentuje metodę obejścia tego problemu jak i bezpośrednią aktualizację plików instalacyjnych pakietu (tzw. "slipstreamed installation"). W celu wykonania aktualizacji, należy z płyty CD wyodrębnić pliki instalatora (katalog "Adobe Acrobat 9 Pro") i skopiować je do przykładowego katalogu (np. do "d:\Acro"). Następnie ściągnąć wszystkie możliwe pliki aktualizacyjne skojarzone z naszą wersją "Adobe Acrobat". Przy aktualizacji należy pamietać o kolejności, czyli na początku należy zacząć od aktualizacji oznaczonej numerem "9.1", następnie "9.1.1, 9.1.2, 9.1.3, 9.2.0, 9.3.0, 9.3.1, 9.3.2, 9.3.3" a zakończyć na numerze "9.3.4". W celu wykonania pierwszej aktualizacji z wersji "9.0" do wersji "9.1" należy użyć następującej komendy:
msiexec /a <ścieka_do_pliku\plik.msi> /p <ścieżka_do_pliku\plik.msp>
w naszym przypadku komenda będzie miała następującą postać:
msiexec /a d:\Acro\AcroPro.msi /p d:\Update\AcroProStdUpd910_T1T2_incr.msp
Komunikat błędu:
Product: Adobe Acrobat 9 Pro – English, Français, Deutsch — Error 1334.The file 'interop.adobepdfmakerx.dll' cannot be installed because the file cannot be found in cabinet file 'Data1.cab'. This could indicate a network error, an error reading from the CD-ROM, or a problem with this package.
Product: Adobe Acrobat 9 Pro – English, Français, Deutsch — Błąd 1334.Plik 'interop.adobepdfmakerx.dll' nie może być zainstalowany, ponieważ nie ma go w pliku 'Data1.cab'. Może to wskazywać na problem z połączniem sieciowym, błąd odczytu z CD-ROM, lub jakiś inny problem z tym pakietem.
Z komunikatu błędu wynika, że podczs procesu aktualizacji plików instalacyjnych nie wszystkie są poprawmie wypakowywane z pliku Data1.cab. Aby zapobiec dalszemu pojawianiu się tego komunikatu, należy wypakować oryginalną instalację do postaci zewnętrznych nieskomprensowanych plików (tzw. "external uncompressed files") i ponownie przystąpić do aktualizacji. Wykonamy to przy pomocy poniższego polecenia:
msiexec /a <ścieka_do_pliku\plik.msi>
w naszym przypadku komenda będzie miała następującą postać:
msiexec /a d:\Acro\AcroPro.msi
Podczas wypakowywania plików instalacyjnych zostaniemy poproszeni o wskazanie miejsca docelowego, gdzie zostaną one zapisane (np. do katalogu "d:\AcroUpd"). Jak można łatwo zauważyć, do katalogu "d:\AcroUpd" kopiowane są pliki z pominiecięm "Data1.cab", gdyż właśnie z niego są wypakowywane.
Po prawidłowym wypakowaniu plików możemy ponownie przystapić do procesu aktualizacji. Przy aktualizacji z wersji 9.1.1 do wersji 9.1.2 możemy napotkać na kolejny błąd "MSI" o numerze "2602". Proces aktualizacji zostanie w tym momencie przerwany.
Komunikat błędu:
Product: Adobe Acrobat 9 Pro – English, Français, Deutsch — Error 2602.The File table entry 'Annots.api_911' has no associated entry in the Media table.
Product: Adobe Acrobat 9 Pro – English, Français, Deutsch — Błąd 2602. Wpis 'Annots.api_911' w tabeli "Files" nie ma poprawnego powiązania z wpisem z tabeli "Media".
Błąd MSI 2602
Z informacji zawartych w komunikacie błędu wynika,że instalator napotkał na nieprawidłowe wpisy w tabelach "File" i "Media". Aby sprawdzić poprawność wpisów w obu wspomnianych wcześniej tabelach, należy w pierwszej kolejności użyć edytora "Orca" i otworzyć w nim plik "AcroPro.msi". Następnie przechodzimy do tabeli "Files" i sprawdzamy numer sekwencyjny (kolumna "Sequence") pliku "Annots.api_911". Jest nim "25000". W kolejnym kroku przechodzimy do tabeli "Media" i sprawdzamyw kolumnie "LastSequence" poprawność numeru sekwencyjnego. Numer ten powinien wskazywać na ostatni numer sekwencyjny w tabeli "Files" czyli na 25000. Numer naszego pliku powinien znajdować się w podanym wcześniej zakresie (od 1 do 25000).
Edytor Orca – umiejscowienie pliku "Annots.api_911" w tabeli "Files"
Edytor Orca – maksymalny numer sekwencyjny w tabeli "Media"
W celu sprawdzenia poprawności kolejnej aktualizacji o numerze "9.1.2" w edytorze "Orca" przechodzimy do menu "Transform" i przy pomocy polecenia "View Patch…" wybieramy ją do podglądu (plik "AcrobatUpd912_all_incr.msp").
Edytor Orca – podgląd zawartości pliku aktualizacyjnego w tabeli "Media"
Ponownie przechodzimy do wymienionych powyżej tabel i sprawdzamy ich poprawność. Jak można łatwo zauważyć tabela "Media" zawiera nieprawidłowe wpisy odnoszące się do numeru sekwencyjnego naszego pliku. Ostatnim numerem sekwencyjnym w tabeli "Files" jest 24013, natomiast w tabeli "Media" numer sekwencyjny powiązany z "Data1.cab" wynosi 18227 (poprzednio "25000"). Ostatnim numerem sekwencyjnym dodanym przez aktualizację jest 24013 (kolumna "LastSequnce").
Aby naprawić ten błąd należy otworzyć w edytorze "Orca" plik "AcroPro.msi" i w tabeli "Files" zmienić numer sekwencyjny pliku "Annots.api_911" z 25000 np. na 18215 (jeden z wolych numerów w zakresie od 1 do 18227) i zapisać zmiany. Nie musimy się tutaj martwić, że bezpośrednio modyfikujemy plik .msi, ponieważ jest on zmieniany przy każdej aktualizacji. Jedyne co pozostanie do zrobienia, to implementacja pozostałych aktualizacji, aż do wersji 9.3.4 i póżniejsze dopasowanie pakietu instalacyjnego .msi (przy pomocy transformacji .mst) np. przy użyciu narzędzia "Adobe Customization Wizard" dostępnego na stronach producenta.
Specjalne foldery w Windows Installer
| 2010-04-08 | Posted by Krzysiek under How To, Polskie blogi IT, Windows Installer |
|
Windows Installer zawiera w sobie kikanaście zdefiniowanych "Property" do obsługi standardowych folderów (np. "WindowsFolder" – wskazujący na folder Windows). Pozostałe foldery można obsłużyć poprzez zmienne środowiskowe (np. %ALLUSERSPROFILE%), które mogą być używane analogicznie do "Property" ale w trochę odmiennej postaci zrozumiałej dla wewnętrznych prcedur Windows Installera (np. [%ALLUSERSPROFILE]). Zarówno standardowe foldery w Windows Installer jak i ich odpowiedniki wyczytywane poprzez zmienne środowiskowe nie pokrywają w całości wszystkich dostępnych folderów w Windows, których umiejscowienie i mnogość zależne są od jego wersji. W przypadku napotkania problemów przy wyczytywaniu ścieżki do niestandardowego folderu bardzo pomocnym może okazać się poniższy skrypt wyczytujący wartości CSIDL_* w postaci ścieżki dostępu do niego i zapisujący tą wartość w tabeli "Property". Poniższy skrypt wyczytuje ścieżkę do katalogu "c:\Documents and Settings\All Users\Dokumenty" i zapisuje ją w tabeli "Property" pod nazwą "SD_COMMON_DOCUMENTS".
Const CSIDL_COMMON_DOCUMENTS = &h2e
Set objShell = CreateObject(“Shell.Application”)
Session.Property(“SD_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path
Set objShell = Nothing
Skrypt powinien być umieszczony jako akcja ("Custom Action") przed sekwencją "CostFinalize",
Umiejscowienie skryptu w tabeli "CustomAction"
Umiejscowienie skryptu w tabeli "InstallExecuteSequence"
wykonywany wewnętrznie jako "Call VBScript from Embeded Code" i natychmiastowo "Immediate".
Tabela "Directory"
W załączonej tabeli wymienione zostały wszystkie dostępne katalogi, które można wyczytać poprzez powyższy skrypt w systemach Windows XP/Vista/7 (ze względu na rozmiar tabela została umieszczona na osobnej stronie) – Tabela: Specjalne foldery w Windows Installer
Błąd MSI 1402 i 1406 podczas aktualizacji Adobe Readera
| 2010-03-16 | Posted by Krzysiek under Błędy-MSI, How To, Polskie blogi IT, Windows Installer |
|
Przy ostatniej aktualizacji Adobe Readera z wersji 7.1.1 do 8.2 natrafiłem na pewien błąd, który uniemożliwił instalację aktualizacji na około 30 % "klientów". Podczas procesu instalacji wygenerowane zostały błędy krytyczne, które uniemożliwiły dalszą instalację programu. Użytkowicy końcowi zostali pozbawieni Adobe Readera, gdyż aktualizacja w pierwszej kolejności odinstalowywała jego starszą wersję. Analizując logi i wpisy z dziennika zdarzeń napotkałem na dwa błędy Windows Installera o numerach 1402 i 1406. Poniżej ich treść.
Error 1402: Could not open key: HKEY_LOCAL_MACHINE\Software\Classes\.pdf\PersisstentHandler"…
Błąd 1402: Nie mogę otworzyć klucza: HKEY_LOCAL_MACHINE\Software\Classes\.pdf\PersisstentHandler"…
W dzienniku zdarzeń pojawił się następujący wpis:
Typ zdarzenia: Błąd
Źródło zdarzenia: MsiInstaller
Kategoria zdarzenia: Brak
Identyfikator zdarzenia: 11402
Data: 2010-03-09
Godzina: 13:59:58
Użytkownik: COMPUTERNAME\USERNAME
Komputer: COMPUTERNAME
Opis:
Produkt: Adobe Reader 8.1.0 – Polish — Błąd 1402.Nie można otworzyć klucza: HKEY_LOCAL_MACHINE\Software\Classes\.pdf\PersistentHandler. System error 5. Zweryfikuj swój dostęp do klucza lub skontaktuj się z obsługą personelu.
Error 1406: Could not write value to key: "\Software\Classes\.pdf\PersisstentHandler"…
Błąd 1406: Nie mogę zapisać wartości do klucza: "\Software\Classes\.pdf\PersisstentHandler"…
następny wpis z dziennika zdarzeń:
Typ zdarzenia: Błąd
Źródło zdarzenia: MsiInstaller
Kategoria zdarzenia: Brak
Identyfikator zdarzenia: 11406
Data: 2010-03-09
Godzina: 15:47:11
Użytkownik: COMPUTERNAME\USERNAME
Komputer: COMPUTERNAME
Opis:
Produkt: Adobe Reader 8 – Polish — Błąd 1406.Nie można zapisać wartości dla klucza \Software\Classes\.pdf\PersistentHandler. Błąd systemowy . Zweryfikuj swoje przywileje dostępu do klucza lub skontaktuj się z obsługą personelu.
Z powyższych informacji wynika, że pakiet podczas aktualizacji ma problemy z odczytem/zapisem informacji z/do klucza, a co za tym idzie, problemy z uprawnieniami. Bardzo interesującą rzeczą jest też to, że pakiet podczas deinstalacji "zdejmuje" (sytuacja ta nie występuje zawsze) prawa do odczytu/zapisu grupie Administratorów i koncie systemowemu. Problem ten można naprawić poprzez przejęcie obiektu przez grupę Administratorów oraz przywrócenie uprawnień odczytu/zapisu zarówno dla grupy Administratorów jak i dla konta systemowego. Wykonamy to w następujący sposób.
- Otwieramy erytor rejestru i przechodzimy do klucza "HKCR\.pdf\PersistenHandler". Następnie wchodzimy we "Właściwości" klucza i sprawdzamy, czy grupa Administratorów oraz konto systemowe mają pełne prawa (Full control) do wyżej wymienionego klucza. W przypadku stwierdzenia braku pełnych uprawnień do klucza wykonujemy kolejno.
- Przechodzimy do "Zaawansowanych" uprawnień do klucza rejestru
Wybór "Zaawansowanych" uprawnień do klucza rejestru
- Następnie w zakładce "Właściciel" sprawdzamy czy grupa Administratorzy jest domyślnym "Właścicielem" obiektu. Jeśli nie, to ustawiamy ją jako domyślną oraz zaznaczmy opcję "Zamień właściciela dla podkontenerów i obiektów".
Zakładka "Właściciel" obiektu
- W ostatnim kroku powracamy do zakładki "Uprawnienia" i zaznaczamy opcję "Zmień wpisy uprawnienia na wszystkich obiektach podrzędnych na wpisy tutaj pokazane, stosowane do obiektów podrzędnych"
Zakładka "Uprawnienia"
- Zatwierdzamy zmiany i ponownie wykonujemy instalację pakietu. Przy natrafieniu na podobny problem dotyczący innych kluczy rejestru, postępujemy w analogiczny sposób.
Opisany powyżej problem dotyczy wersji Adobe Readera 6.x - 9.x. Proces nadawania uprawnień możemy zautomatyzować poprzez umieszczenie w pakiecie akcji ("CustomAction") przywracającej standardowe uprawnienia do kluczy rejestru grupie Admnistratorów i kontu systemowemu.
Uruchamianie instalacji pakietu-msi z uprawnieniami „System Account”
| 2010-02-25 | Posted by Krzysiek under How To, Polskie blogi IT, Windows Installer |
|
Przy testowaniu gotowego pakietu-msi bardzo ważne jest, aby przetestować cały proces instalacji z uprawnieniami konta systemowego. Można to wykonać na dwa sposoby: przy wykorzystaniu zaplanowanych zadań lub programu "psexec.exe".
1. Metoda polegająca na dodaniu zaplanowanego zadania.
Z linii poleceń wpisujemy:
at <h:m> /interactive <plik_instalacyjny>
gdzie:
h:m – czas uruchomienia zaplanowanego zadania
interactive – zezwala, aby zadanie współdziałało z zadaniami użytkownika, który jest zalogowany wówczas, gdy jest ono uruchomione
plik_instalacyjny – ścieżka do pliku instalacyjnego
przykład:
at 12:01 /interactive c:\Temp\install.cmd
2. Przy wykorzystaniu programu "psexec.exe"
Z linii poleceń wpisujemy:
psexec.exe -i -s cmd
gdzie:
i - proces uruchamiany w oknie konsoli
s - uruchamia proces z uprawnieniami konta systemowego
Uzyskana w ten sposób sesja pozwala na uruchamianie instalacji z uprawnieniami "System Account"
Źródła:
psexec.exe – wchodzi w skład pakietu "PSTools" dostępnego na stronach Microsoft
Konfiguracja DPM dla ochrony Exchange 2007 LCR
| 2010-02-08 | Posted by Tomasz_Sochacki under Exchange 2007, How To, Polskie blogi IT |
|
Przy konfiguracji Data Protection Manager dla ochrony Exchange 2007 jeżeli mamy uruchomioną funkcjonalność LCR (Local Continuous Replication), musimy zrobić odpowiedni wpis w rejestrze serwera Exchange. W przeciwnym wypadku story z uruchomionym LCR nie będą widziane przez DPM. Klucz, który trzeba dodać „EnableVssWriter” w gałęzi: HKLM\Software\Microsoft\Exchange\Replay\Parameters o wartości 0 typ:DWORD
Odinstalowanie aplikacji przy użyciu SCCM 2007
| 2009-08-11 | Posted by Tomasz_Sochacki under How To, Polskie blogi IT, SCCM 2007 |
|
Jak odinstalować aplikację na komputerach klienckich bez pliku *.msi przy użyciu SCCM 2007? W tym przykładzie odinstalujemy Windows Defender na komputerach klienckich przy użyciu komendy MsiExec.exe /X 1. Utworzyć nowe zadanie (task sequences) w Operating System Deployment. 2. Po utworzeniu nowego zadania, wybieramy je i prawym przyciskiem klikamy edytuj. 3. Klikamy Add -> General -> [...]
Jak wylistować wszystkie usługi na danym komputerze
| 2009-05-10 | Posted by Tomasz_Sochacki under How To, Polskie blogi IT |
|
Jak wylistować wszystkie usługi na danym komputerze? Należy użyć polecenie wmic service list full wynik otrzymamy na monitorze lub prosto do pliku HTML: wmic /output:services.html service list full /format:htable
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
Instalacja Hyper-V w Windows Server 2008
| 2009-01-11 | Posted by Tomasz_Sochacki under How To, Polskie blogi IT, Server 2008 |
|
Instalacja Hyper-V w Windows Server 2008, czyli prosty sposób na stabilne środowisko wirtualizacyjne w 10 min. 1. Procesor serwera musi wspierać wirtualizację (np.: modele VT-x or AMD-V) 2. System Windows Server 2008 musi być w wersji x64. 3. Należy sprawdzić czy na serwerze zainstalowana jest poprawka „Hyper-V Update for Windows Server 2008 x64 Edition [...]