SharePoint 2010 : Problème dans le menu des pages wiki

Symptômes

Dans le cadre d’une migration de SharePoint 2007 vers SharePoint 2010, l’erreur suivante apparaissait dans le menu de gauche des pages wiki et le lien « Recently Modified » ne fonctionnait pas :

Résolution

Créez une colonne indexée sur la colonne « Modified ».

1. Allez dans la bibliothèque de pages wiki, puis cliquez sur « Document Library settings » :

2. Cliquez sur « Indexed columns » :

3. Cliquez sur « Create a new index » :

4. Choisissez la colonne « Modified », puis cliquez sur « Create ».

Note : Si la colonne « Modified » n’apparaît pas, cet article décrit la résolution du problème.

5. De retour sur les pages wiki, le menu fonctionne désormais !

SharePoint 2010 : Installer une ferme avec authentification SQL

Cet article présente une méthode pour installer une ferme SharePoint 2010 avec authentification SQL.

Cette méthode d’installation est utile lorsque votre ferme (ou au moins votre frontal) n’appartient pas à un domaine AD, par exemple dans le cas d’un extranet en DMZ.

Ici je vais considérer devoir installer une ferme SharePoint 2010 comportant un frontal et un serveur SQL, ces 2 serveurs étant dans le même workgroup.

Le principe

N’ayant par définition pas d’Active Directory disponible, vous devez utiliser l’authentification SQL pour monter votre ferme SharePoint; le frontal va alors « dialoguer » avec le moteur SQL via un compte SQL, et non plus le compte AD habituellement spécifié dans le wizard.

Vous avez peut-être l’habitude de configurer votre ferme SharePoint en passant par le wizard de configuration et en spécifiant le compte de la ferme, mais dans ce cas de figure il va falloir oublier cette méthode car cette configuration va se faire en utilisant l’outil PSConfig.

Avant tout, voici les prérequis :

• Création d’un utilisateur (+ les rôles requis) dans SQL Server,
• Création des bases de données initiales,
• Création des comptes locaux sur votre serveur frontal pour l’installation de SharePoint.

Prérequis 1 : Création d’un utilisateur dans SQL Server

1. Créez un user SQL en cliquant-droit sur « Security/Logins », puis sur « New Login »

2. Saisissez le nom du compte (ici « SQLFarmAccount »), cliquez sur « SQL Server authentication » saisissez un mot de passe, et décochez « Enforce password expiration ». Cliquez dans le menu de gauche sur « Server roles ».

3. Attribuez les rôles SQL securityadmin, dbcreator et sysadmin à ce compte. Cliquez sur « OK ».

Prérequis 2 : Création des bases de données initiales

Créez depuis SQL Server bases 2 bases de données vides avec pour collation « Latin1_General_CI_AS_KS_WS » :

• BDD de configuration :  DMZ_Config
• BDD de l’administration centrale : DMZ_AdminContent

1. Cliquez-droit sur « Databases », puis sur « New Database »

2. Saisissez le nom de la base, puis mettez le compte SQL précédemment créé (SQLFarmAccount) comme owner de la base. Cliquez dans le menu de gauche sur « Options ».

3. Choissez « Latin1_General_CI_AS_KS_WS » dans la liste déroulante « Collation »

Prérequis 3 : Création des comptes locaux

1. Créez localement sur votre serveur frontal SharePoint les comptes requis pour l’installation : SP_Install et SP_Farm.

Vous créez donc les mêmes comptes que d’habitude, sauf qu’ils sont locaux, et non pas dans l’AD.

2. Placez ensuite le compte « SP_Install » dans le groupe « Administrators » du frontal, et reloguez-vous avec ce compte.

Test de la connexion SharePoint -> SQL

1. Sur le serveur SharePoint, créez un fichier « .udl » pour vous permettre de tester la connexion vers le serveur SQL; ouvrez le fichier.

Saisissez le nom du serveur SQL, les nom et mot de passe du compte SQL, et cliquez sur « Test Connection ».

2. Si la connexion fonctionne correctement la popup suivante apparaît.

Installation de la ferme

1. Connecté à votre frontal en tant que SP_Install, installez SharePoint comme d’habitude mais décochez « Run the wizard » à la fin de l’installation.

2. Lancez la commande suivante pour créer la base de données de configuration de la ferme SharePoint :

psconfig -cmd -configdb -create -server VotreServeurSQL -database DMZ_Config -dbuser SQLFarmAccount -dbpassword @Password2  -passphrase passPhrase -admincontentdatabase DMZ_AdminContent -user VotreServeurFrontal/SP_Farm -password @Password1 

3. La ferme SharePoint est créée, lancez le wizard (vous pouvez également utiliser psconfig) pour finir la configuration.

4. Sur la page suivante, on retrouve bien les paramètres passés à psconfig.

Choisissez l’option « Do not disconnect … », cliquez sur « Next », choisissez ensuite le port de votre administration centrale et passez les fenêtres restantes.

5. La configuration s’achève.

6. Lancez l’administration centrale .

Vérification du compte utilisé

Un coup d’oeil sur le SQL Server Profiler nous montre que SharePoint utilise bien le compte SQL que nous avons spécifié pour communiquer avec les bases de données. 

Installation de mises à jour SharePoint

La mise à jour de la ferme SharePoint se déroule de manière classique,  je suis passé dans cet exemple de la version 14.0.4762.1000 (RTM) à la version 14.0.6126.5000 (SP1 + CU août 2012).

Quid des applications de service ?

Pour tester la création des applications de service, rien de tel qu’un « Farm Configuration Wizard » avec toutes les cases cochées ou presque.

Résultat, 2 applications de service en erreur :

• Application Registry Service, qui pour un usage standard de SharePoint n’est pas indispensable,
• Web Analytics Service Application, à priori pas prévu pour fonctionner avec ce type de ferme.

Tests (basiques) de fonctionnement

** Création d’une application web **

Avant de créer une application web, vous pouvez créer un nouveau « managed account » dédié au pool d’application : créez un compte local (ici SP_AppPool) et passez par PowerShell pour effectuer la création :

Vous pouvez ensuite passer par l’administration centrale pour créer l’application web  en sélectionnant le pool d’application précédemment créé :

Et surtout en sélectionnant l’option « SQL authentication » :

** Création d’une collection de site **

RAS, effectuez la création comme d’habitude :

** La recherche **

Si le « full crawl » se passe bien, le « Query Component » peut se faire tirer l’oreille pour démarrer :

Dans ce cas il vous faudra passer par PowerShell (cf. cet article).

Conclusion

La mise en oeuvre d’une ferme SharePoint hors d’un contexte AD est donc possible, bien que ne garantissant pas l’absence de (mauvaises) surprises à l’utilisation.

Je n’ai personnellement pas testé toutes les fonctionnalités (loin de là) dans ce mode d’utilisation, ayant rarement eu à faire avec ce type d’installation chez des clients.

Par ailleurs, de ce que j’en connais, vous ne pouvez pas rajouter de second frontal à ce type de ferme.

SharePoint 2013 / 2010 / 2007 : Changer d’utilisateur quand l’option n’est pas disponible

[EDIT 1]

Microsoft a publié une KB qui décrit ce problème pour SharePoint 2013 : voir ici.

[/EDIT1]

[EDIT2]

J’ai déposé le WSP et les sources du projet à cet endroit (Buildé avec VS2012 et testé sur SharePoint 2013).

[/EDIT2]

Par défaut, dans SharePoint (hors version 2013), vous avez la possibilité de changer d’utilisateur en utilisant l’option « Sign in as Different User », qui vous demande alors un couple login / mot de passe.

Cette fonctionnalité a été supprimée dans SharePoint 2013, mais il y a néanmoins plusieurs possibilités de contourner ce comportement.

Cas de SharePoint 2013

Par défaut donc, vous n’avez pas moyen de switcher facilement d’utilisateur, comme vous le faisiez avec les versions précédentes de SharePoint.

** Solution 1 **

Il vous suffit de lancer la page « /_layouts/AccessDenied.aspx?loginasanotheruser=true » pour retrouver la popup de saisie de login/mot de passe.

** Solution 2 **

La seconde solution est d’utliser la solution 1, mais en la déployant (globalement ou non) via une feature.

Dans cet exemple je crée une feature de scope « ferme », qui est chargé de rajouter dans le menu des « Site settings » une entrée pour changer d’utilisateur.

Comme elle est de scope « Farm », cette feature va s’activer automatiquement et l’option sera alors disponible sur tous les sites de votre ferme.

Bien entendu il vous suffit de restreindre le scope (WebApplication, Site ou Web) pour réduire le champ d’application.

La feature en question :

Le fichier XML associé :

Un ptit coup de PowerShell et le tour est joué :

Dans l’administration centrale, cliquez sur « Manage farm features » :

La feature est bien activée :

Sur un site SharePoint, cliquez sur le bouton « Settings », l’option « Sign in as Different User » est bien présente :

Une fois le couple login / mot de passe saisi, on a bien changé d’utilisateur :

Si on télécharge un document, c’est bien l’utilisateur « test » qui est utilisé :

** Solution 3 **

Vous pouvez trouver sur cette page une autre solution, [EDIT 1] et de Microsoft, cf KB citée au début de ce post [/EDIT1] qui est de modifier un « user control » par défaut de SharePoint.

Je ne l’ai pas testé, car modifier un fichier du 15 n’est pour moi pas une solution envisageable.

Cas de SharePoint 2007 / 2010

Dans ces versions de SharePoint vous pouvez également tomber sur des cas où cette option n’est pas disponible (customisations, pages en erreur, …).

Les solutions sont alors les mêmes que pour SharePoint 2013, mais la solution 1 devrait vous suffire, à savoir lancez la page « /_layouts/AccessDenied.aspx?loginasanotheruser=true » pour retrouver la popup de saisie de login/mot de passe.

SharePoint 2010 : User Profiles – Erreur lors de la configuration d’une connexion AD

Symptômes

Dans le cadre de la gestion des « User Profiles », si l’erreur suivante se produit (« MOSS MA not found ») lors de la configuration d’une nouvelle connexion de synchronisation :

Résolution

Le problème est probablement lié aux services liés à FIM (arrêtés ou à redémarrer) :

Depuis l’administration centrale, redémarrez le service « User profile synchronization » pour corriger le problème.

SharePoint 2010 : La colonne « Modified » n’est pas disponible pour une colonne indexée

Symptômes

Dans le cadre d’une migration de SharePoint 2007 vers SharePoint 2010, j’ai rencontré un problème sur les wikis, qui avait comme solution la création d’une colonne indexée « Modified ».

Problème : La colonne « Modified » n’apparaissait pas dans la liste déroulante.

(Sur cette copie d’écran c’est ce que j’aurai du avoir sans le problème).

Résolution

Lancez l’url « /_layouts/fldedit.aspx?field=Modified » à la racine de la collection de sites, puis cliquer sur « OK » sans rien modifier dans le formulaire pour faire réapparaître « Modified » dans la liste de choix.

SharePoint 20xx : Mettre en place une page de maintenance

Lors d’une mise à jour, un besoin relativement récurrent est de pouvoir empêcher les utilisateurs d’accéder au site, tout en leur affichant un message « user-friendly ».

Il est possible de mettre en place cette fonctionnalité assez facilement : il vous suffit de placer une page nommée « App_Offline.htm » à la racine du site IIS de votre application web, page vers laquelle vos utilisateurs seront alors redirigés.

Une fois votre opération terminée, il vous suffira de supprimer ce fichier vous retrouver un fonctionnement « normal ».

Cette manipulation fonctionne avec toutes les versions de SharePoint, puisqu’apportée par Asp.net 2.0.

Contenu du fichier

Le fichier est bien sûr personnalisable, il doit juste avoir une taille minimale de 512 octets, d’où le charabia placé en fin de document.

<!DOCTYPE html PUBLIC « -//W3C//DTD XHTML 1.0 Transitional//EN » « http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd« >
<html xmlns= »http://www.w3.org/1999/xhtml » >

<head>
<title>Le site est en maintenance</title>
</head>

<body>
<h1>Le site est en cours de maintenance</h1>
<p>
La page est super moche, mais elle remplit son rôle !
</p>
<!–
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
–>
</body>

</html>

Mise en place

1. Via l’explorateur Windows ou IIS, copiez-collez le fichier à la racine de l’application web.

2. That’s all, vous pouvez tester le résultat

SharePoint 2010 : Le champ « Product Key » est grisé

Symptômes

Lors du passage d’une licence « Standard » vers une licence « Entreprise », en utilisant la fonctionnalité « Convert farm license type » :

Le champ permettant de saisir la clé est grisé.

Résolution

Suivre les instructions de cet  article Technet, à savoir passer par le lien « Enable Enterprise Features » :

Sélectionnez « Enterprise », et saisissez la clé de licence.

SharePoint 2013/2010 : Le service “Usage and Health Data Collection Proxy” est arrêté

Si le service « Usage and Health Data Collection Proxy » est arrêté sur votre ferme SharePoint (2010 ou 2013).

Exécutez les commandes PowerShell suivantes :

$SAProxy = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}
$SAProxy.Provision()

Le service est alors démarré.

Installation de Data Protection Manager 2010 (Windows 2008 R2)

La protection de DPM 2010 couvre les versions de SharePoint allant de 2003 à 2010, et permet (entre autre) de restaurer une ferme, une base de données, une collection de site, un site ou un item (ouf).

Pour plus d’informations sur comment protéger SharePoint avec DPM 2010, vous pouvez consulter ce WhitePaper.

L’installation de DPM 2010 est simple, surtout que cette version ne requiert plus l’installation de IIS sur le serveur et que SIS (Single Instance Storage) est installé automatiquement.

Parmi les prérequis pour installer DPM 2010 on trouve :

• Un serveur Windows Server 2008 (R2 ou pas), version Standard ou Enterprise – 64 bits,
• Le serveur est rattaché à un domaine,
• Un disque dédié au « Storage Pool », où DPM stockera ses données,
• 2 Go de RAM minimum (recommandation),
• Une instance SQL dédiée de SQL Server 2008 SP1 (32 ou 64 bits), version Standard ou Enterprise – au besoin SQL Server peut être installé par l’installeur de DPM,
• Le Framework .NET 3.5 SP1.

Installation

1. Lancez l’installeur; cliquez sur « Install Data Protection Manager ».

2. Cliquez sur « I accept… », puis sur « OK ».

3. Cliquez sur « Next ».

4. La vérification des prérequis se lance; nous sommes averti de l’installation de SIS.

Cliquez sur « Next ».

5. « Single Instance Storage » a été installé, rebootez le serveur.

6. Relancez l’installeur; la vérification des prérequis est validée. Cliquez sur « Next ».

7. Saisissez votre nom et celui de votre société. Cliquez sur « Next ».

8. Vous avez la possibilité d’inclure SQL Server 2008 à cette installation; si vous ne le faites pas, vous devrez utiliser une instance SQL existante.  Cliquez sur « Next ».

9. Saisissez un mot de passe pour les utilisateurs locaux créés par DPM. Cliquez sur « Next ».

10. Choisissez si vous désirez utiliser les mises à jour Microsoft. Cliquez sur « Next ».

11. Choisissez si vous désirez participer au « Customer Experience Improvement Program ». Cliquez sur « Next ».

12.  Cliquez sur « Install ».

13. L’installation débute.

14. L’installation est terminée sans erreurs. Cliquez sur « Close ».

Configuration

1. Lancez  DPM 2010 en cliquant sur « Microsoft System Center Data Protection Manager ».

2. En premier lieu il va falloir configurer le disque dédié au « Storage Pool ».

Cliquez sur l’onglet « Management ».

3. Cliquez sur l’onglet « Disks », puis sur « Add… »

4. Ajouter le disque en cliquant sur « Add », puis sur « OK ».

5. Cliquez sur « Yes » dans la popup.

6. Le disque s’affiche bien dans la liste, DPM est prêt à être utilisé.

Dans un prochain post je présenterai la configuration de DPM pour protéger SharePoint ainsi que quelques exemples de restauration.

 

Installation d’une mise à jour SharePoint : The installation of this package failed

Symptômes

A l’installation d’un update sur SharePoint 2010 (ici le SP1), vous obtenez le message d’erreur « The installation of this package failed » :

Résolution

Téléchargez de nouveau le package d’installation et vérifiez qu’aucun problème ne se produit pendant le téléchargement.