Badack's blog

J’ai décidé de dédier un post traitant de 2 erreurs que j’ai rencontré de manière récurrentes lors de mes déploiements d’infrastructures App-V. Ce sont toujours les mêmes problèmes donc autant en faire un petit résumé qui pourra peut-être vous être utile si un jour vous y êtes confronté.

L’ensemble des problèmes traités ici sont générés à partir du client App-V mais l’origine se trouve à chaque fois du côté serveur.

Erreur 00000917:

Le message suivant peut apparaitre pour 2 raisons totalement différentes.

Raison 1
Votre client tente de se connecter sur le serveur App-V pour récupérer les informations nécessaires mais il n’a pas les droits.
Quand je dis qu’il n’a pas les droits, c’est en fait l’utilisateur qui est actuellement connecté sur le poste de travail qui n’a pas les droits.
Lors de l’installation du serveur App-V, vous devez définir 2 groupes :
Le premier groupe est utilisé pour définir les administrateurs de l’infrastructure App-V au travers de la console de management, donc cela ne nous concerne pas. (Ex : GAX-SrvAppV-Adm)
Le second groupe est utilisé pour autoriser les clients, lors d’une connexion, à recevoir les informations ce dont ils ont besoin.  C’est celui-ci qui nous concerne.(Ex : GAX-SrvAppv-Usr)
Si vous recevez cette erreur, c’est que l’utilisateur connecté sur la station de travail n’est pas membre de ce groupe, il vous suffit donc de le rajouter.

Raison 2
Le chemin contenant les fichiers OSD et ICO sur le serveur App-V n’est pas définit.
Pour le définir, connectez-vous à la console de management.
Faites un clic droit sur le serveur App-V et choisissez System Options…

Entrez le chemin correcte, soit en UNC soit en HTTP (tout depend de votre configuration).

Erreur 0000274D:

Cette erreur peut également provenir de 2 sources de problèmes différents.

Raison 1:
Le service Application Virtualization Management Server n’est pas démarré sur le serveur App-V.
Il suffit donc de le démarrer

Raison 2:
Le fichier OSD lié à l’application que vous désirez executer ne contient pas la bonne URL pour obtenir le fichier sft.
En regardant dans le fichier log du client (sftlog.log), on peut remarquer que l’erreur y est indiquée.
Dans notre cas, il s’agit d’une application qui devrait être publiée via le protocol de streaming RTSP et non son pendant sécurisé RTSPS.

Pour solutionner ce problème, vous devez éditer le fichier OSD sur le serveur, corriger le tag suivant et rafraichir le client.

Enjoy !!!!

Quoi de plus normal que d’installer la console de management de App-V sur sur son poste de travail. Il existe un tas d’outils permettant ce scénario nous évitant, par la même occasion, de travailler à distance sans avoir besoin d’initier une session Rdp et risquer LA boulette en travaillant directement sur le serveur (ex: le drag & drop involontaire)

Suite à l’installation de cette console sur mon poste client, lors de ma tentative de connexion sur le serveur App-V, j’ai reçut l’erreur suivante:

Par contre, en utilisant la console de management localement sur le serveur, aucune erreur de connexion.

Le fichier sftmmc.log de la console de gestion de App-V nous donne également un message d’erreur intéressant:

J’ai essayé de reproduire cette erreur dans un environnement de labo avec la même version de App-V (4.5) mais sans succès, car dans cette configuration, un poste client n’avait aucun problème pour initier une connexion distante au niveau de la console.

Google étant notre amis, il n’a pas pu m’aider (dans un premier temps) sur cette erreur assez spécifique.

Mais que signifie cette erreur?

L’erreur The remote server returned an error: (400) Bad Request nous indique que vous vous êtes correctement identifié avec votre compte utilisateur mais qu’une erreur est survenue lors de l’autorisation.

Identification et autorisation sont 2 choses totalement différentes.

D’où peut provenir cette erreur?

L’architecture de App-V est très simple, vous avez un service web qui est installer sur le serveur et qui permet la connexion du client ainsi que de la console de gestion.

Puisque nous avons un problème avec le processus d’autorisation, cela signifie qu’’il y a bien une connexion qui s’est établie entre la console et le service web, donc tout porte à croire que le problème se situe soit au niveau du service web, soit au niveau de l’IIS.

J’ai suivit le guide suivant pour revalider chaque point de l’installation de mon serveur App-V.

• Vérifier les droits sur compte Network Service
• Vérifier que le compte ASP.NET a bien les droits nécessaire sur certains fichiers
• Vérifier l’application pool de l’IIS qui héberge le web service de App-V
• Vérifier quelques autres points de configurations comme les chemins d’accès

Malgré cela, le problème a persisté.

J’ai élargit mon scope de recherche en me basant sur le message d’erreur présent dans le fichier sftmmc.log et par chance j’ai trouvé un article traitant d’un problème similaire pour un autre produit de Microsoft: CLM

Cette article explique que cette erreur peut être générée quand un ticket Kerberos dépasse la taille gérée par défaut par l’IIS. Ce dépassement peut survenir par exemple car votre compte utilisateur se trouve dans beaucoup de groupes.

Et bingo, c’est mon cas. Mon utilisateur est membre de 230 groupes, ce qui génère un ticket Kerberos assez important en taille.

La solution

Pour solutionner ce problème, il faut changer les valeurs par défaut de IIS.

• Créer 2 clés de registre sur le serveur IIS: HKLM\System\CurrentControlSet\Services\Http\Parameters\

• Net stop http
• Net start http
• Net stop iisadmin /y
• Net start “World Wide Web Publishing Service”

Et voilà, tout est rentré dans l’ordre

Résumé des articles:

• Softgrid Remoting Error
• CLM: Http bad request
• Http.sys Registry settings for IIS.

Enjoy !!!