text: Update 11/29/2012: This article is current as of the 6.3.173.1 version of the SQL MP.
  Using RunAs accounts and profiles is an often poorly understood area of OpsMgr. As I began to investigate setting this up for the SQL MP, I quickly realized how little I understood it. Chatting with my PFE peers, I found that while everyone felt they had a “big picture” idea of how to configure it, nobody I talked to really understood all the options and impact.
  This post will be a primer on the basics of using RunAs accounts and profiles, and an in depth example of applying them to the SQL Management pack under different typical scenarios..
  In SOME cases, the application being monitored does not allow Local System (or a local admin/domain user account) to have any, or enough rights to the application. When this happens, we need to use a RunAs account and profile..
  Following are the most common scenarios I run into, in the field:
  Scenario #1. You use Local System as the default agent action account.
  You accept the default SQL permissions, or modify them to ensure that Local System has the “SA” role to the SQL instance. 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. This is not the most secure scenario, but likely the simplest to manage..
  Scenario #3. You use Local System as the default action account.
  However, the SQL team has restricted the NT AUTHORITY\SYSTEM (Local System) SQL login, and removed the “SA” right. In this case, the Local System account has full rights to monitor the server OS, however, does not have enough rights to discover and monitor the SQL application. In this case – we would use a Run-As account(s) to manage access for the SQL workflows only, to execute under this Run-As account. This account(s) can be created and fully managed by the SQL team. This is the MOST common scenario.
  Scenario #4. You use a Domain User account as the default action account.
  This account is a member of the Local Administrators group on the OS. It is used by the OpsMgr team as their agent account. However, the SQL team has restricted or deleted the BUILTIN\Administrators SQL login, thereby removing the “SA” right from local admins. The SQL team will not allow this account, which they do not control, to have any access to SQL. In this case, the default agent action domain user account has full rights to monitor the server OS, however, does not have enough rights to discover and monitor the SQL application. In this scenario – we would use a Run-As account(s) to manage access for the SQL workflows only, to execute under this Run-As account. This account(s) can be created and fully managed by the SQL team.
  So – in summary – the most common scenarios are:
  - Use a default agent action account that has Local Admin rights to the OS and SA rights to SQL
  - Use a default agent action account that has no rights to SQL and therefore configure RunAs accounts and profiles to gain access to SQL.”
  4. Type in the credentials for username, password, and domain..
  I really don’t like the terminology we chose of “Less Secure”. I think they were trying to stress that using “more secure” is a better way to ensure that the tightest security model is upheld. Theoretically, someone could take an agent management machine they had access to, and hack the credential presented until they got the password. This model has completely changed from SP1, where were distributed the credential anywhere that needed it, automatically. This presented a risk, because a server admin who didn’t get access to the credential, could theoretically “fake” that he had an application which needed the credential by placing a dummy registry entry, having this class discovered, get the credential distributed, and start trying to hack the credential. "The new “more secure” absolutely controls the distribution of the Run As credential, and only OpsMgr admins have access to this.
  Less Secure really isn't a valid option. The reason for this, is that the agent, as soon as it receives a RunAs credential, performs a series of tests to make sure that we can use the Run As credential. This includes testing for the “Log On Locally”. If you create a Run As account, and choose “Less Secure” you will immediately get a flood of alerts from all your Domain Controllers, Exchange servers, and any other servers that restrict the Log on Locally right. In enterprise server environments, this is very typical to remove “Domain Users” or the local “Users” group from this user right via group policy – or to deny “Log on Locally” for service accounts. This essentially makes “Less Secure” unusable for any practical purpose.
  Therefore we WILL be using “More Secure”.
  Now that we have that settled, this means we need to choose the Health Services to distribute the Run As credential to. Go ahead and finish creating the Run As Account using more secure, then open the properties of the newly created account. There is a distribution tab:” in almost all my SQL server names, so this is easy enough for me – I type in “sql” and his – if a new MonitoringHost.exe process will spin up,”. This warrants yet another deep dive discussion.
  Normally – the MP Author should let you pick “All targeted objects” and you can be on your way. have to choose “All targeted objects” or “A selected class, group, or object”.
  Since ALL workflows that leverage the SQL Server Monitoring Account profile are targeting a class that is a SQL specific discovered class, we can use “All Targeted Objects”.
  4. Done!
  Last – let’s examine the SQL Server Default Action Account profile., or DBEngine objects. The Windows Computer object Hosts/Contains all other application classes, that is why you can use this one for your groups. Alternatively – you can use Database Engine objects if you prefer…. as the DBEngine Hosts/Contains almost all the SQL classes in the MP that leverage a Run As profile.
  -.
  Here is how it will look when complete:.
  Conclusion
  I hope this helps provide more answers than it does questions. This is just one example of how to use the Run As in OpsMgr 2007 and 2012. Other strategies could be formed. Keep in mind – usually the simplest solution is best, so don’t over-complicate things. Make a strategy that is the easiest to maintain, while providing good security separation.
  Additionally – this example above is not the “most secure” configuration…. because we assumed our Run As account would have SA rights to SQL. That is not technically required. The SQL MP guide does a good job of documenting the minimum instance and database rights needed to grant a Run As account so it can fully monitor SQL. That said – the Run As account and profile configuration (the focus of this article) will not be any different if you further restrict SQL rights – Run As will work exactly the same way.
  ***Thanks to many conversations with Jimmy Harper, Jesse Harris, Russ Slaten, Tim McFadden, and Bonnie Feinberg for assisting me with the data provided.
  SQL MP Run As 6.1.314.36.xlsx
  I have learned a lot from you!
  Thanks!
  Hi Kevin,
  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?
  Thanks is advance.
  Murad
  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?
  @Vivak –
  Since your SQL server is ON the RMS…. this wont use Local System. This will use the Management Server Action Account as the default action account for all monitoring workflows.
  Therefore – your MSAA needs the rights to SQL…. OR you need to set up the Run-As account and profile to be used by the SQL MP for the RMS.
  Hi Kevin, I have just started with SCOM . Could you please suggest me some links/docs that starts with scratch for beginners. Thanks
  Thx Kevin for the detailed explanation.
  Kevin, I am using the 2nd option for my SQL MP
  "
  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?
  Thanks, Murad
  Cannot be resolved generally means you did not distribute the run-as account to that particular health service.
  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.
  @Murad
  Discovery is pretty basic…. you dont need a lot of rights to discover the items.
  Are you discovering some, or none of the virtuals?
  Do the virtual instances show up in the Windows Computer and Windows Server class by name?
  Have you enabled Agent proxy for all cluster nodes, and have an agent on all nodes in the cluster?
  Bounce the agent health service. Wait 5 minutes. Are there any discovery errors or 10801 or 33333 events on the agent OpsMgr event log, or the Management server it is assigned to?
  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.
  @Udit –
  What monitor or rule specifically do you feel is not working? There is no monitor for a decommissioned DB.
  Hi Graham –
  I didnt. I started to… got some SDK code in C#, but what I really want is for this to be included in the product, or it to be portable to PS script.
  Kevin – Thanks for getting back so quickly: Yes I am receiving hundereds of 88888 & 10801 alerts on my Management Server
  Log Name: Operations Manager
  Source: DataAccessLayer
  Date: 9/29/2010 2:38:14 PM
  Event ID: 33333
  Task Category: None
  Level: Warning
  Keywords: Classic
  User: N/A
  Computer: management server.domain.com
  Description:
  Data Access Layer rejected retry on SqlError:
  Request: p_RelationshipDiscovered — (RelationshipId=624cbcb3-fe58-8090-b174-cb788533791f), (SourceEntityId=42a835c6-81f3-4473-7365-2dee46ac999c), (TargetEntityId=63e73ddc-5438-63a1-c50d-89d08e436b28), (RelationshipTypeId=0c18d101-8d27-4333-6d54-682fe19a5896), (DiscoverySourceId=e898cacb-3382-bf39-40b0-e7eb930cff14), (HealthServiceEntityId=3dc442a6-0a0d-c47b-d812-4cb242531eb0), (PerformHealthServiceCheck=True),
  ———————————-
  Log Name: Operations Manager
  Source: Health Service Modules
  Date: 9/29/2010 2:38:14 PM
  Event ID: 10801
  Task Category: None
  Level: Error
  Keywords: Classic
  User: N/A
  Computer: cho3wse9sco03.corp.transunion.com following details should help to further diagnose:
  DiscoveryId: a344fd27-6d81-6a3b-7b9f-e9e55778465e
  HealthServiceId: 3dc442a6-0a0d-c47b-d812-4cb242531eb0
  Invalid relationship source specified in the discovery data item.
  RelationshipSourceBaseManagedEntityId: 42a835c6-81f3-4473-7365-2dee46ac999c
  RuleId: a344fd27-6d81-6a3b-7b9f-e9e55778465e
  Instance:
  <?xml version="1.0" encoding="utf-16"?><RelationshipInstance TypeId="{0c18d101-8d27-4333-6d54-682fe19a5896}" SourceTypeId="{387eadfe-1fde-623d-015a-cd39a8b40d55}" TargetTypeId="{02c5162c-b89f-1d61-349a-9b0667fbd60e}"><Settings /><SourceRole><Settings><Setting><Name>f0721862-8f99-78b7-6ede-936326423438</Name><Value>custdev.transunion.com</Value></Setting></Settings></SourceRole><TargetRole><Settings><Setting><Name>f0721862-8f99-78b7-6ede-936326423438</Name><Value>custdev.transunion.com</Value></Setting><Setting><Name>7a7a1247-5661-8a5f-4262-dc42bbdcf5b9</Name><Value>CUSTDEVCHU2WSE1CDC03</Value></Setting></Settings></TargetRole></RelationshipInstance>.
  Event Xml:
  —>No MPs were recently deleted
  —> Database server has plenty of space
  —>Network connectivity problems – Not that I am away of.
  —>Discovery data received is not valid = Whats does that mean?
  What would you recommend the next steps should be?
  Thanks
  Murad
  @John –
  I am actually working on that this week – there are three blog posts floating around out there with examples, I am going to try and build out a comprehensive post which covers all of them.
  "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.
  But i guess that's a bit off topic to the blogpost 🙂
  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.
  I am trying to figure out how to modify a runas accounts distribution list using the SDK.
  Do you have any idea which class, property or methods to use ?
  The class MonitoringSecureData represents the runas account, but I can't find anything about distribution list or less/more secure.
  Thanks,
  Jan
  Very helpfull! thanks…
  Dear Kevin,
  Fantastic explaination
  Here is my issue:
  I have implemented Scenario #1. You use Local System as the default agent action account.
  SQL 2008 SCOM 2007 R2 , The OPSMGR DB is on the RMS itself
  I was getting alert based on follwoing rule :
  Run As Account does not exist on the target system or does not have enough permissions
  After checked i saw Local System ahs SA rights on DB instanctance
  Still i got the same alert for all the DB's
  I checked the Action Accounts Listed in Console and saw 2 action accounts ,
  1. Local System Action Account
  2. Managemnet Server action account that was created during setup
  As checked the Management server action account doesnt have SA privilages , it just has Public rights on the DB
  I gave it SA rights and the event which caused the alert stopped.
  Any reason why that must have to be done ?
  Hi Kevin
  Did you ever get a chance to look at this in more depth?
  "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. "
  Cheers
  Graham
  I went through your directions.. Now I just got dozens of alerts saying "An account specified in the Run As profile "Microsoft.SQLServer.SQLDefaultAccount" cannot be resolved."
  What is causing that?
  And how do I distribute it?
  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.
  Regards,
  Chris
  Hi Murad.. I Have the same scenario.. Did you find out anything more regarding this. In advance thank you. Regard Nicklas
  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?
  Kevin,
  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.
  support.microsoft.com/…/2590230
  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.
  Any thoughts?
  Thanks,
  Keith
  Great and very interesting blog. I think it’s also an informative. Thanks for sharing.
  Please, also remember that, as stated by the MP documentation, the use of run as profiles – Low Privilege Environment – is not supported in clustered environment.
  By the way : why isn't it supported ?
  Kevin,
  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, Do you have any update about a way to do a dynamic run as account distribution. Thanks so much in advance
  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?
  Pingback from SCOM QUICK Install | config.re!
  Very good explanation!!!! I’m already making use of scenarios in my LAB.
  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.
  Hi Kevin,
  It means that SCOM MP only discover and monitor SQL Servers and MP doesn’t change and modyfying any settings data in SQL?
  Thank you!
  I wrote a post explaining Run As accounts a while back here:
  Kevin,
  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?
  Again Thank you
  David D.
  @David –
  1. I don’t think this has anything to do with whether proxy is enabled or not. I turn proxy on as a default setting so all new agents inherit proxy enabled, for EVERYONE. Dealing with that setting is pointless IMHO.
  2. Whenever a profile associates an account to a class hosted by an agent – you will see these "cannot be resolve" errors, which simply means the RunAs account has not been distributed yet. Distributing the account will resolve those. For automation – see:
  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.
  Any idea?
  @Srini –
  Cannot be resolved will be expected on machines that either are not distributed, or are not in a trusted domain.
  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.
  Any other reason?
  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.
  @ Avijit –
  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.
  Excellent explanation. I did not understand that RunAs Profiles in essence are optional, as long as the Default Action Account for that particular server/service has the necessary permissions.
  that’s a bingo
  Hi Kevin,
  Hope you are doing good.
  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.
  select distinct
  managementpackview.Name as ‘Management Pack Name’,
  monitorname as ‘Monitor Name’,
  SecureReferenceView.displayname as ‘RunasProfile Name’
  from dbo.Monitor
  inner join SecureReferenceView on monitor.runas = SecureReferenceView.id
  inner join managementpackview on managementpackview.id = SecureReferenceView.ManagementPackId
  where SecureReferenceView.displayname like ‘%YOUR RUNAS PROFILE NAME%’
  Most of this information is provided in the Management pack Guide, But incase if we do not have a guide or lost it then it will be useful so asked,
  Are groups consisting of windows computer objects sufficient when associating the always on discovery and monitoring profiles?
  Should I be including availability groups?
  Yes – they are – because Windows Computer objects contain all the other hosted instances on the agents.
  Hi Kevin ,
  I have SCOM 2012 R2 UR9 running in my environment.
  SQL 2008,2012,2014,2016 are running
  Have created the Accounts and Distributed it to the SQL Servers.(Accounts have admin level access to Servers and Sysadmin level access to SQL)
  Have Associated the Accounts with the below Classes and groups in the profiles
  Class::
  SQL Server 2*** Agent
  SQL Server 2*** Agent Job
  SQL Server 2*** DB
  SQL Server 2*** DB Engine
  Group::
  SQL Server 2*** DB Engine Group
  In many Servers i get this below error for profiles
  ”
  Microsoft.SQLServer.SQLDiscoveryAccount
  Microsoft.SQLServer.SQLProbeAccount ”
  Log Name: Operations Manager
  Source: HealthService
  Date: 12/19/2016 12:03:37 AM
  Event ID: 1108
  Task Category: None
  Level: Error
  Keywords: Classic
  User: N/A
  Computer:
  Description:
  An Account specified in the Run As Profile “Microsoft.SQLServer.SQLProbeAccount” cannot be resolved. Specifically, the account is used in the Secure Reference Override “SecureOverride7abf93bb_3f52_39b9_1229_9233b8a1b14c”..
  Management Group:
  Run As Profile: Microsoft.SQLServer.SQLProbeAccount
  SecureReferenceOverride name: SecureOverride7abf93bb_3f52_39b9_1229_9233b8a1b14c
  SecureReferenceOverride ID: {F7391A0D-BBDB-AFAC-5FDD-665FA0228630}
  Object name: MsDtsServer110
  Object ID: {B8568913-7DD5-79D0-8660-EA20A2623BF9}
  Account SSID: 00F665CC36675DFA25A72DA4777F6273E2AED2E2B400000000000000000000000000000000000000
  What could be the reason.?
  how to fix the same?
  @Dinesh kumar
  Account not resolved simply means it is not distributed.
  Why not skip all this and use Service SID’s?
  Hi Kevin ,
  Saw your Run as Account Addendum Management Pack.
  Champion Idea.
  There are more than 800 DB servers running with Profile/Run as Account/distribution setup in my environment.
  How can i implement SSID method , Without any impact to SQL monitoring
  Any thoughts?
  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
  Hi Kevin,
  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”.
  So please let me know what should i need to do in this scenario.
  Hi kevin,
  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.
  “cannot bind parameter’Process’. Cannot convert the “Domain\Account name” value of type “System.String” to type “System.Management.Automation.Scrpitblock”.
  Please let me know what should i need to do in this scenario.
  Thanks,
  Gourav
  Hi Kevin, I working on an MP form Netapp.
  I got 4 groups with run as account used in the discovery DS.
  This is an sample from the Mp
  Discovery
  $MPElement$
  $MPElement[Name=”DataONTAP.Cluster.AdminVserversGroup”]$
  $MPElement[Name=”DataONTAP.Cluster.AdminVserver”]$
  $MPElement[Name=”SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities”]$
  The group was not populate.
  If i build a custom group with same without the runas It’s working.
  I am not sure to understang why they used a runas in a group discovery.
  I try to distribute the runas on my RMS it’s working.
  Can you Explain pls
  Sorry Bad Copy paste.
  Discovery
  $MPElement$
  $MPElement[Name=”DataONTAP.Cluster.AdminVserversGroup”]$
  $MPElement[Name=”DataONTAP.Cluster.AdminVserver”]$
  $MPElement[Name=”SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities”]$
  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.
  Thanks,
  Ramu Chittiprolu