We use the scheduler datasource in SCOM for workflows for all kinds of purposes. Most workflows have some concept of a schedule in the datasource to tell how often to inspect for something, like a service running, or to look at perfmon data, or to run a script.
The most common property would be the Interval, which is how often we want the workflow to run.
SyncTime is another common property. This is used to tell the workflow to run “synchronized” on a very specific point in time. From: http://msdn.microsoft.com/en-us/library/jj130319.aspx
“Specifying a synchronization time forces the module to output a data item at the specified time, and it executes on that frequency based on that synchronization point. “
If we do not provide a sync time, and only provide an interval (say, 5 minutes for example), the behavior of the workflow will be to run the workflow IMMEDIATELY upon agent startup (or as soon as the agent is capable of running workflows) and then on a 5 minute interval schedule from that point forward. This is generally a good thing, as it will randomize when agents are running workflows on common intervals, assuming all your agents don’t start up at the same time. This has two good effects: It controls us from flooding the network sending data from the agents to MS in bursts, all at the same time, and it keeps us from overloading a Hypervisor host, having lots of monitored servers running on it. If all agents ran a script that consumed 50% CPU at the exact same time, it could exhaust the resources of the host during script executions.
If we DO provide a sync time for the workflow, then the behavior is to NOT run the workflow immediately on agent startup. Instead, we will run the workflow based on the set interval, and start running it as soon as possible where it will run “synchronized” to the given sync time. When the workflow or agent is initialized, the full schedule is calculated, and the module is output at the next closest time. This might be confusing, so let me provide some examples:
Scenario 1: Daily execution I have a script based rule, where the Interval is set to 86400 seconds (once per day) and the sync time is set to 05:15. Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time. Lets say the monitored agent gets rebooted at 11:03 PM. The workflow will wait, to run on its defined interval, and execute at exactly 5:15 am.
Scenario 2: Infrequent execution I have a script based rule, where the Interval is set to every 4 hours and the sync time is set to 05:15. Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time. Lets say the monitored agent gets rebooted at 11:03 PM. The workflow will wait, to run on its defined interval, and execute based on its interval, that also must fall on 5:15 AM. Therefore, since the agent started up at 11:03 PM, the next possible interval on the 05:15 sync time would be 1:15 AM. This will be the first execution of the script, and then it will continue repeating every 4 hours, staying in sync with always having one of the executions running at 05:15.
Scenario 3: Moderate frequency I have a script based rule, where the Interval is set to every 15 minutes and the sync time is set to 05:15. Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time. Lets say the monitored agent gets rebooted at 11:03 PM. The workflow will wait, to run on its defined interval, and execute based on its interval, that also must fall on 5:15 AM. Therefore, since the agent started up at 11:03 PM, the next possible interval on the 05:15 sync time would be 11:15 PM. This will be the first execution of the script, and then it will continue repeating every 15 minutes, staying in sync with always having one of the executions running at 05:15.
Scenario 4: Very frequent I have a script based rule, where the Interval is set to every 1 minute and the sync time is set to 05:15. Sync time is based on a 24 hour clock, so 05:15 is 5:15am, local agent time. Lets say the monitored agent gets rebooted at 11:03 PM. The workflow will wait, to run on its defined interval, and execute based on its interval, that also must fall on 5:15 AM. Therefore, since the agent started up at 11:03 PM, the next possible interval on the 05:15 sync time would be 11:04 PM. This will be the first execution of the script (assuming the agent has fully started and is ready to run workflows), and then it will continue repeating every 1 minute, staying in sync with always having one of the executions running at 05:15. As you can see, there is VERY LITTLE value to ever using a sync time with a very frequent execution.
What we can see, is that synch time bring the most value, when we want to control when workflows execute at a specific point in time. This works really well, if I have a MP with very expensive discovery scripts, and I need to ensure they don’t all run at the same time, or we wish to control which discoveries runs first as subsequent discoveries might depend on previous discovered data. It can also be useful if we DON’T want the agent to run the workflow upon agent startup. Beyond that, you should take care in leveraging any sync time value, as you can accidentally create unnecessary load on the network, or virtualization hosts.