SharePoint 2013 : Noderunner.exe

Aujourd'hui, un nouvel article sur SharePoint 2013!

En travaillant quotidiennement sur la nouvelle mouture de SharePoint Server, il s'avère que cette version est très plaisante mais qu'elle est aussi beaucoup plus gourmande que la précédente version en terme de consommation de ressources machine.

En allant faire un tour sur le Technet au niveau des prérequis matériels de SharePoint 2013, cette assertion est confirmée:

http://technet.microsoft.com/en-us/library/cc262485(v=office.15).aspx#hwforwebserver

 

Il faut pour l'instant compter 8Go de RAM pour une installation SharePoint Foundation 2013 et 24Go de RAM pour la version SharePoint Server 2013! (oui oui 24Gb, ce n'est pas une erreur...).

 

Autant vous dire que pour une machine virtuelle de développement SharePoint Server 2013 qui tourne sur un PC portable de 8Go de RAM, l'affaire va s'avérer compliquée et l'optimisation des ressources va être nécessaire...

 

En faisant un tour sur les processus sur ma VM, je me suis aperçu que le service NodeRunner était vraiment très gourmand. Ce service est en fait relié à la recherche FAST!

 

Il existe néanmoins un moyen de contenir cet appétit des plus voraces.

Pour cela, il faut suivre les actions suivantes:

• Réduire l'impact de la recherche sur la CPU de la machine de développement. Pour cela, il faut lancer la commande Powershell suivante : "Set-SPEnterpriseSearchService -PerformanceLevel Reduced"
• Modifier le fichier de configuration situé à l'emplacement suivant : "C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config" afin de lui préciser la quantité de RAM dont il peut disposer. Il faut se positionner sur la balise "noderunnersettings" et modifier l'attribut "memoryLimitMegaBytes". Par défaut, la valeur est à "0", ce qui signifie que l'exécutable n'a aucune limite de RAM.

 

 

Ce problème de consommation des ressources par le service de recherche pourrait éventuellement être corrigé lors de la sortie de la version RTM, mais il vaut mieux être au courant de ce genre de paramétrage.

INFOPATH : Solution Sandbox SharePoint

Aujourd'hui, un petit article sur les solutions  en mode Sandbox (ou en bon français : en mode bac à sable). Il est effectivement possible d'utiliser ce genre déploiement pour un formulaire de type InfoPath.

 

Les avantages sont les suivants:

• Un administrateur de la collection de sites pourra déployer le formulaire lui-même sans demander de réaliser ceci à un administrateur ayant les accès à l'administration centrale.
  
• Pas d'interruption de service sur la ferme SharePoint,
• Possibilité de limiter la quantité de ressources utilisées par cette solution sandbox.
• Le formulaire sera publié directement depuis InfoPath sans avoir besoin de passer par l'étape envoi à l'administrateur et téléchargement dans l'administration centrale,
• Au niveau protection et sécurité de la ferme, les solutions Sandbox sont exécutées dans un processus séparé (il existe un service Windows User Code Host) tandis qu'un formulaire dans l'administration centrale peut exécuter n'importe quel genre de code sans sécurité et accéder à n'importe quelle ressource de la ferme.

 

Les inconvénients se situent surtout au niveau  du CAS (Code Access Security) qui entraine de nombreuses limitations sur le code :

• Pas de possibilité d'impersonnation du contexte SharePoint (Le fameux 'RunWithElevatedPrivileges' bien connu des développeurs SharePoint...),
• Modèle objet SharePoint limité,
• Pas d'accès au disque,
• ...

 

 

Vous l'aurez compris, il est recommandé d'utiliser le déploiement Sandbox d'un formulaire avec code lorsque vous disposez d'une faible quantité de code à embarquer dans le formulaire!

 

Bon jeu dans le bac à sable de SharePoint 2013!

INFOPATH 2010 : Erreur SecurityException

Aujourd'hui, un court article sur un problème souvent rencontré par les débutants InfoPath qui souhaitent utiliser du code managé dans leur formulaire.

Lors de l'utilisation de votre formulaire dans SharePoint, vous pouvez rencontrer ce genre de problèmes :

 

System.Security.SecurityException Request for the permission of type ‘Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ failed

 

 

Comme l'exception l'indique, il s'agit d'un problème de sécurité du formulaire. En effet, pour utiliser du code managé dans votre formulaire, il vous faut un niveau élévé.

Pour corriger ce dysfonctionnement, il vous faudra suivre les opérations suivantes:

1. Ouvrir le formulaire en mode conception,
2. Cliquer sur "Options du formulaire" dans la partie "Fichier",
3. Cliquer sur "Sécurité et approbation",
4. Décocher "Déterminer automatiquement le niveau de sécurité",
5. Cliquer sur "Autorisation totale"
6. Republier le formulaire.

 

 

SHAREPOINT 2010 : Résultat recherche lecture seule

Aujourd'hui, un petit point intéressant sur la recherche SharePoint 2010.

Certains clients remontent un problème contraignant : sur quelques postes, les résultats de recherche fournis par SharePoint ne permettent d'ouvrir les documents Office qu'en mode "Lecture seule".

Ce qui peut-être contraignant dans certains cas d'utilisation!

 

En fait, ceci dépend du paramétrage de Internet Explorer du PC.

Pour corriger ceci, il faut réaliser les actions suivantes:

• Cliquer sur les "options internet",
• Dans l'onglet "Programmes", cliquer sur "Module complémentaire",
• Se positionner sur le module "Office document cache Handler" puis l'activer.
• Fermer et rouvrir IE.

 

 

 

Ainsi les documents de recherche s'ouvriront en mode lecture ou modification.

 

 

Le même problème peut survenir sur Firefox.

Pour pouvoir modifier un document issu de la recherche sur Firefox, il faut réaliser l'action suivante:

• Taper "about:config" dans la barre des tâches et confirmer l'alerte de sécurité,
• Chercher la clé "browser.helperApps.deleteTempFileOnExit". Si celle-ci n'existe pas, il faut faire un clic droit puis "Nouveau" puis valeur booléenne,
• Positionner la valeur à "False"
• Fermer le navigateur puis le rouvrir.

 

 

Attention, ces modifications doivent être réalisées sur chaque poste de travail, ce qui est légèrement contraignant sur un parc machine développé!

Une option reste de modifier le XSL des résultats de recherche afin de modifier le lien renvoyé par la page en appelant la même URL que lors du clic d'un élément depuis une bibliothèque SharePoint.

SHAREPOINT 2010 : Service SharePoint Administration

Aujourd'hui, un post sur un problème rencontré chez un client sur une plateforme SharePoint 2010.

Le service SharePoint Administration s'est retrouvé éteint sur les serveurs de la ferme.

La tentative de démarrage de ce service envoyait une erreur de type 1053. Le service s'était donc arrêté de lui-même.

Pour rappel, ce service doit impérativement être démarré sur les serveurs d'une ferme.

 

Après diverses recherches, il s'avère que ce problème survient sur des serveurs SharePoint ayant le SP1 + la CU de février 2012.

Le problème provient de l'installation de la KB 2677070. Cette mise à jour permet la mise à jour automatique des certificats racines du serveur.

 

Le passage de cette KB sur une ferme SharePoint 2010 en CU de février 2012 n'ayant pas accès à internet entraine ce blocage.

Il existe donc 3 solutions:

1. Modifier les règles du proxy pour autoriser les connexions aux URLs permettant d'actualiser les certificats,
2. Désinstaller la KB 2677070 si vous jugez que les serveurs concernés ne sont pas concernés par la faille de sécurité corrigée par ce patch car les serveurs n'ont pas accès à internet,
3. Si vous considérez que cette mise à jour est nécessaire et que l'ouverture du proxy n'est pas envisageable, il faudra bloquer la mise à jour des certificats racines via  les GPO en décochant la case "Automatically update certificates in the Microsoft Root Certificate Program (recommended)"