OFFICE et OFFICE SERVER SP1

Les SP1 d'Office 2013 et SharePoint 2013 viennent d'être publiés. Voici la liste des binaires disponibles au téléchargement : 

http://blogs.technet.com/b/office_sustained_engineering/archive/2014/02/25/announcing-the-release-of-service-pack-1-for-office-2013-and-sharepoint-2013.aspx

 

Côté Office, cette mise à jour comprend l'ajout des fonctionnalités suivantes:

• Comptabilité accrue avec Windows 8.1 et Internet Explorer 11,
• Meilleur prise en charge des améliorations matérielles (support high DPI,...),
• Côté développement, amélioration des apps pour Office (task pane apps pour Outlook,...),
• Power Map pour Excel,
• Skydrive Pro qui change de nom et devient OnDrive...

 

Côté SharePoint 2013:

• Support de Windows Server 2012 R2 (rappelons que SP ne pouvait pas être installé sur un R2 auparavant. Il faudra donc posséder un ISO directement en SP1... (http://support.microsoft.com/kb/2891274),
• Intégration d'une section Office 365 dans l'administration centrale permettant de gérer l'intégration Yammer et OneDrive. Un joli pont pour intégrer Office 365 dans l'entreprise,
• ...

Comme toutes mises à jour depuis le SP1 de SP 2010, il n'est pas nécessaire d'installer la partie "Foundation" avant d'installer le patch "Server". Par contre, contrairement aux Public Update (PU) et CU (Cumulative Update), les packs de langues utilisés sur votre ferme doivent êtres installés en version SP1.

La version de votre serveur SharePoint suite à la mise à jour devrait être la suivante : "15.0.4569.1506".

 

Note 1 : Le serveur WAC (Office Web Apps) dispose aussi d'une mise à jour vers SP1. Ne cherchez pas les language pack, ils sont pré-intégrés à l'intérieur du binaire.

Note 2 : Les SDK pour réaliser du développement client sur SharePoint 2013 sont disponibles ici : http://msdn.microsoft.com/en-us/dn369240#fbid=OirLxAiPCYt dans la section Office.

SharePoint 2013 : Erreur Sideloading

Lors de vos développements d'Apps dans SharePoint, vous pouvez être amené à recevoir l'erreur suivante : "Error occured in deployment step 'Install app for SharePoint' : Sideloading of apps is not enabled on this site".

 

Cette erreur provient d'une fonctionnalité manquant sur le site : la feature masquée "Developer".

 

Pour éviter cette erreur, vous pouvez donc tout d'abord créer un site de type "développeur" puis déployer l'apps à cet emplacement.

Si vous souhaitez vraiment tester votre apps sur un autre type de site, il faudra activer la fonctionnalité "Developer".

 

Sur un site SharePoint 2013 On-Premise, il suffit d'activer la fonctionnalité via la commande Powershell pour SharePoint suivante:
Enable-SPFeature -Identity e374875e-06b6-11e0-b0fa-57f5dfd72085 -Url "http://mawebapp/sites/XXX"

 

Pour l'activer dans office 365, il faudra vous donner un peu plus de mal!
Il reste tout de même possible d'activer la fonctionnalité en ouvrant l'éditeur Powershell pour SharePoint Online (http://technet.microsoft.com/fr-fr/library/fp161362.aspx) et en utilisant du client object model:

$programFiles = [environment]::getfolderpath("programfiles")
add-type -Path $programFiles'\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\Microsoft.SharePoint.Client.dll'
Write-Host 'To enable SharePoint app sideLoading, enter Site Url, username and password'

$siteurl = 'https://XXX.sharepoint.com/sites/...'
$username = 'login@XXX.onmicrosoft.com'
$password = ConvertTo-SecureString -String 'MonMotdePasse' -AsPlainText -Force

$outfilepath = $siteurl -replace ':', '_' -replace '/', '_'
 
 try
 {
 [Microsoft.SharePoint.Client.ClientContext]$cc = New-Object Microsoft.SharePoint.Client.ClientContext($siteurl)
 [Microsoft.SharePoint.Client.SharePointOnlineCredentials]$spocreds = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $password)
 $cc.Credentials = $spocreds
 Write-Host -ForegroundColor Yellow 'SideLoading feature is not enabled on the site:' $siteurl
 $site = $cc.Site;
 $sideLoadingGuid = new-object System.Guid "AE3A1339-61F5-4f8f-81A7-ABD2DA956A7D"
 $site.Features.Add($sideLoadingGuid, $true, [Microsoft.SharePoint.Client.FeatureDefinitionScope]::None);
 $cc.ExecuteQuery();
 Write-Host -ForegroundColor Green 'SideLoading feature enabled on site' $siteurl
 }
 catch
 {
     Write-Host -ForegroundColor Red 'Error encountered when trying to enable SideLoading feature' $siteurl, ':' $Error[0].ToString();
 }

SharePoint 2013 : Traduire un claim

Dans SharePoint 2013, les applications web utilisent nativement une authentification basée sur les revendications.
Techniquement, le principe est le suivant : les utilisateurs obtiennent un jeton de sécurité signé numériquement par un fournisseur d’identité approuvé. Ce jeton contient un ensemble de revendications, chacune représentant un élément spécifique des données concernant un utilisateur, par exemple son nom, ses appartenances à des groupes et son rôle sur le réseau. Les applications qui prennent en charge l’authentification basée sur les revendications obtiennent un jeton de sécurité d’un utilisateur, au lieu d’informations d’identification, et utilisent les informations des revendications pour déterminer l’accès aux ressources.
L’authentification basée sur les revendications repose sur des normes telles que WS-Federation et WS-Trust, et sur des protocoles tels que SAML (Security Assertion Markup Language).

 

Ce nouveau processus comporte de nombreux avantages :

• De nombreux fournisseurs d'authentification peuvent être utilisés simplement sur les web application,
• Il n'est plus nécessaire d'étendre vos web application pour supporter différents providers (FBA, NTLM, ADFS,...).

Dans SharePoint 2013, lorsque vous créez une application web depuis l’administration centrale, vous pouvez uniquement spécifier les types et les méthodes d’authentification basée sur les revendications. Il reste en effet toujours possible de créer des applications web en mode dit "classique" via PowerShell mais ce mode n'est pas conseillé voir déprécié.
 

Bien que cette authentification par claims était déjà disponible sous SharePoint 2010, peu de sociétés avaient sauté le pas. Ce changement induit donc quelques modifications dans les développements SharePoint.
 

Pour éviter quelques surprises, voici une fonction permettant de traduire un identifiant claims en sa correspondance "Domaine\NomUtilisateur":

 

private string GetAccountNameFromClaim(string claimUserName)
{
 try
 {
  SPClaimProviderManager spClaimProviderManager = SPClaimProviderManager.Local;
  if (spClaimProviderManager != null)
  {
   if (SPClaimProviderManager.IsEncodedClaim(claimUserName))
   {
    // Retourne l'identifiant sous forme Domaine\NomUtilisateur
    return spClaimProviderManager.ConvertClaimToIdentifier(claimUserName);
   }
  }
  
  // Retourne le token windows de l'utilisateur si celui-ci n'a pas pu être traduit précédemment
  return claimUserName;
 }
 catch (Exception ex)
 {
  throw new Exception("Une erreur est survenue lors de la conversion du claim.",ex);
 }
}

InfoPath : This is the end!

C'est avec un petit pincement au cœur que je relaie une information publiée par Microsoft ce Vendredi 31/01/2014 : La roadmap de InfoPath est arrivée à son terme!
En clair, InfoPath 2013 et InfoPath Forms services 2013 seront la dernière version et n'existeront plus dans la prochaine version d'Office et Office Server. Ce produit qui avait fait son apparition en 2003 connaitra donc officiellement sa dernière version 10 ans plus tard.

Il faut bien avouer que la fin semblait proche étant donné la rumeur grandissante et le faible nombre de modifications apportées à la mouture 2013. De plus, Microsoft tendant actuellement vers une approche multi-device et sous forme d'Apps, la version actuelle d'InfoPath ne pouvait respecter ces critères par conception.

La décision parait pourtant surprenante étant le grand nombre d'entreprises qui utilisent ces formulaires dans leurs processus métiers! J'irai même plus loin : pourquoi intégrer des formulaires InfoPath permettant d'éditer les formulaires de liste SharePoint 2010 et 2013 si le produit n'avait pas d'avenir?

La question en suspend reste la suivante : Quel outil de développement utiliser à présent pour la création de formulaires d'entreprise maintenant que le produit tire sa révérence ?

La phrase principale de l'article est la suivante : "If you’re an InfoPath customer, we want to reassure you that we’re working on migration guidance in parallel as we’re building our next generation of forms technology. Until we have more detailed technology roadmap and guidance to share with you, we encourage you to continue using InfoPath tools"!

Bien qu'il soit clairement formulé dans cet article l'encouragement à continuer d'utiliser InfoPath, il me parait peu probable que les entreprises investissent sur un produit en fin de vie. Pour la parenthèse, cela me rappelle un peu le dilemme de Silverlight à l'époque. De nombreuses entreprises avaient réalisé des projets sur ce produit prometteur avant de se retrouver le bec dans l'eau.

Par contre cette fois-ci, de mon avis peut-être pas assez neutre, les solutions de substitutions proposées actuellement sont insuffisantes (Apss, Access,...).
Pour avoir étudié Access Services, il est impossible de le placer dans la catégorie des remplaçants potentiels (pas de code managé, pas de workflow, pas de sécurité sur les éléments,...).
Le support de Microsoft sur InfoPath sera tout de même assuré jusqu'à 2023!

Il nous reste donc à attendre le nouvel outil de conception de formulaires qui apparaitra dans les prochaines versions.
Comme le dit l'article, les ingénieurs Microsoft travaillent sur une procédure de migration des formulaires InfoPath vers le futur produit.
En espérant que les bon choix soient réalisés sinon cela risque de gronder dans les entreprises.

Voici le lien vers l'article en question : http://blogs.office.com/2014/01/31/update-on-infopath-and-sharepoint-forms/

N'hésitez pas à laisser vos feedback.