SHAREPOINT 2013 : InfoPath connexion de données

Aujourd'hui, une petite remontée de bug SharePoint 2013 lors de l'utilisation d'InfoPath.

Il s'avère que lorsque vous disposez d'un formulaire InfoPath 2010 utilisant une connexion de données vers un site SharePoint 2010, vous pourrez rencontrer des soucis lors du passage en SharePoint 2013.

 

Ce problème est référencé sur le site des correctifs de Microsoft :

http://support.microsoft.com/kb/2752020

 

Cette KB est elle même intégrée dans le Cumulative Update (CU) d'avril 2013 de SharePoint 2013.Notez que pour installer cette CU, vous devrez au préalable installer le Primary Update (PU) de Mars 2013 qui fait office de mini service pack.

 

A noter aussi que certains utilisateurs ont constaté un ralentissement de l'ouverture des formulaires InfoPath suite à l'installation de cette CU.

Si l'intervention peut attendre, il sera donc privilégié d'attendre la prochaine CU. Celle de Juin ayant été repoussée : http://blogs.technet.com/b/stefan_gossner/archive/2013/06/12/june-2013-cu-for-sharepoint-2013-is-delayed.aspx

Si cela est urgent, il faudra qualifier l'installation de la CU d'Avril sur un environnement de validation afin de vérifier qu'elle n'entraine pas de régression plus profondes dans d'autres briques de SharePoint.

 

Important : Les CU ne sont à installer que dans le cas de bug avérés. A contrario le passage de la PU est grandement préconisée lors de l'installation d'une ferme.

SHAREPOINT 2013 : PU Mars 2013 BCS Database

Comme beaucoup le savent, il est indispensable d'installer le PU (Primary Update) de SharePoint 2013 dès l'installation d'une ferme. Celui-ci est une sorte de mini SP1 plus que recommandé par MS.

 

Par contre, un des dommages collatéral de cette mise à jour de SharePoint est que la base de données du BCS reste en état mise à jour requise soit le message "Database is in compatibility range and upgrade is recommanded" :

Pour corriger ce dysfonctionnement, il faudra lancer la commande PowerShell pour SharePoint suivante:

(Get-SPDatabase | ?{$_.type -eq “Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase”}).Provision()

Une fois cette action réalisée, la base apparaitra comme ne nécessitant pas d'intervention :

 

 

L'erreur disparaitra de même de l'analyseur d'intégrité SharePoint.

 

Il faudra tout de même que le compte de service exécutant le service possède le droit « SPDataAccess » sur la base de données du BCS. Le cas échéant vous obtiendrez une jolie erreur de type 229 (impossible d'exécuter la procédure stockée dans la base associée au service du BCS).

SHAREPOINT : Désactiver la vérification des certificats

Dans la majorité des installations de SharePoint réalisées, les serveurs SharePoint n'accèdent pas à Internet pour des raisons de sécurité.

 

Le problème principal reste que les performances des sites SharePoint sont réduites de par la vérification de la révocation des certificats de sécurité.

Ceci est un fonctionnement natif du .Net qui tente de se connecter au site crl.microsoft.com afin de vérifier la version.

 

Malheureusement, sur un serveur SharePoint, ce genre de contrôle n'a aucun intérêt et ralenti le rendu des pages à cause de la tentative de connexion à ce serveur qui termine en échec!

 

Pour vérifier ceci, il suffit de se rendre dans le journal d'évènement de votre serveur SharePoint:

• Se positionner dans le journal d'évènement Windows à l'emplacement suivant "Applications et services / Microsoft / CAPI2",
• Cliquer sur le log situé en dessous (nommé "Opérational") pui réaliser un clic-droit afin d'obtenir le menu permettant d'activer les logs.

Lors du chargement d'une web application dans SharePoint, vous pourrez voir apparaitre dans ces logs des erreurs récurrents avec un id d'évènement 11 : "The revocation function was unable to check revocation because the revocation server was offline".

 

 

Afin de rectifier tout ceci, il sera nécessaire de rajouter le certificat SharePoint dans le magasin de certificat racine des autorités de confiance:

$rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content C:\SharePointRootAuthority.cer -Encoding byte

 

Ainsi la révocation ne sera plus vérifiée via Internet!

Vous pouvez consulter tout ceci sur l'article du support MS suivant : http://support.microsoft.com/kb/2625048?wa=wsignin1.0

SHAREPOINT 2010 : Office documents prompt d'authentification

Aujourd'hui, un article concernant SharePoint 2010 et son utilisation en mode claims.

Sur une web application comprenant un fournisseur d'authentification de type ADFS, nous avons récemment rencontré un problème lors de l'ouverture des documents office.

Problématique : la mire d'authentification ADFS était affichée à chaque ouverture des documents.

Afin d'identifier le problème, notre ami "Fiddler" a été d'une grande utilité puisqu'il a permis de détecter une jolie erreur 403 Forbidden dans les requêtes http.

En utilisant un outil de gestion des cookies (cookies manager de FF par exemple), il s’avère que le cookie généré est en mode d'expiration "Fin de session".
A cause de cela, lors de l’ouverture d’un document Office, le contexte est perdu et un nouveau cookie est nécessaire.

Il est donc nécessaire de passer avec cookie FedAuth en expiration fin de date (« End of date ») :
 

 

Pour cela, il faudra lancer les commandes suivantes sur le serveur SharePoint 2010  (puis réaliser un IISRESET sur chaque frontaux) :

 

 

 

Note : Par défaut la durée de validité du cookie est définie à 1h à partir de la connexion. Cette valeur peut être modifiée si nécessaire.
 

Voici un très bon article du Technet sur le STS permettant de le configurer finement : http://msdn.microsoft.com/fr-fr/library/hh147183(v=office.14).aspx