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 sind allgemeine Probleme aufgeführt, die bei der Verwendung von WorkSpaces Amazon-Anwendungen auftreten können.

Der SAML-Verbund funktioniert nicht. Der Benutzer ist nicht berechtigt, WorkSpaces Anwendungsanwendungen anzusehen.

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 von dem Verbundbenutzer übernommen, der auf einen WorkSpaces Anwendungsstapel zugreift. Bearbeiten Sie die Rollenberechtigungen, um den Stack-ARN einzuschließen. Weitere Informationen finden Sie unter Integration von WorkSpaces Amazon-Anwendungen 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 URL für den WorkSpaces Anwendungs-Stack-Relay-Status auf. Stellen Sie sicher, dass der in Ihrem Verbund-Setup konfigurierte Relay-Status dem Stack-Relay-Status entspricht, der in den Stack-Details über die WorkSpaces Applications Console angezeigt wird. Wenn sie identisch sind und das Problem weiterhin besteht, wenden Sie sich an AWS Support. Weitere Informationen finden Sie unter Integration von WorkSpaces Amazon-Anwendungen mit SAML 2.0.

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

WorkSpaces Anwendungen verlassen sich darauf, dass die DNS-Server in Ihrer VPC eine Antwort auf eine nicht vorhandene Domäne (NXDOMAIN) für lokale Domainnamen zurückgeben, die nicht existieren. Dadurch kann die WorkSpaces Applications-managed Netzwerkschnittstelle mit den Verwaltungsservern kommunizieren.

Wenn Sie ein Verzeichnis mit Simple AD erstellen, werden zwei Domänencontroller AWS Directory Service erstellt, die in Ihrem Namen auch als DNS-Server fungieren. Da die Domänencontroller die NXDOMAIN-Antwort nicht bereitstellen, können sie nicht mit WorkSpaces Anwendungen verwendet werden.

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

WorkSpaces Applications speichert automatisch Anwendungseinstellungen, die an bestimmten Speicherorten auf der Windows-Instanz erstellt wurden. 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:

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:

In Fällen, in denen eine Streaming-Instance keiner Active Directory-Domäne angehört PhotonUser, ist der Windows-Benutzer auf jeder Flotteninstanz unterschiedlich. 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:\path-to-unsaved-location\

Wenn Sie Chrome mit diesen Parametern ausführen, wird verhindert, dass der Festplatten-Cache zwischen WorkSpaces Anwendungssitzungen gespeichert wird.

Ich habe eine benutzerdefinierte Domain für meine eingebetteten WorkSpaces Anwendungsstreaming-Sitzungen eingerichtet, aber meine WorkSpaces Anwendungs-Streaming-URLs leiten nicht zu meiner benutzerdefinierten Domain weiter.

Um dieses Problem zu beheben, stellen Sie sicher, dass Sie bei der Erstellung Ihrer WorkSpaces Anwendungs-Streaming-URL den WorkSpaces Anwendungs-Endpunkt durch Ihre benutzerdefinierte Domain ersetzt haben. Standardmäßig sind Streaming-URLs für WorkSpaces Anwendungen wie folgt formatiert:

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

Um den WorkSpaces Standard-Anwendungsendpunkt in Ihrer Streaming-URL zu ersetzen, ersetzen Sie https://appstream2. region die URL durch Ihre benutzerdefinierte Domain. 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 Domänen für eingebettete WorkSpaces Anwendungsstreaming-Sitzungen finden Sie unterKonfigurationsanforderungen für die Verwendung benutzerdefinierter Domänen.

Ich habe eine App auf einer Smartcard-fähigen WorkSpaces Anwendungsflotte gestartet, und der App steht eine begrenzte Anzahl von Zertifikaten (oder keine) zur Authentifizierung zur Verfügung.

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

Um dieses Problem zu beheben, verwenden Sie das PowerShell Modul, Get-Service um den Status des Certificate Propagation Service abzufragen, und stellen Sie sicher, dass er läuft, 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 Certification Propagation Service wird auf meiner Smartcard-fähigen WorkSpaces Anwendungsflotte nicht gestartet.

Wenn der Zertifikatweitergabedienst nicht startet, ist der Starttyp des Dienstes möglicherweise auf Deaktiviert eingestellt. Um dieses Problem zu beheben, starten Sie in dem WorkSpaces Applications Image Builder, mit dem Sie das Image Ihrer Flotte erstellt haben, die Microsoft Management Console für Windows-Dienste und stellen Sie sicher, dass der Starttyp des Zertifikatsverbreitungsdienstes nicht auf Deaktiviert gesetzt ist.

Wenn der Starttyp nicht auf Deaktiviert gesetzt ist und der Dienst in Ihrer WorkSpaces Anwendungsflotte immer noch nicht gestartet wird, verwenden Sie das PowerShell Modul, um den Certificate Propagation Service Start-Service zu starten, wenn Ihre Flotten-Instance gestartet wird.

Beispielsweise startet das folgende PowerShell Skript den Dienst, 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)
}   

Ich kann mich nach der SAML-Authentifizierung nicht mit meinem Active Directory-Benutzernamen oder -Passwort anmelden.

Die NameID im SAML-Anspruch muss mit dem Benutzernamen in Active Directory übereinstimmen. Einige IdPs erfordern ein Update, eine Aktualisierung oder eine erneute Bereitstellung, nachdem bestimmte Attribute angepasst wurden. Wenn Sie eine Anpassung vornehmen und diese nicht in Ihrer SAML-Erfassung berücksichtigt wird, lesen Sie in der Dokumentation Ihres IdP oder im Supportprogramm nach, welche spezifischen Schritte erforderlich sind, damit die Änderung wirksam wird.