locked
SCOM 2012 R2 EMS event 26004: unable to open the DhcpAdminEvents event log on computer in other domain RRS feed

  • Question

  • Our environment runs SCOM 2012 R2 with 3 management servers and a couple of gateways for domains without a trust.

    One of our managment servers in our domain logs event 26004 every 12 minutes about one of the DHCP servers in one of the untrusted domains. The exact message:

    -------------------------------------------------------------------------------------------

    The Windows Event Log Provider is still unable to open the DhcpAdminEvents event log on computer 'server1.externaldomain.com'. The Provider has been unable to open the DhcpAdminEvents event log for 583920 seconds.

    Most recent error details: The RPC server is unavailable.

    One or more workflows were affected by this.

    {workflow information}

    -------------------------------------------------------------------------------------------

    There's 3 of these right after eachother, each with a different affected workflow.

    Server1 is being monitored just fine via the gateway of 'externaldomain.com', but somehow the management server in our own domain tries to read the eventlog of server1. I'd suspect that this should be done by the gateway instead of the management server.

    I already tried to reboot the management server and reïnstalling the client on server1 as well, with no improvement.

    What am I missing here?
    Wednesday, September 16, 2015 8:27 AM

Answers

  • The base of the class "Microsoft Windows DHCP Server 2012 Failover Relationship" is System.Perspective and according to this http://social.technet.microsoft.com/wiki/contents/articles/1209.choose-base-classes-for-your-management-pack.aspx this base class has a side effect: Always hosted on the Root Management Server. With SCOM 2012 you don't have a RMS anymore, but there is still an emulator role. So in this case the management server holding the RMSe role will try to open the Eventlog on that server as mentioned in the Local Server property.

    There are some options:
    Make sure there is direct access from the RMSe role to that server (not an option for you).
    Disable the monitors.
    Log a case with Microsoft to raise this as a bug.

    This means there is not really a good solution for you here.

    Thursday, October 1, 2015 2:08 PM

All replies

  • Have you configured some agent-less monitoring as usually the Management Server will not try to read anything on an agent. Using the workflow information you should be able to identify the monitor or rule.

    I only know of some workflows like for Exchange 2010 where the workflow runs on the management server instead of on the agent, but this is because of the Exchange Correlation engine, but even in those cases the workflows will not check directly from the management server on the agent.

    Monday, September 28, 2015 11:41 AM
  • The workflows that are affected (for as far as the events go) are: 

    • Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher.UnitMonitor.LostCommunicationWithfailoverPartnerServer
    • Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher.UnitMonitor.ErrorCommunicationWithfailoverPartnerServer
    • Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher.UnitMonitor.OutOfTimeSync

    I traced it back to the monitors:

    • DHCP Server 2012 Failover Server Relationship Lost Communication With Partner Server
    • DHCP Server 2012 Failover Server Relationship Error Communication With Partner Server
    • DHCP Server 2012 Failover Server Relationship Out of Sync

    All three of these are set to target the class "Microsoft Windows DHCP Server 2012 Failover Relationship" and can be found in the "Microsoft Windows Server DHCP 2012" MP. The only object I can find in there is the relationship of said DHCP server the initial error is about. And that relationship-object is completely fine: the affected monitors dont show any errors, not even a single state change.

    I didn't add any agent-less monitoring to the servers. At least, not knowingly :P


    Thursday, October 1, 2015 1:00 PM
  • We don't use the DHCP server management pack since they stopped monitoring individual scopes (since 2008).
    But I had a look in the management pack and I started with the first monitor on your list "Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher.UnitMonitor.ErrorCommunicationWithfailoverPartnerServer"

    One thing immediately had my attention and that is this part in the XML:

    <Configuration>
            <FirstComputerName>$Target/Property[Type="Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher"]/LocalServer$</FirstComputerName>
            <FirstLogName>DhcpAdminEvents</FirstLogName>
            <FirstExpression>
                <And>
                    <Expression>
    

    As you can see it using "$Target/Property[Type="Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher"]/LocalServer$" as the target to do the check in the eventlog. Usually you would use this "$Target/Host/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName" as this would point to the local machine.

    I'm really curious what kind of data you see if create a stateview to class "Microsoft Windows DHCP Server 2012 Failover Relationship" and what the information is in property LocalServer.

    Thursday, October 1, 2015 1:16 PM
  • I did as you suggested, made a state view of that class. Here's the information:

    • Display Name: server1-server2
    • Path:
    • Object Display Name: server1-server2
    • Name: server1-server2
    • Local Server: server2.externaldomain.com
    • Partner Server: server1.externaldomain.com
    • Scope Id: System.Object[]
    • Mode: LoadBalance
    • Load Balance Percent: 50
    • Server Role:
    • Reserve Percent:
    • Max Client Lead Time: 01:00:00
    • State Switch Interval:
    • Auto State Transition: False
    • Enable Authorization: True
    • OS Current Version: 6.2

    Not seeing any weird stuff here... right?

    Thursday, October 1, 2015 1:46 PM
  • The base of the class "Microsoft Windows DHCP Server 2012 Failover Relationship" is System.Perspective and according to this http://social.technet.microsoft.com/wiki/contents/articles/1209.choose-base-classes-for-your-management-pack.aspx this base class has a side effect: Always hosted on the Root Management Server. With SCOM 2012 you don't have a RMS anymore, but there is still an emulator role. So in this case the management server holding the RMSe role will try to open the Eventlog on that server as mentioned in the Local Server property.

    There are some options:
    Make sure there is direct access from the RMSe role to that server (not an option for you).
    Disable the monitors.
    Log a case with Microsoft to raise this as a bug.

    This means there is not really a good solution for you here.

    Thursday, October 1, 2015 2:08 PM
  • Thanks for the help, much appreciated!

    I've reported the bug and disabled the monitor for now.

    Friday, October 2, 2015 9:00 AM
  • Hi Erwin,

    Were you able to get any response from MS?

    I have same problem with workflow: "Microsoft.Windows.DHCPServer.2012.FailoverServerWatcher.UnitMonitor.OutOfTimeSync" effected. I found this with servers from other domain as well as from same domain.  Finally I had to put an override for the Management server health service on this monitor.


    bishvesh sharma



    • Edited by BishS Tuesday, December 8, 2015 10:20 AM
    Tuesday, December 8, 2015 10:19 AM
  • I can confirm that disabling the above monitors works in SCOM2012 and  SCOM1801 (Disabled monitors for 2012 and 2012R2):

       • DHCP Server 2012 Failover Server Relationship Lost Communication With Partner Server

       • DHCP Server 2012 Failover Server Relationship Error Communication With Partner Server

       • DHCP Server 2012 Failover Server Relationship Out of Sync

    This monitor was also disabled but not sure if above would be sufficient:

    • DHCP Server 2012 Failover Server Relationship Health

    These were disabled "For all objects of class: Microsoft Windows DHCP Server 2012 Failover Relationship" for our use case.

    • Edited by JoelWG Friday, August 10, 2018 4:58 PM
    • Proposed as answer by JoelWG Friday, August 10, 2018 4:58 PM
    Friday, August 10, 2018 4:52 PM