Affichage des articles dont le libellé est MOSS. Afficher tous les articles
Affichage des articles dont le libellé est MOSS. Afficher tous les articles

jeudi 30 avril 2009

Le service pack 2 de WSS 3.0 et Office SharePoint Server 2007 sont disponibles!

Voici enfin les tant attendus Service Pack 2 pour SharePoint 2007 (WSS 3.0 et Office SharePoint Server 2007). Pour récupérer ces fichiers, cela se passe ici:

WSS 3.0 Service Pack 2:
http://www.microsoft.com/downloads/details.aspx?FamilyId=79BADA82-C13F-44C1-BDC1-D0447337051B&displaylang=en

MOSS 2007 Service Pack 2:
http://www.microsoft.com/downloads/details.aspx?FamilyId=B7816D90-5FC6-4347-89B0-A80DEB27A082&displaylang=en

NB: ne pas oublier de récupérer et installer également le Service Pack 2 des modules linguistiques, et ce, pour toutes les langues déjà installées sur la plateforme! Attention également à récupérer le service pack dans la bonne version (FR, EN...) en fonction de l'existant.
Attention: il est naturellement plus qu'impératif de tester ces services packs en environnement de recette avant de les passer en production, afin de valider qu'il n'y a aucune régression aussi bien technique que fonctionnelle.

jeudi 5 février 2009

MOSS: Packages cumulatives de Décembre 2008

Comme convenu, Microsoft a sorti au bout de 2 mois les nouveaux packages cumulatives pour WSS 3 et SharePoint 2007 datés de Décembre 2008. Ils sont disponibles ici et correspondent à la version 12.0.6335:
Attention néanmoins avec l'application des mises à jours (tout patch confondus), comme on peut le voir sur le site ci-dessous, après l'application des patchs Infrastructure, la commande "stsadm -o preparetomove" est à utiliser avec précaution (voir ne plus utiliser) en cas de migration de base SharePoint vers une autre Web Application ou une autre ferme:

lundi 15 décembre 2008

ADOBE PDF iFilter x64 disponible!

Après 2 ans d'attente, ADOBE a enfin publié son propre iFilter PDF en version 64 Bits. Il est compatible avec tous les moteurs d'indexation Microsoft, notamment celui de SharePoint 2007!

Cela devrait permettre de ne plus utiliser Foxit qui est payant, et de limiter les effets de "bug" (cf post du 16 Novembre 2008).
Le lien pour le télécharger, ça se passe ici:

A tester en environnement de qualification avant d'implémenter en production!

dimanche 16 novembre 2008

MOSS 2007: Liste des patchs disponibles depuis la sortie du produit

Vous trouverez ci-dessous un tableau relativement complet de tous les patchs disponibles pour WSS 3.0 et MOSS 2007 depuis la sortie de chacun des produits. On retiendra notamment que désormais Microsoft a décidé de sortir des packages cumulatifs tous les 2 mois.


Liste des patchs MOSS 2007 & WSS 3.0

jeudi 16 octobre 2008

Problème d'indexation des fichiers PDF sous MOSS 2007

Problème:
MOSS 2007 nécessite une version spécifique de iFilter afin de pouvoir indexer les fichiers PDF. Si en version 32 Bits, il suffit d'installer la dernière version de Adobe Reader, en version 64 Bits il faut passer par un produit tiers. En l'occurence, l'un des plus connu s'appelle Foxit. Ce logiciel souffre d'un bug contraignant: à chaque mise à jour de sécurité Microsoft, les clés produits Foxit sont écrasées, et par conséquent l'indexation des fichiers PDF ne fonctionne plus.


Solution:
Elle est indiquée sur le site de l'éditeur: il suffit de réinstaller (ou réparer) l'utilitaire Foxit (source:
http://www.foxitsoftware.com/support/techsupport/showfaq_ifilter.htm#ifilter_12). Pas d'interruption de service à prévoir, mais il faut le savoir tout de même, sinon attention aux plaintes utilisateurs.

mercredi 15 octobre 2008

Impossible de finaliser l'assistant de configuration suite à la mise à jour d'une plateforme MOSS 2007 en Service Pack 1 ou ultérieur

Problème:
Suite à l'installation du Service Pack 1, ou du package Post SP1, ou bien d'un autre package sur une plateforme MOSS 2007, l'administrateur est censé exécuter l'assistant de configuration (Configuration Wizard) qui va ainsi appliquer les mises à jours aux bases de configuration et d'administration notamment. Cet assistant n'arrive pas à se terminer avec succès.
Cause:
Dans certaines configurations où la redondance des rôles est souhaitée, il est possible de voir le rôle "Central Administration" déployé sur plusieurs serveurs, au sein d'une même ferme. Cette configuration n'est pas supportée par l'assistant de configuration MOSS, si bien que si une ferme est dans ce cas, son exécution ne pourra jamais se terminer correctement.
Solution:
Deux possibilités: dans tous les cas, la résolution passe par la désactivation du rôle Central Administration sur les serveurs secondaires, afin qu'un seul serveur subiste avec ce rôle. Ensuite, une fois l'assistant de configuration exécuté avec succès, si le besoin initial est justifié, il reste toujours possible de réactiver ce rôle sur les serveurs secondaires, ou bien si cela n'est pas impératif, de laisser la ferme MOSS avec un seul serveur avec le rôle Central Admin.

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.