Tag Archives: MimboloveDaylight Saving

SCOM Management Pack: Daylight Saving Time Change Detection

Written by Tao Yang

I wrote this management pack to detect system time changes that are caused by daylight saving. It’s called “Custom Daylight Saving Detection”.

Background:

When supporting a infrastructure that has servers across the globe, it is hard to keep track of daylight saving schedules for all time zones. There is a requirement that we need to be notified when the Windows servers have entered/exited daylight saving time.

Functionalities:

This management pack generates alerts when:

  1. the agent computer has entered / exited Daylight Saving time.
  2. the agent computer is entering / exiting Daylight Saving time within a configurable number of days (default is 10 days).

Inside the Custom Daylight Saving Detection Management Pack:

This MP consists of 4 rules:

image

 

Rule #1. Compare Current and Previous DaylightInEffect WMI Setting

Rule Type: Timed Script

Schedule: Runs every hour on 1 minute after full hour on Saturdays and Sundays

Description:

The script inside this rule retrieve DaylightInEffect value from Win32_ComputerSystem and compare it with the value previously saved in <OpsMgr Agent Install Dir>\CustomDST_MP.Control file. If the current value and the previous value are different, a event with event ID 9999 is logged in Operations Manager event log and CustomDST_MP.Control file is updated to the current value from WMI. This rule only runs during the weekend because daylight savings don’t happen during week days.

Note:

1. If CustomDST_MP.Control file does not exist, the script creates it and store the Current DaylightInEffect value in it. therefore there is no pre-configuration required on agent computers.

2. If the script detects the time zone is not impacted by daylight saving, it will skip to the end of the script and CustomDST_MP.Control file is not created on the agent computer.

The event 9999 looks like this:

image

(Please note the timing from above example is not correct because for testing purpose, I manually changed the value in the CustomDST_MP.control file.)

Rule #2. The “Daylight Saving In Effect” Setting has been changed

Rule Type: Alert Generating Rule

Description: This rule detects the event 9999 from Operations Manager event log that are generated by the previous rule (rule #1). and generates a information alert similar to this:

image

Rule #3. Detect Next Daylight Saving Effect Date and Time

Rule Type: Timed Script

Schedule: Runs on 12:00am every Monday

Description: The script inside this rule detects when (exact date and time) is the agent computer entering or exiting Daylight Saving time. if it is within the configurable number of days (AlertDayRange, the default is set to 10 days), an event with event ID 9998 is logged in Operations Manager log. the script works out the exact date and time for the daylight saving time changes and approximate number of days from when the script was run.

Event 9998 looks similar to this:

image

Note: for testing purpose, I have changed the AlertDayRange from 10 to 150 so the alert can be generated. In live environment, please be aware if you change the number to be greater than 14, you will be notified multiple times because the script runs once a week. For the same reason, if you change the number to be smaller than 7, you may not to get notified at all.

How to change AlertDayRange to a number other than 10?

To change AlertDayRange from the default of d10 days, simply create an override for this MP for the parameter called “Argument”:

image

Rule #4. The system time will be changed by Daylight Saving setting soon

Rule Type: Alert Generating Rule

Description: This rule detects the event 9998 from Operations Manager event log that are generated by the previous rule (rule #3). and generates a information alert similar to this:

image

This management pack can be downloaded here.

There are 3 files in the zip file. the XML file is the actual management pack (unsealed). the other 2 vbscripts are the actual scripts used in rule #1 and #3 for your reference.

ConfigMgr 2007 Inbox (Outbox) Monitor: Could not complete polling cycle within configured period

Written by Tao Yang

Starting few weeks ago, In the SCCM environment which I support, all site servers located in one country started generating status messages similar to below every 15 minutes:

SMS Inbox Monitor took 3627 seconds to complete a cycle.  This exceeds its configured interval of 900 seconds by 2727 seconds.

image

These messages are also logged in Site server’s application log. SCOM also detects it and generated warning alerts:

image

 

After reviewing inboxmgr.log, I noticed the time stamp for the log entries was 1 hour ahead of the system time. This also happens to the other SCCM log files. I then noticed the day light saving for that particular time zone has ended few weeks ago and the SCCM services has not been restarted since then.

Cause: SCCM services have not been restarted since system time changed.

Solution: I restarted SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services on affected site servers. and the system has stopped generating these messages. and time stamp for status messages are now back to normal.