L'article idoine de la KB Microsoft (http://support.microsoft.com/kb/820129) le dit très bien:
La valeur configurée dans le script d'Exchange Server 2010 est donc alignée avec la base de connaissance IIS de Microsoft. Dans des environnements plus classiques, mettre 65534 pour MaxFieldLength et 65536 pour MaxRequestBytes suffit généralement à résoudre 99.99% des problèmes (Note: MaxRequestBytes doit être à minima supérieur de 2 octets à MaxFieldLength).
Bref, éviter les problèmes Kerberos... Il semblerait que cela soit la volonté de la DevTeam car dans Exchange Server 2013 Preview, on constate que ces deux valeurs sont positionnées par défaut... à 65536 ! (Au passage, on remarque que les scripts en rapport avec Kerberos n'existent plus... :))
La preuve en images:
Là où le bât blesse est que la valeur positionnée par Exchange Server 2013 dépasse le maximum théoriquement configurable. Il faudra donc effectuer quelques tests et vérifier que le pilote HTTP.SYS se comporte correctement sur les deux systèmes supportés (Windows Server 2008 R2 SP1 et +, et 2012 RTM et +). En effet, il arrive parfois qu'une valeur de registre dépassant le maximum autorisé soit traitée comme invalide et donc ignorée (et donc 16Ko ici)... si le code du pilote HTTP.SYS est bien fait, il devrait traiter toute valeur hors limites comme étant la limite (donc ici, dépassant la limite haute: 65536 est corrigé en 65534).
Fait étrange (mais probablement pas exprès :)), Lync Server 2013 ne positionne pas cette valeur. Pourtant, il est fréquent que le Remote Shell Lync ne fonctionne pas pour cette même raison (à cause de la taille du token Kerberos...) et que cela fasse planter le Lync Control Panel .
Donc, sauf erreur de ma part, et étant un puriste, MaxFieldLength devrait être positionné à 65534. Je vais tout de même tenter de prévenir la DevTeam au cas où...
Articles
Bonjour,
RépondreSupprimerMerci pour l'article.
Je suis confronté à un soucis avec le client lync 2013 qui affiche de manière aléatoire un popup demandant login/mdp. En cliquant sur annuler et la fenêtre se ferme et l'utilisateur peut continuer à utiliser le client.
Je m'orientais sur l'authent kerberos et je suis tombé sur cet article.
Est-ce que cela peut venir des valeures MaxFieldLength et MaxRequestBytes ?
Bonsoir PaLoTTE,
RépondreSupprimerIl est fort à parier que vous ayez une divergence d'authentification entre votre client Oulook/Exchange et votre client Lync. Cela peut arriver parfois lorsque l'un des clients démarre l'authentification en Negotiate et passe en Kerberos, et que l'autre passe et Negotiate et finit par tomber en Ntlm.
Si vous avez installé Lync Server, par défaut l'authentification se fait en Negotiate mais les Web Services en particulier seront en Ntlm. Il y a de la configuration additionelle afin de faire du "Full Kerberos" sur Lync... Comme pour Exchange cela passe par la création d'une identité portant les SPNs HTTP/truc.domain.com.
Vous pouvez tenter de forcer Outlook à utiliser l'authentification Ntlm (propriétés du compte ==> sécurité) et voir si cela change la donne.
En ce qui concerne le MaxFieldLength et MaxRequestBytes, il est recommandé de les mettre à niveau quoiqu'il arrive. Je n'ai pas mentionné dans l'article: si vous voulez activer Kerberos sur Exchange, Lync (et autres), il faudra aussi combiner le changement de ces valeurs avec une augmentation probable du MaxTokenSize. La valeur recommandée pour cette dernière valeur est 48000 octets (c'est d'ailleurs la valeur par défaut dans Windows Server 2012...).