by Marc
30. janvier 2010 11:42
Détails techniques: http://support.microsoft.com/kb/974674/fr
Téléchargements:
Cette MAJ est donc également disponible pour Windows Server 2008 R2 en version 64-bit uniquement évidemment:
Marc
by Marc
25. janvier 2010 12:21
Une petite surprise de fin d’année 2009 repointe le bout de son nez début 2010: Sur IIS6, si un site est paramétré pour utiliser l’authentification Windows Intégrée (IWA), le processus W3WP.exe servant ce site est susceptible de planter avec le code de retour 0xffffffff si Windows Server 2003 est en service pack 2 et que la mise à jour KB973917 est installée.
Ce problème est en fait causé par un certain nombre de fichiers d’IIS qui ne sont pas au niveau requis malgré la présence du service pack 2.
Petite procédure pour remettre IIS en ordre de marche et si nécessaire réinstaller cette MAJ
- Effectuer un inventaire des MAJ actuellement installées, afin de pouvoir les réinstaller si nécessaire par après. Personnellement j’utilise PsInfo pour ce faire (option –h). Mais il existe évidemment d’autres méthodes
- Ré-appliquer le Service Pack 2
- Si nécessaire, réinstaller les MAJ en fonction de l’inventaire effectué à l’étape 1
- Vérifier les niveaux de version des fichiers d’IIS. Voir “Complément d’information”
- Si nécessaire, réinstaller la MAJ KB973917
Complément d’information
Evidemment, il se peut que IIS plante pour d’autres raisons. Le code de retour devrait dans ce cas vous mettre sur la piste du coupable.
Marc
by Marc
9. novembre 2009 18:18
A plusieurs reprises, il m'a été donné d'aider des administrateurs ou développeurs SharePoint aux prises avec ce comportement pour le moins déconcertant: alors que les utilisateurs peuvent se connecter et s'authentifier au serveur SharePoint sans le moindre problème, les administrateurs ayant ouvert une session localement sur le serveur se voient refusés l'accès à SharePoint tout en recevant l'erreur HTTP 401.1 (Unauthorized: Access is denied).
Ce comportement est, comme souvent avec Microsoft "By Design" depuis le service pack 1 de Windows Server 2003: il a pour but d'augmenter le niveau de sécurité sur un serveur lorsque les conditions suivantes sont d'application:
- La version de l'OS est au moins Windows Server 2003 SP1
- Un utilisateur ou administrateur est loggé localement sur la console du serveur ou via RDP
- Il (ou elle, ne soyons pas macho, le système ne l’étant pas), tente d’accéder à une ressource ou un service utilisant l’authentification NTLM en passant un nom d’hôte pointant vers l’adresse de loopback (127.0.0.1) alors que ce nom d’hôte n’est pas “localhost”
Le résultat étant un “Access Denied” ou en langage HTTP, un 401.1. il est à noter que ce problème pourrait tout aussi bien se produire en accédant à un répertoire partagé, par ex.
Bien mais pourquoi est-ce alors si flagrant dans le cas de SharePoint? Il existe deux grands cas de figure dans lesquels il est fréquent de recourir à la modification du fichier HOSTS afin de faire pointer une ou plusieurs application web vers l’adresse 127.0.0.1:
- L'indexeur paramétré pour se viser lui-même, et non un autre serveur frontal. Cela se faisant soit manuellement par l’édition du fichier HOSTS, soit en laissant SharePoint s’en charger
- Les machines de développement, afin d’éviter de devoir enregistrer des noms dans le serveur DNS
Il n’est pas rare que des scripts de “warm-up” de SharePoint provoque également le problème.
Plusieurs solutions existent:
Marc
by Marc
3. août 2009 09:56
La consolidation est à la mode, Exchange n'y échappe pas. Moins de serveurs donc plus de BALs sur le même serveur. Idem pour les contrôleurs de domaine AD.
Récemment, un client en pleine phase de consolidation m'a fait part d'un problème d'authentification impactant uniquement les utilisateur d’Outlook et ce de manière récurrente: “aléatoirement”, les utilisateurs reçoivent une boîte de dialogue émanant d’Outlook leur demandant de se ré-authentifier. Les administrateurs Messagerie ayant tôt fait de décréter qu’il s’agissait d’un problème AD, l’équipe en charge dudit AD a commencé à chercher les problèmes d’ouvertures de session, de comptes verrouillés etc… Mais rien de visible au niveau des contrôleurs de domaine: pas de “logon failed”, de mot de passe expiré, en tout cas pas pour les utilisateurs subissant ce désagrément. Plus étrange encore, ce sont les utilisateurs d’un même site qui se plaignent, mais les utilisateurs impactés sont différents chaque jour (!).
Décision fut prise de prendre une trace réseau à partir du contrôleur de domaine dédicacé à ce site et également utilisé pour les opérations MAPI/NSPI. Verdict: le DC retourne à certains clients le message “MAPI_E_LOGON_FAILED” alors que l’utilisateur est bel et bien authentifié avec certitude. Après investigation, le coupable est une nouvelle option de sécurité au niveau AD qui limite le nombre de connections MAPI/NSPI concurrentes à 50 (par défaut) sur les DC tournant sous Server 2008 et retourne donc l’erreur MAPI_E_LOGON_FAILED à Outlook. Celui-ci l’interprétant correctement cad en demandant de saisir nom d’utilisateur et mot de passe à nouveau.
Fort heureusement, il est possible d’augmenter cette limite de conncetions voire de revenir au comportment d’application sur les versions antéreures de Windows (2000-2003). L’article du support MS ci-dessous fournit les explications, la solution ainsi que le niveau de logging à configurer pour qu’un événement soit écrit de le log de Windows dès que la limite est atteinte.
On aurait évidemment préféré que le protocole côté serveur retourne un message plus en rapport avec la cause exacte, dans le style “Too many concurrent connections” par ex…
Marc
Contact
Souscrire
Filter by APML