It was designed to automate the operation to solve the following issue (but not exclusively).
Windows Active Directory provides a loose sync time management infrastructure for all machines joined to the AD Domain. This time-keeping capability is sufficient and reliable enough for Windows and AD’s operations, particularly in ensuring that Kerberos authentication succeeds in the Forest/Domain and in-guest applications that do not require strict time accuracy (in sub-seconds). All Windows machines that are joined to a particular Windows Domain default to using the Windows-provided w32time service which looks at the domain/forest time hierarchy for its authoritative time synchronization.
vSphere includes a configuration option to enable virtual machines to synchronize their time with the ESXi host through the VMware Tools. Modern ESXi versions have this feature disabled (unchecked) by default. Most customers mistake this newer default option to indicate that a VM will not perform any time synchronization with the ESXi host under any circumstances. We know that, under certain operations (e.g. at boot time, resume and VMotion), a VM will adjust its clock to match that of the ESXi on which it resides. This behavior is not universally known among our customers and it has also resulted in some unintended and undesirable consequences for customers who have not been diligent in adhering to the good recommended practices of ensuring that host’s CMOS clocks are correct and the ESXi host is configured to use an external NTP time source for time-keeping.
The workflow can be started from the VMware vRealize Orchestrator (vRO) client. If the vRO is already registered in a vCenter instance, then the workflow can also be initiated directly from the vSphere Web Client. In either case, you first need to import the attached workflow package into the vSphere environment (using the vRO Client) before you can successfully use it in your vSphere environment.