Using the “sync time” property in workflows and overrides


<!--[if lt IE 9]>

<![endif]-->

Comments (10)
  1. Anonymous says:

    SyncTime provides almost no value, in my opinion. The only time it may actually help reduce load is when a single server provides several different role – this is where a discover sync time may help to conserve cpu resource minimally.

    When it comes to virtualized agent restarts, sync time doesn’t provide value there. Whether or not the host system or any agents restart on that host, sync time will have the same impact on cpu as queuing the workflows to run when possible. In fact, I would argue that sync time would have a greater impact in the virtualized world than not having sync time, because it’s a rare occasion to have a ESX or Hyper-V host go down unexpectedly. Even still, this would mean the hosted agents will still run on a theoretical sync time – until any one agent is restarted, and then you have a real spread of workflows being triggered at different times.

    I believe sync time provides value when your pack has a discovery race issue, for whatever reason. This is a very uncommon scenario, but I have see certain services and distributed applications where it wasn’t exactly necessary to have a hosting relationships or seed class for a particular discovery to run. In this case, it is recommended to use sync time, in order to force a cascaded discovery.

    Good to see you blogging again, and congrats on the twins!

    Jonathan

  2. Anonymous says:

    Rapael – yes, I see it now 🙂

  3. Anonymous says:

    Jonathan – I agree on all counts.
    Raphael – that’s interesting – I might add some details around that option to this post.

  4. Anonymous says:

    I will clarify on one thing – if you have multiple scripts in your pack, it is a good idea to use sync time. 5 scripts, for example, would be sync time of 00:01, 00:02, 00:03, 00:04, 00:05. If a script runs for more than a minute, then there are other problems 🙂

  5. Anonymous says:

    Raphael – I can’t even find SpreadInitializationOverInterval mention on MSDN for the scheduler module, other than this page here: http://msdn.microsoft.com/en-us/library/ee692976.aspx.

    I see Daniele Grandini ad actually wrote about this a while back for SCOM 2007 R2, and I must have missed it – but he offers no MSDN references.

    Any MSDN resources regarding this configuration element for System.Scheduler?

    -Jonathan

  6. TechieSeeker says:

    wow ! Good to know about this internal SCOM control which can help minimize impact on infrastructure and assets in the context of resource choke.Thanks much.

  7. Raphael Burri says:

    Using "SpreadInitializationOverInterval" instead of "SyncTime" on the schedulers is another option to assure that the workflows do not run immediately after the agent starts. To run a workflow hourly, while letting the agent place the initial run randomly
    during the first hour, the following configuration example may be used: 3600 3600 Obviously it is either SyncTime or SpreadInitializationOverInterval. And it sometimes means more work since many library MP datasources have wired parameters for SyncTime overrides
    but not usually SpreadInitializationOverInterval overrides. Raphael

  8. rob1974 says:

    Using sync times with infrequent/daily intervals can lead to situations where it just never runs. e.g. due to a planned reboot at that specific time.

  9. Raphael Burri says:

    Jonathan: Indeed: It isn’t very clearly written up. However; you can find the reference in the schema definition of the PublicSchedulerType on http://msdn.microsoft.com/en-us/library/jj130319.aspx There you see that you actually have a choice between SpreadInitializationOverInterval and SyncTime.

  10. Anonymous says:

    Pingback from OpsMan » SCOM: ???sync time??? property

Comments are closed.

Skip to main content