Archive

Posts Tagged ‘Erreur 500’

HTTP 500 SharePoint Troubleshoot

Hey Folks !

En ce début d’année je vous propose un petit topo sur les erreurs 500 qui peuvent exister au niveau IIS sur du SharePoint.

Une erreur 500 c’est quoi d’abord ? … enfin comment sait on si c’est une erreur et comment, pourquoi 500. L’ensemble est basé sur les codes d’un protocol (ici HTTP) les codes de statuts quand a eux sont spécifiés par une RFC (la RFC 2616)

Niveau code, la règle est la suivante et les codes commences par :

Information : 1

Succès : 2

Redirection : 3

Erreur Client || Serveur : 4

Erreur Serveur (niveau applicatif) : 5

 

A quoi ressemble une erreur de type 500 ?

image

(Ahhh oui ca me parle….)

 

Passons au vif du sujet, comment trouver la source de l’erreur 🙂

Tout d’abord lorsque vous rencontrez cette erreur, essayer depuis un autre poste des fois que la configuration ne soit pas correcte, et pouvoir incriminer le serveur ou le poste client 🙂

Ensuite, toujours depuis le client, vérifiez bien si le site auquel vous voulez accéder est bien le bon (question de réseaux) essayer de pinger la machine, tracert, tcping, nbtstat, nslookup, etc. …

Une fois les postes clients exclus, vérifiez a partir du serveur SharePoint (cela peut venir de SQL, mais vous aurez une erreur SQL) Checker ensuite les AAM de SharePoint en vérifiant le DNS, généralement c’est bien visible dans les ULS.

Vérifier ensuite les applications pools, ils peuvent être a l’arrêt suite à iisreset (par ailleurs avec SharePoint ajouter toujours iisreset /noforce) si c’est le cas de votre application pool, démarré le. Si le problème persiste cela proviens généralement du compte de l’application pool, renseignez vous pour savoir qui a changé les passwords du compte… Vous verrez ca dans les logs de IIS (dans l’event viewer).

Vous pouvez aussi vérifier les mappages de IIS, afin de vous assurez que iis est bien à l’écoute sur l’hôte. (Pour les NLB c’est un peu plus particulier)

A ce stade l’ensemble des éléments d’ordre infra sont vérifiés mais il reste encore les fichiers web.confg, applicationHost, etc. …

Par défaut les fichiers web.config sont stockés à l’emplacement c:\inetpub\wwwroot\wss\virtualDirectories\ID Site  …. pensez à changer les emplacements des fichiers web.config, c’est une best practices Microsoft SharePoint. Une fois le fichier trouvé, vérifier la date de modification.

Notez qu’il est possible de passer la balise EnableCustomError à la valeur Off pour avoir plus d’info mais cela nécessite un reset du pool d’application.

Afin de ne pas effectuer cette action, nous allons activer le Failed Request Tracing de IIS.

IIS Failed Request Tracing

Pour le paramétrage avec l’assistant, laisser All Content puis entrer 500 pour le Status code.

IIS Failed Request Tracing

Essayer a nouveau d’accéder au site, vous aurez toujours l’erreur 500 , mais vous aurez un fichier de log (au même emplacement que le Web.config) vous verrez deux fichiers, un XML avec les erreurs et un XSLT permettant de mettre en forme le XML lié.

Ouvrez alors le fichier XML dans le navigateur vous verrez alors le numéro de la ligne contenant l’erreur dans votre fichier web.config

Dans beaucoup de cas, il s’agit de problématique de balises ou de commentaires.

 

Hope this helps,

& stay tuned !

 

 

 

 

 

 

Catégories :IIS, Troubleshooting Étiquettes : , , ,