Le blog technique

SEP, Symantec Endpoint Protection est le dernier antivirus de Symantec. Chaque évolution de SEP est nommée MR (Major Release). Symantec corrige et améliore la solution SEP à chaque release. Il est donc important de toujours maintenir à jour la solution avec le dernier correctif.

Aujourd’hui, nous sommes à la version SEP MR6

Chaque MR apporte trois évolutions :

• Evolution du SEPM (cf post sur l’architecture SEP)
• Evolution de la base SEP (SQL ou Sybase)
• Evolution des clients

Ces évolutions ne sont ni une mise a jour du moteur antivirus, ni une mise à jours de la base virale du client SEP.Chaque montée de version fait donc l’objet d’un « upgrade » de l’architecture SEP.

Il existe plusieurs méthodologies pour faire cette montée de version. Voici celle que j’estime être la plus sure, et la plus rapide.

Les pré-requis sont :

• Un serveur de « spare »
• La nouvelle version (les sources, CD1)
• Du temps 🙂 (cette migration peut se faire sur deux à trois jours)

1) Rappel d’une architecture SEP (cf : Lien Solution SEP )

Une architecture SEP est constituée des composants suivants :

• SEPM (manager)
• Clients SEP (postes et serveurs client)
• GUP (client SEP, serveur ou poste de travail, relais pour la mise à disposition des mises à jour)
• Base de données (une par défaut, SQL ou Sybase) SEP

2) Montage d’un serveur de relais pour la migration

Un second serveur de relais sert à ne pas impacter les utilisateurs lors de la migration du serveur SEPM (montée de version du SEPM et de la base de données).

Donc, la première des actions est de monter un second serveur avec une seconde base (même version que le premier).

3) Synchroniser les deux serveurs

Le but de la synchronisation est de s’assurer que les deux bases aient le même niveau d’information.

• Politique
• Client
• Package de déploiement
• …

4) Faire basculer les postes clients sur le second serveur

Cette bascule s’effectue via la configuration de la liste de serveur SEPM.

Il faut créer une liste (via la copie de la liste par défaut est un bon moyen).

Créer une nouvelle priorité de serveur, et ajouter le second serveur à la liste.

Attention, il faut bien vérifier que le nouveau serveur est en priorité1

5) Casser la synchronisation

Lors de la migration d’un serveur SEPM, la base est migrée. Si la synchronisation est active, elle risque de casser les tables de la seconde base.

6) Migrer le premier serveur

Lancer simplement le setup. Exe du CD 1 dans le dossier SEPM

7) Vérifier le bon fonctionnement du SEPM, de la base

Redémarrer le serveur et la base.

Vérifier que les informations de la base sont accessibles via la console de gestion SEP…

8) Basculer un lot de postes clients SEP et vérifier le bon fonctionnement de ceux-ci

Tester que le client est bien connecté au serveur SEPM

Le bouclier informe de l’état de la solution SEP client et informe du lien avec le SEPM (pastille et couleur).

• Vert OK
• Jaune lié mais léger problème SEP ou définitions non a jour
• Rouge antivirus désactivé ou non fonctionnel
• -Non présent SEP en mode « Autonome – Hors Ligne »

9) Basculer le reste des clients

Les clients doivent être rebasculés dans l’intégralité avant de passer à l’étape d’après.

10) Couper le serveur relais

Le serveur relais n’a pas besoin d’être migré.

TMG et support de l’IPv6

A l’instar de son prédécesseur, TMG 2010 ne supporte pas le trafic IPv6. Ainsi lors de l’installation, certaines fonctionnalités IPv6 intégrées à Windows Server 2008 / Windows Server 2008 R2 sont désactivées. De plus un serveur TMG rejette par défaut l’intégralité du trafic IPv6 qu’il reçoit.

Ce comportement est intrinsèque au produit et est documenté sur Microsoft Technet dans la page unsupported configuration. Voici un extrait de l’article :

Forefront TMG does not support IPv6 traffic
Issue: IPv6 traffic is not supported by Forefront TMG (except for DirectAccess).

Cause: Filtering of IPv6 traffic is not supported, and all IPv6 traffic is blocked by default.

Solution: It is recommended that you disable IPv6 traffic on the Forefront TMG computer or array members. To disable the IPv6 stack on the Forefront TMG computer or array member, see Knowledge Base article KB929852 (http://go.microsoft.com/fwlink/?LinkId=179983).

Microsoft conseille donc de positionner la clé de registre DisabledComponents avec la valeur 0xFFFFFFFF afin de désactiver totalement la pile IPv6 dans le système d’exploitation.

Le seul scénario où l’utilisation de l’IPv6 avec TMG est supporté correspond à la mise en oeuvre de Direct Access. En effet Direct Access nécessite l’activation de la pile IPv6 ainsi que celle de plusieurs technologies de transition (ISATAP, Teredo…).

Dans ce cas bien précis une clé de registre spécifique doit être créée avant l’installation de TMG sur le serveur.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\ISACTRL]
"CTRL_SKIP_DISABLE_IPV6_PROTOCOLS"=dword:00000001

A titre informatif, la procédure exacte de configuration de Direct Access sur TMG est disponible sur le Blog Technet dédié à TMG.

Remarque : Même si il est possible d’implémenter Direct Access sur un serveur TMG, la plateforme à privilégier reste Forefront UAG (Unified Access Gateway). Pour en apprendre plus sur les avantages de Direct Access avec UAG, consultez ce lien.

Problématique rencontrée avec le service VPN / RRAS

Une fois la clé de registre DisabledComponents positionnée et le serveur TMG redémarré, toutes les fonctionnalités de TMG fonctionnent correctement hormis le service VPN (qui correspond en fait au service Routage et accès distant de Windows) qui refuse de démarrer.

Dans la console MMC de TMG, le service Remote Access Service est en état arrêté et l’erreur suivante se produit lorsque l’on tente de le démarrer manuellement :

The service could not be started

En parallèle, les erreurs suivantes sont générées dans le journal Système à chaque tentative de démarrage du service.

• Source : Service Control Manager
  Event ID : 7024
  Description : The Routing and Remote Access service terminated with service-specific error A device attached to the system is not functioning.
• Source : RemoteAccess
• Event ID : 20103
  Description : Unable to load C:\Windows\System32\iprtrmgr.dll.

Ce sujet est abordé dans certains forums (dont les forums MS Technet) et un moyen de contournement consisterait à supprimer la clé de registre suivante ainsi que tout son contenu :

HKEY_LOCAL_MACHINE \ System \ currentcontrolset \ services \ remoteaccess \ routermanagers \ IPV6

Effectuer cette opération permet en effet un lancement manuel du service RRAS mais à chaque redémarrage du serveur TMG, le service RRAS refuse de démarrer automatiquement et il faut impérativement le lancer manuellement ! Dans ce scénario l’erreur suivante est loguée dans le journal d’évènements Applications :

• Log Name : Application
  Source : Microsoft Forefront TMG Firewall
  Event ID : 21199
  Description: The Remote Access Service configuration for VPN could not be completed. As a result, the Remote Access Service may be stopped.

Cette solution (suppression de la clé de registre routermanagemers\IPV6) n’est donc pas une fin en soi mais un simple contournement permettant de démarrer (manuellement) le service RRAS. De plus dans ce scénario, le service RRAS accepte de démarrer mais la configuration positionnée dans TMG ne descend plus sur le service RRAS (TMG ne remplit donc plus son rôle qui consiste à "piloter" le service RRAS).

La solution : réactiver l’IPv6 !

Après de nombreux tests infructueux, j’ai finalement déterminé une solution au problème : il suffit de "réactiver l’IPv6" en supprimant la clé de registre DisabledComponents !

Comme quoi il faut parfois aller au delà des préconisations Microsoft.

Si vous souhaitez aller plus loin, cette problématique est également en discussion sur le forum Technet suivant :

http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeVPN/thread/d033a9d1-aff6-4098-a002-e5e15ee1834c