• This topic has 6 replies, 3 voices, and was last updated February 27, 2019 by Matthew C.

AD failover, unable to sync NTP

  • When we failover test/live  , our AD does not get the NTP time , when it power up it says it’s using CMOS time when running w32tm /query /source , due to the time difference between UTC time and EST time (5 hours behind)  so every time we failvoer , we have to manually perform w32tm /resync /force to set the time before we can bring up other VPGs.  Is there a better way of doing this? So AD VM can get the proper time?

    You could put that into a script and have Zerto launch the script upon failover. I’ve done this for manual DNS records that I needed updated and it works well.

    I am guessing this is the post script feature, will it be able to issue the DOS command  w32tm /resync /force?

    My concern is , we have other servers running at the time of this, so if the command is not run immediately after the AD server boots up, the other server will sync their time to UTC time.

    May be worth noting that Zerto scripts are run from the recovery zerto instances (ZVM or ZCA); there are indeed ways to run cmds within the guest itself from the zerto instance though not natively. For example, if the recovery zerto instances has powercli available (and the recovery site is vcenter) then the recovery script could leverage the invoke-vmscript cmdlet to run a script or cmds directly into the guest: https://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Invoke-VMScript.html

    You should orchestrate your failover so that your AD servers come up first, and are in a good state, before you failover other servers. What I did was stage a DC at my failover site, so I didn’t have to failover AD, thus lowering my RTO significantly.

    Thank you for all the suggestions.  Currently we don’t have an option to have another AD at DR location. When we failover, we only failover a subset of servers.

    All windows VMsare sync to AD, therefore , if the Time deviates, the server running will get the wrong time.



    In that case, I’d look at building a post-failover script. You could build in a natural delay, enough time for the DC to boot, then it can execute your time sync script. Once you verify that has completed, you’d move on to failing over your other servers. Just an idea.

You must be logged in to create new topics. Click here to login