Présentation d’Office Web Apps Server

  • Article

Article d’origine publié le mardi 11 septembre 2012

Ce billet a été écrit par Nick Simons, Directeur de programme pour Office Web Apps.

Au cours de l’été 2010, nous vous avons présenté Office Web Apps : une version web de Word, PowerPoint, Excel et OneNote. Ces produits ont été distribués sous la forme d’un ensemble d’applications SharePoint. Les clients qui déploient Office Web Apps sur leurs propres réseaux l’ont donc installé sur des serveurs SharePoint.

À cette époque, l’intégration à SharePoint semblait la meilleure approche. SharePoint était et reste clairement un pilier dans l’histoire d’Office Web Apps. En outre, il dispose d’un modèle bien défini pour l’intégration d’applications du type d’Office Web Apps. Mais quand nous avons commencé à planifier la version suivante d’Office Web Apps, il est apparu clairement qu’il serait difficile d’atteindre certains de nos objectifs majeurs avec une architecture aussi étroitement liée à SharePoint.

Nous avions voulu simplifier la planification de l’installation et de la capacité, et activer la fédération sur plusieurs batteries de serveurs. Nous avions aussi voulu satisfaire les demandes d’intégration de nouveaux partenaires comme Lync. Enfin, bon nombre de clients, à la fois sur Office 365 et en local, souhaitaient les mêmes améliorations dont bénéficiaient régulièrement nos utilisateurs SkyDrive.

Pour atteindre ces objectifs, nous avons repris notre copie et repensé le mode d’intégration d’Office Web Apps à d’autres produits actuels et futurs. Nous avons créé un nouveau modèle qui sépare Office Web Apps de toute technologie partenaire spécifique. Pour finir, notre modèle allège considérablement le poids du code sur les hôtes de fichiers comme SharePoint et nous permet d’exécuter Office Web Apps sur des serveurs complètement séparés.

Ce nouveau serveur autonome s’appelle Office Web Apps Server.

Nous avons bien conscience qu’à première vue, l’idée d’un nouveau type de serveur tend à rendre la tâche plus complexe et du ressort de l’administrateur. En réalité, vous remarquerez que grâce à son autonomie, nous obtenons les avantages suivants :

1.  Installation simplifiée

2.  Mise à jour et maintenance entièrement indépendantes de SharePoint

3.  Plusieurs batteries de serveurs SharePoint s’intégrant à une seule batterie Office Web Apps Server

4.  D’autres produits tels qu’Exchange, Lync et des produits tiers s’intégrant à Office Web Apps

5.  Nouvelles fonctionnalités et améliorations pour nos clients web et locaux sensiblement au même moment

Quand nous comparons les déploiements Office Web Apps précédents sur SharePoint 2010 aux nouveaux déploiements qui utilisent Office Web Apps Server, l’avantage paraît évident.

Avec la version antérieure d’Office, un déploiement typique d’Office Web Apps était plutôt de ce type :

 

Version antérieure des déploiements Office Web Apps

Notez que la version antérieure d’Office Web Apps devait être installée sur chaque ordinateur de chaque batterie de serveurs. De plus, la montée en charge d’Office Web Apps était liée à la montée en charge globale de SharePoint. Et la mise à jour d’Office Web Apps nécessitait la mise à jour du code sur chaque ordinateur de toutes les batteries SharePoint.

Avec Office Web Apps Server, nous espérons un déploiement plutôt de ce type :

 

Déploiements Office Web Apps avec Office Web Apps Server

Comme vous pouvez le constater, une seule batterie Office Web Apps Server peut servir plusieurs batteries de serveurs SharePoint 2013 ainsi que Lync 2013 et Exchange 2013 (Outlook Web Access). En outre, vous pouvez utiliser votre batterie de serveurs Office Web Apps pour afficher n’importe quel fichier Word, Excel ou PowerPoint accessible via une adresse URL ou UNC.

Brève présentation du nouveau modèle d’intégration

Voyons maintenant comment Office Web Apps s’intègre globalement à un hôte de fichiers comme SharePoint. Ces informations vous aideront à comprendre la configuration requise en matière de réseau et de sécurité décrite plus bas.

Commençons par quelques définitions :

  • Office Web Apps Server : fournit la fonctionnalité Office Web Apps aux hôtes et constitue le thème principal de cet article.
  • Hôte : utilise les services fournis par Office Web Apps Server pour afficher des fichiers dans un navigateur web. Par exemple, SharePoint Server 2013, Lync Server 2013 et Exchange Server 2013 sont tous des hôtes.
  • Client : il s’agit d’un navigateur ou d’un autre logiciel de même type.

L’un des composants essentiels du nouveau modèle d’intégration est une nouvelle API publique qu’Office Web Apps utilise pour communiquer avec les hôtes. Cette API est appelée WOPI (Web application Open Platform Interface). Office Web Apps Server extrait et manipule des fichiers à l’aide de l’API WOPI. Nous faisons souvent référence à Office Web Apps Server en tant qu’application WOPI. Les hôtes doivent comprendre les demandes WOPI venant des applications WOPI.

WOPI est une API RESTful qui utilise les protocoles HTTP/HTTPS. Cela signifie que, entre autres, tout le trafic entre les hôtes et Office Web Apps Server transite via des ports HTTP/HTTPS standard. Cela signifie aussi que, autant que possible, Office Web Apps Server est sans état. Il est donc plus résistant aux pannes telles que les pannes réseau ou les pannes totales de matériel.

Pour comprendre comment fonctionne WOPI, prenons un scénario dans lequel un utilisateur, Sally, affiche un fichier appelé test.docx hébergé sur SharePoint. Voici comment cela fonctionne :

1.  Sally accède à une bibliothèque de documents dans laquelle est stocké test.docx.

2.  Sally clique sur le nom du fichier dans la bibliothèque de documents.

3.  SharePoint accède à une page SharePoint spécifique dans le navigateur qui sait comment envoyer des demandes à Office Web Apps Server (et à d’autres applications WOPI). Appelons cette page SharePoint WOPIFrame.aspx.

4.  WOPIFrame.aspx contient un iframe (https://dev.w3.org/html5/spec/the-iframe-element.html) qui accède à une page d’Office Web Apps Server. Appelons cette page WordViewer.aspx. La demande HTTP vers WordViewer.aspx inclut les informations importantes :

    • L’URL (ou point de terminaison WOPI) qui sera utilisée par Office Web Apps Server pour obtenir test.docx.
    • Le nom du fichier. En réalité, le point de terminaison WOPI et le nom du fichier forment un paramètre unique appelé « source WOPI ».
    • Une chaîne qu’Office Web Apps peut transmettre au point de terminaison WOPI et qui représente les informations d’identification de Sally. Nous l’appelons le jeton d’accès.
      À des fins de sécurité, le jeton d’accès ne donne accès à Sally qu’à un seul fichier donné. Si une personne mal intentionnée parvient à voler le jeton d’accès, il ne pourra prendre l’identité de Sally que pour accéder à ce seul fichier. Bien entendu, ce n’est pas non plus ce que l’on souhaite, il est donc important de protéger ce jeton d’accès par SSL.

5.  Office Web Apps Server utilise la source WOPI et le jeton d’accès pour obtenir test.docx auprès de SharePoint.

6.  WordViewer.aspx affiche test.docx dans l’iframe sur WOPIFrame.aspx.

Voici une image représentant le flux de données entre le navigateur, SharePoint et Office Web Apps Server :

Flux de données entre le navigateur, SharePoint et Office Web Apps Server

Configuration de la batterie Office Web Apps Server

Une batterie de serveurs, dans ce cas, peut être aussi bien un ordinateur virtuel s’exécutant sur un serveur partagé qu’une batterie d’une douzaine de serveurs dans un centre de données. La configuration et la maintenance de base sont les mêmes dans tous les cas. Les prérequis et la procédure de création d’une batterie de serveurs sont évidemment fournis avec le produit. Je ne reproduirai donc pas cette documentation ici, mais je vais décrire ce que cela implique avec suffisamment de détails.

Matériel

Pour commencer, vous avez besoin d’ordinateurs. Supposons que vous configurez une batterie de serveurs destinée à répondre aux besoins de 80 000 utilisateurs de plusieurs batteries de serveurs SharePoint. Vous aurez probablement besoin de 4 serveurs dotés de la configuration suivante :

  • Windows Server 2008 R2 ou Windows Server 2012 avec tous les prérequis ;
  • 8 cœurs ;
  • 8 Go de RAM ;
  • un disque dur de taille suffisante (60 Go ou plus).

Vous avez aussi besoin d’un programme d’équilibrage de charge. Nous disposons d’une batterie de 10 ordinateurs configuré chez Microsoft qui partage un programme d’équilibrage de la charge matérielle F5 BIG-IP avec un certain nombre de serveurs. Cette organisation fonctionne très bien mais n’importe quelle solution d’équilibrage de charge décente ferait tout aussi bien l’affaire. Il faut juste impérativement que votre solution d’équilibrage de charge prenne en charge l’affinité. En termes de performances, il est préférable qu’un même serveur gère toutes les demandes pour une session donnée.

Réseau

Supposons que vous voulez que les utilisateurs aient accès à Office Web Apps aussi bien à partir de votre réseau interne que d’Internet. Dans ce cas, vous aurez besoin de configurer les DNS interne et externe pour votre batterie de serveurs. Ou bien, vous pouvez choisir de configurer seulement le DNS externe et d’utiliser les règles DNS internes pour conserver les demandes internes sur votre réseau privé. C’est ce que je ferais.
C’est votre réseau, il vous appartient donc d’en choisir la configuration, mais vous devez au moins respecter les points suivants :

  • Les clients (généralement des navigateurs web) doivent être en mesure d’envoyer des demandes à la batterie de serveurs. Ce sont des demandes HTTP/HTTPS normales sur le port 80 ou 443 respectivement.
  • Les ordinateurs de la batterie de serveurs Office Web Apps envoient des demandes à un service sur l’hôte de fichiers (par ex., SharePoint). Ces demandes sont aussi de type HTTP/HTTPS sur le port 80 ou 443. C’est de cette façon que les ordinateurs Office Web Apps génèrent ou modifient des fichiers.
  • Les hôtes de fichiers doivent parfois demander des informations directement auprès de la batterie Office Web Apps Server via le programme d’équilibrage de charge. Ces demandes sont aussi de type HTTP/HTTPS sur le port 80 ou 443.
  • Tous les ordinateurs de la batterie Office Web Apps Server doivent communiquer les uns avec les autres via le port 809. Idéalement, ces ordinateurs se trouvent sur un sous-réseau privé de sorte qu’aucun autre ordinateur ne puisse rejoindre la batterie de serveurs ou écouter un trafic. Si ce n’est pas le cas, certaines fonctionnalités intégrées à Office Web Apps Server permettent de sécuriser une batterie de serveurs sur un réseau plus ouvert. Je n’aborderai pas ces fonctionnalités ici. Pour plus d’informations, voir Planification de la sécurité pour Office Web Apps Server Preview.

Il est crucial que vous vous assuriez que ces itinéraires réseau sont configurés correctement. Les applications Office Web Apps sont relativement simples mais elles ne fonctionnent que lorsque les canaux de communication sont ouverts.

Sécurité

Comme je l’ai indiqué dans la section précédente, la demande initiale pour générer ou modifier un fichier inclut des informations d’identification sous la forme d’un jeton d’accès. À son tour, le jeton d’accès est inclus dans toutes les demandes d’Office Web Apps vers les hôtes. Tout ce trafic doit être protégé par SSL, sauf si vous vous trouvez sur un réseau privé et que vous connaissez toutes les personnes qui ont accès à ce réseau. Même dans ce cas, vous devriez quand même utiliser SSL. Vraiment.
La configuration de SSL requiert la création de certificats et leur mise en place sur chaque ordinateur Office Web Apps Server ou sur le programme d’équilibrage de charge. Si vous choisissez d’arrêter SSL au niveau du programme d’équilibrage de charge, des paramètres spécifiques peuvent être utilisés dans Office Web Apps Server. J’y reviendrai dans un moment.

Configuration d’Office Web Apps Server

Maintenant que votre matériel et votre infrastructure réseau sont en place, vous pouvez vraiment créer votre batterie Office Web Apps Server. Tout d’abord, installez Office Web Apps Server et ses modules linguistiques sur tous les ordinateurs. N’essayez pas d’installer d’autres logiciels sur les ordinateurs. Ni SharePoint, ni Exchange. Rien d’autre. Si vous voulez partager le matériel, utilisez des ordinateurs virtuels.

Une fois terminé, exécutez la commande Windows PowerShell suivante sur le premier ordinateur de votre batterie (appelons-le Serveur1). Cette commande Windows PowerShell suppose les conditions suivantes :

  • Vous ne configurez que le DNS externe à l’URL https://officewebapps.contoso.com. Il peut s’agir de n’importe quelle URL que vous configurez.
  • Vous configurez une batterie Office Web Apps Server pour prendre en charge la modification et l’affichage.
    Ne le faites que si votre organisation possède les licences appropriées pour la modification. Je n’aborderai pas les détails de licences ici, mais sachez que l’affichage d’Office Web Apps est gratuit contrairement à la modification. Pour plus d’informations, voir Planifier Office Web Apps (utilisé avec les produits SharePoint 2013).
  • Vous arrêtez SSL au niveau du programme d’équilibrage de charge.

Voici la commande Windows PowerShell :

New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded

Vous avez désormais une batterie Office Web Apps Server constituée d’un ordinateur unique.

Voyons maintenant Serveur2. Sur ce serveur, exécutez la commande suivante :

New-OfficeWebAppsMachine -MachineToJoin "Serveur1"

Vous avez à présent une batterie constituée de deux ordinateurs. Répétez l’étape précédente sur Serveur3 et Serveur4.

Connexion à SharePoint

À ce stade, votre batterie de serveurs Office Web Apps est fin prête. Mais elle n’est encore connectée à aucun hôte. Pour connecter une batterie de serveurs SharePoint à cette batterie Office Web Apps Server, ouvrez une invite de commande Windows PowerShell sur l’un des serveurs de la batterie SharePoint et exécutez la commande suivante :

New-SPWopiBinding -ServerName "officewebapps.contoso.com"

Vous devrez aussi exécuter la commande qui suit pour indiquer à la batterie de serveurs SharePoint que vous voulez utiliser l’URL externe de la batterie Office Web Apps Server et qu’elle utilise le protocole HTTPS.

Set-SPWopiZone -Zone "external-https"

Maintenant, vous avez vraiment terminé. Accédez à une bibliothèque de documents de la batterie de serveurs SharePoint et créez, affichez et modifiez des fichiers Office comme vous l’entendez. Aucune autre configuration n’est requise.

Pour finir, si vous voulez déconnecter la batterie Office Web Apps Server de SharePoint, exécutez la commande suivante :

Remove-SPWopiBinding -All

Si vous accédez à une bibliothèque de documents de la batterie de serveurs SharePoint après avoir exécuté cette commande, il n’y aura aucune trace d’Office Web Apps.

Vous pouvez connecter autant de batteries de serveurs SharePoint que vous le souhaitez à une batterie de serveurs Office Web Apps unique. C’est également le cas avec Exchange et Lync. Pour plus d’informations, voir Exchange Server 2013 : Intégration d’Office Web Apps Server et Déploiement d’Office Web Apps Server et Lync Server 2013.

Obtention de mises à jour pour Office Web Apps Server

Depuis le début nous nous efforçons de mettre à jour Office Web Apps fréquemment. Toutefois, nous n’avons distribué nos mises à jour qu’aux clients locaux via des Service Packs. Une fois lancée la version d’Office Web Apps Server 2013, nous prévoyons de mettre à disposition des mises à jour bien plus fréquemment. Nous pensons que les administrateurs pourront s’en charger, car la mise à jour d’Office Web Apps Server est très facile.

Pour mettre à jour des ordinateurs dans une batterie Office Web Apps Server, vous devez supprimer les ordinateurs du programme d’équilibrage de charge et de la batterie de serveurs. Toutefois, ce processus peut être géré de sorte qu’il n’y ait pratiquement aucun impact sur les utilisateurs.
Fondamentalement, si vous avez une batterie de serveurs constituée de 4 ordinateurs, vous retirez deux ordinateurs et vous les mettez à jour. Ensuite vous créez une autre batterie de serveurs avec ces 2 ordinateurs et vous faites pointer le programme d’équilibrage de charge vers ces 2 ordinateurs au lieu des 2 autres de la batterie d’origine. Il ne vous reste plus qu’à mettre à jour les deux ordinateurs restants et les inclure à la nouvelle batterie de serveurs, puis faire pointer le programme d’équilibrage de charge vers ces deux ordinateurs également.

Quand les ordinateurs sont retirés de la batterie de serveurs, certains utilisateurs peuvent constater des contretemps, mais Office Web Apps sera rapidement opérationnel. Cette méthode s’applique dans tous les cas, sauf quand la batterie de serveurs est constituée d’un ordinateur unique (pour des raisons évidentes).

En savoir plus sur Office Web Apps Server

Des ressources supplémentaires pour Office Web Apps Server sont à votre disposition ici :
• Bibliothèque Office Web Apps sur TechNet
• Exchange Server 2013 : Intégration d’Office Web Apps Server
• Déploiement d’Office Web Apps Server et Lync Server 2013
• Forum sur le déploiement et la configuration d’Office Web Apps

Nick Simons
Directeur de programme, Office Web Apps

 

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Introducing Office Web Apps Server