Silent MSI Installation

Hello guys, i'm currently working out an issue with the MSI installer for Nod32 3.0

I have gotten the msiexec command and properties worked out fine as;

msiexec /qn /i eavbe_nt32_enu.msi ADMINCFG="NodX86ver3config.xml" REBOOT="ReallySuppress"

The xml and package has been generated and retrieved through the admin console.

The issue is that part of the way through the installer it is coming up with unsigned driver messages asking to click continue for each one. This prompt will even appear if you force a complete silent install. There are three of these pop-ups that after looking in the MSI itself, conencides with 3 kernel drivers that need to be installed - however i've verified their catalogs to be fully signed on the same desktop.

Furthermore i've checked out the certificate service on this desktop and it is fine with all WHQL'ed drivers displaying in Device Manger & the latest third-party roots from MS installed.

Any ideas? its kinda got me stumped given its direct from eset! I called support this time last week, and which point i was told to email them about it - did so and have had no response so far

 

Still no resolution & still no reply to my support ticket!
I only bump this thread because i recently had a laptop with 'anti-virus 2009' that had gotten totally by a fully up to date NOD 2.7. Fortunately the user was a non-admin and the infection was limited to the users account, but this would be unacceptable if it happened to a large number of users!

 

FWIW this is what we do;

MSIEXEC /I "eavbe_nt32_enu.msi" /qn

and we have cfg.xml in the same directory, which is what it grabs.

It works about 95% of the time. Certain stations do not pull in the cfg.xml so I have to VNC into them and import the cfg.xml. This is all done from a c:\ location.

I recall some sort of issue with not using the default cfg.xml name. Not sure if that is applicable here.

 

Hi!

The ADMINCFG parameter doesn't work as it should (unless they have fixed it in .684). In my experience you need to name the file cfg.xml and place it in the same folder as the MSI-file or the installer will ignore it as "edwin3333" wrote.

Otherwise you could try the following which I have used several times:

MSIEXEC /i eavbe_nt32_enu.msi REBOOT="ReallySuppress" /qb-

 

Thanks for your replies fellas, unfortunately they both give me the same result as before.

I know the cryptographic service responsible for checking these signatures is working correctly afaik. I can confirm the validity of installed drivers in device manager due to this service. I have done a clean out of it on the test system i am working with as per internet faqs. This system has no other software installed, it is a clean setup of XP SP3.

In the end i came across a few guys working on a means to silently install drivers during an unattended install of XP here. At the end of it all they had a binary that will disable the signature validation temporarily. I've managed to install silently using this utility! I should be able to put together a script for this with a little time and get the new version of NOD deployed with some testing first of course.

wonderful support from eset btw, just wonderful..

 

You do have an AD domain? Group Policy, IntelliMirror available?

 

aye 700 odd PCs. We use SCCM 2007 to deploy software these days.

 

How many systems did you test this on? Frankly it sounds like something local is screwed up if you are seeing it complain about drivers not being signed when they clearly are.

 

Its beginning to look like some kind of policy related issue as i've got it repeating via a VM snapshot so that when its in a workgroup it does not pop up the message I'm going to have to debug all that now, but i just cant see what policy would be responsible for such a thing.

It is odd because while joined to the domain i can go and examine the cat's from an admined dump of the msi and it shows them to be fully legit by verisign till sometime in 2010!

Nonetheless it DID work earlier on like i said, but that appears to be an odd one off that makes even less sense really. Anyway i dont think that signature tool is really working for me after all..

 

After much digging around, it turned out to be remnants of a depreciated sign driver policy.

The policy itself had been long removed, but some registry was still left in the GPO and i had to manually remove that part and increment the version in SYSVOL.