Archive

Archive for avril 2009

Bonne pratique concernant le nom du serveur SQL pour une ferme Sharepoint


Bonne pratique

Si votre infrastructure SQL comporte des instances nommées (nom_serveur\nom_instance), il ne faut pas les utiliser avec Sharepoint. Utiliser à la place un alias.

Explication

L’automne dernier, j’ai été impliqué dans le changement de serveur SQL d’une ferme Sharepoint qui utilisait une instance nommée comme nom de serveur SQL hébergeant les banques de données de Sharepoint. Après plusieurs tentatives infructueuses avec la procédure de migration de Microsoft, et quelques étapes supplémentaires nous ne sommes pas parvenu à venir à migrer complètement la ferme. À l’époque, nous avions fait des recherches directement dans la banque de configuration SQL pour se rendre compte que l’instance nommée n’était pas changée par la commande stsadm renameserver. Nous avions  donc décidé de reconstruire la ferme avec un alias.

Le temps nous a donné raison car le 30 mars dernier, Microsoft modifiait la procédure pour annoncer que la commande stsadm renameserver, ne prennait pas en charge un nom de serveur avec une instance nommée (nom_serveur\nom_instance).

European Best Practices Sharepoint Conference – Les présentations


Plusieurs jours ont passés depuis la fin de la conférence européenne et quelques présentateurs ont publiés leurs présentations sur internet. Voici la liste que j’ai pu recueillir jusqu’à maintenant :

Joel Oleson : http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=206

Agnes Molnar : http://dotneteers.net/blogs/aghy/archive/2009/04/14/spbpuk-the-best-ever.aspx

Andrew Connell : http://www.andrewconnell.com/blog/articles/Speaking.aspx#PreviousEngagements

Chris O’brien : http://www.sharepointnutsandbolts.com/2009/04/slide-deck-from-my-deployment-talk-at.html

Mike Watson : http://www.sharepointmadscientist.com/Lists/Posts/Post.aspx?ID=33

Catégories :Best Practice, Sharepoint Étiquettes : ,

Sortie annoncée pour le SP2 de Office 2007


Microsoft annonce aujourd’hui la sortie du Service Pack 2 de Office 2007 pour le 28 avril prochain.  Il y a des éléments pour les produits clients de la suite office (Word, Excel, …) et d’autres pour Microsoft Office System Server.

Plus de détail à l’adresse suivante : http://blogs.technet.com/office_sustained_engineering/archive/2009/04/16/service-pack-2-for-the-2007-microsoft-office-system-due-to-ship-april-28th.aspx

Catégories :Service Pack, Sharepoint Étiquettes : ,

Gestion du Web.config – Bonnes pratiques et pièges à retenir


En guise de conclusion à cette série de billet concernant la gestion du Web.config, voici quelques bonnes pratiques et pièges à éviter concernant la gestion du Web.config.

Bonnes pratiques

  1. Ne pas modifier le contenu du Web.config manuellement à moins d’y être forcé par une situation particulière (voir la partie 6);
  2. Pour ajouter un élément au Web.config de l’ensemble des applications Web, utilisez la technique présentée à la partie 2;
  3. Pour ajouter un élément au Web.config d’un seul application Webm utilisez la technique présentée à la partie 3;
  4. Pour ajouter un « safe control » ou une règle CAS, utiliser le manifest.xml de la solution Sharepoint tel que présentée à la partie 4;
  5. Pour les « AppSetting », dans la mesure du possible, utiliser une seule manière normalisée pour l’ensemble des paramètres des applications Web;

Pièges à retenir

L’utilisation de la classe SPWebConfigModification est sujet à quelques problèmes résumés ci-dessous et très bien expliqués dans l’article de Reza Alirezaei :

  1. La documentation est faible;
  2. Lorsqu’on applique un changement à l’aide de SPWebConfigModification, le changement s’applique sur l’ensemble des zones de l’application Web, Lorsqu’on retire le changement, ce dernier est retiré seulement sur la zone Defaut et il faut retirer les éléments à la main sur les autres zones;
  3. Il n’est pas possible de faire un changement sur une seule zone;
  4. Si on utilise EnsureSection, les changements ne seront pas retirés;
  5. SPWebConfigModification ne peut pas être utilisé pour ajouter certains éléments tel que : assemblyBinding;
  6. L’instruction
    SPFarm.Local.Services.GetValue<SPWebService>().ApplyWebConfigModifications(); ne fonctionne pas, il faut plutôt utilisé l’instruction webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

L’utilisation de la commande stsadm -o copyappbincontent effacera les modifications manuelles apportées au Web.config.

Gestion du Web.config – partie 6


Dans les parties précédentes, je vous ai présenté différentes techniques pour modifier différents éléments du Web.config. Le point commun de ces techniques : le Web.config n’est jamais modifié à la main par un administrateur.

Malheureusement, dans certaines situations il n’est pas possible de faire autrement que d’apporter une modification manuelle au Web.config.

Supposons un site Web sous Sharepoint visible sur internet (Gestion de contenu Web). Ce site se matérialise dans Sharepoint par un application Web comportant 2 zones. La première (Défaut) sera utilisée pour l’administration de l’application Web. Cette zone est normalement accessible en mode authentifié (NTLM ou Kerberos par exemple). La seconde zone (Internet) sera accessible par l’internaute qui normalement est anonyme ou en mode « Forms ». Chaque zone est en fait un site Web différent dans IIS et possède son propre Web.config.

L’extrait suivant présente une partie du Web.config de la zone par défaut :

...
    <authentication mode="Windows" />
    <identity impersonate="true" />
    <authorization>
      <allow users="*" />
    </authorization>
...

Le second extrait présente une partie du Web.config de la zone internet :

...
    <authentication mode="Forms">
      <forms name=".ASPXAUTH" timeout="5" loginUrl="/GererAuthentification/FormulaireAuthentification.aspx" protection="All" slidingExpiration="true" />
    </authentication>
    <identity impersonate="false" />
    <authorization>
      <allow users="*" />
    </authorization>
...

Il n’est pas possible d’utiliser les techniques présentées dans les parties 2 et 3 car les modifications s’appliqueraient aux 2 zones. On doit donc se rabattre sur la modification manuelle. Il serait intéressant que Microsoft apporte des améliorations à la classe SPWebConfigModification dans un prochain service pack ou dans la prochaine version du produit pour répondre à cette situation.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.config – partie 5


Cette partie présente différentes réflexions concernant la paramètre de type « AppSetting ». À ma connaissance, pour ce qui est de ce type d’élement, on a le choix des solutions. Dépendant des circonstances, vous serez donc tenter de choisir entre les techniques présentées dans les billets précédents.

Il serait donc possible d’ajouter un « AppSetting » globalement à l’ensemble des applications Web au moyen de la technique présentée dans la partie 2. Par la suite, ajouter un autre « AppSetting » spécifique à un application Web au moyen de la technique présentée dans la partie 3. Par la suite, d’autres features pourraient aussi ajouter d’autres « AppSetting » au Web.config au gré de leurs activation. Vous voyez que ça risque de devenir rapidement un problème. 

Une manière unique de procéder serait préférable. Pour ce faire, je vous recommande de jeter un coup d’oeil sur le Sharepoint Config Store publié sur CodePlex par Chris O’brien.

Sur certains projets, j’ai vu des systèmes de gestions de paramètres corporatif. Ce genre de système s’applique à l’ensemble des applications de l’entreprise. Lorsque placé dans une situtation semblable, c’est évidemment une bonne idée d’utiliser le système en place car cela comporte de nombreux avantages pour le projet et l’organisation.

Ce n’est ni blanc, ni noir pour les éléments « AppSetting » et encore une fois Sharepoint nous offre plusieurs façons différentes pour arriver à notre fin. Une bonne réflexion s’impose lors des travaux d’implantation du produit pour définir les façons de faire de l’organisation.

Ne vous gêner surtout pas pour commenter si vous avez des éléments intéressants à ajouter. Je serai le premier intéressé à les lire et la communauté aussi par la suite.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,

Gestion du Web.config – partie 4


Dans cette partie, je vous présente comment enregistrer un assembly en tant que « safe control » dans le Web.Config.

Certains parlent d’ajouter manuellement les lignes nécessaires dans le Web.Config. D’autres parlent d’utiliser SpWebConfigModification tel que discuter dans la partie 3 de cette série d’article. Ces deux propositions feront le travail mais nécessitent plus d’efforts que la technique que je vous présente ici.

La meilleure façon d’enregistrer un assembly en tant que que « safe control » dans le Web.Config est d’inscrire les instructions nécessaires dans le fichier manifest.xml de la solution Sharepoint (.wsp) qui sera utilisée pour déployer votre assembly.

Voici un exemple très simple d’un manifest.xml qui ne fait que déployer un assembly dans l’application Web et enregistrer ce dernier en tant que « safe control ».

<Solution SolutionId="{d718f72f-567f-4b15-bed4-140b18daf58f}" xmlns="http://schemas.microsoft.com/sharepoint/">
	<Assemblies>
		<Assembly DeploymentTarget="WebApplication" Location="nom_assembly.dll">
			<SafeControls>
				<SafeControl Assembly="nom_assembly, Version=1.0.0.0, Culture=neutral,
				PublicKeyToken=151c9ce4fd83003a" namespace="nom_du_namespace" TypeName="*" Safe="True" />
			</SafeControls>
		</Assembly>
	</Assemblies>
</Solution>

 La documentation relative au fichier manifeste est disponible à l’adresse suivante : http://msdn.microsoft.com/fr-ca/library/ms442108.aspx. La documentation relative au solution Sharepoint (wsp) est disponible à l’adresse suivante : http://msdn.microsoft.com/fr-ca/library/ms413687.aspx.

Catégories :Sharepoint, Web.Config, WSS Étiquettes : , ,
%d blogueurs aiment cette page :