none
Problème serveur Exchange 2013 sur le protocole IMAP4 : connexion dépassé, comment diminuer le nombre de connexion en mémoire cache ? RRS feed

  • Discussion générale

  • Bonjour à tous,

    J'ai un problème sur un serveur Exchange 2013 pour un de mes clients, je bloque totalement.

    - Le message concerne des utilisateurs utilisant ThunderBird avec le Protocal Imap4, Information important, cela fonctionne en Webmail pour les utilisateurs.

    - Message d'erreur :

    Impossible de se connecter au serveur IMAP, vous avez-eut-être dépassé le nombre de connexions au serveur. Si c'est le cas, utilisez les paramètres avancés de serveur IMAP pour diminuer le nombre de connexions conservées en mémoire cache. <--  Ici je ne suis pas sur de savoir comment faire.

    - Actions effectuées :

    1.  Contrôle des ports ouverts de notre parfeu stormshield / Ok 
    2.  Contrôle des services MSExchangeIMAP4BE et MSExchangeImap4 et redémarrage en Powershell Exchange / Ok   
    3.  Mise à jour du système d'exploitation --> reboot
    4. Connexion en ECP en admin --> Serveur --> Serveur --> IMAP4 --> Limites de connexion (2147483647) modifié en (1147483647) --> reboot --> toujours même problème --> remise en état d'origine --> reboot --> même Problème....
    5. Nombre maximal de connexions à partir d'une seule adresse IP : 2147483647) modifié en (1147483647) --> reboot --> toujours même problème --> remise en état d'origine --> reboot --> même Problème....
    6. Vous demandez de l'aide.

    Si quelqu'un à une petite idée qu'il/elle m'en face part je suis totalement bloqué, et les utilisateurs ne peuvent pas utiliser leurs logiciel ThunderBird

    En vous remerciant de votre contribution bonne journée à tous 

    jeudi 14 novembre 2019 09:21

Toutes les réponses

  • Bonjour,

    Le point de départ serait déjà de savoir où la connexion bloque.

    Je vous propose de vérifier ceci (dans l'ordre) :

    • Au niveau de votre pare-feu : quel est le nombre de sessions TCP établies et en attente (ESTABLISHED, TIME_WAIT) à destination du serveur exchange sur le port IMAP (143) : est-ce que le pare-feu est en mesure de conserver autant de sessions simultanées ET n'y a t-il pas un protocole de type IPS qui limiterait ce nombre de sessions ?
      Il vous faudra certainement vous rapprocher du manuel de Stormshield et/ou de leur support
    • Ensuite, au niveau du Windows Server qui héberge Exchange : au moment du problème, combien de sessions TCP sur le port 143 ouvertes (netstat -ant|findstr ":143") ?
      En effet, même si vous limitez à 2 milliard le nombre de connexions, la pile TCP/IP n'est pas en mesure d'en gérer autant

    Une fois déterminé où se situe le problème (pare-feu ou Windows), vous saurez où intervenir.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    jeudi 14 novembre 2019 13:15
  • Bonjour,

    Merci de votre réponse, j'ai vérifié les informations que vous m'avez fournis le résulta est :

    1. Le Stormshield à que très peut de connexion en Time_wait
    2. Le Stormshield n'effectue pas de filtrage ips/ids entrante et sortant sur le serveur
    3. La commande netstat -ant|findstr ":143" me ressort 6 connexions. en time_wait
    4. La commande netstat -ant|findstr " 587 me ressort 3 connexions en established

    Savez-vous s'il hésite une commande permettant de réinitialiser les connexions serveur du protocole IMAP ?

    Car les autres clients utilisent Exchange ne sont pas impactés, très curieux comme situation.

    Merci de vos réponses

    jeudi 14 novembre 2019 15:31
  • Bonjour,

    Merci de votre réponse, j'ai vérifié les informations que vous m'avez fournis le résulta est :

    1. Le Stormshield à que très peut de connexion en Time_wait
    2. Le Stormshield n'effectue pas de filtrage ips/ids entrante et sortant sur le serveur
    3. La commande netstat -ant|findstr ":143" me ressort 6 connexions. en time_wait
    4. La commande netstat -ant|findstr " 587 me ressort 3 connexions en established

    Savez-vous s'il hésite une commande permettant de réinitialiser les connexions serveur du protocole IMAP ?

    Car les autres clients utilisent Exchange ne sont pas impactés, très curieux comme situation.

    Merci de vos réponses

    Bonjour,

    Qu'en est-il des sessions établies ?

    En effet, si vous avez peu de sessions en Time_wait mais que le routeur (ou le serveur) est saturé de sessions établies, le résultat sera le même


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    vendredi 15 novembre 2019 07:28
  • Bonjour,

    Merci de votre retour une nouvelle fois.

    Après vérifications :

    J'ai pas mal de connexions établies (mais loin du million) sur le serveur et le routeur, mais cela est normal, en vue du nombre de client qui se connecte.

    D’où mon problème qui ne touche seulement une entreprise qui utilise du IMAP4 avec thunderbird.

    Cordialement,

    vendredi 15 novembre 2019 13:02
  • Bonjour,

    Je vous conseille de réduire le timeout de session authentifiée (par défaut 30 minutes) à 5 minutes, par exemple : https://docs.microsoft.com/fr-fr/exchange/set-connection-time-out-limits-for-imap4-exchange-2013-help

    Cela permettra de réduire le nombre de sockets ouverts en permanence (les clients de messagerie ne les fermant pas nécessairement).

    En parallèle, il faudrait regarder les journaux de Windows pour voir si la limite de sessions établies ne serait pas dépassée (16384 ports par défaut) : si tel est le cas, il faudra l'augmenter : https://support.microsoft.com/fr-fr/help/929851/the-default-dynamic-port-range-for-tcp-ip-has-changed-in-windows-vista


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    vendredi 15 novembre 2019 13:10
  • Re,

    Oui j'avais déjà effectué ces actions.

    Par contre dans les journaux j'ai l'erreur : 

    Une alerte irrécupérable a été reçue du point de terminaison distant. Le code d’alerte irrécupérable défini par protocole de TLS est 46.

    TLS avec SSL port 993 et 143 est le protocole de connexion à l'IMAP si je ne me trompe pas 

    cela doit jouer 

    vendredi 15 novembre 2019 14:17
  • Re,

    Oui j'avais déjà effectué ces actions.

    Par contre dans les journaux j'ai l'erreur : 

    Une alerte irrécupérable a été reçue du point de terminaison distant. Le code d’alerte irrécupérable défini par protocole de TLS est 46.

    TLS avec SSL port 993 et 143 est le protocole de connexion à l'IMAP si je ne me trompe pas 

    cela doit jouer 

    Bonjour,

    Cela signifie que le client de messagerie a généré le problème : dans ce cas, le problème semble se situer côté Thunderbird, ou du site qui héberge les Thunderbird.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    lundi 18 novembre 2019 07:04
  • Bonjour,

    Merci de vos réponses et de votre aide dans un premier temps.

    Visiblement cela impacte tout les logiciels qui utilise le protocole IMAP4. Je n'ais plus d'idées honnêtement.

    Tout me parait fonctionnelle et actif, mais cela ne fonctionne pas...

    Cordialement, 

    lundi 18 novembre 2019 09:20
  • Bonjour,

    D'après tout les tests effectuées avec différents logiciels de mails.

    Le problème viendrait du serveur, mais nous ne comprenons pas pourquoi. Pourquoi et surtout comment un protocole Imap4 ne fonctionne plus du jours au lent demain sans avertissements. Sachant que les services sont toujours actifs et répondent très bien aux commandes...

    Si quelqu'un a une idée je suis preneur.

    Cordialement,

    mardi 19 novembre 2019 09:48