Skip to main content

Fünf Schritte, um Anwendungen mit Windows 8 kompatibel zu machen

In diesem Artikel:


Optimieren des Anwendungsanalyse- und -testprojekts

„Was ist unser nächstes Projekt? Unsere Anwendungen testen, um uns auf Windows 8 vorzubereiten? Kein Problem, Chef. Wir müssen dafür nur ungefähr 950 Anwendungen analysieren …“

Wie gründlich Sie die Anwendungskompatibilität im Rahmen des Migrationsprojekts überprüfen, bestimmt, ob die Betriebssystembereitstellung relativ problemlos verläuft oder ob Sie Gefahr laufen, Ihrem IT-Team einen Ansturm von Helpdeskanrufen und Schuldzuweisungen und unzählige Überstunden zuzumuten.

Als Unternehmen vor einigen Jahren mit der Evaluierung von Windows Vista begannen, war die Anwendungskompatibilität ein Punkt, der bei vielen den Umstieg zum Stillstand brachte. In einigen Fällen waren wichtige Anwendungen einfach nicht für Windows Vista verfügbar. In anderen Fällen hatten die Unternehmen weder das Budget noch den Wunsch, eine neue für Windows Vista konzipierte Version zu lizenzieren. Und schließlich handelte es sich in einigen Fällen bei wichtigen Anwendungen um angepasste oder interne Entwicklungen, und die ursprünglichen Entwickler waren entweder nicht mehr im Unternehmen angestellt oder aus anderen Gründen nicht verfügbar, um den Code anzupassen.

Wenn Sie den Umstieg auf Windows 8 planen, werden Sie merken, dass der Anwendungskompatibilitätsprozess diesmal wesentlich leichter ist als noch vor einigen Jahren. Wenn Sie von Windows Vista oder Windows 7 migrieren, können Sie die meisten Anwendungen unter Windows 8 problemlos weiterhin verwenden. Wenn Sie von Windows XP migrieren, werden Sie feststellen, dass die meisten unabhängigen Softwarehersteller ihre Anwendungen aktualisiert haben, sodass sie mit den modernen Windows-Betriebssystemen funktionieren, und durch die üblichen regelmäßigen Softwareupdates verfügen Sie wahrscheinlich bereits über eine kompatible Version. Unabhängig davon, ob Sie also von Windows XP, Windows Vista oder Windows 7 migrieren – es ist heute einfacher als damals.

Darüber hinaus kann es aber ein größeres Unterfangen sein, Ihr Anwendungsportfolio auf eine Betriebssystemmigration vorzubereiten. Wenn die Schritte jedoch in der richtigen Reihenfolge ausgeführt und klare, risikomindernde Entscheidungen zur Verringerung des Testumfangs gefällt werden, dann ist diese Aufgabe nicht ganz so gewaltig.

Zurück zum Anfang


Warum funktionieren einige Anwendungen unter Windows 8 nicht mehr?

Welche Änderungen wurden in Windows 8 eingeführt, die bewirken, dass für frühere Windows-Versionen entwickelte Anwendungen nicht mehr funktionieren? Sicherlich haben die für Windows 8 verantwortlichen Entwicklerteams dieses Problem nicht auf die leichte Schulter genommen.

Es wurden Änderungen an Windows vorgenommen, die die Sicherheit, Zuverlässigkeit, Leistung und Benutzerfreundlichkeit erhöhen, und in einigen Fällen wurden ältere Komponenten entfernt, deren Nützlichkeit einfach nicht mehr gegeben war. Wir werden in diesem Artikel nicht auf alle Änderungen im Detail eingehen, sondern nur diejenigen aufführen, die für die Anwendungskompatibilität am wichtigsten sind, wie die Benutzerkontensteuerung/Standardbenutzerkonten und Versionsprüfungen.

Benutzerkontensteuerung/Standardbenutzerkonten

Seit Windows XP SP2 sind Sicherheitsaspekte die treibende Kraft für viele der Investitionen in Windows. Bei der Beschäftigung mit dem Thema Sicherheit sind die Entwickler jedoch im Laufe der Zeit auf verschiedene Dinge aufmerksam geworden. Erstens: Sämtliche Sicherheitsfunktionen nützen nichts, wenn jeder Benutzer und jede Anwendung diese Funktionen selbst wieder außer Kraft setzen können, da sie über Administratorrechte verfügen! Zweitens haben die Mitglieder des Entwicklungsteams immer wieder von Unternehmen gehört, dass die Verwaltung von Standardbenutzerkonten günstiger ist – und zwar wesentlich günstiger. Sie konnten die Administratorrechte jedoch nicht einfach deaktivieren und dadurch Geld sparen, da viele Anwendungen danach nicht mehr funktionierten.

Bei der Entwicklung von Windows Vista haben sich die Entwickler daher des Problems der Anwendungskompatibilität angenommen und Unternehmen in die Lage versetzt, ihre Benutzer entsprechend den Unternehmensanforderungen als Standardbenutzer einzurichten und nur den Benutzern lokale Administratorrechte zu erteilen, die diese wirklich brauchen, wie Entwickler und IT-Administratoren. Diese Funktionen wurden in der so genannten Benutzerkontensteuerung zusammengefasst. Trotz verschiedener hilfreicher automatischer Problembehebungen der Software waren auch manuelle Behebungen notwendig, denn manche Anwendungen erforderten Codeänderungen.

Wenn Sie bisher Windows Vista oder Windows 7 eingesetzt haben, haben Sie diesen Prozess in der Regel bereits abgeschlossen und verfügen über ein Softwareportfolio, das sich ohne Administratorrechte ausführen lässt. Die wenigen Unternehmen jedoch, die die Benutzerkontensteuerung deaktiviert haben und allen Benutzern Administratorrechten erteilt haben, sollten diese Entscheidung vor der Migration zu Windows 8 noch einmal überdenken, da diese Funktion eine Voraussetzung für die immersiven Anwendungen im Windows 8-Stil ist. Diejenigen, die von Windows XP migrieren, werden die meisten Benutzer bisher als lokale Administratoren eingerichtet haben und würden diese Anzahl sicher gerne verringern.

Anwendungen, die ursprünglich für Administratorrechte geschrieben wurden, werden teilweise automatisch repariert, aber einige müssen mit den Shims für die Anwendungskompatibilität der Benutzerkontensteuerung manuell angepasst werden. Wieder andere erfordern Codeänderungen, um die Abhängigkeit von Administratorrechten aufzuheben.

Versionsprüfungen

Die größte Auswirkung auf die Anwendungskompatibilität hat von allen Änderungen in Windows 8 vor allem die Änderung der Versionsnummer. Dabei wurde nicht einmal die Hauptversionsnummer geändert – es geht immer noch um die Version 6, und zwar seit Windows Vista! Nachdem alle Versionsprüfungen für Windows XP korrigiert wurden, schrieben die Entwickler neue Versionsprüfungen für Windows Vista. Nachdem diese korrigiert wurden, schrieben die Entwickler neue Versionsprüfungen für Windows 7! Aus irgendeinem Grund können die Entwickler diese Gewohnheit anscheinend nicht ablegen. Wir freuen uns auf den Tag, an dem die Entwickler einfach nur auf das „Betriebssystem x oder später“ prüfen, bis dahin können wir dieses Problem relativ leicht mit Shims zur Anwendungskompatibilität mildern.

Zurück zum Anfang


Fünf Schritte, um Anwendungen mit Windows 8 kompatibel zu machen

Wie bei den meisten Aufgaben ist auch ein Projekt für die Anwendungskompatibilität einfacher durchzuführen, wenn Sie sich die Zeit nehmen, den Prozess in logische, verwaltbare Schritte aufzuteilen.

In der Regel wird ein Projekt für die Anwendungskompatibilität in folgende drei Hauptschritte unterteilt: Ermitteln, Analysieren und Testen/Warten. Wir möchten hier jedoch zwei weitere Schritte hinzufügen: Virtualisierung und Orchestrierung.

Schritt 1: Anwendungsermittlung

Der erste Schritt ist die Anwendungsermittlung, bei der Sie eine Liste der Anwendungen erstellen, die Sie als verwaltete Apps einstufen und die Sie daher vor der Bereitstellung auf der neuen Plattform testen sollten.

Während der Beschäftigung mit diesem Schritt, der in das Software Asset Management (SAM) fällt, sollten Sie sich bewusst machen, dass die Priorisierung von Anwendungen den größten Einfluss auf das Anwendungstestprojekt hat. Im Idealfall sollten Sie jede Ihrer Anwendungen einer der folgenden Kategorien zuordnen können (die Kategorien können durchaus andere Namen haben, wichtig sind die Merkmale, die diese Kategorien ausmachen):

  • Verwaltete Anwendungen: Diese Anwendungen werden als geschäftskritisch eingestuft und erfordern daher proaktives Testen, um die Risiken, die mit einer Änderung der Umgebung einhergehen, abzuschwächen. Geht es um Migrationen mit hohem Risikopotenzial, müssen die Tests noch verschärft werden. Vor der Migration sollten alle verwalteten Anwendungen ermittelt worden sein.
  • Unterstützte Anwendungen: Diese Anwendungen sind für das Unternehmen ebenfalls wichtig, sie können aber erst während der Pilotphase genauer geprüft werden. Sie kennen wahrscheinlich bereits viele dieser unterstützten Anwendungen, und es ist nicht notwendig, dass Sie vor der Pilotphase jede einzelne ermittelt haben.
  • Nicht unterstützte Anwendungen: Diese Anwendungen werden nicht von der IT unterstützt, und Sie müssen sie daher auch nicht kennen. In der Regel werden Sie sich auch nicht die Mühe machen, sie zu entfernen: Die einzelnen Benutzer sind selbst verantwortlich für den Support dieser Anwendungen.
  • Gesperrte Anwendungen: Diese Anwendungen werden Sie in der Regel aus Ihrer Umgebung entfernen. Neue Technologien, wie AppLocker, können dabei helfen, Sperren für solche Anwendungen durchzusetzen. Es ist zwar nützlich, diese Anwendungen zu kennen, um entsprechende Sperren zu verhängen, für das Testen der Anwendungskompatibilität ist es jedoch nicht notwendig.

Wenn Sie ein relativ gut entwickeltes SAM haben, verfügt Ihr Unternehmen möglicherweise über eine Anwendungsdatenbank, die Sie nur abfragen müssen, um eine Liste der verwalteten Anwendungen zu erhalten. Viele Unternehmen haben aber nicht die Möglichkeit, eine solche Abfrage auszuführen. In diesem Fall muss der Ermittlungsprozess manuell angegangen werden, indem eine Liste der verwalteten Anwendungen erstellt wird.

Manchmal bietet sich dabei als Ausgangspunkt die Erstellung eines Anwendungsinventars an, um sicherzustellen, dass keine verwaltete Anwendung übersehen wird. In anderen Fällen macht es mehr Sinn, diese Liste manuell zu erstellen, indem die Benutzer einfach nach den entsprechenden Anwendungen gefragt werden. (Dies ist vor allem bei Plattformen der Fall, bei denen die Anwendungsliste so lang ist, dass das Rationalisieren des Bestands unpraktisch wird, wie z. B. bei Web-URLs: schnell können die besuchten URLs in die Zehntausend oder sogar Hunderttausend Millionen gehen). Es ist dabei nicht unbedingt notwendig, jede Anwendung zu ermitteln, die bei den Benutzern installiert oder in Verwendung ist; Sie sollten den Aufwand hier nicht übertreiben. Sie sollten nur sicherstellen, dass Sie alle (oder fast alle) der verwalteten Anwendungen ermitteln. (Es ist nicht schlimm, wenn Sie beim ersten Mal welche übersehen. Sie sollten sich diese Anwendungen aber für das nächste Mal merken.)

Wenn Sie meinen, dass sich die Erstellung einer Inventarliste anbietet, können Sie verschiedene Tools zum Automatisieren dieses Prozesses einsetzen. Sie können z. B. das Anwendungskompatibilitäts-Toolkit von Microsoft verwenden, das kostenlos heruntergeladen werden kann. Wenn Sie bereits eine andere Inventarmethode verwenden (z. B. Microsoft System Center Configuration Manager oder Microsoft Asset Inventory Service), können Sie aber auch diese als Ausgangspunkt verwenden.

Um die Liste mit verwalteten Anwendungen auch für die spätere Nutzung möglichst brauchbar zu machen, sollten Sie nicht nur den Namen der Anwendung erfassen. Informationen dazu, wer die Anwendung nutzt, welche Rollen die Benutzer haben und wie wichtig diese Anwendung für die Benutzer ist, können sehr hilfreich für die Migration und auch für spätere SAM-Aufgaben sein

So hat die Ermittlung auch einen positiven Nebeneffekt: Sie stoßen dabei möglicherweise auf häufig verwendete Anwendungen, die Sie zurzeit noch nicht verwalten. Sie sollten diese Anwendungen von nun an auf Ihre Liste setzen, damit Sie sicherstellen können, dass sie richtig verwaltet werden, in der genehmigten Version vorliegen und über alle erforderlichen Softwareupdates verfügen.

Schritt 2: Analysieren der Anwendungen

Wie viele Anwendungen unterstützen Sie gegenwärtig, die ersetzt wurden oder aus anderen Gründen von den Geschäftskunden nicht mehr genutzt werden? In den meisten Unternehmen ist dies eine beträchtliche Anzahl. In einigen Unternehmen gehören sogar die meisten Anwendungen zu dieser Kategorie. Wenn Sie die Anwendungsermittlung abgeschlossen haben und sich einen umfassenden Überblick verschafft haben, sollten Sie als Nächstes die Liste der verwalteten Anwendungen bereinigen und auf die wirklich erforderlichen Anwendungen begrenzen, bevor Sie mit den zeit- und kostenaufwendigen Regressionstests beginnen. Einige der Anwendungen können in die Kategorie der unterstützten Anwendungen herabgestuft werden, die nicht proaktiv getestet werden müssen, andere müssen vielleicht hochgestuft und bei der Migration besonders genau geprüft werden.

Legen Sie angemessene Ziele für das Anwendungsportfolio fest. Wie viele Anwendungen können oder möchten Sie verwalten, und wie viele Anwendungen sollen zu den unterstützten zählen? Ab wann sollte eine Anwendung der Kategorie der „verwalteten“ Anwendungen zugeordnet werden?

Wenn Sie die Ziele festgelegt haben, ist es an der Zeit, die Problemfälle zu finden und die Anwendungen einzugrenzen, die getestet werden müssen:

  • Entfernen Sie redundante und nicht verwendete Anwendungen. Sie werden zweifellos feststellen, dass einige Anwendungen vorhanden sind, die dieselbe Funktion erfüllen. Dies ist der richtige Zeitpunkt, eine Standardanwendung pro Funktion festzulegen und diejenigen Anwendungen zu entfernen, die dadurch nicht mehr erforderlich sind. Versuchen Sie hierbei Anwendungsabhängigkeiten zu berücksichtigen, da Sie möglicherweise eine ältere Version einer Anwendung unterstützen müssen, damit eine andere Version vom Softwarehersteller weiterhin unterstützt wird. Und natürlich entfernen Sie die Anwendungen, die nur selten oder gar nicht genutzt werden. Dadurch erleichtern Sie nicht nur die Tests, sondern Sie sparen möglicherweise auch Lizenzkosten ein.
  • Entfernen Sie mehrere Versionen einer Anwendung, und legen Sie die aktuelle Version als Standard fest. Meistens verfügt die neueste Version über das beste Leistungsverhalten und ist am sichersten und zuverlässigsten. Achten Sie auch hier wieder auf Anwendungsabhängigkeiten.
  • Sammeln Sie Informationen von Geschäftskunden, um geschäftskritische Anwendungen leichter priorisieren zu können und zu ermitteln, welche Abteilungen mit welchen Anwendungen arbeiten. Dies ist auch bei der Planung der einzelnen Testphasen hilfreich. Sie sollten die Zeitplanung der Tests an der gestaffelten Bereitstellung des neuen Desktopabbilds ausrichten.

Schritt 3: Bewerten von Inkompatibilitäten und Optionen zur Risikominimierung

Als Nächstes müssen Sie herausfinden, welche der verwalteten Anwendungen einwandfrei unter Windows 8 laufen. Für diesen Test ist eine genaue Planung erforderlich.

Wenn für eine Anwendung Supportdienste von Seiten des Herstellers benötigt werden, sollten Sie als Erstes den aktuellen Supportstatus ermitteln. Sie möchten den ganzen Prozess sicherlich nicht für eine Anwendung fortführen, die Sie am Ende sowieso nicht ausführen können, da kein Support mehr geleistet wird. Wenn Supportdienste benötigt werden, diese aber für die aktuelle Version nicht zur Verfügung stehen, sollten Sie sich als Nächstes um eine aktualisierte, unterstützte Version kümmern. Manche informieren sich sogar bei Anwendungen, für die kein Support benötigt wird, über den Status des Herstellersupports. Wenn es sich um weit verbreitete Anwendungen handelt, finden sich in der Regel genug Hinweise zu Supportleistungen – und solche Hinweise geben praktischerweise auch Aufschluss darüber, ob die Anwendung funktionieren wird oder nicht.

Manche Kunden lassen eine „Feuerprobe“ durch die technischen Mitarbeiter oder eine statische Analyse mit Kompatibilitätstools oder sogar beides durchführen. Diese technischen Tests können sehr hilfreich sein, um die Kompatibilität der Pakete und Anwendungen zu ermitteln.

Die letzte Kompatibilitätsprüfung ist immer der Benutzerakzeptanztest. Der Benutzer kann selbst am besten feststellen, ob Probleme bei bestimmten Benutzerszenarios vorliegen. Die vor dem Benutzerakzeptanztest durchgeführten Aufgaben dienen im Prinzip dazu, den Benutzerakzeptanztest für die Benutzer zu vereinfachen, die sich in der Regel freiwillig für den Test gemeldet haben und deren Kooperationsbereitschaft man unter Umständen nicht einschätzen kann.

Im Laufe dieses Prozesses stoßen Sie möglicherweise auf Anwendungen, die noch nicht vollständig mit Windows 8 kompatibel sind, vor allem, wenn Sie von Windows XP migrieren. In diesem Fall haben Sie verschiedene Möglichkeiten:

  • Ersetzen Sie die nicht kompatible Anwendung durch eine neue Version. Dies ist sicherlich die zuverlässigste Methode, leider aber auch die teuerste. Wenn die Anwendung geschäftskritisch oder anderweit strategisch wichtig für das Unternehmen ist, dann sollten Sie so vorgehen.
  • Erstellen Sie Shims für die vorhandenen Anwendungen. Die in Windows 2000 eingeführten Shims stellen die Anwendungskompatibilität sicher, indem sie das Bearbeiten von Aufrufen an das zugrunde liegende Betriebssystem ermöglichen. Es gibt z. B. Shims, die der Simulation einer älteren Version des Betriebssystems dienen, und Shims, die das Umleiten von Dateilese- und -schreibvorgängen an andere Orte ermöglichen. Dies ist zwar mit etwas zusätzlichem Verwaltungsaufwand verbunden, da Sie eine Shim-Datenbank pflegen müssen, aber diese Vorgehensweise ist trotzdem äußerst effektiv und kann viele Kompatibilitätsfehler beheben. Dies ist oft der kostengünstigere Weg und möglicherweise die einzige Möglichkeit, wenn der Hersteller der Anwendung nicht mehr zur Verfügung steht. Es gibt jedoch einen Nachteil: Viele Hersteller unterstützen das Verwenden von Shims für Anwendungen nicht. (Wenn für die Anwendung noch Support geleistet wird, können Sie den Hersteller natürlich einfach anrufen und nach einem Update fragen – dann brauchen Sie keine Shims!)
  • Sie können das unerwünschte Verhalten der Anwendung über Gruppenrichtlinien ändern. Das Ändern der Systemkonfiguration mithilfe der Gruppenrichtlinie kann zwar beim Beheben von Kompatibilitätsproblemen helfen, hat aber auch Nachteile. Im Grunde wird bei diesem Ansatz mithilfe von Richtlinien eine bestimmte Funktion deaktiviert, die den Anwendungsfehler verursacht. Unglücklicherweise haben diese Funktionen in vielen Fällen Einfluss auf die Sicherheit des zugrunde liegenden Systems, sodass bedeutende Abstriche gemacht werden müssen. Zudem ist dieses Vorgehen nur möglich, wenn die Anwendung über Gruppenrichtlinieneinstellungen verfügt.

Bei benutzerdefinierten oder intern entwickelten Anwendungen können Sie den Code modifizieren. Das ist nicht immer möglich, aber wenn doch, stehen Ihnen praktische Ressourcen zur Erleichterung dieser Aufgabe zur Verfügung. Es gibt z. B. Application Compatibility Cookbooks, in denen die Unterschiede zwischen Windows XP und Windows Vista, zwischen Windows Vista und Windows 7 und zwischen Windows 7 und Windows 8 beschrieben werden. Diese Cookbooks sind kostenlose Leitfäden, die die Änderungen an den Betriebssystemen für Entwickler verdeutlichen und sie dabei unterstützen, Kompatibilitätsfehler zu beheben.

Schritt 4: Vorbereitung der Betriebssystembereitstellung und neuer Anwendungsverteilungsoptionen

Der Beginn eines Migrationsprojekts für ein Betriebssystem ist der ideale Zeitpunkt für Sie, die Art der Bereitstellung von Anwendungen für die Endbenutzer zu überdenken. Die Virtualisierungstechnologien für Anwendungen haben sich erheblich verbessert und Möglichkeiten eröffnet, die möglicherweise nicht verfügbar waren, als Sie das letzte Mal Entscheidungen zur Bereitstellung getroffen haben. Sie sollten verschiedene Modelle für die Anwendungsbereitstellung in Betracht ziehen, bevor Sie mit dem Testen beginnen. Möglicherweise stellen Sie fest, dass die Einsparungen bei der Anwendungsbereitstellung, zusammen mit Anwendungstests und Anwendungsvorbereitungen, die Kosten der Implementierung einer virtualisierten Umgebung mehr als aufwiegen – und gleichzeitig erhalten Sie eine flexiblere und leichter zu verwaltende Umgebung für zukünftige Projekte.

Die Virtualisierung des Anwendungsportfolios bietet eine Reihe von Vorteilen in Bezug auf die Verwaltbarkeit und Flexibilität, ein Hauptvorteil besteht jedoch in der Minimierung der Konflikte zwischen Anwendungen. Diese Art von Konflikten entsteht beispielsweise, wenn zwei Versionen derselben Anwendungen gleichzeitig ausgeführt werden müssen. Das ist z. B. der Fall, wenn mehrere Versionen einer Anwendung vom Helpdesk unterstützt werden, oder wenn die Finanzabteilung auf eine neuere Version der Buchhaltungssoftware umstellt, bis zum Abschluss des Finanzjahrs aber noch auf die alte Version zugreifen muss.

Schritt 5: Festlegen der Reihenfolge für Tests, Pilottests und Bereitstellung

In Schritt 1 haben wir das Erfassen von Informationen zu Ihren Anwendungen erläutert, die für den weiteren Prozess hilfreich sind. Diese Daten können Sie besonders gut für die Planung eines Prozesses nutzen, der eine schnelle und effektive Bereitstellung ermöglicht.

Eine der erfolgreichsten Bereitstellungsmethoden ist die Bereitstellung nach Rolle. Da mit der Bereitstellung sinnvollerweise erst dann begonnen wird, wenn die Anwendungskompatibilität geklärt ist, sollten Sie zuerst ermitteln, welche Anwendungen von welchen Rollen eingesetzt werden, und sich dann darauf konzentrieren, alle innerhalb dieser Rollen verwendeten Anwendungen kompatibel zu machen. Danach können Sie diese für die entsprechenden Benutzer bereitstellen.

Welche Rollen sollten Sie aber als Erstes auswählen? Bei dieser Entscheidung ist meistens ausschlaggebend, wie viele Anwendungen von Personen mit einer bestimmten Rolle eingesetzt werden (Sie können sich dann zuerst um die Rollen mit einer geringen Anzahl an Anwendungen kümmern und schnell erste Erfolge verbuchen), oder welche Rollen die höchste Fehlertoleranz aufweisen (auf diese Weise gehen Sie am Anfang, wenn Sie noch in der Lernphase sind, kein zu großes Risiko ein).

Wenn Sie die Anwendungen für eine bestimmte Rolle getestet haben, können Sie mit den Pilottests für diese Rolle beginnen. Während des Prozesses können Probleme bei den unterstützten Anwendungen auftreten (hoffentlich jedoch nicht bei den verwalteten Anwendungen; ist dies aber doch der Fall, sollten Sie einen Ausweichplan parat haben). So lange jedoch das Helpdesk über Kapazitäten verfügt, Unterstützung für diese Anwendungen zu leisten, können Sie den Pilottest langsam immer stärker ausbauen, bis letztendlich eine vollständige Bereitstellung entsteht. So können Sie sich Rolle für Rolle durch das Unternehmen arbeiten und dabei eng mit den Verantwortlichen für die Bereitstellung des Betriebssystemimages kooperieren, um den Prozess zu koordinieren und zu beschleunigen. Und ehe Sie sich versehen, haben Sie alle für die Windows 8-Bereitstellung vorgesehenen Arbeitsplätze abgedeckt.

Zurück zum Anfang


Weitere Ressourcen

Die Vorbereitung des Anwendungsportfolios auf eine Migration zu Windows 8 kann ein umfangreiches Unternehmen sein, aber glücklicherweise sind einige Tools und eine Fülle von Anleitungen verfügbar, damit dieser Prozess reibungsloser und verwaltbar wird. In diesem Artikel konnte die Thematik nur angerissen werden; wenn Sie sich intensiver mit dem Thema beschäftigen und den Prozess ins Rollen bringen möchten, sollten Sie als Nächstes die Seite über die wichtige Aufgabe der Anwendungskompatibilität auf TechNet besuchen, das Anwendungskompatibilitäts-Toolkit herunterladen und mit dem Erstellen des Projektplans beginnen.

Hilfreiche Informationen und Anleitungen finden Sie zudem im Blog von Chris Jackson. Weitere Informationen zu den oben genannten Virtualisierungstechnologien erhalten Sie außerdem in der Ressourcensammlung zu Microsoft Desktop Optimization Pack.

Aktuelle Informationen, Anleitungen und Communitykontakte zu Windows 8 und den Windows-Clienttechnologien finden Sie im Windows 8 TechCenter.

Zurück zum Anfang

Wichtige Aufgaben

Verwandte Ressourcen

  • Windows Assessment and Deployment Kit

    Kostenlose Tools und Dokumentationen (einschließlich ACT), die Ihnen bei der Evaluierung und Minimierung von Problemen mit der Anwendungskompatibilität helfen, bevor Sie Windows 8 bereitstellen.

  • Windows 8 Compatibility Cookbook

    Informationen zu Änderungen und neuen Funktionen der Windows 8- und Windows Server 2012-Betriebssysteme.

  • Windows 8 Compatibility Center

    Onlinesammlung von Informationen zur Kompatibilität mit Windows 8 sowie eine Liste von Hardwaretreibern und Softwareupdates, die mit Windows 8 kompatibel sind.

Bleiben Sie auf dem Laufenden