Trying to deploy an agent across a lot of systems. My fixlet downloads the .msi, creates a batchfile and runs the batchfile. Here’s the batch file:
delete __createfile
createfile until ThisIsTheEnd
@echo off
c:
cd c:\temp\IPAMInstall
Men_and_Mice_Controllers_x64_10.3.4.exe /s /v"/qn /L*V C:\temp\IPAMInstall\controllerInstall.log REBOOT=ReallySuppress ADDLOCAL={parameter "AppInstall"}"
ThisIsTheEnd
delete c:\temp\IPAMInstall\InstallIPAM.cmd
copy __createfile c:\temp\IPAMInstall\InstallIPAM.cmd
action uses wow64 redirection false
dos "c:\temp\IPAMInstall\InstallIPAM.cmd"
It creates the batch file, it generates the controllerInstall.log so I at least know it’s trying, but neither the control log nor the BES log have any info on why it fails to install. I’ve tried both with and without the redirection, same failure.
If I log in and run the batch file interactively it quietly does it without issue, error, or popup.
I’ve been beating my brains out over this for a week, hoping the experts here can spot what I’ve missed.
Apologies, the parameter is defined higher up, I didn’t want to dump the whole script here to save space, especially because the fixlet properly creates the file that runs if I execute it locally. Here’s the bit that defines the parameter:
if {exists service “DNS”}
parameter “AppInstall” = “DNS”
else
parameter “AppInstall” = “DHCP”
endif
I tried waithidden cmd.exe /c, same deal. Creates the file, controllerlog is created so it tries, but the app is not installed and the service is not created. Testing in BES and cmd, the controllerlog has a difference, but I’m no msi expert and nothing stands out, though I suspect it’s what was discussed in another post, it doesn’t like being installed as SYSTEM.
Failed controllerlog entries:
MSI (s) (10:2C) [14:23:45:314]: Machine policy value ‘Debug’ is 0
MSI (s) (10:2C) [14:23:45:314]: ******* RunEngine:
******* Product: C:\Windows\system32\config\systemprofile\AppData\Local{97B82ACF-EFFD-452B-87D9-01FB3337B1CD}\Men and Mice Controllers.msi
******* Action:
******* CommandLine: **********
MSI (s) (10:2C) [14:23:45:314]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\Local{97B82ACF-EFFD-452B-87D9-01FB3337B1CD}\Men and Mice Controllers.msi 3: -2147287037
MSI (s) (10:2C) [14:23:45:314]: MainEngineThread is returning 3
MSI (s) (10:DC) [14:23:45:314]: User policy value ‘DisableRollback’ is 0
MSI (s) (10:DC) [14:23:45:314]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (10:DC) [14:23:45:314]: Incrementing counter to disable shutdown. Counter after increment: 0
Successful
MSI (s) (B4:0C) [14:39:57:985]: Machine policy value ‘Debug’ is 0
MSI (s) (B4:0C) [14:39:57:985]: ******* RunEngine:
******* Product: C:\Users\mfg_cpinckar.AMR\AppData\Local{97B82ACF-EFFD-452B-87D9-01FB3337B1CD}\Men and Mice Controllers.msi
******* Action:
******* CommandLine: **********
MSI (s) (B4:0C) [14:39:58:017]: Machine policy value ‘DisableUserInstalls’ is 0
MSI (s) (B4:0C) [14:39:58:049]: Note: 1: 2203 2: C:\Windows\Installer\inprogressinstallinfo.ipi 3: -2147287038
MSI (s) (B4:0C) [14:39:58:049]: SRSetRestorePoint skipped for this transaction.
MSI (s) (B4:0C) [14:39:58:049]: File will have security applied from OpCode.
A couple years back, I had one installer that gave errors when running as system because it was expecting administrator rights. It was hard coded into their installer. Since we had some weight with that vendor, I pointed out their stupidity.
I wish I had an answer to give you on how I solved it, but I honestly don’t recall and my documentation & fixlets are not showing the workaround… I recall figuring it out by reading the install logs.
You may want to try and run your fixlet with administrator using runas as a test…
I’ve no weight with this vendor. I’m suspecting that you’re correct, but I don’t know if I can runas admin in a fixlet when each box has a different, vault-managed admin pwd…which means I’m installing on 100s of systems by hand.
Hi @iMacAllen one suggestion is to download psexec.exe and run:
psexec.exe -i -s cmd.exe
Then attempt to install interactively and/or silently and see if the installer can report to you what is the root of the problem. The goal is to run the installer as system as depicted below and see if it provides any additional information why it is failing to install:
My problem is that it has no problems interactively. BES makes the batch file, runs it, fails to install. I log into the system and run the same batch file and it runs, quietly and successfully.
What I’m going to try to do next is have BES do a “run now” schdtask and see if that works.
Hi @iMacAllen, when you log into the system, you’re using an administrative user account based on the install logs you provided above versus when the BigFix agent is installing this package. BigFix agent is using the local system account to perform this action. You can attempt to duplicate how BigFix attempts to install this package via the instructions I previously provided. -Gus
I know. Using SchdTask does the same thing. I run it interactively to get a system command prompt, and if it works I just use it to run the task from BES. I’ll report out here if it works, thanks
I’m aware of at least one package (Oracle JRE) that does…really strange things based on the USER PROFILE or APP DATA directories when it installs, and doesn’t behave well using LocalSystem in either 32- or 64-bit context or both.
If your manually install as LocalSystem also does not work, check our JRE fixlets in “Updates for Windows Applications” to see our workarounds (creating a symlink for one of LocalSystem’s Profile directories). Try that manually and see whether it helps.
(I kind of hope it doesn’t, because then I’ll know if two packages with this ugly behavior.)
I think vendor escalation is the right path, and using Task Scheduler or psexec gives them a way to reproduce it without BigFix in the path, so that’s good.
If you do try to pursue it further yourself, I’ve found useful details before by using ‘procmon’ to log the low level files & registry entries the installer is accessing. Sometimes a “path not found” result can show some profile directory it’s trying to use, that may not exist for SYSTEM
JRE - found the best way of installing is to extract the msi from the exe and run the msi within BF. Msi can be extracted when you initially run the exe but do not click yes to install, msi is in appdata. hope this helps.
Yes, it’s the same batch job. The BES fixlet deposits a batch job on the system with the binaries, then runs it (as wait hidden or schtasks, tried both) and it tries to install and backs out. I then go to the system, log it as me, run the same batch file and it works, both from the command line and from schtask. I then launched a cmd prompt as system and did the same test, it fails. It’s not BES, the installer doesn’t like system.
