November, 2012

  • Blog Office IT Pro

    Nouveau contenu dans le kit de ressources Office sur la compatibilité et la télémétrie d’Office 2013 destiné aux professionnels de l’informatique

    Article d’origine publié le mercredi 17 octobre 2012

    Nous avons publié une nouvelle affiche Visio et un nouvel article sur la compatibilité et la télémétrie dans Office 2013. Ce sont deux documents de base intéressants pour les professionnels de l’informatique qui recherchent une vue globale sans trop entrer dans les détails.

    L’affiche Visio (disponible également en format PDF et Zoom-it) décrit le fonctionnement d’Office 2013. Vous y trouverez des informations sur les composants de télémétrie, les types de fichiers et solutions surveillés, le processus de surveillance et bien d’autres choses encore.

    Le nouveau guide de compatibilité Office 2013 décrit le processus moderne de compatibilité Office et la façon dont il est pris en charge par la télémétrie Office. Vous y découvrirez des rubriques relatives à la découverte et à l’inventaire, l’importance du travail en collaboration avec des groupes professionnels et comment mener un test d’acceptation de l’utilisateur à l’aide d’Office « Démarrer en un clic », entre autres sujets.


    Comme toujours, nous restons ouverts à tout commentaire et nous vous encourageons à vérifier toutes les semaines la présence de contenu nouveau ou mis à jour.

    Jill

     

     

     

     

    Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page New Office 2013 compatibility and telemetry content for IT Pros in the Office Resource Kit

  • Blog Office IT Pro

    Gestion des compléments à l’aide du tableau de bord de télémétrie

    Article d’origine publié le mercredi 19 septembre 2012

    Ce billet de blog a été écrit par Nobuko Miwa, responsable de programme dans l’équipe de gestion des solutions Office

    VOUS AVEZ TOUJOURS VOULU GÉRER DES COMPLÉMENTS POUR OFFICE ? Si vous êtes un professionnel de l’informatique qui gère l’utilisation des applications, il est probable que vous voulez également gérer les compléments pour Office. Si vous parvenez à empêcher vos utilisateurs d’exécuter des compléments non approuvés qui pourraient entraîner des problèmes ou une baisse de performances, alors vous pourrez réduire les coûts liés au support technique. Avec Office 2013, nous fournissons une nouvelle fonctionnalité qui vous permet de gérer l’utilisation des compléments.

    Grâce au tableau de bord de télémétrie d’Office 2013, vous pouvez surveiller l’utilisation des compléments ainsi que les performances et d’autres problèmes. Les données collectées vous permettent de déterminer les compléments que vous devez gérer. Cet article décrit comment gérer des compléments pour Office à l’aide du tableau de bord de télémétrie.

    GÉRER DES COMPLÉMENTS À L’AIDE DU TABLEAU DE BORD DE TÉLÉMÉTRIE

    Pour commencer, vous devez déployer le tableau de bord de télémétrie. Reportez-vous à cet article TechNet pour plus d’informations sur ce déploiement.

     Une fois la configuration du tableau de bord terminée, accédez à la feuille Solutions du tableau de bord de télémétrie. Dans cette feuille, se trouve un lien nommé Mode Gestion des compléments dans l’angle supérieur droit, comme indiqué dans la capture d’écran ci-dessous. Cliquez sur le lien pour afficher la feuille Gestion des compléments.

    Dans la feuille Gestion des compléments, vous pouvez déterminer les compléments qui doivent être contrôlés en fonction de leur utilisation, du temps de chargement et des problèmes détectés. Une fois que vous avez choisi les compléments à contrôler, suivez les instructions qui s’affichent sur le côté droit de l’écran pour créer un script Windows PowerShell permettant d’appliquer ces paramètres. La capture d’écran suivante représente la feuille Gestion des compléments dans le tableau de bord de télémétrie.

     

    Prenez note des remarques suivantes :

    • Vous aurez besoin d’une autorisation pour créer un objet de stratégie de groupe et l’associer à une unité d’organisation (par ex., un conteneur Active Directory).
    • Si la gestion des compléments n’est pas prise en charge, le bouton est grisé.

    Les applications dans lesquelles vous pouvez gérer des compléments sont : Excel, Word, Outlook, PowerPoint, Project, Publisher, Visio, OneNote, Access, InfoPath.

    Les types de complément pris en charge sont les suivants :

     

    Complément COM

    .dll

    Complément Excel Automation

    .dll

    Complément Excel XLL

    .xll

    Complément Excel

    .xla, .xlam

    Complément Excel RTD

    .dll

    Complément Word

    .dot, .dotm, .dotx, .docm

    Complément PowerPoint

    .ppa, .ppam

     

    Vous pouvez choisir parmi les options de gestion de compléments suivantes :

    • Bloqué : le complément est bloqué et ne peut pas être géré par l’utilisateur final.
    • Toujours activé : le complément est toujours activé et ne peut pas être géré par l’utilisateur final.
    • Autoriser : le complément est autorisé et PEUT être géré par l’utilisateur final.

    Une méthode de gestion des compléments plus restrictive consiste à bloquer tous les compléments non gérés à l’aide des fichiers de modèles d’administration (admx) d’Office 2013, puis à utiliser le paramètre Autoriser décrit plus haut pour autoriser les utilisateurs à se servir uniquement des compléments spécifiés. Il existe des paramètres individuels de gestion des compléments pour chaque application Office 2013 prise en charge. Ils sont situés aux emplacements suivants :

    • User Configuration/Administrative Templates/Office 2013 nom de l’application/Miscellaneous/List of managed add-ins
    • User Configuration/Administrative Templates/Office 2013 nom de l’application/Miscellaneous/Block all unmanaged add-ins

    Une fois que vous avez généré le script Windows PowerShell dans la feuille Gestion des compléments, vous pouvez l’exécuter dans le Module Active Directory pour Windows PowerShell. Dans la console, spécifiez le nom de l’objet de stratégie de groupe auquel appliquer les paramètres, comme indiqué dans la capture d’écran suivante :

    Vous pouvez maintenant associer l’objet de stratégie de groupe créé à n’importe quelle unité d’organisation.

    DÉCOUVRIR COMMENT SONT GÉRÉS LES COMPLÉMENTS POUR OFFICE

    Voyons comment vous gérez les compléments dans votre client Office. Ouvrez la boîte de dialogue Compléments COM sur vos ordinateurs clients Office en appliquant la procédure suivante :

    1. Sélectionnez Fichier, puis Options.
    2. Dans la boîte de dialogue Options Application, sélectionnez Compléments.
    3. Dans la liste déroulante Gérer, sélectionnez Compléments COM, puis cliquez sur Atteindre.

    Vous pouvez constater que les compléments sont désactivés et contrôlés par l’administrateur. Les utilisateurs finaux n’ont pas la possibilité de réactiver le complément sur leurs ordinateurs, comme le montre la capture d’écran suivante :

    Si la stratégie de groupe n’est pas encore appliquée, vous pouvez utiliser la commande suivante à l’invite de commande pour déclencher le processus de mise à jour :

    gpupdate /force

     

    Nobuko

     

    Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à l’adresse Let's manage add-ins using Telemetry Dashboard

  • Blog Office IT Pro

    Configurer rapidement le tableau de bord de télémétrie sur un ordinateur de groupe de travail ou appartenant à un domaine

    Article d’origine publié le mercredi 26 septembre 2012

    Ce billet de blog a été écrit par Junko Kyomasu, responsable de programme dans l’équipe de gestion des solutions Office 

    Le tableau de bord de télémétrie Office est un nouvel outil puissant permettant de gérer des documents et des compléments Office dans votre organisation. Il simplifie la procédure de mise à jour de votre Office existant vers Office 2013. Nous sommes heureux de constater que bon nombre d’entre vous ont essayé les fonctionnalités de télémétrie avec Office 2013, mais certains nous ont fait part de leur désir de tester les composants du tableau de bord dans un environnement de groupe de travail, ce qui n’était pas pris en charge jusqu’à présent. La configuration du Registre pour activer les rapports immédiats sur les données peut aussi s’avérer compliquée.

    Pour que votre évaluation soit plus facile et plus rapide, nous avons publié un script Windows PowerShell, Deploy-TelemetryDashboard.ps1, qui configurera tous les composants à la fois ! Vous pouvez exécuter le script pour installer les composants sur un seul ordinateur de groupe de travail ou sur un ordinateur appartenant à un domaine. Le script permet aussi à l’agent de télémétrie intégré de commencer immédiatement à générer des rapports sur les données. Ce script est le seul moyen permettant de configurer les composants du tableau de bord dans un groupe de travail.

    Pour les environnements de production qui contiennent des centaines ou des milliers d’ordinateurs clients, vous pouvez déployer chaque composant pas à pas comme décrit dans Déployer le tableau de bord de télémétrie Office.

    Comment exécuter Deploy-TelemetryDashboard.ps1

    Téléchargez Deploy-TelemetryDashboard.ps1 et TDDB.bak depuis la Galerie TechNet et exécutez Deploy-TelemetyDashboard.ps1 sur l’ordinateur sur lequel est installé Office 2013.

    C’est tout !

    Le script vous permet de configurer le tableau de bord de télémétrie sur votre ordinateur et les données de télémétrie lui seront retournées immédiatement.

    Quel est le rôle de Deploy-TelemetryDashboard.ps1

    Le script configure tous les composants nécessaires pour commencer à utiliser le tableau de bord de télémétrie. Vous devez l’exécuter sur un ordinateur équipé des éditions Office Professionnel Plus 2013 ou Office 365 ProPlus d’Office 2013.

    Le script effectue les tâches suivantes : 

    1. Créer 2 groupes locaux (groupe de travail uniquement) : pour autoriser un accès sécurisé au dossier partagé et à la base de données, le script crée 2 groupes locaux sur un ordinateur et ajoute l’utilisateur actuellement connecté aux groupes. Ces groupes sont :

    TDAgent : groupe local qui aura accès au dossier partagé

    TDDatabase : groupe local qui aura accès à la base de données

    2. Créer un autre dossier partagé : emplacement dans lequel les ordinateurs clients Office téléchargent les données de télémétrie.

    TDShared : dossier local créé à la racine du lecteur système (par ex., C:\TDShared)

    3. Installer le service du processeur de télémétrie Office : le service traite les données téléchargées depuis l’ordinateur client et les insère dans la base de données.

    *4. Restaurer la base de données de télémétrie (groupe de travail uniquement) : le script restaure une base de données vide.

    *Remarque : pour un ordinateur appartenant à un domaine, le script lance l’Assistant Paramètres du processeur de télémétrie Office au lieu de restaurer une base de données vide. Vous pouvez créer une autre base de données en suivant l’Assistant Paramètres.

    5. Configurer l’agent de télémétrie : l’agent de télémétrie est intégré aux éditions Office Professionnel Plus 2013 et Office 365 ProPlus d’Office 2013. Le script écrit des valeurs de Registre qui permettent à l’agent de collecter et télécharger des données. Reportez-vous à l’Agent de télémétrie Office pour plus d’informations sur les valeurs de Registre.

    6. Exécuter la tâche de l’agent : l’agent de télémétrie est déclenché par la tâche planifiée. Le script exécute la tâche de l’agent (Microsoft\Office\OfficeTelemetryAgentLogOn) manuellement de sorte que l’agent collecte et télécharge des données de télémétrie dans le dossier partagé.

    7. Lancer le tableau de bord de télémétrie : une fois que tous les paramètres ont été déployés correctement et que l’agent a téléchargé les données de télémétrie, le script lance le tableau de bord de télémétrie.

    8. Exporter des valeurs de Registre de l’agent : vous pouvez exporter des paramètres de Registre pour que l’agent les envoie à d’autres ordinateurs clients Office qui possèdent un agent de télémétrie.

    Nous espérons que ce script Windows PowerShell vous aidera à configurer sans problème les fonctionnalités de télémétrie Office, et que vous pourrez obtenir les données de télémétrie dont vous avez besoin pour effectuer sans crainte la mise à jour vers Office 2013 et ainsi commencer à tirer parti de ses nombreuses fonctionnalités exceptionnelles.

    Vos questions et commentaires sur ce script sont les bienvenus. Vous pouvez les ajouter à ce billet ou à l’onglet Questions-Réponses de la Galerie TechNet.

     

    Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à l’adresse Quickly set up Office Telemetry Dashboard on a workgroup or domain-joined computer

  • Blog Office IT Pro

    Ce que les professionnels de l’informatique doivent savoir au sujet du nouveau format de fichier VSDX dans Visio 2013

    Article d’origine publié le samedi 27 octobre 2012

    Vous devez savoir maintenant que l’une des nouveautés de Visio 2013 est le format de fichier XML, VSDX, permettant d’obtenir de nouvelles fonctionnalités dans Visio, telles que la co-création et d’améliorer l’interopérabilité avec d’autres applications. Si vous ne le saviez pas, vous trouverez des informations intéressantes dans le billet du Blog Visio VSDX : le nouveau format de fichier Visio. Si vous voulez en savoir plus sur les détails techniques du format VSDX, voir Présentation du format de fichier Visio 2013 (.vsdx) et Procédure : manipuler le format de fichier Visio 2013 par programme sur MSDN.

    Nos professionnels de l’informatique se rappellent probablement des difficultés de la migration du format de fichier binaire Office 2003 vers le format de fichier OpenXML utilisé dans Office 2007 et les versions ultérieures. Avec Visio 2013, vous pourrez rencontrer des difficultés similaires, cependant nous avons de bonnes raisons de croire que la migration est un pas dans la bonne direction. Ce nouveau format VSDX présente de nombreux avantages, y compris des tailles de fichier moins volumineuses, une restauration des données améliorée et une interopérabilité simplifiée.

    Nouveaux types de fichier dans Visio 2013

    Visio possède trois types de fichier principaux : les dessins, les modèles et les gabarits. Ces types de fichier sont toujours disponibles dans le nouveau format, à une différence près : tout comme les autres applications Office, nous offrons désormais des formats sans macros et d’autres prenant en charge les macros. Les nouvelles extensions de chaque fichier sont répertoriées dans le tableau ci-dessous.

     

    Sans macros

    Prenant en charge les macros

    Dessin

    VSDX

    VSDM

    Modèle

    VSTX

    VSTM

    Gabarit

    VSSX

    VSSM

     

    Fonctionnalités de compatibilité dans Visio 2013

    Visio 2013 fournit plusieurs fonctionnalités de compatibilité pour aider les utilisateurs à passer de l’ancien au nouveau format. Parmi ces fonctionnalités, on trouve notamment :

    • Un mode de compatibilité pour ouvrir des dessins VSD dans Visio 2013.
    • Un bouton de conversion qui convertit les dessins VSD en VSDX.
    • Un vérificateur de compatibilité pour aider les utilisateurs à enregistrer les nouveaux dessins sous l’ancien format VSD.

    Les utilisateurs peuvent obtenir plus d’informations sur les nouvelles fonctionnalités de compatibilité dans les articles suivants sur Office.com :

    Définition du type de fichier par défaut dans Visio 2013 à l’aide de la stratégie de groupe

    Par défaut, Visio 2013 enregistre les fichiers au format VSDX. Ce qui est acceptable si tous les utilisateurs possèdent Visio 2013. Mais si certains d’entre eux continuent à utiliser d’anciennes versions de Visio, vous pouvez utiliser la stratégie de groupe pour définir le type de fichier par défaut dans Visio 2013 sur VSD. Le paramètre de stratégie de groupe Enregistrer les fichiers Visio en tant que est disponible dans les fichiers de modèles d’administration Office 2013 (ADMX/ADML) et l’outil de personnalisation Office. Recherchez le paramètre sous User Configuration\Administrative Templates\Microsoft Visio 2013\Visio Options\Save\Save Documents.

    Les formats de fichier que vous pouvez définir en tant que type de fichier par défaut pour Visio 2013 sont les suivants :

    • Document Visio : format VSDX (il s’agit du format par défaut)
    • Document Visio prenant en charge les macros : format VSDM
    • Document Visio 2003-2013 : format VSD

     

    Comme d’habitude, laissez-nous un commentaire si vous avez des suggestions de contenu destiné aux professionnels de l’informatique sur Visio 2013.

    --Jill

     

     

    Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page What IT Pros need to know about the new VSDX file format in Visio 2013

  • Blog Office IT Pro

    Présentation d’Office Web Apps Server

    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 (http://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

  • Blog Office IT Pro

    Présentation du journal de télémétrie dans Office 2013

    Article d’origine publié le mercredi 7 novembre 2012

    Ce billet a été écrit par David Matsumoto, responsable de programme dans l’équipe de gestion de solutions Office

     Dans nos derniers billets de blog, nous avons abordé les fonctionnalités de la télémétrie Office, une nouveauté d’Office 2013. Vous avez peut-être déjà lu des billets de blog détaillés au sujet du tableau de bord de télémétrie et avec un peu de chance vous avez même pu commencer à l’utiliser.

    Dans ce billet de blog, nous allons aborder le journal de télémétrie pour Office 2013, installé avec le tableau de bord de télémétrie. Nous allons découvrir quel est son objectif et comment optimiser son utilisation.

    Pourquoi utiliser le journal de télémétrie ?

    Le journal de télémétrie permet aux utilisateurs finaux de mettre en évidence les problèmes de compatibilité rencontrés avec certaines applications* Office 2013 sur leur ordinateur client local. Pour sa part, le tableau de bord de télémétrie s’adresse aux professionnels de l’informatique en entreprise et leur permet de recueillir des informations d’utilisation et de télémétrie à travers l’organisation, et de les présenter sous forme d’une vue unique. Le journal de télémétrie affiche le même genre d’informations par utilisateur sur l’ordinateur de l’utilisateur.

    Quand la journalisation de télémétrie est activée, chaque fois que l’utilisateur ouvre ou ferme un fichier ou une solution dans Office 2013, un événement est enregistré dans un magasin de données local sur l’ordinateur client. En cas d’erreurs, même les plus évidentes, elles sont enregistrées dans le magasin de données local avec les informations relatives à l’utilisateur et à l’ordinateur. Dans certains cas, les erreurs sont mappées à des problèmes de compatibilité connus qui peuvent être affichés dans le journal de télémétrie.

    *Pour obtenir une liste des fichiers et solutions Office faisant l’objet d’un suivi dans le journal de télémétrie, voir le Tableau 1 de la section Fonctionnement du journal de télémétrie.

    Mise en route

    Si vous avez installé Office 2013 sur Windows 8, il vous suffit d’effectuer un balayage vers le haut pour afficher la barre de l’application. Choisissez Toutes les applications, puis Journal de télémétrie pour Office 2013. (Pour Windows 7, choisissez Tous les programmes, puis dans la liste des programmes, développez successivement Microsoft Office 2013 et Outils Office 2013, puis choisissez Journal de télémétrie pour Office 2013.).

    Quand vous lancez le journal de télémétrie, un nouveau classeur s’ouvre dans Excel 2013. Il contient trois feuilles intitulées Événements, Infos système et Guide.

    Cliquez sur la feuille Guide, puis sur le bouton vert pour activer la journalisation :

    Vous avez terminé la configuration ! À chaque fois que vous ouvrirez un document ou une solution Office 2013, ils seront immédiatement suivis dans le journal de télémétrie. Essayez maintenant d’ouvrir et de fermer un document ou de charger une solution. Ensuite, accédez à la feuille Événements et cliquez sur le bouton Actualiser dans l’angle supérieur droit du volet d’en-tête. Vous observerez une ou plusieurs lignes correspondant à tous les événements qui se sont produit quand vous avez ouvert et fermé ce document ou cette solution. Vous pouvez les vérifier en examinant plusieurs colonnes de la feuille Événements. (Voir l’exemple de la Figure 1 ci-dessous.).

    Par exemple, dans la feuille Événements, vous obtenez les informations suivantes :

    • la date et l’heure du chargement du fichier ;
    • le nom du fichier ;
    • l’application (par ex., Word, Excel, PowerPoint, etc.) qui a été lancée ;
    • l’emplacement à partir duquel le fichier a été chargé.

    Figure 1: Journal de télémétrie (vue Événements)

     

    La feuille Infos système vous indique aussi si le journal de télémétrie est activé ou non.

    Remarque : si votre ordinateur client s’exécute dans un environnement géré, votre administrateur informatique a peut-être déjà configuré votre ordinateur pour qu’il active la journalisation de télémétrie de sorte que les données soient téléchargées dans la base de données et signalées dans le tableau de bord de télémétrie.

     

    Comment optimiser l’utilisation du journal de télémétrie ?

    Le journal de télémétrie est particulièrement utile pour les utilisateurs et testeurs expérimentés qui souhaitent examiner les problèmes liés aux documents ou solutions et découvrir la procédure de correction appropriée.

    Prenons l’exemple suivant, dans lequel le journal de télémétrie sert à dépanner des problèmes liés à un document (également applicable aux problèmes liés à une solution) :

    1. Un testeur charge deux documents (par ex., CalendarControl_report.xls et ConfidentialityAgreement_template.docx), il tente d’exécuter des contrôles (ou macros, etc.) qui présentent des problèmes. (Notez que les contrôles doivent être exécutés pour que les éventuels problèmes soient effectivement déclenchés et enregistrés dans le journal de télémétrie).

    2. Le testeur lance le journal de télémétrie et examine la feuille Événements pour localiser les documents en cours d’utilisation. Il repère une erreur et un avertissement générés pour ces deux fichiers, ainsi qu’une explication de la cause potentielle du problème. (Voir l’exemple mis en évidence dans la Figure 2 ci-dessous).

    Figure 2 : Journal de télémétrie : exemple de la vue Événements contenant l’erreur et/ou l’avertissement et une explication

    3. Il clique sur le lien situé sous la colonne Plus d’infos correspondant au problème qu’il examine (dans notre cas, le document ConfidentialityAgreement_template.docx). Il affiche des informations supplémentaires disponibles sur MSDN, qu’il peut explorer en détails et parmi lesquelles il trouve des informations utiles pour que son développeur puisse corriger le problème. (Voir l’exemple mis en évidence dans la Figure 3 ci-dessous).

    Figure 3 : Recherche d’informations supplémentaires sur MSDN

     

    4. Une fois que le développeur a corrigé le problème, le testeur ouvre une copie mise à jour du fichier et constate qu’aucun problème n’a été enregistré dans le journal de télémétrie.

    Résumé

    Dans ce billet de blog, nous avons expliqué quel est l’objectif du journal de télémétrie et abordé sa mise en route. Nous avons également vu comment les utilisateurs finaux, en particulier les développeurs et les testeurs, peuvent optimiser son utilisation.

     

    Ressources supplémentaires
    Centre pour développeurs Office

    Guide de référence pour l’utilisation du journal de télémétrie

    Problèmes de compatibilité dans Office 2013

     

     

     

     

     

    Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Introducing Telemetry Log in Office 2013.

Page 1 of 1 (6 items)