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:
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:
Aggregate and Dependency Monitors:
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.