binaryfactory.ca

You may have issues with the discovery in SCOM not doing anything other than pretending to be working…for days.

It can happen on new setups, or on existing ones if things in particular break. It is a very common problem, and being the lucky guy I am, I obviously had this issue except none of the fixes discussed on forums worked.

Here’s a link to the thread I opened on technet… which includes a detailed description of the problem:

http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/0d76679f-a6ae-4b41-bae8-5477d905a160

Here’s a rundown of what to check. However, this document doesn’t explain how to do every Windows or AD operation, but if you need more info on a specific step, believe me, there’s a lot of information out there on how to proceed with them..

Bottom line:

1 – Is your SCOM running with Local System or domain service accounts?

Let’s use setspn to check some…SPNs ! setspn -L domain\account

If Local system: Make sure the computer has SPNs registered for: Itself (HOST), the health service (MSOMHsvc) as well as the SDK (MSOMSdkSvc). It needs one SPN with the netbios name only, and one with the FQDN. So that means six SPNs, not counting potential SQL SPNs if you are running SQL on the same box.

If domain accounts: Make sure the computer has the SPNs registered for itself and the health service, for a total of 4 SPNs. Make sure the SDK account has the SDK SPNs registered to itself. If it has not, you have two choices: register it manually using setspn, or give the account access to update its own SPNs. To do this, use adsiedit, browse to the service account, and in the advanced permissions, grant Write ServicePrincipalName to “SELF”. Next time you start the services, the SPNs will get registered, and there’s no chance you’ll make a typo.

2 – Is your SQL service running with Local System or domain service accounts?

Proceed with the same checks as above. We’re looking for SPNs on either the computer account if local or the service account if on the domain. You should find two MSSQLSvc SPNs. One with just the FQDN, and the other one with the port number of the SQL instance. The same steps as above apply, if you want to give the service account the rights to register its own SPN.

3 – Is your clock in sync? Stupid question but hey, it screws up kerberos… check the date too !

4 – Is the SDK account (if it’s a domain account) owner of the SQL OperationsManager database?

If not, this could be a problem if the account used originally to create it is now disabled or deleted. Change it.

5 – Double check for duplicate SPNs.

It is possible that old accounts contain bad MSSQLSvc, MSOMSdkSvc or MSOMHSvc SPNs. I suggest using your favorite AD tools to search. (adfind by joeware, ldifde, ldp.exe can all do the trick). If you identify any duplicate SPNs, delete the bad ones.

6 – Try this in SQL, as a sysadmin.

execute as login = ‘domain\sqlserviceaccount’

The results should be simply OK. Then, try any other domain account.  If you get this error, you still have an impersonation problem:

An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'DOMAIN\scom01opsmgr', error code 0x5.

Add your SQL and SDK service accounts to the Windows Authorization Access domain group. This is what finally fixed it for me !