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: surname.name@mycompany.com. 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

IIS : Erreur lors de la déclaration de l’identité d’un pool d’application

iisSur un serveur qui fonctionnait parfaitement (c’est à dire que IIS tourne et les sites répondent), je crée un nouveau pool d’application avec un compte d’annuaire comme identité. Et là boom, erreur de type “Données incorrectes” (HRESULT : 0x80090005) :

iis_bad_data

Ou plus sexy en Powershell :

iis_bad_data_ps

Dans un premier temps, on pourrait croire que le mot de passe du compte est erroné. Mais ce n’est pas le cas. Quand cette erreur survient, le serveur a déjà vérifié la validité du compte.

Comment IIS encrypte les mots de passe ?
IIS encrypte les mots de passe en utilisant différents providers qui sont stockées dans le fichier applicationHost.config (%SystemRoot%\System32\inetsrv\config), dans la section <configProtectedData>, par exemple :


<add name="IISWASOnlyAesProvider" type="Microsoft.ApplicationHost.AesProtectedConfigurationProvider" description="Uses an AES session key to encrypt and decrypt" keyContainerName="iisWasKey" cspProviderName="" useOAEP="false" useMachineContainer="true" sessionKey="*****" />

Le provider “AesProvider” est utilisé pour crypter et décrypter les sections system.webServer.
Le provider “IISWASOnlyRsaProvider” est utilisé pour crypter et décrypter les sections dans le applicationHost.config.

Quant aux clés d’encryption, elles sont dans C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, et elles sont uniques à chaque serveur !

Conclusion : Cette erreur viendrait du fait que les providers décrits dans applicationHost.config ne correspondent plus aux clés du serveur.

Que s’est-il passé ?
Il y a évidemment plusieurs scénarii qui aboutissent à ce problème, mais le plus simple est le suivant : le fichier applicationHost.config a été écrasé à partir d’une copie d’un autre serveur.

Comment résoudre ?
Il y a plusieurs solutions aussi, plus ou moins douloureuses :
Restaurer le fichier applicationHost.config s’il a été sauvegardé,
Réinstaller le rôle “Serveur web”,
Importer également les clés du serveur d’origine. Cet article explique bien le problème et la manipulation à faire.

Un autre article intéressant explique tout cela en détail : MachineKeys on IIS 7.x : Inside Out.

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:\Users\sp_admin> Use-CacheCluster
PS C:\Users\sp_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 !

cache_21

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

Use-CacheCluster
Stop-SPDistributedCacheServiceInstance -Graceful
Remove-SPDistributedCacheServiceInstance

Use this code to force the uninstall :

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

$s = Get-SPServiceInstance <GUID>

$s.Delete()

2- Unregister all hosts (on each WFE) :

Unregister-CacheHost

3- Register all hosts :

Register-CacheHost -Provider "SPDistributedCacheClusterProvider" -ConnectionString "Data Source=DBAlias;Initial Catalog=SPServer2013_Config;Integrated Security=True;Enlist=False" -Account "DOMAIN\SP_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 Files\AppFabric 1.1 for Windows Server\DistributedCacheService.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) :

Add-SPDistributedCacheServiceInstance

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 }

Use-CacheCluster
Get-CacheHost

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 :

1.Pré-requis

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 :

Use-CacheCluster
Get-CacheHost

Si tous les serveurs sont à UP, on peut continuer.

cache1

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.

cache2

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 :

Use-CacheCluster
Stop-SPDistributedCacheServiceInstance -Graceful
Remove-SPDistributedCacheServiceInstance

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 :

Add-SPDistributedCacheServiceInstance

4.Vérifications

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.

cache3

Hourra, les fonctionnalités portées par le cache distribuées marcheront avec grâce et célérité.

[Retour d’expérience] Nantes en Direct pour Android

Logo Nantes en Direct Contrairement à la version pour Windows Phone qui est en XAML (langage natif), Nantes en Direct pour Android est une application HTML.

Avec Android Studio, j’ai créé une application quasi-vide, avec une seule activité qui implémente une WebView.

L’application HTML est quant à elle hébergée sur Azure.

Exigences de développement

“Nantes en Direct” est une application simple : aggréger l’actualité nantaise.
Quand des personnes installent un produit offrant un service simple, elles s’attendent à que ce prédicat s’applique à tout : simplicité de compréhension, d’utilisation (ergonomie) et simplicité d’éxecution (performances).

Au final, mon exigence principale est que l’application doit aussi bien tourner sur un appareil Android bas de gamme qu’un Android performant de dernière génération.
En plus de cela, il faut aussi économiser sur la consommation de données.

Ergonomie

Infographiste, c’est un métier, et ce n’est pas le mien :/ Mais je voulais que Nantes en Direct propose une ergonomie simple et directement compréhensible.

Chaque article est composé de 7 éléments ou informations :

  • Le titre
  • L’origine
  • Le type (fait divers, politique, circulation…)
  • Date de publication
  • Lieu
  • Lien
  • Photo

Pas facile de loger toutes ces informations dans un espace restreint !
Depuis la première version, l’agencement n’a pas trop changé :

Article dans Nantes en Direct

De plus, il y a 3 grandes catégories d’article : Actualité, Sorties et Sport.
Hérité de Windows Phone, j’ai conservé la présentation en pages qui coulissent horizontalement.

Peut-être des expert en ergonomie auraient des remarques à faire, je suis ouvert !

Performances

Déjà pour débugger tout en s’assurer que l’appli fonctionnera sur des appareils pas chers, il faut… acheter un téléphone pourri ! J’ai choisi un Logicom à 50€ à la FNAC, avec une résolution de 480 * 800 et des spécificité au ras des pâquerettes.

Données

Soyons léger ! La liste des articles est générée dans le cloud sur un serveur Azure qui s’occupe de parcourir les sites d’information.

L’application mobile se contente simplement de lire le fichier XML qui en résulte.

What ? XML et pas JSON ?
Et oui, le XML hérite de la version WIndows Phone. Le framework .NET était à l’époque beaucoup à l’aise avec ce format que le jeune et arrogant JSON.

Prochainement je migrerai en JSON, notamment pour économiser encore plus sur la consommation de données.

Design plat et adaptif
Autre légereté : Le peu d’utilisation d’image…. Merci le flat design !
La aussi on gagne sur la conso data.

ned_capture

Combo HTML 5/CSS/jQuery
Enfin le développement web, tout ce qu’il y a de plus classique : HTML/CSS pour mettre en forme tout cela.
jQuery charge les données et adapte la taille des éléments pour être responsive design.

Je n’exclus pas d’utiliser bootstrap dans une version prochaine, histoire d’apporter un peu d’élégance à peu de frais.

Utilisation

Disponible au public depuis 3 mois, l’application a été téléchargée 269 fois, avec un taux de conservation de 77% (personne qui gardent l’application sans la désinstaller.)

On est loin des 2100 de Windows Phone ! Mais j’espère arriver rapidement à 5000 utilisateurs en tout sur Nantes.

Nantes en Direct pour Android

Nantes en Direct pour Windows Phone