J’ai été récemment confronté par deux fois à d’importantes lenteurs sous SharePoint 2007:

• Lors du premier appel suite à recyclage de l’application pool: 2 minutes pour avoir la page
• Lors de la recherche d’une personne dans l’AD : au moins 30 secondes

2 minutes lors du premier appel

IIS essaye de contacter crl.microsoft.com en http, mais n’y arrive pas. Ceci afin de vérifier la signature des assembly dans le GAC .Net. Les symptômes ainsi que des solutions sont proposées sur ce blog:

http://www.muhimbi.com/blog/2009/04/new-approach-to-solve-sharepoints.html

J’ai choisi la méthode suivante:

• Téléchargement des CRL:
  • http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
  • http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
• Ajout des CRL au magasin:
  • certutil -addstore CA CodeSignPCA.crl
  • certutil -addstore CA CodeSignPCA2.crl

Et voilà, on passe à environ 20 secondes, ce qui est « normal » dans la mesure où il doit compiler. Vous pouvez aller encore plus loin en:

• changeant l’heure par défaut de recyclage de l’application pool
• Utiliser SPWakeUp, pour « chauffer » le moteur SharePoint en appelant chaque site

Recherche dans l’AD : au moins 30 secondes

Symptômes: vous essayez d’autoriser un utilisateur, un groupe, ou juste assigner une tâche à quelqu’un, cela prends au moins 30 secondes au lieu d’une seconde en général. Je parle ici du temps entre le moment où l’on clique sur la recherche et le moment où le nom est souligné (donc validé).

Analyse du problème: dans mon cas, en traçant l’activité réseau du serveur, on se rend compte qu’il essaye de contacter en vain des contrôleurs de domaines d’une autre forêt en vain au même moment à plusieurs reprise. Cette tentative de connexion est dûe à l’ajout d’une autre forêt via stsadm pour la propriété peoplepicker. Par défaut, SharePoint ne cherche des utilisateurs que dans le domaine où il est. Pour étendre la recherche à d’autre domaines/forêt, il faut les ajouter avec cette commande:
stsadm -o setproperty -url http://SharePointSite:85 -pn peoplepicker-searchadforests –pv “domain1.com”,<loginname1>,<password1>;”domain2.com”,<loginname2>,<password2>

S’il y a une relation d’approbation entre les forêts, il n’y a pas besoin de spécifier un login et un mot de passe.

Voici un post plus détaillé sur le sujet: http://www.gk.id.au/2009/04/people-picker-sharepoint-and-forest.html

Solution: Autoriser les serveurs SharePoint à se connecter aux contrôleurs de domaines de la forêt ciblée. Le port à ouvrir est ldap (389) à la fois en TCP et UDP.

Et voilà, la recherche prend de nouveau environ une seconde et on peut maintenant aussi chercher des utilisateurs de l’autre forêt!

Popularity: 5% [?]