A Brief History of Time

Actually no. But a quick post on how time can throw you in OpsMgr. I recently built a new 2 VM demo system – 1 for AD and the other for OpsMgr (all roles). I fired it up to do some testing on a problem I was working on and I received an alert to say that the AD health service was down. Checked the service on AD. Restarted it. Pinged the RMS by NetBios and FQDN and so on but that alert stubbornly refused to go even though it appeared all was well. I looked at Health Explorer and all the diagnostics that it had ran were green. I was puzzled.

I was looking at the OpsMgr log on the AD server and I noticed an event that was unfamiliar. Event 5500 and words that caught my attention were

“..caused the incoming state change request to be dropped due to it being older than currently recorder state change for this monitor.”

The rest of the message did not make sense but the older made me look at the time on both servers. Both had the same date and time but one was set to GMT, which I always set my servers to as I am in the UK, but for some strange reason the OpsMgr server was set to Pacific Time which is 8 hours behind GMT. That explained it. The AD was heart beating but as it was in GMT time zone the management server saw the heartbeat as being 8 hours old. As soon as I changed the time zone to GMT the alert immediately showed itself in the future so all I have to do now is wait 8 hours for both machines to be back in synch.

Suggestion for the product group. Have an alert when a heartbeat is received that is more than 1 hour out as that will probably be a time zone problem. Also MOM 2005 showed the list of agents and when was their last heartbeat. I tried to see if I could create a view to emulate that but did not find last heartbeat as a property of the agent. I used to find that view useful in 2005 so it would be nice to get in back in 2007.

Now that is sorted all sing along …

“…Let’s do the Time Warp again!…”

%d bloggers like this: