Kevin Holman's System Center Blog

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

Some things to know about the DHCP MP version 6.0.6709.0

Some things to know about the DHCP MP version 6.0.6709.0

  • Comments 16
  • Likes

 

A new DHCP Management Pack recently released, version 6.0.6709.0 on 7/9/2010.  One of my customers asked me to review this MP because of some questions he had about it.  There are some interesting things worthy of pointing out about this MP.

 

You can download it from the MP catalog.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e5b48bef-4b21-4743-b562-580ec7984b24

 

As with ANY MP – first – read the guide fully – to understand the scope of the MP, and how to deploy it correctly.

 

Let’s start with “What's in the MP?”:

 

This MP is a single file.  All library, discovery, and monitoring components were shipped together.  The ID format has also changed from the previous more standardized MP’s.

  • Classes:  1
  • Discoveries:  1
  • Groups:  0
  • Monitors:  43
  • Rules:  110
  • Reports:  0
  • Views: 16

So at first glance – this appears to be a very basic, no-nonsense MP.  It does not have a diverse class hierarchy like previous DHCP MP’s had.  This also means it will likely scale a lot better than previous MP’s.

 

Let’s dig a little deeper:

Classes: 

  • There is only a single class in this MP:  Microsoft.Windows.2008R2.DHCP.Server.Role.  This class is based on Microsoft.Windows.ComputerRole.  What this means is – we are no longer discovering any of the previous classes in the previous 2003/2008 DHCP MP’s.  Such as the Server, Scope, Runtime, Database.  What this means is, we will no longer have a state view of all scopes anymore.  However, the previous MP was discovering large numbers of scope that caused problems in scalability for large enterprises.  Because of this change, you can see our supported number of scopes went from a TOTAL of 500 discovered scopes/superscopes (in the old MP) to 2450 scopes per DHCP server!  This is far more scalable.  I doubt the 2450 number is a hard limit, however.  This number is likely built on the number of scopes tested when the MP was developed. 
  • This single class gives a slightly misleading experience – when you look at state for this class – you will see ALL DHCP servers for ALL versions – even though the class name specifically states it is 2008R2.  So just be aware – this class discovers ALL DHCP servers, not just 2008R2 and the class name would lead you to think:

image

Discoveries: 

  • This class has a single discovery, which is based on a filtered registry discovery provider.  It simply runs every 6 hours – looking for HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Start value, and reads the Integer.  If it is set to 2, or 3, your system gets discovered.  This basically means ANY monitored DHCP server (REGARDLESS OF OS VERSION) will be discovered as an instance of this class, if it has a DHCP Server service in Automatic or Manual startup mode.  Keep this in mind – because this means that this new MP will attempt to monitor ANY version of DHCP – not just 2008 R2 as the naming scheme might lead you to believe.  This is by design.

Groups: 

  • None

Aggregate and Dependency Monitors: 

  • None

Unit Monitors:

  • There are 43 Unit monitors.  All enabled.  All alert generating.  Of these – there are 31 Manual Reset Monitors.  You should be aware of these – because should these monitors ever trigger – they REQUIRE you to go in the console and manually reset them.  If you feel manual reset monitors can be a challenge for your organization, read this for more information:  The Challenges with Manual Reset Monitors 
  • Next, there is a single monitor to monitor the DHCP service status. (DHCP Service Running Monitor)  This monitor description and alert description are a bit off:  “The DHCP service is not servicing any clients because none of the active network interfaces have statically configured IP addresses, or there are no active interfaces.”   This should probably state something closer to “the service isn't running”.  We cannot override alert description.  Lastly – this monitor will not monitor the DHCP service on a cluster by default.  It will need an override to tell it “Alert only if startup type is automatic = false”.  This is common and the default behavior for service unit monitors.  Because of the alert description issue – I would probably lean toward recommending to disable this monitor, and create your own monitor targeting this same class, with a richer alert description.
  • The rest of the monitors are simple 2 or 3 state event log monitors.
  • There is a side effect of this MP, when it discovers older versions of DHCP on Server 2003.  There are two monitors that are trying to open an event log that does not exist on Windows 2003 and older DHCP servers.  This causes the agent to throw “Failed Accessing Windows Event Log” alerts and spams the event log on the agent with 25002 and 25004 errors (see examples in the rules section below).  If you still have Windows 2003 DHCP servers, you should consider setting these to disabled for non-Windows 2008 DHCP servers or we will log these errors and turn the Healthservice for those agents to a warning state.  The monitors that can have this side effect are:
    • DHCP Server configuration change monitoring - Activity Logging
    • Link Layer Based Filtering is not configured correctly

Rules:

  • There are 110 rules
    • All of them target our single class in this MP.
    • All are enabled
    • 78 are simple event collection rules
    • 32 are performance collection rules
  • In general – I personally don’t like to collect too many events.  If an event is actionable – we should generate an alert.  If it isn't actionable, we “could” collect them.  However, this is really only beneficial for reports or diagnostic research in the event of a problem.  This MP has no reports.   The reason I am careful with event collection rules, if there is ever a case where a problem can happen, and these events flood the system log, this can actually overwhelm OpsMgr with too many events.  I recommend you examine each of these events for value to you, and consider disabling these event collection rules if you aren't using them inside OpsMgr.
  • There is a side effect of this MP, when it discovers older versions of DHCP on Server 2003.  There are two rules that are trying to open an event log that does not exist on Windows 2003 and older DHCP servers.  This causes the agent to throw “Failed Accessing Windows Event Log” alerts and spams the event log on the agent with 25002 and 25004 errors (see examples below).  If you still have Windows 2003 DHCP servers, you should consider setting these to disabled for non-Windows 2008 DHCP servers or we will log these errors and turn the Healthservice for those agents to a warning state.   The event logs on your Windows 2003 DHCP servers will start flooding with the following events:

Event Type:    Error
Event Source:    Health Service Modules
Event Category:    None
Event ID:    25002
Date:        8/31/2010
Time:        10:00:06 AM
User:        N/A
Computer:    DC01
Description:
The Windows Event Log Provider was unable to open the Microsoft-Windows-Dhcp-Server/FilterNotifications event log on computer 'dc01.opsmgr.net' for reading. The provider will retry opening the log every 30 seconds.

Most recent error details: The system cannot find the file specified.

One or more workflows were affected by this. 

Workflow name: Microsoft.Windows.2008R2.DHCP.Server.Monitor.LinkLayerFiltering
Instance name: dc01.opsmgr.net
Instance ID: {3FFD04D2-BE7B-2E4E-7F71-13E362DB405D}
Management group: PROD1

Event Type:    Error
Event Source:    Health Service Modules
Event Category:    None
Event ID:    25004
Date:        8/31/2010
Time:        10:12:08 AM
User:        N/A
Computer:    DC01
Description:
The Windows Event Log Provider is still unable to open the Microsoft-Windows-Dhcp-Server/FilterNotifications event log on computer 'dc01.opsmgr.net'. The Provider has been unable to open the Microsoft-Windows-Dhcp-Server/FilterNotifications event log for 720 seconds.

Most recent error details: The system cannot find the file specified.
One or more workflows were affected by this. 

Workflow name: Microsoft.Windows.2008R2.DHCP.Server.Rule.LinkLayerFiltering
Instance name: dc01.opsmgr.net
Instance ID: {3FFD04D2-BE7B-2E4E-7F71-13E362DB405D}
Management group: PROD1

You should disable these rules for all non-2008 DHCP servers, or better yet – just disable these across the board as they are just event collection rules and we likely don’t need/want these in the OpsMgr database anyway.  These rules are: 

    • Rule for event collection - Link Layer based filtering
    • Rule for event collection - DHCP server configuration changes

 

  • There 32 performance collection rules.  The DHCP MP collects every available counter that DHCP Server object offers in perfmon.  Consider disabling all of these and only enabling the ones you actually want and need for reporting.  (There are no built in reports so none of this data is available immediately except in custom reports you would build).  I recommend you talk to your DHCP admins and see what they really need and are interested in reporting on, and disable the rest.
  • There is a side effect of this MP, when it discovers older versions of DHCP on Server 2003.  There are performance collection rules that use a perfmon object that only exists on 2008/2008R2 DHCP servers.  These performance counters do not exist on Windows 2003 DHCP servers.  If you have Windows 2003 DHCP servers, you will see a flood of events on all your non-Windows 2008R2 DHCP servers.  The example of events you will see are:

Event Type:    Warning
Event Source:    Health Service Modules
Event Category:    None
Event ID:    10102
Date:        8/31/2010
Time:        9:59:58 AM
User:        N/A
Computer:    DC01
Description:
In PerfDataSource, could not resolve counter DHCP Server v6, Requests/sec, . Module will not be unloaded.

One or more workflows were affected by this. 

Workflow name: Microsoft.Windows.2008R2.DHCP.Server.Role.PerformanceCollection.V6.RequestsPerSecond
Instance name: dc01.opsmgr.net
Instance ID: {3FFD04D2-BE7B-2E4E-7F71-13E362DB405D}
Management group: PROD1

You should disable these collection rules (for Windows 2003 DHCP servers) and possibly consider disabling them across the board if you don’t need to report on all of them.

    • Rule for performance collection -  DHCP Denied due to match
    • Rule for performance collection -  DHCP Denied Due To Non Match
    • Rule for performance collection -  DHCP Offer Queue Length
    • Rule for performance collection -  DHCPv6 Acks Per Second
    • Rule for performance collection -  DHCPv6 ActiveQueueLength
    • Rule for performance collection -  DHCPv6 AdvertisesPerSecond
    • Rule for performance collection -  DHCPv6 ConfirmsPerSecond
    • Rule for performance collection -  DHCPv6 DeclinesPerSecond
    • Rule for performance collection -  DHCPv6 DuplicatesDroppedSecond
    • Rule for performance collection -  DHCPv6 InformsPerSecond
    • Rule for performance collection -  DHCPv6 MillisecondsPerPacketAvg
    • Rule for performance collection -  DHCPv6 PacketsExpiredPerSecond
    • Rule for performance collection -  DHCPv6 PacketsReceivedPerSecond
    • Rule for performance collection -  DHCPv6 RebindsPerSecond
    • Rule for performance collection -  DHCPv6 ReleasesPerSecond
    • Rule for performance collection -  DHCPv6 RenewsPerSecond
    • Rule for performance collection -  DHCPv6 RequestsPerSecond
    • Rule for performance collection -  DHCPv6 SolicitsPerSecond

 

 

Summary:

 

In summary – the main thing to get from this MP, is that while this MP can work “in addition” to the previous DHCP MP’s…. it is really a “replacement” MP.  It adds some support for 2008R2 DHCP server events and performance objects.  It is MUCH lighter weight and therefore will scale much better for large environments

However – it does have a few issues for old DHCP servers, and will require some additional overrides for Windows 2003 based DHCP servers.

There have been other blog articles on this MP as well, some even recommend unsealing it and enhancing it yourself.  I am not a fan of that direction, because if you re-seal it yourself with your own key, you will break upgrade compatibility with the next version.

Comments
  • Kevin, thanks for an excellent analysis of this MP (as usual).

    Also spot on with the Manual Reset Monitors, I hate these things and as Russ states the Operations Teams living part-time in the OpsMgr console are mostly not aware of it and simply close the alerts without resetting the Health.

    This will probably end in creating our own DHCP MP if asked for, because this one ain't gonna make it into our enviroment.

    One things puzzles me ... how did this ever get past 'Quality Control'?

    Cheers,

    Serge

  • I was shocked after importing this at how badly it's written compared to other Microsoft MPs. Hopefully someone is working on a significantly enhanced version.

  • I dont think it's that bad.... it was written to be a very simple MP which will scale really well.  There are just some quirks if you still have older DHCP servers in the mix.

  • i also  don't like this one. Why doesn't ms create a new one real fast and adds all the things you've just mentioned. it's not rocket science and saves a lot of people unnecessary work.

  • As always, great job Kevin. Thank you for all you do. Talk about mixed feelings. I'm rewriting this one now in Notepad ++ because the MP is a decent base and ++ has a great find/replace. Anything is better than the previous version, which was way too heavy. This one is lean but the formatting leaves much to be desired, especially the view display names. I can't grasp why anyone would do numerous manual reset monitors and so many event/perf collection rules. At MMS it was encouraging to learn the product teams were writing their own MP's, but I'm not so sure after Exchange 2010 and now this. It is not unreasonable to expect MP's from MSFT to be better than this.

  • Kevin,

    we have some scopes which are full by design (intended to be full). How can those be excluded in the new DHCP MP?

    Thanks,

    Natascia

  • There is also a monitor for "Link Layer based filtering" that checks the "Microsoft-Windows-Dhcp-Server/FilterNotifications event log ", so on windows 2003 systems you might want to disable that monitor as well.

  • I have disabled all of the monitors and rules and have completely reset the Warning that shows for the monitor. However, I am still getting the same warning - Failed Accessing Windows Event Log with the following description:

    The Windows Event Log Provider is still unable to open the Microsoft-Windows-Dhcp-Server/Operational event log on computer 'rwsintpot.rwsc.net'. The Provider has been unable to open the Microsoft-Windows-Dhcp-Server/Operational event log for 5760 seconds. Most recent error details: The system cannot find the file specified. One or more workflows were affected by this. Workflow name: Microsoft.Windows.2008R2.DHCP.Server.Monitor.ActivityLogging Instance name: rwsintpot.rwsc.net Instance ID: {DEA4B135-C6F6-5C12-53AD-F758C490F3FA} Management group: RWServivces

    Any thoughts on this?

  • @Robert -

    If you are still getting that error it is one of two things:

    1.  The Microsoft.Windows.2008R2.DHCP.Server.Monitor.ActivityLogging is NOT disabled as you think.

    2.  rwsintpot.rwsc.net has an agent issue, is not getting the new config to download the overrides, and threfore doesnt know its disabled.

  • I have gone back and confirmed that all settings are disabled for group DHCP 2003 Servers. All of the Windows 2003 servers with DHCP enabled in our environment are receiving this message still. How do I push updates to those machines?

  • My Server 2008 NON R2 is giving the same error regarding the DHCP log access as mentioned: "Failed Accessing Windows Event Log".

    Is this because the NON R2 is regarded as old as Server 2003 in this respect? And I should deploy the solution for this problem as mentioned just like it's 2003?

  • @Paul -

    Yes - It is possible these events logs are R2 only, I didnt test with a native 2008 DHCP server (non-R2).  Yes - you would use the same steps - disable them.  If they are trying to open a log that does not exist - there is no monitoring taking place - so you should disable the workflow for those machines.

  • Hi Kevin,

    we have SCOM 2007 SP1 with CU1 update.

    I recently updated my DHCP MP the latest version.

    We have split scope implemented in ur DHCP servers.

    In our earlier MP, whenever the DHCP scope exhausts on one server, it used to throw alert and we created a manual process to our monitoring team to check the other server hosts the same range of scope implemented to server. If any one of the status is healthy in the monitoring-> Scope Health section they ignore the alerts and if both are critical then they used to create Ticket for the AD team to act.

    But in the new DHCP MP Guide i read the following

    •Ability to monitor the scope with delay feature that is used to prevent exhaustion of IP addresses from a scope especially those deployed for redundancy such as split-scope

    So we upgraded the DHCP MP. But still i have the same kind of alerting.

    Even 1 scope exhausted we used to get SOCM alerts and our monitoring team still following the same process.

    Then shall i know what is the meaning of above statement ?

    Kindly clarify..also suggest a solution to avoid the manual process being followed by our monitoring team.

    Our aim is to alert only if both the scopes exhaust then only it need to send an alert.

    Kindly help

  • Its probably also worth mentioning that all the tasks defined in the management pack are broken out of the box. (At least on a 2008 R2 SCOM Server) they all call %COMSPEC% without a /c or /k argument - so you get no output. Even when that is fixed they still don't work since they have an extra space between \\ and the DNSName variable that breaks netsh.exe

    Its kind of surprising this would be released like this - even more surprising that a year later its still like that.

  • It seems that the error: "The Windows Event Log Provider is still unable to open the Microsoft-Windows-Dhcp-Server/FilterNotifications event log on computer "

    can also occour under Windows Server 2008

    I.e. beginning with Windows Server 2008R2 and ongoing the eventlog exists.


    Can you confim that this is true?

    Rgds Roland


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs