PI Services

L’administration, l’exploitation ou l’exécution de toutes les tâches relatives à SharePoint peuvent être réalisées à partir de différents outils selon la version de SharePoint déployée sur la plateforme :

- La console d’administration centrale

- L’outil stsadm.exe

- L’outil SharePoint 2010 Management Shell (disponible depuis la version SharePoint 2010)

Plateformes MOSS 2007

1. Console d’administration centrale

Cette console est simple puisque elle offre l’aspect visuel des actions.

L’accès à la console d’administration centrale se fait à partir du chemin suivant :

All Programs-> Microsoft Office Server -> SharePoint 3.0 Central Administration

Néanmoins plusieurs actions sont indisponibles à partir de cette console. C’est pour cette raison que Microsoft a mis à disposition l’outil de ligne de commande: stsadm.exe

2. Stsadm.exe

Cet outil est disponible en suivant le chemin suivant : C:\Programs files\Common Files\Microsoft shared\web server extension\12\BIN

L’exécution de cette commande se fait à partir d’une fenêtre cmd ou powershell.exe en se plaçant dans le répertoire C:\Programs files\Common Files\Microsoft shared\web server extension\12\BIN.

Il existe 182 commandes possibles avec l’outil stsadm.exe

Les tâches réalisées à partir de stsadm doivent être exécutées avec le compte administrateur local du serveur, autrement, le résultat d’exécution retourne une erreur « Accès refusé ».

L’avantage de cet outil réside dans le fait de pouvoir programmer l’exécution des actions en utilisant les tâches planifiées du serveur.

Par exemple la planification d’une sauvegarde :

- Réalisation des scripts contenant la commande stsadm –o backup

Il est possible utiliser l’outil de scripting Powershell.exe. Dans ce script, le chemin vers la commande stsadm.exe doit être renseigné.

- Création d’une tâche planifiée qui permet de lancer le script crée.

Important: cocher la case « Run with highest privileges ».

Cet outil de ligne de commande reste tout de même limité par rapport à l’outil SharePoint 2010 Management Shell disponible depuis la version SharePoint 2010.

Plateforme SharePoint 2010

1. Console d’administration Centrale

Cette console est accessible à partir de : Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Central Administration

La console d’administration de SharePoint 2010 est plus ergonomique que la console d’administration de MOSS 2007.

Cette dernière offre plus d’actions à réaliser en mode graphique.

Mais reste néanmoins moins riche que l’outil de ligne de commande SharePoint 2010 Management Shell.

2. Stsadm.exe : l’utilisation de cet outil reste possible mais est déconseillée.

Cet outil est accessible à partir de C:\Program Files\Common Files\Microsoft shared\web server extensions\14\BIN

Cet outil doit être exécuté à partir d’un serveur SharePoint

3. SharePoint 2010 Management Shell

Cet outil se trouve dans : Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell.

Cette console est une console personnalisée dédiée à SharePoint et différente de la console Windows PowerShell par défaut qui au moment de son exécution charge le script Sharepoint.ps1 permettant d’utiliser la console PowerShell avec les cmdlets propres à SharePoint

Il existe plus de 600 Cmdlets propre à SharePoint.

Remarque: Windows PowerShell 2.0 est requis.

4. Powershell.exe

Il est possible d’utiliser l’outil Powershell.exe pour exécuter les cmdlets SharePoint, pour cela il faut obligatoirement :

Ajouter le composant « Microsoft.SharePoint.PowerShell » en procédant comme suit :

Add-PSSnapin Microsoft.SharePoint.PowerShell

Il est bien evidement possible de planifier l’exécution des cmdlets powershell par tâche planifiée

Remarque : Que ce soit l’utilisation de la console SharePoint 2010 Management Shell ou la console PowerShell, il faut respecter la configuration minimale requise pour exécuter les cmdlets SharePoint :

- Etre membre du rôle SharePoint_Shell_Access ou du groupe local WSS_Admin_WPG

Sinon utiliser la cmdlets suivante « Add-SPShellAdmin » qui permet :

- d’ajouter l’utilisateur au groupe WSS_Admin_WPG dans tous les serveurs web frontaux

-D’ajouter l’utilisateur au rôle SharePoint_Shell_Access. Dans le cas où les bases de données ne possedent pas ce rôle , ce dernier est crée automatquement à l’aide cette commande.

Après exécution de la cmdlets Add-SPShellAdmin, il est possible d’exécuter les cmdlets SharePoint.

L’utilisateur exécutant la cmdlet Add-SPShellAdmin doit posséder les autorisations suivantes :

o Accès au rôle de serveur Securityadmin sur l’instance SQL et rôle db_owner dans une base de données.

o Autorisation administrative sur l’ordinateur local.

Il faut exécuter la cmdlet Add-SPShellAdmin pour toutes les bases de données auxquelles vous voulez accorder l’accès. Si aucune base de données n’est spécifiée, la base de données de configuration de la batterie de serveurs est utilisée. Si vous spécifiez une base de données, la base de données de contenu de la batterie sera incluse en plus de la base de données de configuration de la batterie que vous spécifiez.

Une plateforme SharePoint utilise l’Active Directory de l’entreprise pour l’authentification des utilisateurs. Lorsqu’on se retrouve dans le cas d’une migration d’un domaine AD à un autre, nous somme dans l’obligation de réaliser une migration des comptes utilisateurs afin que chaque utilisateur puisse s’authentifier et conserver ses droits et ses autorisations sur la plateforme SharePoint.

Cette étape de migration doit obligatoirement suivre la migration des comptes utilisateurs au niveau de l’AD.

Commande de migration :

Stsadm –o migrateuser –oldlogin –newlogin -ignoresidhistory

• oldogin represente le nouveau login de l’utilisateur : anciendomaine\user
• newlogin represente l’ancien login utilisateur : nouveaudomaine\user
• Le paramétre ignorersidhistory lorsque ce dernier n’est pas renseigné ou porte la valeur « False », les métadonnées d’historique SID du nouvel utilisateur sont vérifiées pour savoir si elles correspondent au nom de l’ancien utilisateur. Si le paramètre ignoresidhistory est renseigné, la vérification des métadonnées n’est pas effectuée.

Pour rappel :

SIDHistory signifie " historique des identifiants de sécurités ".Cette fonction permet de conserver temporairement le SID (Security IDentifier) de l’ancien domaine. La conservation de cet identifiant permet de préserver l’accès des utilisateurs à leurs ressources habituelles malgré l’utilisation d’un nouveau compte utilisateur dans un nouveau domaine de sécurité. Ceci permet donc de pourvoir migrer les différentes ressources du domaine A vers le domaine B par étape sans avoir un impact sur l’utilisateur.

Il peut arriver aussi que des autorisations soient attribuées aux groupes Active Directory sur la plateforme SharePoint, Afin que les utilisateurs appartenant à ces groupes puissent conserver leurs autorisations hérités des groupes parents. Ces groupes doivent aussi être migrés dans SharePoint.

Comme pour le cas de la migration des utilisateurs cette dernière doit suivre la migration des groupes dans l’AD.

Il faut aussi que cette migration soit effectuée après la migration des utilisateurs dans l’AD.

Commande de migration :

Stsadm –o migrategroup –oldlogin –newlogin

Cette commande de migration est disponible depuis les cumulatives updates Aout 2009.

Les cumulatives updates sont les mises à jour dédiées à SharePoint qui sont publiées tous les 2 mois. Ces packages peuvent corriger des bugs apparus sur le produit SharePoint, comme ça peut être une évolution du produit, par exemple certaines commandes propres à SharePoint sont disponibles à la suite d’une publication d’un cumulative Updates.

Les cumulatives peuvent contenir des corrections mineures, elles peuvent aussi contenir des changements importants et dans ce cas on parle de Service Pack

Pour une bonne administration de SharePoint, il faut se tenir informé et consulter ces mises à jour tous les 2 mois sur le site officiel de Microsoft, bien prendre du recul par rapport aux mises à jour surtout lorsqu’elles sont importantes et surtout toujours les tester sur des plateformes de test avant de les déployer en production. Il faut valider leur interaction avec la plateforme déjà mise en place et personnalisée.

Format des packages Cumulatives Updates SharePoint

MOSS 2007 :

• CU pour WSS + CU pour MOSS 2007

SharePoint 2010 :

• CU SharePoint Foundation 2010
• CU pour SharePoint Foundation 2010 + SharePoint Server 2010
• CU pour SharePoint Foundation 2010 + SharePoint Server 2010 + Project Server 2010

Mode d’installation des packages de mises à jour :

1. MOSS 2007 :

• Plateforme à serveur autonome (unique) : installation et configuration du package CU pour WSS ensuite installation et configuration du package CU pour sharePoint.

· Plateforme multiserveurs :

• Les CUs pour WSS doivent être installés sur le serveur d’application qui héberge la console d’administration centrale en premier , il faut ensuite lancer le wizard de configuration, cette étape doit être mise en pause le temps de déployer les CUs pour WSS sur les serveurs frontaux, une fois ces CUs installés et configurés sur les serveurs frontaux, l’etape de configuration des CUs sur le serveur d’application peut être finalisée.
• Les CUs pour sharePoint doivent être installées à l’identique des CUs pour WSS expliqué ci-dessus.

2. SharePoint 2010

· Plateforme à serveur autonome (unique) :

Important : En raison du changement du mode de packaging, il n’est plus nécessaire d’installer les CU de SharePoint Foundation puis les CU de SharePoint Server.

• De ce fait et selon le package de CU choisi suivant le type de produit SharePoint déployé sur la plateforme SharePoint, il faut lancer l’installation ensuite la configuration du CU sur cette dernière.

· Plateforme multiserveur :

Comme expliqué ci-dessus, suivant le produit SharePoint déployé sur la plateforme, il faut installer les CUs correspondants dans l’ordre suivant :

• Installation des CU sur le serveur d’application qui héberge la console d’administration centrale en premier,
• Installation des CU sur le(s) serveur(s) d’application
• Vérifier que les mises à jours ce sont correctement installées
• Arrêter le load balancing entre les serveurs frontaux
• Installer les CUs sur les serveurs frontaux un par un
• Vérifier que les mises à jour ce sont correctement installées
• Lancer le wizard de configuration sur le serveur d’application qui héberge la console d’administration centrale
• Lancer le wizard de configuration sur le reste des serveurs d’application
• Lancer le wizard de configuration sur les serveurs frontaux un par un

Une fois les CUs installées et configurées, il faut vérifier que la version de SharePoint correspond à celle attendue et publiée par Microsoft.

Symptômes :

- Sur un serveur Windows 2008 R2 il peut arriver que lorsqu’on ouvre la console « Gestionnaire du serveur », les onglets Rôles et features soient en Erreur » avec un code erreur 0x800B0100

- Dans Panneau de configuration, Programs-> Programs and features, les mises à jour installées n’apparaissent plus.

Cause :

Une mise à jour mal installée avec des packages manquants ou corrompus.

Solution :

Cibler le ou les packages incriminés et les réinstaller, pour cela il faut suivre les étapes suivantes :

• Télécharger l’outil « System Update Readiness Tool for Windows Server 2008/Vista : Il faut choisir la version correspondant à l’architecture du serveur : x86 ou x64 bits
• Executer l’outil
• Un fichier de log est généré automatiquement dans C:\Windows\logs\CBS\CheckSUR.log , voici un exemple de fichier log

Dans ce cas et qui peut être différent d’un serveur à un autre, la mise à jour KB2506014 avait 2 packages corrompus et qui ont été corrigé et remplacé automatiquement.

Il peut arriver que des packages soient manquants dans ce cas il faut :

• Télécharger la KB.msu
• Renommer.msu en .cab et extraire tous les fichiers pour récupérer les packages manquants.
• Copier ces packages dans un nouveau dossier
• Modifier le propriétaire du dossier C:\Windows\Servicing\Packages, en le remplaçant avec le compte que vous utilisez
• Donner les droits « full control » pour le compte que vous utilisez

• Copier les packages dans le dossier C:\Windows\Servicing\Packages
• Ne pas oublier de réattribuer le droit « Propriétaire » à l’utilisateur initial.

Le module PowerShell de Windows offre la possibilité d’automatiser l’installation de SharePoint 2010. Voici les étapes à suivre :

• Récupérer la clé de License du produit.
• Télécharger le module SPModule qui est un module Windows PowerShell qui installe une batterie de serveur SharePoint (un .zip + fichier.txt)
• Extraire les fichiers dans un dossier (le .zip contient 2 dossiers :SPModule.misc et SPModule.setup)
• Activer l’exécution des scripts Power shell en exécutant la cmdlet suivante : Set-Executionpolicy Unrestrited

• Importer le module SPModule dans PowerShell : il faut exécuter Windows PowerShell en mode Administrateur puis lancer les cmdlets suivantes :

• Créer un fichier .XML qui contiendra tous les paramètres de configuration : « sharepointInstall_config.xml »

  <Configuration> <Package Id="sts"> <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/> </Package> <Package Id="spswfe"> <Setting Id="SETUPCALLED" Value="1"/> <Setting Id="OFFICESERVERPREMIUM" Value="1" /> </Package> <Logging Type="verbose" Path="%temp%" Template=" Setup(*).log"/> <PIDKEY Value="PKXTJ-DCM9D-6MM3V-G86P8-MJ8CY" /> <Setting Id="SERVERROLE" Value="APPLICATION"/> <Setting Id="USINGUIINSTALLMODE" Value="1"/> <Setting Id="SETUP_REBOOT" Value="Never" /> <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/> <INSTALLLOCATION Value="c:\Program Files\Microsoft SharePoint" /> <Display Level="Basic" CompletionNotice="Yes" AcceptEULA="Yes" /> </Configuration>

Détails des attributs et des arguments:

<Package Id="sts"> : ce package permet d’installler le module : SharePoint Foundation 2010 qui représente le socle de SharePoint 2010

<Package Id="spswfe"> ce package installe le modutle SharePoint 2010

<Setting Id="SERVERROLE" Value="APPLICATION"/>: permet de faire une installation d’une ferme de serveur,

<Display Level="Basic" CompletionNotice="Yes" AcceptEULA="Yes" /> :

Displey Level =”basic” : permet d’afficher les étapes d’installation , la clé du produit et les termes du contrat de License

CompletionNotice =”Yes” : Applicable uniquement si “Level” a la valeur Basic ou None. Le programme d’installation affiche l’avertissement de fin d’opération.

AcceptEULA = “Yes” : ce paramètre permet d’accepeter les termes du programme d’installation

<Logging Type="verbose" Path="%temp%" Template="SharePoint Server Setup(*).log"/>
Logging Type =”verbose” : permet d’ecrire toutes informations dans les fichiers de log , c’est le niveau de logging le plus elevé.

Path=”%temp% il s’agit du chemin par défaut pour stocker le fichier de log”.

Template =”Setup (*).log : le nom du fichier log , l’* permet au programme d’installation d’ajouter une chaine de caractère “AAAAMMJJHHMMSSxxx” afin que le fichier de log soit unique

• Lancer la cmdlet suivante :

Install-SharePoint -SetupExePath <nom et Chemin d’accès au setup.exe> -ConfigXML <nom et chemind’accès au fichier xml>

De plus en plus d’entreprise ayant choisit MOSS 2007 pour répondre à leur besoin en terme de travail collaboratif commencent à migrer vers la solution SharePoint 2010 afin de bénéficier de toutes les nouveautés et des améliorations du produit.

Microsoft propose nativement quelques méthodes de migration, chacune de ces méthodes possèdent des avantages et des inconvénients.

La migration peut être découpée en deux étapes importantes : migration de la version de l’outil SharePoint (Déploiement de SharePoint 2010 sur tous les serveurs de la ferme) et la migration du contenu du portail existant SharePoint.

Ave Point propose son outil Doc Ave SharePoint Migrator V5 permettant de migrer le contenu SharePoint d’une ferme à une autre.

Voici la liste des éléments pouvant être migrés :

• Les bibliothèques 
• Les dossiers
• Les pages Web
• Les listes
• Les différentes versions des documents (si le versionning est activé sur le site SharePoint)
• La Sécurité : utilisateurs et permissions
• Les listes personnalisées
• Les métadatas
• Les modèles de sites
• Mes Liens

Avantages de l’utilisation de cet outil :

• Minimiser les efforts requis pour le déploiement de la nouvelle version de SharePoint : puisque DocAve permet de déplacer automatiquement le contenu source vers le contenu Cible en gardant les mappages des éléments ainsi que toutes les propriétés.
• DocAve assure l’intégrité des données sensibles durant la migration.
• Réutilisation des sauvegardes SharePoint pour faciliter la migration : Lors d’une migration il est possible soit de migrer le contenu directement (en Live) soit de faire une restauration à partir de sauvegardes existantes, dans ce 2^e cas l’administrateur optimise sa productivité puisqu’il n’aura pas à recréer la structure de la plateforme.
• Permet aux administrateurs SharePoint de réussir leur Migration en évitant d’oublier des étapes à exécuter.
• Avec DocAve Migrator, la migration en direct est très simple et se base sur un simple glissé/deplacé ce qui par conséquent simplifie la migration
• Flexibilité de la migration : Avec docAve Migrator, la migration peut se faire de manière granulaire (une instance, un dossier, ou un élément…) et peut être planifiée (exécution de la tâche de migration à une heure précise).
• L’outil DocAve Migrator peut être deployé sur un matériel existant de la plateforme SharePoint existante, aucun pré requis matériel n’est obligatoire
• DocAve Migrator, utilise un scanner de pré migration afin d’éviter tout risque d’erreur.

Les ressources pouvant être migrées avec DocAve Migrator vers SharePoint 2010:

• SharePoint 2001, 2003, 2007
• Exchange Public Folder
• File Systems/Network Shares
• Documentum/eRoom
• Open Text Livelink/Vignette
• Lotus Notes/QuickPlace
• Oracle Stellent
• Static, HTTP/S accessible web content and internet sites
• Microsoft Content Management Server 2002 (MCMS 2002)

Dans le cas ou le serveur qui héberge le site d’administration centrale est indisponible (Par défaut il s’agit du 1er serveur frontal de chaque ferme). Il est possible de basculer le site sur un des serveurs frontaux de la ferme MOSS

Pour basculer le site d’administration centrale sur un autre serveur frontal, suivre la procédure suivante :

Ouvrir une session sur le serveur frontal devant devenir le nouvel hôte du site d’administration centrale.

1. Lancer une invite de commande

1. Se positionner au niveau du dossier  "C:\Program Files\Fichiers communs\Microsoft Shared\web server extensions\12\BIN"

1. Lancer la commande : Psconfig -cmd adminvs -provision -port %numéro_port% –windowsauthprovider OnlyUseNtlm

1. Redémarrer les services IIS ainsi que les services SharePoint

1. Vérifier le fonctionnement du site : http://localhost:<n°port admincentrale>  (exemple :http://frontal2:2009)

L’erreur DCOM est une erreur qui apparait quasi systématiquement après l’installation et la configuration d’une plateforme MOSS 2007. Cette erreur apparait sur tous les serveurs de la ferme et à des intervalles réguliers.

Cette erreur est due au droit « LOCAL Activation » manquant sur certains objets DCOM pour les utilisateurs SharePoint et principalement les comptes utilisés pour les pools d’application qui font partie du groupe IIS_WPG.

Pour remédier à cette erreur procédez comme suit :

Ajoutez l’utilisateur “Service Réseau” (NETWORK Service)  au groupe “Utilisateurs du modèle COM distribué” (Distributed COM Users).

Accordez au groupe IIS_WPG les bons droits sur les composants IIS Admin Service et IIS WAMREG Admin Service

1 - Démarrez la console services de composants en exécutant : C:\Windows\System32\com\comexp.msc

ou

Cliquez sur Démarrer | Outils D’administration | Services de composants

2 - Réinitialisez la configuration de la sécurité des composants IIS Admin Service et IIS WAMREG Admin Service :

Cliquez sur le composant IIS Admin Service avec le bouton droit puis cliquez sur Propriétés.

Sélectionnez l’onglet Sécurité et positionnez toutes les autorisations à Par Défaut (Use Default) puis cliquez sur le bouton OK.

Important : Réalisez la même opération pour le composant IIS WAMREG Admin Service.

Cliquez sur le composant IIS Admin Service avec le bouton droit puis cliquer sur Propriétés.

Sélectionnez l’onglet Sécurité, au niveau de la section Autorisation d’exécution et d’activation ("Launch and Activation Permissions"), côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit").

Ajoutez le groupe IIS_WPG et accordez-lui toutes les autorisations.

Au niveau de la section Autorisations d’accès ("Access Permissions"), côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit").

Ajoutez le groupe IIS_WPG et accordez-lui toutes les autorisations.

Vérifier les droits de configuration pour le groupe Utilisateurs.

Au niveau de la section Autorisations de configuration ("Configuration Permissions") côchez Personnaliser ("Customize") puis cliquez sur Modifier ("Edit"). 

Vérifiez que le groupe Utilisateurs dispose des autorisations Lecture ("Read") et Autorisations Spéciales ("Special permissions").

Important : Réalisez la même opération pour le composant IIS WAMREG Admin Service.

A l'issue de cette procédure, l'erreur DCOM ne devrait plus ce produire !