jeudi 18 septembre 2008

Impossible d'afficher une librairie de documents en mode "Vue Explorer" (Explorer View)

Dans certains cas très spécifiques, il est impossible d'afficher le contenu d'une librairie de documents dans SharePoint 2007 en vue "Mode Explorateur".


Cela est dû à un problème de communication WebDav entre le poste client et le serveur MOSS. Pour corriger ce problème, Microsoft a publié un hotfix de mise à jour du poste client. Celui-ci est disponible ici:



MOSS 2007 et les notifications d'ajout d'un utilisateur à un groupe SharePoint

Dans la continuité de mon précédent post, les URLs de notifications posent également problème lors de l'ajout d'un utilisateur à un groupe SharePoint.
En effet, lorsqu'une personne ayant les droits suffisants ajoute un utilisateur à un groupe d'accès SharePoint (pré-existant ou crée), une option est disponible en bas de page: "Envoyer un message d'accueil aux nouveaux utilisateurs". Lorsque cette option est cochée, un message de notification est envoyé à l'utilisateur (ou aux utilisateurs) ajouté(s). Ce message contient l'URL d'accès au site.
.
La problématique:
Pour bien comprendre, nous allons prendre le cas extrême:
  1. nous avons un site SharePoint crée sur la Web App http://mawebapp:8080/monsite.
  2. nous avons réalisé 4 extensions d'URL pour 3 types d'accès différents: Intranet (http://url.intranet/), Internet (http://url.internet/), Extranet (http://url.extranet/).

Nous avons donc 4 URLs différentes disponibles pour accéder au site, suivant le type d'utilisateur correspondant (Administrateur, Intranet, Internet et Extranet). SharePoint 2007 reprend l'URL en cours d'utilisation pour notifier les utilisateurs ajoutés au site. En conséquence, si j'ajoute mes utilisateurs depuis l'URL de ma Web App, c'est l'URL http://mawebapp:8080/monsite qui sera envoyée aux utilisateurs, si je passe par l'URL Intranet ce sera l'URL http://url.intranet/monsite, etc...
La question qui se pose donc est: peut-on modifier ces messages par défaut envoyés aux utilisateurs ?
.
Résultats:
Malheureusement non. Le blog suivant (en anglais) explique relativement bien pourquoi cela n'est pas possible: http://blogs.msdn.com/anolan/archive/2008/01/07/is-it-possible-to-modify-sharepoint-email-notifications.aspx. En d'autres termes, il n'est pas possible de modifier les templates de message (i.e.: Deadweb.xml) en espérant qu'il prenne en compte les bonnes URLs.
.
Solutions disponibles:
  1. Comme indiqué sur le blog cité plus haut, s'il n'est pas possible de modifier le texte et les URLs utilisées, il reste cependant possible de modifier la "boite de texte" disponible sur cette même page, afin d'envoyer un message par défaut. Cette solution se trouve rapidement limitée lorsque l'on a plusieurs Web App et donc plusieurs extensions. De plus si les templates MOSS sont modifiés, cela peut être une raison valable pour Microsoft de refuser d'offrir son support en cas de problème.
  2. Une autre possibilité, peut être la meilleure à ce jour: redévelopper la page ASPx d'ajout d'un utilisateur à un site SharePoint, afin de reprendre l'existant mais également offrir d'autres possibilités, comme rajouter une liste déroulante contenant les URLs disponibles sur la Web App en cours d'utilisation.
  3. Dernière possibilité, la moins coûteuse: éduquer les administrateurs et utilisateurs pour soit ne pas envoyer le message automatique mais en envoyer un (via un client de messagerie) personnalisé, ou bien utiliser la boîte de texte pour indiquer quelle est la vraie URL à utiliser en fonction des utilisateurs ajoutés.

MOSS 2007 et les notifications administratives par mail

Vous avez réussi à implémenter une ferme MOSS 2007, vous possédez désormais plusieurs sites en production avec plusieurs utilisateurs, et puis soudain vous décidez de mettre en oeuvre les alertes administratives, telles que:

- Les alertes de Quota (Quota Alerts): notification envoyée aux administrateurs de la collection de site lorsque le niveau d'alerte est atteint ou bien que le Quota limite lui même est atteint.
- La confirmation d'utilisation d'un site (avec ou sans suppression automatique: Site Usage Confirmation): tous les 90 jours (par défaut) SharePoint envoie aux administrateurs (Primaire et Secondaire) de la collection de Sites, un message demandant si le site correspondant est toujours utilisé.

Pour chacun de ces messages, un lien vers le site est inclus, et c'est là que le problème survient:
- En général, lorsque l'on crée une application web (Web App), l'URL d'accès par défaut est sous la forme http://nomduserveur:port/nomdusite.
- Par la suite, il est fréquent de voir la création d'extension d'URL (Intranet, Internet...) sous la forme: http://masociete.corp.local/nomdusite, afin d'avoir une URL plus réaliste, proche des utilisateurs et plus facile à utiliser. Parfois même cette URL peut être configurée en mode répartition de charge (logique ou matérielle), tandis que l'URL de la Web App n'est accessible que sur un réseau isolé administratif en direct.

Le problème est donc que pour toutes ces notifications administratives envoyées à l'utilisateur, ce n'est pas l'URL "User friendly", c'est-à-dire http://masociete.corp.local/nomdusite, mais bien l'URL de la Web App qui est envoyée:
- sur une ferme qui n'implémente pas l'isolation des réseaux (un réseau accès utilisateur, et un réseau accès administratif), cela peut s'avérer gênant mais non bloquant dans le sens où l'utilisateur aura tout de même accès au site mais via une adresse inconnue qui peut parfois prêter à confusion.
- sur une ferme qui implémente en revanche l'isolation des accès, alors là systématiquement les utilisateurs n'accéderont pas aux sites.
- si en plus de la confirmation d'utilisation, le paramètre de suppression automatique est activé (cad si l'utilisateur ne confirme pas l'utilisation du site, celui ci peut être supprimé de façon automatique), alors là de gros problème peuvent survenir.

La cause de tout cela:
Pour les notifications administratives, SharePoint utilise l'URL de la zone Defaut, c'est à dire l'URL de l'application Web par défaut. Il n'existe aucune option de la console Central Administration, ni de l'outil en ligne de commande stsadm qui permette de changer cela. Cette fonctionnalité est ce que l'on appelle "by design".

Solution:
La solution de contournement est relativement simple, et se situe au niveau des "Alternates Access Mapping", de l'onglet "Opérations" de la console Central Administration. Une fois l'application web créée, les extensions d'URL créées, alors il suffit d'aller dans le menu des mappings des accès alternatifs et d'inverser les URLs "Defaut" et "Intranet" (par exemple). Cela permet à SharePoint d'envoyer l'URL désirée à l'utilisateur qui ne se verra plus perturbé par une URL inconnue, voir inaccessible.

Pré-requis:
Il est impératif que le mode d'authentification de l'extension choisie soit identique à celle de la zone Defaut, par exemple: les deux sont en modes Windows Intégré, sinon il faudra également modifier les fournisseurs d'authentification (Authentication Providers).

Limite:
Si l'administrateur primaire accède au site via une extension de type Intranet, et que l'administrateur secondaire accède via un autre type d'accès, et donc une autre URL, il ne sera pas possible de notifier chacun par l'URL qui lui correspond (cela est rare mais pas impossible comme situation).

Status:
Cette fonctionnalité est by design dans MOSS 2007, y compris SP1 et POST SP1.

Bienvenue!

Bienvenue sur mon blog :)

Etant consultant en infrastructure Microsoft, il m'arrive de rencontrer certains cas de figure où même Google ne peut aider ;-)
Ce blog a pour but de rescencer quelques informations que je juge importantes et qui pourront peut-être (je l'espère) en aider plus d'un!
Bonne lecture.