Archive

Archive for décembre 2009

Les limites reliées à la mise à jour d’une solution


La mise à jour d’une solution à l’aide de la commande « stsadm-o upgradesolution » comporte certaines limitations.

Afin de bien comprendre les limitations précisées un peu plus loin, il est important d’expliquer ce qui se passe vraiment lors de l’exécution de la commande. En fait, c’est bien simple, Sharepoint supprime les fichiers contenus dans la version précédente et installe les fichiers contenus dans la nouvelle version de la solution. Aucune autre opération ne sera effectuée sauf le recyclage du ou des applications pools impliqués dans l’opération.

Une fois ceci bien compris, il est maintenant facile de comprendre qu’il ne faut pas effectuer les opérations suivantes sur la solution :

  • Ajout ou suppression d’un feature
  • Changement au niveau de l’assembly qui est utilisé comme récepteur d’événement (event receiver)
  • Modification, ajout ou suppression d’une propriété d’un feature ou changement au niveau de l’identifiant d’un feature
  • Ajout ou suppression d’élément d’un feature (Element.xml)

Si jamais vous rencontrez une des situations énumérées ci-dessus, il sera nécessaire de faire une rétractation complète de solution précédente et effectuer un déploiement de la nouvelle solution.

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

Solution : Kerberos et BlobCache provoque une fermeture inexpliquée de la connexion TCP


Avec la sortie du Cumulative Update de décembre pour WSS et MOSS vient le correctif pour le problème de fermeture de la connexion TCP dont j’avais parlé le 5 février dernier.

En effet selon le KB97023, le correctif est inclus. Voici un bref extrait en anglais de la description du problème provenant de l’article :  

You enable BLOB Caching on an Office SharePoint Server 2007 site. Then, you use NTLM authentication on this SharePoint site. When a client sends a GET response with the If-None-Match header, Office SharePoint Server 2007 responds with an « HTTP 304 » response and a « Connection: Close » header. This causes two more unnecessary requests for NTLM authentication.

Ça risque de prendre quelques temps avant que je puisse faire les essais mais j’ai d’excellentes raisons de croire que la problématique sera résolue.

Catégories :Sharepoint 2007 Étiquettes : ,

Erreur « HTTP/1.1 404 Connection: close » lors de la création de Mon Site


Cette après-midi, je faisais des essais pour la création de Mon Site sous Sharepoint 2007. J’ai donc supprimé Mon Site afin de pouvoir le créer à nouveau. À partir de ce moment, j’obtenais toujours l’erreur suivante lors de ma tentative de recréation de Mon Site :

HTTP/1.1 404 Connection: close Date: Tue, 15 Dec 2009 20:15:59 GMT Server: Microsoft-IIS/6.0 MicrosoftSharePointTeamServices: 12.0.0.6219 X-Powered-By: ASP.NET

Pas d’erreur dans le journal des événements de Windows et pas d’erreur dans le log de Sharepoint. J’ai aussi vérifié que j’étais authorisé à créer un Mon Site dans le SSP. Tout me semble correct partout et pour les utilisateurs qui possédait déjà un MonSite, c’était fonctionnel.

Il fallait donc que ce soit un élément de mon profil qui était corrompu. Je suis donc aller voir le détail de mon profil dans le SSP en utilisant l’item de menu « Propriétés et profil utilisateur ».

Quel ne fût pas ma surprise de constater que le champ « Site personnel » contenait encore une valeur même site Mon Site avait été supprimé.

J’ai retiré la valeur du champ, sauvegardé mon profil et par la suite j’ai été en mesure de créer à nouveau Mon Site.

Catégories :Sharepoint 2007 Étiquettes :

Messages d’erreurs lors de l’exécution d’une commande STSADM


Est-ce qu’il vous est déjà arrivé d’avoir l’un des messages suivants lorsque vous tentez d’exécuter une commande STSADM :

  • Access is denied.
  • Cannot connect to the configuration database.
  • Login failed for user ‘(null)’. Reason: Not associated with a trusted SQL Server connection. (Error code: 18452).

Pas plus tard que la semaine dernière, c’est arrivé lorsque je préparais un travail planifié de backup d’une collection de sites Sharepoint. Le compte de service qu’on m’avait fournit et que j’ai utilisé pour configurer le travail planifié ne possédait tout simplement pas les permissions requises pour effectuer l’opération.

Il faut savoir que pour effectuer la plupart des commandes STSADM, il faut posséder les permissions suivantes :

  • Être administrateur local du serveur sur lequel on exécute la commande;
  • Être administrateur de la ferme Sharepoint (farm administrator);

En plus, il faut aussi posséder les bonnes permissions dans SQL Server. En effet, puisque la commande STSADM s’exécute sous l’identité du compte avec lequel on la lance, il est requis que ce compte soit reconnu par SQL Server.

L’article  KB896148 présente deux méthodes pour attribuer les privilèges dans SQL Server :

  1. Placer le compte membre du groupe Administrateur local du serveur SQL;
  2. Donner au compte les rôle « Administrateur de la sécurité » et « Créateurs de bases de données » dans SQL Server et les rôles « public » et « db_owner » sur chaque banque SQL utilisées par Sharepoint.

Il va s’en dire que dans un organisme où les banques de données sont créées par l’administrateur SQL, seulement les rôles « public » et « db_owner » de chaque banque SQL utilisées par Sharepoint seront attribués au compte.

Pour en revenir à mon travail planifié, c’était justement les permissions dans SQL Server qui n’étaient pas adéquates.

J’espère ainsi vous éviter de précieuses minutes de recherche.

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