Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SharePoint Grib's Lair

Journal technique de Sébastien PICAMELOT

IIS et les Applications Web SharePoint : Best Practices

SharePoint et IIS, Best Practices

Une des choses que j’aime avec SharePoint, c’est de voir que la frontière exploitation/développeurs est souvent moins marquée qu’ailleurs.

Moins marquée parce que SharePoint fait appel à tellement de systèmes différents qu’un développeur ne pourra pas s’en sortir bien longtemps sans s’intéresser à des problématiques un peu plus connotée infrastructure/système/réseau qu’à son habitude.

Moins marquée également car les admins se mettent à s’intéresser au monde du développement. Et j’insiste sur ce point, car je l’ai vu plusieurs fois : les admins veillent de plus en plus souvent aux fuites mémoire et sont aussi souvent conscient que des Best Practices de développement (l’appel au Dispose) peuvent les réduire considérablement. Mieux que ça : j’en ai vu se mettre à coder, dans Visual Studio (chose plutôt rare), ou via PowerShell  (chose déjà bien plus courante).

Bref, la frontière se réduit par endroit et c’est une très bonne chose. Il n’empêche… certaines vielles habitudes persistent de chaque côté et impliquent des difficultés d’administration et/ou des dysfonctionnement dont je viens parler ici.

Problèmes concrets :

La souplesse de SharePoint fait qu’une batterie de serveurs peut s’élargir facilement, pour mieux tenir la charge par exemple, ou encore pour assurer une continuité de service. Lorsqu’un nouveau serveur est ajouté à la batterie de serveurs, SharePoint réalise automatiquement une série d’opérations sur le nouveau serveur :

  • Création des applications pools
  • Création des sites IIS
  • Déploiement des fichiers de solution contenus dans le magasin de solutions SharePoint (fichiers dans le répertoire 12, déploiement dans le GAC/BIN, …)
  • Mise à jour des fichiers web.config en fonction des modifications gérées par SharePoint (SafeControls, SPWebConfigModification, …)

Bref, en théorie un site est opérationnel dès que le serveur est rattaché à la batterie de serveurs. En pratique, ce mécanisme est très souvent insuffisant car les développeurs et/ou les administrateurs ont introduit des changements à faire manuellement : le mécanisme automatique de SharePoint ne les réalise donc pas… et c’est le drame !

Quelques exemples de problèmes vécus :
  • Ajout manuel de paramètres dans le fichier web.config :

Les développeurs ont ajouté manuellement des paramètres dans le fichier web.config. Une ConnectionString par exemple, ou encore n'importe quel paramètre, référence à une ressource externe, etc. Lorsque l’utilisateur se connecte à l’Application Web SharePoint, le mécanisme de load balancing détermine quel serveur traite la demande. Dans certain cas le serveur qui répondra aura les bons paramètres… de temps en temps ce sera le serveur à qui il manque des paramètres. Dans le dernier cas, les utilisateurs ont de forte chance de tomber sur une page d’erreur.

  • Déploiement manuel de WebParts / Features / Ressources.

Les développeurs ont déployés les WebParts, Features et/ou ressources en les copiant manuellement dans le répertoire 12 puis en utilisant la commande stsadm –o installfeature. Le nouveau serveur sera dépourvu de ces éléments et tout utilisateur dirigé vers ce serveur sera confronté à une page d’erreur SharePoint.

  • Modification du port ou changement de host header directement depuis IIS

Qui n’a jamais voulu changer le port ou les host headers après la création d’une application Web SharePoint (pour un changement de DNS par exemple) ? Ces paramètres sont bien connus des admins qui savent les modifier depuis IIS. Lorsque cette opération est réalisée via IIS, elle reste locale. En d’autres termes, SharePoint créé automatiquement les sites IIS sur le nouveau serveur mais les modifications réalisées manuellement sur les autres serveurs ne sont pas propagées. Les utilisateurs peuvent alors tomber sur d’autres sites que ceux demandés ou sur des erreurs 404.

  • Paramétrage des pools d’applications

Assez similaire aux sites IIS. Vous pouvez souhaiter les paramétrer pour prendre en compte des modifications sur les comptes de service. Dans ce cas spécifique SharePoint ne vous laissera pas faire… en tout cas pas longtemps. En effet, SharePoint changera automatiquement le compte associé au pool d’application pour lui fixer sa propre valeur. Pour les autres paramètres du pool d’application, toute modification sur IIS reste locale.

Comment éviter ces problèmes / Les Best Practices :

Le fichier Web.Config

Les développeurs ASP.Net ont l’habitude de modifier manuellement le fichier web.config d’une application web pour y ajouter des paramètres. Avec SharePoint il faut cependant privilégier un autre moyen : la classe SPWebConfigModification. J’ai cependant souvenir de propos négatifs concernant cette classe, tels que '”tout le monde sait qu’il ne faut pas l’utiliser”. Et bien pourtant si ! Les détracteurs lui reprochent de compromettre le fichier web.config. Je répond que NON. Ces personnes ont tout simplement rencontré des problèmes avec des fichiers web.config qu’elles avaient modifiés manuellement et qu’elles voulaient modifier, en plus, via la classe SPWebConfigModification. Les problèmes potentiels ne sont à imputer qu’aux modifications manuelles et pas à la classe SPWebConfigModification. Bref, passer par cette classe pour modifier le fichier web.config est un Best Practice. A chaque fois qu’un développeur fait le choix d’une modification manuelle, il induit une difficulté supplémentaire pour les admins (en cas d’ajout ou de restauration d’un serveur SharePoint) et pour les prochains développeurs (qui ne pourront plus utiliser cette classe sans avoir de problème).

Déploiement de WebParts / Features / Ressources.

Les copier/coller sont à proscrire. Utilisez des solutions SharePoint. SharePoint stocke alors vos solutions dans le magasin de solutions et sait quelles sont les opérations à rejouer pour les déployer sur de nouveaux serveurs. En outre, ce procédé évite de toucher aux éléments natifs de SharePoint (je l’ai encore vu récemment).

Magasin de solutions SharePoint

Modification des paramètres IIS

Ce point est un peu plus délicat. En effet, l’interface d’administration SharePoint n’offre pas la possibilité de modifier ces paramètres sans détruire puis recréer l’application Web à partir d’une base de données existante. Ce mécanisme est (trop) lourd et peu envisageable. Il existe cependant une alternative, discrète : modifier les paramètres IIS depuis le modèle objet SharePoint à l’aide de la classe SPIisSettings. Un petit exemple avec du code ajoutant un host header au site IIS :

System.Uri uri = new Uri("http://localhost");
SPWebApplication webApplication = SPWebApplication.Lookup(uri);
SPIisSettings settings = webApplication.IisSettings[SPUrlZone.Default];
SPServerBinding binding = new SPServerBinding();
binding.Port = 80;
binding.HostHeader = "gribs.virtualdomain.com";
settings.ServerBindings.Add(binding);
webApplication.IisSettings[SPUrlZone.Default] = settings;
webApplication.Update();
webApplication.Unprovision();
webApplication.Provision();
Les paramètres IIS modifiables sont nombreux. Autre exemple : inutile de modifier le fichier metabase.xml à la main pour passer en Kerberos, un simple settings.DisableKerberos = false; suffit. Idem pour modifier le répertoire du site IIS : le recours à settings.Path règle le problème.

Bref, il reste à passer ce type de code en PowerShell pour ce que soit exploitable plus facilement par des admins (hum… Fabrice ? :-))

Modification de l’Application Pool

Très similaire à IIS avec la classe SPApplicationPool.

Conclusions :

Ces Best Practices se résument facilement : il FAUT passer par les mécanismes natifs SharePoint pour toute modification impactant les déploiements. Je regrette qu'il soit cependant parfois si complexe de les mettre en pratique : pour le SPWebConfigModification, par exemple, dès lors que d’autres développeurs ont fait le choix des modifications manuelles. Pour les modifications IIS également, car il n’y a pas d’interface (ça ne sautait tarder… je suis en train d’en faire une :-)).

Il n’empêche : faire l’impasse sur ces recommandations impliquera obligatoirement des lourdeurs dans les tâches d’exploitation.

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: mardi 21 avril 2009 02:41 par Gribouillon
Classé sous : , ,

Commentaires

ROMELARD Fabrice a dit :

C'est particulierement vrai pour les nouveaux développements.

En revanche, on a pas toujours la possibilité d'utiliser la classe pour le Web.Config, surtout pour des composants comme des WebParts 2003 que l'on rajoute dans 2007.

Pour le reste, je suis bien d'accord, et le PowerShell est effectivement bien pratique pour ces cas précis, c'est même l'idéal.

Romelard Fabrice [MVP]

# avril 21, 2009 18:57

vLabz a dit :

Donc pour utiliser ces classes là il faut écrire du code qui tournera soit dans une appli "one shot", typiquement du powershell comme tu dis, ou bien une page sharepoint par exemple ?

# avril 22, 2009 14:26

Gribouillon a dit :

Par exemple... ou dans IIS 7.0 pour ce que je suis en train de faire :-)

# avril 22, 2009 15:32
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Office 365: Nettoyage des versions de List Item avant migration depuis SharePoint On Premise vers SharePoint Online par Blog Technique de Romelard Fabrice le 08-08-2017, 15:36

- Office 365: Comment supprimer des éléments de liste SharePoint Online via PowerShell par Blog Technique de Romelard Fabrice le 07-26-2017, 17:09

- Nouveau blog http://bugshunter.net par Blog de Jérémy Jeanson le 07-01-2017, 16:56

- Office 365: Script PowerShell pour assigner des droits Full Control à un groupe défini par Blog Technique de Romelard Fabrice le 04-30-2017, 09:22

- SharePoint 20XX: Script PowerShell pour exporter en CSV toutes les listes d’une ferme pour auditer le contenu avant migration par Blog Technique de Romelard Fabrice le 03-28-2017, 17:53

- Les pièges de l’installation de Visual Studio 2017 par Blog de Jérémy Jeanson le 03-24-2017, 13:05

- UWP or not UWP sur Visual Studio 2015 ? par Blog de Jérémy Jeanson le 03-08-2017, 19:12

- Désinstallation de .net Core RC1 Update 1 ou SDK de Core 1 Preview 2 par Blog de Jérémy Jeanson le 03-07-2017, 19:29

- Office 365: Ajouter un utilisateur ou groupe dans la liste des Site collection Administrator d’un site SharePoint Online via PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-24-2017, 18:52

- Office 365: Comment créer une document library qui utilise les ContentTypeHub avec PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-22-2017, 17:06