problems upgrading to NOD32 AV 4.2.40

[rpremuz]

While testing the upgrade from NOD32 AV Business Edition ver. 4.0.474 to ver. 4.2.40 (on MS Win XP Pro. SP3 machines) using the push install in the Eset RA Console ver. 3.1.15 I encountered a problem.

Post update: the MS Win XP Pro. computers are members of a MS Windows Domain. The user account used for push install was a domain admin account.

On some machines the upgrade was unsuccessful. The failed installation status was:
Failure during the package install - exit code: 1603
The einstaller.log is in the attachment.

The logged on user received the following popup:
"Installation of ESET NOD32 Antivirus will be run after a computer restart. Do you want to restart the computer now?"

The restart resulted in NOD32 AV BE 4.2.40 installed but with antivirus protection disabled. The NOD32 GUI protection status window said:

A serious error occurred while starting real-time file system protection. The computer is not protected against threats. The program needs to be reinstalled.
ESET NOD32 Antivirus has been updated to a newer version. We recommend that you restart the computer.

The user also noticed that she was unable to browse web pages (i.e. communication over HTTP was not working).

After the second restart of Windows the AV protection was enabled and working fine.

If I compare the cases of successful upgrade and the upgrade with the error, the following factor seems significant:

• If no user was logged on or a user with administrative rights in Windows was logged on, the upgrade was successful.
• If a normal user (without administrative rights) was logged on (either a local user or a domain user), the upgrade produced the above error and required two restarts of Windows to complete.

This looks like a bug in the NOD32 AV installer.
Has anyone experienced the same?

-- rpr.

[Cudni]

why is it a bug if it fails under non admin user accounts?

[doktornotor]

Originally Posted by Cudni

why is it a bug if it fails under non admin user accounts?

Well, because the push install is supposed to run the MSI in admin/system context so that it can install. It's kinda a complete showstopper for centralized management otherwise, you are not supposed to make all users local admins.

That said, I cannot reproduce this w/ XP SP3 boxes w/ LUA logged on and don't have any Vista/W7 box to test the same ATM.

[Cudni]

Originally Posted by doktornotor

Well, because the push install is supposed to run the MSI in admin/system context so that it can install.

so it should be almost bog standard tested procedure and .msi. Maybe a group policy breaks it?

[doktornotor]

Would be kinda whacky GP that disallows domain admins to install stuff remotely, but whatever.

[rpremuz]

Originally Posted by doktornotor

That said, I cannot reproduce this w/ XP SP3 boxes w/ LUA logged on and don't have any Vista/W7 box to test the same ATM.

Doctornotor, are you sure that the logged on user is not member of the Administrators or Power Users local user groups?

You can use the following command line commands for checking:

rem - list info about a local user account:
net user username
rem - list info about a domain user account:
net user username /domain
rem - list info about the following local user groups:
net localgroup administrators
net localgroup users
net localgroup "power users"

-- rpr.

[rockshox]

Check these threads:

http://www.wilderssecurity.com/showthread.php?t=238288

http://www.wilderssecurity.com/showthread.php?t=207826

http://www.wilderssecurity.com/showthread.php?t=238288

[jimwillsher]

We occasionally get the 1603 error. Not often - from 122 PCs it's probably happened a dozen times. Visiting the computer and installing manually always works though, and that's what we've had to do on this dozen.


Jim

[doktornotor]

Originally Posted by rpremuz

Doctornotor, are you sure that the logged on user is not member of the Administrators or Power Users local user groups?

To avoid more confusion here, I do NOT have the problem and cannot reproduce it either.

[rpremuz]

Hi!

I've done another upgrade test that confirmed earlier tests with push install. The environment is the same:
- MS Windows XP Pro. SP3 (32-bit) in a Windows domain.
- NOD32 Antivirus BE ver. 4.0.474 is installed.
- There are no traces of another AV software.
Here is how you can reproduce the test:

A local user logs on to Windows. The user account doesn't have administrative rights in Windows (i.e. it is only a member of the Users local user group):

>net user test
User name                    test
...
Local Group Memberships      *Users
Global Group memberships     *None
The command completed successfully.

The user runs the following command to start a command line window using the domain administrator account, which is normally able to install software and to do other administrative tasks on computers that are members of the domain:

runas /user:administrator@xxx.local cmd.exe

After successful start of the command window, the installation of NOD32 Antivirus BE ver. 4.2.40 is started using the following command in the command window:

eavbe_nt32_enu.msi /qn /norestart /lvx install.log

(the available options can be shown by running eavbe_nt32_enu.msi /? )

Although the installation used the /qn option (no GUI) the logged on user receives the following popup:
"Installation of ESET NOD32 Antivirus will be run after a computer restart. Do you want to restart the computer now?"

After the restart the NOD32 AV BE 4.2.40 is installed but with antivirus protection disabled. The NOD32 GUI protection status window says:

A serious error occurred while starting real-time file system protection. The computer is not protected against threats. The program needs to be reinstalled.
ESET NOD32 Antivirus has been updated to a newer version. We recommend that you restart the computer.

After the second restart of Windows the AV protection was enabled and working fine. (So, this is actually a workaround for the issue.)

The installation log can be found at http://www.hotshare.net/file/248464-7280140db7.html

-- rpr.

[rockshox]

I just tested this again pushing v4.2.40.0 over v4.0.474.0 through a remote install. The target machine is Windows XP SP3 in a Windows Domain without a user logged in (sitting at Ctrl-Alt-Del screen). Once the push install completed, I logged in remotely to the machine and confirmed Eset was running successfully. It did have the orange icon and stating a newer version had been installed and a reboot was necessary, which is normal.

Maybe you have a problem with the Windows Installer service? If the computer is wanting a reboot prior to even running the MSI, that usually is an issue of the Windows Installer service already being flagged that a restart is necessary before installations can continue. The 1603 error is coming from the Windows Installer errors, and not an ESET specific error.

http://support.microsoft.com/kb/834484

[rpremuz]

Originally Posted by rockshox

I just tested this again pushing v4.2.40.0 over v4.0.474.0 through a remote install. The target machine is Windows XP SP3 in a Windows Domain without a user logged in (sitting at Ctrl-Alt-Del screen). Once the push install completed, I logged in remotely to the machine and confirmed Eset was running successfully. It did have the orange icon and stating a newer version had been installed and a reboot was necessary, which is normal.

In my case this type on install is also successful (see the first post in this thread). You should test the install while a user who doesn't have admin rights is logged on to Windows.

-- rpr.

[rockshox]

Originally Posted by rpremuz

In my case this type on install is also successful (see the first post in this thread). You should test the install while a user who doesn't have admin rights is logged on to Windows.

Sorry, misunderstood that part. So I tested again, different set of machines (6 machines, Windows XP SP3, fully patched). Logged in as a Domain User which is a User on the machine (not even Power User). Started up Word, Notepad, IE8 and Solitaire to simulate a person using the computer. Pushed v4.2.40.0 over v4.0.474.0 without any popups, or restarts. When it was finished, received the Orange ESET icon asking for a restart due to the new version.



Have you checked the Event Viewer and made sure there aren't any errors in there that might help?

[rpremuz]

Originally Posted by rockshox

Have you checked the Event Viewer and made sure there aren't any errors in there that might help?

Of course I've checked the Event Log as it is an important step in problem solving on Windows known to every sysadmin 8-).

Since the system boot there have been only errors resulting from the NOD32 installer:

Event Type:	Error
Event Source:	MsiInstaller
Event Category:	None
Event ID:	11923
Date:		06.05.2010
Time:		17:04:35
User:		XXX\Administrator
Description:
Product: ESET NOD32 Antivirus -- Error 1923. Service 'ESET Service'
(ekrn) could not be installed.  Verify that you have sufficient
privileges to install system services.
Data:
0000: 7b 30 38 42 38 35 37 44   {08B857D
0008: 46 2d 45 36 46 39 2d 34   F-E6F9-4
0010: 32 38 33 2d 38 35 33 41   283-853A
0018: 2d 34 46 33 32 39 43 43   -4F329CC
0020: 30 39 41 34 46 7d         09A4F}  

Event Type:	Information
Event Source:	MsiInstaller
Event Category:	None
Event ID:	11708
Date:		06.05.2010
Time:		17:04:55
User:		XXX\Administrator
Description:
Product: ESET NOD32 Antivirus -- Installation failed.
Data:
0000: 7b 30 38 42 38 35 37 44   {08B857D
0008: 46 2d 45 36 46 39 2d 34   F-E6F9-4
0010: 32 38 33 2d 38 35 33 41   283-853A
0018: 2d 34 46 33 32 39 43 43   -4F329CC
0020: 30 39 41 34 46 7d         09A4F}  

As you can see, the strange thing is that although the installer runs as the domain admin it says it doesn't have sufficient privileges to install system services.

-- rpr.

[rockshox]

Hum...Clearly somehow your Domain Admin is not having permission.

Have you tried doing a gpupdate /force to refresh your Group Policy?

Do you have any other security software/firewall software on the machines?

Can you do a full scan on one of the machines with Malware Bytes and confirm nothing is picked up with it?

[rpremuz]

rockshox, look at the initial post. I repeat the third time: the domain admin is actually able to upgrade to NOD32 AV 4.2.20 but only if the user with admin rights is currently logged on in Windows or if no user is logged on. If a normal user is logged on, the update initiated by the domain admin (either through a push install or by running .msi installer) is not successful. Two restarts are required to finish the installation, as explained above.

This happened on a dozen of tested machines. This happened even on a MS Windows XP Pro. SP3 that is not in the domain and doesn't use group policy settings.

-- rpr.

[doktornotor]

Originally Posted by rpremuz

This happened on a dozen of tested machines. This happened even on a MS Windows XP Pro. SP3 that is not in the domain and doesn't use group policy settings.

Well, this does not happen here w/ XP SP3, Vista x64 nor W7 x64. I guess you'll have to dig somewhat deeper...

[rockshox]

Originally Posted by rpremuz

This happened on a dozen of tested machines. This happened even on a MS Windows XP Pro. SP3 that is not in the domain and doesn't use group policy settings.

Sorry that none of my suggestions have helped. Unfortunately I cannot recreate this problem on my end. I've pushed to a couple other Windows XP SP3 machines again today with a Domain User logged in and do not get any of the errors you are receiving. Definitely sounds like an issue specific to your location/environment/permissions.

[Cudni]

this might help
http://kb.eset.com/esetkb/index?page=content&id=SOLN82

[tanstaafl]

Originally Posted by rpremuz

In my case this type on install is also successful (see the first post in this thread). You should test the install while a user who doesn't have admin rights is logged on to Windows.
-- rpr.

Actually, it may be more than that.

Above you specifically stated that when the problem occurs, the user is logged on with a LOCAL user account, that is ONLY a member of the LOCAL computers USERS group, correct?

To be more precise - are you saying that this uiser is NOT a member of the 'Domain Users' group? IF not, that may be your problem. Why would your users be running LOCAL accounts as opposed to domain member accounts?

[rpremuz]

Originally Posted by tanstaafl

To be more precise - are you saying that this uiser is NOT a member of the 'Domain Users' group? IF not, that may be your problem. Why would your users be running LOCAL accounts as opposed to domain member accounts?

In the first post I wrote:

If a normal user (without administrative rights) was logged on (either a local user or a domain user), the upgrade produced the above error and required two restarts of Windows to complete.

So, the problem exists for:

• a local user account which is a member of the Users local user group only
• a domain user account which is a member of the Domain Users user group and is not a member of the Domain Admins user group

(A note for those not familiar with Windows domains: after a Windows machine is added to a Windows domain, the Domain Users user group is added to the Users local user group on that machine so that all regular domain users can log on to that machine. Also, the Domain Admins user group is added to the Administrators local user group on that machine so that all domain administrators can have admin rights on that machine.)

-- rpr.

[tanstaafl]

Originally Posted by rpremuz

In the first post I wrote:

If a normal user (without administrative rights) was logged on (either a local user or a domain user), the upgrade produced the above error and required two restarts of Windows to complete.

You're right, sorry, I didn't read the first post closely enough...

(A note for those not familiar with Windows domains: after a Windows machine is added to a Windows domain, the Domain Users user group is added to the Users local user group on that machine so that all regular domain users can log on to that machine. Also, the Domain Admins user group is added to the Administrators local user group on that machine so that all domain administrators can have admin rights on that machine.)

One of the things I always do is create two new domain Groups: 'Local PU' and 'Local Admins'. Then I add the 'Local PU' group to the 'Power Users' Group and the 'Local Admins' group to the 'Administrators' Group on each PC, so that I can selectively make certain users Power Users or Local Admins simply by adding them to the appropriate Group.

There may be a better way to do this, but this has worked well for me for many years...

[rpremuz]

I also tried to upgrade to NOD32 AV Business Edition ver. 4.2.58.3 on MS Windows XP Pro. SP3 machines using the push install in the Eset RA Console ver. 4.0.122. The upgrade was unsuccessful if a normal user (without administrative rights) was logged on the Windows XP: the upgrade produced the error mentioned above and required two restarts of Windows to succeed.

BTW, after starting this thread I contacted my local ESET support regarding this issue. During two months I exchanged 20+ emails with them, trying the upgrade over and over again, providing various logs, screen shots and info, which was quite tedious work, and it seems that the the real cause of the problem has still not been discovered by ESET.

-- rpr.

[rpremuz]

I also tried to upgrade NOD32 AV Business Edition on MS Windows XP Pro. SP3 machines in a MS Windows domain from ver. 4.0.* and 4.2.* to ver. 4.2.67.10 using the push install in the Eset RA Console ver. 4.0.138. The domain administrator account was used for the push installation.

The testing results show that the upgrade was successful only if no user was logged on the Windows or if a user with local administrative rights was logged on the Windows. But if a normal user (without administrative rights) was logged on the Windows the upgrade was unsuccessful: the upgrade produced the error mentioned above and required two restarts of Windows to succeed.

I'd really like that Eset fixes this issue which I reported 6 months ago. It causes difficulties with managing NOD32 AV in corporate environments where most users don't have admin rights on their PCs (this policy prevents them to change the system configuration, install software and also makes the system configuration more resistant to malware activities).

If it is not fixed soon I'll have to switch to another corporate AV software.

-- rpr.

[Marcos]

Please always include information if a Diagnostic task was completed successfully or post here the detailed task results if it fails. If it's completed fine, there should be no problems with remote installation whatsoever.