Office 365 ProPlus : Mise à jour Office

La sortie de Windows 10 étant à présent officielle, il était temps de faire un refresh de mon PC vers le nouvel OS Microsoft.
La qualité de celui-ci est une bonne surprise : pas de problème de mise à jour à déplorer, la plupart des logiciels est compatible, interface conviviale et performante.

 

Après l'installation de Office 365 ProPlus (version Office Click to run), quelle ne fut pas ma surprise de revoir apparaître un logiciel nommé "Lync" (remplacé en début d'année Skype for Business).

J'ai donc lancé une mise à jour de mon PC via Windows Update afin de corriger ceci, mais "Lync" était toujours présent. En fait, le problème ne vient pas de Windows mais d'un changement de mode de mise à jour des versions Office 365.

Il s'avère que sur une installation click to run de Office 2013, les mises à jour Office ne descendent plus par Windows Update comme précédemment. Pour procéder à la mise à jour, il est nécessaire d'ouvrir un logiciel Office (Word,Excel,...) puis d'aller dans "Fichiers"/"Compte office" et sélectionner "Mise à jour"...

INFOPATH 2013 : Rediriger un formulaire

Une demande récurrente dans la conception des formulaires InfoPath Forms Services est la possibilité de rediriger le formulaire vers une URL spécifique lors de l'enregistrement, la fermeture ou l'annulation du formulaire.

 

Il existe une méthode "classique" qui consiste à modifier l'adresse dans le paramètre "Source" de l'url du formulaire. Lorsque le formulaire se ferme, vous êtes automatiquement redirigé vers la valeur précisée dans le paramètre source.

Cette technique fonctionne très bien uniquement lorsque que vous restez sur votre tenant SharePoint.

Si vous devez préciser une URL externe, il sera nécessaire de passer par une page intermédiaire stockée dans SP. Afin de contourner le problème de limitation d'une redirection vers une url externe, vous pouvez suivre les étapes suivantes:

• Créer un fichier ".aspx" sur votre PC,
• Dans ce fichier, insérer uniquement une balise JavaScript et insérer le code de redirection suivant : "window.location="monurl":

• Télécharger ce fichier dans une bibliothèque SharePoint en l'approuvant ou le publiant si nécessaire,
• Faire pointer le paramètre "Source" de l'url de votre formulaire vers l'adresse de ce fichier.

 

Note : Si vous concevez un fichier HTML (à la place d'une page ASPX), celui-ci ne sera pas être ouvert directement par SharePoint et il vous sera demandé de le télécharger. Ce comportement reste tout de même modifiable en changeant le mode de sécurité de l'application web de 'Strict' à 'Permissif' (attention cette option n'est pas disponible sur Office 365).

 

 

Ceci est une version basique fonctionnant sur SharePoint 2013 et Office 365. Il serait possible d'être plus intelligent et dynamique en réalisant des redirections en fonction:

• de valeurs du formulaire (interrogation via JSOM),
• du type de formulaires,
• du type d'utilisateurs,...

Pour cela, il suffira uniquement de passer les paramètres souhaités à la page de redirection qui comprendra l'intelligence métier.

Office 365 : InfoPath GetUserProfileByName

Aujourd'hui un court article sur une limitation découverte sur InfoPath Forms Services dans le cadre d'Office 365 lors de la tentative d'utilisation d'un service web SharePoint.

 

La méthode "GetUserProfileByName" permet de retrouver facilement les informations de l'utilisateur connecté sur SharePoint en recherchant les données depuis sa fiche de profil.

L'appel de cette méthode depuis un formulaire InfoPath Forms Services génère une exception (error 5566 ou 401).

 

En effet, celui-ci n'est pas accessible depuis InfoPath dans Office 365 à cause du paramétrage de désactivation de la protection de bouclage ("DisableLoopBackCheck").

Cela fonctionne généralement sur les serveurs SharePoint On Premise car la clé de registre "DisableLoopBackCheck" est positionnée à "1".

 

Voici un article du support MS répertoriant ce problème :

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

 

Malheureusement, pour des raisons de sécurité évidentes du côté de chez Microsoft, cette contrainte semble immuable. Autant prédire qu'il y ait peu de chances que cette utilisation dans O365 soit un jour possible ...

 

Il reste donc 2 solutions de contournement aussi contraignantes l'une que l'autre:

• Réaliser un formulaire "client lourd" se connectant à ce web service car cela fonctionne avec cette méthode (Inconvénient : Les utilisateurs devront posséder InfoPath sur leur poste),
• Utiliser une liste SharePoint comprenant les informations nécessaire (Inconvénient : duplication de l'information).

Office 365 : Ajout champ géolocalisation

Dans un précédent post, j'avais traité de la possibilité de rajouter le nouveau type de champ "Geolocation" sur une ferme SharePoint 2013 On Premise en utilisant du PowerShell.

Suite à la demande grandissante, voici le code (utilisant le Client Object Model) à exécuter afin de réaliser cet ajout sur votre site SharePoint situé dans O365 (changer les informations de connexion : tenant, nom utilisateur, password) : 

Uri oUri = new Uri("https://tenant.sharepoint.com");
MsOnlineClaimsHelper claimsHelper = new MsOnlineClaimsHelper(oUri, "userid@tenant.onmicrosoft.com", "userpassword");
using (ClientContext context = new ClientContext(oUri))
   {
     context.ExecutingWebRequest += claimsHelper.clientContext_ExecutingWebRequest;
     List oList = context.Web.Lists.GetByTitle("MaListe");
     oList.Fields.AddFieldAsXml("", true, AddFieldOptions.AddToAllContentTypes);
     oList.Update();
     context.ExecuteQuery();
                    
    }

Remarque : A présent, il est possible d'administrer SharePoint Online dans O365 à laide de commandes PowerShell en utilisant les applets de commandes à cet effet : http://technet.microsoft.com/fr-fr/library/fp161364.aspx

La liste des applets de commandes disponibles actuellement n'est pas très étoffée. A n'en pas douter, l'avenir de Office 365 passera par l'extension de ces méthodes afin de fournir un outil complet d'administration.