rpremuz
-
Posts
39 -
Joined
-
Last visited
Posts posted by rpremuz
-
-
Hi!
We have a MS Windows Server 2012 R2 with Windows Server Update Services (WSUS) role added. The WSUS uses Windows Internal Database (WID).
After ESET File Security for Microsoft Windows Server v. 4.5.12017.0 has been installed on the server, the ESET FS advanced setup tree in Computer protection > Antivirus and antispyware > Exclusions contains an automatically generated list of paths that are excluded from scanning. The list includes the following paths:
C:\WSUS\WSUSContent\UpdateServicesDbFiles\SUSDB.mdf
C:\WSUS\WSUSContent\UpdateServicesDbFiles\SUSDB_log.ldf
The problem is that those paths are not correct. The following are correct paths for default installation of WID:
C:\Windows\WID\Data\SUSDB.mdf
C:\Windows\WID\Data\SUSDB_log.ldf
BTW, the C:\WSUS\WSUSContent\UpdateServicesDbFiles\ folder does not exist either, while C:\WSUS\WSUSContent\ exists and is used for storing updates.
I'd suggest that ESET developers fix this issue so that ESET FS correctly sets automatic exclusions for WSUS on MS Windows Server 2012 R2.
-- rpr.
-
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.
-
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, 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, 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.
-
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.
-
I understand that Home version and Endpoint are independent products but some program modules (e.g. HIPS module) exist in both product groups.
ESET Home products ver. 7 have HIPS module improved. If the improved module works without issues in home products I'd say it shouldn't cause more issues for business users. So, will such improvements be included in Endpoint products?-- rpr.
-
ESET KB 3343 describes some improvements in ESET Smart Security 7 and ESET NOD32 Antivirus 7.
According to the Downloads for Business page business users can download only version 5 or 4 of the products which can be administered remotely using ERAS/ERAC tools.
Will version 7 with remote administration features ever be available for business users? If so, when we can expect it?-- rpr.
-
This would be possible but only with Self-defense disabled (e.g. by applying an ERA policy). You could then apply a GPO which will remove the above mentioned registry key and eventually you'd enable Self-defense again.
I've tried to do this by an ERA policy which has the following settings set through ESET Configuration Editor:
Windows desktop v5 → Kernel → Settings → Antivirus protection → Enable Self-defense: No
Windows desktop v5 → HIPS → Settings → Enable ESET Endpoint Security Self-defense: No
After the policy is applied a Windows restart is required to make it active.
Then another Windows restart is required to successfully delete the WscState value in the Registry, e.g. via a startup script that runs the following command:
reg delete "HKLM\SOFTWARE\ESET\ESET Security\CurrentVersion\Info" /v WscState /f
And then the third Windows restart is required to make ESET AV aware of the change in the Registry.
After all that hassle some machines still report that there is no antivirus software installed. I'm attaching the screenshots.
-- rpr.
-
Marcos, your suggestion solves the issue.
But it is quite inconvenient to restart many PCs in safe mode. It is strange that the registry value cannot be deleted in normal mode.
-- rpr.
-
Arkasi,
the machines where I see this problem are all new HP laptops/desktops with OEM Windows 7 Pro. SP1 64-bit and with current MS updates installed. It's very unlikely that some services are not running or DLLs missing on them. But to satisfy you curiosity I checked the services and files with the following commands (in cmd.exe):sc query wscsvc sc query RpcSs sc query DcomLaunch sc query Winmgmt dir %SystemRoot%\System32\wscsvc.dll dir %SystemRoot%\System32\oleres.dll dir %Systemroot%\system32\wbem\wmiapsrv.exe
and here are the results which show that everything's fine:
C:\>sc query wscsvc SERVICE_NAME: wscsvc TYPE : 20 WIN32_SHARE_PROCESS STATE : 4 RUNNING (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 C:\>sc query RpcSs SERVICE_NAME: RpcSs TYPE : 20 WIN32_SHARE_PROCESS STATE : 4 RUNNING (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 C:\>sc query DcomLaunch SERVICE_NAME: DcomLaunch TYPE : 20 WIN32_SHARE_PROCESS STATE : 4 RUNNING (NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 C:\>sc query Winmgmt SERVICE_NAME: Winmgmt TYPE : 20 WIN32_SHARE_PROCESS STATE : 4 RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 C:\>dir %SystemRoot%\System32\wscsvc.dll Volume in drive C has no label. Volume Serial Number is 70B8-B314 Directory of C:\windows\System32 14.07.09. 03:41 97.280 wscsvc.dll 1 File(s) 97.280 bytes 0 Dir(s) 412.182.974.464 bytes free C:\>dir %SystemRoot%\System32\oleres.dll Volume in drive C has no label. Volume Serial Number is 70B8-B314 Directory of C:\windows\System32 14.07.09. 03:31 25.600 oleres.dll 1 File(s) 25.600 bytes 0 Dir(s) 412.182.974.464 bytes free C:\>dir %Systemroot%\system32\wbem\wmiapsrv.exe Volume in drive C has no label. Volume Serial Number is 70B8-B314 Directory of C:\windows\system32\wbem 14.07.09. 03:39 203.264 WmiApSrv.exe 1 File(s) 203.264 bytes 0 Dir(s) 412.182.974.464 bytes free C:\>
-- rpr.
-
Hello Peter,
I've done what the KB article suggests - run the following commands in Command Prompt:
NET STOP WINMGMT /Y REN %WINDIR%\SYSTEM32\WBEM\REPOSITORY REP.OLD
and restarted Windows three times but after each restart Windows 7 Action Center reported that "Windows did not find antivirus software on this computer".
-- rpr.
-
Hi!
On MS Windows 7 Pro. x64 with SP1 that have ESET Endpoint Antivirus v. 5.0.2214.4 installed the Action Center gives the following warning about virus protection:
"Windows did not find antivirus software on this computer" (see the attached picture).This is a bit strange as one would expect that ESET Endpoint AV is compatible with Windows 7, which is not a new OS.
Is there a way to make the Action Center recognize the ESET Endpoing AV as an antivirus software?
-- rpr.
). 
ESET FS automatic exclusions on Windows Server 2012 R2 with WSUS
in ESET Products for Windows Servers
Posted
Jeffrey, I'm not able to download those installation files with the username and password we've got with EAV Business Edition license.