Shouldn't be a problem. Just create a zone on your DNS server called 'time.windows.com'. We do it all the time for various things we want to override.
You can also try handing out the NTP server parameter (option ntp-servers) on your DHCP server. Windows may not pick it up, but it couldn't hurt.
On one hand, this is a neat question, but on the other hand, it may be primarily opinion-based. There really is no one single way to do this. You have options, and many of them are equally as valid.
From reading blog posts like this one, you get the impression that even Microsoft employees are torn about it:
Our original recommendation was to disable the time synchronization and leave it up to the DC’s own functionality to synchronize time with other DC’s.
For a time, I followed that advice with no ill-effects, because I was so comfortable with the way NTP and time sync in an AD domain works, that I felt that the Hyper-V time sync was just getting in the way. It worked fine for me.
But Ben Armstrong, Hyper-V Program Manager, says this:
Question #8 – When should I disable the Hyper-V time synchronization
service (either in the virtual machine settings, or inside the guest
operating system)?
Never.
There are definitely times when you will want to augment the
functionality of the Hyper-V time integration services with a remote
time source (be it a domain source or an external time server) but the
only way to get the best experience around virtual machine boot /
restore operations is to leave the Hyper-V time integration services
enabled.
When I run the following commands on a Win8.1 virtualized guest (joined to an AD domain, whose DCs are also virtualized, and time sync integration services enabled on all,) on Hyper-V 2012 R2, I see this:
C:\>w32tm /query /source
VM IC Time Synchronization Provider
C:\>w32tm /query /peers
#Peers: 1
Peer: DC01.labs.myotherpcisacloud.com
State: Active
Time Remaining: 254.6744551s
Mode: 3 (Client)
Stratum: 2 (secondary reference - syncd by (S)NTP)
PeerPoll Interval: 10 (1024s)
HostPoll Interval: 10 (1024s)
The output seems contradictory.
And this guy talks about partially disabling the time sync on your domain guests via a registry tweak on all your domain members. But I personally shun that approach. It bugs me when I go into someone else's environment (to fix their time sync issues no doubt) and I see that they've manually reconfigured every single domain member's Windows Time service. Leave it alone, is my motto.
Here's my own personal check list:
Leave time sync integration service enabled everywhere.
Assuming all DCs are VMs, configure your forest root PDCE domain controller to sync with an external time source, such as *.pool.ntp.org. Your forest root PDCE should be the only computer in your AD forest configured to look to an external time source. All other domain members and domain controllers will organically locate a DC via traditional Windows Time mechanisms.
Configure your Hyper-V hosts to point to the same external time source(s) as the virtualized forest root PDCE. Regardless of whether your Hyper-V hosts are joined to the same domain or not, you want them to be able to reach a reliable time source if the virtualized DCs that run inside them are down.
This works fine... it isn't the only way to skin the cat, but it works fine.
Best Answer
I don't think it has changed in Server 2016.
https://support.microsoft.com/en-us/help/816042/how-to-configure-an-authoritative-time-server-in-windows-server
Although, if it's a cloud hosted virtual machine there is a good chance your operating system's clock is synced with the host's clock, and your hosting provider should already be keeping that synced with a reliable time source. But, you might have to contact them about how they handle that.