Freigeben über

Bereitstellen und Installieren von Outlook-Add-Ins zu Testzwecken

  • Artikel

Im Rahmen des Prozesses zum Entwickeln eines Outlook-Add-Ins werden Sie wahrscheinlich das Add-In wiederholt zu Testzwecken bereitstellen und installieren, was die folgenden Schritte beinhaltet.

  1. Erstellen einer Manifestdatei zur Beschreibung des Add-Ins
  2. Bereitstellen der Add-In-Ui-Dateien auf einem Webserver.
  3. Installieren des Add-Ins in Ihrem Postfach
  4. Testen des Add-Ins, Implementieren eventuell nötiger Änderungen an den Benutzeroberflächendateien und Manifestdateien und Wiederholen der Schritte 2 und 3 zwecks Testen der Änderungen

Hinweis

Benutzerdefinierte Bereiche sind veraltet. Stellen Sie sicher, dass Sie einen unterstützten Add-In-Erweiterungspunkt verwenden.

Erstellen einer Manifestdatei für das Add-In

Jedes Add-In wird durch ein Manifest beschrieben, ein Dokument, das dem Server Informationen zum Add-In bereitstellt, beschreibende Informationen zum Add-In für den Benutzer bereitstellt und den Speicherort der HTML-Datei der Add-In-Benutzeroberfläche identifiziert. Sie können das Manifest in einem lokalen Ordner oder auf einem lokalen Server speichern, vorausgesetzt, auf den Speicherort kann vom Exchange-Server des Postfachs zugegriffen werden, den Sie für die Testzwecke verwenden. Hier wird davon ausgegangen, dass Sie das Manifest in einem lokalen Ordner speichern. Informationen zum Erstellen einer Manifestdatei finden Sie unter Office-Add-In-Manifeste.

Bereitstellen eines Add-Ins auf einem Webserver

Sie können HTML und JavaScript verwenden, um das Add-In zu erstellen. Die resultierenden Quelldateien werden auf einem Webserver gespeichert, auf den der Exchange-Server zugreifen kann, der das Add-In hostet. Nach der ersten Bereitstellung der Quelldateien für das Add-In können Sie die Add-In-Benutzeroberfläche und das Verhalten aktualisieren, indem Sie die auf dem Webserver gespeicherten HTML-Dateien oder JavaScript-Dateien durch eine neue Version der HTML-Datei ersetzen.

Installieren des Add-Ins

Nachdem Sie die Add-In-Manifestdatei vorbereitet und die Add-In-Benutzeroberfläche auf einem Webserver bereitgestellt haben, auf den zugegriffen werden kann, können Sie das Add-In mithilfe eines Outlook-Clients für ein Postfach auf einem Exchange-Server querladen oder es installieren, indem Sie Windows PowerShell-Remote-Cmdlets ausführen.

Querladen des Add-Ins

Sie können ein Add-In installieren, wenn sich Ihr Postfach in Exchange befindet. Für das Querladen von Add-Ins ist mindestens die Rolle "Meine benutzerdefinierten Apps" für Ihre Exchange Server erforderlich. Um das Add-In zu testen oder Add-Ins generell durch Angeben einer URL oder eines Dateinamens für das Add-In-Manifest zu installieren, sollten Sie Ihren Exchange-Administrator bitten, die erforderlichen Berechtigungen bereitzustellen.

Der Exchange-Administrator kann das folgende PowerShell-Cmdlet ausführen, um einem einzelnen Benutzer die erforderlichen Berechtigungen zuzuweisen. In diesem Beispiel wendyri ist der E-Mail-Alias des Benutzers.

New-ManagementRoleAssignment -Role "My Custom Apps" -User "wendyri"

Bei Bedarf kann der Administrator das folgende Cmdlet ausführen, um mehreren Benutzern ähnliche erforderliche Berechtigungen zuzuweisen.

$users = Get-Mailbox *$users | ForEach-Object { New-ManagementRoleAssignment -Role "My Custom Apps" -User $_.Alias}

Weitere Informationen zur Rolle „Eigene benutzerdefinierte Apps“ finden Sie unter Rolle „Eigene benutzerdefinierte Apps“.

Wenn Sie Microsoft 365 oder Visual Studio zum Entwickeln von Add-Ins verwenden, wird Ihnen die Organisationsadministratorrolle zugewiesen. Damit können Sie Add-Ins mithilfe einer Datei oder URL im EAC installieren, oder Sie können Powershell-Cmdlets verwenden.

Installieren eines Add-Ins mithilfe von Remote-PowerShell

Nachdem Sie auf Ihrem Exchange-Server eine Windows PowerShell-Remotesitzung eingerichtet haben, können Sie mit dem Cmdlet New-App ein Outlook-Add-In mithilfe des folgenden PowerShell-Befehls installieren.

New-App -URL:"http://<fully-qualified URL">

Die vollqualifizierte URL ist der Speicherort der Add-In-Manifestdatei, die Sie für Ihr Add-In vorbereitet haben.

Nutzen die folgenden zusätzlichen PowerShell-Cmdlets zum Verwalten der Add-Ins für ein Postfach.

  • Get-App – Listet die für ein Postfach aktivierten Add-Ins auf.
  • Set-App – Aktiviert oder deaktiviert ein Add-In für ein Postfach.
  • Remove-App – Entfernt ein zuvor installiertes Add-In von einem Exchange-Server.

Clientversionen

Die Entscheidung, welche Versionen des Outlook-Clients getestet werden sollten, hängt von Ihren Entwicklungsanforderungen ab.

  • Wenn Sie ein Add-In für die private Verwendung oder nur für Mitglieder Ihrer organization entwickeln, ist es wichtig, die outlook-Versionen zu testen, die Ihr Unternehmen verwendet. Denken Sie daran, dass einige Benutzer möglicherweise Outlook im Web verwenden, daher ist es auch wichtig, die Standardbrowserversionen Ihres Unternehmens zu testen.

  • Wenn Sie ein Add-in zur Auflistung in AppSource entwickeln, müssen Sie die in den Commercial Marketplace-Zertifizierungsrichtlinien 1120.3 angegebenen erforderlichen Versionen testen. Diese umfassen:

    • Die aktuelle Version von Outlook unter Windows und deren Vorgängerversion.
    • Die aktuelle Version von Outlook für Mac.
    • Die aktuelle Version von Outlook für iOS und Android (wenn Ihr Add-In den mobilen Formfaktor unterstützt).
    • Die Browserversionen, die in der Commercial Marketplace-Validierungsrichtlinie 1120.3 angegeben wurden.

Hinweis

Wenn das Add-In einen der obigen Clients nicht unterstützt, weil ein API-Anforderungssatz angefordert wird, den der Client nicht unterstützt, wird dieser Client aus der Liste der erforderlichen Clients entfernt.

Outlook im Web für Exchange Server-Versionen

Benutzer und Microsoft 365-Konto-Benutzer sehen die moderne Benutzeroberflächenversion, wenn Sie auf Outlook im Web zugreifen und die klassische Version, die nicht mehr unterstützt wird, nicht mehr sehen. Lokale Exchange-Server unterstützen weiterhin das klassische Outlook im Web. Daher wird während des Überprüfungsvorgangs möglicherweise eine Warnung angezeigt, dass das Add-In nicht mit klassischem Outlook im Web kompatibel ist. In diesem Fall sollten Sie das Add-In in einer lokalen Exchange-Umgebung testen. Diese Warnung blockiert ihre Übermittlung an AppSource nicht. Wenn Ihre Kunden Outlook im Web in einer lokalen Exchange-Umgebung verwenden, ist ihre Erfahrung jedoch möglicherweise nicht optimal.

Um dies zu verhindern, empfiehlt es sich, das Add-In in Outlook im Web zu testen, das mit ihrer eigenen lokalen Exchange-Umgebung verbunden ist. Weitere Informationen finden Sie unter Anleitung zum Einrichten einer Exchange 2016-oder Exchange 2019-Testumgebung sowie zum Verwalten von Outlook im Web in Exchange Server.

Alternativ können Sie auch einen Dienst bezahlen, der lokale Exchange-Server hostet und verwaltet. Es gibt verschiedene Optionen:

Wenn Sie nicht möchten, dass Ihre Add-Ins für Benutzer zur Verfügung stehen, die mit lokalem Exchange verbunden sind, können Sie den Anforderungssatz im Add-In-Manifest auf 1,6 oder höher festlegen. Solche Add-Ins werden auf der Benutzeroberfläche von Outlook im Web nicht getestet oder überprüft.

Siehe auch