Artikel
05/03/2016

Leitfaden zur Office 2010-Anwendungskompatibilität

Gilt für: Office 2010

Letztes Änderungsdatum des Themas: 2015-03-09

Der Test- und Wartungsprozess für die Anwendungskompatibilität für Microsoft Office 2010-Bereitstellungen dient zum Bestimmen von Kompatibilitätsproblemen und Möglichkeiten ihrer Behebung. Diese Informationen sind in erster Linie für IT-Spezialisten hilfreich, die Anwendungskompatibilitätsprobleme beheben müssen. Für Entwickler, die Office-Anwendungen Upgrades unterziehen, können diese Informationen ebenfalls hilfreich sein. Nach Abschluss des in diesem Artikel beschriebenen Prozesses sind Administratoren und Entwickler besser damit vertraut, welche Add-Ins und Anwendungen mit Office interagieren und wie sie zu Office 2010 migriert werden.

In diesem Artikel werden die Kompatibilität, Konvertierung oder Migration von Dokumenten nicht behandelt. Weitere Informationen zum Konvertieren von Office-Dateien aus Vorversionen und Verwenden des Kompatibilitätsmodus finden Sie unter Dokumentkompatibilität für Office 2010.

Inhalt dieses Artikels:

Einführung in die Anwendungskompatibilität in Office 2010
Bewertungs- und Wartungsprozess für die Anwendungskompatibilität
Planen von Kompatibilitätstests
Bewerten der Umgebung
Testen und Warten von Kompatibilitätsproblemen

Einführung in die Anwendungskompatibilität in Office 2010

Entwickler und erfahrene Benutzer haben seit Einführung der ersten Office-Produkte Code zum Erweitern von Office geschrieben. Office wurde durch das Ändern und Entfernen von Features und das Ändern von Dateiformaten weiterentwickelt, wodurch allerdings auch die Wahrscheinlichkeit zugenommen hat, dass ältere Add-Ins und Anpassungen in Verbindung mit Office 2010 nicht ordnungsgemäß ausgeführt. Es überrascht daher nicht, dass das Thema Anwendungskompatibilität für Organisationen mit Office-Dateien, die mindestens ein Jahrzehnt alt sind, eine Herausforderung darstellen kann.

In Office 2010 gibt es viele Produktverbesserungen und sonstige Änderungen, die sich auf die Kompatibilität mit vorhandenen Dateien, Makros, Add-Ins und Microsoft Visual Studio-Lösungen auswirken können. Dies sind einige der Änderungen.

Entfernte Funktionen Add-Ins und Anwendungen können fehlerhaft werden, wenn sie von Funktionen (und den dazugehörigen Objektmodellen) abhängig sind, die aus Office 2010 entfernt wurden.
Featureänderungen Aktualisierte Features und deren Objektmodelle können dazu führen, dass Add-Ins und Anwendungen nicht erwartungsgemäß ausgeführt werden. Manchmal sind diese Änderungen offensichtlich, und manchmal werden sie nur nach gründlichen Tests festgestellt.
64-Bit-Inkompatibilitäten Office 2010 ist als 32-Bit- und 64-Bit-Version verfügbar. Die 64-Bit-Version ist für Benutzer gedacht, die beim Arbeiten mit komplexen Microsoft Excel-Kalkulationstabellen oder Microsoft Project-Dateien mehr Arbeitsspeicherkapazität benötigen. Wenn Sie die 64-Bit-Version von Office bereitstellen möchten, müssen Sie berücksichtigen, dass ActiveX-Steuerelemente, Add-Ins und Microsoft VBA-Lösungen (Visual Basic for Applications), die für 32-Bit-Clientcomputer entwickelt wurden, möglicherweise nicht mit der 64-Bit-Version von Office 2010 kompatibel sind.

Mehrere Tools und Lösungen sind verfügbar, um Anwendungskompatibilitätsprobleme bei Office 2010 zu bewerten und zu beheben. IT-Administratoren können mit dem neuen Tool zur Bewertung der Office-Umgebung (Office Environment Assessment Tool, OEAT) Add-Ins und Anwendungen identifizieren, die mit Office interagieren. Entwickler können mit dem neuen Microsoft Office 2010 Code Compatibility Inspector-Tool zusätzliche Tests ausführen, um potenziellen inkompatiblen Code in VBA-Projekten oder Visual Studio-Code ausfindig zu machen. Wenn Anwendungen nicht repariert werden können, können Administratoren mithilfe von Lösungen wie z. B. Remotedesktopdienste (Terminaldienste), parallelen Installationen und dem neuen Microsoft Application Virtualization (App-V)-Tool die vorherige, kompatible Office-Umgebung parallel zu Office 2010 verwalten

In den folgenden Abschnitten werden die Tools zur Bewertung der Anwendungskompatibilität von Office 2010 kurz beschrieben.

Tool zur Bewertung der Office-Umgebung (Office Environment Assessment Tool, OEAT) Das OEAT ist ein neues Prüftool für Office 2010, mit dem auf den Computern der Benutzer installierte Add-Ins identifiziert werden. Das OEAT sammelt und meldet Add-In-Informationen für Microsoft Office 97, Microsoft Office 2000, Microsoft Office XP, Microsoft Office 2003 und 2007 Microsoft Office System. Außerdem vergleicht das OEAT die Liste der gefundenen Drittanbieter-Add-Ins mit einer Liste kompatibler Add-Ins, die vom Programm zur Sichtbarkeit der ISV-Anwendungskompatibilität von Microsoft nachverfolgt werden.

Das OEAT können Sie von der Webseite Office 2010: Tool zur Bewertung der Office-Umgebung (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x407) herunterladen.

Programm zur Sichtbarkeit der ISV-Anwendungskompatibilität Mit diesem neuen Programm werden unabhängige Softwareanbieter (ISVs) nachverfolgt, die die Kompatibilität ihrer Produkte mit Office 2010 zusichern. ISVs verbreiten Informationen zu ihren Produkten über ein spezielles ISV-Portal. Diese Informationen werden dann von Microsoft im Ressourcencenter Kompatibilität mit Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x407) veröffentlicht. Das OEAT weist mithilfe dieser Liste im Zusammenfassungsbericht auch auf bekannte kompatible Add-Ins hin.

Die aktuelle Liste der ISVs, die an diesem Programm teilnehmen, finden Sie unter Kompatibilität mit Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x407).

Microsoft Office 2010 Code Compatibility Inspector (OCCI) Mit dem Microsoft Office 2010 Code Compatibility Inspector wird vorhandener VBA-, Visual Basic .NET- und C#-Quellcode für Aufrufe der Objektmodell-API, die mit Office 2010 nicht kompatibel sind, verglichen. Dieses Tool ist in Microsoft Visual Basic for Applications 7.0 (VBA 7) und Microsoft Visual Studio 2008 oder Microsoft Visual Studio 2010 integriert und enthält einen einfachen Scanner. Wenn ein Inspektortool Code findet, der nicht mit Office 2010 kompatibel ist, wird dem Code ein Kommentar hinzugefügt, damit der Entwickler diesen später auffinden und korrigieren kann. Mit dem Inspektortool wird Code auch auf Declare-Anweisungen und Verweise auf DLLs hin überprüft, die von ActiveX-Steuerelementen verwendet werden, welche für die Kompatibilität mit der 64-Bit-Version von Office 2010 aktualisiert werden müssen.

Das OCCI-Tool können Sie von der Webseite Office 2010-Tool: Compatibility Inspector (https://go.microsoft.com/fwlink/?linkid=181874\&clcid=0x407) herunterladen.

In der folgenden Tabelle werden die Office-basierten Anpassungstypen, die es in vielen Organisationen gibt, sowie das Tool zum Bewerten der Anpassungen beschrieben. Da manche dieser Anpassungen für frühere Versionen von Office identisch waren, verweisen die Links zu weiteren Informationen oft auf Entwicklerdokumentation für Office 2003 und frühere Versionen.

Anpassungstyp	Beschreibung	Bewertungstool
Automatisierungs-Add-Ins (XLL oder WLL)	Mit Automatisierungs-Add-Ins können Entwickler die Funktionalität einer vorhandenen Office 2010-Anwendung in benutzerdefinierte Anwendungen integrieren. Ein Beispiel für ein Office-Automatisierungs-Add-in ist eine CRM-Anwendung, mit der Fakturierungsdaten des Kunden in ein Microsoft Excel-Arbeitsblatt geschrieben werden. Weitere Informationen zu Automatisierungs-Add-Ins finden Sie unter Excel-COM-Add-Ins und Automatisierungs-Add-Ins (https://go.microsoft.com/fwlink/?linkid=186622&clcid=0x407).	OEAT
COM-Add-In (Windows-DLL)	COM-Add-Ins wurden im Rahmen von Microsoft Office 2000 eingeführt und ermöglichen Entwicklern beim Erstellen Office-basierter Lösungen die Verwendung der Programmiersprache und Umgebung ihrer Wahl. Ein erstelltes COM-Add-In wird als DLL-Datei kompiliert. Die DLL-Datei kann von einer oder mehreren Office-Anwendungen geladen werden und mit Office-Objektmodellen interagieren. Weitere Informationen zu COM-Add-Ins finden Sie unter Was ist ein COM-Add-In? (https://go.microsoft.com/fwlink/?linkid=186623&clcid=0x407).	OEAT
VBA-Add-Ins im Office 97-2003-Format (DOT, WLL, XLA, XLL, PPA) VBA-Add-Ins im Office 2007-2010-Format (DOTM, XLAM, PPAM)	VBA-Vorlagen-Add-Ins werden mithilfe von Microsoft VBA (Visual Basic for Applications) erstellt. Weitere Informationen zu VBA-Add-Ins finden Sie unter Erste Schritte mit VBA in Office 2010 (https://go.microsoft.com/fwlink/?linkid=186624&clcid=0x407). Erklärungen zu den Unterschieden zwischen Microsoft Word-Vorlagen und -Add-Ins finden Sie unter Word-Dokumentvorlagen und Word-Add-Ins (globale Vorlagen) (https://go.microsoft.com/fwlink/?linkid=186625&clcid=0x407).	OEAT und OCCI
Dateien mit VBA-Makros im Office 2007-2010-Format (DOCM, XLSM, PPTM)	Diese Dateien enthalten VBA-Makrocode, werden aber nicht als Add-Ins gespeichert. Das OEAT erkennt Word- und Excel-Dateien mit Makros, die im Startordner gespeichert sind oder die als globale Vorlagen geladen werden. Das OEAT erkennt keine Dateien mit Makros, die in anderen Speicherorten gespeichert sind, und auch keine PowerPoint-Dateien mit Makros in einem beliebigen Speicherort. Weitere Informationen zu Dateien mit Makros finden Sie unter In Office 2010 unterstützte Dateiformate.	OEAT und OCCI
Mithilfe von Visual Studio erstellte Office-Add-Ins	Organisation können mithilfe von mit Visual Studio erstellten Office-Add-Ins Office-Anwendungen anpassen und bestimmte Features hinzufügen, die für Geschäftsprozesse erforderlich sind. Visual Studio unterstützt zwei Arten von Lösungen, die in Ihrer Organisation verwendet werden können: Anpassungen auf Dokumentebene Diese Anpassungen bestehen aus einer Assembly, die einem einzelnen Dokument, einer einzelnen Arbeitsmappe oder einer einzelnen Vorlage in Microsoft Word oder Microsoft Excel zugeordnet ist. Die Features in Anpassungen auf Dokumentebene sind nur verfügbar, wenn das zugeordnete Dokument geöffnet ist. Von diesen Anpassungen können keine Änderungen vorgenommen werden, die die gesamte Anwendung betreffen, z. B. das Anzeigen eines neuen Menüelements oder einer Menüband-Registerkarte, wenn ein beliebiges Dokument geöffnet ist. Add-Ins auf Anwendungsebene Diese Add-Ins bestehen aus einer Assembly, die einer Office-Anwendung zugeordnet ist. Mit dem Add-In kann das Objektmodell aufgerufen werden, um die Anwendungen zu automatisieren und zu erweitern, und es können alle Klassen von Microsoft .NET Framework verwendet werden. Mit dem OEAT können nur Add-Ins auf Anwendungsebene erkannt werden. Weitere Informationen zu mithilfe von Visual Studio erstellten Office-Add-Ins finden Sie unter Übersicht über die Entwicklung von Office-Projektmappen (https://go.microsoft.com/fwlink/?linkid=188380&clcid=0x407).	OEAT und OCCI

Bewertungs- und Wartungsprozess für die Anwendungskompatibilität

Die folgende Abbildung enthält eine Zusammenfassung des Bewertungs- und Wartungsprozesses für die Anwendungskompatibilität. Für jede in dieser Abbildung definierte Aufgabe gibt es einen entsprechenden Abschnitt in diesem Artikel.

Der Anwendungskompatibilitätsprozess

Hinweis

In dieser Anleitung werden die Kompatibilität, Konvertierung oder Migration von Dokumenten nicht behandelt. Weitere Informationen zum Konvertieren von Office-Dateien aus Vorversionen und Verwenden des Kompatibilitätsmodus finden Sie unter Dokumentkompatibilität für Office 2010.

Planen von Kompatibilitätstests

Die Planung der Bewertung, Wartung und Verwendung in der Pilotphase von Add-Ins und Anwendungen ist ein wichtiger erster Schritt beim Testen der Anwendungskompatibilität. Wir raten davon ab, frühere Ergebnisse von 2007 Office System-Kompatibilitätstests heranzuziehen, da dadurch nur eine erfolgreiche Bereitstellung verzögert wird.

Planen der Bewertung

In den folgenden Abschnitten werden Planungsaufgaben beschrieben, mit denen Sie die Bewertung der Add-Ins und Anwendungen in Ihrer Organisation vorbereiten können.

Erstellen des zentralen Repositorys für Bewertungsdokumentation und Ergebnisse

Zur Verwaltung des Bewertungs- und Wartungsprozesses wird empfohlen, ein zentrales Repository mit gefundenen Anwendungen und deren Status zu erstellen. Mit einer Lösung wie z. B. Microsoft SharePoint Server 2010 sind alle Projektmitglieder stets auf dem neuesten Stand und das Projekt selbst auf dem besten Weg.

Identifizieren der Beteiligten

Beteiligte sind jene Personen oder Gruppen, die Ressourcen für das Projekt genehmigen und zuordnen. Durch das Identifizieren der Beteiligten in einer frühen Phase des Planungsprozesses kann das Projektteam für die Anwendungskompatibilität den Projektlieferumfang überprüfen und den Personen mit einem berechtigten Interesse mitteilen.

In der folgenden Tabelle werden die typischen Beteiligtenrollen in einem Anwendungskompatibilitätsprojekt beschrieben.

Rolle	Zuständigkeit
Anwendungsbesitzer	Stellt sicher, dass der mit der früheren Version von Office ausgeführte Geschäftsprozess nach dem Upgrade ohne Unterbrechung fortgesetzt wird.
Projektsponsor	Wirbt innerhalb der Organisation für den Erfolg des Office-Upgrades und sorgt für eine positive Wahrnehmung.

Zuweisen von Rollen für die Projektteilnehmer

In der folgenden Tabelle werden mögliche Rollen und die entsprechenden Zuständigkeiten für ein Anwendungskompatibilitätsprojekt beschrieben.

Rolle	Zuständigkeit
Projektmanager	Stellt den Projektfluss insgesamt sicher und verwaltet allgemein die Ressourcen, Metriken und Risiken.
Kompatibilitätsvalidierungstester	Testet anhand des Testplans Office-Komponenten auf potenzielle Inkompatibilitätsprobleme, einschließlich Dateiformat, Makros, Add-Ins oder Office-Automatisierung.
OEAT-Bediener	Ist mit der Installation und Konfiguration von OEAT vertraut und führt diese Schritte aus.
Wartungsleiter	Führt die Aktionen zum Beheben von Kompatibilitätsproblemen für Office-Anpassungen aus.
Regressionstester	Stellt sicher, dass die für ein Office-Objekt ausgeführte Wartung erfolgreich ist. Diese Rolle wird oft vom Wartungsleiter übernommen.
Benutzerakzeptanztester	Der Vertreter einer betroffenen Unternehmenseinheit, der bestimmt, dass die Wartung einer Anwendung erfolgreich war und dass es keine negativen Auswirkungen auf andere Anpassungen oder Aktionen gibt. Dies sollte auf keinen Fall die Person sein, die die Wartung oder die Regressionstests vornimmt.
Business Analyst oder Besitzer	Besitzt den Code und die Dokumentation der Anwendungen und Add-Ins, die für die Unternehmenseinheit eine wichtige Rolle spielen.
Leiter des Bereitstellungsteams	Kontrolliert und verfolgt die Pünktlichkeit des gesamten technischen Prozesses. Er kann bestimmte Berichterstellungs- oder Verwaltungsaktivitäten delegieren.
Anwendungsverpackungsteam	Besitzt das Office 2010-Installationspaket.
Client (Desktop)-Team	Besitzt die Bereitstellung des Office 2010-Pakets über das Konfigurationsverwaltungstool der Organisation, wie z. B. Systems Center Configuration Manager (SCCM).
Kundendienst	Bietet den Testern, und nach Abschluss der Migration den Benutzern, funktionalen Support für Office.

Identifizieren der Unternehmenseinheiten und Gespräch mit deren Vertretern

Der nächste Schritt bei der Bewertungsplanung ist das Identifizieren der Abteilungen und Unternehmenseinheiten und ein Gespräch mit deren Vertretern, um festzustellen, inwieweit die aktuell vorhandenen Add-Ins den Anforderungen des Unternehmens entsprechen. Die Kenntnis der Bedeutung jedes Add-Ins, dessen Zweck, weshalb es entwickelt wurde, welche Aktionen damit ausgeführt werden und von wem es entwickelt wurde spielen eine wichtige Rolle, um eine fundierte Entscheidung zu treffen, wie das Add-In gewartet werden soll und wie gefundene Probleme behoben werden sollen.

Einige Add-Ins für Office-Anwendungen wurden möglicherweise inoffiziell in Ihrer Organisation erstellt. Deshalb müssen Sie eventuell Untersuchungen anstellen, um den Besitzer und, soweit noch vorhanden, den ursprünglichen Quellcode zu ermitteln.

Das folgende Formular können Sie als Vorlage für den Gesprächsfragebogen verwenden.

Anwendungsinformationen

Unternehmenseinheit

Name der Anwendung

Kontakt/Besitzer der Anwendung

Anwendungs-ID

Version

Priorität

Ebene

Office 2010-Kompatibilitätsstatus soweit bekannt (Erfolgreich, Fehler)

Beschreibung des Kompatibilitätsproblems (soweit vorhanden)

Anzahl der Benutzer

Von der Anwendung verwendete Office-Version (XP, 2003, 2007, 2010 usw.)

Beschreibung der Nutzungsart (z. B. exportiert ein Office-Dokument, Add-In nach einer Office-Anwendung usw.)

Von der Anwendung verwendete Office Suite-Komponenten

Word

Excel

Access

PowerPoint

Andere

Verwendet diese Anwendung komplexe Office-Objekte wie z. B. Diagramme, PivotTable-Berichte oder Grafiken?

Handelt es sich um eine Dateneingabe- oder Front-End-Anwendung? Falls ja, Details angeben.

Welche Sprache(n) wird/werden von der Anwendung unterstützt?

Identifizieren der zu überprüfenden Clientcomputer

Nachdem Sie die verschiedenen Unternehmenseinheiten bestimmt haben, deren Clientcomputer überprüft werden müssen, können Sie mit dem Identifizieren einer statistisch relevanten Auswahl von Clientcomputern für jede Unternehmenseinheit beginnen. Nicht jeder Clientcomputer in Ihrer Organisation muss überprüft werden. Manchmal ist jedoch (in Abhängigkeit von der Größe der Organisation) die Überprüfung der gesamten Umgebung oder einer kompletten Gruppe oder Organisationseinheit (Organizational Unit, OU) möglicherweise mit weniger Einschränkungen verbunden (oder einfacher) als die Festlegung der einzubeziehenden separaten Clientcomputer. Eine statisch relevante Auswahl von maximal 20 % sollte ausreichend Informationen liefern, um die Kompatibilitätsprobleme in Ihrer Office 2010-Umgebung erfolgreich zu bewerten und zu beseitigen.

Wichtig

Auf allen Clientcomputern, auf denen das OEAT ausgeführt wird, muss Microsoft .NET Framework 2.0 oder eine höhere Version installiert sein. Weitere Informationen zu den Anforderungen für das OEAT finden Sie unter Anleitung für das Tool zur Bewertung der Office-Umgebung (OEAT) für Office 2010.

Wenn in Ihrer Organisation keine aktuelle Clientinventur vorhanden ist, sollten Sie eventuell das Microsoft Assessment and Planning (MAP) Toolkit ausführen, um eine Clientinventur zu generieren und die Bereitschaft von Office 2010 zu bewerten. Anhand dieser Clientinventur können Sie zusammen mit Unternehmensteamleitern einen Teil der Clientcomputer für die Bewertung durch das OEAT auswählen. Weitere Informationen zum MAP-Toolkit finden Sie unter Microsoft Assessment and Planning Toolkit (https://go.microsoft.com/fwlink/?linkid=149448\&clcid=0x407).

Planen der Wartung

Mithilfe der folgenden Abschnitte können Sie grundlegende Kriterien zum Klassifizieren und Warten inkompatibler Anwendungen aufstellen. Wenn Sie in einer frühen Phase des Planungsprozesses eine Vereinbarung treffen, können Sie nach der Verfügbarkeit der Bewertungs- und Testergebnisse Unstimmigkeiten oder sonstige Verzögerungen vermeiden.

Bestimmen der Methode zum Klassifizieren und Priorisieren

In Unternehmen werden viele Office-basierte Anwendungen und Add-Ins entwickelt, bereitgestellt und gewartet, wobei jedes Unternehmen ganz unterschiedliche Prioritäten haben kann. Deshalb müssen Anwendungen basierend auf deren Bedeutung für das Unternehmen unbedingt in Klassen oder Stufen angeordnet werden. Eine einfache Methode ist das Klassifizieren einer Anwendung als kritisch. Die folgenden zusätzlichen Klassifikationen sollten berücksichtigt werden:

Interne Anwendungen und Drittanbieteranwendungen
Abteilungsanwendungen
Nicht verwaltete Lösungen wie z. B. von Endbenutzern erstellte Vorlagen, Add-Ins und Makros
Anzahl der Benutzer für die Anwendung
Verwendung der Anwendung durch Führungskräfte
Voraussichtliche Lebensdauer der Anwendung

In der folgenden Tabelle wird beschrieben, wie in einer Organisation unterschiedliche Office-Anpassungstypen klassifiziert und priorisiert werden können.

Anpassung	Kritisch	Nicht kritisch
Automatisierungs-Add-Ins	Proaktive(r) OEAT-Überprüfung, -Test und -Wartung	Reaktion auf gefundenen Benutzer
COM-Add-Ins	Proaktive(r) OEAT-Überprüfung, -Test und -Wartung	Reaktion auf gefundenen Benutzer
VBA-Add-Ins	Proaktive(r) OEAT- und OCCI-Überprüfung, -Test und -Wartung	Reaktion auf gefundenen Benutzer

Für die weitere Priorisierung von kritischen Anwendungen können Sie diese als Stufe 1, Stufe 2 oder Stufe 3 klassifizieren. Es folgen Beispiele für die Klassifizierung der verschiedenen Stufen:

Stufe 1: Kritisch Ein Fehler bei kritischen Anwendungen schadet der Geschäftskontinuität oder dem Umsatz der Organisation. Jede Anwendung, die von Führungskräften verwendet wird, sollte als kritisch betrachtet werden, unabhängig von der Anzahl der Benutzer oder der Priorität der Anwendung für das Unternehmen. Zu dieser Stufe gehören auch Anwendungen, die von mehr als 10 % der Benutzer in der Organisation verwendet werden.
Stufe 2: Unternehmenswichtig Diese Anwendungen sind unternehmenswichtig oder werden von mindestens 10 % der Benutzer in der Organisation verwendet. Zu dieser Stufe können auch Anwendungen zählen, die von 1 bis 10 % der Benutzer in der Organisation verwendet werden und eine Priorität für das Unternehmen aufweisen. Diese Anwendungen sind nicht kritisch und haben keine Auswirkungen auf den Umsatz. Sie könnten jedoch indirekt die Ausgaben erhöhen oder den Umsatz durch eine geringere Produktivität senken.
Stufe 3: Geschäftsanwendungen Diese Anwendungen sind nicht kritisch und betreffen nur maximal 10 Mitarbeiter oder maximal 1 % der Organisation. Hierbei handelt es sich in der Regel um Tools, die für kleinere Aufgaben verwendet werden und geringe Auswirkungen auf das Geschäft haben.

Identifizieren der Wartungsstrategien

Nachdem Sie Kriterien zum Klassifizieren der Anwendungen definiert haben, sollten Sie potenzielle Wartungsstrategien identifizieren. Die Planung der eigentlichen Wartungsarbeiten ist zwar schwierig, aber Sie können allgemeine Strategien als Grundlage zum Beheben von Problemen für jeden Anpassungstyp aufstellen. Die folgende Tabelle enthält Vorschläge zu Wartungsstrategien basierend auf dem Anwendungstyp und der voraussichtlichen Lebensdauer.

Typ	Potenzielle Strategie
Interne Anwendung mit begrenzter Lebensdauer	Zurückziehen der Anwendung und Suchen nach einem neuen Prozess
Interne Anwendung mit langer Lebensdauer	Neuerstellen oder Umschreiben des Codes gemäß dem neuen Objektmodell
Drittanbieteranwendung mit begrenzter Lebensdauer	Zurückziehen der Anwendung und Suchen nach einem neuen Prozess
Drittanbieteranwendung mit langer Lebensdauer	Kontaktaufnahme mit dem Hersteller wegen eines Updates oder Umtauschs
Anwendung ist nicht funktionsfähig	Neuinstallieren der Anwendung mit einer neuen Verzeichnisstruktur oder Erstellen einer virtuellen Umgebung für die Anwendung

Beim Warten der Anwendungen stellen Sie möglicherweise fest, dass deren Priorität von der ursprünglichen Bewertung abweicht. Sie sollten sich an einen strikten Prozess für Wartungsbewertungen halten, sodass eine Anwendung bei den Stufen nur nach oben (aber nicht nach unten) verschoben werden darf. Weitere Informationen zur Vorgehensweise beim Kategorisieren und Priorisieren von Anwendungen durch Microsoft IT finden Sie unter Bereitstellen von 2007 Office System bei Microsoft (https://go.microsoft.com/fwlink/?linkid=178278\&clcid=0x407).

Microsoft stellt auch auf der TechNet-Website Informationen zu bekannten Problemen beim Migrieren von Office-Anpassungen bereit. Weitere Informationen finden Sie unter Änderungen bei Produkten und Features in Office 2010. Darüber hinaus gibt es Microsoft-Partner, die Tools zur Unterstützung des Wartungsprozesses entwickelt haben.

Planen der Pilotphase

Das Projektteam muss sich überlegen, wie Add-Ins und Anwendungen in der Pilotphase verwendet werden sollen. Das Team sollte insbesondere Folgendes festlegen:

Welche Benutzer an der Pilotphase teilnehmen.
Wie Benutzer in der Pilotphase Probleme melden.
Ob Helpdeskmitarbeiter die Pilotphase unterstützen und wie sie ggf. geschult werden.
Wann die Pilotphase beginnt. Beispielsweise beginnen manche Organisationen die Tests für die Pilotphase frühzeitig, während der Planungsphase, um im Laufe des Prozesses zu einem frühen Zeitpunkt Feedback zu erhalten.

Die folgenden Ressourcen sind zur Unterstützung beim Planen der Pilotphase verfügbar. Diese Ressourcen gelten nicht speziell für Office 2010-Kompatibilitätstests. Viele der in diesen Ressourcen behandelten Prinzipien gelten jedoch auch weiterhin.

Bewerten der Umgebung

Während der Bewertungsphase erfassen Sie eine Reihe von Add-Ins und Anwendungen, indem Sie das Tool zur Bewertung der Office-Umgebung (Office Environment Assessment Tool, OEAT) für eine statistisch relevante Auswahl von Clientcomputern ausführen. Nach der Analyse der Ergebnisse und der Priorisierung der Anwendungen können Sie mit der Test- und Wartungsphase fortfahren.

Ausführen von OEAT

Das OEAT kann in einer Netzwerkfreigabe ausgeführt oder an Benutzer verteilt werden. Mit dem OEAT werden Clientcomputer überprüft, und anschließend werden die Ergebnisse der Überprüfungen in einem festgelegten Speicherort gespeichert (in der Regel in einer Netzwerkfreigabe). Wenn Sie die Überprüfungen abgeschlossen haben, können Sie mit dem OEAT die Ergebnisse zur Verwendung beim Wartungsprozess als Microsoft Excel-Kalkulationstabelle kompilieren.

Je nach Umgebung können Sie das OEAT mithilfe einer der folgenden Methoden bereitstellen:

Active Directory-Umgebungen Stellen Sie das OEAT mithilfe eines Active Directory-Anmeldeskripts bereit. Wenn sich die Benutzer anmelden, wird das OEAT automatisch ausgeführt, und die Ergebnisse werden im festgelegten Speicherort gespeichert.
Verwaltete Umgebungen Stellen Sie das OEAT mithilfe einer Verwaltungslösung wie z. B. Systems Management Server (SMS) oder System Center Configuration Manager (SCCM) bereit.
Nicht verwaltete oder nicht zentralisierte IT-Umgebungen Erstellen Sie eine Freigabe für das OEAT, und geben Sie den Benutzern Anweisungen zum manuellen Ausführen einer Überprüfung.

Weitere Informationen zum Bereitstellen und Verwenden des OEAT finden Sie unter Anleitung für das Tool zur Bewertung der Office-Umgebung (OEAT) für Office 2010. Das OEAT können Sie von der Webseite Office 2010: Tool zur Bewertung der Office-Umgebung (https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x407) herunterladen.

Überprüfen der OEAT-Ergebnisse

Wenn die Überprüfungen der Clientcomputer abgeschlossen sind, erstellen Sie mithilfe der Option Compile results im OEAT eine Kalkulationstabelle mit einer Zusammenfassung der Ergebnisse aller Clientcomputer, die überprüft wurden. Die Kalkulationstabelle enthält mehrere Arbeitsblätter:

SummaryReport Dieses Arbeitsblatt enthält zusammenfassende Informationen, mit deren Hilfe Sie entscheiden können, ob die überprüften Clientcomputer für Office 2010 bereit sind. Dabei handelt es sich um Daten zum durchschnittlich freien Speicherplatz, zu Prozessoren, Computerherstellern, Windows-Installationen (einschließlich Service Pack-Stufen) und Office-Installationen. Die Ergebnisdaten könnten aus Sicht der Konfigurationsverwaltung interessant sein, da auf den Clientcomputern möglicherweise nicht die erwarteten Versionen von Office oder Windows ausgeführt werden.
MicrosoftOfficeAddins Dieses Arbeitsblatt enthält eine List aller Add-Ins, die im Lieferumfang von Office enthalten sind.
AddinsNotShippedWithOffice Dieses Arbeitsblatt enthält eine Liste aller Add-Ins, die nicht im Lieferumfang von Office enthalten sind. Ein Großteil Ihrer Bewertung und Planung beruht auf diesem Bericht. Sie können die Liste nach der Anwendung sortieren, die zuletzt aufgerufenen oder geänderten Elemente anzeigen sowie die Anzahl der Clientcomputer anzeigen, auf denen das Add-In erkannt wurde. Darüber hinaus können Sie Versionsnummern derselben Add-Ins vergleichen, um festzustellen, ob einige Clientcomputer veraltet sind. Dies könnte ein Hinweis auf ein Problem bei Konfigurationsverwaltungsprozessen in Ihrer Organisation sein.

Beginnen Sie im Arbeitsblatt AddinsNotShippedWithOffice zunächst mit der Spalte Compatibility und dem Kompatibilitätsstatus jedes Add-Ins. Das OEAT generiert die Daten für diese Spalte durch Vergleichen der gefundenen Add-Ins mit der Liste kompatibler Add-Ins, die vom Programm zur Sichtbarkeit der ISV-Anwendungskompatibilität nachverfolgt werden. Die folgenden Kompatibilitätsstatusergebnisse sind möglich:

UNKNOWN Das Add-In ist derzeit nicht in der Microsoft-Händlerliste mit Office 2010-kompatiblen Add-Ins aufgeführt. Deshalb ist der Status dieses Add-Ins unbekannt. Beachten Sie, dass sich dieser Status ändern kann, wenn dem OEAT neue Herstellerdaten zur Verfügung gestellt werden. Bei jeder Kompilierung des Arbeitsblatts haben Sie die Möglichkeit, neue Herstellerdaten herunterzuladen.
PARTIAL MATCH Das OEAT meldet diesen Status in zwei Situationen. Zum einen, wenn das OEAT nur eine Übereinstimmung für den Herstellernamen gefunden hat. Zum anderen, wenn das OEAT eine Übereinstimmung für den Herstellernamen und den Produktnamen gefunden hat, aber die Versionsnummer nicht übereinstimmte. Verwenden Sie den in der Spalte URL vorhandenen Link, um die Herstellerliste auf kompatible Add-Ins des Herstellers zu überprüfen.
EXACT MATCH Dieser Status wird angezeigt, wenn der Herstellername übereinstimmt, der Produktname übereinstimmt und die Versionsnummer des Add-Ins gleich oder größer als die vom Hersteller gemeldete Version ist.

Wichtig

Die Spalte Compatibility wird nicht angezeigt, wenn Sie bei der entsprechenden Aufforderung in der endgültigen Version des OEAT angegeben haben, dass keine Kompatibilitätsdaten heruntergeladen werden sollen, oder wenn Sie die Betaversion des OEAT verwenden. Die endgültige Version des OEAT können Sie von der Webseite Microsoft Download Center herunterladen.

Abschließen der Wartungspläne

Nun sind Sie bereit, die OEAT-Ergebnisse mit den Priorisierungskriterien, die Sie in der Planungsphase aufgestellt haben, zueinander in Beziehung zu setzen. Wenn Sie einen Zeitplan für diese Arbeit festlegen, sollten Sie zusätzliche Zeit zum Prüfen und Priorisieren von Add-Ins einplanen, die bei den Gesprächen mit den Unternehmenseinheiten nicht identifiziert wurden. Um den Umfang der Inkompatibilitäten von VBA-Add-Ins und Visual Studio-Add-Ins zu ermitteln, kann das Entwicklungsteam OCCI in dieser Phase ausführen, um festzustellen, wie viel des zugrunde liegenden Codes geändert werden muss.

Testen und Warten von Kompatibilitätsproblemen

In dieser Phase beginnen Sie und Ihr Entwicklungsteam mit dem Testen kritischer Add-Ins und Anwendungen sowie anderer Add-Ins und Anwendungen mit hoher Priorität , um nach bestimmten Kompatibilitätsproblemen bei Office 2010 zu suchen. Nachdem die Inkompatibilitäten identifiziert wurden, beginnt das Entwicklungsteam basierend auf den Ergebnissen der Planungsphase mit der Wartung inkompatibler Add-Ins und Anwendungen.

Wenn mehrere Anwendungen und Add-Ins gewartet werden, können Sie nicht davon ausgehen, dass sie anschließend miteinander kompatibel sind. Sie müssen alle gewarteten Komponenten gemeinsam testen und anschließend in einem Pilotprojekt unter realen Bedingungen verwenden. Jeder Schritt spielt beim Überprüfen der Wartungsschritte eine wichtige Rolle, da dadurch die gesamte Bereitstellung von Office 2010 stabilisiert und letztlich eine erfolgreichere Migration ermöglicht wird.

Testen von Add-Ins und Anwendungen

Die folgenden Flussdiagramme enthalten allgemeine Anweisungen für Entwickler, die unterschiedliche Anwendungstypen testen, um Inkompatibilitäten bei Office 2010 zu identifizieren. Weitere Anweisungen finden Sie in den folgenden Ressourcen:

Allgemeine Anwendungstests

Das folgende Flussdiagramm bietet einen Überblick über Anwendungstests. In nachfolgenden Flussdiagrammen in diesem Abschnitt werden die Prozesse zum Testen bestimmter Office-Anwendungen beschrieben, wie z. B. Add-Ins, Makros und Skripts sowie der Office-Automatisierung.

Flussdiagramm für Anwendungstest

Testen von Office-Add-Ins

Flussdiagramm für Office-Add-In-Test

Testen von Makros und Skripts

Flussdiagramm für Makrotest

Testen der Office-Automatisierung

Flussdiagramm für automatischen Office-Test

Ausführen des Office Code Compatibility Inspector-Tools

Im Rahmen des Testprozesses können Entwickler das Office Code Compatibility Inspector-Tool (OCCI) ausführen, um nach bekannten Änderungen oder veralteten Elementen bei Objektmodellelementen zu suchen. Mit OCCI werden auch Declare-Anweisungen von VBA und Verweise auf DLLs überprüft, die von ActiveX-Steuerelementen verwendet werden, welche für die Kompatibilität mit der 64-Bit-Version von Office 2010 aktualisiert werden müssen. Wenn das Tool potenzielle Kompatibilitätsprobleme findet, wird im Code ein Kommentar hinzugefügt, um den Entwickler auf die Probleme hinzuweisen.

Nach jeder Überprüfung mit dem Inspector werden eine Zusammenfassung und ein detaillierter Bericht der im Projekt gefundenen Probleme erstellt. Die folgenden Elemente werden überprüft:

Änderungen Jede syntaktische Änderung an einem Objektmodellelement wird gekennzeichnet. OCCI erkennt die Verwendung jedes Objektmodellelements, das seit Office 97 geändert wurde.
Veraltete Elemente Jede Verwendung eines veralteten Objektmodellelements wird gekennzeichnet. OCCI erkennt die Verwendung jedes Objektmodellelements, das seit Office 97 veraltet ist.

Weitere Informationen zur OCCI-Verwendung finden Sie unter Benutzerhandbuch für Microsoft Office Code Compatibility Inspector. Anwendungsspezifische Entwicklungsressourcen, z. B. Details zu Änderungen am Objektmodell im Vergleich zu früheren Versionen von Office, finden Sie unter Microsoft Office 2010 (https://go.microsoft.com/fwlink/?linkid=206197\&clcid=0x407).

Warten von Add-Ins und Anwendungen

Es gibt mehrere Vorgehensweisen, um eine Anwendung oder ein Add-In zu korrigieren, das ein Kompatibilitätsproblem mit Office 2010 aufweist. In den folgenden Abschnitten werden die Wartungsoptionen kurz beschrieben.

Besorgen von Updates von Herstellern

OEAT-Berichte enthalten Links zu Add-Ins, von denen bekannt ist, dass sie kompatibel sind. Möglicherweise sind jedoch nicht alle Anwendungen aufgelistet. In diesem Fall müssen Sie sich direkt an den Hersteller wenden. Sie sollten temporäre Problemumgehungen entwickeln, falls das aktualisierte Add-In für Ihre Migration nicht rechtzeitig verfügbar ist oder falls das Add-In nicht aktualisiert wird (oder es den Hersteller nicht mehr gibt). Für den Fall, das keine temporäre Problemumgehung verfügbar ist, sollten Sie die Virtualisierung oder eine parallele Installation in Betracht ziehen.

Aktualisieren interner Anwendungen

Wenn Sie den Quellcode besitzen und die Funktionsweise des Add-Ins oder der Anwendung kennen, oder wenn Sie die Dokumentation besitzen und das ursprüngliche Entwicklungsteam noch existiert oder kontaktiert werden kann, liegt eine ideale Situation zum Aktualisieren einer internen Anwendung vor. Der Aktualisierungsvorgang für interne Anwendungen wird durch die Verwendung von OCCI wesentlich vereinfacht. Dieses Tool identifiziert inkompatible Funktionen im Quellcode. Das Entwicklungsteam muss auch weiterhin die erforderlichen Reparaturen selbst vornehmen. Das Auffinden des inkompatiblen Codes ist jedoch mit OCCI erheblich einfacher.

Hinweis

Falls die zum Schreiben der internen Anwendung verwendete Plattform sehr alt ist (z. B. Visual Basic 6 oder frühere Versionen), empfiehlt es sich, das Tool mithilfe von .NET Framework komplett neu zu schreiben.

Die folgenden Anweisungen sind für Entwickler hilfreich, die interne Anwendungen aktualisieren müssen.

Mithilfe von Visual Studio erstellte Add-Ins

Die Laufzeitkomponenten für Office 2010 wurden so erstellt, dass alle Add-Ins, Dokumentlösungen und Tabellenvorlagen von Microsoft Visual Studio Tools for Applications (VSTA) und Visual Studio 2008 .NET unter der 64-Bit-Version von Office 2010 ausgeführt werden. Diese Laufzeitkomponenten werden zusammen mit Office 2010 installiert. Deshalb muss der Administrator keine separate Installation für diese Laufzeit verwenden. Es müssen jedoch andere Punkte berücksichtigt werden.

In einem Visual Studio-Projekt kann C#- oder Visual Basic-Code in MSIL (Microsoft Intermediate Language) kompiliert werden, wenn die Option Beliebige CPU verwendet wird. Zur Laufzeit wird MSIL mit dem Just-In-Time-Compiler (JIT) in den entsprechenden Chipsatz kompiliert, und zwar entweder AMD oder Intel 32-Bit bzw. 64-Bit. Diese Technologie kann jedoch nicht für .NET Framework, Version 1.0 und 1.1, verwendet werden. Für diese Versionen ist die 64-Bit-Transformation nicht möglich.

Selbst kompatibler .NET Framework 2.0-Code muss geprüft werden, da alle Aufrufe eines Prozessauslösers (p/invoke) im Code systemeigen sind (abhängig von der Prozessorarchitektur). Beim Versuch, systemeigene API-Methoden mithilfe von p/invoke aufzurufen, kann es sein, dass Ihre VSTO-Lösung unter der 64-Bit-Version von Office 2010 nicht ordnungsgemäß ausgeführt wird.

Probleme können auch auftreten, wenn im Code absichtlich eine Win32-API aufgerufen wird, die nicht genau die gleiche Signatur (Methodenname, Parameterliste und DLL-Name) wie eine entsprechende Win64-API aufweist. Dies gilt für jede Lösung, unabhängig davon, ob es sich um eine Office-Lösung oder eine Windows-basierte Lösung handelt.

Weitere Informationen zum Erstellen von Lösungen für die 64-Bit-Version von Office 2010 finden Sie unter 64-Bit-Anwendungen für Visual Studio 2005 (https://go.microsoft.com/fwlink/?linkid=178279\&clcid=0x407) und 64-Bit-Anwendungen für Visual Studio 2010 (https://go.microsoft.com/fwlink/?linkid=152431\&clcid=0x407) in der MSDN Library.

VBA-Lösungen und -Makros

Mithilfe von Visual Basic for Applications (VBA) erstellte Lösungen und Makros sind funktionsfähig, wenn sie eine Schnittstelle mit dem Office 2010-Objektmodell aufweisen. Bestimmte Aufrufe sind jedoch möglicherweise veraltet und werden deshalb nicht mehr ausgeführt. Falls in VBA-Code Windows-API-Aufrufe verwendet werden, erfolgen diese Aufrufe wahrscheinlich für 32-Bit-DLLs. Dies können Sie einfach beheben, indem Sie den Code aktualisieren, sodass für die Declare-Anweisungen das PtrSafe-Schlüsselwort verwendet wird. Diese Declare-Anweisungen können mit OCCI identifiziert werden. Weitere Informationen zur VBA-64-Bit-Kompatibilität finden Sie unter Kompatibilität zwischen der 32-Bit-Version und der 64-Bit-Version von Office 2010 (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x407).

ActiveX-Steuerelemente

ActiveX-Steuerelemente, die systemeigene 32-Bit-Steuerelemente sind (wahrscheinlich Steuerelemente, die mit 2007 Office System und früheren Office-Versionen kompatibel sind), werden in der 64-Bit-Version von Office 2010 nicht unterstützt. Für diese Steuerelemente müssen Sie den Code erneut kompilieren (falls der Quellcode verfügbar ist), ein Update des Herstellers anfordern oder darauf warten oder aber eine Virtualisierungsmethode verwenden. Weitere Informationen zur VBA-64-Bit-Kompatibilität finden Sie wiederum unter Kompatibilität zwischen der 32-Bit-Version und der 64-Bit-Version von Office 2010 (https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x407).

Outlook-Anwendungen

Outlook 2010 erzwingt einen neuen schnellen Herunterfahrvorgang für Add-Ins. Dieser neue Vorgang hindert Add-Ins am Verursachen langer Verzögerungen durch Blockieren von Ressourcen, nachdem der Benutzer Outlook beendet hat. Da sich diese Änderung negativ auf einige vorhandene Add-Ins auswirken kann, können Add-In-Anbieter und IT-Administratoren diese Auswirkungen vermeiden, indem Sie Outlook zwingen, zum standardmäßigen Herunterfahrvorgang für Add-Ins zurückzukehren. Weitere Informationen zum neuen Vorgang für das Herunterfahren finden Sie unter Änderungen beim Herunterfahren für Outlook 2010 (https://go.microsoft.com/fwlink/?linkid=203255\&clcid=0x407).

Exchange-Clienterweiterungen werden in Outlook 2010 nicht geladen. Verschiedene Drittanbieteranwendungen, z. B. Archivierungs- und Sicherheitslösungen, arbeiten mit Exchange-Clienterweiterungen und müssen für Outlook 2010 aktualisiert werden. Weitere Informationen finden Sie unter Ankündung des Auslaufens der Unterstützung von Exchange-Clienterweiterungen (https://go.microsoft.com/fwlink/?linkid=203888\&clcid=0x407).

Bei Installation der 64-Bit-Version von Outlook 2010 müssen 32-Bit-Versionen von MAPI-Anwendungen, Add-Ins und Makros für Outlook auf 64-Bit aktualisiert werden. Weitere Informationen finden Sie unter 64-Bit-Editionen von Office 2010, Erstellen von MAPI-Anwendungen auf 32-Bit- und 64-Bit-Plattformen (https://go.microsoft.com/fwlink/?linkid=203889\&clcid=0x407) und Entwickeln von Outlook 2010-Lösungen für 32-Bit- und 64-Bit-Systeme (https://go.microsoft.com/fwlink/?linkid=208699\&clcid=0x407).

Verwenden paralleler Installationen oder der Virtualisierung

Wenn keine passende Lösung zum Neucodieren oder erneuten Schreiben vorhanden ist, gibt es zusätzliche Optionen, um nach einer Lösung für ein Kompatibilitätsproblem zu suchen.

Falls Sie auf Updates des Herstellers für ein Add-In warten, das nach dem Datum Ihrer Bereitstellung verfügbar sein wird, können Sie Office 2003 oder eine frühere Version parallel zu Office 2010 installieren (oder nur die Anwendungen, für die Updates vom Hersteller ausstehen, wie z. B. Office Excel 2003).

Hinweis

Falls Sie auf eine 64-Bit-Version von Office 2010 umstellen, ist eine parallele Installation von 2007 Office System (oder einer früheren Version) nicht möglich. Alle vorherigen Versionen sind nur als 32-Bit-Versionen verfügbar.
Falls Sie Windows 7 ausführen, können Sie eine parallele Installation von Office 2003 (oder eine frühere Version) im Windows XP-Kompatibilitätsmodus vornehmen. Falls Sie eine ältere Version von Office verwenden, können Sie in einer virtuellen Computerumgebung installieren.
Verwenden Sie App-V (wurde früher als SoftGrid bezeichnet). Weitere Informationen zu App-V finden Sie unter Microsoft Application Virtualization 4.6 (https://go.microsoft.com/fwlink/?linkid=143973\&clcid=0x407).
Verwenden Sie die Windows-Terminaldienste, und führen Sie einen der folgenden beiden Schritte aus:
- Falls Sie Windows Server 2003 verwenden, können Sie mithilfe der Windows-Terminaldienste Desktopcomputer bereitstellen, auf denen diese Lösungen mit einer früheren Version von Office remote ausgeführt werden können.
- Falls Sie Windows Server 2008 verwenden, können Sie RemoteApp installieren. Die Benutzer arbeiten auf Ihren Clientcomputern dann scheinbar in einer ähnlichen Benutzeroberfläche wie sie dies von der älteren Anwendung und der Vorversion von Office gewohnt sind. Weitere Informationen zu RemoteApp finden Sie unter Bereitstellen von Windows Server 2008 RemoteApp für Terminaldienste (https://go.microsoft.com/fwlink/?linkid=178280\&clcid=0x407).

Pilotphase für gewartete Add-Ins und Anwendungen

Die Pilotphase ist der letzte wichtige Schritte vor der Bereitstellung von Office 2010. In dieser Phase müssen sich die gewarteten Optionen letztlich bewähren. Das Projektteam sollte während der gesamten Pilotphase für Office 2010 beteiligt sein, um etwaige Probleme zu erkennen und zu beheben. Während der Pilotphase überwacht Ihr Releaseverwaltungsteam eine kontrollierte Umgebung, in der Benutzer ihre typischen Geschäftsaufgaben mithilfe der neuen Features ausführen, einschließlich gewarteter Anwendungen und Add-Ins, die mit Office 2010 interagieren. Dabei wird nachgewiesen, dass sich die gewarteten Komponenten erwartungsgemäß verhalten und dass die Geschäftsanforderungen der Organisation erfüllt werden.

Wenn in der Pilotphase Probleme gemeldet werden, sollten Sie diese mittels eines Iterationsverfahrens beheben, einen neuen Testfall erstellen, Tests durchführen und anschließend die aktualisierten Anwendungen wieder im Pilotprojekt für die zusätzliche Überprüfung bereitstellen. Ihr Hauptaugenmerk sollte dabei der Funktionsweise dieser Optionen, dem Benutzerfeedback und Problemen, durch die der Leistungsumfang oder die Funktionalität des gewarteten Add-Ins oder der gewarteten Anwendung eingeschränkt wird, gelten.

Weitere Informationen zum Stabilisieren von Anwendungen und Ausführen eines Pilotprojekts finden Sie unter Stabilisieren der Dienstverwaltungsfunktion (https://go.microsoft.com/fwlink/?linkid=115624\&clcid=0x407) in Microsoft Operations Framework 4.0 in der TechNet-Bibliothek.