The scenario is that upon imaging a new machine, one of our first automation tasks is to sync time with a NTP time source. This is needed so the machine will be able to domain join in a later step.
When we attempt to set the system time and time zone from an NTP source in a Big Fix action script, it negatively affects the “restart 60” action in a later task within the same baseline. So for example, if the system time changes the internal CMOS clock by two hours, the restart is changed to 2 hours and the 60 seconds is ignored. We thought about restarting the BES client following the time change task but that would likely kill the baseline.
We are using “tzutil.exe /s “ to set the time zone and “W32TM” with a manual peer list consisting of our internal time servers. When the machine joins the domain later on in the process, we configure the system time to point to our domain hierarchy (again with “W32TM”).
Any ideas of how to handle this time change gracefully inclusive of the reboot, but without interrupting the baseline action?
The issue isn’t the setting of the time itself, rather it is how the client handles the change in time. Think of all the way the client uses date/time information - licensing, signatures, actions, etc.
The goal is to have a fully automated solution. However when the time changes significantly, it throws off the client and skews date/time in actions. Technically, Bigfix client works fine, the issue is the surrounding automation process flow.
An example to help clarify:
A machine gets pulled off the shelf for a new deployment. Its CMOS battery is dead, so it defaults to 1/1/1970. An image is laid down including the Bigfix agent. It starts staging via policy actions. One of the first steps is to set the date/time. It successfully completes. The next step is to reboot in 60 seconds … except now the client thinks it is in 46 years and 60 seconds. So it sits and waits … for 46 years and 60 seconds … obviously impractical and undesirable. Technically the agent is correct, process-wise and automation-wise it is a failure. Using a non-actionscript command (as an alternative) to reboot the computer will cause the baseline (and hence the automation) to fail.
Actionscript does not seem to be taking that change into consideration.
The restart command or the restart option has a time parameter. That’s where we discovered this issue.
We are looking into a post-imaging, pre-Bigfix agent install option for date/time setting. It would be handy to do this in Bigfix. It sounds like it isn’t practically feasible.
This is essential to be correct as following steps like domain join would otherwise fail.
Have you tried prompting for a restart with a time limit as the post action to a fixlet that sets the clock?
Also you could try having your normal policy actions be non-relevant if the clock is wrong, and then have a task/fixlet that fixes the clock that is not a part of a baseline?