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?


EDIT: i have tried the -sms switch, which doesnt help
Answer Summary:
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


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.

- 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"
Answered 03/12/2009 by: VBScab
Red Belt

Please log in to comment
thanks fo the info! I think I'll try re-packaging it with installshield
Answered 03/12/2009 by: smsguy
Senior Yellow Belt

Please log in to comment
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...
Answered 03/13/2009 by: VBScab
Red Belt

Please log in to comment