SCOM: MSSQLServer Event ID 28005

Hey everyone, Theron (aka T-) here, Senior Consultant with Microsoft Consulting Services (MCS) specializing in Active Directory, but also dabbles with all things Systems Center.

Recently, while implementing SCOM 2019 in a customer’s environment, I ran into an issue when trying to install agents; the discovery wizard would never complete the ‘discovery’ process. After making sure that my account was granted ‘Log on as a service’ to the management server, I started going through event logs. There really wasn’t anything of interest in the Operations Manager log of the management server, so I moved onto the SQL server hosting the OperationsManager database.

Well, there was lots of interesting things in its Application log….LOTS. The primary event of interest and what I focused on was Event ID: 28005.

Log Name:      Application
Source:        MSSQLSERVER
Date:          10/24/2012 4:55:48 PM
Event ID:      28005
Task Category: Server
Level:         Error
Keywords:      Classic
User:          N/A
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\OmSDK’, error code 0x5.

– Credit goes to the TechNet blogger mentioned later for those details, I copied them from his post.

Essentially, the event is saying that information about the SDK account couldn’t be ‘obtained’ from Active Directory. Really?

I shook my head, literally LOLed and said to myself, “that can’t be true”, but I’m a firm believer in checking all leads, regardless of how far fetched they may be. So, I opened ADUC, found the SDK account and looked at its ACL. I wanted to see if the SQL server or its service account had rights, any rights, through any means, to it.

Wouldn’t you know it? My literal LOL came back to bite me in the backside. I couldn’t find an ACE granting neither SQL accounts, server nor service, rights to the SDK account, not even read. The event being generated now made sense, I think. More on that later.

Now you may be asking yourself, like I did, “why didn’t those SQL accounts have rights to read the SDK account? After all, Authenticated Users should have rights to read just about anything in the directory, right?”. Technically, you’re right, those SQL accounts by default should have read rights to just about anything in the directory….buuuuuuttttt, this wasn’t the case; Authenticated Users didn’t have any rights to the account. And before anyone asks, no, I didn’t look into why. Didn’t have time nor desire at that point, I just wanted to get SCOM functioning correctly.

Before I started “shooting from the hip’ and made any changes, I started scouring the internet, searched high and low for just about everything that made sense regarding this issue. I found a lot of information about the SQL Server Broker service not running. Contrary to what I said earlier about being “a firm believer in checking all leads, regardless of how far fetched they may be”, I didn’t check this one, because I had already verified the service was running.

So I kept searching. Finally, when all hope seemed lost and I was about to making the changes I thought needed to be made, I found a TechNet blog post from 2012 that not only links to details about how the Discovery process works, it was IDENTICAL to the issue I was seeing. Thank you, baby Yoda!!! Kudos to Łukasz Rutkowski for the post. If you’re into screen shots, make sure to check out the post. FWIW, I couldn’t produce screen shots of the actual issue due to security protocol nor could I replicate it in my lab.

Tired of reading at this point, what’s the fix?!?!

After reading the post, which validated my thoughts about a possible fix, I granted read rights for the SDK account to the SQL service account. After doing so, all of the SQL events stopped! Winning! Also, I could discover servers and install the agent. Double winning!

Simple fix to a baffling problem. Well, baffling to me, anyway.