Siemens HiPath ProCenter Client 7.0 R3
Good afternoon all,
I am attempting to package OpenScape Contact Center Enterprise V7.0 R3 Client (A.K.A Siemens HiPath ProCenter Client 7.3.0.544). The source media has been provided in the form of a vendor MSI (HiPath ProCenter Client.msi), vendor MSP (OSCC70R3G03Client.msp) and exetrnal cab file. My normal approach to this would be to create an Admin Install of the MSI and the stream the MSP into that AI. Unfortunately, whilst I can create the AIP using the MSI I am unable to apply the MSP file. The account I am using has full permissions on the AIP directory and all files contained within. I have also created an AIP using shortfilenames but attempts to apply the MSP file yields the same results.
1. MSIEXEC /a HiPath ProCenter Client.msi - works as expected and produces an AIP
2. MSIEXCEC /p OSCC70R3G03Client.msp /a <path to AIP>\HiPath ProCenter Client.msi - Fails and produces the following error
Error 25014. Installation operation failed. See the log file HPPCInstall.log located in your TEMP directory for details.
Unfortunately, HPPCInstall.log doesn't actually get created anywhere on the target PC. I have run verbose logging against step 2 above and believe the extract below is the relevant section:
Action 10:18:51: CopyClientFiles.
MSI (s) (94:30) [10:18:51:737]: Executing op: CustomActionSchedule(Action=CopyClientFiles,ActionType=1025,Source=BinaryData,Target=CopyClientFiles,CustomActionData=C:\Temp\hipath\OpenScape Contact Center Client\AIC:\Temp\hipath\OpenScape Contact Center Client\AI{5A844150-214F-4EF1-A7C2-4B1D2EE65912})
MSI (s) (94:AC) [10:18:51:768]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI65E.tmp, Entrypoint: CopyClientFiles
(HPPC 10:18:51:987) INFO: Copying File: "C:\Temp\hipath\OpenScape Contact Center Client\AI\0x0407.ini"
(HPPC 10:18:52:002) ERROR: "CopyFile()" failure. "GetLastError()" returned 32 (the process cannot access the file because it is being used by another process). SourceFile="C:\Temp\hipath\OpenScape Contact Center Client\AI\0x0407.ini", TargetFile="C:\Temp\hipath\OpenScape Contact Center Client\AI\0x0407.ini", FailIfExists=0, OverwriteIfReadOnly=1. Detected in source file ".\tincgnCopyFile.cpp" (line 165)
MSI (c) (B4:BC) [10:18:52:018]: Transforming table Binary.
MSI (c) (B4:BC) [10:18:52:033]: Transforming table Binary.
MSI (c) (B4:BC) [10:18:52:033]: Note: 1: 2262 2: Binary 3: -2147287038
Error 25014.Installation operation failed. See the log file HppcInstall.log located in your TEMP directory for details.
MSI (s) (94!6C) [10:20:10:191]: Product: OpenScape Contact Center Enterprise V7.0 R3 Client -- Error 25014.Installation operation failed. See the log file HppcInstall.log located in your TEMP directory for details.
Action ended 10:20:10: InstallFinalize. Return value 3.
The MSI and MSP install fine as a manual install but the MSI requires a reboot before the MSP can be applied. The MSI installs version 7.3.0.544 with the MSP patching that install up to 7.3.3.129.
Has anyone come across a similar issue with Hipath or indeed with any other application while attempting this approach? Any input or suggestions would be gladly received.
Thanks in advance,
AD.
I am attempting to package OpenScape Contact Center Enterprise V7.0 R3 Client (A.K.A Siemens HiPath ProCenter Client 7.3.0.544). The source media has been provided in the form of a vendor MSI (HiPath ProCenter Client.msi), vendor MSP (OSCC70R3G03Client.msp) and exetrnal cab file. My normal approach to this would be to create an Admin Install of the MSI and the stream the MSP into that AI. Unfortunately, whilst I can create the AIP using the MSI I am unable to apply the MSP file. The account I am using has full permissions on the AIP directory and all files contained within. I have also created an AIP using shortfilenames but attempts to apply the MSP file yields the same results.
1. MSIEXEC /a HiPath ProCenter Client.msi - works as expected and produces an AIP
2. MSIEXCEC /p OSCC70R3G03Client.msp /a <path to AIP>\HiPath ProCenter Client.msi - Fails and produces the following error
Error 25014. Installation operation failed. See the log file HPPCInstall.log located in your TEMP directory for details.
Unfortunately, HPPCInstall.log doesn't actually get created anywhere on the target PC. I have run verbose logging against step 2 above and believe the extract below is the relevant section:
Action 10:18:51: CopyClientFiles.
MSI (s) (94:30) [10:18:51:737]: Executing op: CustomActionSchedule(Action=CopyClientFiles,ActionType=1025,Source=BinaryData,Target=CopyClientFiles,CustomActionData=C:\Temp\hipath\OpenScape Contact Center Client\AIC:\Temp\hipath\OpenScape Contact Center Client\AI{5A844150-214F-4EF1-A7C2-4B1D2EE65912})
MSI (s) (94:AC) [10:18:51:768]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI65E.tmp, Entrypoint: CopyClientFiles
(HPPC 10:18:51:987) INFO: Copying File: "C:\Temp\hipath\OpenScape Contact Center Client\AI\0x0407.ini"
(HPPC 10:18:52:002) ERROR: "CopyFile()" failure. "GetLastError()" returned 32 (the process cannot access the file because it is being used by another process). SourceFile="C:\Temp\hipath\OpenScape Contact Center Client\AI\0x0407.ini", TargetFile="C:\Temp\hipath\OpenScape Contact Center Client\AI\0x0407.ini", FailIfExists=0, OverwriteIfReadOnly=1. Detected in source file ".\tincgnCopyFile.cpp" (line 165)
MSI (c) (B4:BC) [10:18:52:018]: Transforming table Binary.
MSI (c) (B4:BC) [10:18:52:033]: Transforming table Binary.
MSI (c) (B4:BC) [10:18:52:033]: Note: 1: 2262 2: Binary 3: -2147287038
Error 25014.Installation operation failed. See the log file HppcInstall.log located in your TEMP directory for details.
MSI (s) (94!6C) [10:20:10:191]: Product: OpenScape Contact Center Enterprise V7.0 R3 Client -- Error 25014.Installation operation failed. See the log file HppcInstall.log located in your TEMP directory for details.
Action ended 10:20:10: InstallFinalize. Return value 3.
The MSI and MSP install fine as a manual install but the MSI requires a reboot before the MSP can be applied. The MSI installs version 7.3.0.544 with the MSP patching that install up to 7.3.3.129.
Has anyone come across a similar issue with Hipath or indeed with any other application while attempting this approach? Any input or suggestions would be gladly received.
Thanks in advance,
AD.
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
nheim
14 years ago
Hi Adrian,
this is definitely a bug in the MSI authoring. The error is caused by an action in the AdminExecuteSequence table (ProcessClientFiles), which is well meant, but causes the file access problem. This action combines the patching and the copying of the Windows Installer 4.5 installation file (WindowsXP-KB942288-v3-x86.exe) from the source directory (which BTW doesn't make sense at all, because the MSI itself is a version 3.01 database).
Please report this bug back to the vendor.
There are two fast solutions to this problem:
1. Just do the patching until it errors out. Let it stay like this and copy the hole AIP-directory to a new one and use this directory. That's all!
2. Edit the MSI and change the condition of the offending action to one, which never resolves to true.
Then create a new action in AdminExecuteSequence, called "PatchFiles" with a sequence of 4006. That's all.
Regards, Nick
this is definitely a bug in the MSI authoring. The error is caused by an action in the AdminExecuteSequence table (ProcessClientFiles), which is well meant, but causes the file access problem. This action combines the patching and the copying of the Windows Installer 4.5 installation file (WindowsXP-KB942288-v3-x86.exe) from the source directory (which BTW doesn't make sense at all, because the MSI itself is a version 3.01 database).
Please report this bug back to the vendor.
There are two fast solutions to this problem:
1. Just do the patching until it errors out. Let it stay like this and copy the hole AIP-directory to a new one and use this directory. That's all!
2. Edit the MSI and change the condition of the offending action to one, which never resolves to true.
Then create a new action in AdminExecuteSequence, called "PatchFiles" with a sequence of 4006. That's all.
Regards, Nick
Posted by:
anonymous_9363
14 years ago
Use WhoLockMe (freeware) to find out if that INI file is actually in use and, if so, by whom/which process.
Posted by:
deepak_2007
14 years ago
It happens once in a bluemoon that admin install is vague.
In your case , I would suggest to add the patch instllation command in runonce which would enable patch to run once the PC restarts .
In your case , I would suggest to add the patch instllation command in runonce which would enable patch to run once the PC restarts .
Posted by:
AD
14 years ago
Thanks for the replies VBScab & deepak. Unfortunately, 0x0407.ini is simply where the Windows Installer is taking the error code to display in the Event Viewer from:
1603=Error installing Windows Installer engine. A file which needs to be replaced may be held in use. Close all applications and try again.
I don't think it's integral to the process. Some file is obviously getting locked but even Procmon isn't proving particularly helpful.
I am hoping I don't have to apply any messy workarounds. I can't imagine Siemens would not have a proven method for rolling this app out to a corporate environment. I have logged a call with Siemens and am waiting on them to get back to me. They're taking their time though. I logged it 6 hours ago. If they do offer a satisfactory solution I will post it up here. In the meantime, if anyone has any more suggestions I'm all ears [8|]
1603=Error installing Windows Installer engine. A file which needs to be replaced may be held in use. Close all applications and try again.
I don't think it's integral to the process. Some file is obviously getting locked but even Procmon isn't proving particularly helpful.
I am hoping I don't have to apply any messy workarounds. I can't imagine Siemens would not have a proven method for rolling this app out to a corporate environment. I have logged a call with Siemens and am waiting on them to get back to me. They're taking their time though. I logged it 6 hours ago. If they do offer a satisfactory solution I will post it up here. In the meantime, if anyone has any more suggestions I'm all ears [8|]
Posted by:
nheim
14 years ago
Hi AD,
this sounds like a malformed AdminExecuteSequence table.
Could you upload the MSI and the MSP to a free ftp service like senduit and post us the link?
So, i could get a look at them.
Regards, Nick
this sounds like a malformed AdminExecuteSequence table.
Could you upload the MSI and the MSP to a free ftp service like senduit and post us the link?
So, i could get a look at them.
Regards, Nick
Posted by:
joedown
14 years ago
Nick is probably correct but just for testing purposes have you attempted to create you AIP on the local workstation and applying the patch to that? I've seen issues with network shares in the past when creating AIPs.
Posted by:
AD
14 years ago
Nick - I have uploaded the MSI & MSP to Senduit - http://senduit.com/82de98. They will be available for 1 week so if you do get a chance to have a look it would be much appreciated. I'm not sure you'll be able to tell a lot from them. As I said the creation of the AIP for the MSI is absolutely fine. I only run into issues when I attempt to stream in the MSP.
Joedown - I wish it was that easy [:)] I've come accross that issue before and have been trying to create the AIP under C:\Temp on my loocal machine. Always worth a mention though so thanks for your reply.
Joedown - I wish it was that easy [:)] I've come accross that issue before and have been trying to create the AIP under C:\Temp on my loocal machine. Always worth a mention though so thanks for your reply.
Posted by:
AD
14 years ago
Brilliant Nick, Absolutely Brilliant!!
Thank you so much for taking the time to look into this. I have tested both solutions and both work. I have rated your post. I honestly wish I could rate it 100 times.
I will make the Siemens aware of this. I'm not sure they will take an interest given that I have heard absolutely nothing from them since I logged the call with them. They haven't even replied to my queries regarding Windows Installer 4.5. I can only hope they take it on board. I'll be disappointed if they don't but I guess all will become clear when we get the next release.
Thanks again for all your help.
Regards,
AD.
Thank you so much for taking the time to look into this. I have tested both solutions and both work. I have rated your post. I honestly wish I could rate it 100 times.
I will make the Siemens aware of this. I'm not sure they will take an interest given that I have heard absolutely nothing from them since I logged the call with them. They haven't even replied to my queries regarding Windows Installer 4.5. I can only hope they take it on board. I'll be disappointed if they don't but I guess all will become clear when we get the next release.
Thanks again for all your help.
Regards,
AD.
Posted by:
nortonl
13 years ago
I had this problem today.
Another option to patch is to specify SKIP_ADMIN_CA=Yes on the patch command line as ProcessClientFiles has the condition 'Not SKIP_ADMIN_CA'.
Another option to patch is to specify SKIP_ADMIN_CA=Yes on the patch command line as ProcessClientFiles has the condition 'Not SKIP_ADMIN_CA'.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.