Archive

Archive for juin 2009

L’installation du SP2 écrase le fichier SPTHEMES.XML


Vous savez probablement déjà qu’il n’est pas supporté de modifier directement les fichiers de base du produit Sharepoint. Malheureusement, on doit contrevenir à cette règle si on désire ajouter un thème personnalisé.

 En effet, nous sommes obligés de modifier le fichier C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1036\SPTHEMES.XML. Pour le détail concernant la création d’un thème, vous pouvez consulter ces liens : http://sharepoint.developpez.com/faq/?page=V#34 ou http://www.asp-php.net/tutorial/asp.net/sharepoint-theme.php?page=1

 Ce qui devait arriver arriva. Nous avons installés le Service Pack 2 sur nos serveurs et notre thème personnalisé est disparu de la liste des thèmes disponibles. La solution est simple, il faut l’ajouter à nouveau dans le fichier SPTHEMES.XML sur chaque serveur de la ferme.

 Notons au passage que l’installation du Service Pack a changé la version contenu dans une ligne en commentaire du fichier SPTHEMES.XML :

 <!– _lcid= »1036″ _version= »12.0.6500″ _dal= »1″ –>

 Morale de cette histoire : Faites attention de bien tester suite à l’installation d’un Service Pack surtout si vous avez changer des fichiers de base de Sharepoint.

Catégories :Service Pack, Sharepoint, Thème, WSS Étiquettes : , ,

Présentation du SPTechCon Boston


Juste un petit mot pour vous dire que Shane Young a bien voulu partager ses présentations qu’il a donné au SPTechCon de Boston.

Vous les trouverez en suivant ce lien : http://msmvps.com/blogs/shane/archive/2009/06/29/downloads-of-my-sptechcon-boston-sessions.aspx

Mise à jour du 1 juillet 2009

Dux Raymond Sy et Mike Taylor ont aussi partager leur présentation. Vous trouverez la présentation en suivant ce lien : http://www.slideshare.net/meetdux/sharepoint-worst-practices-5-common-mistakes-to-avoid et un vidéo de la présentation en suivant celui-ci http://sp.meetdux.com/archive/2009/07/01/sharepoint-worst-practices-5-common-mistakes-to-avoid.aspx

Catégories :Conférence, Sharepoint, WSS Étiquettes : , ,

Règle : Nomenclature et emplacement des pièces personnalisées sous le répertoire 12


Ce billet est le premier d’une série concernant différentes règles de développement sous Sharepoint. Au fil du temps et des projets, on identifie des règles qui peuvent faciliter le développement et aussi l’administration de Sharepoint. Il est plus que temps de partager ces éléments avec la communauté. Par conséquent, j’ajouterai des billets de temps en temps sous la catégorie Règle de développement .

Le déploiement de Sharepoint entraîne presque inévitablement du développement maison pour étendre les fonctionnalités du produit et mieux répondre aux besoins des utilisateurs. Certains ont tendance à déployer les éléments un peu n’importe où sous le répertoire 12.

StructureBase12L’image ci-contre présente la structure de base du répertoire 12 sous lequel est placé les composantes de Sharepoint. Évidemment, on ne dépose pas d’élément à ce niveau mais par contre il est possible d’en placer dans la plupart des sous-répertoires. C’est ce que nous verrons avec les images suivantes.

 

 

 

 

 

 

 

 

StructureBase12ConfigSous le répertoire CONFIG, ce n’est pas très compliqué. C’est à cet endroit qu’on dépose les fichiers XML des commandes STSADM qu’on développe maison. 

 

 

StructureBase12Isapi

Sous le répertoire ISAPI, on dépose nos services Web développés maison. Ici, il est suggéré de créer au minimum un sous répertoire du nom de l’entreprise ou de l’organisme. Ceci à pour effet que nos services Web ne sont pas mélangés avec ceux de Sharepoint. Nous serons donc en mesure de répérer plus rapidement nos pièces.

 

 

StructureBase12Resources

Sous le répertoire Resources, c’est l’endroit où il faut déposer nos fichiers de ressources personnalisées.

 

 

 

StructureBase12Template

Enfin, le répertoire que vous utiliserez probalement le plus : TEMPLATE. Ce dernier contient plusieurs sous-répertoires qui permettent d’y placer différents éléments. On regarde cela de plus prêt immédiatement.

Sous le répertoire 1036\xml, on place les fichiers XML de nos définitions de sites réalisés avec Visual Studio.

Sous le répertoire CONTROLTEMPLATES, on place les contrôles utilisateurs qu’un designer pourra déposer sur les pages d’un site Sharepoint.

Sous le répertoire FEATURES, on place nos features réalisés encore une fois avec Visual Studio. Chaque feature possède son répertoire.

Sous le répertoire IMAGES, on place par exemple les logos de nos features.

Sous le répertoire LAYOUTS, il est suggéré de créer un répertoire propre à l’organise ou l’entreprise afin d’y déposer toutes les pièces relatives aux pages d’applications (page aspx, image, css, javascript).

Sous le répertoire SiteTemplate, on dépose les autres fichiers en relation avec nos définitions de site. Il faut créer un répertoire par définition de site.

Sous le répertoire THEMES, on dépose nos thèmes personnalisés. Encore une fois, un répertoire par thème.

     

Vous avez s’en doute notez que chaque fois que c’est possible, je préconise la création d’un sous répertoire au nom de l’entreprise. Pour les autres éléments, il faut toujours prendre soins de nommer ces derniers avec un nom significatif. Bien sûr, assurez-vous d’arrimer le tout avec vos règles de nomenclature existante lorsque c’est le cas.

Comme vous l’avez constaté, il est quand même relativement simple d’organiser les éléments afin de s’y retrouver.

Catégories :Règle de développement, Sharepoint, WSS Étiquettes : ,

STSADM Preupgradecheck sans avoir des droits suffisants dans SQL


Dans ce billet, j’aimerais portée à votre attention le fait que la commande STSADM Preupgradecheck ne réussit pas toujours à vérifier l’ensemble de ses règles. En effet, dans un environnement où le compte d’administration de Sharepoint ne possède pas de droits suffisants dans SQL Server, une règle de validation ne pourra être vérifiée.

Dans le log de la commande vous trouverez l’erreur suivante :

[SPObjectProcessor] [ERROR] [2009-06-01 13:56:58]: An unexpected error occured while processing a health analysis rule.
This rule will be skipped. The following message was generated by the error: System.Reflection.TargetInvocationException:
Une exception a été levée par la cible d'un appel. ---> System.Data.SqlClient.SqlException: CREATE DATABASE permission denied in database 'master'.
 à System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
 à System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
 à System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
 à System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
 à System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
 à System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
 à System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
 à Microsoft.SharePoint.Utilities.SqlSession.ExecuteNonQuery(SqlCommand command)
 à Microsoft.SharePoint.Administration.Health.InvalidDatabaseSchema.EnsureTempDatabase(SPContentDatabase contentDb)
 à Microsoft.SharePoint.Administration.Health.InvalidDatabaseSchema.Check()
 --- Fin de la trace de la pile d'exception interne ---
 à System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
 à System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
 à System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
 à System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
 à System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
 à Microsoft.SharePoint.StsAdmin.SPObjectProcessor.ISPHealthAnalysisRuleCheck(Object rule)
 à Microsoft.SharePoint.StsAdmin.SPObjectProcessor.ProcessObject()

Une bonne pratique serait donc de vérifier dans le log afin de vérifier si ce dernier contient des erreurs de ce type.

Vous trouverez plus d’information sur la commande STSADM Preupgradecheck dans mon billet du 1 juin dernier.

Catégories :Sharepoint, STSADM, WSS Étiquettes : , ,

STSADM : une carte interactive en Silverlight


Ce soir j’ai découvert un lien à mettre dans nos favoris. C’est une carte interactive présentant l’ensemble des commandes STSADM réalisée en Silverlight Tel que présenté dans l’image ci-dessous, on peut rechercher ou trier les commandes. C’est très intuitif.

STSADM_Silverlight

L’adresse pour accéder à ce superbe outil est la suivante : http://technet.microsoft.com/en-us/office/sharepointserver/cc948709.aspx

Merci à Dan Lewis de m’avoir fait découvrir cela.

Catégories :Sharepoint, STSADM Étiquettes : , ,

STSADM Preupgradecheck


Aujourd’hui, j’ai eu le bonheur d’exécuter pour la première fois la nouvelle commande STSADM Preupgradecheck introduite avec le SP2 de Sharepoint.

Cette commande permet de faire une vérification en plusieurs points afin de déterminer si notre ferme est prête pour passer à Sharepoint Server 2010. La syntaxe de la commande est simple :

stsadm -o preupgradecheck -[rulefiles <rule file name>] -[listrulefiles] -localonly

Le paramètre  -[rulefiles <rule file name>] permet de vérifier uniquement un sous-ensemble de règles.

Le paramètre -[listrulefiles] permet d’énumérer la liste des fichiers de règles. Ces derniers, au nombre de 2 (1 fichier pour WSS et 1 fichier pour MOSS) se trouve dans le répertoire C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\CONFIG\PreUpgradeCheck

Le paramètre -localonly permet de vérifier uniquement le serveur sur lequel la commande a été lancé et non l’ensemble de la ferme.

De mon côté, j’ai lancé la commande sans aucun paramètre supplémentaire. Il faut compter quelques minutes dépendant de la grosseur de la ferme pour obtenir le résultat. La commande produit 3 fichiers dans le répertoire C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\Logs.

Le nom des fichiers ressemble à ceci : PreUpgradeCheck-20090601-135621-592.xml. Il y a un fichier XML, un fichier HTML et un fichier log. Le fichier HTML s’affiche et le plus intéressant est à la fin complètement. Voici d’ailleurs une image ci-dessous :

Echec_preupgradecheck

Vous noterez le bilinguisme du rapport. En effet, bien que notre serveur possède un OS français et Sharepoint français, le rapport est à moitié anglais et à moitié français. À part cela, on a pas trop de problème, il faut juste migrer à Windows Server 2008, passer à 64 bits et supprimer 2 collections de sites orphelines.

Catégories :Sharepoint, STSADM Étiquettes : ,
%d blogueurs aiment cette page :