Agora

Windows Vista Service Pack 2 disponible en version finale!

2009-05-05T12:24:00.003+02:00

C'est le printemps, et Microsoft nous offre une panoplie de "release" finale: après la RC de Windows 7, le SP2 de Office client/Server, voici le Service Pack 2 de Windows Vista et Windows Server 2008.

Ces services packs sont pour l'instant disponible sur la MSDN, et devrait prochainement être disponible sur Windows Update.

Windows 7 Release Candidate disponible en téléchargement et en français!

2009-05-05T12:18:00.002+02:00

Avec un peu de retard, la tant attendue version RC de Windows 7 est désormais disponible sur les différents sites de Microsoft (MSDN, Connect...).

Je vous conseille vivement de la télécharger et de l'installer afin de vous faire une idée précise du prochain Windows qui devrait débarquer fin 2009/Début 2010 et qui s'annonce très prometteur :)

http://www.microsoft.com/presspass/press/2009/apr09/04-30Windows7RCPR.mspx

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

2009-04-30T10:32:00.005+02:00

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.

SCOM et les clusters sous Windows 2008 Server

2009-02-05T11:48:00.003+01:00

Bon à savoir: lors du déploiement des agents SCOM sur un cluster Windows 2008 Server (avec le Management Pack correspondant), il ne faut pas oublier d'activer le mode proxy sur les noeuds du cluster afin de voir apparaître les ressources virtuelles dans la console SCOM, sinon quoi seuls les noeuds physiques seront visibles.

MOSS: Packages cumulatives de Décembre 2008

2009-02-05T09:45:00.004+01:00

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:

MOSS: http://support.microsoft.com/kb/960011
WSS: http://support.microsoft.com/kb/960010

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:

http://blogs.msdn.com/toddca/archive/2009/01/30/preparetomove-away-from-running-this-command.aspx (en anglais).

Microsoft SQL 2005 Service Pack 3 disponible!

2008-12-16T16:38:00.004+01:00

C'est Noël avant l'heure. Microsoft vient de publier son Service Pack 3 pour SQL Server 2005, en version 32bits et 64bits.

Si initialement il était conseillé d'appliquer le dernier Service Pack (le SP2) avec le dernier Cumulative Update (le dernier en date disponible étaient les 10 et 11), il est désormais recommandé d'appliquer ce fameux SP3.

Attention néanmoins à bien le valider en environnement de tests avant de l'appliquer en Production, afin de vérifier qu'il n'y a pas d'effets de bords.

Pour télécharger cette mise à jour, ça se passe ici:

http://www.microsoft.com/downloads/details.aspx?FamilyID=ae7387c3-348c-4faa-8ae5-949fdfbe59c4&displaylang=en

ADOBE PDF iFilter x64 disponible!

2008-12-15T16:34:00.005+01:00

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:

http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025

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

Mieux comprendre les profils utilisateurs sous SharePoint

2008-12-04T23:13:00.006+01:00

Ayant récemment cherché des informations précises pour mieux comprendre le fonctionnement des profils utilisateurs dans SharePoint, il se trouve que j'ai eu du mal à trouver les réponses désirées. Voici un résumé des éléments essentiels du fonctionnement des profils utilisateurs dans une ferme SharePoint 2007.

Tout d'abord: oui il est possible d'installer et configurer une ferme SharePoint sans avoir à utiliser les profils utilisateurs internes. Néanmoins, cela limitera les fonctionnalités disponibles au sein de cette ferme, par exemple: les audiences par utilisateurs ne sont pas possibles, et il faut alors les utiliser via des groupes utilisateurs SharePoint, ou bien les données de profils utilisateurs ne sont pas remplies, etc...

Il existe deux façons d'avoir des profils utilisateurs: les créer manuellement, ou bien les importer (ponctuellement ou de façon planifiée) depuis un annuaire externe (le plus couramment utilisé étant l'annuaire Microsoft Active Directory, mais il est également possible d'utiliser des BDC ou des annuaires LDAP tierces). Toutes ces opérations se déroulent dans le portail administratif des services partagés (SharedServices Administration page), accessible depuis la console d'administration SharePoint.

Maintenant, comment sont gérées les informations utilisateurs:

Source externe: les informations requises doivent être renseignées au niveau de l'annuaire externe (ie: adresse de messagerie, numéro de téléphone, département, nom, prénom...), soit manuellement par les adminstrateurs de l'annuaire, soit automatiquement depuis une application tierce de ressources humaines ou autre annuaire synchronisé. Ces informations correspondent à des attributs dans cet annuaire, ces attribus devant de préférence respecter les normes LDAP.
Source interne: au niveau de la page d'administration des SharedServices, dans la section des profils utilisateurs, on configure des connecteurs pour importer les profils depuis une source externe (ie: connecteur Active Directory), avec une planification de synchronisation complète ou incrémentielle, selon les besoins. Pour que cette synchronisation soit efficace, il est possible de vérifier et le cas échéant modifier la configuration de "mapping" des attributs de l'annuaire externe avec les attributs des profiles utilisateurs SharePoint (ie: on peut spécifier que l'attribut "service" de l'annuaire externe correspond à l'attribut "département" dans la ferme SharePoint). Si un attribut "interne" n'est pas relié à un attribut externe, il ne sera pas rempli lors de la synchronisation avec la source externe, même si celui-ci y a un équivalent et qu'il est rempli. De la même façon, si un attribut est défini, mais que en interne cet attribut est modifié manuellement (par l'utilisateur s'il a les droits, ou par un administrateur), alors cet attribut sera écrasé lors de la prochaine synchronisation complète des profils. Autre point important: il est également possible de définir si un attribut doit se répliquer avec tous ceux des collections de site, le rendant ainsi non modifiable par l'utilisateur, ou si au contraire il ne doit pas se répliquer, permettant ainsi si besoin, de le rendre modifiable par l'utilisateur.
Source par collection de site: il existe en effet une troisième source, ou plus précisément, la cible. Lorsqu'un utilisateur est ajouté à un site SharePoint, au niveau de la ferme MOSS il est déclaré comme "membre" mais pas comme "actif". Par conséquent, les informations utilisateurs au niveau du site ne sont pas renseignées. Dès que l'utilisateur effectue une opération au sein du site (ie: ajout ou suppression de document par exemple), il devient alors actif au niveau de la ferme, et par conséquent ses informations utilisateurs sont importées au niveau de la collection de site et sont stockées dans la table UserInfo de la base de contenu SQL qui contient la collection de site. Cette table d'information qui héberge les informations utilisateurs au niveau site est mise à jour régulièrement par deux "jobs" SharePoint (Profile Synchronization et Quick Profile Synchronization) par défaut toutes les heures. Attention si un paramètre est configuré comme "non réplicable" et donc a été modifié ultérieurement par un utilisateur, ces modifications ne seront pas prises en compte sur tous les sites, si bien que des écarts peuvent alors survenir et nécessiter des opérations manuelles pour forcer les mises à jour.

Attention: si la base de profils utilisateurs dans le SharedServices peut être "nettoyée" via des commandes, les tables internes aux collections de sites ne peuvent pas l'être à ce jour: ainsi une table UserInfo peut voir sa taille grandir continuellement sans possibilité de la purger.

SharePoint et la configuration en ligne de commande (stsadm)

2008-12-04T23:03:00.007+01:00

STSADM.exe est l'outil natif de SharePoint qui permet d'effectuer de multiple opérations de configuration et de déploiement au sein d'une ferme SharePoint 2007, et ce, en ligne de commande.

Si nativement cet outil permet de faire beaucoup de chose, il ne permet pas d'aller jusqu'au bout de la configuration d'une ferme SharePoint (ie: aller jusqu'à la création des applications web et de leur extension d'URL). Un MVP Microsoft SharePoint nommé Gary Lapointe a développé un "addon" à cet outil qui permet de rajouter une panoplie de switch relativement utile pour combler le manque de la version native. On notera spécifiquement les switchs gl-createwebapp et gl-extendwebapp qui permettent respectivement de créer une application web puis de l'étendre selon les zones requises (extension d'URL).

Pour plus d'information, et notamment télécharger cet addon (gratuit!), il suffit d'aller sur le blog (en anglais) de Gary Lapointe:
http://stsadm.blogspot.com/

Vivement recommandé! :-)

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

2008-11-16T18:34:00.004+01:00

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

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

2008-10-16T14:03:00.003+02:00

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.

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

2008-10-15T21:02:00.004+02:00

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.

Windows Server 2008 et SQL Server 2005 en Cluster

2008-10-15T20:46:00.005+02:00

Problème:
Lors de l'installation de SQL Server 2005 sur un cluster Windows Server 2008 Failover Cluster, un message d'erreur apparaît indiquant que tous les services n'ont pu être démarrés.

Cause:
Ce problème est lié au fait que SQL Server 2005 requiert au minimum son Service Pack 2 afin de fonctionner correctement sous Windows Server 2008. Le service concerné est SQL Server Full Text Search.

Solution:
Il suffit de terminer l'installation de SQL Server, puis d'installer le Service Pack 2 de SQL Server 2005, et enfin de démarrer manuellement le service Full Text Search (ou bien de redémarrer le noeud du cluster) pour que le problème soit résolu.

Note:
- Il n'existe pas à ce jour de source d'installation de SQL Server 2005 qui inclus le Service Pack 2.
- En date du mois d'Octobre 2008, le package "SQL Cumulative Update 10" est déjà disponible, et s'installe après le Service Pack 2 de SQL Server 2005.

Problème de connexion à distance à Windows Server 2008

2008-10-15T20:39:00.004+02:00

Problème:
Une fois Windows Server 2008 (standard ou ultérieur) installé, et la fonction d'accès à distance activée (Remote Desktop), il reste impossible de se connecter au serveur en utilisant le client Bureau à distance.

Parfois même, un message d'erreur indiquant que "le certificat est invalide ou a expiré" peut apparaître.

Solution:
Il est possible de voir sur la plupart des blogs de la toile, la solution toute simple qui consiste à contrôler la date et l'heure du système: en effet, si la date et l'heure du client sont différents, ce type de problème peut survenir. Mais parfois cela ne suffit pas. Il est possible que pour certains serveurs, le problème soit isolé au niveau de la version du BIOS du serveur lui même. En effet, il suffit parfois d'aller voir sur le site du constructeur si une mise à jour du BIOS du serveur n'est pas disponible, et le cas échéant de l'appliquer aux serveurs correspondants.

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

2008-09-18T22:00:00.003+02:00

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:

http://www.microsoft.com/downloads/details.aspx?familyid=17C36612-632E-4C04-9382-987622ED1D64&displaylang=en

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

2008-09-18T10:24:00.020+02:00

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:

nous avons un site SharePoint crée sur la Web App http://mawebapp:8080/monsite.
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:

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.
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.
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

2008-09-18T10:24:00.016+02:00

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!

2008-09-18T10:24:00.014+02:00

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.