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 :
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 :

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

It generates this code in the View element :
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 2013 : Email notifications are not sent (from My Site's newsfeed)

sharepoint2013 Context : Users of your SharePoint web applications can receive email alerts, but they are never notified by all the « My Site » activities, such as « Someone has started following you » or « Someone has mentioned you ».
In the SharePoint logs (ULS), you can see errors like:
Failed attempt x sending mail to recipients: Mail Subject: NAME Surname mentioned you in a conversation. Error: SmtpException while sending email: System.Net.Mail.SmtpException: Mailbox unavailable. The server response was: 5.7.1 Client does not have permissions to send as this sender
Solution : These notifications seem to be sent in an authenticated way, by the app pool service account (unlike the standard emails (alerts) that use the address defined in the « outcoming email » in central administration, in an anonymous way). So you have to add the right « Send-As » to this account in Exchange.
NB : If it doesn’t work, grant this right to the SharePoint Timer service account as well. I still have a doubt on this one :/
Source : Technet forum

SharePoint 2013 : How I fixed my corrupted AppFabric Cache Service

sharepoint2013 I have faced some troubles with Ditributed Cache… (again ?)
Especially when I tried to change the service account of the AppFabric Caching service, as explained here.
Then, my services seemed corrupted, it was impossible to restart them properly (Restart-CacheCluster command).
Their status was stuck on STARTING for a few minutes, and then went DOWN :

PS C:Userssp_admin> Use-CacheCluster
PS C:Userssp_admin> Get-CacheHost
HostName : CachePort Service Name Service Status
-------------------- ------------ --------------
Server1:22233 AppFabricCachingService DOWN
Server2:22233 AppFabricCachingService STARTING

And I had this error in the Windows Event logs (Event ID 1000 and 1001) – Seeing a failing KERNELBASE.dll module is not very reassuring !
This is what I have done to fix it. BEWARE that a corrupted distributed cache can result in resinstalling SharePoint from scratch ! So please be careful.
1- Stop all the SharePoint Distributed Cache service instances (on each WFE) :

Stop-SPDistributedCacheServiceInstance -Graceful

Use this code to force the uninstall :

Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"} | % { $_.Server; $_.Status; $_.Id }
$s = Get-SPServiceInstance <GUID>

2- Unregister all hosts (on each WFE) :


3- Register all hosts :

Register-CacheHost -Provider "SPDistributedCacheClusterProvider" -ConnectionString "Data Source=DBAlias;Initial Catalog=SPServer2013_Config;Integrated Security=True;Enlist=False" -Account "DOMAINSP_DistributedCache" -CachePort 22233 -ClusterPort 22234 -ArbitrationPort 22235 -ReplicationPort 22236 -HostName Server1

  • The parameter « Account » must be the managed account that run the service (as displayed in the central administration).
  • The parameters « Provider » and « ConnectionString » must be copied from the following file « C:Program FilesAppFabric 1.1 for Windows ServerDistributedCacheService.exe.config »
  • The parameter « HostName » must be changed as well.

4- Start each cache host (on each WFE) :

Start-CacheHost -ComputerName Server1 -CachePort 22233

5- Restart all the servers
6- Create the SharePoint Service Instances (on each WFE) :


Everything went well then. These 2 commands showed me that the services were Online, and the AppFabric Services were marked as UP :

Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"} | % { $_.Server; $_.Status; $_.Id }

SharePoint 2013 : Réparer un cluster de cache distribué défectueux

sharepoint2013 Quand on rencontre des difficultés avec le cache distribué de SharePoint, il faut suivre les instructions données sur cette page : Manage the Distributed Cache service in SharePoint Server 2013.
Cependant, on peut se retrouver avec une ferme plutôt têtue qui refuse de créer correctement un cluster de cache, notamment avec des hôtes qui restent en statut « Provisioning » :/
Voici comment j’ai réussi à m’en sortir :
Premièrement, je pars avec des services de mise en cache AppFabric correctement configurés et lancés.
On vérifie cela avec cette commande :


Si tous les serveurs sont à UP, on peut continuer.
Sinon, j’ai écris un autre article sur le sauvetage d’une installation AppFabric qui tournait de l’oeil : SharePoint 2013 : How I fixed my corrupted AppFabric Cache Service
2.Etat des services
Avec cette commandes, on vérifie l’état des services de cache distribué :

Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"}

Mon problème était là : l’un des hôte restait sur « Provisioning », malgré toutes mes manipulations pour détruire et recréer cet hôte.
Solution : Recréer complètement le cluster.
3.Recréer un cluster de cache distribué
3.1.Supprimer toutes les instances de cache
Passer ces commandes sur tous les hôtes du cluster. On se retrouvera donc avec un cluster vide :

Stop-SPDistributedCacheServiceInstance -Graceful

3.2.Redémarrer les serveurs
Cela peut paraitre un peu brutal, mais dans mon cas c’était indispensable.
3.3.Recréer les instances de service
Sur tous les serveurs qui devront héberger le cluster, passer cette commande :


Passer de nouveau cette commande :

Get-SPServiceInstance | ? {($_.service.tostring()) -eq "SPDistributedCacheService Name=AppFabricCachingService"}

L’ensemble de serveurs devrait être à « Online ».
En passant par l’administration centrale, et aller dans « Paramètres Système » > « Gérer les services sur le serveur ».
Les services de « Cache distribué » doivent être démarré (« Started ») sur tous les serveurs.
Hourra, les fonctionnalités portées par le cache distribuées marcheront avec grâce et célérité.

SharePoint 2013 : Load balancer could not find the endpoint for… (SPEndpointAddressNotFoundException)

Stupeur et tremblement dans les ULS…
This kind of warning can occur with any service application. It means that the application (under IIS) is not running or does not exist !
How can I check ?
When you create a new service application, you should always check that it is actually running under IIS :

  • Get the Service Application ID (SharePoint 2013 Management Shell) :
  • (Get-SPServiceApplication -name "WorkManagementServiceApp").Id

  • Launch IIS Manager (inetmgr.exe) , and check if the web application exists under « SharePoint Web Services » :
  • SPEndpointAddressNotFoundException_Capture_2

  • Also check if the associated application pool is running

What Happened ?
If you created your service application with Powershell, there is a chance that it has not been provisioned.
The command « Get-SPServiceApplication » might return something, but there’s no app in IIS ! This article explains it with more details.
See that example that creates a Work Management Service :

# Get the App Pool Account :
$appPoolAccount = Get-SPManagedAccount "DOMAINSPServices"
New-SPServiceApplicationPool -Name "WorkManagementProxyApplicationPool" -Account $appPoolAccount
$appPool = Get-SPServiceApplicationPool "WorkManagementProxyApplicationPool"
# Create the Service Application :
New-SPWorkManagementServiceApplication -Name "WorkManagementService" -ApplicationPool $appPool
$serviceApp = Get-SPServiceApplication -name "WorkManagementService"
# Create Proxy
New-SPWorkManagementServiceApplicationProxy -name "WorkManagementServiceProxy" -ServiceApplication $serviceApp -DefaultProxyGroup

Is that enough ? No, it isn’t. You should provision it :


A few minutes later, you should see the web application and the application pool runnning in IIS.

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 :
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).