When deploying an update to the ZCM Agent on various workstations from 10.2 (exact sub-version unknown, I can get it if necessary) to 10.3.3 with the requisite stopover at 10.3.0a, in many though not all cases the update "hangs" waiting for CASA.MSI to be processed.

During the processing of CASA.MSI, it launches a sub-process of 'micasad.exe /install'. (In some cases it does this twice, the second time with additional arguments for a REINSTALL scenario.)

micasad.exe itself then launches a sub-process of 'regsvr32 /s /n /i lcredmgr.dll' (with full paths, et cetera). This process apparently never returns.

If I run the regsvr32 command by hand, it completes instantly, with no errors.

If I use Task Manager to kill the "hung" regsvr32 process which was launched by micasad - with or without having run the same command by hand - micasad proceeds from there, and the install continues, to finish without errors. (In cases where micasad is launched again for a REINSTALL scenario, the same hang often repeats, but the same fix of killing regsvr32 fixes it.)

If I instead use Task Manager to kill micasad.exe, CASA rolls itself back and the install continues, but finishes with an error (because CASA wasn't upgraded properly). Repairing this scenario requires jumping through quite a few hoops, and I haven't found a single consistent fix yet.

Additional data:

* This update has been attempted on both XP SP2 and XP SP3, but to date the hang has been seen only on SP3. (We are only now deploying Windows 7, so we're not deploying 10.3.3 there as an update, but it has had no problems in from-scratch install so far.)

* The hang is not universally consistent. In a few cases, the install proceeded flawlessly. The hardware involved in those cases is identical to the ones where it failed, and the machines involved were built from the same image, although that was in January and they may have diverged since then. This success happened in roughly 4 cases out of 25; I have not managed to identify any common factor.

* I am not positive, but I believe that the hang has occurred only in the 10.3.0a phase of the update, not in the 10.3.3 phase.

Any ideas what might be causing this?

Failing that, any ideas for how to work around it by automating the "wait for regsvr32.exe to hang, then kill it so the install can proceed" process? (Keeping in mind that of course we can't run bundles during all this.)