Friday, November 28, 2008

SCOM Database Owner

When one is installing a SCOM environment (for a customer for instance) one will do so with a certain account. However, this account becomes automatically the owner of the database. On it self no worries there. But what happens when this accounts gets disabled or removed?

Certain issues will arise, like SCOM not being able to discover new systems.

Therefore it is better to change the ownership of the SCOM databases to an account which never will be deleted. Even better is to use a specific Acitve Directory (AD) account for it. Be sure to grant this account only the needed permissions and nothing more.  

Otherwise these errors will pop-up in the SQLSERVER log:

Event Type: Error
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 28005
Date: xx-xx-xxxx
Time: xx:xx:xx
User: N/A
Computer: BLA
Description:
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\ACCOUNT', error code 0xea.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 65 6d 00 00 10 00 00 00 em......
0008: 08 00 00 00 53 00 43 00 ....x.x.
0010: 4f 00 4d 00 53 00 51 00 x.x.x.x.
0018: 4c 00 00 00 07 00 00 00 x.......
0020: 6d 00 61 00 73 00 74 00 m.a.s.t.
0028: 65 00 72 00 00 00 e.r...

Follow this procedure for correcting this issue:

First you have to create a dedicated AD account and grant it just enough permissions. This account will be used in the procedure:

1. Start SQL Server Management Studio
2. Go to Databases --> System Databases
3. Select Properties
4. On the Select a Page select Files
5. On the right under header Database the current owner is displayed
6. Check the account. It's not the dedicated AD account? Click the button with the 3 dots
7. The screen 'Select Database Owner' appears
8. Click Browse. Select the dedicated AD account
9. Save the modifications
10. Close all screens

Repeat these steps for all SCOM related databases.

8 comments:

Barry said...

I just installed OpsMgr 2007 SP1 and I'm getting these errors you're talking about. The account I used to install OpsMgr is a member of the local administrator group and is also the db owner of the OpsMgr databases. Do you have any suggestions about how to fix these errors. Right now the discovery wizard hangs and doesn't discover any computers. I've already looked at KB 938994, but it didn't help.

Marnix Wolf said...

Hi Barry.

When the discovery wizard doesn't work (it hangs) it could be a problem with the SQL Broker not working. Check this posting of mine where you can check whether that's the case and how to resolve it. Keep me posted about how you're doing.

Posting: http://thoughtsonopsmgr.blogspot.com/2009/01/scom-discovery-wizard-doesnt-work.html

Best regards,
Marnix

Barry said...

Marnix,
I ended up having to call MS support. The problem was that the SPN was not set correctly. I was doing a reinstall and the SPN was still registered with the machine name from the previous installation, rather than with the active directory account I was using for the SDK service. We deleted the 2 entries for MSOMSDKSVC and then added them back with the correct account. Thanks for getting back with me.

Marnix Wolf said...

Hi Barry.

Good to know all is well again.

Best regards,
Marnix

Brian Deyo said...

Hi Marnix, Barry,

It wasn't specified on what object in AD you changed the SPN on, was it the RMS? Was it on the SDK/Config svc account you have setup?

I'm experiencing the same symptoms you are having, and am also reinstalling OpsMgr, but didn't remove the computer objects from AD before I reinstalled. If you happen to see this I would appreciate any response you can offer me.

thanks!

Marnix Wolf said...

Hello Brian.

Thanks for visiting my blog.

Eventhough I do not have more information from Barry than he mentioned in his comments, I logically presume it is the SDK domain account he changed the SPN on.

Kevin Holman has blogged about resolving this issue, to be found here: http://blogs.technet.com/kevinholman/archive/2007/12/13/system-center-operations-manager-sdk-service-failed-to-register-an-spn.aspx.

Please let me know whether this helped.

Best regards,
Marnix Wolf

Brian Deyo said...

Hi Marnix,

Thanks for the information on the SPN links. It turns out that my issue was stemming from installing the OpsMgr DB while logged in locally as the Config/SDK account I created. This prevented the OpsMgr install from setting the correct users and permissions on the SQL database. So for me it was solved by uninstalling the DB & RMS, logging in under a domain admin account and reinstalling.

Thanks for having this blog... it will come in very helpful I feel.

Marnix Wolf said...

Hi Brian.

Thank you for your nice words. Whenever you have a question do not hesistate to ask me.

Best regards,
Marnix