returning error codes to SCCM
Hey
Im deploying IBM Client Access through sccm silently. I created an answer file and use the following command line to install:
\\path\SETUP.EXE -s -f1"path\setup.iss" -f2c:\ibm.log
this works fine but sccm always reports as completing successfully. A lot of the pc's it is being pushed out to havent been restarted since an uninstall of an older version was done, so in the log file they are coming up as -12
I have 1200 pcs to install this to and it would really help if I could tell which ones got an error code of 0 and which ones returned 12
any ideas? do I need to do it through a script of some sort?
thanks
EDIT: i have tried the -sms switch, which doesnt help
Im deploying IBM Client Access through sccm silently. I created an answer file and use the following command line to install:
\\path\SETUP.EXE -s -f1"path\setup.iss" -f2c:\ibm.log
this works fine but sccm always reports as completing successfully. A lot of the pc's it is being pushed out to havent been restarted since an uninstall of an older version was done, so in the log file they are coming up as -12
I have 1200 pcs to install this to and it would really help if I could tell which ones got an error code of 0 and which ones returned 12
any ideas? do I need to do it through a script of some sort?
thanks
EDIT: i have tried the -sms switch, which doesnt help
0 Comments
[ + ] Show comments
Answers (3)
Answer Summary:
Please log in to answer
Posted by:
anonymous_9363
15 years ago
SCCM and MSI were made for each other. Convert the legacy setup stub and your answer file to an MSI Or, if you don't have InstallShield - [hint] trial versions are available [/hint] - then capture it to an MSI.
IIRC, the Client Access reboot is unnecessary. From memory, it only needs it because a) IBM is too stupid to work out how to write software which doesn't need to use PATH to find its files and b) it's equally too stupid to work out that adding its location to the User PATH, rather than the System PATH, negates the need to reboot. Having said that, at one client, things like the log-in dialog took a long, long time to appear without a reboot having been done. YMMV.
So, that gives you two potential routes: re-package and program-out the reboot or write a script which 'moves' the PATH addition from System to User.
Notes:
- The IS converter doesn't make a particularly good job with feature names for the converted MSI. You may want to rename them as you go.
- If you go the re-package route, your authoring software *may* error as it tries to extract COM information from Client Access's DLLs. This is because IBM is too stupid to work out what compiler switch to use so that the files do not contain the DLLRegisterServer entry-point. Consequently, the 2 major vendor's tools see that entry-point, they then attempt to extract the COM information and obviously fail. For CA, turn that option off. You *then* have to use IBM's own registration tool CWBSREG.EXE to register the DLLs.
Lastly, watch out for the registry fix-ups which the vendor install applies. It changes some Prog IDs from those inside the DLL in question. For example, the ProgID in cwbunshf.dll is "IBM.AS400.Network" but the fix-up changes the registry entry to "IBM.AS400.Network.3.7.1"
IIRC, the Client Access reboot is unnecessary. From memory, it only needs it because a) IBM is too stupid to work out how to write software which doesn't need to use PATH to find its files and b) it's equally too stupid to work out that adding its location to the User PATH, rather than the System PATH, negates the need to reboot. Having said that, at one client, things like the log-in dialog took a long, long time to appear without a reboot having been done. YMMV.
So, that gives you two potential routes: re-package and program-out the reboot or write a script which 'moves' the PATH addition from System to User.
Notes:
- The IS converter doesn't make a particularly good job with feature names for the converted MSI. You may want to rename them as you go.
- If you go the re-package route, your authoring software *may* error as it tries to extract COM information from Client Access's DLLs. This is because IBM is too stupid to work out what compiler switch to use so that the files do not contain the DLLRegisterServer entry-point. Consequently, the 2 major vendor's tools see that entry-point, they then attempt to extract the COM information and obviously fail. For CA, turn that option off. You *then* have to use IBM's own registration tool CWBSREG.EXE to register the DLLs.
Lastly, watch out for the registry fix-ups which the vendor install applies. It changes some Prog IDs from those inside the DLL in question. For example, the ProgID in cwbunshf.dll is "IBM.AS400.Network" but the fix-up changes the registry entry to "IBM.AS400.Network.3.7.1"
Posted by:
smsguy
15 years ago
thanks fo the info! I think I'll try re-packaging it with installshield
Posted by:
anonymous_9363
15 years ago
Good choice.
BTW, don't you just LOVE the way IBM still cannot decide what this product is called? The shiny box says 'iSeries Access [blah, blah, blah]' but the version info for some of the files, lots of text in Help files and so on still refer to 'Client Access'. Still, it is only 7 (?) years since they changed the name...
BTW, don't you just LOVE the way IBM still cannot decide what this product is called? The shiny box says 'iSeries Access [blah, blah, blah]' but the version info for some of the files, lots of text in Help files and so on still refer to 'Client Access'. Still, it is only 7 (?) years since they changed the name...
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.