Badack's blog

Cette erreur peut survenir lorsque vous désirez déployer un second Management Server se connectant au DataStore0(la base de donnée SQL App-V) se trouvant sur un autre Management Server.

Cette erreur est générée dans l’Event Viewer avec un ID de 1005 :

Le fichier log de l’installation se trouve à l’emplacement suivant:

Settings\Temp\SoftGrid-server-setup.txt

En analysant le fichier, vous allez trouver l’erreur suivante qui n’est pas des plus explicites mais qui, grâce à l’aide de notre amis Google, est suffisante pour trouver de l’information quand à sa nature.

Voici le scénario qui m’a amené à rencontrer cette erreur.

A. Scénario :

Server1.MyDomain.Lab est le serveur principal de mon infrastructure App-V. Pour des raison d’équilibrage de charges, de redondance, je décide d’installer un second Management Server qui sera Server2.MyDomain.Lab.

Comme vous pouvez le voir sur le schéma, il n’est nullement question d’installer une seconde instance d’SQL Server. Je vous rappelle qu’avant la version 4.5 SP2, vous ne pouviez avoir qu’une seule instance de votre DataStore (à moins de clusteriserle tout).

Le service SQL Service fonctionne sous un compte de domain créé à cet effet : MyDomain\SQL2005SRVC.

Ce compte possède les droits d’administrateur local sur le Server1.MyDomain.Lab mais est un simple utilisateur au niveau du domain.

Lorsque je désire installer mon second management server, l’erreur se produit.

J’ai exécuté l’installation de App-V sous un compte ayant des droits Domain Admin pour écarter tout soucis à ce niveau.

Mais pourquoi diable cette erreur apparait donc ?

B. Explication :

Le fichier log de l’installation contient l’information sur l’erreur : Cannot generate SSPI context.

Qui dit SSPI, dit authentification intégrée Windows donc Kerberos.

Comme mon service SQL Server tourne dans un contexte autre que Local System ou qu’un compte Domain Admin, il lui manque des informations relatives à son Service Principal Name.

Dans mon cas, le compte de service n’avait pas les droits d’écrire de nouvelles valeurs pour son SPN.

Evidement, lorsque votre service SQL Server tourne dans un contexte Local System ou Domain Admin, il n’y a aucun problème de droit pour modifier le SPN.

C. Solution :

Au travers de l’outil ADSIEDIT.MSC, nous allons octroyer les droits de lecture et d’écriture à notre compte de Service : MyDomain\Sql2005Srvc.

1. Démarrer la console ADSIEDIT.MSC



2. Faites un clique droit sur le compte de service (en vous rendant dans le bon container) et sélectionnez Properties.



3. Allez dans l’onglet Security et cliquez sur Advanced



4. Sélectionnez l’entrée portant le nom SELF (si vous ne l’a trouvez pas, ajoutez là) et sélectionnez Edit.



5. Allez dans l’onglet Properties et cochez les 2 entrées suivantes :

• Read servicePrincipalName => Allow
• Write servicePrincipalName => Allow

6. Validez le tout et recommencez l’installation de votre second Management Server.

Pour plus d’information, voici le lien d’un article Microsoft traitant du sujet : Lien

Enjoy !!!!

Share this post: sur Twitter sur Facebook sur Google+

It's only fair to share...