Peningkatan akurasi waktu untuk Windows Server 2016

Windows Server 2016 telah meningkatkan algoritma yang digunakannya untuk memperbaiki waktu dan mengondisikan jam lokal untuk disinkronkan dengan UTC. NTP menggunakan 4 nilai untuk menghitung offset waktu, berdasarkan tanda waktu permintaan/respons klien dan permintaan/respons server. Namun, jaringan berisik, dan mungkin ada lonjakan data dari NTP karena kemacetan jaringan dan faktor lain yang memengaruhi latensi jaringan. Windows algoritma 2016 rata-rata kebisingan ini menggunakan sejumlah teknik berbeda yang menghasilkan jam yang stabil dan akurat. Selain itu, sumber yang kami gunakan untuk referensi waktu yang akurat adalah API yang ditingkatkan yang memberi kami resolusi yang lebih baik. Dengan peningkatan ini, kami dapat mencapai akurasi 1 ms sehubungan dengan UTC di seluruh domain.

Hyper-V

Windows 2016 telah meningkatkan layanan Hyper-V TimeSync. Peningkatan termasuk waktu awal yang lebih akurat pada mulai VM atau pemulihan VM dan koreksi latensi interupsi untuk sampel yang disediakan untuk w32time. Peningkatan ini memungkinkan kami untuk tetap dengan 10μs host dengan RMS, (Root Mean Squared, yang menunjukkan varians), dari 50μs, bahkan pada mesin dengan beban 75%. Untuk informasi selengkapnya, lihat Arsitektur Hyper-V.

Catatan

Beban dibuat menggunakan tolok ukur prime95 menggunakan profil seimbang.

Selain itu, tingkat Stratum yang dilaporkan Host kepada tamu lebih transparan. Sebelumnya Tuan Rumah akan menyajikan Stratum tetap 2, terlepas dari akurasinya. Dengan perubahan di Windows Server 2016, host melaporkan Stratum yang lebih besar dari Stratum host, yang menghasilkan waktu yang lebih baik untuk tamu virtual. Host Stratum ditentukan oleh w32time melalui cara normal berdasarkan waktu sumbernya. Domain yang bergabung Windows 2016 tamu akan menemukan jam yang paling akurat, daripada default ke host. Karena alasan inilah kami menyarankan untuk menonaktifkan pengaturan Penyedia Waktu Hyper-V secara manual untuk mesin yang berpartisipasi dalam domain di Windows 2012R2 ke bawah.

Pemantauan

Penghitung monitor performa telah ditambahkan. Ini memungkinkan Anda untuk membuat garis besar, memantau, dan memecahkan masalah akurasi waktu. Penghitung ini meliputi:

Penghitung	Deskripsi
Offset Waktu Komputasi	Offset waktu absolut antara jam sistem dan sumber waktu yang dipilih, seperti yang dihitung oleh Layanan W32Time dalam mikrodetik. Saat sampel valid baru tersedia, waktu komputasi diperbarui dengan offset waktu yang ditunjukkan oleh sampel. Ini adalah offset waktu aktual dari jam lokal. W32time memulai koreksi jam menggunakan offset ini dan memperbarui waktu komputasi di antara sampel dengan offset waktu yang tersisa yang perlu diterapkan ke jam lokal. Akurasi jam dapat dilacak menggunakan penghitung kinerja ini dengan interval polling rendah (misalnya:256 detik atau kurang) dan mencari nilai penghitung lebih kecil dari batas akurasi jam yang diinginkan.
Penyesuaian Frekuensi Jam	Penyesuaian frekuensi jam absolut yang dilakukan pada jam sistem lokal oleh W32Time di bagian per miliar. Penghitung ini membantu memvisualisasikan tindakan yang diambil oleh W32time.
Penundaan Pulang Pergi NTP	Penundaan round-trip terbaru yang dialami oleh Klien NTP dalam menerima respons dari server dalam mikrodetik. Ini adalah waktu yang berlalu pada klien NTP antara mengirimkan permintaan ke server NTP dan menerima respons yang valid dari server. Penghitung ini membantu mencirikan penundaan yang dialami oleh klien NTP. Perjalanan pulang pergi yang lebih besar atau bervariasi dapat menambahkan kebisingan ke komputasi waktu NTP, yang pada gilirannya dapat memengaruhi akurasi sinkronisasi waktu melalui NTP.
Jumlah Sumber Klien NTP	Jumlah aktif sumber Waktu NTP yang digunakan oleh Klien NTP. Ini adalah hitungan alamat IP aktif dan berbeda dari server waktu yang merespons permintaan klien ini. Jumlah ini mungkin lebih besar atau lebih kecil dari rekan-rekan yang dikonfigurasi, tergantung pada resolusi DNS nama serekan dan kemampuan jangkauan saat ini.
Permintaan Masuk Server NTP	Jumlah permintaan yang diterima oleh Server NTP (Permintaan/Detik).
Respons Keluar Server NTP	Jumlah permintaan yang dijawab oleh Server NTP (Respons/Detik).

3 penghitung pertama mengimbangi skenario target untuk memecahkan masalah akurasi. Bagian Akurasi Waktu Pemecahan Masalah dan NTP di bawah ini, di bawah Praktik Terbaik, memiliki detail lebih lanjut. 3 penghitung terakhir mencakup skenario server NTP dan berguna saat menentukan beban dan garis besar performa Anda saat ini.

Pembaruan Konfigurasi per Lingkungan

Berikut ini menjelaskan perubahan konfigurasi default antara Windows 2016 dan versi sebelumnya untuk setiap Peran. Pengaturan untuk Windows Server 2016 dan Windows 10 Anniversary Update (build 14393), sekarang unik itulah sebabnya diperlihatkan sebagai kolom terpisah.

Peran	Pengaturan	Server Windows 2016	Windows 10	Windows Server 2012 R2 Windows Server 2008 R2 Windows 10
Server Mandiri/Nano
	Server Waktu	\- time.windows.com	NA	\- time.windows.com
	Frekuensi Polling	64 - 1024 detik	NA	Seminggu sekali
	Frekuensi Pembaruan Jam	Sekali per detik	NA	Satu jam sekali
Klien Mandiri
	Server Waktu	NA	\- time.windows.com	\- time.windows.com
	Frekuensi Polling	NA	Sekali sehari	Seminggu sekali
	Frekuensi Pembaruan Jam	NA	Sekali sehari	Satu jam sekali
Pengendali Domain
	Server Waktu	PDC/GTIMESERV	NA	PDC/GTIMESERV
	Frekuensi Polling	64 -1024 detik	NA	1024 - 32768 detik
	Frekuensi Pembaruan Jam	Sekali per detik	NA	Satu jam sekali
Server Anggota Domain
	Server Waktu	DC	NA	DC
	Frekuensi Polling	64 -1024 detik	NA	1024 - 32768 detik
	Frekuensi Pembaruan Jam	Sekali per detik	NA	Setiap 5 menit sekali
Klien Anggota Domain
	Server Waktu	NA	DC	DC
	Frekuensi Polling	NA	1204 - 32768 detik	1024 - 32768 detik
	Frekuensi Pembaruan Jam	NA	Setiap 5 menit sekali	Setiap 5 menit sekali
Tamu Hyper-V
	Server Waktu	Memilih opsi terbaik berdasarkan Stratum server Host dan Time	Memilih opsi terbaik berdasarkan Stratum server Host dan Time	Default ke Host
	Frekuensi Polling	Berdasarkan Peran di atas	Berdasarkan Peran di atas	Berdasarkan Peran di atas
	Frekuensi Pembaruan Jam	Berdasarkan Peran di atas	Berdasarkan Peran di atas	Berdasarkan Peran di atas

Catatan

Untuk Linux di Hyper-V, lihat bagian Mengizinkan Linux menggunakan Waktu Host Hyper-V di bawah ini.

Dampak peningkatan polling dan frekuensi pembaruan jam

Untuk memberikan waktu yang lebih akurat, default untuk frekuensi polling dan pembaruan jam ditingkatkan yang memungkinkan kita untuk membuat penyesuaian kecil lebih sering. Ini akan menyebabkan lebih banyak lalu lintas UDP/NTP, namun, paket-paket ini kecil sehingga seharusnya ada sangat sedikit atau tidak ada dampak atas tautan broadband. Manfaatnya, bagaimanapun, adalah bahwa waktu harus lebih baik pada berbagai perangkat keras dan lingkungan.

Untuk perangkat yang didukung baterai, meningkatkan frekuensi polling dapat menyebabkan masalah. Perangkat baterai tidak menyimpan waktu saat dimatikan. Ketika dilanjutkan, mungkin memerlukan koreksi yang sering pada jam. Meningkatkan frekuensi polling akan menyebabkan jam menjadi tidak stabil dan juga dapat menggunakan lebih banyak daya. Microsoft menyarankan agar Anda tidak mengubah pengaturan default klien.

Pengendali Domain harus terkena dampak minimal bahkan dengan efek dikalikan dari peningkatan pembaruan dari Klien NTP di Domain AD. NTP memiliki konsumsi sumber daya yang jauh lebih kecil dibandingkan dengan protokol lain dan dampak marginal. Anda lebih cenderung mencapai batas untuk fungsionalitas domain lain sebelum terpengaruh oleh peningkatan pengaturan untuk Windows Server 2016. Direktori Aktif memang menggunakan NTP aman, yang cenderung menyinkronkan waktu kurang akurat daripada NTP sederhana, tetapi kami telah memverifikasinya akan meningkatkan skala ke klien dua Stratum jauh dari PDC.

Sebagai rencana konservatif, Anda harus memesan 100 permintaan NTP per detik per inti. Misalnya, domain yang terdiri dari 4 DC dengan masing-masing 4 core, Anda harus dapat melayani 1600 permintaan NTP per detik. Jika Anda memiliki 10k klien yang dikonfigurasi untuk menyinkronkan waktu setiap 64 detik sekali, dan permintaan diterima secara seragam dari waktu ke waktu, Anda akan melihat 10.000/64 atau sekitar 160 permintaan/detik, yang tersebar di semua DC. Ini mudah berada dalam 1600 permintaan NTP kami/detik berdasarkan contoh ini. Ini adalah rekomendasi perencanaan konservatif dan tentu saja memiliki dependensi besar pada jaringan, kecepatan prosesor, dan beban Anda, sehingga selalu mendasar dan menguji di lingkungan Anda.

Penting juga untuk dicatat bahwa jika DC Anda berjalan dengan beban CPU yang cukup besar, lebih besar dari 40%, ini hampir pasti akan menambah kebisingan pada respons NTP dan memengaruhi akurasi waktu Anda di domain Anda. Sekali lagi, Anda perlu menguji di lingkungan Anda untuk memahami hasil aktual.

Pengukuran Akurasi Waktu

Metodologi

Untuk mengukur akurasi waktu untuk Windows Server 2016, kami menggunakan berbagai alat, metode, dan lingkungan. Anda dapat menggunakan teknik ini untuk mengukur dan menyempurnakan lingkungan Anda dan menentukan apakah hasil akurasi memenuhi kebutuhan Anda.

Jam sumber domain kami terdiri dari dua server NTP presisi tinggi dengan perangkat keras GPS. Kami juga menggunakan mesin uji referensi terpisah untuk pengukuran, yang juga memiliki perangkat keras GPS presisi tinggi yang diinstal dari produsen yang berbeda. Untuk beberapa pengujian, Anda akan memerlukan sumber jam yang akurat dan andal untuk digunakan sebagai referensi selain sumber jam domain Anda.

Kami menggunakan empat metode berbeda untuk mengukur akurasi dengan komputer fisik dan virtual. Beberapa metode yang disediakan independen berarti memvalidasi hasilnya.

1. Ukur jam lokal, yang dikondisikan oleh w32tm, terhadap mesin uji referensi kami yang memiliki perangkat keras GPS terpisah.

2. Mengukur ping NTP dari server NTP ke klien menggunakan "stripchart" W32tm

3. Mengukur ping NTP dari klien ke server NTP menggunakan "stripchart" W32tm

4. Ukur hasil Hyper-V dari host ke tamu menggunakan Time Stamp Counter (TSC). Penghitung ini dibagi antara partisi dan waktu sistem di kedua partisi. Kami menghitung perbedaan waktu host dan waktu klien di komputer virtual. Kemudian kami menggunakan jam TSC untuk menginterpolasi waktu host dari tamu, karena pengukuran tidak terjadi pada saat yang sama. Selain itu, kami menggunakan penundaan dan latensi faktor jam TSV di API.

W32tm bawaan, tetapi alat lain yang kami gunakan selama pengujian tersedia untuk repositori Microsoft di GitHub sebagai sumber terbuka untuk pengujian dan penggunaan Anda. Untuk informasi selengkapnya tentang cara menggunakan alat untuk melakukan pengukuran, lihat Windows Alat Kalibrasi Waktu Wiki

Hasil pengujian yang ditunjukkan di bawah ini adalah subset pengukuran yang kami buat di salah satu lingkungan pengujian. Mereka menggambarkan akurasi yang dipertahankan pada awal hierarki waktu, dan klien domain anak pada akhir hierarki waktu. Ini dibandingkan dengan komputer yang sama dalam topologi berbasis 2012 untuk perbandingan.

Topologi

Sebagai perbandingan, kami menguji topologi berbasis Windows Server 2012R2 dan Windows Server 2016. Kedua topologi terdiri dari dua komputer host Hyper-V fisik yang mereferensikan komputer Windows Server 2016 dengan perangkat keras jam GPS terpasang. Setiap host menjalankan 3 tamu jendela yang bergabung dengan domain, yang diatur sesuai dengan topologi berikut. Garis mewakili hierarki waktu, dan protokol/transportasi yang digunakan.

Gambaran Umum Hasil Grafis

Dua grafik berikut mewakili akurasi waktu untuk dua anggota tertentu dalam domain berdasarkan topologi di atas. Setiap grafik menampilkan hasil Windows Server 2012R2 dan 2016 yang dilapisi, yang menunjukkan peningkatan secara visual. Akurasinya diukur dari dengan-di mesin tamu dibandingkan dengan host. Data grafis mewakili subset dari seluruh rangkaian pengujian yang telah kami lakukan dan menunjukkan skenario kasus terbaik dan kasus terburuk.

Performa PDC Domain Akar

Root PDC disinkronkan ke host Hyper-V (menggunakan VMIC) yang merupakan Windows Server 2016 dengan perangkat keras GPS yang terbukti akurat dan stabil. Ini adalah persyaratan penting untuk akurasi 1 ms, yang ditampilkan sebagai area berbayang hijau.

Performa Klien Domain Anak

Klien Domain Anak dilampirkan ke PDC Domain Anak yang berkomunikasi ke PDC Root. Waktu juga dalam persyaratan 1 ms.

Tes Jarak Jauh

Bagan berikut membandingkan 1 hop jaringan virtual dengan 6 hop jaringan fisik dengan Windows Server 2016. Dua bagan dilapisi satu sama lain dengan transparansi untuk menunjukkan data yang tumpang tindih. Meningkatkan hop jaringan berarti latensi yang lebih tinggi, dan penyimpangan waktu yang lebih besar. Bagan diperbesar sehingga batas 1 md, yang diwakili oleh area hijau, lebih besar. Seperti yang Anda lihat, waktunya masih dalam 1 md dengan beberapa lompatan. Ini bergeser negatif, yang menunjukkan asimetri jaringan. Tentu saja, setiap jaringan berbeda, dan pengukuran tergantung pada banyak faktor lingkungan.

Praktik Terbaik untuk timekeeping yang akurat

Jam Sumber Padat

Waktu mesin hanya sebagus jam sumber yang disinkronkannya. Untuk mencapai akurasi 1 md, Anda memerlukan perangkat keras GPS atau appliance waktu di jaringan yang Anda referensikan sebagai jam sumber master. Menggunakan default time.windows.com, mungkin tidak menyediakan sumber waktu yang stabil dan lokal. Selain itu, saat Anda menjauh dari jam sumber, jaringan memengaruhi akurasi. Memiliki jam sumber master di setiap pusat data diperlukan untuk akurasi terbaik.

Opsi GPS Perangkat Keras

Ada berbagai solusi perangkat keras yang dapat menawarkan waktu yang akurat. Secara umum, solusi saat ini didasarkan pada antena GPS. Ada juga solusi modem radio dan dial-up menggunakan garis khusus. Mereka terpasang ke jaringan Anda sebagai appliance, atau dicolokkan ke PC, misalnya Windows melalui PCIe atau perangkat USB. Opsi yang berbeda akan memberikan tingkat akurasi yang berbeda, dan seperti biasa, hasil tergantung pada lingkungan Anda. Variabel yang memengaruhi akurasi termasuk ketersediaan GPS, stabilitas dan beban jaringan, dan Perangkat Keras PC. Ini semua adalah faktor penting ketika memilih jam sumber, yang seperti yang kami sebutkan, adalah persyaratan untuk waktu yang stabil dan akurat.

Domain dan Waktu Sinkronisasi

Anggota domain menggunakan hierarki domain untuk menentukan mesin mana yang mereka gunakan sebagai sumber untuk menyinkronkan waktu. Setiap anggota domain akan menemukan komputer lain untuk disinkronkan dan menyimpannya sebagai sumber jam. Setiap jenis anggota domain mengikuti sekumpulan aturan yang berbeda untuk menemukan sumber jam untuk sinkronisasi waktu. PDC di Forest Root adalah sumber jam default untuk semua Domain. Tercantum di bawah ini adalah peran yang berbeda dan deskripsi tingkat tinggi tentang bagaimana mereka menemukan sumber:

• Pengendali Domain dengan peran PDC - Komputer ini adalah sumber waktu otoritatif untuk domain. Ini akan memiliki waktu paling akurat yang tersedia di domain, dan harus disinkronkan dengan DC di domain induk, kecuali dalam kasus di mana peran GTIMESERV diaktifkan.
• Pengendali Domain lainnya - Komputer ini akan bertindak sebagai sumber waktu untuk klien dan server anggota di domain. DC dapat disinkronkan dengan PDC domainnya sendiri, atau DC apa pun di domain induknya.
• Server Klien/Anggota – Komputer ini dapat disinkronkan dengan DC atau PDC domainnya sendiri, atau DC atau PDC di domain induk.

Berdasarkan kandidat yang tersedia, sistem penilaian digunakan untuk menemukan sumber waktu terbaik. Sistem ini memperhitungkan keandalan sumber waktu dan lokasi relatifnya. Ini terjadi sekali ketika waktu layanan dimulai. Jika Anda harus memiliki kontrol yang lebih baik tentang bagaimana waktu disinkronkan, Anda dapat menambahkan server waktu yang baik di lokasi tertentu atau menambahkan redundansi. Lihat bagian [Tentukan Layanan Waktu Andal Lokal Menggunakan GTIMESERV untuk informasi selengkapnya.

Lingkungan OS Campuran (Win2012R2 dan Win2008R2)

Meskipun lingkungan Domain Windows Server 2016 murni diperlukan untuk akurasi terbaik, masih ada manfaat di lingkungan campuran. Menyebarkan Windows Server 2016 Hyper-V di domain Windows 2012 akan menguntungkan tamu karena peningkatan yang kami sebutkan di atas, tetapi hanya jika tamu juga Windows Server 2016. PDC Windows Server 2016, akan dapat memberikan waktu yang lebih akurat karena algoritma yang ditingkatkan itu akan menjadi sumber yang lebih stabil. Karena mengganti PDC Anda mungkin bukan opsi, Anda dapat menambahkan Windows Server 2016 DC dengan kumpulan roll GTIMESERV yang akan menjadi peningkatan akurasi untuk domain Anda. Windows Server 2016 DC dapat memberikan waktu yang lebih baik kepada klien waktu hilir, namun, itu hanya sebagus waktu NTP sumbernya.

Juga seperti yang dinyatakan di atas, polling jam dan frekuensi refresh telah dimodifikasi dengan Windows Server 2016. Ini dapat diubah secara manual ke DC tingkat bawah Anda atau diterapkan melalui kebijakan grup. Meskipun kami belum menguji konfigurasi ini, mereka harus ber perilaku baik di Win2008R2 dan Win2012R2 dan memberikan beberapa manfaat.

Versi sebelum Windows Server 2016 memiliki beberapa masalah yang menjaga waktu yang akurat yang mengakibatkan waktu sistem melayang segera setelah penyesuaian dilakukan. Karena itu, mendapatkan sampel waktu dari sumber NTP yang akurat sering dan mengkondisikan jam lokal dengan data menyebabkan penyimpangan yang lebih kecil dalam jam sistem mereka dalam periode intra-sampling, menghasilkan waktu yang lebih baik menjaga versi OS tingkat bawah. Akurasi terbaik yang diamati adalah sekitar 5 md ketika Klien NTP Windows Server 2012R2, dikonfigurasi dengan pengaturan akurasi tinggi, disinkronkan waktunya dari server NTP Windows 2016 yang akurat.

Dalam beberapa skenario yang melibatkan pengontrol domain tamu, sampel Hyper-V TimeSync dapat mengganggu sinkronisasi waktu domain. Ini seharusnya tidak lagi menjadi masalah bagi tamu Server 2016 yang berjalan di host Hyper-V Server 2016.

Untuk menonaktifkan layanan Hyper-V TimeSync agar tidak menyediakan sampel ke w32time, atur kunci registri tamu berikut: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Mengizinkan Linux menggunakan Waktu Host Hyper-V

Untuk tamu Linux yang berjalan di Hyper-V, klien biasanya dikonfigurasi untuk menggunakan daemon NTP untuk sinkronisasi waktu terhadap server NTP. Jika distribusi Linux mendukung protokol TimeSync versi 4 dan tamu Linux mengaktifkan layanan integrasi TimeSync, maka itu akan disinkronkan terhadap waktu host. Ini dapat menyebabkan penyimpanan waktu yang tidak konsisten jika kedua metode diaktifkan.

Untuk menyinkronkan secara eksklusif terhadap waktu host, disarankan untuk menonaktifkan sinkronisasi waktu NTP dengan:

• Menonaktifkan server NTP apa pun dalam file ntp.conf

• atau Menonaktifkan daemon NTP

Dalam konfigurasi ini, parameter Server Waktu adalah host ini. Frekuensi Polling-nya adalah 5 detik dan Frekuensi Pembaruan Jam juga 5 detik.

Untuk menyinkronkan secara eksklusif melalui NTP, disarankan untuk menonaktifkan layanan integrasi TimeSync di tamu.

Catatan

Catatan: Dukungan untuk waktu yang akurat dengan tamu Linux memerlukan fitur yang hanya didukung di kernel Linux upstream terbaru dan ini bukan sesuatu yang tersedia secara luas di semua distro Linux. Silakan referensi Komputer virtual Linux dan FreeBSD yang didukung untuk Hyper-V di Windows untuk detail selengkapnya tentang distribusi dukungan.

Tentukan Reliable Time Service Lokal Menggunakan GTIMESERV

Anda dapat menentukan satu atau beberapa pengendali domain sebagai jam sumber yang akurat dengan menggunakan GTIMESERV, Good Time Server, bendera. Misalnya, pengendali domain tertentu yang dilengkapi dengan perangkat keras GPS dapat ditandai sebagai GTIMESERV. Ini akan memastikan domain Anda mereferensikan jam berdasarkan perangkat keras GPS.

Catatan

Informasi selengkapnya tentang bendera domain dapat ditemukan dalam dokumentasi protokol MS-ADTS.

TIMESERV adalah Bendera Layanan Domain terkait lainnya yang menunjukkan apakah komputer saat ini otoritatif, yang dapat berubah jika DC kehilangan koneksi. DC dalam status ini akan mengembalikan "Unknown Stratum" ketika dikueri melalui NTP. Setelah mencoba beberapa kali, DC akan mencatat Peristiwa Sistem Time-Service Peristiwa 36.

Jika Anda ingin mengonfigurasi DC sebagai GTIMESERV, ini dapat dikonfigurasi secara manual menggunakan perintah berikut. Dalam hal ini DC menggunakan komputer lain sebagai jam master. Ini bisa berupa appliance atau mesin khusus.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Catatan

Untuk informasi selengkapnya, lihat Mengonfigurasi Windows Time Service

Jika DC menginstal perangkat keras GPS, Anda perlu menggunakan langkah-langkah ini untuk menonaktifkan klien NTP dan mengaktifkan server NTP.

Mulailah dengan menonaktifkan Klien NTP dan aktifkan Server NTP menggunakan perubahan kunci registri ini.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

Selanjutnya, mulai ulang Layanan Waktu Windows

net stop w32time && net start w32time

Terakhir, Anda menunjukkan bahwa komputer ini memiliki sumber waktu yang dapat diandalkan menggunakan.

w32tm /config /reliable:yes /update

Untuk memeriksa apakah perubahan telah dilakukan dengan benar, Anda dapat menjalankan perintah berikut yang memengaruhi hasil yang ditunjukkan di bawah ini.

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 di Platform Virtual Pihak Ke-3

Ketika Windows divirtualisasi, secara default Hypervisor bertanggung jawab untuk memberikan waktu. Tetapi anggota yang bergabung dengan domain perlu disinkronkan dengan Pengendali Domain agar Direktori Aktif berfungsi dengan baik. Yang terbaik adalah menonaktifkan virtualisasi kapan saja antara tamu dan host platform virtual pihak ketiga mana pun.

Menemukan Hierarki

Karena rantai hierarki waktu ke sumber jam master bersifat dinamis di domain, dan dinegosiasikan, Anda perlu meminta status komputer tertentu untuk memahami sumber waktu dan rantainya ke jam sumber master. Ini dapat membantu mendiagnosis masalah sinkronisasi waktu.

Mengingat Anda ingin memecahkan masalah klien tertentu; langkah pertama adalah memahami sumber waktunya dengan menggunakan perintah w32tm ini.

w32tm /query /status

Hasilnya menampilkan Sumber antara lain. Sumber menunjukkan dengan siapa Anda menyinkronkan waktu di domain. Ini adalah langkah pertama dari hierarki waktu komputer ini. Selanjutnya gunakan entri Sumber dari atas dan gunakan parameter /StripChart untuk menemukan sumber waktu berikutnya dalam rantai.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Juga berguna, perintah berikut mencantumkan setiap pengontrol domain yang dapat ditemukan di domain yang ditentukan dan mencetak hasil yang memungkinkan Anda menentukan setiap mitra. Perintah ini akan mencakup komputer yang telah dikonfigurasi secara manual.

w32tm /monitor /domain:my_domain

Dengan menggunakan daftar, Anda dapat melacak hasilnya melalui domain dan memahami hierarki serta offset waktu di setiap langkah. Dengan menemukan titik di mana offset waktu menjadi jauh lebih buruk, Anda dapat menentukan akar waktu yang salah. Dari sana Anda dapat mencoba memahami mengapa waktu itu salah dengan mengaktifkan pengelogan w32tm.

Menggunakan Kebijakan Grup

Anda dapat menggunakan Kebijakan Grup untuk mencapai akurasi yang lebih ketat dengan, misalnya, menetapkan klien untuk menggunakan server NTP tertentu atau untuk mengontrol bagaimana OS tingkat bawah dikonfigurasi saat divirtualisasikan. Di bawah ini adalah daftar kemungkinan skenario dan pengaturan Kebijakan Grup yang relevan:

Domain Virtual - Untuk mengontrol Pengendali Domain Virtual di Windows 2012R2 sehingga mereka menyinkronkan waktu dengan domain mereka, daripada dengan host Hyper-V, Anda dapat menonaktifkan entri registri ini. Untuk PDC, Anda tidak ingin menonaktifkan entri karena host Hyper-V akan memberikan sumber waktu yang paling stabil. Entri registri mengharuskan Anda memulai ulang layanan w32time setelah diubah.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:000000000

Beban Sensitif Akurasi - Untuk beban kerja sensitif akurasi waktu, Anda dapat mengonfigurasi grup komputer untuk mengatur server NTP dan pengaturan waktu terkait, seperti polling dan frekuensi pembaruan jam. Ini biasanya ditangani oleh domain, tetapi untuk kontrol lebih lanjut Anda dapat menargetkan komputer tertentu untuk menunjuk langsung ke jam master.

Pengaturan Kebijakan Grup	Nilai Baru
NtpServer	ClockMasterName,0x8
MinPollInterval	6 – 64 detik
MaxPollInterval	6
UpdateInterval	100 – Sekali per detik
EventLogFlags	3 – Semua pencatatan waktu khusus

Catatan

Pengaturan NtpServer dan EventLogFlags terletak di bawah System\Windows Time Service\Time Providers menggunakan pengaturan Konfigurasi Windows Klien NTP. 3 lainnya terletak di bawah System\Windows Time Service menggunakan pengaturan Konfigurasi Global.

Beban Sensitif Akurasi Jarak Jauh – Untuk sistem di domain cabang misalnya Ritel dan Industri Kredit Pembayaran (PCI), Windows menggunakan informasi situs saat ini dan Pencari Lokasi DC untuk menemukan DC lokal, kecuali ada sumber waktu NTP manual yang dikonfigurasi. Lingkungan ini membutuhkan akurasi 1 detik, yang menggunakan konvergensi yang lebih cepat ke waktu yang benar. Opsi ini memungkinkan layanan w32time untuk memindahkan jam ke belakang. Jika ini dapat diterima dan memenuhi persyaratan Anda, Anda dapat membuat kebijakan berikut. Seperti halnya lingkungan apa pun, pastikan untuk menguji dan membuat garis besar jaringan Anda.

Pengaturan Kebijakan Grup	Nilai Baru
MaxAllowedPhaseOffset	1, jika lebih dari pada detik, atur jam ke waktu yang benar.

Pengaturan MaxAllowedPhaseOffset terletak di bawah System\Windows Time Service menggunakan pengaturan Konfigurasi Global.

Catatan

Untuk informasi selengkapnya tentang kebijakan grup dan entri terkait, lihat Windows Time Service Tools dan artikel Pengaturan di TechNet.

Pertimbangan IaaS Azure dan Windows

Azure Virtual Machine: Active Directory Domain Services

Jika Azure VM yang menjalankan Active Directory Domain Services adalah bagian dari Active Directory lokal Forest yang ada, maka TimeSync (VMIC), harus dinonaktifkan. Ini untuk memungkinkan semua DC di Forest, baik fisik maupun virtual, untuk menggunakan hierarki sinkronisasi satu kali. Lihat laporan resmi praktik terbaik "Menjalankan Pengendali Domain di Hyper-V"

Azure Virtual Machine: Komputer yang bergabung dengan domain

Jika Anda menghosting mesin yang merupakan domain yang bergabung ke Active Directory Forest yang ada, virtual atau fisik, praktik terbaik adalah menonaktifkan TimeSync untuk tamu dan memastikan W32Time dikonfigurasi untuk disinkronkan dengan Pengendali Domainnya melalui waktu konfigurasi untuk Type=NTP5

Azure Virtual Machine: Mesin grup kerja mandiri

Jika Azure VM tidak bergabung ke domain, juga bukan Pengendali Domain, rekomendasinya adalah mempertahankan konfigurasi waktu default dan membuat VM disinkronkan dengan host.

Aplikasi Windows Membutuhkan Waktu Akurat

API Stempel Waktu

Program yang memerlukan akurasi terbesar sehubungan dengan UTC, dan bukan berlalunya waktu, harus menggunakan GetSystemTimePreciseAsFileTime API. Ini memastikan aplikasi Anda mendapatkan Waktu Sistem, yang dikondisikan oleh layanan Windows Time.

Performa UDP

Jika Anda memiliki aplikasi yang menggunakan komunikasi UDP untuk transaksi dan penting untuk meminimalkan latensi, ada beberapa entri registri terkait yang dapat Anda gunakan untuk mengonfigurasi berbagai port yang akan dikecualikan dari port mesin pemfilteran dasar. Ini akan meningkatkan latensi dan meningkatkan throughput Anda. Namun, perubahan pada registri harus terbatas pada administrator berpengalaman. Selain itu, ini bekerja di sekitar mengecualikan port agar tidak diamankan oleh firewall. Lihat artikel referensi di bawah ini untuk informasi selengkapnya.

Untuk Windows Server 2012 dan Windows Server 2008, Anda harus menginstal Hotfix terlebih dahulu. Anda dapat mereferensikan artikel KB ini: Kehilangan datagram saat menjalankan aplikasi penerima multicast di Windows 8 dan di Windows Server 2012

Perbarui Driver Jaringan

Beberapa vendor jaringan memiliki pembaruan driver yang meningkatkan performa sehubungan dengan latensi driver dan buffering paket UDP. Silakan hubungi vendor jaringan Anda untuk melihat apakah ada pembaruan untuk membantu throughput UDP.

Pengelogan untuk Tujuan Audit

Untuk mematuhi peraturan pelacakan waktu, Anda dapat mengarsipkan log w32tm, log peristiwa, dan informasi pemantauan performa secara manual. Nantinya, informasi yang diarsipkan dapat digunakan untuk membuktikan kepatuhan pada waktu tertentu di masa lalu. Faktor-faktor berikut digunakan untuk menunjukkan akurasi.

1. Akurasi jam menggunakan penghitung monitor performa Computed Time Offset. Ini menunjukkan jam dengan akurasi yang diinginkan.
2. Sumber jam mencari "Respons Serekan dari" di log w32tm. Mengikuti teks pesan adalah alamat IP atau VMIC, yang menjelaskan sumber waktu dan berikutnya dalam rantai jam referensi untuk divalidasi.
3. Status kondisi jam menggunakan log w32tm untuk memvalidasi bahwa "ClockDispl Discipline: *SKEW*TIME*" terjadi. Ini menunjukkan bahwa w32tm aktif pada saat itu.

Pencatatan Aktivitas

Untuk mendapatkan cerita lengkapnya, Anda juga memerlukan informasi Log peristiwa. Dengan mengumpulkan log Peristiwa Sistem, dan pemfilteran di Time-Server, Microsoft-Windows-Kernel-Boot, Microsoft-Windows-Kernel-General, Anda mungkin dapat menemukan apakah ada pengaruh lain yang telah mengubah waktu, misalnya, pihak ketiga. Log ini mungkin diperlukan untuk mengesampingkan gangguan eksternal. Kebijakan grup dapat memengaruhi log peristiwa mana yang ditulis ke log. Lihat bagian di atas tentang Menggunakan Kebijakan Grup untuk detail selengkapnya.

Pengelogan Debug W32time

Untuk mengaktifkan w32tm untuk tujuan audit, perintah berikut memungkinkan pengelogan yang menunjukkan pembaruan jam secara berkala dan menunjukkan jam sumber. Mulai ulang layanan untuk mengaktifkan pengelogan baru.

Untuk informasi selengkapnya, lihat Cara mengaktifkan pengelogan debug di Windows Time Service.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Monitor Kinerja

Layanan Windows Server 2016 Windows Time memaparkan penghitung kinerja yang dapat digunakan untuk mengumpulkan pengelogan untuk audit. Ini dapat dicatat secara lokal atau jarak jauh. Anda dapat merekam penghitung Offset Waktu Komputer dan penundaan Pulang Pergi. Dan seperti penghitung kinerja apa pun, Anda dapat memantaunya dari jarak jauh dan membuat pemberitahuan menggunakan Manajer Operasi Pusat Sistem. Misalnya, Anda dapat menggunakan pemberitahuan untuk membuat alarm saat Time Offset menyimpang dari akurasi yang diinginkan. Paket Manajemen Pusat Sistem memiliki informasi lebih lanjut.

Contoh Keterlacakan Windows

Dari file log w32tm Anda akan ingin memvalidasi dua informasi. Yang pertama adalah indikasi bahwa file log saat ini adalah jam kondisi. Ini membuktikan bahwa jam Anda sedang dikondisikan oleh Windows Time Service pada waktu yang disengketakan.

151802 20:18:32.9821765s - ClockDispln Disipline: WAKTU SKEW* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307 151802 20:18:33.9898460s - ClockDispln Disiplin: SKE WAKTUW* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41 151802 20:18:44.1090410s - ClockDispln Disipline: WAKTU SKEW* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Poin utamanya adalah Anda melihat pesan yang diawali dengan ClockDispln Disipline yang merupakan bukti w32time berinteraksi dengan jam sistem Anda.

Selanjutnya Anda perlu menemukan laporan terakhir dalam log sebelum waktu yang disengketakan yang melaporkan komputer sumber yang saat ini digunakan sebagai jam referensi. Ini bisa berupa alamat IP, nama komputer, atau penyedia VMIC, yang menunjukkan bahwa alamat IP disinkronkan dengan Host untuk Hyper-V. Contoh berikut menyediakan alamat IPv4 10.197.216.105.

151802 20:18:54.6531515s - Respons dari peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123-10.197.216.105>:123), ofs: +00.0012218s

Sekarang setelah Anda memvalidasi sistem pertama dalam rantai waktu referensi, Anda perlu menyelidiki file log pada sumber waktu referensi dan mengulangi langkah yang sama. Ini berlanjut sampai Anda sampai ke jam fisik, seperti GPS atau sumber waktu yang diketahui seperti NIST. Jika jam referensi adalah perangkat keras GPS, maka log dari yang diproduksi mungkin juga diperlukan.

Pertimbangan Jaringan

Algoritma protokol NTP memiliki dependensi pada Simetri jaringan Anda. Saat Anda meningkatkan jumlah hop jaringan, probabilitas asimetri meningkat. Di sana, sulit untuk memprediksi jenis akurasi apa yang akan Anda lihat di lingkungan spesifik Anda.

Monitor Performa dan penghitung Waktu Windows baru di Windows Server 2016 dapat digunakan untuk menilai akurasi lingkungan Anda dan membuat garis besar. Selain itu, Anda dapat melakukan pemecahan masalah untuk menentukan offset komputer apa pun saat ini di jaringan Anda.

Ada dua standar umum untuk waktu yang akurat melalui jaringan. PTP (Precision Time Protocol - IEEE 1588) memiliki persyaratan yang lebih ketat pada infrastruktur jaringan tetapi sering kali dapat memberikan akurasi sub-mikrosekon. NTP (Network Time Protocol – RFC 1305) bekerja pada berbagai jaringan dan lingkungan yang lebih besar, yang membuatnya lebih mudah dikelola.

Windows mendukung Simple NTP (RFC2030) secara default untuk mesin yang bergabung dengan non-domain. Untuk komputer yang bergabung dengan Domain, kami menggunakan NTP aman yang disebut MS-SNTP, yang memanfaatkan rahasia negosiasi domain yang memberikan keuntungan manajemen daripada NTP Terautentikasi yang dijelaskan dalam RFC1305 dan RFC5905.

Protokol gabungan domain dan non-domain memerlukan port UDP 123. Untuk informasi selengkapnya tentang praktik terbaik NTP, lihat Draf IETF Praktik Terbaik Protokol Waktu Jaringan Saat Ini.

Reliable Hardware Clock (RTC)

Windows tidak melangkah ke waktu, kecuali batas tertentu terlampaui, melainkan disiplin jam. Itu berarti w32tm menyesuaikan frekuensi jam secara berkala, menggunakan pengaturan Frekuensi Pembaruan Jam, yang defaultnya satu detik sekali dengan Windows Server 2016. Jika jam berada di belakang, itu mempercepat frekuensi dan jika berada di depan, itu memperlambat frekuensi ke bawah. Namun, selama waktu itu antara penyesuaian frekuensi jam, jam perangkat keras terkendali. Jika ada masalah dengan firmware atau jam perangkat keras, waktu pada komputer bisa menjadi kurang akurat.

Ini adalah alasan lain Anda perlu menguji dan mendasar di lingkungan Anda. Jika penghitung kinerja "Computed Time Offset" tidak stabil pada akurasi yang Anda targetkan, maka Anda mungkin ingin memverifikasi bahwa firmware Anda sudah diperbarui. Sebagai pengujian lain, Anda dapat melihat apakah perangkat keras duplikat mereproduksi masalah yang sama.

Akurasi Waktu Pemecahan Masalah dan NTP

Anda dapat menggunakan bagian Menemukan Hierarki di atas untuk memahami sumber waktu yang tidak akurat. Melihat offset waktu, temukan titik dalam hierarki di mana waktu paling menyimpang dari Sumber NTP-nya. Setelah memahami hierarki, Anda mungkin ingin mencoba dan memahami mengapa sumber waktu tertentu tidak menerima waktu yang akurat.

Berfokus pada sistem dengan waktu yang berbeda, Anda dapat menggunakan alat-alat ini di bawah ini untuk mengumpulkan lebih banyak informasi untuk membantu Anda menentukan masalah dan menemukan resolusi. Referensi UpstreamClockSource di bawah ini, adalah jam yang ditemukan menggunakan "w32tm /config /status".

• Log Peristiwa Sistem
• Aktifkan pengelogan menggunakan: w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• kunci w32Time Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Jejak jaringan lokal
• Penghitung Kinerja (dari komputer lokal atau UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING UpstreamClockSource untuk memahami latensi dan jumlah hop ke Sumber
• Tracert UpstreamClockSource

Masalah	Gejala	Resolusi
Jam TSC lokal tidak stabil.	Menggunakan Perfmon - Komputer Fisik - Jam sinkronisasi stabil, tetapi Anda masih melihat bahwa setiap 1-2 menit dari beberapa 100us.	Perbarui Firmware atau validasi perangkat keras yang berbeda tidak menampilkan masalah yang sama.
Latensi Jaringan	diagram strip w32tm menampilkan RoundTripDelay lebih dari 10 mdtk. Variasi dalam penundaan menyebabkan kebisingan sebesar 1/2 dari waktu pulang pergi, misalnya penundaan yang hanya dalam satu arah. UpstreamClockSource adalah beberapa hop, seperti yang ditunjukkan oleh PING. TTL harus mendekati 128. Gunakan Tracert untuk menemukan latensi di setiap hop.	Temukan sumber jam yang lebih dekat untuk waktu. Salah satu solusinya adalah menginstal jam sumber pada segmen yang sama atau secara manual menunjuk ke jam sumber yang secara geografis lebih dekat. Untuk skenario domain, tambahkan komputer dengan peran GTimeServ.
Tidak dapat menjangkau sumber NTP dengan andal	W32tm /stripchart sewaktu-waktu mengembalikan "Permintaan kehabisan waktu"	Sumber NTP tidak responsif
Sumber NTP tidak responsif	Periksa penghitung Perfmon untuk Jumlah Sumber Klien NTP, Permintaan Masuk Server NTP, Respons Keluar Server NTP dan tentukan penggunaan Anda dibandingkan dengan garis besar Anda.	Menggunakan penghitung kinerja server, tentukan apakah beban telah berubah sebagai referensi ke garis besar Anda. Apakah ada masalah kemacetan jaringan?
Pengendali Domain tidak menggunakan jam yang paling akurat	Perubahan topologi atau jam waktu master yang baru ditambahkan.	w32tm /resync /rediscover
Jam Klien menyimpang	Time-Service peristiwa 36 di Log peristiwa sistem dan/atau teks dalam file log yang menjelaskan bahwa: penghitung "Jumlah Sumber Waktu Klien NTP" dari 1 ke 0	Pecahkan masalah sumber hulu dan pahami apakah mengalami masalah performa.

Waktu Baselining

Baselining penting agar Anda dapat terlebih dahulu, memahami performa dan akurasi jaringan Anda, dan membandingkan dengan garis besar di masa depan ketika masalah terjadi. Anda akan ingin menggarisbawaahkan PDC akar atau mesin apa pun yang ditandai dengan GTIMESRV. Kami juga akan merekomendasikan Anda mendasarkan PDC di setiap forest. Akhirnya pilih DC atau mesin penting yang memiliki karakteristik menarik, seperti jarak atau beban tinggi dan garis besarnya.

Ini juga berguna untuk garis besar Windows Server 2016 vs 2012 R2, namun Anda hanya memiliki w32tm /stripchart sebagai alat yang dapat Anda gunakan untuk membandingkan, karena Windows Server 2012R2 tidak memiliki penghitung kinerja. Anda harus memilih dua komputer dengan karakteristik yang sama, atau meningkatkan mesin dan membandingkan hasilnya setelah pembaruan. Adendum Pengukuran Waktu Windows memiliki informasi lebih lanjut tentang cara melakukan pengukuran terperinci antara 2016 dan 2012.

Dengan menggunakan semua penghitung kinerja w32time, kumpulkan data setidaknya selama seminggu. Ini akan memastikan Anda memiliki cukup referensi untuk memperhitungkan berbagai di jaringan dari waktu ke waktu dan cukup menjalankan untuk memberikan keyakinan bahwa akurasi waktu Anda stabil.

Redundansi Server NTP

Untuk konfigurasi Server NTP manual yang digunakan dengan komputer yang bergabung dengan non-domain atau PDC, memiliki lebih dari satu server adalah ukuran redundansi yang baik jika terjadi ketersediaan. Ini mungkin juga memberikan akurasi yang lebih baik, dengan asumsi semua sumber akurat dan stabil. Namun, jika topologi tidak dirancang dengan baik, atau sumber waktu tidak stabil, akurasi yang dihasilkan bisa lebih buruk sehingga hati-hati disarankan. Batas server waktu yang didukung w32time dapat mereferensikan secara manual adalah 10.

Detik Lompatan

Periode rotasi bumi bervariasi dari waktu ke waktu, yang disebabkan oleh peristiwa iklim dan geologis. Biasanya, variasinya sekitar satu detik setiap beberapa tahun. Setiap kali variasi dari waktu atom tumbuh terlalu besar, koreksi satu detik (naik atau turun) dimasukkan, yang disebut lompatan detik. Ini dilakukan sed sehingga perbedaannya tidak pernah melebihi 0,9 detik. Koreksi ini diumumkan enam bulan sebelum koreksi aktual. Sebelum Windows Server 2016, Microsoft Time Service tidak mengetahui detik lompatan, tetapi bergantung pada layanan waktu eksternal untuk menangani hal ini. Dengan peningkatan akurasi waktu Windows Server 2016, Microsoft sedang mengerjakan solusi yang lebih cocok untuk masalah kedua lompatan.

Seeding Waktu Aman

W32time di Server 2016 menyertakan fitur Secure Time Seeding. Fitur ini menentukan perkiraan waktu saat ini dari koneksi SSL keluar. Nilai waktu ini digunakan untuk memantau jam sistem lokal dan memperbaiki kesalahan kotor apa pun. Anda dapat membaca lebih lanjut tentang fitur dalam posting blog ini. Dalam penyebaran dengan sumber waktu yang dapat diandalkan dan komputer yang dipantau dengan baik yang mencakup pemantauan untuk offset waktu, Anda dapat memilih untuk tidak menggunakan fitur Secure Time Seeding dan mengandalkan infrastruktur yang ada sebagai gantinya.

Anda dapat menonaktifkan fitur dengan langkah-langkah berikut:

1. Atur nilai konfigurasi registri UtilizeSSLTimeData ke 0 pada komputer tertentu:

   reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f
   

2. Jika Anda tidak dapat segera me-reboot komputer karena alasan tertentu, Anda dapat memberi tahu layanan W32time tentang pembaruan konfigurasi. Ini menghentikan pemantauan dan penegakan waktu berdasarkan data waktu yang dikumpulkan dari koneksi SSL.

   W32tm.exe /config /update
   

3. Me-reboot komputer membuat pengaturan segera efektif dan juga menyebabkannya berhenti mengumpulkan data kapan saja dari koneksi SSL. Bagian terakhir memiliki overhead yang sangat kecil dan tidak boleh menjadi perhatian.

4. Untuk menerapkan pengaturan ini di seluruh domain, atur nilai UtilizeSSLTimeData dalam pengaturan kebijakan grup W32time ke 0 dan terbitkan pengaturan. Ketika pengaturan diambil oleh klien Kebijakan Grup, layanan W32time akan diberi tahu dan akan menghentikan pemantauan dan penegakan waktu menggunakan data waktu SSL. Pengumpulan data waktu SSL akan berhenti saat setiap komputer di-boot ulang. Jika domain Anda memiliki laptop/tablet ramping portabel dan perangkat lain, Anda mungkin ingin mengecualikan komputer tersebut dari perubahan kebijakan ini. Perangkat ini pada akhirnya akan menghadapi pengurasan baterai dan membutuhkan fitur Secure Time Seeding untuk bootstrap waktunya.