Häufig gestellte Fragen zum Microsoft Entra-Anwendungsproxy

Auf dieser Seite werden häufig gestellte Fragen zu Microsoft Entra-Anwendungsproxy beantwortet.

Allgemein

Kann ich eine Anwendungsproxy-App auf der Seite **App-Registrierungen** im Microsoft Entra Admin Center ändern?

Nein, die folgenden Konfigurationselemente werden vom App-Proxy verwendet und sollten nicht geändert oder gelöscht werden:

  • Aktivieren/Deaktivieren von „Allow public clients flows“ (Öffentliche Clientflows zulassen).
  • Verbund-Anmeldeinformationen.
  • API-Berechtigungen. Wenn Sie eines der oben genannten Konfigurationselemente auf der Seite für die App-Registrierung ändern, wird die Vorauthentifizierung für den Microsoft Entra Anwendungsproxy unterbrochen.

Der geheime Clientschlüssel einer Anwendungsproxy-App (CWAP_AuthSecret) läuft bald ab oder ist bereits abgelaufen. Was soll ich tun?

Anwendungsproxy-Apps basieren nicht mehr auf geheimen CWAP-Schlüsseln. Für Apps, die die Vorauthentifizierung mit Microsoft Entra ID nutzen, werden stattdessen nun Verbundidentitätsanmeldeinformationen (Federated Identity Credentials, FIC) eingesetzt. FIC ist sicherer, läuft nicht ab und erfordert deutlich weniger Wartung. Anwendungen, die mit passthrough-Vorauthentifizierung konfiguriert sind oder zugriffstoken verwenden, erfordern keine Verbundidentitätsanmeldeinformationen – auch wenn zuvor ein FIC erstellt wurde.

Sie können alle vorhandenen CWAP-Geheimnisse in der App-Registrierung Ihrer Anwendungsproxy-App sicher ignorieren oder alte oder abgelaufene Geheimnisse löschen. Weitere Informationen zu Verbundidentitätsanmeldeinformationen finden Sie unter Übersicht über Verbundidentitätsanmeldeinformationen in Microsoft Entra ID.

Kann ich eine Anwendungsproxy-App auf der Seite „App-Registrierungen“ im Microsoft Entra Admin Center löschen?

Nein, Sie sollten eine Anwendungsproxy-App aus dem Bereich Unternehmensanwendungen im Microsoft Entra Admin Center löschen. Wenn Sie die Anwendungsproxy-App aus dem Bereich App-Registrierungen im Microsoft Entra Admin Center löschen, können Probleme auftreten.

Welche Lizenz ist erforderlich, um Microsoft Entra Anwendungsproxy zu verwenden?

Um Microsoft Entra-Anwendungsproxy verwenden zu können, benötigen Sie eine Microsoft Entra-ID P1 oder P2-Lizenz. Weitere Informationen zur Lizenzierung finden Sie unter Microsoft Entra Preise.

Was passiert mit dem Microsoft Entra Application Proxy in meinem Mandanten, wenn meine Lizenz abläuft?

Wenn Ihre Lizenz abgelaufen ist, wird der Anwendungsproxy automatisch deaktiviert. Ihre Anwendungsinformationen werden bis zu einem Jahr gespeichert.

Warum ist die Schaltfläche Anwendungsproxy aktivieren ausgegraut?

Stellen Sie sicher, dass Sie mindestens über eine P1- oder P2-Lizenz für Microsoft Entra ID verfügen und ein privater Microsoft Entra-Netzwerkconnector installiert ist. Nachdem Sie den ersten Connector erfolgreich installiert haben, wird der Microsoft Entra-Anwendungsproxydienst automatisch aktiviert.

Steckverbinder-Konfiguration

Verwendet der Anwendungsproxy denselben Connector wie der Microsoft Entra-Privatzugriff?

Ja, der private Microsoft Entra-Netzwerkconnector wird vom Anwendungsproxy und vom Microsoft Entra-Privatzugriff verwendet. Weitere Informationen zum Connector finden Sie unter Microsoft Entra Private Network Connector. Informationen zur Problembehandlung bei der Connectorkonfiguration finden Sie unter Problembehandlung für Connectors.

ConnectorTroubleshooter kann nicht gestartet werden

Die ConnectorTroubleshooterLauncher.exe ist veraltet und funktioniert nicht mehr. Derzeit ist kein Ersatz verfügbar.

Kann ich den Anmeldebenutzer des Microsoft Entra Private Network Connector/Updater Services ändern?

Das Ändern des Anmeldebenutzers des Connector- oder Updaterdiensts wird nicht unterstützt.

Richtige Konfiguration:

Microsoft Entra Private Network Connector: Netzwerkdienst Microsoft Entra Private Network Connector Updater: NT Authority\System

Anwendungskonfiguration

Muss ich geheime Client-Schlüssel beim Deployen von Anwendungsproxy-Apps verwalten oder rotieren?

Nein. Anwendungsproxy-Apps basieren nicht mehr auf geheimen Clientschlüsseln (CWAP_AuthSecret). Für Apps, die die Vorauthentifizierung mit Microsoft Entra ID nutzen, werden stattdessen nun Verbundidentitätsanmeldeinformationen (Federated Identity Credentials, FIC) eingesetzt. FIC ist sicherer, läuft nicht ab und erfordert keine manuelle Rotation oder Wartung. Anwendungen, die mit passthrough preauthentication konfiguriert sind, oder für Anwendungen, die Zugriffstoken verwenden, sind keine Verbundidentitätsanmeldeinformationen erforderlich. Sie können alle vorhandenen CWAP-Secrets in der App-Registrierung sicher ignorieren und alte oder abgelaufene Secrets entfernen. Weitere Informationen finden Sie unter Übersicht über Verbundidentitätsanmeldeinformationen in der Microsoft Entra-ID.

Kann ich die Domänensuffixe „[Mandantenname].onmicrosoft.com“ oder „[Mandantenname].mail.onmicrosoft.com“ in der externen URL verwenden?

Wenngleich diese Suffixe in der Suffixliste angezeigt werden, sollten Sie sie nicht verwenden. Diese Domänensuffixe sind nicht für die Verwendung mit dem Microsoft Entra-Anwendungsproxy vorgesehen. Wenn Sie diese Domänensuffixe verwenden, funktioniert die erstellte Microsoft Entra Anwendungsproxyanwendung nicht. Sie können entweder das Standarddomänensuffix msappproxy.net oder eine benutzerdefinierte Domäne verwenden.

Unterstützt Anwendungsproxy souveräne und regionale Clouds?

Microsoft Entra ID verfügt über einen Anwendungsproxydienst, mit dem Benutzer und Benutzerinnen auf lokale Anwendungen zugreifen können, indem sie sich mit ihrem Microsoft Entra-Konto anmelden. Wenn Sie Connectors in verschiedenen Regionen installiert haben, können Sie den Datenverkehr optimieren, indem Sie die nächstgelegene Clouddienstregion des Anwendungsproxys für jede Connectorgruppe auswählen. Weitere Informationen finden Sie unter Optimieren des Datenverkehrsflusses mit dem Microsoft Entra-Anwendungsproxy.

Ich erhalte eine Fehlermeldung über ein ungültiges Zertifikat oder ein möglicherweise falsches Passwort.

Nachdem Sie das SSL-Zertifikat hochgeladen haben, erhalten Sie im Portal die Meldung „Invalid certificate, possible wrong password“ (Ungültiges Zertifikat, möglicherweise falsches Kennwort).

So können Sie diesen Fehler z. B. beheben:

  • Überprüfen Sie, ob Probleme mit dem Zertifikat vorliegen. Installieren Sie es auf Ihrem lokalen Computer. Wenn keine weiteren Probleme auftreten, ist das Zertifikat in Ordnung.
  • Stellen Sie sicher, dass das Kennwort keine Sonderzeichen enthält. Das Kennwort sollte nur die Zeichen 0-9, A-Z und a-z enthalten.
  • Wenn das Zertifikat mit Microsoft Software Key Storage Provider erstellt wurde, muss der RSA-Algorithmus verwendet werden.

Wie lang sind das Standard- und das „lange“ Backend-Timeout? Kann das Timeoutlimit verlängert werden?

Die Standarddauer beträgt 85 Sekunden. Die „lange“ Einstellung beträgt 180 Sekunden. Das Timeoutlimit kann nicht verlängert werden.

Kann ein Dienstprinzipal den Anwendungsproxy mithilfe von PowerShell oder über Microsoft Graph-APIs verwalten?

Nein, dies wird derzeit nicht unterstützt.

Ich verwende oder möchte Microsoft Entra-Anwendungsproxy verwenden. Kann ich die Fallbackdomäne „onmicrosoft.com“ meines Mandanten in Microsoft 365 ersetzen, wie es im Artikel „Hinzufügen und Ersetzen Ihrer onmicrosoft.com-Fallbackdomäne in Microsoft 365“ beschrieben ist?

Nein, Sie müssen die ursprüngliche Fallbackdomäne verwenden.

Erwähnter Artikel: Hinzufügen und Ersetzen Ihrer onmicrosoft.com Fallbackdomäne in Microsoft 365

Wie ändere ich die Landing Page, die meine Anwendung lädt?

Auf der Seite „Anwendungsregistrierungen“ können Sie die Homepage-URL in die gewünschte externe URL der Landing Page ändern. Die angegebene Seite wird geladen, wenn die Anwendung über „Meine Apps“ oder das Office 365-Portal gestartet wird. Die Konfigurationsschritte finden Sie unter Festlegen einer benutzerdefinierten Startseite für veröffentlichte Apps mithilfe eines Microsoft Entra-Anwendungsproxys

Warum werde ich zu einer abgekürzten URL umgeleitet, wenn ich versuche, auf meine veröffentlichte Anwendung zuzugreifen und die URL ein Rautezeichen (#) enthält?

Wenn die Microsoft Entra-Vorauthentifizierung konfiguriert ist und die Anwendungs-URL beim ersten Versuch, auf die Anwendung zuzugreifen, ein Nummernzeichen („#“) enthält, werden Sie zur Authentifizierung zu Microsoft Entra ID (login.microsoftonline.com) umgeleitet. Nachdem Sie die Authentifizierung abgeschlossen haben, werden Sie vor dem Zeichen "#" an den URL-Teil umgeleitet, und alles, was nach dem "#" kommt, scheint ignoriert/entfernt zu werden. Wenn die URL beispielsweise https://www.contoso.com/#/home/index.html lautet, wird der Benutzer nach der Microsoft Entra-Authentifizierung auf https://www.contoso.com/ umgeleitet. Dieses Verhalten ist beabsichtigt aufgrund der Art und Weise, wie das Zeichen "#" vom Browser verarbeitet wird.

Mögliche Lösungen/Alternativen:

  • Richten Sie eine Umleitung von https://www.contoso.com zu https://contoso.com/#/home/index.html ein. Der Benutzer muss zuerst auf https://www.contoso.com zugreifen.
  • Die für den ersten Zugriffsversuch verwendete URL muss das Rautezeichen (#) in codierter Form (%23) enthalten. Dies wird vom veröffentlichten Server möglicherweise nicht akzeptiert.
  • Konfigurieren Sie den Vorauthentifizierungstyp „Passthrough“ (nicht empfohlen).

Können nur IIS-basierte Anwendungen veröffentlicht werden? Wie sieht es mit Webanwendungen aus, die auf Nicht-Windows-Webservern ausgeführt werden? Muss der Connector auf einem Server installiert sein, auf dem IIS installiert ist?

Nein, es gibt keine IIS-Anforderung für Anwendungen, die veröffentlicht werden. Sie können Webanwendungen veröffentlichen, die auf Servern ausgeführt werden, die nicht auf Windows Server basieren. Jedoch können Sie möglicherweise keine Vor-Authentifizierung bei einem Nicht-Windows-Server verwenden, abhängig davon, ob der Webserver das Negotiate-Protokoll (Kerberos-Authentifizierung) unterstützt. IIS ist nicht auf dem Server erforderlich, auf dem der Connector installiert ist.

Kann ich den Anwendungsproxy so konfigurieren, dass der HSTS-Header hinzugefügt wird?

Der Anwendungsproxy fügt HTTPS-Antworten nicht automatisch den HTTP Strict-Transport-Security-Header hinzu, behält jedoch den Header bei, wenn er sich in der ursprünglichen von der veröffentlichten Anwendung gesendeten Antwort befindet. Die Bereitstellung einer Einstellung zum Aktivieren dieser Funktionalität befindet sich in der Roadmap.

Kann ich eine benutzerdefinierte Portnummer in der externen URL verwenden?

Nein, wenn das Protokoll http in der externen URL konfiguriert ist, akzeptiert der Microsoft Entra-Anwendungsproxy-Endpunkt eingehende Anfragen auf TCP-Port 80. Wenn das Protokoll https konfiguriert ist, erfolgt die Annahme über TCP-Port 443.

Kann ich eine benutzerdefinierte Portnummer in der internen URL verwenden?

Ja. Beispiele für interne URLs mit Ports sind http://app.contoso.local:8888/, https://app.contoso.local:8080/ und https://app.contoso.local:8081/test/.

Welche Herausforderungen müssen berücksichtigt werden, wenn sich die externen und internen URLs unterscheiden?

Einige Antworten, die von den veröffentlichten Webanwendungen gesendet werden, können hartcodierte URLs enthalten. In diesem Fall muss mithilfe einer Linkübersetzungslösung sichergestellt werden, dass der Client immer die richtige URL verwendet. Lösungen für die Linkübersetzung können komplex sein und funktionieren möglicherweise nicht in allen Szenarios. Weitere Informationen finden Sie unter "Hartcodierte Umleitungslinks" für Apps, die mit dem Microsoft Entra-Anwendungsproxy veröffentlicht wurden.

Als bewährte Methode wird empfohlen, identische externe und interne URLs zu verwenden. Externe und interne URLs werden als identisch betrachtet, wenn protocol://hostname:port/path/ in beiden URLs identisch ist.

Dies kann mithilfe des Features Benutzerdefinierte Domänen erreicht werden.

Beispiele:

Identisch:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Nicht identisch:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Wenn die interne URL einen nicht standardmäßigen Port (nicht TCP 80/443) enthält, ist es nicht möglich, identische externe und interne URLs zu verwenden.

In einigen Szenarios müssen Änderungen an der Konfiguration der Web-App vorgenommen werden.

Integrierte Windows-Authentifizierung

In welchen Fällen sollte ich die „PrincipalsAllowedToDelegateToAccount“-Methode beim Einrichten der eingeschränkten Kerberos-Delegierung (Kerberos Constrained Delegation, KCD) verwenden?

Die „PrincipalsAllowedToDelegateToAccount“-Methode wird verwendet, wenn sich Connectorserver in einer anderen Domäne befinden als das Webanwendungsdienstkonto. Dafür muss die ressourcenbasierte eingeschränkte Delegierung verwendet werden. Wenn sich die Connectorserver und das Webanwendungsdienstkonto in derselben Domäne befinden, können Sie „Active Directory-Benutzer und -Computer“ verwenden, um die Delegierungseinstellungen für die einzelnen Connectorcomputerkonten zu konfigurieren, sodass sie an den Ziel-SPN delegiert werden können.

Wenn sich die Connectorserver und das Webanwendungsdienstkonto in unterschiedlichen Domänen befinden, wird die ressourcenbasierte Delegierung verwendet. Die Delegierungsberechtigungen werden für den Zielwebserver und das Webanwendungsdienstkonto konfiguriert. Diese Methode der eingeschränkten Delegierung ist relativ neu. Die Methode wurde in Windows Server 2012 eingeführt. Dieses Betriebssystem unterstützt die domänenübergreifende Delegierung, indem der Besitzer der Ressource (des Webdiensts) steuern kann, welche Computer- und Dienstkonten die Delegierung ausführen können. Es gibt keine Benutzeroberfläche, die Sie bei dieser Konfiguration unterstützt, daher müssen Sie PowerShell verwenden. Weitere Informationen finden Sie im Whitepaper Grundlegendes zur eingeschränkten Kerberos-Delegierung mit dem Anwendungsproxy.

Funktioniert die NTLM-Authentifizierung mit Microsoft Entra-Anwendungsproxy?

Die NTLM-Authentifizierung kann nicht als Vorauthentifizierung oder SSO-Methode verwendet werden. Die NTLM-Authentifizierung kann nur verwendet werden, wenn sie direkt zwischen dem Client und der veröffentlichten Webanwendung ausgehandelt werden kann. Bei Verwendung der NTLM-Authentifizierung wird in der Regel eine Anmeldeaufforderung im Browser angezeigt.

Kann die Anmeldeidentität „Lokaler Benutzerprinzipalname“ oder „Name des lokalen SAM-Kontos“ in einem B2B-IWA-Szenario mit einmaligem Anmelden verwendet werden?

Nein, sie funktioniert nicht, da ein Gastbenutzer in Microsoft Entra ID nicht über das Attribut verfügt, das von den oben erwähnten Anmeldeidentitäten benötigt wird.

In diesem Fall erfolgt ein Zurückgreifen auf „Benutzer-Principal-Name“. Weitere Informationen zum B2B-Szenario finden Sie im Abschnitt über den Zugriff von B2B-Benutzern in Microsoft Entra ID auf Ihre lokalen Anwendungen.

Passthrough-Vorauthentifizierung

Kann ich Richtlinien für bedingten Zugriff für Anwendungen verwenden, die mit Passthrough-Authentifizierung veröffentlicht werden?

Richtlinien für bedingten Zugriff werden nur für erfolgreich authentifizierte Benutzer in der Microsoft Entra-ID erzwungen. Die Passthrough-Vorauthentifizierung löst keine Microsoft Entra-Authentifizierung aus, aus diesem Grund können Richtlinien für bedingten Zugriff nicht erzwungen werden. Bei der Passthrough-Vorauthentifizierung müssen MFA-Richtlinien auf dem on-premises-Server implementiert werden, wenn möglich, oder durch Aktivierung der Microsoft Entra ID-Vorauthentifizierung mit Microsoft Entra Application Proxy.

Kann ich eine Webanwendung mit Clientzertifikat-Authentifizierungsanforderung veröffentlichen?

Nein, dieses Szenario wird nicht unterstützt, da der Anwendungsproxy den TLS-Datenverkehr beendet.

Remotedesktopgateway-Veröffentlichung

Wie kann ich das Remotedesktop Gateway über den Microsoft Entra Application Proxy veröffentlichen?

Weitere Informationen finden Sie unter Veröffentlichen des Remotedesktops mit dem Microsoft Entra-Anwendungsproxy.

Kann ich die eingeschränkte Kerberos-Delegierung (Einmaliges Anmelden – Windows Integrated Authentication) im Szenario der Remotedesktopgateway-Veröffentlichung verwenden?

Nein, dieses Szenario wird nicht unterstützt.

Meine Benutzer verwenden Internet Explorer 11 nicht, und das Szenario der Vorauthentifizierung funktioniert bei ihnen nicht. Entspricht dies dem erwarteten Verhalten?

Ja, das entspricht dem erwarteten Verhalten. Für das Szenario der Vorauthentifizierung ist ein ActiveX-Steuerelement erforderlich, das in Browsern von Drittanbietern nicht unterstützt wird.

Wird der Remotedesktop-Webclient (HTML5) unterstützt?

Ja, dieses Szenario befindet sich derzeit in der Vorschau. Weitere Informationen finden Sie unter Veröffentlichen des Remotedesktops mit dem Microsoft Entra-Anwendungsproxy.

Nach der Konfiguration des Szenarios der Vorauthentifizierung musste ich feststellen, dass sich der Benutzer zweimal authentifizieren muss: zuerst auf dem Microsoft Entra-Anmeldeformular und dann auf dem RDWeb-Anmeldeformular. Entspricht dies dem erwarteten Verhalten? Wie kann ich das auf eine Anmeldung reduzieren?

Ja, das entspricht dem erwarteten Verhalten. Wenn der Computer des Benutzers Microsoft Entra eingebunden ist, meldet sich der Benutzer automatisch bei Microsoft Entra ID an. Der Benutzer muss seine Anmeldeinformationen nur auf dem RDWeb-Anmeldeformular angeben.

Kann ich in einem Szenario zur Microsoft Entra-Vorauthentifizierung die Option „RDP-Datei herunterladen“ der Ressourcenstartmethode unter „Einstellungen“ im Remotedesktop-Webclientportal verwenden?

Mit dieser Option kann der Benutzer die RDP-Datei herunterladen und über einen anderen RDP-Client verwenden (außerhalb des Remotedesktop-Webclients). In der Regel können andere RDP-Clients (etwa der Microsoft-Remotedesktopclient) die Vorauthentifizierung nicht nativ verarbeiten. Deshalb funktioniert das Szenario nicht.

SharePoint-Veröffentlichung

Wie kann ich SharePoint über Microsoft Entra-Anwendungsproxy veröffentlichen?

Entsprechende Informationen finden Sie unter Aktivieren des Remotezugriffs auf SharePoint per Microsoft Entra-Anwendungsproxy.

Kann ich die mobile SharePoint-App (iOS/Android) verwenden, um auf einen veröffentlichten SharePoint-Server zuzugreifen?

Die mobile SharePoint-App unterstützt derzeit keine Microsoft Entra-Vorauthentifizierung.

Veröffentlichung von Active Directory-Verbunddienste (AD FS)

Kann ich den Microsoft Entra-Anwendungsproxy als AD FS-Proxy (z. B. Webanwendungsproxy) verwenden?

Nein, der Microsoft Entra-Anwendungsproxy ist für die Arbeit mit Microsoft Entra ID konzipiert und erfüllt nicht die Anforderungen, um als AD FS-Proxy fungieren zu können.

Kann ich Microsoft Entra Anwendungsproxy verwenden, um einen beliebigen AD FS-Endpunkt (z. B. /adfs/portal/updatepassword/) zu veröffentlichen?

Nein, das wird nicht unterstützt.

WebSocket

Unterstützt Microsoft Entra-Anwendungsproxy das WebSocket-Protokoll?

Anwendungen, die das WebSocket-Protokoll verwenden, z. B. QlikSense und Remotedesktop-Webclient (HTML5), werden jetzt unterstützt. Es gelten die folgenden bekannten Einschränkungen:

  • Der Anwendungsproxy verwirft das Cookie, das in der Serverantwort festgelegt ist, während die WebSocket-Verbindung geöffnet wird.
  • Für die WebSocket-Anforderung wird kein einmaliges Anmelden (Single Sign-On, SSO) angewendet.
  • Die Features (Ereignisprotokolle, PowerShell und Remotedesktopdienste) im Windows Admin Center (WAC) funktionieren nicht über den Microsoft Entra-Anwendungsproxy.

Die WebSocket-Anwendung hat keine eindeutigen Veröffentlichungsanforderungen und kann auf dieselbe Weise wie alle anderen Anwendungsproxyanwendungen veröffentlicht werden.

Wirkt sich die Verwendung der Linkübersetzung auf die Leistung aus?

Ja. Die Verwendung der Linkübersetzung wirkt sich auf die Leistung aus. Der Anwendungsproxydienst überprüft die Anwendung auf hartcodierte Links und ersetzt diese durch die entsprechenden veröffentlichten externen URLs, bevor sie Benutzern angezeigt werden.

Um eine optimale Leistung zu erzielen, empfiehlt sich die Verwendung von identischen internen und externen URLs durch die Konfiguration benutzerdefinierter Domänen. Wenn die Verwendung benutzerdefinierter Domänen nicht möglich ist, können Sie die Leistung der Linkübersetzung durch Verwenden der Erweiterung zur sicheren Anmeldung bei „Meine Apps“ oder des Microsoft Edge-Browsers auf mobilen Geräten verbessern. Siehe Umleiten von hartcodierten Links für Apps, die mit Microsoft Entra-Anwendungsproxy veröffentlicht wurden.

Platzhalter

Wie kann ich mithilfe von Platzhaltern zwei Anwendungen mit demselben benutzerdefinierten Domänennamen, aber mit unterschiedlichen Protokollen – für HTTP und für HTTPS – veröffentlichen?

Dieses Szenario wird nicht direkt unterstützt. Sie haben bei diesem Szenario die folgenden Möglichkeiten:

  1. Veröffentlichen Sie die HTTP-URL und die HTTPS-URL als separate Anwendungen mit einem Platzhalter, aber weisen Sie diesen jeweils eine andere benutzerdefinierte Domäne zu. Diese Konfiguration funktioniert, weil unterschiedliche externe URLs verwendet werden.

  2. Veröffentlichen Sie die HTTPS-URL über eine Platzhalteranwendung. Veröffentlichen Sie die HTTP-Anwendungen separat mithilfe der folgenden PowerShell-Cmdlets für den Anwendungsproxy:

  • Last updated on