OM12 Installation Quick Trick 02: OM12 Database Owner & Why To Change Them

In the second posting of this series I’ll describe the owner of the OM12 databases and why it’s important to change that.

Situation
When installing OM12 the databases are created as well. Automatically the owner of those very same databases is the same account which is used for installing OM12, like this example where I installed OM12 with the domain admin account:

On itself nothing bad. But suppose you install OM12 under your own account and after some time you decide to pursue your career else where. Now your account – the same one you used to install OM12 and thus the owner of the OM12 databases – will be deleted in some point in time.

Now you have an issue at hand since the OM12 databases don’t have an owner any more. The results may vary from some nagging events in the SQLServer log, like this one:

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.

Or – worse – Discoveries not running anymore. This is unwanted behavior. So therefore it’s Best Practice to change the owner of the OM12 databases right away.

Quick Trick
Change the owner of the OM12 databases to an AD account which is specially made for it. Normally when I design and implement an OM12 environment, I request a series of service accounts. Among them I always request a SQL account specifically for OM12, like OM-SQL for instance.

This account is added to the SQL Admin group during the installation of the SQL Server instance used for OM12. Therefore this AD service account is a great candidate for becoming the owner of the OM12 databases.

How to change the DB owner you ask? Just follow this procedure:

1. Open SQL Server Management Studio with an account which has SA permissions on the SQL Server instance which hosts the OM12 databases and connect to that very same SQL Server instance;
2. Right click on the OperationsManager database > Properties > second option on the left Files > click on the button with the three dots next to the text Owner;
   
3. > Browse > Select the AD account which must become the new owner of the database, in this example SC\OM-SQL > OK > OK. Now you have this situation:
   
4. Click OK and after a few seconds the new owner of the OperationsManager database is set;
5. Repeat Steps 2 to 4 for the OperationsManagerDW database as well. Oh, and while your at it, check the owner of the ReportServer database as well. Sometimes it has a wrong owner as well.

This way you have covered possible issues with the OM12 database owner. It’s better to get it right from the start and not later on to bump into strange issues because of it…