AMON not enabled on first reboot

Hi everyone,
While I make the offline packages tests, I'm working on the installation of local workstations via the push method, and I've come across the following problem: installation is pushed and performed (with AMON set enabled and set to start automatically), user is queried to reboot, system restarts, all the modules load (IMON, EMON, DMON, automatic updates & all) but AMON is disabled (grey). Manual startup via the start button fails with: "No es posible cargar la protección de AMON, monitor del sistema de archivos."
The system needs a second restart to make AMON active.
Any ideas? I could have every wkstn reboot twice, but once should be more than enough...
Any extra setting I might have clicked on while creating the installation package that might be messing up the AMON startup?
Regards,
Kepler

--- Update

Here's the package xml configuration file: http://rapidshare.com/files/14270042/centro.xml.html

 

What previous antivirus was on that system?

Do you receive the same results on every push or just that one?

Cheers

 

Used to have TrendMicro, but it was uninstalled and rebooted the previous day

I had the same problem with a file server today. Trend had been removed and rebooted a couple of days ago. I didn't push the installation, but made it manual via VNC. The machine was rebooted and when I tried to start AMON manually I got the following message on my server log:

Module AMON
Type Warning
Event No es posible cargar la protección de AMON, monitor del sistema de archivos.

I didn't restart the server, but logged out and logged in with an administrator account. I was then able to start AMON, resulting in all my clients being unable to access all my server shares. I tried stopping AMON, unloading the antivirus with no success. I ended up disabling AMON and restarting the server.

I can't afford to see if the same happens if I reenable AMON after my second reboot since I have around 500 people accessing applications there, so I have to wait til 5AM to retry to see if the second reboot has solved my problems. In the meantime, I've got my server unprotected, and my fingers crossed (in case I get a virus outbreak, or my new antivirus decides to DoS me)

Ideas?

TIA

Kepler

 

Further investigation on the workstations issue proved this:
No problems on W95/98
No problems on W2K/XP
Problem on WNT4: I created a configuration package that has the "Start AMON automatically" option set by default, but my stations boot up with that option disabled by default. I have to set it to Yes manually or via conf. task and ask the user to reboot for the module to start. Anyone got a clue as to what might be causing these? I've got NT on more than 300 machines that I need to deploy, and this would be a real pain in the ********
Regards,
Kepler

 

Microsoft hasn't supported NT for quite some time. I would make sure each NT is fully patched.

You are deploying to an old problematic operating system that I know some tech's will not touch with a barge poll.

You will have to wait for someone to come along with other suggestions, while waiting you could send an email to the local NOD32 support office in your country.

Cheers

 

See if installing THIS on the NT servers helps.

Cheers

 

We'll... after searching and searching, and more searching, I came across this http://support.microsoft.com/kb/177078 regarding a setting on the LanMan service for NT Servers that proved to work on the servers, should somebody have this problem too.

I gotta check if this also applies to the glitch I'm having on my NT Workstations.

I agree on not wanting to touch the servers with a barge poll... but unfortunately, it's what I currently have & I can't wait to have all my computers updated (hard & soft) to deploy NOD32.

The local NOD32 tech guys are working on this too.

-- updated --

that setting doesn't solve my workstations lossing the "start automatically" setting problems

 

I have found out further information:

Cheers

 

Holly crap! Isn't there a way to prevent this? I'm talking about 300+ PCs that will require installation + reboot + configuration task + second reboot to be "protected"

Thx

Kepler