ESET_logo

Un petit retour d’expérience, après avoir mis en place la solution Eset Endpoint Protection Advanced, j’ai été confronté au problème suivant :
Sur les pc des utilisateurs nomades, Eset ne se mettait pas à jour lorsque le pc était en dehors de notre réseau (problème bien embêtant pour des utilisateurs nomades !)

Niveau configuration, nous avons installé sur un serveur le produit Eset Remote Administrator (et Eset File Security) puis, depuis la console ERA (Eset Remote Administrator) nous avons fait descendre l’agent Eset Remote, qui nous a permit d’installer  sur les postes des utilisateurs le produit Eset Endpoint Antivirus.

En procédant de la sorte, Eset a une stratégie, active par défaut, qui renseigne un serveur proxy sur Eset Endpoint Antivirus pour les mises à jour (le serveur où est installé ERA généralement).
Ce qui a pour conséquence que les mises à jour sont téléchargées une seule fois, sur le serveur, puis redistribuées en local sur les postes.

Un avantage pour un parc informatique volumineux (+100 postes). Sur un parc de petite ou moyenne taille, l’impact des mises à jour n’est pas très important (la taille d’une mise à jour représentant quelques méga au maximum).

Deux solutions s’offrent à vous. La 1ere, si vous souhaitez garder la stratégie par défaut et donc avoir les mises à jour centralisées, consiste à créer un second profil pour les utilisateurs nomades.
Pour cela, je vous renvoie au KB3621 d’Eset.

Sinon, la seconde solution, notamment si vous avez un parc informatique de petite ou moyenne taille, consiste à modifier la stratégie en question.
Pour cela, rendez vous sur la page de gestion ERA
Ensuite, dans l’onglet Admin sur votre gauche, choisissez Stratégies, puis Produit de sécurité pour Windows – Utilisation du proxy HTTP.
Eset1

Eset2

Allez dans Paramètres, Outils, Serveur Proxy puis décochez « utiliser un serveur proxy »

Eset3

Il ne reste plus qu’a patienter le temps que la stratégie se mette à jour sur les postes.

wsus

Si comme moi, vous avez installé la mise à jour Windows KB3159706 sur votre serveur de mise à jour, il est fort probable que le service WSUS ne se lance plus, ou se coupe tout seul. L’accès à la console WSUS en est aussi impossible.

Pour résoudre le problème, il suffit d’ouvrir une fenêtre Dos en tant qu’admin et d’y lancer la commande suivante :

cd C:\Program Files\Update Services\Tools\
wsusutil.exe postinstall /servicing

Rendez-vous ensuite dans le gestionnaire de serveur, puis dans Gérer et Ajouter des rôles et des fonctionnalités.
Dans Fonctionnalités, déroulez Fonctionnalités de .NET Framework 4.5 et cochez « Activation HTTP » comme nous le précise Microsoft : Support

Toute fois, dans mon cas, je n’avais pas l’activation HTTP sous le .Net Framework 4.5. Par contre il était présent sous .Net Framework 3.5. Je l’ai donc activé puis j’ai relancé mon service WSUS.
Cette fois-ci, ça fonctionne !

Si vous avez SSL d’activé sur votre serveur de mise à jour, je vous invite à suivre l’étape supplémentaire décrite sur le Support Microsoft partie « If SSL is enabled on the WSUS server«