Étiquette : Sharepoint

Create a link that initiates a Nintex Workflow associated to a Document Set

Nintex Switzerland

It’s been a long time since my last post !
I’ve moved to Geneva for a new job, but I’m still on SharePoint and other Microsoft stuff 🙂
Nintex is used a lot in Switzerland. I had an issue about creating a client-side script that initiates a workflow. I did not manage to do it with « StartWorkflow » from workflow.asmx. As usual with document sets, a specific treatment is needed.
So, this is the link that you can use :
/_layouts/15/NintexForms/InitiateWorkflow.aspx?List={xxx}&ID={yyy}&ItemGuid={zzz}&WorkflowName=MyNintexWorkflow
Where xxx is the list Guid, yyy is the document set ID (as displayed in docsethomepage.aspx?ID=yyy), and yyy is the UniqueId of the document set.

SharePoint : How to filter an external data XsltListViewWebPart in SharePoint Designer ?

sharepoint 2013
sharepoint 2013

Context : You use Business Data Connectivity to retrieve external data in SharePoint, and you wish to display a filtered view of this data in a page.
In SharePoint Designer, you insert a Data View of that external data.
Then, there are 2 ways to filter it :

  • By using the « Filter » button in the office ribbon :
SharePoint Designer Filter
SharePoint Designer Filter

This actually generates a CAML query :
SharePoint_BDC_Filter_External_Data_2

  • By passing a parameter to the finder method of the BDC Model. You can do this manually or by using the « Search » button :

SharePoint_BDC_Filter_External_Data_1b
It generates this code in the View element :
SharePoint_BDC_Filter_External_Data_3
You should use the second solution. Why ? We could consider the CAML query as a « front-end » filter. It means that ALL the records are sent by the BDC, and then the CAML query filter it.
If you retrive thousands of records, it can affect performances.
If you pass a parameter directly to the BDC (finder method), the request sent to the external source will be filtered, and SharePoint will have to deal with less data.
Maybe you will have to create a new finder method in your BDC, but it worth the time spent on it !

SharePoint 2013 : How to repair a broken Search component at low cost

sharepoint 2013
sharepoint 2013

Once upon a time, after a whole server farm reboot, one of my search component was broken. Content crawling was taking forever, and the ULS were not very explicit. In the central administration, I could see this :

SharePoint Components
SharePoint Components

My application server was unable to run the « Content Processing Component », even if I restart the whole search service (net stop / start OSearch15).
I noticed 2 things that drove me to the solution :
– First, a noderunner.exe process was missing. This confirmed the red cross in the central administration. There was 2 processes instead of 3 (the crawler doesn’t spawn a noderunner.exe process) :

SharePoint Search Processes
SharePoint Search Processes

– On the second hand, there was strictly no logs in the « 15.0DataOffice ServerApplicationsSearchNodesContentProcessingComponent » directory !
It was like the search topology was ignoring this component. So I decided to re-install the search topology, just by cloning it, and activating it :

$searchApp = Get-SPEnterpriseSearchServiceApplication
$initialTopology = Get-SPEnterpriseSearchTopology -SearchApplication $searchApp -Active
$cloneTopology = New-SPEnterpriseSearchTopology -SearchApplication $searchApp -Clone -SearchTopology $initialTopology
Set-SPEnterpriseSearchTopology -Identity $cloneTopology -SearchApplication $searchApp

And it works, without any service interruption !

SharePoint Components
SharePoint Components

SharePoint 2010 / 2013 : La recherche ne fonctionne plus (sur aucun site)

SPDesigner Il y a de multiples définitions pour « la recherche ne fonctionne plus ». Il n’est pas question ici d’indexation, mais de l’impossibilité pour tous les utilisateurs de tous les sites de lancer une recherche.

 

Contexte : Ferme SharePoint 2010 ou 2013, Windows Server 2008 / 2008 R2.
Symptôme : Le lancement d’une recherche sur un site web aboutit à une erreur (Exception). Dans les fichiers de logs SharePoint, il y a des entrées du type :
« Tentative d’opération non autorisée sur une clé du Registre marquée pour suppression »
Dans le journal des événements Windows, il y a :
« Windows a détecté que votre fichier de Registre est toujours utilisé par d’autres applications ou services. Le fichier va être déchargé… »
Diagnostic : le compte de service de recherche essaie d’accéder à une clé de registre, mais il ne peut pas. Une session a pu être ouverte avec ce compte de service sur l’un des serveurs de la ferme (en bureau à distance). Des services ont été redémarrés (ou tentés de l’être). Puis la session a été fermée. Les ouvertures et fermetures de session provoques des ajouts / suppression de clés dans la base de registre. Il SEMBLERAIT que les services qui ont été redémarrés cherchent à accéder à ces clés, alors qu’elles étaient supprimées une fois la session fermée. Cette situation est expliquée ici : blogs.msdn.com.
Solution (Dans le cas du service de recherche) :

  • Dans services.msc : Redémarrer les services « SharePoint Server Search 14 » et “SharePoint Foundation Search V4” (si déjà démarrés)
  • Dans IIS : Recycler le pool d’application « SecurityTokenServiceApplicationPool » sur tous les serveurs SharePoint
  • Dans l’administration centrale de SharePoint : Aller dans « Gérer les services sur le serveur », et redémarrer : « Service de paramètres de site et de requête de recherche ».
  • En dernier recours, un reboot de serveur serait une solution, mais provoquerai une coupure de service, ce qui n’est pas toujours souhaitable.

Comment ne pas réitérer cet incident ?
Ne pas se connecter avec les comptes de service pour relancer les services eux-mêmes.
Il y aurait également une GPO (« Do not forcefully unload the user registry at user logoff ») à modifier (Lien externe), mais ceci nécessite un accord avec les administrateurs du domaine (risque de GPO locales écrasées).

DevOps + SharePoint ?

I think the structure of SharePoint is naturally « DevOps oriented ». Actions to create web applications and configure services through a web interface is a DevOps philosophy ! On standard .NET environnements, such actions require interventions on servers, but SharePoint does this « out-of-the-box ».
But the work of DevOps in a SharePoint environment is not limited to that. In the case of a SharePoint farm hosting several applications, how to ensure that a solution deployment does not impact non-concerned applications ? How to be sure that an application will not be broken by an undisciplined neighbor ?
Because SharePoint is a complex service, the traditional tools of production operators are not sufficient to watch a farm. And on the other hand, development teams should not have to worry about server scalability !
This is the role of DevOps : Being the bridge between developers and production, while maintaining a consistent chain of delivery.
In a future post I will talk about the tools available to the « DevOps SharePoint ».
This is my view about what a « DevOps SharePoint » shoud be :

How to "DevOps" SharePoint ?
How to « DevOps » SharePoint ?

Traduction française :
Je pense que la structure même de SharePoint est orientée DevOps. Les actions de création d’applications web et de configuration de services au travers d’une interface web est une philosophie DevOps ! Ce genre d’actions nécessiteraient des interventions sur les serveurs, mais ici c’est SharePoint qui contrôle cela « out-of-the-box ».
Mais le travail du DevOps dans un environnement SharePoint ne se limite pas à cela. Dans le cas d’une ferme SharePoint qui hébergeraient plusieurs applications autonomes, comment garantir qu’un déploiement de solution n’impacte pas des applications non concernées ? Comment être sûr qu’une application ne soit pas impactée par le développement du voisin ?
Parce que SharePoint est un service complexe, les outils classiques des opérateurs / exploitants de production ne suffisent pas à gérer une ferme. Mais d’un autre côté, les équipes de développement n’ont pas à se soucier de l’évolutivité (scalability) des serveurs !
C’est là le rôle du DevOps : Faire le pont entre dev et prod, tout en maintenant une chaine de livraison cohérente.
Dans un prochain post je parlerais des outils à disposition du « DevOps SharePoint ».

Install and Configure iFilter for SharePoint Foundation 2010

SharePoint Foundation 2010 : Installer et configurer iFilter 9 pour fichiers PDF.
In SharePoint Foundation 2010, these are the steps to make PDF files indexed by the search engine :

  • Install Adobe iFilter 9 for PDF files
  • Copy a PDF icon in %CommonProgramFiles%Microsoft SharedWeb Server Extensions14TEMPLATEIMAGES
  • Add an entry in the Docicon.xml file
  • Modify the registry (twice !)
  • Configure the indexer so that it takes into account the PDF extension (VBS script provided by MS)
  • iisreset

Just follow these two tickets :
http://support.microsoft.com/kb/2293357
http://support.microsoft.com/kb/2518465
You don’t need to install Search Server 2010.
TRADUCTION
Pour que les fichiers PDF soient indexés par le moteur de recherche Foundation 2010, il faut faire les actions suivantes :

  • Installer iFilter 9 fourni par Adobe
  • Copier une icone de fichier PDF dans %CommonProgramFiles%Microsoft SharedWeb Server Extensions14TEMPLATEIMAGES
  • Ajouter une entrée dans le fichier DOCICON.XML
  • Modifier la base de registre (2 fois)
  • Configurer l’indexeur pour qu’il prenne en compte l’extension PDF (script VBS fourni par MS)
  • iisreset

 
Il suffit donc de suivre à la lettre les 2 billets suivants :
http://support.microsoft.com/kb/2293357
http://support.microsoft.com/kb/2518465
Pas besoin d’installer Search Server 2010 !

SharePoint 2010 : Diminuer la durée rétention des données d'utilisation

Better than a Shrink
Voici la commande à passer pour passer à 3 jours de rétention pour les données d’utilisation de la ferme (Console Powershell SharePoint) :
Get-SPUsageDefinition | foreach-Object { Set-SPUsageDefinition -Identity $_.Name -DaysRetained 3 }
Ceci permet de réduire la taille de la base WSS_Logging.

SharePoint (2007/2010) : Echec de l'élévation de privilèges dans un EventReceiver.

Au rez-de-chaussée, c’est ‘.
Dans un EventHandler de ce type (ou d’un autre !) :
public override void ItemAdded(SPItemEventProperties properties){
   SPSecurity.RunWithElevatedPrivileges(delegate()   {
  // Actions nécessitant des privilèges.
});
Dans le code exécuté avec privilèges, il NE FAUT PAS utiliser directement les objets présentés par l’objet properties (.List, .Web, etc.). Il faut retrouver ces objets avec leur ID (.ListID, .SiteID, etc.). Sinon il y a de grandes chance d’avoir des valeurs ‘ ou des exceptions d’accès.
SPSite monSite = new SPSite("url.com");
SPList maListe = monSite.Lists[properties.ListID];
SPItem monItem = maListe.GetItemById(properties.ListItemId);
etc…
 

SharePoint : La suppression d'une colonne provoque une "erreur inconnue"

L’un connu, l’autre pas.
Symptôme : Le fait de supprimer la colonne d’une liste provoque une erreur inconnue. La trace est la suivante :
w3wp.exe (0x0AA8) 0x044C Windows SharePoint Services General 8dzz High Exception Type: System.Web.HttpException Exception Message: Unable to validate data.
Diagnotic : Certaines pages systèmes (dans /_layouts/*.aspx) ne supportent pas la présence d’une webpart de recherche dans la page maître. Article détaillé.
Solution : Si la page maître d’application “application.master” contient une webpart de recherche, il faut la supprimer (édition dans un bloc note, puis publication dans la galerie des pages maitres du site).

SharePoint : "stsadm -o backup" renvoie des erreurs KeyNotFoundException

Où sont passées les clés ?
Symptôme : Lors d’un backup catastrophique de la ferme, l’erreur “KeyNotFoundException” peut survenir, notammanent pour les objets liés à la recherche SSP (“Index de recherche partagé” ou la base de données associée).
Explication : Plusieurs causes sont envisageables. Notamment un index déféctueux ou obsolète. Le mieux est de vérifier si les services de recherche sont bien configurés et démarrés (dans l’admin centrale, mais aussi dans les services partagés).
Solution 1 : Purger les index.

  • Accéder au serveur d’administration incriminé.
  • Ouvrir l’Administration centrale de SharePoint 3.0
  • Accéder au site des services partagés
  • Cliquer sur « Administration de la recherche »
  • A gauche, cliquer sur « Réinitialiser tout le contenu analysé ».
  • Cliquer sur le bouton « Réinitialiser maintenant », confirmer par “OK”.
  • La sauvegarde ne devrait plus retourner d’erreurs.

Solution 2 : Dans le cas où le script ne fonctionne toujours pas, on redémarre les services de recherche en vérifiant leur bonne configuration.

  • Aller dans l’administration centrale
  • Cliquer sur « Opérations », puis « Services sur le serveur »
  • Arrêter le service « Service de recherche Office SharePoint Server », et confirmer.
  • Démarrer ce même service
  • Cliquer sur « Opérations », puis « Services sur le serveur »
  • Cliquer sur « Recherche d’aide Windows SharePoint Services » (ou « recherche d’aide… » selon la version).
  • Confirmer le compte et mot de passe du « compte d’accès au contenu », cliquer sur OK.
  • Cliquer sur « Administration de services partagés »
  • Faire « Modifier » sur le service partagé, et lui associer le serveur d’indexation.
  • Le service de recherche SSP devrait fonctionner, et le script de sauvegarde ne devrait plus retourner d’erreurs.

La solution 2 a fonctionné dans un cas précis. Seul problème : on perd ses index, et dans le cas de fermes SharePoint conséquentes, d’autres solutions sont à envisager.