PI Services

Ce billet a pour objectif de référencer les versions des différentes extensions de schéma disponibles pour Active Directory, Exchange et LCS/OCS.

Remarque : Les versions intermédiaires (Beta, RC, CTP...) des produits utilisent des numéros de versions spécifiques qui ne sont pas indiqué dans ce billet (seules les versions finales ou RTM sont prises en compte).

Extensions de schéma Active Directory

Le tableau ci-dessous liste les différentes versions de schéma existantes pour l'annuaire Active Directory.

Extensions de schéma Exchange

Le tableau ci-dessous liste les différentes versions de schéma existantes pour la plateforme de messagerie Exchange.

Extensions de schéma LCS/OCS

Le tableau ci-dessous liste les différentes versions de schéma existantes pour le logiciel de collaboration Office Communication Server (OCS).

Comment vérifier manuellement une version de schéma ?

Pour vérifier manuellement la version du schéma Active Directory, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut objectVersion sur le conteneur "CN=Schema,CN=Configuration,DC=domaine,DC=local"
• Exécuter la commande suivante :

dsquery.exe * "CN=Schema,CN=Configuration,DC=domaine,DC=local" -scope base -attr objectversion

Pour vérifier manuellement la version du schéma Exchange, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut rangeUpper sur l'attribut ms-Exch-Schema-Version-Pt
• Exécuter la commande suivante :

dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=domaine, dc=local -scope base –attr rangeUpper

Pour vérifier manuellement la version du schéma OCS, plusieurs options sont possibles :

• Utiliser la console ADSIEdit, ouvrir la partition de schéma, puis afficher la valeur de l'attribut rangeUpper sur l'attribut ms-RTC-SIP-SchemaVersion
• Exécuter la commande suivante :

dsquery.exe * CN=ms-RTC-SIP-SchemaVersion,CN=Schema,CN=Configuration, DC=domaine,DC=com -scope base -attr rangeupper

Problématique rencontrée

Lorsqu'une nouvelle imprimante est ajoutée sur un serveur d'impression Windows Server 2008 R2, le pilote injecté par l'assistant d'installation est celui correspondant au système d'exploitation (pilote pour architecture x64).

Les postes de travail 2000/XP/Vista et Seven étant généralement déployés en 32 bits (architecture x86), il faut impérativement rajouter le pilote x86 dans les propriétés de l'imprimante partagée.

Lorsque l'on réalise cette opération un fichier système nommé ntprint.inf est requis. Par défaut le media d'installation Windows est demandé (répertoire D:\i386).

Les images ISO de Windows 2000, Windows XP et Windows Server 2003 32 bits contiennent effectivement un fichier ntprint.inf sous le répertoire i386. Or lorsque l'on sélectionne ce fichier, l'assistant ne le prend pas en compte et réaffiche indéfiniment la fenêtre permettant de sélectionner l'emplacement du fichier.

Explication

Le fichier ntprint.inf contenu dans les sources de Windows 2000/XP/2003 n'est pas celui attendu par l'assistant d'ajout de pilote.

Ce dernier s'attend à recevoir un fichier ntprint.inf plus récent (Windows Vista 32 bits ou supérieur) situé dans le répertoire C:\Windows\winsxs.

Solution

La solution consiste à utiliser le fichier ntprint.inf situé dans C:\Windows\winsxs de l'une des versions suivantes de Windows :

• Windows Vista 32 bits
• Windows Seven 32 bits
• Windows 2008 32 bits

Le nom précis du répertoire est le suivant :

C:\Windows\winsxs\x86_ntprint.inf_<id>_<version>.<id>_none_<id>

Remarque : <id> et <version> correspondent à des ID et à la version du système (par exemple 6.0.6002 pour Windows Server 2008 SP2) - cela signifie que le nom du répertoire varie d'une version de Windows à l'autre et également en fonction du service pack

Voici le nom exact du répertoire pour Windows 7 32 bits :

• x86_ntprint.inf_31bf3856ad364e35_6.1.7600.16385_none_3ad6f3251c0676a9

Pour Windows Server 2008 SP2 32 bits le nom exact est :

• x86_ntprint.inf_31bf3856ad364e35_6.0.6002.18005_none_3cec160db7d4ac84

Exemple pas-à-pas avec une imprimante Laser Dell 5200

Voici un exemple pas-à-pas pour ajouter une imprimante partagée sous Windows Server 2008 R2 avec les pilotes x64 et x86.

Dans un premier temps il est conseillé d'installer le rôle Print and Document Services avec le sous-composant Print Server (cf. captures d'écran ci-dessous).

Une fois l'installation du rôle effectuée, lancez la console MMC Print Management. Dans l'arborescence de la console, développez Print Servers / <Nom du serveur>, puis faites un clic droit sur Printers et lancez l'assistant Add Printers...

Dans la page Printer Installation, choisissez Add a TCP/IP or Web Services Printer by IP address or hostname, puis cliquez sur le bouton Next.

Dans la page Printer Address, sélectionnez TCP/IP Device dans la liste déroulante, entrez l'adresse IP de l'imprimante, puis cliquez sur le bouton Next.

Si le pilote n'est pas déjà installé sur le serveur, sélectionnez Install a new driver puis cliquez sur Next.

Si le pilote de votre imprimante n'est pas présent dans la liste prédéfinie de Windows Server 2008 R2, cliquez sur le bouton Have Disk... pour insérer le pilote (le pilote demandé ici est celui correspondant au système serveur à savoir le pilote x64).

Une fois le fichier INI chargé, sélectionnez le pilote correspondant à votre périphérique d'impression (dans cet exemple il s'agit d'une imprimante Dell M5200N).

Dans la page Printer Name and Sharing Settings, entrez le nom de l'imprimante, le nom du partage de fichiers et l'emplacement (dans cet exemple le nom du partage est "Imprimante Technique" et l'emplacement est PIS/FRANCE/NOISY/OPEN-SPACE-TECHNIQUE).

Patientez durant l'installation du pilote d'impression...

Une fois le pilote installé, afficher les propriétés de l'imprimante dans la console MMC Print Management, allez dans l'onglet Sharing, puis cliquez sur le bouton Additionnal Drivers...

Remarque : Vous pouvez également côcher la case List in directory pour créer l'objet imprimante correspondant dans l'annuaire Active Directory (par défaut l'objet imprimante sera créé à l'intérieur du compte ordinateur correspondant au serveur d'impression).

Côchez la case x86, puis cliquez sur le bouton OK.

Une fenêtre doit alors s'ouvrir et demander le pilote d'impression x86 (à télécharger sur le site du constructeur).

Une fois le pilote x86 correctement installé, une nouvelle fenêtre demande un fichier nommé ntprint.inf présent dans le répertoire i386.

Spécifiez ici l'emplacement du fichier ntprint.inf (emplacement situé dans le répertoire C:\ Windows \ winsxs \ x86_ntprint.inf_<id>_<version>_none_<id> d'une machine Vista / Seven / 2008 en version 32 bits).

Après quelques secondes le pilote est correctement installé !

Commande sconfig et activation de Windows

Les versions Core de Windows Server 2008 R2 intègrent un nouvel utilitaire nommé sconfig. Cet utilitaire permet de simplifier les tâches de configuration usuelles (installation des mises à jour Windows Update, intégration dans un domaine, activation du bureau à distance, réglage de la date et de l’heure…) via un système de menus textuels.

Malheureusement sconfig n’intègre pas d’option pour activer le système d’exploitation. Pour cela il faut toujours utiliser le script slmgr.vbs présent dans “C:\Windows\System32”.

Procédure d’activation

Voici la procédure à suivre pour effectuer l’activation avec slmgr.vbs :

Dans un premier temps il est possible d’afficher l’état d’activation du serveur en saisissant les commandes suivantes :

• cd c:\Windows\System32
• slmgr.vbs –xpr

Dans notre exemple le système n’est pas activé car une date de fin est annoncée pour la période de grâce.

Pour insérer la clé de produit dans le système il faut ensuite saisir la commande suivante :

• slmgr.vbs –ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

Une fenêtre Windows Script Host doit apparaître suite à l’injection de la clé de produit. Pour débuter l’activation à travers Internet, la commande suivante doit être saisie :

• slmgr.vbs /ato

Si l’activation est réussie, le message suivant doit apparaître au bout de quelques secondes : “Product activated successfully”.

Suite à l’activation du serveur, la commande slmgr.vbs –xpr doit renvoyer le message suivant “The machine is permanently activated”.

Positionnement d’un serveur de proxy

Si l’accès au Web est conditionné par le passage à travers un serveur de proxy, celui-ci doit être renseigné au préalable avec la commande suivante :

• netsh winhttp set proxy <proxy-FQDN>:<proxy-port>

Dans le cas contraire une erreur de type “slui.exe 0x2a 0x80072EE2” ou “error: 0x80072EE2” se produit lors de la tentative d'activation.

Dans le cadre d’une migration depuis un “ancien” serveur SQL 2005 vers un nouveau serveur sous SQL 2008 SP1, j’ai été amené à déplacer les bases de données associées à un pool OCS 2007 R2.

Ce billet décrit la procédure à suivre pour réaliser cette opération.

La première étape consiste à arrêter tous les services OCS sur le ou les serveurs frontaux composant le pool.

Ensuite, il faut se connecter au serveur SQL et mettre hors ligne l’intégralité des bases de données liées à OCS 2007 R2.

N.B. : Il est également possible d’utiliser la fonction “Detach…”, voire d’effectuer une sauvegarde des bases.

Les fichiers de bases de données (MDF) ainsi que les journaux de transaction (LDF) doivent être copiés sur le serveur SQL de destination dans les répertoires appropriés.

Il est ensuite possible de rattacher les bases de données OCS sur le serveur SQL de destination à l’aide de la console SQL Server Management Studio. Pour cela il faut se connecter à l’instance adaptée, faire un clic droit sur “Databases” puis sélectionner “Attach…”.

Dans la fenêtre permettant de rattacher une base SQL, il faut cliquer sur “Add”, puis sélectionner le fichier MDF nouvellement copié.

Attention : Il est possible que le fichier LDF ne soit pas localisé automatiquement (notamment si l’emplacement de stockage a changé par rapport au serveur SQL d’origine). Dans ce cas un message “Not Found” s’affiche en face du fichier LDF et le chemin doit être corrigé manuellement.

Cette opération doit être répétée pour chacune des bases de données OCS 2007 R2.

Le script suivant doit ensuite être exécuté dans la console SQL Server Management Studio afin de repositionner les autorisations nécessaires sur les groupes d’administration OCS (<domain> doit être remplacé par le nom NetBIOS de votre domaine Active Directory) :

CREATE LOGIN [<domain>\RTCArchivingUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCComponentUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCHSUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCUniversalReadOnlyAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCUniversalServerAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;

CREATE LOGIN [<domain>\RTCUniversalUserAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;

EXEC sp_dboption 'rtc', 'db chaining', TRUE EXEC sp_dboption 'rtcdyn', 'db chaining', TRUE

Une fois le script exécuté, vous pourrez vérifier la présence des groupes OCS dans la section Security / Logins de la console SQL.

Enfin, la dernière étape consiste à exécuter la commande suivante sur le serveur OCS (le but de cette commande est de reconfigurer le pool OCS pour pointer vers le nouveau serveur SQL) :

lcscmd /forest /action:updatepoolbackend /poolname:mypool /poolbe:mysqlserver\rtc

Remarque : “mypool” doit être remplacé par le nom NetBIOS du pool et mysqlserver\rtc représente la nouvelle instance SQL Server (si vous utilisez l’instance par défaut alors il suffit de préciser le nom du serveur).

A l’issue de cette étape vous pouvez valider la bonne modification du pool en affichant la valeur de l’attribut msRTCSIP-BackEndServer à l’aide d’ADSIEdit.

Une fois ce point validé, la migration est terminée et les services OCS peuvent être redémarrés !

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

Pourquoi synchroniser l’heure ?

Au sein d’un domaine Active Directory, tous les postes de travail et serveurs membre synchronisent leur horloge auprès du contrôleur de domaine ayant le rôle d’émulateur PDC (Primary Domain Controller) que joue le rôle de serveur de temps pour le domaine.

Le bon fonctionnement de certains protocoles comme Kerbros v5, utilisé pour authentifier les utilisateurs au sein du domaine et assurer l’accès aux ressources partagées, est fortement dépendant de la synchronisation horaire entre les machines.

En effet, la RFC 4120 stipule que le décalage acceptable entre deux hôtes est de l’ordre de 5 minutes environ.

Each host on the network MUST have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection.  The degree of "looseness" can be configured on a per-server basis, but it is typically on the order of 5 minutes.

C’est d’ailleurs cette valeur qui est positionnée par défaut depuis Windows 2000 sur le service Kerberos (cf. article KB837361 de la base de connaissance Microsoft).

Lorsque le décalage entre deux postes dépasse les 5 minutes, aucune authentification n’est possible via le protocole Kerberos. Ceci est particulièrement gênant lorsque la machine décalée correspond à un contrôleur de domaine ou à un serveur de fichiers.

Il convient donc de s’assurer que tous les postes et serveurs sont capables de joindre l’émulateur PDC et de mettre à jour leur horloge (lorsque cela n’est pas le cas, des erreurs W32Time sont générées par le service de temps Windows sur les postes de travail).

Il est également très important de synchroniser l’émulateur PDC avec une source de temps externe valide de manière à ce que l’heure propagée au sein du domaine soit la plus proche possible de l’heure exacte.

Or de trop nombreuses entreprises ne font pas attention à ce point qui n’est pourtant pas un détail car une juste synchronisation de l’horloge simplifie la vie des utilisateurs qui sont très friands de services Web où l’horodatage a une importance certaine (tweeter, myspace ou facebook pour ne pas les nommer).

D’un point de vue IT, la synchronisation de tous les équipements informatique (postes de travail, serveurs, mais aussi NAS, pare-feu et autres équipements réseau) auprès d’une seule et même source de temps permet de simplifier énormément les opérations de dépannage car les fichiers de logs sont alors parfaitement synchrones.

Quelle source de temps utiliser ?

Par défaut tout poste Windows est configuré pour synchroniser son horloge auprès du serveur “time.windows.com”.

De nombreux serveurs NTP “libres” sont accessibles en France et dans le monde (notamment les serveurs NTP des grandes universités françaises). De plus la plupart des FAI proposent à leurs clients un service de synchronisation de temps.

Il est néanmoins un projet qui se distingue de tous les autres par son ampleur : NTP Pool Project. Ce projet a pour objectif de proposer gratuitement un cluster de serveurs de temps gigantesque (1873 serveurs de temps à l’heure où j’écris ces lignes).

L’avantage de ce projet est qu’il propose également une configuration régionalisée par continent et par pays. Ainsi pour synchroniser votre PDC avec des serveurs de temps uniquement situés en France (env. 130 serveurs), il suffit de configurer le serveur pour pointer vers la liste de FQDN suivants :

• 0.fr.pool.ntp.org
• 1.fr.pool.ntp.org
• 2.fr.pool.ntp.org
• 3.fr.pool.ntp.org

Comment procéder ?

Pour reconfigurer l’horloge d’un poste sous Windows et notamment celle d’un émulateur PDC, les commandes suivantes peuvent être utilisées :

• La commande net time fonctionne sur un contrôleur de domaine Windows 2000, 2003 et Windows 2008 (cette commande est maintenant obsolète avec Windows Server 2008 R2)
• La commande w32tm doit impérativement être utilisée si le contrôleur de domaine exécute Windows Server 2008 R2

Avec la commande net time, voici la commande à saisir pour reconfigurer l’horloge du serveur de temps (PDC) vers le cluster “pool.ntp.org” français :

net time /setsntp:"0.fr.pool.ntp.org 1.fr.pool.ntp.org 2.fr.pool.ntp.org"

Pour vérifier la modification il est possible d’exécuter la commande net time /querysntp. Pour forcer la resynchronisation du PDC, il suffit de redémarrer le service de temps Windows (net stop w32time | net start w32time).

Sur un contrôleur de domaine Windows Server 2008 R2, la commande suivante doit être exécutée pour arriver au même résultat :

w32tm /config /update /manualpeerlist:"0.fr.pool.ntp.org,0x8 1.fr.pool.ntp.org,0x8 2.fr.pool.ntp.org,0x8 3.fr.pool.ntp.org,0x8" /syncfromflags:MANUAL

Cette commande doit être suivie des commandes suivantes pour que la configuration soit prise en compte et la resynchronisation initiée :

• w32tm /config /update
• w32tm /resync

Remarque : Il est également possible de le service de temps Windows pour forcer la resynchronisation (net stop w32time | net start w32time).

Les points à valider

Quelques points doivent être validés avant d’effectuer la modification sur l’émulateur PDC :

• Le port du protocole NTP doit être ouvert depuis l’émulateur PDC vers Internet (il s’agit du port UDP 123)
• Si le contrôleur de domaine est virtualisé, il convient de désactiver la synchronisation horaire entre la machine virtuelle et l’hôte physique (sinon l’heure synchronisée à travers le réseau sera toujours réécrite par celle de la machine hôte).

Voici un exemple pour un contrôleur de domaine (émulateur PDC) virtualisé avec Hyper-V 2.0 (version d’Hyper-V intégrée à Windows Server 2008 R2) :

 

Comment mettre à jour les clients ?

En ce qui concerne les postes membres du domaine, aucune opération manuelle n’est nécessaire, le service de temps Windows étant capable d’effectuer les mises à jour automatiquement.

Pour les postes configurés en groupe de travail, il convient d’exécuter la commande suivante, puis de redémarrer le service de temps Windows :

w32tm /config /update /manualpeerlist:"ntp.ad.lan,0x8"
/syncfromflags:MANUAL,DOMHIER

Remarque : Il est conseillé de créer une entrée DNS de type CNAME (alias) pointant vers l’émulateur PDC (par exemple ntp.domainead.local). Cela permet de pouvoir reconfigurer très simplement tous les postes de travail hors domaine en cas de bascule du rôle FSMO.

Dans le scénario idéal, tous les équipements réseau (commutateurs, routeurs, pare-feu, imprimantes réseau, bornes WiFi, serveurs NAS…) doivent également pointer vers le FQDN ntp.domainead.local de manière à assurer un horodatage cohérent.

Pour aller plus loin…

Quelques liens utiles pour aller plus loin :

• RFC 1305 sur le protocole NTP v3 (http://www.rfc-editor.org/rfc/pdfrfc/rfc1305.txt.pdf)
• RFC 4120 sur le protocole Kerberos v5 (http://www.rfc-editor.org/rfc/rfc4120.txt)
• Site du projet de pool NTP (http://www.pool.ntp.org/fr/use.html)
• Entrées de registre Kerberos sous Windows 2003 (http://support.microsoft.com/kb/837361/en-us)
• Lien Technet sur la synchronisation du PDC (http://technet.microsoft.com/en-us/library/cc784553(WS.10).aspx)

La problématique

Lors de l’installation de Symantec Mail Security for Exchange 6.5 sur un serveur Exchange 2010, l’erreur suivante se produit :

Failed to enable ASP.NET web extensions. Installation will not continue.

L’explication

A l’heure actuelle Symantec Mail Security utilise encore des fonctionnalités héritées de IIS 6 (l’installeur à notamment besoin du script iisext.vbs).

Par défaut les composants de rétrocompatibilité IIS 6 suivants sont installés sur un serveur Exchange 2010 exécutant le rôle Hub, Mailbox, Cas ou Unified Messaging (seul le rôle Edge n’est pas concerné car il n’utilise pas IIS) :

• IIS 6 Metabase Compatibility
• IIS 6 Management Console

Cela n’est pas suffisant pour SMS qui nécessite également le composant IIS 6 Scripting Tools.

La Solution

La solution consiste tout simplement à installer les composants IIS 6 Scripting Tools et IIS 6 WMI Compatibility (le premier étant dépendant du second, les deux doivent être installés).

Cette opération peut être effectuée graphiquement via la console MMC Server Manager ou bien en console Powershell via la commande Add-WindowsFeature.

Pour plus d’informations sur les pré-requis nécessaires à Exchange 2010, vous pouvez consulter le lien suivant :

http://technet.microsoft.com/en-us/library/bb691354(EXCHG.140).aspx

Cette solution est tirée de la note technique suivante, pour l’instant uniquement validée avec SMS 6.0 :

http://service1.symantec.com/SUPPORT/ent-gate.nsf/docid/2008081210523154

La problématique

Lors de l’exécution de la commande Sysprep sur une machine virtuelle Windows Seven fraîchement installée, j’ai rencontré l’erreur suivante :

A fatal error occurred while trying to sysprep the machine.

Le sysprep était exécuté avec les options suivantes :

• /generalize
• /oobe
• /unattend

Suite à des recherches sur le site http://support.microsoft.com, j’ai localisé plusieurs articles traitant d’une problématique proche mais appliquées à Windows Vista. Aucune ne m’a été utile.

La solution

J’ai finalement trouvé la solution sur un forum Technet dont voici le lien :

http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/6208afb1-8f3e-4657-a618-0e4a52e9f546

Le problème semblerait venir du service “Windows Media Player Network Sharing Service” et à mon grand étonnement la désactivation de ce service (ou bien la suppression du processus associé : wmpnetwk.exe) a bel et bien résolu mon problème !

En proie au doute, j’ai ré-exécuté l’opération plusieurs fois sur la même machine (en utilisant un snapshot Hyper-V pour revenir en arrière) et ce tips semble bel et bien viable !

N’hésitez pas à laisser un commentaire ou un retour d’expérience si vous avez déjà été confronté à ce problème avec la commande sysprep de Windows 7 ou si ce billet vous a aidé !

Durant les phases de POC ou de pilote il peut s'avérer intéressant de générer des messages reconnus comme étant des SPAM par Brightmail.

Cela permet notamment de valider le bon fonctionnement des règles antispam et/ou des règles de conformité positionnées dans l'environnement du client.

Pour cela il est tout à fait possible d'envoyer un email contenant dans l'objet ou dans le corps du message quelques mots ou expressions savamment choisies.

Il est également possible d'utiliser un en-tête SMTP prévu à cet effet dans le moteur antispam des Appliances SBG !

L'astuce consiste à ajouter l'expression X-Advertisement:spam lorsque vous envoyez un email de test sur une invite de commande en telnet (NB : Cette expression doit être saisie après la commande DATA).

Dans l'exemple ci-dessus, l'email est bel et bien reconnu comme SPAM et l'action prise consiste à modifier l'objet du message, puis à envoyer le message dans la quarantaine.

Ce tips est tiré de la note technique suivante :

Testing mail flow and spam detection in Symantec Brightmail products and Symantec Mail Security appliances.

Introduction

Les boitiers Symantec Brightmail Gateway (anciennement SMS 8300) sont des Appliances antispam et antivirus commercialisées par Symantec. Ces Appliances sont également capables d'appliquer des règles de conformité voir de s'intégrer à des solutions DLP.

On distingue plusieurs types de mises à jour sur les boitiers SBG :

• Les mises à jour des définitions antispam sont appliquées automatiquement par le service Conduit (les mises à jour ont lieu toutes les 10 minutes environ)
• Les mises à jour des définitions antivirus sont appliquées automatiquement par le service LiveUpdate en fonction de la planification définie par l'administrateur
• Les mises à jour du logiciel (software) qui sont appliquées manuellement à l'initiative de l'administrateur

C'est bien entendu la troisième catégorie qui nous intéresse ici ! Symantec ne fournit par de roadmap publique précise en ce qui concerne les mises à jour du logiciel. Néanmoins on peut considérer que des mises à jour mineures sont disponibles de manière trimestrielle et que des mises à jour majeures sont effectuées tous les 1 à 2 ans.

A titre informatif, voici la liste des mises à jour du software de ces deux dernières années en ordre chronologique :

• Août 2007 - 7.5
• Mars 2008 - 7.6.1-7
• Août 2008 - 7.6.1-14
• Septembre 2008 - 7.7.0-17
• Janvier 2009 - 8.0.0-24
• Mars 2009 - 8.0.1
• Mai 2009 - 8.0.2
• Octobre 2009 - 8.0.3  

Pour être averti instantanément lors de la disponibilité d'une nouvelle version du logiciel, le plus simple reste d'utiliser les alertes par emails intégrées au sein du produit (cf. capture d'écran ci-dessous).

Les Best Practices

Voici les best practices en ce qui concerne les mises à jour du logiciel d'une Appliance Symantec Brightmail Gateway :

• Effectuer une sauvegarde de la configuration du "control center"
• Vérifier que le "control center" n'est pas en train d'effectuer une synchronisation avec un serveur d'annuaire
• Vérifier que les "scanner" ne sont pas en train d'effectuer une réplication des données LDAP à partir du "control center"
• Configurer la pile MTA des boitiers "scanner" sur "Do not accept incoming messages"
• Mettre à jour les boitiers "scanner" avec le "control center"

Procédure

Pour lancer la mise à jour d'une Appliance via l'interface Web, il faut suivre la procédure suivante :

1. Cliquer sur Version dans l'onglet Administration
2. Aller dans l'onglet Updates

Il faut ensuite sélectionner la mise à jour, afficher la description (les "release notes"), puis cliquer sur le bouton Update.

L'interface Web affiche ensuite la barre de progression ci-dessous :

Aucune précision supplémentaire n'est ensuite affichée dans l'interface Web. Pour suivre de manière plus précise les différentes étapes de l'installation (téléchargement des différents modules, installation...), il faut se connecter en SSH sur l'Appliance avec un client tel que putty et utiliser la commande watch update.log (cf. capture d'écran ci-dessous).

A l'issue de l'installation, il est possible de vérifier la version installée sur le boitier à l'aide de la commande version.