Loading ...L’une des premières erreurs remontées par SCOM est souvent celle-ci :
Échec du service SDK de System Center Operations Manager lors de l’inscription d’un nom principal de service. Un administrateur de domaine doit ajouter MSOMSdkSvc/SCOMR2 et MSOMSdkSvc/SCOMR2.scala.msft au nom principal de service de SCALA\opsmgrsdk
| Résumé Pour que la console OpsMgr ou tout autre client SDK puisse procéder à une authentification Kerberos, le service d’accès aux données doit enregistrer ses propres noms de service principaux (SPN, Service principal name). Causes S’il n’est pas exécuté en tant que « système local », le service d’accès aux données ne dispose pas des droits suffisants pour enregistrer des SPN dans Active Directory. Solutions Vous pouvez utiliser SetSPN.exe pour enregistrer les SPN associés au service d’accès aux données. Voici les commandes à exécuter à partir d’un compte doté des droits d’administrateur de domaine :
Remarque : si le serveur d’administration racine (RMS, Root Management Server) est ordonné en clusters, utilisez le nom de serveur virtuel. |
Il est important de respecter la casse pour que la commande fonctionne dans ce cas :
- Setspn.exe –A MSOMSdkSvc/SCOMR2 SCALA.MSFT\opsmgrsdk
- Setspn.exe –A MSOMSdkSvc/SCOMR2.scala.msft SCALA\opsmgrsdk
Une autre solution est fournit par Kevin Holman’s : http://blogs.technet.com/kevinholman/archive/2007/12/13/system-center-operations-manager-sdk-service-failed-to-register-an-spn.aspx
Rémy
OpsMgr SDK Service
Flux RSS des catégories : 
Pas de commentaire reçu(s)
Laisser une réponse