Fix Windows Server Time Sync: Troubleshooting w32time 2026

Tolong ya, berhenti ngeabaikan sinkronisasi waktu Windows Server di server produksi kalian. Serius, aku udah lihat kasus ini berulang-ulang, dan tiap kali tetep bikin gemas. Bukan karena ribet, tapi karena hampir selalu gara-gara hal kecil yang sebenarnya gampang dicegah dari awal.

Kemarin aja ada ticket masuk jam 9 pagi. Client panik, sebagian user gak bisa login ke aplikasi internal, ada juga email yang gak keproses bener. Langkah pertamaku waktu cek server? Ya cek jamnya. Dan tebak apa yang terjadi — server-nya telat 7 menit. Fix-nya? Gak sampai 15 menit. Padahal ini masalah yang sama yang udah kejadian ke client yang sama dua kali dalam setahun terakhir. Gila gak sih.

Kenapa Waktu Server Meleset Itu Bukan Masalah Sepele

Banyak yang mikir, “ah telat 2 menit doang mah gak masalah, toh gak ada yang ngeliat.” Sih, nek kui salah besar. Di lingkungan production, selisih waktu lebih dari 5 menit bisa bikin Kerberos authentication gagal total. User gak bisa login domain, service account berhenti komunikasi, RDP nolak koneksi, TLS certificate dianggap belum valid padahal masih berlaku. Belum lagi scheduled task yang eksekusi di jam yang salah dan ngaco-ngacoin automation kalian.

Di environment Active Directory, dampaknya makin besar. Semua member server ngambil waktu dari domain controller — tepatnya dari yang megang role PDC Emulator. Kalau PDC-nya meleset, seluruh domain ikut meleset. Ibarat jam menara di alun-alun, nek jam menaranya salah, semua orang yang liat jam kui ikut salah jadwalnya. Dan jangan tanya gimana rasanya pas client komplain “kok email kita ke-reject karena timestamp mismatch?” — itu nyesek, lha wong penyebabnya cuma jam server meleset 3 menit.

Dari pengalamanku nangani ratusan server, akar masalahnya hampir selalu salah satu dari ini: (1) layanan w32time gak pernah jalan atau ke-kick abis Windows Update, (2) NTP source gak dikonfigurasi atau ke-block firewall UDP 123, (3) PDC Emulator gak diset sebagai reliable time source, (4) timezone server salah dari awal, atau (5) konflik time sync antara w32time dan tool virtualisasi kayak VMware Tools atau Hyper-V Integration Services. Kalau masalahmu masuk salah satu di atas, kamu udah ada di artikel yang bener. Tenang, solusine ana kabeh di sini.

Solusi Step-by-Step: Fix Sinkronisasi Waktu w32time

Sebelum mulai, catat ini dulu: semua perintah di bawah dijalankan dari Command Prompt atau PowerShell yang jalan sebagai Administrator. Kalau pake sesi biasa, perintah bakal ditolak dengan permission error. Siapkan juga minimal dua NTP server public yang bisa diakses dari server kalian.

Step 1: Diagnosa Dulu, Jangan Langsung Ngarang Config

Ini aturan emasku di NOC: cek dulu, baru ubah. Kalau langsung utak-atik konfigurasi tanpa tau kondisi sekarang, kamu bakal buta arah dan malah bikin tambah rusak. Jalankan tiga perintah ini:

w32tm /query /status
w32tm /query /source
w32tm /query /peers

Output yang sehat kira-kira kayak gini:

Leap Indicator: 3(not synchronized)
Stratum: 2 (secondary reference - syncd to (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0624813s
Root Dispersion: 0.0294113s
ReferenceId: 0x0A000001 (source IP: 10.0.0.1)
Last Successful Sync Time: 2026-08-03 07:15:22
Source: 10.0.0.1 (PDC)

Nih, perhatiin bagian yang penting. Kalau kamu lihat Leap Indicator: 3(not synchronized), atau lebih parah lagi Source: Local CMOS Clock atau Source: VM IC Time Synchronization Provider, berarti server itu gak sync dari NTP eksternal sama sekali. “Local CMOS Clock” itu artinya server cuma andelin baterai CMOS-nya sendiri — dan di VPS, ini hampir dijamin bakal drift pelan-pelan. Ini masalah utama yang harus kamu beresin.

Oh ya, jangan lupa cek timezone sekalian:

tzutil /g

Ini penting banget. Aku pernah nemu server yang waktu UTC-nya bener, tapi timezone-nya Singapore karena diawalan dibikin di provider luar negeri. Hasilnya jam lokal meleset 1 jam dan semua user lokal komplain. Nek timezone salah, fix langsung:

tzutil /s "SE Asia Standard Time"

Step 2: Stop Hypervisor Dari Nge-Ganggu w32time

Nah, ini yang paling sering bikin jengkel kalau servernya VPS atau VM. VMware Tools dan Hyper-V Integration Services punya fitur “time synchronization” yang jalan sendiri, terpisah dari w32time. Masalahnya, dua-duanya gak tau satu sama lain. Jadi yang satu reset jamnya, yang lain reset lagi — hasilnya jam server goyang terus dan w32time gak pernah bisa stabil. Parahnya, konflik ini gak keliatan jelas di event log, cuma muncul sebagai clock jump yang kalau gak teliti, ketuker sama gejala lain.

Prinsipnya gampang: pilih satu pengatur waktu, yang lain matiin. Kalau mau w32time yang jadi bos (ini rekomendasiku untuk server yang join domain), matikan time sync dari hypervisor. Di Hyper-V, matikan “Time Synchronization” di Integration Services settings. Di VMware, matikan host time sync lewat guest properties atau set dua opsi ini di file VMX:

time.synchronize.tools = FALSE
time.synchronize.resume.disk = FALSE

Eh tapi, kalau kamu gak yakin mau full pake w32time, sah-sah aja sebaliknya: matiin w32time dan andelin time sync hypervisor. Itu juga valid buat VPS standalone. Asal jangan dua-duanya hidup bareng. Dua-duanya hidup itu sumber kegilaan, jam kamu bakal maju mundur kayak orang bimbang.

Step 3: Set NTP Source (Manual Peer List)

Buat server standalone yang gak join domain, kita set sumber waktu dari NTP eksternal. Ini command yang kupake tiap hari:

w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /update

Catet soal flag 0x8: flag ini bilang ke w32time bahwa peer tersebut dipakai dalam mode client (mode NTP biasa), bukan symmetric active mode. Banyak artikel yang gak jelasin ini, dan akibatnya orang gagal sync ke NTP public karena symmetric mode sering ditolak. Jangan sampai kamu jadi korban artikel setengah jadi.

Terus, restart layanan dan paksa resync:

net stop w32time
net start w32time
w32tm /resync /rediscover

Langkah restart ini cuma menyentuh layanan waktu dan gak ngeganggu aplikasi lain di server. Tapi buat amannya, jalankan di luar jam sibuk biar kalau ada yang aneh, kamu masih punya ruang napas buat rollback.

Verifikasi hasilnya:

w32tm /query /source

Kalau output-nya udah gak “Local CMOS Clock” dan berubah jadi nama host atau IP NTP, berarti kamu sudah di jalur yang bener. Lha, itu aja udah bikin plong 90 persen.

Step 4: Kalau Join Domain, Set PDC Emulator Sebagai Sumber Waktu

Untuk environment Active Directory, ceritanya beda. Aliran waktu itu dua lapis: PDC Emulator sync dari NTP eksternal, dan semua member server lain sync dari PDC. Jadi di PDC Emulator, pastikan AnnounceFlags-nya bener biar dia berani ngumumin diri sebagai reliable time source:

reg add HKLMSYSTEMCurrentControlSetServicesW32TimeConfig /v AnnounceFlags /t REG_DWORD /d 5 /f
reg add HKLMSYSTEMCurrentControlSetServicesW32TimeParameters /v NTPServer /t REG_SZ /d "time.windows.com,0x8 pool.ntp.org,0x8" /f
w32tm /config /syncfromflags:manual /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /reliable:YES /update
net stop w32time && net start w32time
w32tm /resync /rediscover

Sementara di semua member server lain, set biar dia sync dari hierarki domain, bukan nyari NTP eksternal sendiri:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync /rediscover

Jangan sampai kebalik ya. PDC ke luar (eksternal), member server ke dalam (PDC). Aku pernah nemu environment yang semua member servernya diset manualpeerlist ke NTP eksternal berbeda-beda, dan hasilnya antar server malah beda waktu karena masing-masing ngejar source yang drift-nya gak sama. Ujung-ujungnya domain korup trust-nya dan semua pada nyalahin jaringan. Padahal ya itu, salah config waktunya doang.

Step 5: Cek Firewall, UDP Port 123 Wajib Kebuka

NTP jalan di UDP port 123. Kalau ada firewall di antaranya — Windows Firewall, firewall di sisi provider VPS, atau iptables di hypervisor — dan port ini ke-block, w32time bakal gagal sync secara diam-diam. Ini salah satu penyebab paling umum yang sering kelewat karena gak ada error yang berteriak. Gak drama, cuma diam-diam gak sync.

Di Windows Firewall biasanya udah ada rule bawaan “Windows Time Service” untuk UDP 123. Kalau gak ada atau gak aktif, tambahkan manual:

netsh advfirewall firewall add rule name="NTP Outbound" dir=out action=allow protocol=UDP remoteport=123
netsh advfirewall firewall add rule name="NTP Inbound" dir=in action=allow protocol=UDP localport=123

Terus tes jalur NTP-nya pake stripchart — ini alat debugging favoritku, simpel tapi informatif:

w32tm /stripchart /computer:time.windows.com /samples:5 /dataonly

Kalau output-nya timeout atau ICMP error terus-terusan, berarti jalur jaringan ke NTP source-nya yang bermasalah. Cek firewall dan route. Kalau muncul offset kecil kayak +0.01s, berarti koneksinya sehat dan masalahnya di konfigurasi w32time — lanjut ke step berikutnya.

Step 6: Kalau Masih Bandel, Reset Total Layanan w32time

PERINGATAN KEAMANAN: Backup Sebelum Melanjutkan — Sebelum menjalankan perintah di bawah, pastikan kamu sudah backup registry W32Time. Langkah ini nge-unregister layanan w32time, dan walaupun state-nya cuma disimpan di registry (risiko data loss kecil), backup tetep wajib biar tenang. Export dulu:

reg export HKLMSYSTEMCurrentControlSetServicesW32Time C:backupw32time-registry-backup.reg /y

Verifikasi file backup-nya ada dan bisa dibuka. Kalau nanti ada yang salah, kamu tinggal double-click file .reg itu buat restore. Jangan pernah skip langkah verifikasi ini, mumpung cuma butuh sepuluh detik.

Setelah backup aman, baru lanjut reset total:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /config /manualpeerlist:"time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /update
net stop w32time && net start w32time
w32tm /resync /rediscover

Reset ini membersihin state w32time yang corrupt — misalnya service yang ke-stuck abis update Windows, atau sisa-sisa setting lama yang bentrok di registry. Dari pengalamanku, jurus pamungkas ini ngebenerin sekitar 80 persen kasus bandel yang gak mempan sama langkah-langkah sopan di atas.

Step 7: Tuning Interval Sync (Opsional)

Nah, kalau semua udah jalan tapi jam masih suka meleset dikit, kamu bisa atur interval polling-nya. Default UpdateInterval di Windows Server itu 300.000 detik — tapi tenang, itu cuma nentuin seberapa sering w32time nyampling offset dari peer, bukan frekuensi dia narik waktu ke NTP. Yang nentuin polling NTP itu SpecialPollInterval, dan default-nya 3.600 detik (1 jam). Buat server yang butuh presisi, turunkan:

reg add HKLMSYSTEMCurrentControlSetServicesW32TimeParameters /v SpecialPollInterval /t REG_DWORD /d 3600 /f
reg add HKLMSYSTEMCurrentControlSetServicesW32TimeConfig /v UpdateInterval /t REG_DWORD /d 300 /f
net stop w32time && net start w32time
w32tm /resync /rediscover

SpecialPollInterval 3600 berarti polling tiap 1 jam. Kalau mau lebih rapat, 900 itu artinya tiap 15 menit. Jangan dipasang di bawah itu kalau targetnya NTP pool public — operator pool bakal nganggep kamu nakal dan pelan-pelan stop melayani. Dan UpdateInterval jangan asal disentuh kalau kamu gak paham konsekuensinya.

Baca Event Log W32Time Kayak NOC Engineer

Kalau semua langkah di atas udah kamu lakuin tapi masih ada yang aneh, saatnya baca log. W32Time naruh error-nya di Event Viewer, log System, dengan source “W32Time”. Ini contoh yang paling sering aku temuin di lapangan:

Level: Warning, Event ID 36
Provider: W32Time
The time service has not synchronized the system time for 86400 seconds
because none of the time providers has been able to provide a usable
time stamp. The system time is not synchronized.

Level: Error, Event ID 50
Provider: W32Time
The time service encountered a serious problem and was forced to shut down.
The error code was: 0x80070005

Level: Warning, Event ID 12
Provider: W32Time
The time provider NtpClient is configured to acquire time from one or more
time sources, however none of the sources are currently accessible.

Level: Information, Event ID 35
Provider: W32Time
The time service is now synchronizing the system time with the time source
192.0.2.10 (ntp.example.net).

Aku baca log ini dari awal, satu per satu, kayak gini:

• Event ID 12 (Warning): ini gejala awal. NtpClient gak bisa akses sumber waktu mana pun. Penyebab paling umum: firewall nge-block UDP 123, DNS gak resolve hostname NTP, atau NTP server-nya lagi down.
• Event ID 36 (Warning): ini polanya. Udah 86.400 detik (24 jam) gak sync sama sekali. Server makin lama makin jauh dari waktu sebenarnya. Ini sequel jahat dari Event ID 12 yang gak kunjung dibenerin.
• Event ID 50 (Error): ini root cause kalau muncul. Kode 0x80070005 itu access denied — artinya w32time gak punya permission yang bener, biasanya gara-gara service logon account yang salah atau security policy yang kegencet.
• Event ID 35 (Information): ini kabar baik. Server mulai sync lagi. Kalau baris ini muncul abis kamu fix, berarti kasusnya kelar.

Selain event log, kamu juga bisa aktifin debug log w32time:

w32tm /debug /enable /file:C:WindowsTempw32time.log /size:10000000
w32tm /debug /disable

Terus baca file C:WindowsTempw32time.log buat ngeliat detail provider mana yang gagal dan kenapa. Ini senjata ampuh pas mau closing ticket dengan bukti lengkap, bukan cuma “udah aku coba restart”.

Tabel Troubleshooting Cepat Sinkronisasi Waktu

Gejala	Kemungkinan Penyebab	Solusi
w32tm /query /source nampilin “Local CMOS Clock”	NTP source belum pernah diset	Set manualpeerlist + /syncfromflags:manual lalu resync
Event ID 12 muncul terus-menerus	UDP 123 ke-block atau DNS NTP gagal resolve	Cek firewall, tes pake w32tm /stripchart
Jam meleset makin lama makin besar	w32time gak jalan atau polling gak aktif	Reset layanan dan set SpecialPollInterval
Jam goyang maju mundur di VPS	Konflik time sync hypervisor (VMware/Hyper-V)	Matikan time sync tools, biarkan w32time yang jalan
Member server saling beda waktu	Semua diset manualpeerlist ke eksternal	Ganti ke /syncfromflags:domhier, sync dari PDC
Event ID 50 dengan error 0x80070005	Service account / permission w32time salah	Cek service logon, export registry, reset layanan
w32tm /resync gagal terus	NTP source down atau gak reachable	Ganti NTP source dan verifikasi pake stripchart

Pro Tips dari Lapangan

Dari ratusan kasus yang udah aku tangani, ada beberapa hal kecil yang sering bikin beda besar. Nih, catet baik-baik, iki penting:

• Jangan pernah pake hardware clock VPS sebagai sumber waktu. RTC di mesin virtual itu sharing resource dan hampir pasti drift. Selalu pake NTP eksternal.
• Set minimal dua NTP source. Kalau satu mati, masih ada backup. Tapi jangan berlebihan juga, dua sampai tiga udah cukup.
• Catat setiap perubahan konfigurasi. Ini kunci pas mau bikin root cause analysis. Kalau jam meleset tanggal X dan kamu ubah firewall tanggal X-1, jelas banget kaitannya.
• Buat VPS KVM, pastikan agent atau paket virtio-nya gak override waktu. Beda vendor beda tingkah, cek dokumentasi masing-masing.
• Jadikan cek waktu sebagai bagian dari checklist post-reboot. Setiap patch Tuesday atau maintenance, jalanin w32tm /query /status. Drift sering muncul abis reboot karena service start order.

Oh ya, kalau kamu lagi beresin server yang juga bermasalah performa atau layanan lain, cek juga panduan troubleshoot high load VPS dan artikel monitoring server pakai Netdata dan Grafana biar bisa lihat server dari sisi lain. Saling nyambung, dan sering muncul barengan di satu ticket yang sama.

Artikel Terkait

Buat pendalaman lebih lanjut, beberapa artikel ini masih satu keluarga besar dengan topik waktu tadi:

• Backup dan Restore Windows Server yang Aman
• Dasar-Dasar PowerShell Scripting untuk Admin Server
• Troubleshoot High Load VPS Step-by-Step
• Monitoring Server dengan Netdata dan Grafana

FAQ Seputar Fix Waktu Windows Server

Tolong ya, jangan ngulangin kesalahan yang sama kayak yang sering aku lihat di lapangan. Sekarang kamu udah punya checklist lengkap — pake. Pasang monitoring waktu di server production, cek berkala, dan kalau ada ticket jam meleset, kamu gak perlu panik lagi karena udah tau persis harus ngapain. Pelajarin baik-baik biar gak ada lagi client yang komplain email ke-reject gara-gara jam server telat 3 menit. Take it seriously, nggih.