Artículo original publicado el martes, 11 de septiembre de 2012
El autor de esta publicación es Nick Simons, administrador jefe de programas de Office Web Apps.
En el verano de 2010, presentamos Office Web Apps: versiones de Word, PowerPoint, Excel y OneNote basadas en el explorador. Lanzamos estos productos como un conjunto de aplicaciones de SharePoint. Los clientes que querían implementar Office Web Apps en sus propias redes tenían que instalar Office Web Apps en servidores de SharePoint.
En aquel momento, una integración íntima con SharePoint nos pareció lo mejor. A todas luces, SharePoint era y es un pilar de la historia de Office Web Apps. Además, SharePoint tiene un modelo bien definido para integrar aplicaciones como Office Web Apps. Sin embargo, mientras planeábamos la siguiente versión de Office Web Apps, nos dimos cuenta de que sería difícil lograr algunos de nuestros principales objetivos con una arquitectura tan íntimamente ligada a SharePoint.
Queríamos simplificar la planeación de la capacidad y la configuración, así como habilitar la federación en varias granjas de servidores. También queríamos satisfacer las solicitudes de integración de nuevos socios, como Lync. Finalmente, muchos de nuestros clientes, tanto de Office 365 como locales, nos dijeron que querían las mismas mejoras de las que disfrutaban los usuarios de SkyDrive de manera regular.
Para alcanzar estos objetivos, volvimos al principio y nos replanteamos de qué forma se podría integrar Office Web Apps con otros productos ahora y en el futuro. Creamos un modelo nuevo que aislaba Office Web Apps de todas las tecnologías específicas de nuestros socios. Al final, nuestro modelo suponía una carga de codificación relativamente ligera para los hosts de archivos, como SharePoint, y nos permitía usar Office Web Apps en servidores totalmente independientes.
Este nuevo producto de servidor independiente es Office Web Apps Server.
Sabemos que, al principio, puede parecer que la idea de tener un tipo adicional de servidor representa una complicación añadida y una pesada carga para el administrador, pero verá que con esta plataforma independiente conseguimos...
1. Una instalación más sencilla
2. Un proceso de actualización y un mantenimiento totalmente independientes de SharePoint
3. La integración de varias granjas de servidores de SharePoint en una única granja de servidores de Office Web Apps Server
4. La integración de otros productos, como Exchange, Lync y productos de otros fabricantes, en Office Web Apps
5. La entrega de nuevas características y mejoras a nuestros clientes basados en web y locales prácticamente al mismo tiempo
Si comparamos las implementaciones anteriores de Office Web Apps en SharePoint 2010 con las nuevas implementaciones en Office Web Apps Server, las ventajas se hacen patentes.
Con la versión anterior de Office, una implementación normal de Office Web Apps era algo parecido a esto...
La versión anterior de Office Web Apps se tenía que instalar en cada una de las granjas de servidores y en todas las máquinas de cada granja. Además, el escalado de Office Web Apps dependía del escalado global de SharePoint y, para actualizar Office Web Apps, había que actualizar código en todas las máquinas de todas las granjas de servidores de SharePoint.
Con Office Web Apps Server, la implementación debería parecerse más a esto...
Como puede ver, una sola granja de servidores de Office Web Apps Server puede atender a varias granjas de servidores de SharePoint 2013, además de a Lync 2013 y a Exchange 2013 (Outlook Web Access). Además, puede usar la granja de servidores de Office Web Apps para ver cualquier archivo de Word, Excel y PowerPoint que sea accesible a través de una dirección URL o una UNC.
A continuación, se describe cómo se integra Office Web Apps con un host de archivos como SharePoint a alto nivel. Esta información le ayudará a entender los requisitos de red y de seguridad que se detallan más adelante.
Para empezar, lea estas definiciones:
Un componente clave del nuevo modelo de integración es la nueva API pública que Office Web Apps usa para comunicarse con los hosts. Esta API se denomina WOPI (Interfaz de plataforma abierta de aplicación web). Office Web Apps Server busca y manipula archivos con la WOPI API. A menudo, describimos Office Web Apps Server como una aplicación WOPI. Los hosts deben entender las solicitudes WOPI de las aplicaciones WOPI.
WOPI es una API de RESTful que usa HTTP/HTTPS. Esto significa que, entre otras cosas, todo el tráfico transferido entre los hosts y Office Web Apps Server viaja a través de puertos HTTP/HTTPS estándar. También quiere decir que, en la medida de lo posible, Office Web Apps Server no tiene estado, lo que lo hace más resistente a diversos errores, desde interrupciones en la red hasta errores globales de hardware.
Para comprender el funcionamiento de la WOPI, vamos a explorar un escenario sencillo en el que un usuario, Pilar, ve el archivo prueba.docx, que está hospedado en SharePoint. El proceso es el siguiente...
1. Pilar navega hasta la biblioteca de documentos donde está almacenado prueba.docx.
2. En la biblioteca de documentos, Pilar hace clic en el nombre del archivo.
3. SharePoint navega por el explorador hasta llegar a una página especial de SharePoint que puede enviar solicitudes a Office Web Apps Server (y a otras aplicaciones WOPI). A esta página de SharePoint la llamaremos WOPIFrame.aspx.
4. WOPIFrame.aspx contiene un iframe (http://dev.w3.org/html5/spec/the-iframe-element.html) que navega hasta una página ubicada en Office Web Apps Server. A esta página la llamaremos WordViewer.aspx. La solicitud HTTP enviada a WordViewer.aspx incluye algunos datos importantes:
5. Office Web Apps Server usa el origen de la WOPI y el token de acceso para bajar prueba.docx de SharePoint.
6. WordViewer.aspx muestra prueba.docx en el iframe de WOPIFrame.aspx.
En este dibujo se ilustra el flujo de datos entre el explorador, SharePoint y Office Web Apps Server:
En este caso, una granja de servidores puede representar desde una máquina virtual que funciona en un servidor compartido hasta una granja de servidores con docenas de servidores de centros de datos. La configuración y el mantenimiento básicos son iguales en todos los casos. Los pasos y los requisitos previos concretos para crear una granja de servidores se incluyen con el producto, así que no los voy a explicar aquí. Lo que sí voy a hacer es describir con cierto nivel de detalle lo que implica el proceso.
En primer lugar, va a necesitar algunas máquinas. Supongamos que va a configurar una granja de servidores que atienda las necesidades de 80.000 usuarios de varias granjas de servidores de SharePoint. Creemos que posiblemente necesite 4 servidores con:
También vamos a necesitar un equilibrador de carga. Tenemos una granja de servidores con 10 máquinas configurada en Microsoft que comparte un equilibrador de carga de hardware F5 BIG-IP con varios productos de otros servidores. Esta disposición funciona muy bien y cualquier solución buena de equilibrio de carga valdrá. La única recomendación que se debería seguir es que la solución de equilibrio de carga admita afinidad. Para el rendimiento, es muy útil que el mismo servidor atienda todas las solicitudes de una determinada sesión.
Vamos a suponer que quiere que los usuarios puedan acceder a Office Web Apps desde la red interna y desde Internet. Si es el caso, en la granja de servidores deberá configurar tanto el DNS interno como el externo. O, si lo prefiere, puede configurar solo el DNS externo y usar reglas de DNS interno para que las solicitudes internas se queden en la red privada. Esto es lo que yo haría.Pero la red es suya, así que la puede configurar como considere oportuno. Lo que necesitamos es lo siguiente:
Es fundamental asegurarse de que estas rutas de red estén correctamente configuradas. Office Web Apps es relativamente simple, pero solo funciona cuando los canales de comunicación están abiertos.
Como apunté en la sección anterior, la solicitud inicial para representar o modificar un archivo incluye las credenciales del usuario en el token de acceso, que, a su vez, se incluye en todas las solicitudes que Office Web Apps envía a los hosts. Todo este tráfico se debe proteger con SSL a menos que esté en una red privada y confíe en todos los usuarios que tengan acceso a la red. No, no es cierto: aun así debería usar SSL. De verdad.Configurar SSL exige crear certificados y ponerlos en cada una de las máquinas de Office Web Apps Server o en el equilibrador de carga. Si elige colocar la SSL en el equilibrador de carga, puede usar las configuraciones específicas que hay en Office Web Apps Server y que explicaré dentro de un momento.
Ahora que toda la infraestructura de red y hardware está configurada, es hora de crear la granja de servidores de Office Web Apps Server. Primero instale Office Web Apps Server y los paquetes de idioma en todas las máquinas. No intente instalar otro software en las máquinas: ni SharePoint, ni Exchange ni ningún otro. Si quiere compartir hardware, use máquinas virtuales.
Cuando haya hecho esto, ejecute el siguiente Windows PowerShell en la primera máquina de la granja de servidores (la llamaremos Servidor1). Este Windows PowerShell presupone que...
El Windows PowerShell es este:
New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded
Ahora tiene una granja de servidores de Office Web Apps Server con una sola máquina.
Una vez hecho esto, pase al Servidor2 y ejecute lo siguiente:
New-OfficeWebAppsMachine -MachineToJoin "Server1"
Ahora tiene una granja de servidores con dos máquinas. Repita el paso anterior para agregar el Servidor3 y el Servidor4.
Llegados a este punto, la granja de servidores de Office Web Apps ya está lista, pero todavía no está conectada a ningún host. Para conectar una granja de servidores de SharePoint a esta granja de servidores de Office Web Apps Server, abra un símbolo del sistema de Windows PowerShell en cualquier servidor de la granja de servidores de SharePoint y ejecute lo siguiente:
New-SPWopiBinding -ServerName "officewebapps.contoso.com"
También tendrá que ejecutar el comando siguiente para decirle a la granja de servidores de SharePoint que quiere usar la dirección URL externa de la granja de servidores de Office Web Apps Server y que la dirección usa HTTPS.
Set-SPWopiZone -Zone "external-https"
Ahora sí que está todo preparado. Navegue hasta una biblioteca de documentos de la granja de servidores de SharePoint y cree, vea o edite todos los archivos de Office que quiera. No tiene que configurar nada más.
Por último, si quiere desconectar la granja de servidores de Office Web Apps Server de SharePoint, ejecute lo siguiente:
Remove-SPWopiBinding -All
Si ahora va a una biblioteca de documentos de la granja de servidores de SharePoint, no quedará ni rastro de Office Web Apps.
Puede conectar todas las granjas de servidores de SharePoint que quiera a una única granja de servidores de Office Web Apps. Esto mismo se aplica cuando se conectan Exchange y Lync a una granja de servidores de Office Web Apps. Para más información, vea Exchange Server 2013: Integración de Office Web Apps Server e Implementación de Office Web Apps Server y Lync Server 2013.
Desde el principio nos comprometimos a ofrecer actualizaciones frecuentes de Office Web Apps, pero solo las entregábamos a clientes locales a través de Service Packs. Después del lanzamiento de Office Web Apps Server 2013, pensamos proporcionar actualizaciones con mucha más frecuencia y creemos que los administradores podrán con ello porque actualizar Office Web Apps Server es muy fácil.
Para actualizar las máquinas de una granja de servidores de Office Web Apps Server, tendrá que quitar máquinas del equilibrador de carga y de la granja de servidores, pero este proceso se puede administrar de tal forma que no afecte a los usuarios prácticamente en nada.Explicado brevemente, si tiene una granja de servidores con 4 máquinas, saque 2 y actualícelas. Luego cree una granja de servidores nueva con estas 2 máquinas y apunte el equilibrador de carga hacia estas 2 máquinas en lugar de hacia las 2 de la granja de servidores original. Ahora actualice las 2 máquinas restantes, únalas a la granja de servidores nueva y apunte el equilibrador de carga también hacia estas máquinas.
Es posible que, cuando las máquinas se saquen de la granja de servidores, algunos usuarios encuentren pequeños problemas, pero Office Web Apps se recuperará siempre, salvo en los casos en que exista una sola máquina (por razones obvias).
Encontrará recursos adicionales sobre Office Web Apps Server aquí:• Biblioteca de Office Web Apps Preview en TechNet• Exchange Server 2013: Integración de Office Web Apps Server• Implementación de Office Web Apps Server y Lync Server 2013• Foro de configuración e implementación de Office Web Apps
Nick SimonsAdministrador principal de programas, Office Web Apps
Esta publicación del blog es una traducción. Puede leer el artículo original en Introducing Office Web Apps Server
Artículo original publicado el sábado, 27 de octubre de 2012
Puede que ya sepa que Visio 2013 ha introducido un formato de archivo basado en XML, el formato VSDX, para ofrecer nuevas funciones en Visio, como la co-autoría, y mejorar la interoperabilidad con otras aplicaciones. Si acaba de enterarse, encontrará información muy completa en la publicación VSDX: El nuevo formato de archivo de Visio del Blog de Visio. Si quiere profundizar en los detalles técnicos del formato VSDX, vea Introducción al formato de archivo de Visio 2013 (.vsdx) y Cómo manipular el formato de archivo de Visio 2013 mediante programación en MSDN.
Es posible que nuestros profesionales de TI recuerden el desafío que supuso la migración del formato de archivo binario de Office 2003 al formato de archivo OpenXML usado en Office 2007 y versiones posteriores. Con Visio 2013 se presentarán desafíos parecidos, pero creemos que estará de acuerdo en que la migración merece la pena. El nuevo formato VSDX aporta muchas ventajas, como tamaños de archivos más reducidos, una recuperación de datos mejorada y una interoperabilidad más sencilla.
Tipos de archivos nuevos de Visio 2013
Visio tiene tres tipos principales de archivos: dibujos, plantillas y galerías de símbolos. Estos tipos de archivos siguen estando disponibles en el formato nuevo, aunque hay una diferencia: al igual que las otras aplicaciones de Office, ahora ofrecemos formatos sin macros y formatos habilitados para macros. Las nuevas extensiones de cada tipo de archivo se recogen en la tabla siguiente.
Sin macros
Habilitado para macros
Dibujo
VSDX
VSDM
Plantilla
VSTX
VSTM
Galería de símbolos
VSSX
VSSM
Características de compatibilidad de Visio 2013
Visio 2013 ofrece varias características de compatibilidad que ayudan a los usuarios en la transición del formato antiguo al nuevo. Entre estas características se incluyen:
Los usuarios encontrarán más información sobre las nuevas características de compatibilidad en los artículos siguientes publicados en Office.com:
De forma predeterminada, Visio 2013 guarda los archivos con el formato VSDX. Esto no supone ningún problema si todos los usuarios usan Visio 2013. Si algunos de los usuarios van a seguir usando versiones anteriores de Visio, puede usar Directiva de grupo para establecer que el tipo de archivo predeterminado de Visio 2013 sea VSD. La configuración Guardar archivos de Visio como de Directiva de grupo está disponible en los archivos de plantilla administrativa de Office 2013 (ADMX/ADML) y la Herramienta de personalización de Office. Busque la configuración en Configuración de usuario\Plantillas administrativas\Microsoft Visio 2013\Opciones de Visio\Guardar\Guardar documentos.
Estos son los formatos de archivo que puede establecer como tipo de archivo predeterminado en Visio 2013:
Como siempre, no dude en dejarnos un comentario si tiene alguna sugerencia de contenido para profesionales de TI relacionado con Visio 2013.
Jill
Esta publicación del blog es una traducción. Puede leer el artículo original en inglés en What IT Pros need to know about the new VSDX file format in Visio 2013
Artículo original publicado el miércoles, 7 de noviembre de 2012
El autor de esta publicación es David Matsumoto, administrador de programas del equipo de administración de soluciones de Office
En nuestras últimas publicaciones del blog, hemos hablado de las características de telemetría de Office que se han introducido en Office 2013. A lo mejor ha leído algunas publicaciones en el blog que describían el Panel de telemetría con más detalle y, con suerte, puede que haya tenido la oportunidad de empezar a usarlo.
En esta publicación del blog vamos a hablar del Registro de telemetría para Office 2013, que se instala con el Panel de telemetría. Explicaremos la finalidad del Registro de telemetría y cómo sacarle el máximo provecho. ¡Empecemos!
Registro de telemetría permite a los usuarios finales descubrir los problemas de compatibilidad que surgen en determinadas aplicaciones de Office 2013* en los equipos cliente locales. Mientras que Panel de telemetría está diseñado para que los profesionales de TI de las empresas recopilen información de uso y telemetría de las organizaciones y la acumulen en una sola vista, Registro de telemetría muestra el mismo tipo de información por usuario en el equipo del usuario.
Al habilitar Registro de telemetría, cada vez que el usuario abre o cierra un archivo o una solución en Office 2013, se registra un evento en un almacén de datos local ubicado en el equipo cliente. Los errores que se puedan encontrar, aunque no sean obvios, se registrarán con la información del usuario y el equipo en el almacén de datos local. Cuando es posible, los errores se asignan a problemas de compatibilidad conocidos que se pueden mostrar en el Registro de telemetría.
*En la tabla 1 del apartado Funcionamiento de Registro de telemetría puede consultar la lista de los archivos y las soluciones de Office que se registran en el Registro de telemetría.
Si ha instalado Office 2013 en Windows 8, desplace rápidamente el dedo hacia arriba para abrir la barra de aplicaciones y elija Todas las aplicaciones y luego Registro de telemetría de Office 2013. (Si lo ha instalado en Windows 7, elija Todos los programas. Luego, en la lista de programas, expanda Microsoft Office 2013 y Herramientas de Office 2013, y elija Registro de telemetría de Office 2013).
Al iniciar Registro de telemetría, se abre un libro nuevo en Excel 2013. Este libro tiene tres hojas de cálculo tituladas Eventos, Información del sistema y Guía.
Haga clic en la hoja de cálculo Guía y luego en el botón verde para habilitar el registro:
¡Listo! Cuando abra un documento o una solución en Office 2013, estos se registrarán inmediatamente en el Registro de telemetría. Pruebe a abrir y cerrar un documento, o subir una solución. Luego navegue hasta la hoja de cálculo Eventos y haga clic en el botón Actualizar que hay arriba a la derecha en el panel de encabezado. Verá una o varias filas que representan todos los eventos que se produjeron al abrir y cerrar el documento o la solución. Puede comprobar esto consultando varias de las columnas de la hoja de cálculo Eventos. (Vea el ejemplo de la Ilustración 1 abajo).
Por ejemplo, en la hoja de cálculo Eventos, verá lo siguiente:
Ilustración 1: Registro de telemetría (vista Eventos)
También puede comprobar si el Registro de telemetría está habilitado en el equipo haciendo clic en la hoja de cálculo Información del sistema: aquí verá si Registro de telemetría está habilitado o no.
Nota: Si alguno de los equipos cliente está funcionando en un entorno administrado, es posible que el administrador de TI ya haya aprovisionado el equipo para habilitar el Registro de telemetría de forma que los datos se puedan subir a la base de datos y se puedan crear los informes correspondientes en el Panel de telemetría.
Registro de telemetría resulta especialmente útil para evaluadores y usuarios con experiencia que quieran investigar problemas con documentos o soluciones para averiguar las medidas correctoras adecuadas.
Observe el ejemplo siguiente, donde se usa Registro de telemetría para solucionar problemas con un documento (también es aplicable a la solución de problemas con soluciones):
1. Un evaluador ha subido un par de documentos (por ejemplo, CalendarControl_report.xls y ConfidentialityAgreement_template.docx) y ha intentado ejecutar los controles (o las macros, etc.) que están provocando problemas. (Recuerde que los controles se deben ejecutar para que los problemas se desencadenen y se puedan registrar en el Registro de telemetría).
2. Un evaluador inicia Registro de telemetría y mira en la hoja de cálculo Eventos para encontrar los documentos que se están usando. El evaluador ve que hay un error y una advertencia en estos archivos; también puede ver la explicación correspondiente sobre la posible causa del problema. (Vea el ejemplo resaltado abajo en la Ilustración 2).
Ilustración 2: Registro de telemetría: ejemplo de la vista Eventos con error/advertencia de los documentos y la explicación
3. El evaluador hace clic en el vínculo de la columna Más información, que hace referencia al problema que está investigando (en este caso, el del documento ConfidentialityAgreement_template.docx). Ve que hay información más detallada disponible en MSDN, que puede explorar en profundidad para encontrar información útil para el desarrollador a la hora de corregir el problema. (Vea el ejemplo resaltado en rojo abajo en la Ilustración 3).
Ilustración 3: Explorar en profundidad en MSDN para más información
4. Cuando un desarrollador arregla el problema, el evaluador abre una copia actualizada del archivo y ve que no hay problemas nuevos registrados en Registro de telemetría.
En esta publicación del blog, hemos hablado de la finalidad del Registro de telemetría y de cómo empezar a usarlo. También hemos explicado la forma en que los usuarios finales, especialmente los desarrolladores y evaluadores, pueden sacar el máximo partido al Registro de telemetría.
Guía de referencia para usar Registro de telemetría
Problemas de compatibilidad en Office 2013
Esta publicación del blog es una traducción. Puede leer el artículo original en Introducing Telemetry Log in Office 2013
Artículo original publicado el miércoles, 26 de septiembre de 2012
La autora de esta publicación del blog es Junko Kyomasu, administradora de programas del equipo de administración de soluciones de Office
Panel de telemetría de Office es una nueva y potente herramienta que administra documentos y complementos de Office en la organización. Permite disfrutar de una mejor experiencia de actualización de la versión instalada de Office a Office 2013. Nos alegra saber que muchos de nuestros lectores han probado las características de telemetría con Office 2013, pero algunos nos han dicho que quieren probar los componentes del panel en un entorno de grupo de trabajo, que hasta ahora no era posible. Configurar el Registro para habilitar la creación inmediata de informes de datos también puede ser complicado.
Para que tenga que invertir menos tiempo y esfuerzo en la evaluación, hemos publicado un script de Windows PowerShell, Deploy-TelemetryDashboard.ps1, que configura todos los componentes de telemetría a la vez. Se puede ejecutar el script para instalar los componentes en un solo equipo de grupo de trabajo o unido a un dominio. El script también permite que el Agente de telemetría integrado empiece a crear informes de datos de telemetría inmediatamente. En grupos de trabajo, los componentes del panel solo se pueden configurar con este script.
En entornos de producción que contienen cientos o miles de equipos cliente, puede implementar cada componente paso a paso como se describe en Implementar el Panel de telemetría de Office.
Baje Deploy-TelemetryDashboard.ps1 y TDDB.bak de la Galería de TechNet y ejecute Deploy-TelemetyDashboard.ps1 en un equipo que tenga instalado Office 2013.
¡Ya está!
El script le permitirá configurar el Panel de telemetría en el equipo y verá que se envían informes de datos de telemetría al panel de forma inmediata.
El script configura todos los componentes necesarios para empezar a usar Panel de telemetría. Debe ejecutar el script en un equipo que tenga instalada la edición Office Professional Plus 2013 o la edición Office 365 ProPlus de Office 2013.
El script llevará a cabo las tareas siguientes:
1. Crear 2 grupos locales (solo grupo de trabajo): para permitir un acceso seguro a la carpeta compartida y a la base de datos, el script creará 2 grupos locales en un equipo y agregará el usuario que haya iniciado sesión a los grupos, que son:
TDAgent: grupo local que podrá acceder a la carpeta compartida
TDAgent: grupo local que podrá acceder a la base de datos
2. Crear una carpeta compartida nueva: la ubicación en la que los equipos cliente de Office suben los datos de telemetría.
TDShared: carpeta local que se creará dentro de la unidad de sistema (por ej., C:\TDShared)
3. Instalar el servicio Procesador de telemetría de Office: este servicio procesará los datos subidos desde el equipo cliente y los insertará en la base de datos.
*4. Restaurar la base de datos de telemetría (solo grupo de trabajo): el script restaurará una base de datos vacía.*Nota: En equipos unidos a un dominio, el script iniciará el asistente para configurar el Procesador de telemetría de Office en lugar de restaurar una base de datos vacía. Si quiere crear una base de datos, siga los pasos del asistente para configuración.
5. Configurar el Agente de telemetría: el Agente de telemetría está integrado en las ediciones Office Professional Plus 2013 y Office 365 ProPlus de Office 2013. El script escribirá valores del Registro que permitirán al agente recopilar y subir datos. Vea Agente de telemetría de Office para más información sobre cada valor del Registro.
6. Ejecutar la tarea del agente: la tarea programada desencadenará el Agente de telemetría. El script ejecutará la tarea del agente (Microsoft\Office\OfficeTelemetryAgentLogOn) manualmente para que el agente recopile y suba datos de telemetría a la carpeta compartida.
7. Iniciar el Panel de telemetría: cuando todas las opciones de configuración estén correctamente implementadas y el agente haya subido los datos de telemetría, el script iniciará el Panel de telemetría.
8. Exportar valores del Registro del agente: puede exportar opciones de configuración del Registro para que el agente envíe las mismas configuraciones a otros equipos cliente de Office que tengan el Agente de telemetría.
Esperamos que este script de Windows PowerShell le ayude a configurar sin problemas las características de telemetría de Office, que le permitirán empezar a obtener los datos de telemetría que necesita para actualizar con total seguridad a Office 2013 y aprovecharse de sus muchas y fantásticas funciones.
No dude en enviarnos sus dudas o comentarios sobre este script. Si tiene algo que decir, agregue un comentario en esta publicación o en la pestaña Preguntas y respuestas de la Galería de TechNet.
Esta publicación del blog es una traducción. Puede leer el artículo original en Quickly set up Office Telemetry Dashboard on a workgroup or domain-joined computer
Artículo original publicado el miércoles, 17 de octubre de 2012
Hemos publicado un nuevo póster de Visio y un artículo sobre compatibilidad y telemetría en Office 2013. Estos son dos buenos puntos de partida para los profesionales de TI que quieran una vista de alto nivel sin entrar mucho en detalle.
El póster de Visio (también disponible en formato PDF y en Zoom.it) describe el funcionamiento de la telemetría en Office 2013. Aquí encontrará información sobre los componentes de la telemetría, los tipos de archivos y las soluciones que se supervisan, y el proceso de supervisión.
La nueva Guía de compatibilidad de Office 2013 describe el moderno proceso de compatibilidad de Office y el modo en que la telemetría de Office favorece este proceso. Algunas de las cosas que aprenderá son la diferencia entre detección e inventario, la importancia de trabajar con grupos de negocios y cómo realizar pruebas de aceptación del usuario con Hacer clic y ejecutar.
Como siempre, agradecemos que nos envíe sus comentarios y le invitamos a que mire semanalmente si hay contenido nuevo y actualizado.
Esta publicación del blog es una traducción. Puede leer el artículo original en New Office 2013 compatibility and telemetry content for IT Pros in the Office Resource Kit
Artículo original publicado el miércoles, 19 de septiembre de 2012
La autora de esta publicación del blog es Nobuko Miwa, administradora de programas del equipo de administración de soluciones de Office
¿Alguna vez ha querido administrar complementos en Office? Si es un profesional de TI que se dedica a administrar el uso de aplicaciones, a lo mejor también le interesa administrar complementos en Office. Si puede evitar que los usuarios finales ejecuten complementos no aprobados que podrían provocar problemas o deteriorar el rendimiento, puede reducir el costo del soporte técnico. Con Office 2013, ofrecemos una característica nueva que permite administrar el uso de los complementos.
Con el Panel de telemetría de Office 2013, puede supervisar el uso de los complementos, el rendimiento y otros aspectos. Con los datos recopilados, puede decidir qué complementos deben administrarse. Este artículo describe cómo administrar complementos en Office con Panel de telemetría.
Primero tiene que implementar el Panel de telemetría. Eche un vistazo a este artículo de Technet para ver los detalles de la implementación del Panel de telemetría.
Cuando Panel de telemetría esté correctamente configurado, fíjese en la hoja de cálculo Soluciones del Panel de telemetría. En esta hoja de cálculo, verá el vínculo Modo de administración de complementos en la esquina superior derecha, como se muestra en la siguiente captura de pantalla. Haga clic en el vínculo para ver la hoja de cálculo Administración de complementos.
Viendo la hoja de cálculo Administración de complementos, puede decidir qué complementos deberían controlarse en función del uso, el tiempo de carga y los problemas encontrados. Cuando decida qué complementos controlar, siga las instrucciones que aparecen en el lado derecho de la pantalla para crear un script de Windows PowerShell y aplicar esta configuración. En la siguiente captura de pantalla se ve la hoja de cálculo Administración de complementos del Panel de telemetría.
Algunas cuestiones que debe tener en cuenta:
Las aplicaciones que permiten administrar complementos son: Excel, Word, Outlook, PowerPoint, Project, Publisher, Visio, OneNote, Access e InfoPath.
Y estos son los tipos de complementos compatibles:
Complemento COM
.dll
Complemento de automatización de Excel
Complemento XLL de Excel
.xll
Complemento de Excel
.xla, .xlam
Complemento RTD de Excel
Complemento de Word
.dot, .dotm, .dotx, .docm
Complemento de PowerPoint
.ppa, .ppam
Estas son las opciones que puede elegir para administrar cada complemento:
Otro método más restrictivo para administrar complementos consiste en bloquear todos los complementos no administrados con los archivos de plantilla administrativa (admx) de Office 2013 y luego usar la configuración Permitir descrita arriba para permitir que los usuarios usen solo los complementos especificados. Existen opciones de configuración independientes para la administración de complementos en cada aplicación compatible de Office 2013. Se encuentran en las rutas de acceso siguientes:
Después de generar el script de Windows PowerShell en la hoja de cálculo Modo de administración de complementos, puede ejecutarlo en el Módulo de Active Directory para Windows PowerShell. En la consola, indique el nombre del GPO al que quiere aplicar la configuración, como se ve en la captura de pantalla siguiente:
Ahora ya puede vincular el GPO creado a cualquier unidad organizativa.
Vamos a ver cómo administra los complementos en el cliente de Office. Abra el cuadro de diálogo Complementos COM en los equipos cliente de Office haciendo lo siguiente:
Puede ver que los complementos están deshabilitados y que los controla el administrador. Los usuarios finales no pueden volver a habilitar el complemento en los equipos. Esto está ilustrado en la siguiente captura de pantalla:
Si Directiva de grupo no se ha aplicado todavía, puede usar el comando siguiente en el símbolo del sistema para desencadenar el proceso de actualización:
gpupdate /force
Nobuko
Esta publicación del blog es una traducción. Puede leer el artículo original en Let's manage add-ins using Telemetry Dashboard