Résolution de problèmes généraux

Les problèmes généraux suivants peuvent survenir lors de l'utilisation d'Amazon AppStream 2.0.

SAMLla fédération ne fonctionne pas. L'utilisateur n'est pas autorisé à consulter les applications AppStream 2.0.

Cela peut se produire parce que la politique intégrée au IAM rôle de fédération SAML 2.0 n'inclut pas les autorisations d'accès à la pileARN. Le IAM rôle est assumé par l'utilisateur fédéré qui accède à une pile AppStream 2.0. Modifiez les autorisations de rôle pour inclure la pileARN. Pour plus d'informations, consultez la section Résolution Intégration d'Amazon AppStream 2.0 avec la SAML version 2.0 des problèmes liés à la fédération SAML 2.0 AWS dans le guide de IAM l'utilisateur.

Après la fédération depuis un ADFS portail, ma session de streaming ne démarre pas. J'obtiens l'erreur suivante : « Sorry connection went down ».

Définissez le type de demande entrante de la règle de réclamation pour l'SAMLattribut NameID UPNet réessayez de vous connecter.

Je reçois une URI erreur de redirection non valide.

Cette erreur est due à un état URL de relais de pile AppStream 2.0 mal formé ou non valide. Assurez-vous que l'état du relais configuré dans votre configuration de fédération est le même que l'état du relais de pile affiché dans les détails de la pile via la console AppStream 2.0. S'ils sont identiques et que le problème persiste, contactez AWS Support. Pour de plus amples informations, veuillez consulter Intégration d'Amazon AppStream 2.0 avec la SAML version 2.0.

Mes Image Builders et mes flottes n'atteignent jamais l'état « Running » (En cours d'exécution). Mes DNS serveurs se trouvent dans un annuaire Simple AD.

AppStream La version 2.0 s'appuie sur les DNS serveurs de votre entreprise VPC pour renvoyer une réponse domain (NXDOMAIN) inexistante pour les noms de domaine locaux qui n'existent pas. Cela permet à l'interface réseau AppStream gérée par la version 2.0 de communiquer avec les serveurs de gestion.

Lorsque vous créez un annuaire avec Simple AD, il AWS Directory Service crée deux contrôleurs de domaine qui fonctionnent également en tant que DNS serveurs en votre nom. Comme les contrôleurs de domaine ne fournissent pas de NXDOMAIN réponse, ils ne peuvent pas être utilisés avec la AppStream version 2.0.

J’ai activé les paramètres de permanence des paramètres d’application pour mes utilisateurs, mais leurs paramètres d’application permanents ne sont pas enregistrés ni chargés.

AppStream La version 2.0 enregistre automatiquement les paramètres de l'application créés à certains emplacements de l'instance Windows. Les paramètres ne sont enregistrés que si votre application les enregistre à l'un de ces emplacements. Pour une liste des emplacements pris en charge, consultez Fonctionnement de la persistance des paramètres d'application. Si votre application est configurée pour enregistrer dans C:\Users\%username% et si les paramètres d'application ne sont pas persistants entre les sessions, le point de montage n'a peut-être pas été créé. Cela empêche l'enregistrement des paramètres dans le VHD fichier contenant les paramètres permanents de l'application de vos utilisateurs.

Pour résoudre ce problème, procédez comme suit :

1. Sur l’instance de flotte, ouvrez l’Explorateur de fichiers et accédez au répertoire du profil utilisateur C:\Users\%username%.

2. Assurez-vous que ce répertoire contient un lien symbolique, puis effectuez l'une des actions suivantes :

   • S'il y a un lien symbolique, assurez-vous qu'il pointe sur D:\%username%.

   • En l'absence de lien symbolique, essayez de supprimer le répertoire C:\Users\%username%.

     Si vous ne parvenez pas à supprimer ce répertoire, identifiez dans le répertoire le fichier qui empêche la suppression et l'application qui a créé le fichier. Ensuite, contactez le fournisseur de l'application pour plus d'informations sur la modification des autorisations sur les fichiers ou déplacez le fichier.

     Si vous pouvez supprimer ce répertoire, contactez nous AWS Support pour obtenir des conseils supplémentaires afin de résoudre ce problème. Pour plus d’informations, consultez le Centre AWS Support.

J’ai activé la permanence des paramètres d’application pour mes utilisateurs, mais dans le cas de certaines applications de streaming, les mots de passe des utilisateurs ne sont pas conservés entre les sessions.

Ce problème se produit dans les cas suivants :

• Les utilisateurs sont des applications de streaming telles que Microsoft Outlook, qui utilisent la protection des données Microsoft API.

• La permanence des paramètres de l’application est activée pour des instances de streaming qui ne sont pas jointes à des domaines Active Directory.

Dans les cas où une instance de streaming n'est pas jointe à un domaine Active Directory, l'utilisateur Windows est différent sur chaque instance de flotte. PhotonUser En raison du mode de fonctionnement du modèle DPAPI de sécurité, les mots de passe des utilisateurs ne sont pas conservés pour les applications utilisées DPAPI dans ce scénario. Dans les cas où des instances de streaming sont jointes à un domaine Active Directory et que l'utilisateur est un utilisateur du domaine, le nom d'utilisateur Windows est celui de l'utilisateur connecté, et les mots de passe des utilisateurs sont conservés pour les applications qui les utilisentDPAPI.

Les données de Google Chrome remplissent le VHD fichier contenant les paramètres permanents de l'application de mes utilisateurs. Cela empêche la permanence de leurs paramètres. Comment puis-je gérer le profil Chrome ?

Par défaut, Google Chrome stocke à la fois les données utilisateur et le cache disque local dans le profil utilisateur Windows. Pour empêcher les données du cache du disque local de remplir le VHD fichier contenant les paramètres permanents des applications des utilisateurs, configurez Chrome pour enregistrer uniquement les données utilisateur. Pour ce faire, sur l’instance d’une flotte, ouvrez la ligne de commande en tant qu’administrateur et démarrez Chrome avec les paramètres suivants pour modifier l’emplacement du cache disque :

chrome.exe --disk-cache-dir C:\path-to-unsaved-location\

L'exécution de Chrome avec ces paramètres empêche la persistance du cache disque entre les sessions AppStream 2.0.

J'ai configuré un domaine personnalisé pour mes sessions de streaming AppStream 2.0 intégrées, mais mes sessions de streaming AppStream 2.0 URLs ne sont pas redirigées vers mon domaine personnalisé.

Pour résoudre ce problème, vérifiez que lorsque vous avez créé votre streaming AppStream 2.0URL, vous avez remplacé le point de terminaison AppStream 2.0 par votre domaine personnalisé. Par défaut, le streaming AppStream 2.0 URLs est formaté comme suit :

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

Pour remplacer le point de terminaison AppStream 2.0 par défaut dans votre streamingURL, remplacez https://appstream2.region dans le URL avec votre domaine personnalisé. Par exemple, si votre domaine personnalisé est le suivanttraining.example.com, votre nouveau streaming URL doit suivre le format suivant :

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

Pour plus d'informations sur la configuration de domaines personnalisés pour les sessions de streaming AppStream 2.0 intégrées, consultezConfiguration requise pour l'utilisation de domaines personnalisés.

J'ai lancé une application sur un parc AppStream 2.0 compatible avec les cartes à puce, et le nombre de certificats disponibles pour l'authentification est limité (voire aucun).

Cela se produit lorsque l’application est lancée avant que le service de propagation des certificats ne soit en cours d’exécution.

Pour résoudre ce problème, utilisez le PowerShell module Get-Service pour demander l'état du service de propagation des certificats et assurez-vous qu'il est en cours d'exécution avant de lancer votre application.

Par exemple, le script suivant ne lance pas l’application tant que le service de propagation des certificats n’est pas en cours d’exécution :

$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: $_"
        
    }
}   

Le service de propagation des certifications ne démarre pas sur mon parc 2.0 compatible avec les cartes à puce AppStream .

Si le service de propagation des certificats ne démarre pas, il se peut que le type de démarrage du service soit défini sur Désactivé. Pour résoudre ce problème, sur le générateur d'images AppStream 2.0 utilisé pour créer l'image de votre flotte, lancez la console de gestion Microsoft Windows Services et assurez-vous que le type de démarrage du service de propagation des certificats n'est pas défini sur Désactivé.

Si le type de démarrage n'est pas défini sur Disabled et que le service ne démarre toujours pas sur votre flotte AppStream 2.0, utilisez le PowerShell module Start-Service pour démarrer le service de propagation des certificats au démarrage de votre instance de flotte.

Par exemple, le PowerShell script suivant démarrera le service s'il détecte qu'il est arrêté :

$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)
}