none
Invalid Run As account on untrusted domain gateway server - Run As Account could not log on

    Question

  • I've done all the certificate stuff and ran the gateway approval with success, and everything appears OK.  I can even discover and push the agent to the untrusted domain's DCs and member servers under the untrusted domain's action account (Installed the gateway using 'domainB\account').  However my gateway server is still whining about a Run As account from the 'root' management server's domain.  Also ~10m after the untrusted domain's DC receives the agent it'll go from Healthy to Grey every so often, but the Member server stay's yellow.

    How do I configure the untrusted domain's (DomainB) Run As & Action accounts to not care about the RMS/Primary domain's (DomainA) account.

    I'm running SCOM 2012 CU1 on 2008 R2 SP1

    SCOM Alerts

    From the gateway server - run as account could not log on

    Date and Time: 7/27/2012 5:27:59 AM
    Log Name: Operations Manager
    Source: HealthService
    Event Number: 7000
    Level: 1
    Logging Computer: gateway.domainB.com
    User: N/A
     Description:
    The Health Service could not log on the RunAs account domainA\account for management group SCOM_PROD. The error is Logon failure: unknown user name or bad password.(1326L). This will prevent the health service from monitoring or performing actions using this RunAs account 

    Event Data:

    < DataItem type =" System.XmlData " time =" 2012-07-27T05:27:59.0712867-04:00 " sourceHealthServiceId =" 58D8BAA4-50F3-97C0-FEF4-EA14634C975E " >
    < EventData >
      < Data > domainA</ Data >
      < Data > account</ Data >
      < Data > Logon failure: unknown user name or bad password. </ Data >
      < Data > 1326L </ Data >
      < Data > SCOM_PROD </ Data >
      </ EventData >
      </ DataItem >

    from DomainB Domain Controller - System Center Management Health Service Unloaded System Rule(s)

    Date and Time: 7/27/2012 6:26:54 AM
    System Center Management Service ID: 6F5CEFE9-CEDD-3032-9514-6A80F54C87B1
    Host name: domaincontroller.domainB.com

    --------------------------------------------------------------------------------
     
    System Center Management Service is not available although the following server is reachable: gateway.domainB.com

    --------------------------------------------------------------------------------
     
    Reasons:
    43 System Center Management Service failed to load some system rules.

    from Domain B Member server - Run As Account Could Not Log On

    Date and Time: 7/27/2012 6:18:01 AM
    Log Name: Operations Manager
    Source: HealthService
    Event Number: 7000
    Level: 1
    Logging Computer: domainBmember
    User: N/A
     Description:
    The Health Service could not log on the RunAs account domainA\account for management group SCOM_PROD. The error is Logon failure: unknown user name or bad password.(1326L). This will prevent the health service from monitoring or performing actions using this RunAs account 

    Event Data:


    B. Wright

    Friday, July 27, 2012 10:33 AM

Answers

  • This is a known issue with this monitor. If the accounts are setup correctly and monitoring is working, you can disable this monitor against that instance.

    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    • Marked as answer by B. Wright Tuesday, November 06, 2012 1:41 PM
    Tuesday, November 06, 2012 4:52 AM
    Moderator

All replies

  • Hi,

    Check this account's Distribution tab. shouldn't be a 'less secure' (it will try to distribute to all servers).


    http://OpsMgr.ru/

    Monday, July 30, 2012 3:35 AM
    Moderator
  • I thought that may be the issue.  This account is set to be a "less secure", but it is the first account I installed with the management group, and I can't figure out how to change it to be a 'more secure'. 


    B. Wright

    Monday, July 30, 2012 7:50 AM
  • Are you talking about a management server action account? You need to change this at the Profiles\Default Action Account profile.

    http://OpsMgr.ru/


    Monday, July 30, 2012 9:46 AM
    Moderator
  • I have 3 action accounts:

    DomainB\account - added manually - description " - more secure (greyed, cannot be changed)

    Local System - added during RMS in Domain A install - description "Bultin system account to be used as an action account" - more secure (greyed, cannot be changed)

    DomainA\account - added during RMS in Domain A install - description "This is the user... default on the agent" - more secure (greyed, cannot be changed)

    In my default action account profile properties the “Run As accounts” assigned to my agent managed servers are mostly “local system”, except for DomainA\account assigned to the management & gateway servers in Domain A, and DomainB\account assigned to the gateway of Domain B.  This I can change, but only individually.

    When I installed the gateway servers I chose the respective gateway’s account. 

    Am I understanding correctly, that if I reassign all servers (my RMS and gateways) to the ‘localsystem’, I could then delete domanA\account from the action accounts and solve this issue?


    B. Wright

    Monday, July 30, 2012 11:40 AM
  • More info:

    All of my gateway/management servers are using their respective domain's action account.  Upon discovery using "Use selected Management Server Action Account" for the Administrator Account (used when installing the agents on managed computers), and then using "Local System" (use when performing actions).  The agent installs fine on any DomainB member server, and for a short time it displays "Healthy" for a short time until DomanA's runas account tries to hit it (HealthService eventID 7000), and then the server is in warning status.  Do I need to do something funky with either one or a combonation of the run as profiles below (or make a new profile), in order to make DomainA's run as account NOT TRY to access DOMAINB's managed servers?

    Default Action Account - gateway/management servers have their respecive domain account's associated, and any member server is 'local system action'

    Active Directory Base Agent Assignment - No run as accounts currently associated

    Automatic Agent Management Account - No run as accounts currently associated

     


    BW

    Monday, July 30, 2012 5:03 PM
  • I have this as more secure, and only assigned to servers in Domain A.  I've worked around this by disabling the monitor on anything in a group of 'domainbmembers', but it seems hokey.  Any other ideas?

    B. Wright

    Tuesday, August 14, 2012 6:54 PM
  • Bump.

    B. Wright

    Tuesday, August 28, 2012 3:30 PM
  • When you built the gateway server, what domain and account did you specify in the Action Account dialog box? You might want to double check that, as that's the only place & time it gets specified.

    "Fear disturbs your concentration"

    Wednesday, August 29, 2012 5:31 PM
  • I had this problem this morning. There was a simple fix.

    • Delete the problem Run As Account
    • Stop System Center Management (HealthService) on all Management Servers
    • Delete all files from the \Program Files\System Center 2012\Operations Manager\Server\Health Service State folder on the Management Servers
    • Delete all files from the \Program Files\System Center Operations Manager\Gateway\Health Service State folder on the Management Servers
    • Do not start the services
    • Bounce the Management Server that the Gateway is configured to use. I did this as I wanted the SDK and CFG services to flush any cache. 
    • When it is back up, bounce the Gateway SErver and when it comes back up, go into the Event Viewer to check it is talking to the Management Server

    It worked for me. 

    Thankes to Rob for the following:

    http://blogs.technet.com/b/momteam/archive/2011/08/22/topology-changes-in-system-center-2012-operations-manager-overview.aspx

    I bounced the MS because of the System Center Configuration Service. In SCOM 2012, they needed to rewrite the Configuration Service almost completely. In SCOM 2007 versions, the RMS always required a huge amount of memory to properly function. One of the main reasons for this was when the Configuration Service starts; it reads the Operational Database and loads its view of the instance space into memory in XML. In larger Management Groups, this file can easily grow to over 6 GB. The Configuration Service uses this file to compare against the Operational Database to detect changes and issue new configuration to Health Services. In SCOM 2012, every Management Server has a running active Configuration Service, so it is not reasonable to store this in memory any longer. The Configuration Service will store this data in a centralised database (Operational DB) that all Configuration Services in the Management Group participate in keeping up to date and utilising it to detect configurations changes to the instance space. A fantastic benefit that came out of this design is a much faster start-up of Configuration Service. Once the database is initially created, on subsequent starts the Configuration Service does not need to rebuild this database from scratch and instead just maintains it. Therefore, it starts issuing configuration much sooner after restart. This is a major improvement over SCOM 2007 versions where in a large management group it could take up to an hour to start issuing configuration to agents.

    Health Service (Resource Pools)

    To distribute the RMS specific workloads to all management servers, SCOM 2012 needed to develop a mechanism for each Health Service on the management server to function independently, while still having awareness of the workloads the other management servers are performing. This helps to ensure SCOM 2012 does not get workflow duplication or missed workflows. To achieve this Microsoft added a new feature to SCOM 2012 called Resource Pool. Resource Pools are a collection of Health Services working together to manage instances assigned to the pool. Workflows targeted to the instances are loaded by the Health Service in the Resource Pool that ends up managing that instance. If one of the Health Services in the Resource pool were to fail, the other Health Services in the pool will pick up the work that the failed member was running. SCOM 2012 also uses Resource Pools to bring high availability to other product features like Networking and Unix monitoring. 

    Whether I needed to or not, I did not have time to test. Removing the information from the Health State Folder on all the MS and GW servers and the starting the services worked for me. This  way, the GW downloaded a fresh copy and the Run As Account was not referenced.

    • Proposed as answer by Mark Stone Wednesday, October 24, 2012 3:57 PM
    Wednesday, October 24, 2012 3:46 PM
  • This is a known issue with this monitor. If the accounts are setup correctly and monitoring is working, you can disable this monitor against that instance.

    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

    • Marked as answer by B. Wright Tuesday, November 06, 2012 1:41 PM
    Tuesday, November 06, 2012 4:52 AM
    Moderator
  • Jonathan's approach is exactly what I deemed as the most appropiate solution.

    B. Wright

    Tuesday, November 06, 2012 1:41 PM
  • Above Warning is known issue of Kerberos Authentication, so we have to safely ignore it with mentioned Procedure

    http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/f7bb008b-91b0-4184-a349-c12bf28d8093


    Kirpal Singh


    Thursday, March 14, 2013 6:04 AM