Run Failed exit code 4294967295

[Migration User]

This has been the week of issues and errors received in our environement. 

Here's one more scenario:

I have staged an Acrobat Pro 7 update (.msp) to existing Acro installs.

What I am seeing is that I am getting a 50% success rate on the installs.  On the failures, I get Failed exit code 4294967295.  

When I remote control the systems with the failed runs, I can manually kick off the job within the Altiris Agent and runs/installs as expected and reports successfully.  

I verified in my testing that the update doesn't care if Adobe is running or not - will update as expected.

I googled this error message, no luck understanding the cause.  

Anyone ever experience and resolve?  

[Migration User]

• Command line
• Run with Rights - logged on user, system, specified
• Are you using an installer or script

The error is a Microsoft hex error, which you could translate, but most often isn't that useful. You could give it a shot though..

Altiris KB2113

which references

Microsoft KB 186063

[Migration User]

Jim - using straight up .exe from Adobe download - no mod's.

Command line: AcroProUpd710_all_cum.exe /Q /NORESTART
Run with Rights: System Account - always the same
Program can Run: whether or not user is logged in

Very odd behavior that the job works as it should on some systems, others it doesn't and needs to be tickled to run.  To tickle, I've been using Remote Altiris Agent Diagnostics.exe to conenct to the agent and run the job on the failed ones...not the best use of my time.  

I wonder if by disabling the task and re-enable to fix.  I have had to do this before in sequential tasks but not for this type of error.  

[Migration User]

Translating the hex leads to a mound of garbage. FFFFFFFF00000001, which means absolutely nothing, at least in the sense of helping here.

One comment to make. You mentioned it was an .msp but then refer to an .exe. It could be something simple like versioning issues or some clients not understanding how to execute the .msp once it's extracted. I would try extracting the .msp (from the .exe) and then using the following for a command line - %windir%\system32\msiexec.exe /p "xxx.msp" /q

[Migration User]

Yeah, I translated it to hex, didn't mean anything to me either.  

I did mention that it was an. msp originally then I mentioned it was an .exe.  IT is a .exe I just did a mistype because I'm doing Adobe Acrobat Updates to all versions and v 8&9 are all .msp's.  

I know the job is solid as an executable because of when I tickle the task manually from within the agent on a failed system.  

This one has be challeneged for sure.  

Thanks for your input.  

[Migration User]

If these exe's are kicking off msp updates, that should be logged in the app or sys event log on the client machine.  Are there any errors logged in either at the time of the error for these?  Often those windows installer errors are a little more descriptive.  Is it possible its failing due to acrobat being open at the time of install on the client machines?  Can you enable verbose logging on the package to get a better view into what might be failing?

[Migration User]

I haven't looked at the individual system log files.  

I thought at first if Adobe Acrobat was open, it would fail but in testing, the job didn't show this behavior when Adobe was open.  

Verbose logging is enabled.  Where do I see the details?  On the client system?

[Migration User]

Typically the directory where the verbose log is stored is specified in the command line after the /L*v command line option for an msi or msp install.  I know Adobe provides a nice little gui for creating the package, so not sure if that's specified in there or not.

I think I'd start by checking out the app and sys event logs on a client though.  The verbose logging out of an msi\msp install is pretty difficult imo to find the actual error.