Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

Configuring Run As Accounts and Profiles in OpsMgr – A SQL Management Pack Example

I am running SCOM 2007 R2 with SQL 2000/05/08 MPs deployed, and I am experiencing an issue where SCOM is only discovering half of my SQL virtual instance. For excample, I have a 2 node physical SQL cluster running six virtual SQL instance (i.e. vsqla; vsqlb; vsqlc; vsqld; vsqle; vsqlf) and when I go to the Discovered Inventory view and search for theseinstances I only find vsqla/b/e.

>All instances are running under the same SQL service domainaccount

>SCOM SQL Run-As profile is configured to use the default account (SCOM admin account) which is part of the local admin group of this cluster, I even granted this ID domain admin rights but that didn't do anything.

>SCOM agent is installed on both nodes and the PROXY setting is set to enable

>If I look under "Agentless Managed" I only see the said three virtual instance

Any idea what I am missing hereor have you seen something like this before with SQL Management Pack?

Hi Kevin – I have maybe a little bit different problem. I would like to configure a custom RunAs profile for agent installation, and use a RunAs account associated with it. The reason for this is I'm an admin for SCOM, but not domain admin, and our domain security policy has things pretty tightly locked down. There is an installation account configured with Local Admin rights on the servers, and we are using a domain user service account for the agent action account. All the documentation I've found says the agent installation is only able to be performed by the Managemnt Server action account, or an optional account that doesn't save credentials. Is there any way around this that you know of?

"Scenario #2. You use a Domain User account as the default action account.

This account is a member of the Local Administrators group on the server OS. This domain user account has been delegated “SA” rights in SQL explicitly, or via group membership. In this case – the default agent action account has full rights to the Operating System and to SQL. No other configuration or use of Run-As accounts is necessary. The SQL MP will discover and monitor the SQL instances. (Hint – you might consider just using this special account as the default agent action account ONLY for your SQL servers). This is more secure than scenario #1 above, but is more difficult to manage in some cases"

I've verified each instance has "local administrator" "SA" right , but I am still having issues discovery all virtual instances. Anything else I can look at to see whySCOM is unable to see all VSQLs in a two node cluster?

Yes – that will be a soon to come post – I am going to get some assistance and figure out a good way to handle dynamic run as account distribution using the SDK – since the UI leaves a lot to be desired. Stay tuned.

One of the big problems with using the "More Secure" option for distributing Run-As accounts is that every time a new (SQL, in this example) server comes online, the SQL team needs to tell the SCOM team that they've added a new SQL box and to go in and add in the new server. Unfortunately, there's no way to distribute to a dynamic grouping easily (I suppose you could hack something in with powershell, maybe…)

Look in your event logs on the nodes – you will see discovery errors, or – look on the management server event logs that the agents report to – you will see 10801/33333 events about failing to insert discovery data.

Next – your account being a domain admin is irrellevant (and should NEVER be used). What is relevant – is doe the account be used for discovery (default agent action account) have enough rights on the machine to be able to discover the instance….. if some are discovering but not others on the same node – then look at the differences in SQL INSTANCE security.

Last – if the events seen on the agent are timeouts for discovery – increase the timeout via override.

"Wed, Sep 8 2010 4:56 PM: Yes – that will be a soon to come post – I am going to get some assistance and figure out a good way to handle dynamic run as account distribution using the SDK – since the UI leaves a lot to be desired. Stay tuned."

any update on that dynamic run as account distribution? adding each sql server manually is an absolutely fantastic solution in a lab with a half-dozen machines. adding each sql server manually in a production environment is, in a word, ridiculous.

Automatic distribution would indeed be great. Right now I've got a series of PS scripts that ops can run as a task to map the various RunAs profiles for SQL. It helps some, but is only as good as the underlying process. Nice detailed explanation, Kevin.

i'm still puzzled why a domain account with local admin rights and sa rights is generally considered more secure than the system account (scenario 1 vs 2 in your post). it seems to me the domain account has extra rights in the domain whereas the system account can't go beyond the local system.

Thanks for another great article Kevin – I have notied that this rule also fires an alert against the SQL Server if the SQL Server hosts databases that are set to auto-close. Workaround of creating a group of databases and over-riding the rule (enable = false) for the group seems to work.

"Yes – that will be a soon to come post – I am going to get some assistance and figure out a good way to handle dynamic run as account distribution using the SDK – since the UI leaves a lot to be desired. Stay tuned. "

You wrote: "Our goal is to make the initial discoveries – which target the “Windows Server” class, run under the default agent action account. THEN – ALL subsequent discoveries should run under the SQL Discovery Profile/Run As account. Therefore – we should add the “SQL DB Engine” class."

Most of my sql servers can be monitored using the default action account (local system), but I have some sql servers that need to be monitored using another account (domain account). How do I target this runas account? I can not use the SQL DB Engine class because then all sql servers will use this run as account.

Hi Kevin, thanks for this information. My concern is if you are using the Local System account for the “Default Agent Action Account”, what would stop someone from making the agent run scripts that could potentally do damage to the system?

Thanks for your work here. I am having a problem recently where a SQL instance was recently encrypted and as a result the SCOM agent is not able to query the MSCluster namespace via WMI. I am getting repeating event 5605 in the app log of the cluster node.
Here is an article that appears to describe the problem I am having.

As a nice bonus for me, this seemed to cause all SQL and cluster monitors on that SQLcluster to thrash offline and online causing an impressive state storm filling up our Ops DB and taking the RMS offline. Temporarily placing the SQL/cluster objects in
maintenanace mode addressed the state storm and allowed me to free space and make sure the RMS was back online again. However now I am not monitoring the SQL or clustered objects on that cluster so I need to find a way to address the root cause.

I am not sure, but could perhaps you could confirm if setting up a Run as account with higher level permissions to execute the SCOM SQL/Cluster workloads on these encrypted instances would address this issue?

I am concerned that it won’t because the eventid suggests that the resolution has to do with changing the authentication level to Pkt_Privacy.

Awesome post! I am almost ashamed I have only recently been able to implement RunAs for SQL in our environment. But I do not understand why RunAs setup seems to double the work. Distributing the creds to certain systems from the account, then setting up the profile to apply the account to those same systems seems duplicitous. I do not understand but am glad it works to optimize our monitoring capabilities. We are in a decentralized environment where SQL team is not responsible for every SQL server in our enterprise, distribution of specific RunAs creds to specific SQL servers. I was able to point the profile config to a group but you can't push RunAs account creds to a group. But one of the options for adding systems to RunAs cred distribution is 'Show suggested computers'. I picked that and hit Search and the agents for each of the systems from the group were listed. A quick way to add all the correct agents to get those creds! Thanks very much!

Hi Kevin, I have SCOM 2007 R2 in my environment & I am using a SQL Action account as specified above for the SQL monitoring. I have noticed that we are not getting any alerts from the DB, we tested this by decommissiong the DB also, but no alert from the host server on SCOM. We feel, there is no monitoring happening for the SQL DB. How can I troubleshoot this issue?

I’ve configured the low-privilege setup on a couple 2012 SQL servers that were not working well with letting Local System be the action account. I’m getting good data now. I’m now trying the same setup with the SQL cluster used for my SCOM database instances.
I am getting PowerShell script execution error messages in the OpsMgr console saying that there are not enough permissions for the account. When I look at the SQL error logs, I see that something (I’m assuming the MP scripts) is trying to log into the databases
as NT AUTHORITYSYSTEM and can’t because that login is not mapped to any databases. Why wouldn’t the MP be trying to execute those scripts as one of the action accounts I created as part of the low-privilege setup? Does some other object other than the nodes
need the action accounts specified in the RunAs profile?

One of the best explanation on Run As Account & Profile. I was struggling to understand the concept for a while as, I am new to OM. Now, I understood what it mean and how to relate to profile. Thank you very much.

First I would like to thank you for one of the best explanations on how to implement this.

Second, I see that if my SQL Server has the proxy checked I get "An account specified in the Run As profile "Microsoft.SQLServer.SQLDiscoveryAccount" cannot be resolved." error on machines that look to that SQL Server. So if I add these servers to the Distribution
list under the Account it goes away. Is this right?

Hi Kevin,
I get "An account specified in the Run As profile "Microsoft.SQLServer.SQLDiscoveryAccount" cannot be resolved." error on machines that look to that SQL Server. The error still even after I distributed the Run As accounts to all the computers where the error
is thrown.

Thanks for the reply Kevin. But I have distributed the accounts to this server by editing the distribution list manually still the error persists. The server is also in the same domain as the Management servers. Really strange. Infact this appears on all
the SQL servers though the account has been distributed to all of them.

Hi Kevin. quick help needed please. I am installing SCOM2012R2 and just configured the first management server. However I am getting the below error and MS is showing in greyed out state:
“The Health Service could not log on the RunAs account (database read account) for management group (SCOMMG) because it has not been granted the "Allow log on locally" right.”
Not sure why it is asking Read account to have log on access locally but still I added that account as administrator on MS, Operation DB server and DWH and checked local profile setting that it allows administrators to logon locally. But no help. Could you
please suggest a solution here.

The Datawarehouse Read account opens up a process on all management servers to run operations associated with the DW. This account should be granted local administrator on the SCOM management servers. This is documented in our deployment guide. To make things
simple, I recommend having a global group for SCOM admins, and add all the service accounts to this. This use this group as member of each SCOM server’s local administrators group, and as a SCOM Administrator role. If you are still getting failed to log on
locally, then this account is NOT a local administrator, or your organization has implemented explicity policies for log on locally and it must be added there as well as an advanced user right.

I an a SQl DBA got an alert on daily basis on different servers"Run As Account does not exist on the target system or does not have enough permissionst".So my question is what things i have to check on server to resolve this and how can i resolve this
issue.

Is there any powershell commandlet or SQL Query to pull the list of Rules which are associated / mapped to a specific Run as Profile ?
I have a SQL Query which can give the output for Monitors, But was not able to find one for Runes.

This condition may have occurred because the Account is not configured to be distributed to this computer. To resolve this problem, you need to open the Run As Profile specified below, locate the Account entry as specified by its SSID, and either choose to distribute the Account to this computer if appropriate, or change the setting in the Profile so that the target object does not use the specified Account.

Morning, thank you for all this great info! Our SQL environment is one of those “low privileged” environemnts. I inherited them and have been trying to wrap my head around why there are these additional run as accounts for SQL and how they work!! These accounts (one for each of the three tiers in our environments) are “assigned to ALL of the SQL servers….
A question: would the same procedure/process apply to a run as account/run as profile configuration for Domain Controllers in a similar environment?
Thank you again so very mch!
Tony

I have stared working on SCOM 2012 SP1 and I am geeing maximum alert regarding “RUN AS ACCOUNT” issue. i have run a query on operation Shell “cannot bind parameter’Process’. Cannot convert the “Domain\Account name” value of type “System.String” to type “System.Management.Automation.Scrpitblock”.

I have started working on SCOM SP1. And i am getting maximum error of “RUN AS ACCOUNT”. And i run a script on operation manger shell. And i got something like that. there are many account on which i found this error.

Hi Kevin,
I have upgraded SCOM 2012 R2 to UR12 yesterday in our production environment. I have observed the below alerts in all SQL Agent servers (1000 servers). Password for this account is never expires option selected. I re-entered the password in Run as account but still the problem persists. Can you help me with this.

Description:
The password for RunAs account Domain\SQLAccount for management group MG is expiring on Thursday, January 01, 1970. If the password is not updated by then, the health service will not be able to monitor or perform actions using this RunAs account. There are 0 days left before expiration.