Operations Manager 2012 R2 Agent on Domain Controllers cannot report to Management Server

One of my customers is working on a project to monitor all Active Directory domain controllers using System Center 2012 R2 Operations Manager. He uses push installation to deploy Operations Manager 2012 R2 agent to all domain controllers. The agent installation is completed successfully, but the agent stays in "Installation in Progress" under Pending Management. I am able to reproduce the problem in my testing environment. Here is what it looks like.

 

Event ID 20071 and 21016 are logged on the domain controller, complaining that it cannot communicate to the management server.

 

Log Name: Operations Manager

Source: OpsMgr Connector

Date: 5/2/2015 2:33:14 PM

Event ID: 20071

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: SG1DC02.contoso.azure

Description:

The OpsMgr Connector connected to OM12R2DEV02.contoso.azure, but the connection was closed immediately without authentication taking place. The most likely cause of this error is a failure to authenticate either this agent or the server . Check the event log on the server and on the agent for events which indicate a failure to authenticate.

 

Log Name: Operations Manager

Source: OpsMgr Connector

Date: 5/2/2015 2:33:19 PM

Event ID: 21016

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: SG1DC02.contoso.azure

Description:

OpsMgr was unable to set up a communications channel to OM12R2DEV02.contoso.azure and there are no failover hosts. Communication will resume when OM12R2DEV02.contoso.azure is available and communication from this computer is allowed.

 

 

Since the management server is actually in the same domain as the domain controller, it doesn't make sense that Kerberos authentication could fail. Checking the Security Event Log on the management server reveals the problem: the domain controller "has not been granted the requested logon type at this machine."

 

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 5/2/2015 2:33:19 PM

Event ID: 4625

Task Category: Logon

Level: Information

Keywords: Audit Failure

User: N/A

Computer: OM12R2DEV02.contoso.azure

Description:

An account failed to log on.

 

Subject:

    Security ID:        NULL SID

    Account Name:        -

    Account Domain:        -

    Logon ID:        0x0

 

Logon Type:            3

 

Account For Which Logon Failed:

    Security ID:        NULL SID

    Account Name:        SG1DC02$

    Account Domain:        CONTOSO.AZURE

 

Failure Information:

    Failure Reason:        The user has not been granted the requested logon type at this machine.

    Status:            0xC000015B

    Sub Status:        0x0

 

Process Information:

    Caller Process ID:    0x0

    Caller Process Name:    -

 

Network Information:

    Workstation Name:    -

    Source Network Address:    -

    Source Port:        -

 

Detailed Authentication Information:

    Logon Process:        Kerberos

    Authentication Package:    Kerberos

    Transited Services:    -

    Package Name (NTLM only):    -

    Key Length:        0

 

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

 

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

 

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

 

 

It turns out that the customer has a domain group policy similar as below, which only grants Administrators and Domain Computers group with the user right "Access this computer from the network". Unfortunately, Domain Controllers are not members of Domain Computers group. And it causes the problem you see above.

 

 

The solution is simple: Add Domain Controllers group into local administrators group on each Management Servers. The customer will also discuss with his security team if the domain group policy should be modified to include Domain Controllers group in "Access this computer from network".

 

By the way, here is the default setting of "Access this computer from the network" policy.

Comments

• Anonymous
  June 14, 2015
  Adding Domain Controllers group into local administrators group helps.