Veröffentlichung des Originalartikels: 17.10.2012
Wir haben ein neues Visio-Poster und einen neuen Artikel zur Kompatibilität und Telemetrie in Office 2013 veröffentlicht. Beides sind geeignete Ausgangspunkte für IT-Spezialisten, die sich einen Überblick verschaffen möchten, ohne sich allzu sehr mit Details zu befassen.
Das Visio-Poster (auch verfügbar im PDF- und Zoom-it-Format) beschreibt die Funktionsweise der Telemetrie in Office 2013. Sie erhalten Informationen zu den Telemetriekomponenten, den überwachten Datei- und Lösungstypen, dem Überwachungsprozess usw.
Im neuen Leitfaden zur Office 2013-Anwendungskompatibilität werden der moderne Office-Kompatibilitätsprozess und die Unterstützung dieses Prozesses durch die Office-Telemetrie beschrieben. Hier finden Sie Informationen zu Themen wie z. B. Erkennung und Inventar, der Bedeutung der Verwendung von Unternehmensgruppen sowie der Durchführung von Benutzerakzeptanztests mithilfe von Klick-und-Los.
Wie immer freuen wir uns über Ihr Feedback und möchten Sie auffordern, wöchentlich nach neuen und aktualisierten Inhalten zu suchen.
Jill
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter New Office 2013 compatibility and telemetry content for IT Pros in the Office Resource Kit.
Veröffentlichung des Originalartikels: 19.09.2012
Dieser Blogbeitrag wurde von Nobuko Miwa verfasst, einem Program Manager im Office Solutions Management-Team
HABEN SIE SCHON EINMAL VERSUCHT, ADD-INS FÜR OFFICE ZU VERWALTEN? Wenn Sie ein IT-Spezialist sind, der die Verwendung der Anwendungen verwaltet, möchten Sie möglicherweise auch Add-Ins für Office verwalten. Wenn Sie Endbenutzer am Ausführen nicht genehmigter Add-Ins hindern können, die Probleme oder eine Leistungsbeeinträchtigung verursachen, können Sie die Supportkosten senken. Mit Office 2013 bieten wir ein neues Feature zum Verwalten der Verwendung von Add-Ins an.
Mit dem Telemetriedashboard von Office 2013 können Sie die Verwendung der Add-Ins sowie Leistungsprobleme und sonstige Probleme überwachen. Anhand der erfassten Daten können Sie entscheiden, welche Add-Ins verwaltet werden sollten. In diesem Artikel wird beschrieben, wie Sie Add-Ins für Office mit dem Telemetriedashboard verwalten.
Zunächst müssen Sie das Telemetriedashboard bereitstellen. Weitere Informationen hierzu finden Sie in diesem TechNet-Artikel.
Nachdem Sie das Telemetriedashboard erfolgreich eingerichtet haben, zeigen Sie das Arbeitsblatt Lösungen (Solutions) im Telemetriedashboard an. In diesem Arbeitsblatt gibt es wie im folgenden Screenshot dargestellt in der oberen rechten Ecke den Link Add-In-Verwaltungsmodus (Add-in management mode). Klicken Sie auf diesen Link, um das Arbeitsblatt Add-In-Verwaltung (Add-in management) anzuzeigen.
Im Arbeitsblatt Add-In-Verwaltung (Add-in management) können Sie festlegen, für welche Add-Ins die Verwendung, die Ladezeit und erkannte Probleme kontrolliert werden sollen. Nachdem Sie die zu kontrollierenden Add-Ins ausgewählt haben, sollten Sie die Anweisungen auf rechten Seite des Bildschirms befolgen, um ein Windows PowerShell-Skript zum Anwenden dieser Einstellungen zu erstellen. Im folgenden Screenshot ist das Arbeitsblatt Add-In-Verwaltung (Add-in management) im Telemetriedashboard dargestellt.
Folgendes sollten Sie beachten:
In den folgenden Anwendungen können Add-Ins verwaltet werden: Excel, Word, Outlook, PowerPoint, Project, Publisher, Visio, OneNote, Access, InfoPath.
Die folgenden Add-In-Typen werden unterstützt:
COM-Add-In
DLL
Excel-Automatisierungs-Add-In
Excel-XLL-Add-In
XLL
Excel-Add-In
XLA, XLAM
Excel-RTD-Add-In
Word-Add-In
DOT, DOTM, DOTX, DOCM
PowerPoint-Add-In
PPA, PPAM
Die folgenden Optionen können Sie zum Verwalten der einzelnen Add-Ins auswählen:
Eine restriktivere Methode zum Verwalten von Add-Ins ist das Blockieren aller nicht verwalteten Add-Ins mit den administrativen Vorlagendateien für Office 2013 (ADMX) und das anschließende Zulassen nur der angegebenen Add-Ins mithilfe der oben beschriebenen Option Zulassen (Allow). Für jede unterstützte Office 2013-Anwendung gibt es spezielle Einstellungen für die Add-In-Verwaltung. Sie befinden sich in den folgenden Pfaden:
Nachdem Sie das Windows PowerShell-Skript im Arbeitsblatt Add-In-Verwaltungsmodus (Add-in management mode) generiert haben, können Sie das Skript im Active Directory-Modul für Windows PowerShell ausführen. Geben Sie wie im folgenden Screenshot dargestellt in der Konsole den Namen des Gruppenrichtlinienobjekts an, auf das die Einstellungen angewendet werden sollen:
Nun können Sie das erstellte Gruppenrichtlinienobjekt mit einer beliebigen Organisationseinheit verknüpfen.
Lassen Sie uns überprüfen, wie Sie die Add-Ins in Ihrem Office-Client verwalten. Öffnen Sie wie folgt das Dialogfeld COM-Add-Ins (COM Add-Ins) auf Ihren Office-Clientcomputern:
Wie Sie sehen sind die Add-Ins deaktiviert und werden vom Administrator kontrolliert. Die Endbenutzer können die Add-Ins nicht erneut auf ihren Computern aktivieren. Dies ist im folgenden Screenshot veranschaulicht:
Wenn noch keine Gruppenrichtlinien angewendet sind, können Sie den folgenden Befehl an der Eingabeaufforderung ausführen, um den Aktualisierungsvorgang auszulösen:
gpupdate /force
Nobuko
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Let's manage add-ins using Telemetry Dashboard.
Veröffentlichung des Originalartikels: 27.10.2012
Inzwischen haben Sie vielleicht schon von dem neuen XML-basierten Dateiformat VSDX in Visio 2013 gehört. Mit VSDX werden neue Funktionen in Visio bereitgestellt, wie z. B. gemeinsame Dokumenterstellung, und außerdem wird die Interoperabilität mit anderen Anwendungen verbessert. Falls Sie noch nicht damit vertraut sind, gibt es dazu im Visio-Blogbeitrag VSDX: the new Visio file format interessante Informationen. Ausführlichere technische Informationen zum VSDX-Format finden Sie unter Einführung in das Visio 2013-Dateiformat (VSDX) und Vorgehensweise: Programmgesteuerte Bearbeitung des Visio 2013-Dateiformats auf MSDN.
Unsere IT-Spezialisten werden sich wahrscheinlich an die Herausforderungen beim Migrieren des Binärdateiformats von Office 2003 zum OpenXML-Dateiformat in Office 2007 und höheren Versionen erinnern. Bei Visio 2013 gibt es ähnliche Herausforderungen, aber ich denke Sie werden mir zustimmen, dass die Migration die Mühe lohnt. Dieses neue VSDX-Format bietet viele Vorteile, wie z. B. kleinere Dateigrößen, verbesserte Datenwiederherstellung und einfachere Interoperabilität.
Neue Dateitypen in Visio 2013
In Visio gibt es drei Hauptdateitypen: Zeichnungen, Vorlagen und Schablonen. Diese Dateitypen sind auch im neuen Format verfügbar, jedoch mit einem Unterschied: wie bei den anderen Office-Anwendungen gibt es nun Formate mit und ohne Makros. Die neuen Dateierweiterungen für die verschiedenen Dateitypen sind in der folgenden Tabelle aufgeführt.
Ohne Makros
Mit Makros
Zeichnung
VSDX
VSDM
Vorlage
VSTX
VSTM
Schablone
VSSX
VSSM
Kompatibilitätsfeatures in Visio 2013
In Visio 2013 gibt es die folgenden Kompatibilitätsfeatures für die Umstellung der Benutzer vom alten auf das neue Format:
Weitere Informationen zu den neuen Kompatibilitätsfeatures finden Sie in den folgenden Artikeln auf Office.com:
Visio 2013 speichert Dateien standardmäßig im VSDX-Format. Dies ist kein Problem, wenn alle Benutzer Visio 2013 verwenden. Wenn allerdings manche Benutzer weiterhin ältere Versionen von Visio verwenden, können Sie mithilfe der Gruppenrichtlinien in Visio 2013 „VSD“ als Standarddateityp festlegen. Die Gruppenrichtlinieneinstellung Visio-Dateien speichern unter (Save Visio files as) ist in den administrativen Vorlagendateien für Office 2013 (ADMX/ADML) und im Office-Anpassungstool verfügbar. Diese Einstellungen finden Sie unter Benutzerkonfiguration\Administrative Vorlagen\Microsoft Visio 2013\Visio-Optionen\Speichern\Dokumente speichern.
Die folgenden Dateiformate können Sie als Standarddateityp für Visio 2013 festlegen:
Wie immer freuen wir uns über Ihre Kommentare, falls Sie Vorschläge für IT Pro-Inhalte für Visio 2013 haben.
--Jill
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter What IT Pros need to know about the new VSDX file format in Visio 2013.
Veröffentlichung des Originalartikels: 26.09.2012
Dieser Blogbeitrag wurde von Junko Kyomasu verfasst, einem Program Manager im Office Solutions Management-Team
Das Office-Telemetriedashboard ist ein neues, leistungsfähiges Tool zum Verwalten von Office-Dokumenten und -Add-Ins in Ihrer Organisation. Mit diesem Tool wird der Upgradevorgang von Ihrer vorhandenen Office-Version auf Office 2013 vereinfacht. Wir freuen uns, dass viele Benutzer die Telemetriefeatures mit Office 2013 getestet haben. Einige Benutzer haben uns jedoch mitgeteilt, dass sie die Dashboardkomponenten in einer Arbeitsgruppenumgebung testen möchten, was bisher nicht unterstützt wurde. Das Konfigurieren der Registrierung, sodass sofortige Datenberichte ermöglicht werden, kann sich außerdem als tückisch erweisen.
Um Ihre Auswertung zu vereinfachen und zu beschleunigen, haben wir das Windows PowerShell-Skript Deploy-TelemetryDashboard.ps1 bereitgestellt, mit dem alle Telemetriekomponenten in einem Schritt eingerichtet werden! Dieses Skript können Sie ausführen, um die Komponenten auf einem einzelnen Arbeitsgruppencomputer oder einem in eine Domäne eingebundenen Computer zu installieren. Darüber hinaus wird mit diesem Skript der integrierte Telemetrie-Agent aktiviert, um sofort mit dem Erstellen von Berichten zu Telemetriedaten zu beginnen. Dieses Skript ist die einzige Methode, um die Dashboardkomponenten in einer Arbeitsgruppe zu konfigurieren.
Für Produktionsumgebungen mit Hunderten oder Tausenden von Clientcomputern können Sie jede Komponente wie unter Bereitstellen des Office-Telemetriedashboards beschrieben schrittweise bereitstellen.
Laden Sie Deploy-TelemetryDashboard.ps1 und TDDB.bak aus der TechNet Gallery herunter, und führen Sie Deploy-TelemetyDashboard.ps1 auf Ihrem Computer mit installiertem Office 2013 aus.
Das ist schon alles!
Mit dem Skript können Sie das Telemetriedashboard auf Ihrem Computer konfigurieren, und es werden sofort Telemetriedaten im Dashboard angezeigt.
Mit diesem Skript werden alle erforderlichen Komponenten für die Verwendung des Telemetriedashboards eingerichtet. Sie müssen das Skript auf einem Computer ausführen, auf dem die Versionen Office Professional Plus 2013 oder Office 365 ProPlus von Office 2013 installiert sind.
Mit diesem Skript werden die folgenden Aufgaben ausgeführt:
1. Erstellen von zwei lokalen Gruppen (nur Arbeitsgruppe): Für den sicheren Zugriff auf den freigegebenen Ordner und die freigegebene Datenbank werden mit dem Skript zwei lokale Gruppen auf einem Computer erstellt, und der aktuell angemeldete Benutzer wird den Gruppen hinzugefügt. Dabei handelt es sich um die folgenden Gruppen:
TDAgent – lokale Gruppe mit Zugriff auf den freigegebenen Ordner
TDDatabase – lokale Gruppe mit Zugriff auf die Datenbank
2. Erstellen eines neuen freigegebenen Ordners: Der Speicherort, in den Office-Clientcomputer Telemetriedaten hochladen.
TDShared – lokaler Ordner, der auf dem Systemlaufwerk erstellt wird (z. B. C:\TDShared)
3. Installieren des Office-Telemetrieprozessordiensts: Von diesem Dienst werden Daten verarbeitet, die vom Clientcomputer hochgeladen werden, und in der Datenbank eingefügt.
*4. Wiederherstellen der Telemetriedatenbank (nur Arbeitsgruppe): Mit dem Skript wird eine leere Datenbank wiederhergestellt.*Hinweis: Für einen in eine Domäne eingebundenen Computer wird keine leere Datenbank wiederhergestellt, sondern der Einstellungen-Assistent des Office-Telemetrieprozessors gestartet. Mit dem Einstellungen-Assistenten können Sie eine neue Datenbank erstellen.
5. Konfigurieren des Telemetrie-Agents: Der Telemetrie-Agent ist in die Versionen Office Professional Plus 2013 und Office 365 ProPlus von Office 2013 integriert. Mit dem Skript werden Registrierungswerte geschrieben, um dem Agent das Erfassen und Hochladen von Daten zu ermöglichen. Weitere Informationen zu den einzelnen Registrierungswerten finden Sie im Abschnitt zum Office-Telemetrie-Agent.
6. Ausführen des Agent-Vorgangs: Der Telemetrie-Agent wird von dem geplanten Vorgang ausgelöst. Der Agent-Vorgang (Microsoft\Office\OfficeTelemetryAgentLogOn) wird vom Skript manuell ausgeführt, sodass der Agent Telemetriedaten erfasst und in den freigegebenen Ordner hochlädt.
7. Starten des Telemetriedashboards: Nachdem alle Einstellungen erfolgreich bereitgestellt wurden und die Telemetriedaten vom Agent hochgeladen wurden, wird das Telemetriedashboard vom Skript gestartet.
8. Exportieren von Registrierungseinstellungen für den Agent: Sie können Registrierungseinstellungen für den Agent exportieren, um dieselben Einstellungen an andere Office-Clientcomputer zu übertragen, auf denen der Telemetrie-Agent verwendet wird.
Wir hoffen, dass Sie mit diesem Windows PowerShell-Skript Office-Telemetriefeatures problemlos einrichten können, damit Sie die erforderlichen Telemetriedaten abrufen können, um ohne Angst auf Office 2013 zu upgraden und die vielen großartigen Features von Office 2013 nutzen zu können.
Wie freuen uns über Ihre Fragen oder Kommentare zu diesem Skript. Verfassen Sie in diesem Fall bitte Kommentare zu diesem Blogbeitrag oder auf der Registerkarte F&A in der TechNet Gallery.
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Quickly set up Office Telemetry Dashboard on a workgroup or domain-joined computer.
Veröffentlichung des Originalartikels: 07.11.2012
Dieser Beitrag wurde von David Matsumoto verfasst, einem Program Manager im Office Solutions Management-Team
In den letzten Blogbeiträgen haben wir uns mit den neuen Office-Telemetriefeatures in Office 2013 befasst. Möglicherweise haben Sie ein paar Blogbeiträge gelesen, in denen das Telemetriedashboard ausführlicher behandelt wurde, und Sie hatten hoffentlich Gelegenheit, das Telemetriedashboard zu verwenden.
In diesem Blogbeitrag werden wir uns mit dem Telemetrieprotokoll für Office 2013 befassen, das zusammen mit dem Telemetriedashboard installiert wird. Wir werden den Zweck des Telemetrieprotokolls sowie dessen optimale Nutzung beschreiben. Fangen wir also an!
Mit dem Telemetrieprotokoll können Endbenutzer Kompatibilitätsprobleme erkennen, die bei bestimmten Office 2013-Anwendungen* auf dem lokalen Clientcomputer auftreten. Während das Telemetriedashboard für IT-Spezialisten gedacht ist, um Verwendungs- und Telemetrieinformationen in der gesamten Organisation zu erfassen und in einer einzigen Ansicht darzustellen, werden mit dem Telemetrieprotokoll dieselben Informationen pro Benutzer auf dem Computer des Benutzers angezeigt.
Nach der Aktivierung der Telemetrieprotokollierung wird jedes Mal, wenn der Benutzer eine Datei oder Lösung in Office 2013 öffnet oder schließt, ein Ereignis in einem lokalen Datenspeicher auf dem Clientcomputer protokolliert. Aufgetretene Fehler (auch solche, die nicht offensichtlich sind) werden im lokalen Datenspeicher zusammen mit den Benutzer- und Computerinformationen protokolliert. Fehler werden nach Möglichkeit bekannten Kompatibilitätsproblemen zugeordnet, die im Telemetrieprotokoll angezeigt werden können.
*Eine Aufstellung der Office-Dateien und ‑Lösungen, die im Telemetrieprotokoll nachverfolgt werden, finden Sie in Tabelle 1 unter So funktioniert Telemetrieprotokoll.
Wenn Sie Office 2013 unter Windows 8 installiert haben, wischen Sie einfach nach oben, um die App-Leiste anzuzeigen, wählen Sie Alle Apps aus, und wählen Sie dann Telemetrieprotokoll für Office 2013 aus. (Für Installationen unter Windows 7 wählen Sie Alle Programme aus. Erweitern Sie dann in der Liste mit den Programmen Microsoft Office 2013, erweitern Sie Office 2013-Tools, und wählen Sie dann Telemetrieprotokoll für Office 2013 aus.)
Wenn Sie das Telemetrieprotokoll starten, wird eine neue Arbeitsmappe in Excel 2013 geöffnet. Die Arbeitsmappe enthält die drei Arbeitsblätter Ereignisse (Events), Systeminfo (System Info) und Anleitung (Guide).
Klicken Sie auf das Arbeitsblatt Anleitung (Guide), und klicken Sie dann auf die grüne Schaltfläche zum Aktivieren der Protokollierung:
Damit sind Sie fertig! Wenn Sie ein Dokument oder eine Lösung in Office 2013 öffnen, wird es bzw. sie sofort im Telemetrieprotokoll nachverfolgt. Öffnen und schließen Sie doch einmal ein Dokument, oder laden Sie eine Lösung. Navigieren Sie dann zurück zum Arbeitsblatt Ereignisse (Events), und klicken Sie auf die Schaltfläche zum Aktualisieren oben rechts im Kopfzeilenbereich. Es werden Zeilen für die Ereignisse angezeigt, die beim Öffnen oder Schließen dieses Dokuments oder dieser Lösung aufgetreten sind. Sie können dies anhand mehrerer Spalten im Arbeitsblatt Ereignisse (Events) überprüfen. (Siehe das Beispiel in Abbildung 1 unten.)
Beispielsweise wird im Arbeitsblatt Ereignisse (Events) Folgendes angezeigt:
Abbildung 1: Telemetrieprotokoll (Ereignisansicht)
Wenn Sie überprüfen möchten, ob die Telemetrieprotokollierung auf Ihrem Computer aktiviert ist, können Sie auch auf das Arbeitsblatt Systeminfo (System Info) klicken und prüfen, ob die Telemetrieprotokollierung aktiviert ist.
Hinweis: Wenn ein Clientcomputer in einer verwalteten Umgebung ausgeführt wird, hat der IT-Administrator für Ihren Computer möglicherweise bereits die Telemetrieprotokollierung aktiviert, damit Daten in die Datenbank hochgeladen und im Telemetriedashboard angezeigt werden können.
Das Telemetrieprotokoll ist besonders für erfahrene Benutzer und Tester hilfreich, die Probleme bei Dokumenten oder Lösungen analysieren und die geeigneten Schritte zum Beheben der Probleme ermitteln möchten.
Im folgenden Beispiel wird die Problembehandlung bei Dokumenten (oder Lösungen) mithilfe des Telemetrieprotokolls veranschaulicht:
1. Ein Tester hat ein paar Dokumente geladen (z. B. CalendarControl_report.xls, ConfidentialityAgreement_template.docx) und versucht, die fehlerhaften Steuerelemente (oder Makros usw.) auszuführen. (Beachten Sie, dass die Steuerelemente tatsächlich ausgeführt werden müssen, um Probleme auszulösen, damit diese dann im Telemetrieprotokoll aufgezeichnet werden können.)
2. Ein Tester startet das Telemetrieprotokoll und sucht im Arbeitsblatt Ereignisse (Events) nach den verwendeten Dokumenten. Der Tester stellt fest, dass für diese Dateien ein Fehler und eine Warnung sowie eine entsprechende Erläuterung für die Ursache des Problems generiert werden. (Siehe das in Abbildung 2 hervorgehobene Beispiel.)
Abbildung 2: Telemetrieprotokoll – Beispiel für die Ereignisansicht mit Dokumentfehler/Warnung und Erläuterung
3. Der Tester klickt in der Spalte Weitere Informationen (More Info) auf den Link für das untersuchte Problem (in diesem Fall das Dokument ConfidentialityAgreement_template.docx). Es werden ausführlichere Informationen von MSDN angezeigt, für die er einen weiteren Drilldown ausführen und hilfreiche Informationen anzeigen kann, damit dieser Entwickler das Problem beheben kann. (Siehe das in Abbildung 3 hervorgehobene Beispiel.)
Abbildung 3: Drilldown für weitere Informationen auf MSDN
4. Nachdem ein Entwickler das Problem behoben hat, öffnet der Tester eine aktualisierte Kopie der Datei und stellt fest, ob keine neuen Probleme im Telemetrieprotokoll aufgezeichnet werden.
In diesem Blogbeitrag wurden der Verwendungszweck des Telemetrieprotokolls und die ersten Schritte damit behandelt. Darüber hinaus wurde erläutert, wie Endbenutzer, insbesondere Entwickler und Tester, das Telemetrieprotokoll optimal nutzen können.
Referenzhandbuch für die Verwendung des Telemetrieprotokolls
Kompatibilitätsprobleme in Office 2013
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Introducing Telemetry Log in Office 2013.
Veröffentlichung des Originalartikels: 11.09.2012
Dieser Beitrag wurde von Nick Simons verfasst, einem Senior Program Manager für Office Web Apps.
Im Sommer 2010 stellten wir Ihnen Office Web Apps vor: browserbasierte Versionen von Word, PowerPoint, Excel und OneNote. Diese Produkte wurden als SharePoint-Anwendungssatz zur Verfügung gestellt. Kunden, die Office Web Apps in ihren eigenen Netzwerk bereitstellten, installierten zu diesem Zweck Office Web Apps auf SharePoint-Servern.
Damals schien eine nahtlose SharePoint-Integration die beste Vorgehensweise zu sein. SharePoint kam und kommt auch weiterhin eine wichtige Bedeutung im Zusammenhang mit Office Web Apps zu. Außerdem weist SharePoint ein klar definiertes Modell zum Integrieren von Anwendungen wie die Office Web Apps auf. Als wir jedoch mit der Planung der nächsten Version von Office Web Apps begannen, zeigte sich, dass bestimmte zentrale Ziele mit einer so eng in SharePoint integrierten Architektur nur schwer umzusetzen sein würden.
Wir wollten das Setup und die Kapazitätsplanung vereinfachen und den Partnerverbund für mehrere Serverfarmen ermöglichen. Darüber hinaus wollten wir Anfragen bezüglich der Integration von neuen Partnern wie z. B. Lync berücksichtigen. Schließlich bekamen wir von vielen Kunden zu hören, sowohl auf Office 365 als auch lokal, dass sie sich dieselben Verbesserungen wie unsere SkyDrive-Benutzer wünschen.
Zur Umsetzung dieser Ziele begannen wir von vorn und überlegten uns, wie die Office Web Apps nun und in Zukunft in andere Produkte integriert werden würden. Wir entwickelten ein neues Modell, mit dem Office Web Apps von einer spezifischen Partnertechnologie getrennt wurde. Unser Modell bedeutete letztlich einen relativ geringen Codieraufwand für Dateihosts wie etwa SharePoint, während wir Office Web Apps auf völlig separaten Servern ausführen konnten.
Dieses neue eigenständige Serverprodukt ist Office Web Apps Server.
Uns ist bewusst, dass die Idee eines weiteren Servertyps auf den ersten Blick zusätzliche Komplexität und zusätzlichen Arbeitsaufwand für den Administrator mit sich zu bringen scheint. Das eigenständige Modell bietet jedoch die folgenden Vorteile:
1. Einfacheres Setup
2. Upgrade und Wartung sind vollständig von SharePoint getrennt
3. Mehrere SharePoint-Farmen werden in eine einzelne Office Web Apps Server-Farm integriert
4. Andere Produkte wie z. B. Exchange oder Lync und Drittanbieterprodukte werden in Office Web Apps integriert
5. Bereitstellung neuer Features und Verbesserungen für unsere webbasierten und lokalen Kunden praktisch zum selben Zeitpunkt
Beim Vergleich vorheriger Office Web Apps-Bereitstellungen in SharePoint 2010 mit neuen Bereitstellungen mithilfe von Office Web Apps Server zeigen sich die Vorteile.
Mit der vorherigen Version von Office sah eine typische Office Web Apps-Bereitstellung so oder ähnlich aus...
Beachten Sie, dass die vorherige Version von Office Web Apps auf jeder Serverfarm und auf jedem Computer in jeder Serverfarm installiert werden musste. Die Skalierung von Office Web Apps war an die allgemeine SharePoint-Skalierung gebunden. Darüber hinaus musste zum Aktualisieren von Office Web Apps Code auf jedem Computer in allen Ihren SharePoint-Farmen aktualisiert werden.
Mit Office Web Apps Server sieht eine Bereitstellung eher wie folgt aus...
Wie Sie sehen, kann eine einzelne Office Web Apps Server-Farm für mehrere SharePoint 2013-Farmen sowie Lync 2013 und Exchange 2013 (Outlook Web Access) verwendet werden. Darüber hinaus können Sie mit Ihrer Office Web Apps-Farm alle per URL oder UNC zugänglichen Word-, Excel- und PowerPoint-Dateien anzeigen.
Im Folgenden finden Sie eine Übersicht über die Integration von Office Web Apps in einen Dateihost wie etwa SharePoint. Diese Informationen dienen dem Verständnis der weiter unten beschriebenen Netzwerk- und Sicherheitsanforderungen.
Zunächst ein paar Definitionen:
Ein zentraler Bestandteil des neuen Integrationsmodells ist eine neue öffentliche Anwendungsprogrammierschnittstelle (Application Programming Interface, API), die von Office Web Apps für die Kommunikation mit Hosts verwendet wird. Diese API wird als WOPI (Web application Open Platform Interface) bezeichnet. Dateien werden von Office Web Apps Server mithilfe der WOPI-API abgerufen und bearbeitet. Office Web Apps Server wird oft auch als WOPI-App bezeichnet. Hosts müssen die WOPI-Anforderungen von WOPI-Apps verstehen.
WOPI ist eine RESTful-API, die HTTP/HTTPS verwendet. Dies bedeutet, dass unter anderem der gesamte Datenverkehr zwischen Hosts und Office Web Apps Server über standardmäßige HTTP/HTTPS-Ports übermittelt wird. Dies bedeutet auch, dass Office Web Apps Server soweit wie möglich statusfrei ist. Dadurch wird die Anfälligkeit für eine Reihe von Fehlern reduziert, die von Netzwerkausfällen bis hin zum Totalausfall von Hardware reichen kann.
Lassen Sie uns zum besseren Verständnis der Funktionsweise von WOPI ein einfaches Szenario betrachten, bei dem die Benutzerin Sally die in SharePoint gehostete Datei test.docx anzeigt. Und so sieht das Szenario im Einzelnen aus:
1. Sally navigiert zur Dokumentbibliothek, in der test.docx gespeichert ist.
2. Sally klickt in der Dokumentbibliothek auf den Dateinamen.
3. SharePoint navigiert im Browser zu einer speziellen SharePoint-Seite, auf der Anforderungen für Office Web Apps Server (und andere WOPI-Apps) ausgeführt werden können. Diese SharePoint-Seite heißt in diesem Szenario WOPIFrame.aspx.
4. WOPIFrame.aspx enthält einen iFrame (http://dev.w3.org/html5/spec/the-iframe-element.html), in dem zu einer Seite auf dem Office Web Apps Server navigiert wird. Diese Seite heißt in diesem Szenario WordViewer.aspx. Die HTTP-Anforderung für WordViewer.aspx enthält einige wichtige Informationen:
5. Office Web Apps Server verwendet die WOPI-Quelle und das Zugriffstoken zum Abrufen von test.docx von SharePoint.
6. WordViewer.aspx zeigt test.docx im iFrame in WOPIFrame.aspx an.
In der folgenden Abbildung ist der Datenfluss zwischen Browser, SharePoint und Office Web Apps Server dargestellt...
Bei einer Serverfarm kann es sich in diesem Szenario um eine einzelne virtuelle Maschine, die auf einem freigegebenen Server ausgeführt wird, bis hin zu einer Farm mit Dutzenden von Rechenzentrumsservern handeln. Setup und Wartung sind im Prinzip in allen Fällen identisch. Die genauen Voraussetzungen und Schritte zum Erstellen einer Farm sind natürlich im Lieferumfang des Produkts enthalten. Diese Dokumentation soll an dieser Stelle nicht reproduziert werden. Ich werde die Anforderungen grob skizzieren.
Zunächst benötigen Sie einige Server. Angenommen, Sie richten eine Farm für 80.000 Benutzer mehrerer SharePoint-Farmen ein. Sie benötigen wahrscheinlich 4 Server mit...
Darüber hinaus benötigen Sie ein Lastenausgleichsmodul. Wir bei Microsoft verwenden eine Farmkonfiguration mit 10 Servern, die ein F5 BIG-IP-Hardwarelastenausgleichsmodul gemeinsam mit einer Reihe weiterer Serverprodukte verwendet. Diese Konfiguration funktioniert hervorragend, aber jede geeignete Lastenausgleichslösung erfüllt denselben Zweck. Wir empfehlen jedoch dringend, dass die Lastenausgleichslösung die Affinität unterstützt. Bezüglich der Leistung ist es äußerst hilfreich, wenn alle Anforderungen für eine bestimmte Sitzung vom selben Server verarbeitet werden.
Ich gehe davon aus, dass Ihre Benutzer Zugriff auf Office Web Apps sowohl vom internen Netzwerk aus als auch über das Internet haben sollen. In diesem Fall müssen Sie internes und externes DNS für Ihre Farm einrichten. Sie könnten aber auch nur externes DNS einrichten und interne DNS-Regeln für interne Anforderungen in Ihrem privaten Netzwerk verwenden. Ich würde jedenfalls so vorgehen.Sie müssen aber Ihr Netzwerk entsprechend Ihren Anforderungen einrichten. Folgendes muss jedoch erfüllt sein:
Sie müssen unbedingt sicherstellen, dass diese Netzwerkrouten ordnungsgemäß eingerichtet sind. Die Office Web Apps sind relativ einfach, sind aber nur funktionsfähig, wenn die Kommunikationskanäle offen sind.
Wie bereits im vorherigen Abschnitt beschrieben, beinhaltet die Anforderung zum Rendern oder Bearbeiten einer Datei Benutzeranmeldeinformationen in Form eines Zugriffstokens. Dieses Zugriffstoken ist wiederum in allen Anforderungen von Office Web Apps bei Hosts enthalten. Der gesamte Datenverkehr muss mit SSL geschützt werden, außer Sie befinden sich in einem privaten Netzwerk und vertrauen allen Benutzern, die Zugriff auf dieses Netzwerk haben. Selbst in diesem Fall sollten Sie unbedingt SSL verwenden.Zum Einrichten von SSL müssen Sie Zertifikate erstellen und auf jeden Office Web Apps Server-Computer oder auf das Lastenausgleichsmodul kopieren. Falls Sie SSL auf dem Lastenausgleichsmodul beenden, können Sie spezielle Einstellungen in Office Web Apps Server verwenden, die ich gleich behandeln werde.
Nachdem Sie nun über die gesamte Hardware und Netzwerkinfrastruktur verfügen, ist es an der Zeit, Ihre Office Web Apps Server-Farm zu erstellen. Zunächst installieren Sie Office Web Apps Server und die zugehörigen Sprachpakete auf allen Servern. Versuchen Sie nicht, irgendeine andere Software auf den Servern zu installieren. Kein SharePoint. Kein Exchange. Nichts. Verwenden Sie virtuelle Maschinen, falls Sie Hardware gemeinsam nutzen möchten.
Anschließend führen Sie den folgenden Windows PowerShell-Befehl auf dem ersten Server in der Farm aus (wir bezeichnen ihn als Server1). Dabei wird von Folgendem ausgegangen:
Und so sieht der Windows PowerShell-Befehl aus:
New-OfficeWebAppsFarm -ExternalURL "https://officewebapps.contoso.com" -EditingEnabled -SSLOffloaded
Damit verfügen Sie über eine Office Web Apps Server-Farm mit einem einzelnen Server.
Anschließend fahren Sie mit Server2 fort. Führen Sie auf diesem Server folgenden Befehl aus:
New-OfficeWebAppsMachine -MachineToJoin "Server1"
Damit verfügen Sie über eine Farm mit zwei Servern. Wiederholen Sie den vorherigen Schritt für Server3 und Server4.
Ihre Office Web Apps-Farm ist zu diesem Zeitpunkt einsatzbereit. Allerdings ist sie noch nicht mit Hosts verbunden. Um eine Verbindung zwischen einer SharePoint-Farm und dieser Office Web Apps Server-Farm herzustellen, öffnen Sie eine Windows PowerShell-Eingabeaufforderung auf einem beliebigen Server in der SharePoint-Farm, und führen Sie den folgenden Befehl aus:
New-SPWopiBinding -ServerName "officewebapps.contoso.com"
Darüber hinaus müssen Sie folgenden Befehl ausführen, um die SharePoint-Farm anzuweisen, dass Sie die externe URL der Office Web Apps Server-Farm verwenden möchten und dass HTTPS verwendet wird.
Set-SPWopiZone -Zone "external-https"
Das wäre schon alles. Navigieren Sie zu einer Dokumentbibliothek in der SharePoint-Farm, um wie gewünscht Office-Dateien zu erstellen, anzuzeigen und zu bearbeiten. Es ist keine weitere Konfiguration erforderlich.
Führen Sie schließlich den folgenden Befehl aus, wenn Sie die Office Web Apps Server-Farm von SharePoint trennen möchten:
Remove-SPWopiBinding -All
Wenn Sie nun zu einer Dokumentbibliothek in der SharePoint-Farm navigieren, ist keine Spur der Office Web Apps vorhanden.
Sie können beliebig viele SharePoint-Farmen mit einer einzelnen Office Web Apps-Farm verbinden. Dasselbe gilt, wenn Sie eine Verbindung von Exchange und Lync mit einer Office Web Apps-Farm herstellen. Weitere Informationen finden Sie unter Exchange Server 2013: Office Web Apps Server-Integration und Bereitstellen von Office Web Apps Server und Lync Server 2013.
Von Anfang an haben wir uns um häufige Updates für die Office Web Apps bemüht. Die Updates haben wir aber nur lokalen Kunden in Form von Service Packs geliefert. Nach der Veröffentlichung von Office Web Apps Server 2013 möchten wir Updates wesentlich häufiger zur Verfügung stellen. Wir sind der Meinung, dass dies für Administratoren machbar ist, da das Aktualisieren von Office Web Apps Server sehr einfach ist.
Zum Aktualisieren der Server in einer Office Web Apps Server-Farm müssen Sie die Server aus dem Lastenausgleichsmodul und der Farm entfernen. Dieser Vorgang kann jedoch so gehandhabt werden, dass die Benutzer praktisch nicht beeinträchtigt werden.Wenn Sie z. B. über eine Farm mit vier Servern verfügen, schalten Sie zwei Server ab und upgraden sie. Anschließend erstellen Sie eine neue Farm mit diesen beiden Servern und verweisen das Lastenausgleichsmodul nicht auf die beiden Server in der ursprünglichen Farm, sondern auf diese beiden Server. Nun upgraden Sie die anderen beiden Server, fügen sie der neuen Farm hinzu und verweisen das Lastenausgleichsmodul ebenfalls auf diese Server.
Wenn Server aus der Farm entfernt werden, können bei manchen Benutzern kleinere Probleme auftreten, aber die Office Web Apps werden wiederhergestellt. Diese Vorgehensweise eignet sich aus offensichtlichen Gründen für alle Fälle außer einem Szenario mit einem einzelnen Server.
Zusätzliche Ressourcen für Office Web Apps Server finden Sie hier:• Office Web Apps Preview-Bibliothek auf der TechNet-Website• Exchange Server 2013: Office Web Apps Server-Integration• Bereitstellen von Office Web Apps Server und Lync Server 2013• Forum für das Setup und die Bereitstellung von Office Web Apps
Nick SimonsSenior Program Manager, Office Web Apps
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Introducing Office Web Apps Server.