Having some fun this week. I recently deployed a task sequence with a recurring schedule that is scheduled to run every third Monday of the month at 4:01 am for 137 systems.  Simple task sequence we just want those systems to reboot at that time.  For 136 of the systems it's behaving fine so far, i.e. apparently waiting for Monday the 21st of September.  But for one system it's behaving erratically and I can't figure out why. It's one of 20 developer machines that were all built from the same task sequence and are still virtually identical however this one system has been running this task sequence at bizarre time (users are not allowed to interact with the task sequence).

So far it has run at:

8/27 6:00pm

8/27 10:11 pm

8/28 6:00 pm

8/29 at 12:00 am

8/29 at 2:03 am

8/29 at 2:09 am

8/30 at 12:00 am

8//30 at 10:44 pm

8/31 at 6:00 pm

8/31 at 10:11 pm

And the software center showed is was schedule to go again tonight at 6:00 pm.  I've removed it from the collection getting the task sequence to fix the immediate issue, i.e. the machine rebooting so much, but for the life of me I can't see why this system is any different that the other 136 systems in the collection. And what's with the midnight runs or the two that were 6 minutes apart at 2:00 am?

Any ideas of what could be happening here?

 

What are the log telling you.

SMSTS.log

execmgr.log

"Simple task sequence we just want those systems to reboot at that time."

Why are you using a task sequence for this instead of a program in an empty package with a shutdown command in it?

Nothing useful:

SMSTS it started and finished, but no why's

execmgr shows it starting also:

Creating mandatory request for advert PRD2002E, program *, package PRD00090

Execution Request for advert PRD2002E package PRD00090 program * state change from NotExist to WaitingDependency

Request a MTC task for execution request of package PRD00090, program * with request id: {B6972447-F06D-443D-8100-DEC202E784A1}

I'll need to track down that request ID, which probably means getting my SQL guys involved.

That requestID is created locally by the ConfigMgr client and you won't find it in the database if I am not mistaken. "WaitingDependency"? Which one is it?

1) I don't really see where it makes a difference which process I use to do the reboot

2) incase I decide to add to the process (i.e. check for reboot pending)

Figured that but I'm looking for any explanation at this point.

As for the dependency, there is none.  It's a one step task sequence that does a system reboot. So the only "dependency" is it being 4:01 am on the third Monday of the month effective 9/21/2015 and this one system is ignoring that.

Here'd the relevant screenshots

Because you are using a very complicated piece of functionality to perform a very simple task. The principals of KISS are very relevant in IT just like in life. Why make things more complicated than they should be? Particularly since using a task sequence for non-OSD tasks is technically unsupported (even though many use them successfully to do non-OSD things). Why use your car to take a cup of sugar to your neighbor that live 100 feet from your front door? Sure it works, but its a lot more complicated and lot more can go wrong.

I understand your point, but I didn't come here to argue the merits of rebooting with a script vs a pre-defined task sequence, either way doesn't change the basic question.  What could cause this system to simply ignore the defined schedule.

Where are you getting those times from you placed in your original post?

Keeping things simple also means troubleshooting them is easier also and as mentioned, there as fewer things that can go wrong. Simply converting this to something far simpler would almost certainly address your issue also. As mentioned also, what you are doing is technically unsupported.

The times came off the details of the one that ran.  With one of 137 running it off schedule I doubt what is being deployed is the problem.

So those are not timestamps taken from any ConfigMgr related log or any log at all? Have you already examined the logs, eventlog? Do smsts.log/execmgr.log show that the reboot was initiated by the task sequence at all?

I used the details from the status summary from the deployment because it was convenient with less scrolling, as mentioned somewhere above, the same entries are in the SMSTS and EXEMGR logs.  They were just as uninformative as to the why as looking at the status details. Are you trying to say the status reporting is less than reliable?

I think we have a bit of a forest/trees situation going on here, it seems the questions back to me aren't related to the core question I'm asking so maybe I phrased it poorly.  So lets start over.

The scheduled reboot is happening exactly AS expected, it however is not happening WHEN expected for only one system out of 137 systems.  As shown above it is scheduled to run on 9/21 and instead has run multiple times beginning 8/27 (nearly a month prior to when it is scheduled). None of the obvious things are problems (the system time/date is correct and user interaction isn't allowed).

My question is, does anyone know of something that could cause a scheduled item to run much earlier than it was scheduled (besides bad date/time or user interaction)?