Troubleshooting deployment through AD/GPO
Troubleshooting deployment of "Sony Ericsson PC Suite" (v2.10.29) through AD/GPO (per-machine).
To get everything in place
Manually run "PC Suite_2.10.38.exe" and when the feature selection dialog is visible just pause for a minute.
Find the temp subfolder where the "Sony Ericsson PC Suite.msi" and LangID transform (ex. 1033.MST)" is located (ex. %temp%\{4B98F821-99BF-4039-A9C7-3032DC078CFF}).
Find the temp subfolder where the installation files (DeviceData.exe, Drivers.exe, PCSuite.exe...) are located (ex. %temp%\{D6BF6477-8369-489F-8DE6-3731F4B88560}).
Copy these folders to a safe place and exit/cancel the current installation.
To get the two other (MSI) packages that's executed by the "%temp%\<GUID>\Setup.exe" (manually) run:
DeviceData.exe = %temp%\<GUID>\Sony Ericsson Device Data.msi
Drivers.exe = %temp%\<GUID>\Sony Ericsson Drivers.msi
(PCSuite.exe = %temp%\<GUID>\Sony Ericsson PC Suite.msi)
If you have enabled the Windows Installer Logging policy you'll find which public properties that has been passed to each package.
I also monitor created processes using a WMI script (Win32_Process - Instance Creation Event).
Sony Ericsson Device Data.msi:
Setup.exe -> DEVICEDATA.EXE ->
MSIEXEC.EXE /i "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{98A3E09E-027A-4BC4-9BD9-7D19E77204CB}\Sony Ericsson Device Data.msi" /qn /Lv C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\SonyEricsson_DeviceData.log ARPSYSTEMCOMPONENT=1 DEPENDENCY=1 REBOOT=ReallySuppress SETUPEXEDIR="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D6BF6477-8369-489F-8DE6-3731F4B88560}"
Sony Ericsson PC Suite.msi:
Setup.exe -> PCSuite.exe ->
MSIEXEC.EXE /i "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{4B98F821-99BF-4039-A9C7-3032DC078CFF}\Sony Ericsson PC Suite.msi" /Lv C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\SonyEricsson_PCSuite.log ARPSYSTEMCOMPONENT=1 DEPENDENCY=1 REBOOT=ReallySuppress TRANSFORMS="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{4B98F821-99BF-4039-A9C7-3032DC078CFF}\1033.MST" SETUPEXEDIR="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D6BF6477-8369-489F-8DE6-3731F4B88560}"
Sony Ericsson Drivers.msi:
Setup.exe -> Drivers.exe ->
MSIEXEC.EXE /i "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{61977A5F-A633-4F45-B866-486FA7D477BD}\Sony Ericsson Drivers.msi" /qn /Lv C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\SonyEricsson_Drivers.log ARPSYSTEMCOMPONENT=1 DEPENDENCY=1 REBOOT=ReallySuppress SETUPEXEDIR="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D6BF6477-8369-489F-8DE6-3731F4B88560}"
Update the 1033.MST with the DEPENDENCY and REBOOT property, use with "Sony Ericsson PC Suite.msi".
Create a transform with the DEPENDENCY and REBOOT property for both "Sony Ericsson Device Data.msi" and "Sony Ericsson Drivers.msi".
We're now ready for trouble!
My first problem started when I did my first deployment test after having nested "Sony Ericsson Device Data.msi" and "Sony Ericsson Drivers.msi" into the "Sony Ericsson PC Suite.msi" package.
When the client started to install the package it seemed to take rather long time and never ended.
I disabled the client's XP FW and enabled the Windows Installer Logging & Debug policy.
Reset the VMware client and as fast as the client started ("Preparing network connections" dialog) I connected to the client through DebugView.
Looking through the verbose log the last line just said "InstallShield 14:26:04: Registering Msi Server..." and nothing more was logged.
Looking some lines above i found this LOG part:
MSI (s) (F0:C8) [14:26:04:198]: Executing op: ProductPublishClient(Parent={345CDDCB-8241-4E76-9D3B-155F2FD6F07E},ChildPackagePath=:SonyEricssonDrivers.msi,)
MSI (s) (F0:C8) [14:26:04:198]: Executing op: ActionStart(Name=CA_CABLEDRIVER_WritePath,,)
MSI (s) (F0:C8) [14:26:04:198]: Executing op: CustomActionSchedule(Action=CA_CABLEDRIVER_WritePath,ActionType=1089,Source=BinaryData,Target=f1,CustomActionData=C:\Program Files\Common Files\)
MSI (s) (F0:C8) [14:26:04:229]: Creating MSIHANDLE (101) of type 790536 for thread 456
MSI (s) (F0:54) [14:26:04:229]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI5A.tmp, Entrypoint: f1
So this was my second nested install (":SonyEricssonDrivers.msi" stored in the _Storages table) as ":SonyEricssonDeviceData.msi" was first installed in the nested sequence.
To verify that it was this CA that actually "freezed" the installation I opened the rollback scripts; in this case "\\VMclient\c$\Config.Msi\7320.rbs", in notepad and the last line was "CA_CABLEDRIVER_WritePath" so this was last executed.
So there is some kind of problem with the "f1" (which is listed as WritePath in the "IsConfig.ini" file) function call within the Custom Action DLL (binary "ISSetup.dll").
As the CA_CABLEDRIVER_WritePath custom action was executed at the end in the InstallExecuteSequence table I decided to just prevent it from being executed, changed condition from "NOT Installed" to "0 AND NOT Installed".
Test deployed and now another freeze was in place but from the "Sony Ericsson PC Suite.msi", GAAAAHH.
Okey, we've fixed the problem in the nested "Sony Ericsson Drivers.msi" so lets see what else Sony tried to do.
Last line in the verbose log ended as the previous problem:
InstallShield 11:57:40: Done Initializing...
MSI (s) (A0!C0) [11:57:40:396]: Closing MSIHANDLE (104) of type 790531 for thread 448
MSI (s) (A0!C0) [11:57:40:412]: Creating MSIHANDLE (105) of type 790531 for thread 448
InstallShield 11:57:40: Registering Msi Server...
Searched for "doing action:" from bottom and up and found:
MSI (s) (A0:E4) [11:57:38:629]: Doing action: Update_Environmet
So can I prevent "Update_Environmet" from being executed also?
Need more information what this bugger does.
Searched for "Done Initializing" from the different events in DebugView and here we got some more info.
We now have our last "Registering Msi Server..." from the log where the installation seems to freeze.
There's alot of "Creating MSIHANDLE", "Closing MSIHANDLE" and "Passing to service" events but some lines:
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiRecordSetString(103, 1, "Done Initializing...")
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiProcessMessage(87, 67108864, 103)
...
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiRecordSetString(104, 0, "InstallShield [Time]: [1]")
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiRecordSetString(104, 1, "Registering Msi Server...")
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiProcessMessage(87, 67108864, 104)
...
MSI (s) (E0!D0) [12:03:03:317]: Creating MSIHANDLE (105) of type 790531 for thread 464
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiRecordSetString(105, 0, "InstallShield [Time]: [1]")
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiRecordSetString(105, 1, "Invoking script function UpdateEnvironment")
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiProcessMessage(87, 67108864, 105)
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiCloseHandle(105)
MSI (s) (E0!D0) [12:03:03:317]: Closing MSIHANDLE (105) of type 790531 for thread 464
MSI (c) (F0:94) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:94) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:94) [12:03:10:009]: Entering MsiProvideComponentFromDescriptor. Descriptor: T%i&7oT-C?kaTW(0fqX8Toolbox>M5KDYSUnf(HA*L[xeX)y, PathBuf: 190ED98, pcchPathBuf: 190ED94, pcchArgsOffset: 190ECF4
MSI (c) (F0:94) [12:03:10:009]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (F0:94) [12:03:10:009]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (F0:94) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:F0) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:F0) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:F0) [12:03:10:009]: Entering MsiProvideComponentFromDescriptor. Descriptor: T%i&7oT-C?kaTW(0fqX8Toolbox>M5KDYSUnf(HA*L[xeX)y, PathBuf: 154ECDC, pcchPathBuf: 154ECD8, pcchArgsOffset: 154EC38
MSI (c) (F0:F0) [12:03:10:009]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (F0:F0) [12:03:10:009]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (F0:F0) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
The "Update_Environmet" custom action is executed just after the "InstallInitialize" action so it must be doing something the installation needs I think.
Decided to try to deploy the "Sony Ericsson PC Suite.msi" package once more and doing some major waiting.
Came back and the installation was finished!
MSI (s) (E0:F8) [12:03:01:175]: Doing action: Update_Environmet
InstallShield 12:03:03: Registering Msi Server...
MSI (s) (E0!D0) [12:03:03:317]: Closing MSIHANDLE (105) of type 790531 for thread 464
-----------------------------------ONE HOUR WAITING-----------------------------------
MSI (s) (E0!D0) [13:02:38:897]: Creating MSIHANDLE (106) of type 790531 for thread 464
InstallShield 12:03:03: Invoking script function UpdateEnvironment
MSI (s) (E0!D0) [13:02:38:991]: Closing MSIHANDLE (106) of type 790531 for thread 464
Action ended 13:02:39: Update_Environmet. Return value 1.
...
Action ended 13:03:23: INSTALL. Return value 1.
So if I manually install my (custom) "Sony Ericsson PC Suite" package it takes like 10-15 minutes maximum and over 1 hour through Active Directory, yeay!
This happens weither the packages are installed nested or not.
We'll see If there is something we can do to speed this up abit.
To get everything in place
Manually run "PC Suite_2.10.38.exe" and when the feature selection dialog is visible just pause for a minute.
Find the temp subfolder where the "Sony Ericsson PC Suite.msi" and LangID transform (ex. 1033.MST)" is located (ex. %temp%\{4B98F821-99BF-4039-A9C7-3032DC078CFF}).
Find the temp subfolder where the installation files (DeviceData.exe, Drivers.exe, PCSuite.exe...) are located (ex. %temp%\{D6BF6477-8369-489F-8DE6-3731F4B88560}).
Copy these folders to a safe place and exit/cancel the current installation.
To get the two other (MSI) packages that's executed by the "%temp%\<GUID>\Setup.exe" (manually) run:
DeviceData.exe = %temp%\<GUID>\Sony Ericsson Device Data.msi
Drivers.exe = %temp%\<GUID>\Sony Ericsson Drivers.msi
(PCSuite.exe = %temp%\<GUID>\Sony Ericsson PC Suite.msi)
If you have enabled the Windows Installer Logging policy you'll find which public properties that has been passed to each package.
I also monitor created processes using a WMI script (Win32_Process - Instance Creation Event).
Sony Ericsson Device Data.msi:
Setup.exe -> DEVICEDATA.EXE ->
MSIEXEC.EXE /i "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{98A3E09E-027A-4BC4-9BD9-7D19E77204CB}\Sony Ericsson Device Data.msi" /qn /Lv C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\SonyEricsson_DeviceData.log ARPSYSTEMCOMPONENT=1 DEPENDENCY=1 REBOOT=ReallySuppress SETUPEXEDIR="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D6BF6477-8369-489F-8DE6-3731F4B88560}"
Sony Ericsson PC Suite.msi:
Setup.exe -> PCSuite.exe ->
MSIEXEC.EXE /i "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{4B98F821-99BF-4039-A9C7-3032DC078CFF}\Sony Ericsson PC Suite.msi" /Lv C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\SonyEricsson_PCSuite.log ARPSYSTEMCOMPONENT=1 DEPENDENCY=1 REBOOT=ReallySuppress TRANSFORMS="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{4B98F821-99BF-4039-A9C7-3032DC078CFF}\1033.MST" SETUPEXEDIR="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D6BF6477-8369-489F-8DE6-3731F4B88560}"
Sony Ericsson Drivers.msi:
Setup.exe -> Drivers.exe ->
MSIEXEC.EXE /i "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{61977A5F-A633-4F45-B866-486FA7D477BD}\Sony Ericsson Drivers.msi" /qn /Lv C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\SonyEricsson_Drivers.log ARPSYSTEMCOMPONENT=1 DEPENDENCY=1 REBOOT=ReallySuppress SETUPEXEDIR="C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{D6BF6477-8369-489F-8DE6-3731F4B88560}"
Update the 1033.MST with the DEPENDENCY and REBOOT property, use with "Sony Ericsson PC Suite.msi".
Create a transform with the DEPENDENCY and REBOOT property for both "Sony Ericsson Device Data.msi" and "Sony Ericsson Drivers.msi".
We're now ready for trouble!
My first problem started when I did my first deployment test after having nested "Sony Ericsson Device Data.msi" and "Sony Ericsson Drivers.msi" into the "Sony Ericsson PC Suite.msi" package.
When the client started to install the package it seemed to take rather long time and never ended.
I disabled the client's XP FW and enabled the Windows Installer Logging & Debug policy.
Reset the VMware client and as fast as the client started ("Preparing network connections" dialog) I connected to the client through DebugView.
Looking through the verbose log the last line just said "InstallShield 14:26:04: Registering Msi Server..." and nothing more was logged.
Looking some lines above i found this LOG part:
MSI (s) (F0:C8) [14:26:04:198]: Executing op: ProductPublishClient(Parent={345CDDCB-8241-4E76-9D3B-155F2FD6F07E},ChildPackagePath=:SonyEricssonDrivers.msi,)
MSI (s) (F0:C8) [14:26:04:198]: Executing op: ActionStart(Name=CA_CABLEDRIVER_WritePath,,)
MSI (s) (F0:C8) [14:26:04:198]: Executing op: CustomActionSchedule(Action=CA_CABLEDRIVER_WritePath,ActionType=1089,Source=BinaryData,Target=f1,CustomActionData=C:\Program Files\Common Files\)
MSI (s) (F0:C8) [14:26:04:229]: Creating MSIHANDLE (101) of type 790536 for thread 456
MSI (s) (F0:54) [14:26:04:229]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI5A.tmp, Entrypoint: f1
So this was my second nested install (":SonyEricssonDrivers.msi" stored in the _Storages table) as ":SonyEricssonDeviceData.msi" was first installed in the nested sequence.
To verify that it was this CA that actually "freezed" the installation I opened the rollback scripts; in this case "\\VMclient\c$\Config.Msi\7320.rbs", in notepad and the last line was "CA_CABLEDRIVER_WritePath" so this was last executed.
So there is some kind of problem with the "f1" (which is listed as WritePath in the "IsConfig.ini" file) function call within the Custom Action DLL (binary "ISSetup.dll").
As the CA_CABLEDRIVER_WritePath custom action was executed at the end in the InstallExecuteSequence table I decided to just prevent it from being executed, changed condition from "NOT Installed" to "0 AND NOT Installed".
Test deployed and now another freeze was in place but from the "Sony Ericsson PC Suite.msi", GAAAAHH.
Okey, we've fixed the problem in the nested "Sony Ericsson Drivers.msi" so lets see what else Sony tried to do.
Last line in the verbose log ended as the previous problem:
InstallShield 11:57:40: Done Initializing...
MSI (s) (A0!C0) [11:57:40:396]: Closing MSIHANDLE (104) of type 790531 for thread 448
MSI (s) (A0!C0) [11:57:40:412]: Creating MSIHANDLE (105) of type 790531 for thread 448
InstallShield 11:57:40: Registering Msi Server...
Searched for "doing action:" from bottom and up and found:
MSI (s) (A0:E4) [11:57:38:629]: Doing action: Update_Environmet
So can I prevent "Update_Environmet" from being executed also?
Need more information what this bugger does.
Searched for "Done Initializing" from the different events in DebugView and here we got some more info.
We now have our last "Registering Msi Server..." from the log where the installation seems to freeze.
There's alot of "Creating MSIHANDLE", "Closing MSIHANDLE" and "Passing to service" events but some lines:
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiRecordSetString(103, 1, "Done Initializing...")
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiProcessMessage(87, 67108864, 103)
...
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiRecordSetString(104, 0, "InstallShield [Time]: [1]")
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiRecordSetString(104, 1, "Registering Msi Server...")
MSI (a) (60:D0) [12:03:03:286]: Passing to service: MsiProcessMessage(87, 67108864, 104)
...
MSI (s) (E0!D0) [12:03:03:317]: Creating MSIHANDLE (105) of type 790531 for thread 464
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiRecordSetString(105, 0, "InstallShield [Time]: [1]")
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiRecordSetString(105, 1, "Invoking script function UpdateEnvironment")
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiProcessMessage(87, 67108864, 105)
MSI (a) (60:D0) [12:03:03:317]: Passing to service: MsiCloseHandle(105)
MSI (s) (E0!D0) [12:03:03:317]: Closing MSIHANDLE (105) of type 790531 for thread 464
MSI (c) (F0:94) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:94) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:94) [12:03:10:009]: Entering MsiProvideComponentFromDescriptor. Descriptor: T%i&7oT-C?kaTW(0fqX8Toolbox>M5KDYSUnf(HA*L[xeX)y, PathBuf: 190ED98, pcchPathBuf: 190ED94, pcchArgsOffset: 190ECF4
MSI (c) (F0:94) [12:03:10:009]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (F0:94) [12:03:10:009]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (F0:94) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:F0) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:F0) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
MSI (c) (F0:F0) [12:03:10:009]: Entering MsiProvideComponentFromDescriptor. Descriptor: T%i&7oT-C?kaTW(0fqX8Toolbox>M5KDYSUnf(HA*L[xeX)y, PathBuf: 154ECDC, pcchPathBuf: 154ECD8, pcchArgsOffset: 154EC38
MSI (c) (F0:F0) [12:03:10:009]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (F0:F0) [12:03:10:009]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (F0:F0) [12:03:10:009]: CMsiAPIMessage::FSetInternalHandlerValue: UI level set to none because we're running in a non-interactive context.
The "Update_Environmet" custom action is executed just after the "InstallInitialize" action so it must be doing something the installation needs I think.
Decided to try to deploy the "Sony Ericsson PC Suite.msi" package once more and doing some major waiting.
Came back and the installation was finished!
MSI (s) (E0:F8) [12:03:01:175]: Doing action: Update_Environmet
InstallShield 12:03:03: Registering Msi Server...
MSI (s) (E0!D0) [12:03:03:317]: Closing MSIHANDLE (105) of type 790531 for thread 464
-----------------------------------ONE HOUR WAITING-----------------------------------
MSI (s) (E0!D0) [13:02:38:897]: Creating MSIHANDLE (106) of type 790531 for thread 464
InstallShield 12:03:03: Invoking script function UpdateEnvironment
MSI (s) (E0!D0) [13:02:38:991]: Closing MSIHANDLE (106) of type 790531 for thread 464
Action ended 13:02:39: Update_Environmet. Return value 1.
...
Action ended 13:03:23: INSTALL. Return value 1.
So if I manually install my (custom) "Sony Ericsson PC Suite" package it takes like 10-15 minutes maximum and over 1 hour through Active Directory, yeay!
This happens weither the packages are installed nested or not.
We'll see If there is something we can do to speed this up abit.
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
anonymous_9363
16 years ago
GP deployment can sometimes take F O R E V E R for no apparent reason. There seems to be no pattern. Sometimes a package will install in minutes but after resetting the VM back to a snapshot and repeating the exact same install can take getting on for an hour. We just live with it and have decided to wait until the client decides to go for a more flexible deployment system. We are not holding our breath since GP is free and everything else costs money.
Posted by:
AngelD
16 years ago
GP deployment can sometimes take F O R E V E R for no apparent reason.
I do agree with you Ian and I guess in this case it has something to do with the access to the (InstallShield) support files.
But my intention with this post was just to provide some course of actions on how to go ahead with troubleshooting on a client where you're not able to access it physically. From the remote machine you can do as much troubleshooting as from the client itself, so I just throwed in some hints and tips on where to start looking and my steps from a real scenario I'm currently having.
If you for some reason do not know which application that is currently in progress you could always have a look at the "Pending Installation" (.IPI) file. When an installation is pending the InProgress registry key is present under "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer".
The default entry value refer to an .IPI file located under C:\WINDOWS\Installer. One .IPI file will exist so you don't really need to have a look in the registry to find it. So to find out more about the installation in progress open the .IPI file using a text editor such as notepad.
You can find helpful information about:
The path to the cached msi which the pending installation is running from
The Product Code for the pending installation
The user who launched the installation
Any public property passed to the msi
I do agree with you Ian and I guess in this case it has something to do with the access to the (InstallShield) support files.
But my intention with this post was just to provide some course of actions on how to go ahead with troubleshooting on a client where you're not able to access it physically. From the remote machine you can do as much troubleshooting as from the client itself, so I just throwed in some hints and tips on where to start looking and my steps from a real scenario I'm currently having.
If you for some reason do not know which application that is currently in progress you could always have a look at the "Pending Installation" (.IPI) file. When an installation is pending the InProgress registry key is present under "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer".
The default entry value refer to an .IPI file located under C:\WINDOWS\Installer. One .IPI file will exist so you don't really need to have a look in the registry to find it. So to find out more about the installation in progress open the .IPI file using a text editor such as notepad.
You can find helpful information about:
The path to the cached msi which the pending installation is running from
The Product Code for the pending installation
The user who launched the installation
Any public property passed to the msi
Posted by:
AngelD
16 years ago
I wanted to know what the CA_CABLEDRIVER_WritePath and Update_Environmet custom actions actually performed so I will know how to handle these and to deploy "Sony Ericsson PC Suite" through Group Policy without having to wait for 2 hours (1 hour per package).
As manually installing these two packages ("Sony Ericsson Drivers.msi" and "Sony Ericsson PC Suite.msi") didn't "freeze" the different custom actions (CA_CABLEDRIVER_WritePath and Update_Environmet) I decided to go back to basic troubleshooting.
For "Sony Ericsson Drivers.msi" I added a simple vbscript to display a messagebox right before the CA_CABLEDRIVER_WritePath custom action. Didn't need to add another one after this custom action as this one was the last executed before the InstallFinalize action.
CustomAction table
Action Type Source Target
CA_DEBUG1 3174 Call MsgBox("Before CA_CABLEDRIVER_WritePath")
InstallExecuteSequence table
Action Condition Sequence
CA_DEBUG1 NOT Installed 6500
Manually executed "Sony Ericsson Drivers.msi" and when the messagebox came up I basically did a pre-snapshot.
When the messagebox "Before CA_CABLEDRIVER_WritePath" turned up I simply clicked OK and when the installation had ended I did my post-snapshot.
So how come it will take 1 hour for the CA_CABLEDRIVER_WritePath custom action to update the "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath" (REG_EXPAND_SZ) registry entry and nothing more?
The value had now been changed from "%SystemRoot%\inf" to "%SystemRoot%\inf;C:\Program Files\Common Files\Teleca Shared\DCU-11;C:\Program Files\Common Files\Teleca Shared\DSS-20;C:\Program Files\Common Files\Teleca Shared\DSS-25".
To solve this I will prevent the custom action (CA_CABLEDRIVER_WritePath) from being executed and make sure these USB drivers are pre-installed into the DRVSTORE folder by either using the DPinst.exe or the DIFxApp.msm merge module instead.
I did the same for the Update_Environmet custom action for the "Sony Ericsson PC Suite.msi" package but also added one messagebox after the custom action to minimize the captured information.
CustomAction table
Action Type Source Target
CA_DEBUG1 102 Call MsgBox("Before Update_Environmet")
CA_DEBUG2 102 Call MsgBox("After Update_Environmet")
InstallExecuteSequence table
Action Condition Sequence
CA_DEBUG1 NOT Installed 1500
CA_DEBUG2 NOT Installed 1510
Did my pre- and post-snapshot and a dead end. Nothing had been captured.
So I took another approach.
I launched Process Monitor from Sysinternals/Microsoft and enabled capture when the "Before Update_Environmet" messagebox showed up.
Clicked OK and when the final "After Update_Environmet" message came up I turned off capture-mode in ProcMon and saved the "PML" (log) file for later use.
Did a quick sweep through the log entries that was created during the execution of the Update_Environmet custom action and it's basically alot of open, close and query events.
Havn't found any special information yet that I need to replace to be able to disable the Update_Environmet custom action.
I guess the solution for this last custom action will be my next post.
As manually installing these two packages ("Sony Ericsson Drivers.msi" and "Sony Ericsson PC Suite.msi") didn't "freeze" the different custom actions (CA_CABLEDRIVER_WritePath and Update_Environmet) I decided to go back to basic troubleshooting.
For "Sony Ericsson Drivers.msi" I added a simple vbscript to display a messagebox right before the CA_CABLEDRIVER_WritePath custom action. Didn't need to add another one after this custom action as this one was the last executed before the InstallFinalize action.
CustomAction table
Action Type Source Target
CA_DEBUG1 3174 Call MsgBox("Before CA_CABLEDRIVER_WritePath")
InstallExecuteSequence table
Action Condition Sequence
CA_DEBUG1 NOT Installed 6500
Manually executed "Sony Ericsson Drivers.msi" and when the messagebox came up I basically did a pre-snapshot.
When the messagebox "Before CA_CABLEDRIVER_WritePath" turned up I simply clicked OK and when the installation had ended I did my post-snapshot.
So how come it will take 1 hour for the CA_CABLEDRIVER_WritePath custom action to update the "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath" (REG_EXPAND_SZ) registry entry and nothing more?
The value had now been changed from "%SystemRoot%\inf" to "%SystemRoot%\inf;C:\Program Files\Common Files\Teleca Shared\DCU-11;C:\Program Files\Common Files\Teleca Shared\DSS-20;C:\Program Files\Common Files\Teleca Shared\DSS-25".
To solve this I will prevent the custom action (CA_CABLEDRIVER_WritePath) from being executed and make sure these USB drivers are pre-installed into the DRVSTORE folder by either using the DPinst.exe or the DIFxApp.msm merge module instead.
I did the same for the Update_Environmet custom action for the "Sony Ericsson PC Suite.msi" package but also added one messagebox after the custom action to minimize the captured information.
CustomAction table
Action Type Source Target
CA_DEBUG1 102 Call MsgBox("Before Update_Environmet")
CA_DEBUG2 102 Call MsgBox("After Update_Environmet")
InstallExecuteSequence table
Action Condition Sequence
CA_DEBUG1 NOT Installed 1500
CA_DEBUG2 NOT Installed 1510
Did my pre- and post-snapshot and a dead end. Nothing had been captured.
So I took another approach.
I launched Process Monitor from Sysinternals/Microsoft and enabled capture when the "Before Update_Environmet" messagebox showed up.
Clicked OK and when the final "After Update_Environmet" message came up I turned off capture-mode in ProcMon and saved the "PML" (log) file for later use.
Did a quick sweep through the log entries that was created during the execution of the Update_Environmet custom action and it's basically alot of open, close and query events.
Havn't found any special information yet that I need to replace to be able to disable the Update_Environmet custom action.
I guess the solution for this last custom action will be my next post.
Posted by:
AngelD
16 years ago
So a little follow up.
After being away for a week (skiing) I decided to deploy the package without the "Update_Environmet" custom action.
Everthing went like a clock so the problem with the 2 hour deployment is gone.
The hardware wizard installed the related mobile drivers when I plugged in the hardware (USB-cable).
There are two different modes you can select for the mobile while you connect it to the computer with the USB-cable; Transfer- and Phone mode.
Selecting the Transfer-mode some additional drivers were installed and the phone was visible through windows explorer.
To be able to syncronize your contacts and so on with ex. outlook you'll need to select Phone-mode instead and so that I did.
The PC Suite application did not recognize that the mobile was connected while selecting this mode, very annoying.
After some time I just tried to repair the application and you know what? the connected mobile was recognized.
I did a snapshot during the repair and the COM- registration information was written for 5 DLLs.
So I solved this by extracting the registration info from:
[ProgramFilesFolder]Sony Ericsson\Mobile2\OCS\ObexAuthenticationServiceDll.dll
[ProgramFilesFolder]Sony Ericsson\Mobile2\OCS\ObexOperationDll.dll
[ProgramFilesFolder]Sony Ericsson\Mobile2\DynDataProv\DDPObexCap.dll
[CommonFilesFolder]Sony Ericsson Shared\SpecificMPM.dll
[CommonFilesFolder]Sony Ericsson Shared\DeviceStateMPM.dll
and imported them to the package (transform).
Did a clean install and everything worked like it should with both modes (Transfer and Phone).
After being away for a week (skiing) I decided to deploy the package without the "Update_Environmet" custom action.
Everthing went like a clock so the problem with the 2 hour deployment is gone.
The hardware wizard installed the related mobile drivers when I plugged in the hardware (USB-cable).
There are two different modes you can select for the mobile while you connect it to the computer with the USB-cable; Transfer- and Phone mode.
Selecting the Transfer-mode some additional drivers were installed and the phone was visible through windows explorer.
To be able to syncronize your contacts and so on with ex. outlook you'll need to select Phone-mode instead and so that I did.
The PC Suite application did not recognize that the mobile was connected while selecting this mode, very annoying.
After some time I just tried to repair the application and you know what? the connected mobile was recognized.
I did a snapshot during the repair and the COM- registration information was written for 5 DLLs.
So I solved this by extracting the registration info from:
[ProgramFilesFolder]Sony Ericsson\Mobile2\OCS\ObexAuthenticationServiceDll.dll
[ProgramFilesFolder]Sony Ericsson\Mobile2\OCS\ObexOperationDll.dll
[ProgramFilesFolder]Sony Ericsson\Mobile2\DynDataProv\DDPObexCap.dll
[CommonFilesFolder]Sony Ericsson Shared\SpecificMPM.dll
[CommonFilesFolder]Sony Ericsson Shared\DeviceStateMPM.dll
and imported them to the package (transform).
Did a clean install and everything worked like it should with both modes (Transfer and Phone).
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.