It would be helpful to know exactly how much the time is drifting. Note that some amount of drift in the server's Real Time Clock is unavoidable. The clock in a PC is not high-precision atomic clock.
A drift of 1-2 seconds per day is common, but it could be as high as ~10 seconds per day. (It depends on the accuracy tolerance of the 32.768KHz crystal used on the motherboard. An accuracy of ±20ppm is typical and equals 1-2sec of drift per day. Cheaper crystals may be in the ±50ppm or ±100ppm range, which equals 5-10sec of drift per day.)
If you are seeing a drift higher than 10 seconds per day, your RTC crystal is probably running at the wrong frequency. That means you have a defective motherboard and it should be replaced. If the system it is still in warranty, contact the manufacturer. Note that if the RTC crystal is running at the wrong frequency, you may see other "strange" issues with the system because any software that depends on the RTC for sleeps/delays will be inaccurate. Until the problem is solved, I would not use this system in production, especially not in a situation where data integrity is important (domain controller, database server, file server).
Even a best-case drift of 1-2 seconds per day can accumulate over time. So, you need to periodically correct the clock. Typically a Windows PC will sync its time over the Internet via NTP. If the machine is joined to a domain, it will sync with its domain controller. Since you do not have Internet access, you will need to periodically correct the time via some other method.
You can do the periodic corrections manually (just edit the time/date in Windows), or you can add some kind of NTP server to your local network to sync against. You can purchase a GPS-based NTP server device for < $1000 USD. There are also NTP server appliances that use WWVB radio, or nearby cellular towers as a time source. You could also cheaply build your own Linux-based GPS NTP server out of a spare PC and a GPS receiver.
Also, since you mention a CMOS battery, I am assuming this is a physical server, not a VM/hypervisor scenario. Note that Virtual Machines are especially prone to clock drift (minutes per day), so syncing with an outside time source becomes very important if you are virtualized. (VM time drift is a topic unto itself.)