It's clear that the industry best practice is to use a real time source, but there is a flip side: If you deviate from the industry best practice, how much do you risk? When instructed to deviate from best practice, should you be upset and insist that your boss put the request in writing, creating friction between yourself and him/her? Should you refuse to do it completely? Should you just roll with it?
If you have a specific need, then it's important to cater to that need, and you might have to insist against deviation from best practice. But if instead, all you have to worry about is AD remaining functional, and approximate correct timestamps on files and such, and users knowing the correct time to show up at meetings, then your need is much less strict. I hear people on this list referring to "unstable time source" and "false ticker." This is a valid concern, sort-of. In reality, your guest machines are no better at tracking time than the VM time server is, so when there's any deviation between the client and your time server, it doesn't result in a false ticker. The way you get a false ticker is when you have configured several time servers, and some of them agree with each other by quorum, but there is an outlier. In that case, the clients still get the correct time, but the one outlier server needs to be corrected. There is something to be said for anecdotal evidence, when there's a lot of it. I've seen many dozens of environments where AD is run in virtual servers, which get their time from the internet (non-local stratum 2), and AD serves time to the clients on the LAN without noticeable problems. Sure the time may drift a few seconds in either direction, but again - unless you have a specific need, that's good enough for general use. Most environments don't have a dedicated stratum 1 time source, and most AD is run on VM's. In those many dozen environments, I've seen many hundreds of VM's running as guests on peoples' laptops. Most common is the windows VM running inside someone's macbook. This introduces yet another level of VM time-fuzziness, and yet again, I've never seen it cause a problem, because the only requirements in those environments have been to keep AD running, and clients operational, and users showing up to meetings at the right time. I have some further anecdotal evidence: I have actually seen a situation or two, where the AD server was no longer able to get time from the internet (due to firewall change - once hardware, and once software). So the AD time source slowly drifted off, and all the clients slowly followed. We discovered when a human noticed, "Why does my laptop say 4:05, when my phone says 4:13?" So then we restored the ability for AD to follow the internet, and AD slowly adjusted back to the right time, and all the clients slowly followed. Nevermind stratum 1. That's a VM client, following a VM server, following a non-local stratum 2 time source. It's about as bad as you can get, but the problem was caused by firewall blockage, and the behavior of the system was about as ideal as you can get, once the firewall problems were corrected. Unless you have a specific need, in this case, the risk of deviation from best practice is pretty low. Further evidence: Despite trying to demonstrate a problem with this, to prove your boss wrong, you couldn't demonstrate a problem. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
