SHAREPOINT 2010 : Event ID 6482 - Application server administration job failed for service instance

Aujourd'hui, un court article sur un problème rencontré chez un client lors de la suppression d'une solution SharePoint 2010 fournie par un éditeur tierce.

De nombreuses erreurs pas très rassurantes sont apparues dans le journal d'évènement d'un des serveurs frontaux.

 

Après quelques recherches, le problème provient de la définition des timer qui est en erreur sur le frontal incriminé. Pour corriger ce problème, il faudra purger la définition des timer en suivant la méthodologie suivante: 

• Arrêter le service Windows nommé « SharePoint 2010 Timer »,
• Se placer dans le répertoire C:\ProgramData\Microsoft\SharePoint\Config\{GUID} (sur un Windows Server 2008). Si vous avez plusieurs GUID, entrez dans le répertoire ayant pour date de modification celle de l'arrêt du service de Timer SharePoint,
• Copier le fichier « cache.ini » pour en garder une trace au cas où cela se passerait mal,
• Supprimez tous les fichiers XML compris dans ce répertoire (correspondant aux définitions des timerjob),
• Ouvrez le fichier « cache.ini » avec Notepad et positionner « 1 » à l’intérieur,
• Relancer le service Windows nommé « SharePoint 2010 Timer ».

Lorsque le service de timer sera relancé, la liste des définitions sera aussitôt redescendue dans le répertoire et le fichier cache.ini sera modifié automatiquement. Vous pourrez vérifier que le "1" n'est plus présent dans ce fichier.

SHAREPOINT 2010 : Modification claims provider

Cette semaine je suis tombé sur un petit problème lors de l'utilisation d'un custom claim provider dans SharePoint 2010.

 

Contexte
Disposant, d'une authentification par ADFS sur une web application, je souhaitais tester le très bon provider disponible sur CodePlex nommé "LDAPCP".

Pour ceux qui ne connaissent pas, il est disponible pour SP2010 et SP2013 à l'adresse suivante : http://ldapcp2010.codeplex.com/.
L'avantage de ce custom provider est qu'il permet de pouvoir résoudre les noms dans les people picker  de SharePoint lorsque vous utilisez un provider ADFS (ce qui n'est pas possible nativement...).

 

Problème
Pour l'installation, aucun problème, il suffit de suivre la documentation et ainsi de modifier votre "SPTrustedIdentityTokenIssuer" dans SharePoint en mettant à jour le "ClaimProviderName".
Par contre, le problème survient lorsque vous souhaitez désinstaller un custom claim provider et revenir sur le natif de SharePoint...Il semble que vous soyez obligé de supprimer votre "SPTrustedIdentityTokenIssuer" puis de le recréer.
Autant dire, dans le meilleur des cas, cela fera quelques minutes à s'amuser!

 

Solution de contournement
Heureusement, il est possible de modifier votre "SPTrustedIdentityTokenIssuer" sans pour autant le recréer à chaque fois que vous voulez changer de claims provider.
Pour cela, il faudra utiliser les commandes PowerShell pour SharePoint suivantes qui utilisent la reflection pour réutiliser le claim provider standard de SharePoint :

$issuer = Get-SPTrustedIdentityTokenIssuer XXXX
$tissuerGetType().GetField("m_ClaimProviderName","NonPublic,Instance").SetValue($ti, $null)
$issuer.Update()

 

J'ai réalisé ceci sur ma plateforme de développement SP2010 et cela a fonctionné à merveille.
Par contre, je ne pense pas que ceci soit supporté sur MS dans le cas d'une plateforme de production chez un client.

 

INFOPATH : Ligne courante tableau extensible C#

 

Aujourd'hui un rapide post sur une demande récurrente dans les forums.

Il est souvent nécessaire de récupérer les valeurs à l'intérieur d'une section extensible ou d'un tableau extensible.

 

Lors de l'utilisation de l'évènement "Changed" sur un champ compris dans un tableau extensible, il est possible de vouloir récupérer la valeur d'un autre champ situé sur la ligne courante.

 

Par exemple, pour calculer la différence entre 2 dates ou une différence de montant qui ne pourrait pas être réalisée via une règle InfoPath). Pour cela, il faudra utiliser le code suivant dans l'évènement "On changed" de votre champ: