|
|
 
0 |
UPDATE (Sept 2009) -
- Added detail on the fix for granting the OpsMgr SDK account SELF rights to modify the service pricipal name (SPN)
- Added links to related articles
Alert:
The System Center Operations Manager SDK service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/rmscomputer and MSOMSdkSvc/rmscomputer.domain.com to the servicePrincipalName of DOMAIN\sdkaccount
Issue:
Every time the SDK service starts, it tries to update the SPN’s on the AD account that the SDK service runs under. It fails, because by default, a user cannot update its own SPNs. Therefore we see this error logged.
This issue also may cause issue with agent deployment, resulting in errors 21016, 20057, 21001 in the OpsMgr Event Log on the agent computer
Resolution:
The SDK account is a domain admin ( it does not fail), because a domain admin would have the necessary rights. You do not want the SDK account being a domain admin. That isn’t required nor is it a best practice.
To resolve this error, allow the SDK service account permission to update the SPN. On user account object for the SDK account in Active Directory, simply grant SELF to have full control. The most secure solution is to only grant SELF the right of modifying the SPN:
-
Run ADSIEdit as a domain admin.
-
Find the SDK domain account, right click, properties.
-
Select the Security tab, click Advanced.
-
Click Add. Type “SELF” in the object box. Click OK.
-
Select the Properties Tab.
-
Scroll down and check the “Allow” box for “Read servicePrincipalName” and “Write servicePrincipalName”
-
Click OK. Click OK. Click OK.
- Restart your SDK service
To check SPNs:
SPNs can be checked with the SETSPN command line utility. The following command will show all the HealthService SPN's in the domain:
Ldifde -f c:\ldifde.txt -t 3268 -d DC=DOMAIN,DC=COM -r "(serviceprincipalname=MSOMHSvc/*)" -l serviceprincipalname -p subtree
To view SPN's for a specific server:
"setspn -L servername"
Related Articles:
Submitted By: Pete Zerger, MVP