Jump to content

Individually controllable update settings


Recommended Posts

Hello,

Description: In Policy for Windows Clients: Make Update settings individually controllable


Details:

In the windows endpoint policy settings, when I set the flag to enforce a specific option, all other options are automatically flagged, too.
I want to enforce only specific settings, mainly the selected profile and the update server. But users should still have the option to enter their username and password, as our update servers require authentication.

On policies for MacOS/Linux this works as expected, but not on Windows Policies.

Link to post
Share on other sites
  • ESET Staff

@isaha do I get it correctly, that you use a locally created "update mirror" server for updating, instead of clients connecting directly to ESET? 

Link to post
Share on other sites
36 minutes ago, MichalJ said:

@isaha do I get it correctly, that you use a locally created "update mirror" server for updating, instead of clients connecting directly to ESET? 

Yes, the update server is a locally created update mirror server that our users should be able access with their personal username and password.

Link to post
Share on other sites
  • Administrators
2 minutes ago, isaha said:

Yes, the update server is a locally created update mirror server that our users should be able access with their personal username and password.

Is there any reason why you don't update via http from a mirror or via http proxy from ESET's servers? If clients must update from a local mirror via Windows shares, you can create a specific user account with access to the share containing the mirror. It's also possible to set up the updater to connect to the share under the account of the logged in user (however, if no user was logged in update would fail).

Link to post
Share on other sites
1 hour ago, Marcos said:

Is there any reason why you don't update via http from a mirror or via http proxy from ESET's servers? If clients must update from a local mirror via Windows shares, you can create a specific user account with access to the share containing the mirror. It's also possible to set up the updater to connect to the share under the account of the logged in user (however, if no user was logged in update would fail).


Thanks for your fast reactions. I really appreciate it.

The situation is a bit complicated, but try to explain:

We are a large, heterogeneous research institute. There is no central ActiveDirectory that manages all clients. We have Windows, MacOS and various Linux clients.

We are currently preparing to switch from ERAC 5 to ESMC 7, finally.

We have clients that only have access to our internal network;
clients that are allowed to access the Intranet and the Internet;
and clients that are operated outside our network for a long time (e.g. external research locations).

Many employees are only with us for a few months and also bring their private devices with them.
As long as they work with us, they get an institute account and are obliged to use our ESET Antivir solution.

However, if these employees leave, we want to prevent them from continuing to benefit from our ESET license. With protecting the update-server with authentication; when their account expires with their departure, they can no longer access our update mirror server.

So far with ERAC 5, we have had 2 update servers. Once the ERAC as a mirror-server itself via http without password protection in the internal network.
And in addition, precisely because many of our devices are operated outside of our network for a longer time, an https mirror with password protection. Each user has their own login data, which become invalid when the user leaves our institute.

With the switch to ESMC 7, the idea is now to provide a single update mirror server in the DMZ. All clients within our network (whether they have an internet connection or are only allowed to use local resources) can receive their updates from this update mirror without a password based on internal IP addresses.

Clients who are temporarily or a longer time outside the internal network should use a password to access their ESET updates as long as the user has an activated institute account. This password is only known by the user, so they must enter it into the ESET antivir settings on their client.

Clients, who leave our institute and therefore have no valid account anymore, should of course no longer be able to use our ESET antivir infrastructure.

So thats why almost every client setting should therefore be set by a server-side Policy, except for the update setting where user name and password are stored.
This is exactly what is currently not possible with Windows clients. But it is possible with MacOS / Linux Client Policies, so it would be nice if this were possible with Windows Client Policies also.

Link to post
Share on other sites
  • Marcos changed the title to Individually controllable update settings
  • 2 weeks later...

Dear ESET Team,

we have now decided that we will follow your advice and use the official ESET update servers to update all our clients connected to the Internet.
We will set up an internal update server without authentication for internal-only clients.

I have one question left:

Our clients get activated from our internal ESCM server. If I remove a client's licence via ESET Licence Administrator webpage https://ela.eset.com/, will the client reactivate when connecting to official ESET servers or will it have to connect to our internal ESMC server?
 

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...