La seconde solution qui s’offre à vous est l’utilisation des services Windows Network Load Balancing. Pour en avoir installé plusieurs fois, ce service « fonctionne » mais possède pas mal de défauts.
Le premier tient parfois à sa complexité de mise en place selon l’environnement
WINDOWS Network LOAD BALANCING (WNLB)

réseau, surtout dans des environnements virtuels ou lorsque vous être confronté à deux sites physiques distants inscrits dans le même sous réseau IP.
Le second problème est qu’il ne prend pas en compte la vérification du fonctionnement des services. Comme le DNS Round Robin, la couche NLB Windows n’a pas grand-chose à voir avec l’environnement Exchange. Si l’un des serveurs d’accès client vient à cesser de fonctionner, le WNLB lui, toujours actif, tentera d’acheminer les requêtes clients vers le serveur hors service.
Le troisième problème comme je l’ai rappelé en introduction, vient du fait qu’il est incompatible avec le service Windows failover Clustering que vous allez trouver sur les machines Exchange 2010 qui supporteront les rôles de serveur de boîtes aux lettres. Par conséquent, si vous vous engagez sur la mise en place deux machines en haute disponibilité abritant les rôles Hub, Cas et Mailbox, vous ne pourrez pas utiliser la couche WNLB.
Le quatrième problème que vous risquez de rencontrer en mode unicast, est ce que l’on appelle le Port Flooding. C’est d’ailleurs pour cette raison que le WNLB est souvent installé en mode Multicast (Voir sur le site Technet de Microsoft). Pour plus d’informations sur le protocole NLB merci de vous rapporter à l’article Technet suivant.
Ensuite, viennent quelques petits inconvénients d’administration.
- Le premier inconvénient vient du fait que si vous ajoutez un membre du cluster ou si vous en supprimez un, alors les clients Exchange vont devoir se reconnecter.
- Le second tient à la limitation de 8 Nœuds au sein d’un même cluster.
Viennent ensuite les véritables solutions (voir l’article WordPress) que sont les solutions de répartition de charge matériel qui vont réellement prendre en charge les problématiques de persistance de sessions, de panne de services en testant véritablement la présence du service concerné.
La figure 1 montre un exemple de ce qu’est capable de faire un répartiteur de charge : Tester la réponse d’une page OWA et de s’y connecter si besoin est.
Nous reviendrons bien évidement à l’offre matérielle actuellement disponible à ce jour en fin d’article. Intéressons maintenant aux principes de répartition de charge dans ce cas précis.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Cybersécurité : l’IA générative rebat les cartes du cybercrime
- Le World Cyber Ranking, 1er classement mondial de la cybersécurité des entreprises
- Comment le Quarter Plan permet d’aligner IT et Métiers pour délivrer
- Explosion des attaques d’ingénierie sociale en 2025
- SI sous pression : 3 signes que vos flux sont mal orientés
