Allgemeine Problembehebung - Amazon AppStream 2.0
Der SAML-Verbund funktioniert nicht. Der Benutzer ist nicht zur Anzeige der AppStream-2.0-Anwendungen berechtigt.Nach dem Erstellen eines Verbunds von einem ADFS-Portal startet meine Streaming-Sitzung nicht. Ich erhalte die Fehlermeldung „Sorry connection went down” (Entschuldigung, die Verbindung wurde unterbrochen).Ich erhalte einen ungültigen Umleitungs-URI-Fehler.Meine Image Builder und Flotten erreichen nie den Ausführungszustand. Meine DNS-Server befinden sich in einem Simple AD-Verzeichnis.Obwohl ich die Persistenz von Anwendungseinstellungen für meine Benutzer aktiviert habe, werden ihre persistenten Anwendungseinstellungen nicht gespeichert oder geladen.Ich habe die Persistenz der Anwendungseinstellungen für meine Benutzer aktiviert. Für bestimmte Streaming-Anwendungen werden die Passwörter meiner Benutzer jedoch nicht sitzungsübergreifend beibehalten.Google Chrome-Daten füllen die VHD-Datei, in der persistente Anwendungseinstellungen meiner Benutzer enthalten sind. Dadurch wird verhindert, dass ihre Einstellungen dauerhaft gespeichert werden. Wie kann ich das Chrome-Profil verwalten?Ich habe eine benutzerdefinierte Domain für meine eingebetteten Streaming-Sitzungen in AppStream 2.0 eingerichtet, aber meine Streaming-URLs von AppStream 2.0 werden nicht auf meine benutzerdefinierte Domain umgeleitet.Ich habe eine App auf einer Smartcard-fähigen AppStream-2.0-Flotte gestartet und es gibt nur eine begrenzte Anzahl von Zertifikaten (oder keine), die der App zur Authentifizierung zur Verfügung stehen.Der Zertifizierungsweitergabedienst startet nicht auf meiner Smartcard-aktivierten AppStream-2.0-Flotte.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Allgemeine Problembehebung

Im Folgenden finden Sie allgemeine Probleme, die bei der Verwendung von Amazon AppStream 2.0 auftreten können.

Problembereiche

Der SAML-Verbund funktioniert nicht. Der Benutzer ist nicht zur Anzeige der AppStream-2.0-Anwendungen berechtigt.

Dies kann der Fall sein, da die Inline-Richtlinie, die für die IAM-Rolle des SAML-2.0-Verbunds eingebettet ist, keine Berechtigungen für den Stack-ARN enthält. Die IAM-Rolle wird vom Verbundbenutzer übernommen, der auf einen AppStream-2.0-Stack zugreift. Bearbeiten Sie die Rollenberechtigungen, um den Stack-ARN einzuschließen. Weitere Informationen finden Sie unter Amazon-AppStream-2.0-Integration mit SAML 2.0 und Fehlerbehebung für SAML-2.0-Verbund mit AWS im IAM-Benutzerhandbuch.

Nach dem Erstellen eines Verbunds von einem ADFS-Portal startet meine Streaming-Sitzung nicht. Ich erhalte die Fehlermeldung „Sorry connection went down” (Entschuldigung, die Verbindung wurde unterbrochen).

Legen Sie den Eingehenden Anspruchstyp der Anspruchsregel für das SAML-Attribut der Namens-ID auf UPN fest und versuchen Sie, sich erneut zu verbinden.

Ich erhalte einen ungültigen Umleitungs-URI-Fehler.

Dieser Fehler tritt aufgrund einer falsch formatierten oder ungültigen RelayState-URL im AppStream-2.0-Stack auf. Stellen Sie sicher, dass der in Ihrer Verbundeinrichtung konfigurierte RelayState identisch mit dem RelayState des Stacks ist, der in den Stack-Details über die AppStream-2.0-Konsole angezeigt wird. Wenn er übereinstimmt und das Problem weiterhin besteht, wenden Sie sich an den AWS Support. Weitere Informationen finden Sie unter Amazon-AppStream-2.0-Integration mit SAML 2.0.

Meine Image Builder und Flotten erreichen nie den Ausführungszustand. Meine DNS-Server befinden sich in einem Simple AD-Verzeichnis.

AppStream 2.0 verlässt sich darauf, dass die DNS-Server innerhalb Ihrer VPC eine Antwort auf eine nicht existierende Domain (NXDOMAIN) für lokale Domain-Namen zurückgeben, die nicht vorhanden sind. Auf diese Weise kann die von AppStream 2.0 verwaltete Netzwerkschnittstelle mit den Management-Servern kommunizieren.

Wenn Sie ein Verzeichnis mit Simple AD anlegen, erstellt AWS Directory Service zwei Domain-Controller, die zugleich für Sie als DNS-Server fungieren. Da die Domain-Controller die NXDOMAIN-Antwort nicht bereitstellen, können sie nicht mit AppStream 2.0 verwendet werden.

Obwohl ich die Persistenz von Anwendungseinstellungen für meine Benutzer aktiviert habe, werden ihre persistenten Anwendungseinstellungen nicht gespeichert oder geladen.

AppStream 2.0 speichert automatisch Anwendungseinstellungen, die an bestimmten Speicherorten auf der Windows-Instance erstellt werden. Die Einstellungen werden nur gespeichert, wenn Ihre Anwendung sie an einem dieser Speicherorte speichert. Eine Liste der unterstützten Speicherorte finden Sie unter So funktioniert die Persistenz von Anwendungseinstellungen. Wenn Ihre Anwendung zum Speichern unter C:\Users\%username% konfiguriert ist und die Einstellungen Ihrer Benutzer für die Anwendung zwischen Sitzungen nicht persistent sind, wurde möglicherweise kein Bereitstellungspunkt erstellt. Dadurch wird verhindert, dass die Einstellungen in der VHD-Datei gespeichert werden, die die persistenten Anwendungseinstellungen Ihrer Benutzer enthält.

Um dieses Problem zu beheben, führen Sie die folgenden Schritte aus:

  1. Öffnen Sie auf der Flotten-Instance Datei-Explorer und navigieren Sie zu dem Benutzerprofil-Verzeichnis unter C:\Users\%username%.

  2. Bestätigen Sie, ob dieses Verzeichnis eine symbolische Verknüpfung (symlink) enthält, und führen Sie dann einen der folgenden Schritte aus:

    • Wenn eine symbolische Verknüpfung (symlink) vorhanden ist, vergewissern Sie sich, dass sie auf D:\ %username% verweist.

    • Wenn keine symbolische Verknüpfung (symlink) vorhanden ist, versuchen Sie das Verzeichnis C:\Users\%username% zu löschen.

      Falls Sie dieses Verzeichnis nicht löschen können, bestimmen Sie, durch welche Datei im Verzeichnis das Löschen verhindert wird und mit welcher Anwendung diese Datei erstellt wurde. Bitten Sie dann den Anwendungshersteller um Informationen zum Ändern der Dateiberechtigungen oder verschieben Sie die Datei.

      Wenn Sie dieses Verzeichnis löschen können, wenden Sie sich an den AWS Support, um weitere Hilfe bei der Lösung dieses Problems zu erhalten. Weitere Informationen finden Sie unter AWS Support Center.

Ich habe die Persistenz der Anwendungseinstellungen für meine Benutzer aktiviert. Für bestimmte Streaming-Anwendungen werden die Passwörter meiner Benutzer jedoch nicht sitzungsübergreifend beibehalten.

Dieses Problem tritt in folgenden Fällen auf:

  • Benutzer streamen Anwendungen, wie etwa Microsoft Outlook, die die Microsoft-Datenschutz-API verwenden.

  • Die Persistenz der App-Einstellungen ist für Streaming-Instances aktiviert, die mit keinen Active-Directory-Domains verknüpft sind.

Falls eine Streaming-Instance nicht mit einer Active-Directory-Domain verbunden ist, unterscheidet sich der Windows-Benutzer, PhotonUser, auf jeder Flotten-Instance. Aufgrund der Funktionsweise des DPAPI-Sicherheitsmodells bleiben die Passwörter von Benutzern für Anwendungen nicht erhalten, die DPAPI in diesem Szenario verwenden. Wenn Streaming-Instances mit einer Active-Directory-Domain verknüpft sind und es sich beim Benutzer um einen Domain-Benutzer handelt, ist der Windows-Benutzername der des angemeldeten Benutzers und die Passwörter der Benutzer bleiben für Anwendungen erhalten, die DPAPI verwenden.

Google Chrome-Daten füllen die VHD-Datei, in der persistente Anwendungseinstellungen meiner Benutzer enthalten sind. Dadurch wird verhindert, dass ihre Einstellungen dauerhaft gespeichert werden. Wie kann ich das Chrome-Profil verwalten?

Google Chrome speichert standardmäßig sowohl Benutzerdaten als auch das lokale Festplatten-Cache im Windows-Benutzerprofil. Um zu verhindern, dass die VHD-Datei, in der sich die persistenten Anwendungseinstellungen der Benutzer befinden, mit lokalen Festplatten-Cachedaten gefüllt wird, konfigurieren Sie Chrome so, dass darin nur die Benutzerdaten gespeichert werden. Öffnen Sie dazu auf der Flotten-Instance die Befehlszeile als Administrator und starten Sie Chrome mit den folgenden Parametern, um den Speicherort des Datenträger-Caches zu ändern:

chrome.exe --disk-cache-dir C:\Pfad_zu_nicht_gespeichertem_Verzeichnis\

Wenn Chrome mit diesen Parametern ausgeführt wird, verhindert das, dass der Datenträger-Cache zwischen AppStream-2.0-Sitzungen gespeichert wird.

Ich habe eine benutzerdefinierte Domain für meine eingebetteten Streaming-Sitzungen in AppStream 2.0 eingerichtet, aber meine Streaming-URLs von AppStream 2.0 werden nicht auf meine benutzerdefinierte Domain umgeleitet.

Überprüfen Sie, ob Sie bei der Erstellung der Streaming-URL von AppStream 2.0 den AppStream-2.0-Endpunkt durch Ihre benutzerdefinierte Domain ersetzt haben, um dieses Problem zu beheben. Standardmäßig sind AppStream-2.0-Streaming-URLs wie folgt formatiert:

https://appstream2.region.aws.amazon.com/authenticate?parameters=authenticationcode

Geben Sie anstelle https://appstream2.Region in der URL Ihre benutzerdefinierte Domain ein, um den standardmäßigen AppStream-2.0-Endpunkt in Ihrer Streaming-URL zu ersetzen. Wenn Ihre benutzerdefinierte Domain beispielsweise training.example.com lautet, muss Ihre neue Streaming-URL diesem Format entsprechen:

https://training.example.com/authenticate?parameters=authenticationcode

Weitere Informationen zur Konfiguration benutzerdefinierter Domains für eingebettete Streaming-Sitzungen in AppStream 2.0 finden Sie unter Konfigurationsanforderungen für die Verwendung benutzerdefinierter Domänen.

Ich habe eine App auf einer Smartcard-fähigen AppStream-2.0-Flotte gestartet und es gibt nur eine begrenzte Anzahl von Zertifikaten (oder keine), die der App zur Authentifizierung zur Verfügung stehen.

Dies geschieht, wenn die Anwendung gestartet wird, bevor der Zertifikatweitergabedienst ausgeführt wird.

Verwenden Sie zur Behebung dieses Problems das PowerShell-Modul Get-Service, um den Status des Zertifikatweitergabedienstes abzufragen, und vergewissern Sie sich, dass er ausgeführt wird, bevor Sie Ihre Anwendung starten.

Das folgende Skript zum Beispiel startet die Anwendung erst, wenn der Zertifikatweitergabedienst ausgeführt wird:

$logFile = "$Env:TEMP\AS2\Logging\$(Get-Date -Format "yyyy-MM-dd-HH-mm-ss")_applaunch.log" New-Item -path $logfile -ItemType File -Force | Out-Null Function Write-Log { Param ([string]$message) $stamp = Get-Date -Format "yyyy/MM/dd HH:mm:ss" $logoutput = "$stamp $message" Add-content $logfile -value $logoutput } if (Get-Service -Name "CertPropSvc" | Where-Object -Property Status -eq Running) { Write-Log "The Certificate Propagation Service is running. Launching Application..." try { Start-Process -FilePath "Path to Application" -WindowStyle Maximized -ErrorAction Stop } catch { Write-Log "There was an error launching the application: $_" } } else { do { $status = Get-Service "CertPropSvc" | select-object -ExpandProperty Status Write-Log "The Certificate Propagation service status is currently $status" Start-Sleep -Seconds 2 } until (Get-Service -Name "CertPropSvc" | Where-Object -Property Status -eq Running) write-log "The Certificate Propagation Service is running. Launching Application..." try { Start-Process -FilePath "Path to Application" -WindowStyle Maximized -ErrorAction Stop } catch { Write-Log "There was an error launching the application: $_" } }

Der Zertifizierungsweitergabedienst startet nicht auf meiner Smartcard-aktivierten AppStream-2.0-Flotte.

Wenn der Zertifikatweitergabedienst nicht startet, ist der Starttyp des Dienstes möglicherweise auf Deaktiviert eingestellt. Starten Sie zur Behebung dieses Problems auf dem AppStream 2.0 Image Builder, mit dem Sie das Abbild Ihrer Flotte erstellt haben, die Microsoft Management Console für Windows-Services und vergewissern Sie sich, dass der Starttyp des Zertifikatweitergabedienstes nicht auf Deaktiviert eingestellt ist.

Wenn der Starttyp nicht auf Deaktiviert eingestellt ist und der Dienst in Ihrer AppStream-2.0-Flotte immer noch nicht startet, verwenden Sie das PowerShell-Modul Start-Service. Auf diese Weise startet der Zertifikatweitergabedienst beim Start Ihrer Flotten-Instance.

Das folgende PowerShell-Skript startet den Service beispielsweise, wenn es feststellt, dass er sich in einem gestoppten Zustand befindet:

$logFile = "C:\AppStream\Logging\$(Get-Date -Format "yyyy-MM-dd-HH-mm-ss")_certpropcheck.log" New-Item -path $logfile -ItemType File -Force | Out-Null Function Write-Log { Param ([string]$message) $stamp = Get-Date -Format "yyyy/MM/dd HH:mm:ss" $logoutput = "$stamp $message" Add-content $logfile -value $logoutput } if (Get-Service -Name "CertPropSvc" | Where-Object -Property Status -eq Running) { Write-Log "The Certificate Propagation Service is running. Exiting..." Exit } else { do { if (Get-Service -Name "CertPropSvc" | Where-Object -Property Status -eq Stopped) { Write-Log "The Certificate Propagation Service is stopped, attepmting to start..." try { Start-Service -Name "CertPropSvc" -ErrorAction Stop } catch { Write-Log "There was a problem starting the service: $_" break } $status = Get-Service "CertPropSvc" | select-object -ExpandProperty Status Write-Log "The Certificate Propagation service status is currently $status" } else { $status = Get-Service "CertPropSvc" | select-object -ExpandProperty Status Write-Log "The Certificate Propagation service status is currently $status" break } } until (Get-Service -Name "CertPropSvc" | Where-Object -Property Status -eq Running) }