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 » :
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 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
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.
SharePoint 2007 : stsadm trimauditlog, ou comment remplir son disque SQL
Symptômes
A la base le problème est venu d’une innocente case à cocher dans Nintex Reporting 2008, case qui permettait de purger les données d’audit après que le service Nintex ait tourné.
Les données d’audit SharePoint sont stockées dans des tables SQL Server nommées AuditData, et il existe une commande stsadm nommée trimauditlog qui permet de purger ces données d’audit.
Rapidement les disques DATA du serveur SQL se sont remplis à vue d’oeil (et vive les environnements de test !).
Cause du problème
La cause du problème était que Nintex exécute la commande stsadm avec le paramètre « enddate » fixé à la date du jour (de mémoire), paramètre qui permet de spécifier une date jusqu’à laquelle il faut purger les données.
Les tables contenant à ce moment là des millions de lignes, il n’en fallait pas plus pour affoler les compteurs.
Résolution
La résolution a été de lancer manuellement (et à x reprises) la commande stsadm, mais avec cette fois le paramètre « enddate » fixé à une date beaucoup + éloignée de la date du jour, afin de purger graduellement.
Exemple de commande :
stsadm -o trimauditlog –enddate 20110808 –databasename MOSS_Content_Site1
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.
Nettoyer le cache de configuration de SharePoint
Symptômes
Divers et variés !
Je me suis servi de cette méthode à plusieurs reprises : patching (KB, CU) posant problème (wizard tournant dans le vide), des déploiements de solution coincés, …
Je n’ai pas (encore) eu à appliquer ce qui suit sur un environnement SharePoint 2010, mais sait-on jamais …
Ça cache quoi, ce cache de configuration ?
Ce cache de configuration conserve sur les serveurs SharePoint des informations sur la configuration de votre ferme SharePoint, évitant ainsi de requêter la base de données inutilement.
Un timer job nommé « Config Refresh » est exécuté toutes les 15 secondes et est chargé de mettre à jour le cache sur tous les serveurs de la ferme.
Et parfois, il arrive qu’une désynchronisation se fasse entre le cache de votre serveur et la base de données, provoquant ainsi des problèmes divers et variés …
Résolution
La méthode est décrite dans cette KB.
Voici les étapes :
1. Stoppez le service « SharePoint Timer » sur tous les serveurs de la ferme.
2. Accédez au répertoire du cache :
- Pour SharePoint 2007 : C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID
- Pour SharePoint 2010 (enfin Windows 2008) : C:\ProgramData\Microsoft\SharePoint\Config\GUID
3. Effectuez une sauvegarde du répertoire.
4. Supprimez tous les fichiers XML du répertoire, en conservant le fichier « cache.ini ».
5. Ouvrez le fichier « cache.ini », saisissez « 1 » à la place de la valeur, et appuyez sur « Enter ». Sauvegardez et fermez le fichier.
6. Répétez les étapes précédentes sur tous les serveurs de la ferme.
7. Redémarrez le service « SharePoint Timer » sur les serveurs; les fichiers XML réapparaissent au fur et à mesure.
8. Vérifiez que la valeur du fichier « cache.ini » n’est plus « 1 ».
9. Vérifiez dans l’administration centrale que le job « Config refresh » est à l’état « Succeded ».
Créer les comptes AD nécessaires à l’installation de SharePoint
Cet article présente les comptes (AD) que vous devez créer avant de débuter une installation de SharePoint en mode non-standalone. Ces indications sont valables pour SharePoint 2007/2010/2013 dans le cadre d’une installation « Least Privilege », qui fait partie des best-practices à suivre lors d’une installation de SharePoint.
Il fait partie d’une série concernant le déploiement de SharePoint 2013 :
- SharePoint 2013 : Prérequis matériels, logiciels et système,
- SharePoint 20xx : Création des comptes AD nécessaires à l’installation,
- SharePoint 2013 : Améliorer la sécurité de SQL Server,
- SharePoint 2013 : Installer un serveur (en mode ferme),
- SharePoint 2013 : Installer un serveur standalone,
- SharePoint 20xx : Ajouter un serveur à une ferme.
Suite à une remarque m’ayant été faite (merci Julien), je précise que le déroulement de cette procédure suppose que votre contrôleur de domaine soit un serveur distinct du serveur SharePoint.
L’installation de SharePoint sur un DC n’étant de toute manière pas supporté par Microsoft, je vous conseille donc de monter un contrôleur de domaine indépendant.
Liste des comptes à créer
- Votre_Domaine\SP_Install est utilisé pour effectuer l’installation de SharePoint (lancement des setup, du wizard de configuration ou de psconfig), ainsi que pour les mises à jour (updates, language packs, …).
- Votre_Domaine\SP_Farm est utilisé lors de l’installation de SharePoint en tant que « compte d’accès à la base de données ». Ce compte sera utilisé automatiquement par le pool de l’administration centrale, et le service Timer.
Création des comptes
1. Lancez votre console AD.
Lancez le « Server Manager », cliquez à gauche sur « ADDS », puis faites un clic droit sur votre serveur et sélectionnez « Active Directory Users and Computers ».
2. Pour plus de lisibilité, créez une OU propre à SharePoint.
Cliquez-droit sur votre domaine, sélectionnez « New » puis « Organizational Unit ».
3. Saisissez le nom de l’OU (ici SharePointUsers pour être original …); cliquez sur « OK ».
4. Créez les 2 utilisateurs « SP_Install » et « SP_Farm » en suivant les étapes ci-dessous
- Cliquez-droit sur votre OU, sélectionnez « New » puis « User ».
- Saisissez les informations du compte et cliquez sur « Next ».
- Saisissez le mot de passe du compte, et cochez les 2 cases signalées. Cliquez sur « Next ».
- Cliquez sur « Finish »
5. Les 2 comptes sont créés dans la nouvelle OU.
Habilitations des comptes
Seul le compte « SP_Install » nécessite des habilitations particulières.
6. Il doit être membre du groupe « Administrateurs » sur les serveurs sur lesquels SharePoint sera installé (hors SQL et contrôleur de domaine, donc).
- Sur chaque serveur SharePoint, lancez le « Server Manager », cliquez sur « Tools », puis sur « Computer Management ».
- Cliquez sur « Local Users and Groups », cliquez sur « Groups » puis double-cliquez sur « Administrators, et enfin sur « Add » dans la fenêtre.
- Remplissez le nom du compte, validez : le compte « SP_Install » fait désormais partie du groupe « Administrateurs » du serveur.
7. Il doit également posséder les rôles SQL « dbcreator » et « securityadmin ».
- Lancer SQL Server Management Studio. Cliquez sur « Connect ».
- Développez « Security », puis faites un clic-droit sur « Logins » et « New Login ».
- Saisissez le nom du compte « SP_Install ».
- Cliquez « Server Roles », et sélectionnez « dbcreator » et « securityadmin ». Cliquez sur « OK ».
La création et la configuration des comptes est terminée.
SharePoint 2007 : erreur lors de déploiement de contenu
Symptômes
Sous SharePoint 2007, lors du déploiement de contenu entre 2 fermes, l’erreur suivante apparaissait pour une collection de site particulière :
« Failed import operation for Content Deployment job « Remote import job for job with sourceID = 633fc2a0-24b8-41c8-8493-92ac31f1baf8 ». Exception was Microsoft.Sharepoint.SPException: Impossible de terminer cette operation. Please retry. System.Runtime.InteropServices.COMException (0x80004005). The operation could not be completed. Microsoft.SharePoint.Library.SPRequest.ImportNavigationXml. »
Résolution
La cause du problème était un lien hyperlink mal formé dans la description d’une page de publishing.
La suppression de cette description par l’interface ne résolvant pas le problème, un petit bout de code a finalement eu le dernier mot, en substance :
item.File.CheckOut();
item[« Description »] = « »;
item.Update();
item.File.CheckIn(« fixing description »);
item.File.Approve(« fixing description »);
item.File.Publish(« fixing description »);
A noter que ce problème a été corrigé dans SharePoint 2010, cf. KB2598304.