Upgrade Of Endpoint Antivirus 5.0 Gives Error 1923

[rpremuz 6]

Hi!

 

In a Windows 2003 domain environment I tested upgrade of ESET Endpoint AV from v. 5.0.2225.0 to v. 5.2229.1 on MS Windows 7 Pro. SP1 32/64 bit using the ESET Remote Administrator Console 5.2.22.0.

 

In ERAC the diagnostics of Windows push installation using credentials of the domain administrator was successful:

n37.vred.local
Diagnostics user context:                       VRED\administrator
Operating System:                               Windows 7 Professional x64 Edition
Operating System Version:                       6.1
ESET Security Product Name:                     ESET Endpoint Antivirus
ESET Security Product Version:                  5.0.2225.0
ESET Security Product Virus Signature Database: 10142 (20140723)

Installation result:
Setting IPC$ Connection:                                   Result Code: 0 (The operation completed successfully.)
Remote Registry Connecting (OS Info):                      Result Code: 0 (The operation completed successfully.)
Remote Registry Opening (OS Info):                         Result Code: 0 (The operation completed successfully.)
Remote Registry Reading (OS Info):                         Result Code: 0 (The operation completed successfully.)
Remote Registry Connecting (ESET Security Product Info):   Result Code: 0 (The operation completed successfully.)
Remote Registry Opening (ESET Security Product Info):      Result Code: 0 (The operation completed successfully.)
Remote Registry Reading (ESET Security Product Info):      Result Code: 0 (The operation completed successfully.)
Setting ADMIN$ Connection:                                 Result Code: 0 (The operation completed successfully.)
Copying ESET Installer:                                    Result Code: 0 (The operation completed successfully.)
Setting IPC$ Connection:                                   Result Code: 0 (The operation completed successfully.)
Registering ESET Installer as a Service:                   Result Code: 0 (The operation completed successfully.)
Diagnostics conclusion:                                    Result Code: 0 (The operation completed successfully.)

Then in ERAC I run Upgrade Windows Client task which reported:

Client                    Date           State     State Text
Dervbdc.vred.local / n37  3 minutes ago  Finished  Successfully completed

but actually the upgrade was not successful: old version of Endpoint AV was uninstalled but the new version was not installed (leaving the client unprotected). In the Event Log on the client the following events were logged, which show that installation failed with "Error 1923. Service 'ESET Service' (ekrn) could not be installed":

Log Name:      Application
Source:        MsiInstaller
Date:          23.07.14. 19:16:18
Event ID:      1040
Level:         Information
User:          SYSTEM
Description:
Beginning a Windows Installer transaction:
C:\windows\TEMP\ra_pcu-908957140.msi. Client Process Id: 6664.

Log Name:      Application
Source:        MsiInstaller
Date:          23.07.14. 19:16:51
Event ID:      11923
Level:         Error
User:          SYSTEM
Description:
Product: ESET Endpoint Antivirus -- Error 1923. Service 'ESET Service'
(ekrn) could not be installed.  Verify that you have sufficient
privileges to install system services.

Log Name:      Application
Source:        MsiInstaller
Date:          23.07.14. 19:16:54
Event ID:      11708
Level:         Information
User:          SYSTEM
Description:
Product: ESET Endpoint Antivirus -- Installation failed.

Log Name:      Application
Source:        MsiInstaller
Date:          23.07.14. 19:16:54
Event ID:      1033
Level:         Information
User:          SYSTEM
Description:
Windows Installer installed the product. Product Name: ESET Endpoint
Antivirus. Product Version: 5.0.2229.1. Product Language: 1033.
Manufacturer: ESET, spol. s r.o.. Installation success or error
status: 1603.

Log Name:      Application
Source:        MsiInstaller
Date:          23.07.14. 19:16:54
Event ID:      1042
Level:         Information
User:          SYSTEM
Description:
Ending a Windows Installer transaction:
C:\windows\TEMP\ra_pcu-908957140.msi. Client Process Id: 6664.

The MSI log of the unsuccessful installation is attached as MSI1.LOG.

 

After I restarted the client a new EAV installation took place automatically and finished successfully with computer restart recommended - see the first attached image. The MSI log of the second part of the installation is attached as MSI2.LOG.

 

I tested this procedure on a couple of Windows 7 Pro. SP1 32/64 clients and always got the same result if the following condition was also met: the domain user which was logged on during the upgrade had "restricted" rights, i.e. didn't have administrative rights on the client PC.

 

Experienced sysadmins know that it is recommended that domain users don't have admin rights on their machines so that they can't install software or change system settings in Windows. These "restricted" users are members of the Domain Users group and the Domain Users group is a member of the local Users group on every Windows machine joined to the Windows domain - see the second attached image. That way domain users can log on to every PC in the domain and work on it (BTW, roaming profiles and folder redirection is also used).

 

On the other hand, if the domain user which was logged on during the upgrade had administrative rights on the client PC, then the upgrade was successful with computer restart recommended. The MSI log of that installation is attached as MSI3.LOG. (A domain user has administrative rights on a client PC when she is a member of local Administrators group on that PC.)

 

As described above, this issue with upgrade of Endpoint AV can be solved by restarting each PC twice soon after initiating the upgrade in ERAC, but it is inconvenient for the users which are disturbed twice. I had this issue also while upgrading NOD32 AV 4 and also while upgrading from NOD32 AV 4 to Endpoint AV 5. I hope Eset will eventually take care of this issue.

 

Any comments?

 

-- rpr.

logs.zip

[Arakasi 549]

Hello, instead of using upgrade to deploy the new msi to workstations.

Use the Push like your doing a new deploy instead. I will submit a screenshot for you.

Edited July 24, 2014 by Arakasi

[rpremuz 6]

Arakasi, when I reported about this issue before I used Windows Push Installation for upgrade. And then I was advised on (old) ESET forum that I should use Upgrade Windows Client. Either way I have this issue.

 

Edit:

ESET REMOTE ADMINISTRATOR 5 Installation Manual and User Guide, REV. 5/19/2014, says on p. 54:

• Upgrade Windows client – Runs the upgrade task. Use this option if you want to install a newer version of EES/EEV over an older business version.

Edited July 24, 2014 by rpremuz

[Arakasi 549]

Whoever stated that on Wilders may have it backwards.

Was it ESET staff ?

 

Using the normal Push is the best way to upgrade clients.

Let me see ....

Also please hide your domain ... XXXX\Admin in your posts. I can see it. Not good for public forum, you never know who could be browsing around here.

Edited July 24, 2014 by Arakasi

[Arakasi 549]

According to this :

Product: ESET Endpoint Antivirus -- Error 1923. Service 'ESET Service'
(ekrn) could not be installed.  Verify that you have sufficient
privileges to install system services.

 

Your issue is quite apparent.

Open services on your server, and go to ESET Remote Administrator Service, and change the Logon type to credentials that are under the "Domain Admin" workgroup.

This may solve your issue with deployment privilege issues.

 

If you still have the issue, RDP to that workstation and make sure the domain admins workgroup is a member of the local administrators group on the workstation.

:)

Edited July 24, 2014 by Arakasi

[rpremuz 6]

Arakasi, before I test the Push Installation I'd like to ask you why the Upgrade Windows Client is successful if a user with admin rights is logged on to Windows client? Also, when no user is logged on. How do you explain that?

 

Regarding the ERAS, it currently runs as Local System account. In ESET REMOTE ADMINISTRATOR 5 Installation Manual and User Guide I don't find any recommendation on changing that. I'd say that running a service as a domain administrator is not recommended.

 

-- rpr.

[Arakasi 549]

Sure.

You don't have to take my suggestions. However that is most likely the resolution and i am trying to help.

 

I can still see your domain! I hope your security is tight.

 

Also, when no user is logged on. How do you explain that?

 

ERA will use the credentials of the service when deploying and accessing every part of the workstation for installation including $admin share which is where the package will sit.

 

I'd say that running a service as a domain administrator is not recommended.

 

This is false.

 

I have set up about 15 different domain networks with ESET, and have configured and deployed updates on every one of them.

See my attached picture. The local administrator account of my server is also a member of the domain admin workgroup.

 

I didnt say the upgrade windows client doesn't work, however its much simpler to use the new install method.

Edited July 25, 2014 by Arakasi

[Arakasi 549]

Hello again,

 

I would recommend standing by and wait for staff or moderator to respond, that way we have some assurance for you.

Thanks

Edited July 24, 2014 by Arakasi

[rpremuz 6]

I set up the ESET Remote Administrator Server service to run as the domain administrator but it changed nothing regarding this issue.

 

I used Process Explorer to watch the processes on the Windows client after the Windows Push Installation was initiated. It showed that einstaller.exe, esetup.exe and subsequent msiexec.exe processes all run under the SYSTEM account on the Windows client, not the domain administrator:

 

I expected this. I'd say that in Push Installation the ERAC uses the credentials you provide (and which may be different from the account used for running the ERAS service) to connect to the Windows client and to initiate the setup process which runs as the local system account on that Windows client.

 

On the other hand, when you use the Upgrade Windows Client the ERAC communicates with the ESET service already running on the client (under SYSTEM account) and directs it to start the upgrade.

[Arakasi 549]

See the following KB article down to step 5.

hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN82

 

I did not notice you were on 03, even on all my sbs2011 including 2008, i could not get the deploy to function without following the directions in step 5.

 

So where are we at ? Still no success on the deploy ?

[Arakasi 549]

Which directories are you using for folder redirection, and how do you decide which are folder redirect and which are a complete roaming profile ? Do you just have a mix of the two ?

Could this be an ACL problem with local profile or the ones on server ?

 

I noticed you made a similar post here: hxxp://www.wilderssecurity.com/threads/problems-upgrading-to-nod32-av-4-2-40.271876/

Have you had this issue the whole time without resolution, or are you running into it again ?

[rpremuz 6]

Yes, I wrote that post on the old ESET forum and since then the issue has been present with every upgrade of ESET AV.

 

You ask about success on deployment. As I wrote at the start of this thread, the deployment was successful actually except if the domain user who was logged on during the upgrade had "restricted" rights, i.e. didn't have administrative rights on the Windows client.

 

Some of domain users actually have admin rights on their machines and in that case the upgrade is successful. But when a domain user with "restricted" rights is logged on the upgrade is not successful and ends with "ESET Endpoint Antivirus -- Error 1923. Service 'ESET Service' (ekrn) could not be installed.  Verify that you have sufficient privileges to install system services." After restart of the Windows client the upgrade continues and finish successfully asking user for restart, which is normal.

 

The roaming profile or redirected folders can't cause this issue because the users with admin rights on their machines also use roaming profile and redirected folders but don't have this issue.

 

 

And now the good news: While testing this issue I've found out that it is caused by running Process Explorer on client machine. We have setup the Process Explorer to start minimized automatically after user login (with an icon in the systray). That way users and especially sysadmins can quickly notice high CPU usage and kill a misbehaving process or observe running processes and system resources.

 

But somehow the Process Explorer running under a "restricted" user account can block installation of system services such as ESET service (ekrn). It seems a similar issue with Process Explorer was reported in hxxp://forum.sysinternals.com/problem-with-service-deletions_topic28889.html (and this is not the first time I see it causing problems ).

 

So, as a workaround you can kill Process Explorer before starting upgrade of ESET AV -- this can be done remotely with pskill tool (also from Mark Russinovich):

pskill -t \\hostname procexp.exe

I tested this on a dozen machines with "restricted" users logged on and the upgrade of ESET AV was always successful (both with Upgrade Windows Client and Windows Push Installation).

 

-- rpr.