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 Waktu Universal Terkoordinasi (UTC). Protokol Waktu Jaringan (NTP) menggunakan empat 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. Algoritma Windows Server 2016 rata-rata keluar dari kebisingan ini dengan menggunakan beberapa teknik berbeda, yang menghasilkan jam yang stabil dan akurat. Sumber yang kami gunakan untuk waktu yang akurat juga mereferensikan API yang ditingkatkan, yang memberi kami resolusi yang lebih baik. Dengan peningkatan ini, kita dapat mencapai akurasi 1-ms mengenai UTC di seluruh domain.

Hyper-V

Windows Server 2016 telah meningkatkan layanan Hyper-V TimeSync. Peningkatan termasuk waktu awal yang lebih akurat pada mulai komputer virtual (VM) atau pemulihan VM dan koreksi latensi interupsi untuk sampel yang disediakan untuk layanan Waktu Windows (W32Time). Peningkatan ini memungkinkan kita untuk tetap dalam 10μs dari host dengan akar rata-rata persegi (yang menunjukkan varians) 50μs, bahkan pada mesin dengan beban 75%. Untuk informasi selengkapnya, lihat Arsitektur Hyper-V.

Catatan

Beban dibuat dengan menggunakan tolok ukur prime95 menggunakan profil seimbang.

Tingkat Stratum yang dilaporkan host kepada tamu lebih transparan. Sebelumnya, host akan menyajikan Stratum tetap 2, terlepas dari akurasinya. Dengan perubahan di Windows Server 2016, host melaporkan Stratum 1 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. Tamu Windows Server 2016 yang bergabung dengan domain menemukan jam yang paling akurat daripada default ke host. Untuk alasan ini, kami menyarankan agar Anda menonaktifkan pengaturan Penyedia Waktu Hyper-V secara manual untuk komputer yang berpartisipasi dalam domain di Windows Server 2012 R2 dan yang lebih lama.

Pemantauan

Penghitung Monitor Performa telah ditambahkan. Penghitung ini memungkinkan Anda untuk membuat garis besar, memantau, dan memecahkan masalah akurasi waktu. Tabel berikut mencantumkan penghitung.

Penghitung	Deskripsi
Offset Waktu Komputasi	Offset waktu absolut antara jam sistem dan sumber waktu yang dipilih, sebagaimana dihitung oleh layanan W32Time dalam mikrodetik. Saat sampel baru yang valid tersedia, waktu komputasi diperbarui dengan offset waktu yang ditunjukkan oleh sampel. Kali ini adalah offset waktu aktual dari jam lokal. W32Time memulai koreksi jam dengan 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 dengan menggunakan penghitung kinerja ini dengan interval polling rendah (misalnya, 256 detik atau kurang) dan mencari nilai penghitung menjadi 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 pulang pergi terbaru yang dialami oleh klien NTP dalam menerima respons dari server dalam mikrodetik. Penundaan 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. Putaran 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. Jumlah 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 yang dikonfigurasi, tergantung pada resolusi DNS nama serekan dan keterjangkauan 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).

Tiga skenario target penghitung pertama untuk memecahkan masalah akurasi. Untuk informasi selengkapnya, lihat bagian Memecahkan masalah akurasi waktu dan NTP nanti di artikel ini. Tiga penghitung terakhir mencakup skenario server NTP dan sangat membantu ketika Anda menentukan beban dan dasar performa Anda saat ini.

Pembaruan konfigurasi per lingkungan

Tabel berikut ini menjelaskan perubahan konfigurasi default antara Windows Server 2016 dan versi sebelumnya untuk setiap peran. Pengaturan untuk Windows Server 2016 dan Windows 10 Anniversary Update (build 14393) sekarang unik, itulah sebabnya mereka ditampilkan 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 dalam satu 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	1.024 - 32.768 detik
	Frekuensi Pembaruan Jam	Sekali dalam satu detik	NA	Satu jam sekali
Server Anggota Domain
	Server Waktu	DC	NA	DC
	Frekuensi Polling	64 -1.024 detik	NA	1.024 - 32.768 detik
	Frekuensi Pembaruan Jam	Sekali dalam satu detik	NA	Setiap 5 menit sekali
Klien Anggota Domain
	Server Waktu	NA	DC	DC
	Frekuensi Polling	NA	1.204 - 32.768 detik	1.024 - 32.768 detik
	Frekuensi Pembaruan Jam	NA	Setiap 5 menit sekali	Setiap 5 menit sekali
Tamu Hyper-V
	Server Waktu	Memilih opsi terbaik berdasarkan Stratum host dan server waktu	Memilih opsi terbaik berdasarkan Stratum host dan server waktu	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 Izinkan Linux menggunakan waktu host Hyper-V.

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. Perubahan ini menyebabkan lebih banyak lalu lintas Protokol Datagram Pengguna (UDP)/NTP. Paket-paket ini kecil, jadi harus ada sedikit atau tidak ada efek atas tautan broadband. Manfaatnya adalah waktu tersebut harus lebih baik pada berbagai perangkat keras dan lingkungan yang lebih luas.

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

Pengendali domain (DC) harus dipengaruhi secara minimal bahkan dengan efek dikalikan dari peningkatan pembaruan dari klien NTP di domain Direktori Aktif. NTP memiliki konsumsi sumber daya yang jauh lebih kecil dibandingkan dengan protokol lain dan efek marginal. Anda lebih mungkin 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. Kami telah memverifikasi bahwa itu dapat meningkatkan skala ke klien dua Stratum jauh dari pengendali domain utama (PDC).

Sebagai rencana konservatif, Anda harus memesan 100 permintaan NTP per detik per inti. Misalnya, dengan domain yang terdiri dari empat DC dengan masing-masing empat core, Anda harus dapat melayani 1.600 permintaan NTP per detik. Jika Anda memiliki 10.000 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. Jumlah ini mudah berada dalam 1.600 permintaan NTP kami/detik berdasarkan contoh ini. Rekomendasi perencanaan ini konservatif dan sangat bergantung pada jaringan, kecepatan prosesor, dan beban Anda. Seperti biasa, garis besar dan uji di lingkungan Anda.

Jika DC Anda berjalan dengan beban CPU yang cukup besar, lebih besar dari 40%, beban ini hampir pasti menambahkan 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

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

Metodologi

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 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 untuk memvalidasi hasilnya.

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

2. Ukur ping NTP dari server NTP ke klien dengan menggunakan W32tm stripchart.

3. Ukur ping NTP dari klien ke server NTP dengan menggunakan W32tm stripchart.

4. Ukur hasil Hyper-V dari host ke tamu dengan 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 VM. Kemudian kami menggunakan jam TSC untuk menginterpolasi waktu host dari tamu karena pengukuran tidak terjadi pada saat yang sama. Selain itu, kami menggunakan jam volume tersegmentasi waktu untuk memperhitungkan keterlambatan dan latensi dalam API.

W32tmdibangun, 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 Wiki Alat Kalibrasi Waktu Windows.

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

Topologi

Sebagai perbandingan, kami menguji topologi berdasarkan Windows Server 2012 R2 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 tiga tamu Windows 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 sebelumnya. Setiap grafik menampilkan hasil Windows Server 2012 R2 dan 2016 yang dilapisi, yang menunjukkan peningkatan secara visual. Akurasi diukur dari dalam komputer tamu dibandingkan dengan host. Data grafis mewakili subset dari seluruh rangkaian pengujian yang kami lakukan dan menunjukkan skenario terbaik dan terburuk.

Performa PDC domain akar

PDC akar disinkronkan ke host Hyper-V (dengan menggunakan VMIC), yang merupakan Windows Server 2016 dengan perangkat keras GPS yang terbukti akurat dan stabil. Persyaratan ini sangat penting untuk akurasi 1-ms, yang ditampilkan sebagai area berbayang yang diidentifikasi oleh callout.

Performa klien domain anak

Klien domain anak dilampirkan ke PDC domain anak yang berkomunikasi ke PDC akar. Waktunya juga dalam persyaratan 1 ms.

Tes jarak jauh

Bagan berikut membandingkan satu hop jaringan virtual dengan enam hop jaringan fisik dengan Windows Server 2016. Dua bagan dilapisi satu sama lain dengan transparansi untuk menampilkan 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 berbayang, lebih besar. Seperti yang Anda lihat, waktunya masih dalam 1 ms dengan beberapa hop. Ini bergeser negatif, yang menunjukkan asimetri jaringan. Setiap jaringan berbeda, dan pengukuran tergantung pada banyak faktor lingkungan.

Praktik terbaik untuk timekeeping yang akurat

Ikuti praktik terbaik ini untuk penjaga waktu yang akurat.

Jam sumber padat

Waktu komputer hanya sebagus jam sumber yang disinkronkan. Untuk mencapai akurasi 1 ms, 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. Saat Anda semakin jauh dari jam sumber, jaringan memengaruhi akurasi. Memiliki jam sumber master di setiap pusat data diperlukan untuk akurasi terbaik.

Opsi GPS perangkat keras

Berbagai solusi perangkat keras dapat menawarkan waktu yang akurat. Secara umum, solusi saat ini didasarkan pada antena GPS. Solusi modem radio dan dial-up menggunakan baris khusus. Mereka melampirkan ke jaringan Anda sebagai appliance atau menyambungkan ke PC, misalnya, Windows melalui perangkat PCIe atau USB. Opsi yang berbeda memberikan tingkat akurasi yang berbeda, dan seperti biasa, hasilnya bergantung pada lingkungan Anda. Variabel yang memengaruhi akurasi termasuk ketersediaan GPS, stabilitas dan beban jaringan, dan perangkat keras PC. Faktor-faktor ini semua penting ketika Anda memilih jam sumber, yang merupakan persyaratan untuk waktu yang stabil dan akurat.

Domain dan waktu sinkronisasi

Anggota domain menggunakan hierarki domain untuk menentukan komputer mana yang mereka gunakan sebagai sumber untuk menyinkronkan waktu. Setiap anggota domain menemukan komputer lain untuk disinkronkan dan menyimpannya sebagai sumber jamnya. Setiap jenis anggota domain mengikuti sekumpulan aturan yang berbeda untuk menemukan sumber jam untuk sinkronisasi waktu. PDC di akar forest adalah sumber jam default untuk semua domain. Tercantum di sini 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 memiliki waktu yang paling akurat yang tersedia di domain. Ini harus disinkronkan dengan DC di domain induk, kecuali dalam kasus di mana peran GTIMESERV diaktifkan.
• Pengontrol domain lainnya: Komputer ini 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. Pemeriksaan ini terjadi sekali ketika layanan waktu 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. Untuk informasi selengkapnya, lihat bagian Menentukan layanan waktu andal lokal dengan menggunakan GTIMESERV.

Lingkungan OS campuran (Windows Server 2012 R2 dan Windows Server 2008 R2)

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 Server 2012 menguntungkan tamu karena peningkatan yang kami sebutkan, tetapi hanya jika tamu juga berada di Windows Server 2016. PDC Windows Server 2016 dapat memberikan waktu yang lebih akurat karena algoritma yang ditingkatkan, sehingga merupakan sumber yang lebih stabil. Karena mengganti PDC Anda mungkin bukan opsi, Anda dapat menambahkan DC Windows Server 2016 dengan kumpulan roll GTIMESERV, yang akan menjadi peningkatan akurasi untuk domain Anda. Windows Server 2016 DC dapat memberikan waktu yang lebih baik untuk klien waktu hilir, tetapi hanya sebagus waktu NTP sumbernya.

Juga seperti yang dinyatakan, frekuensi polling dan refresh jam dimodifikasi dengan Windows Server 2016. Frekuensi ini dapat diubah secara manual ke DC tingkat bawah Anda atau diterapkan melalui Kebijakan Grup. Kami belum menguji konfigurasi ini, tetapi harus bereaksi baik di Windows Server 2008 R2 dan Windows Server 2012 R2 dan memberikan beberapa manfaat.

Versi sebelum Windows Server 2016 memiliki beberapa masalah dengan timekeeping yang akurat, yang mengakibatkan waktu sistem melayang segera setelah penyesuaian dilakukan. Karena masalah ini, sering mendapatkan sampel waktu dari sumber NTP yang akurat dan mengondisikan jam lokal dengan data menyebabkan penyimpangan yang lebih kecil di jam sistem mereka dalam periode pengambilan sampel intra. Hasilnya adalah penukaran waktu yang lebih baik pada versi OS tingkat bawah. Akurasi terbaik yang diamati adalah sekitar 5 ms ketika klien Windows Server 2012 R2 NTP, dikonfigurasi dengan pengaturan akurasi tinggi, menyinkronkan waktunya dari server Windows Server 2016 NTP yang akurat.

Dalam beberapa skenario yang melibatkan DC tamu, sampel Hyper-V TimeSync dapat mengganggu sinkronisasi waktu domain. Masalah ini seharusnya tidak lagi ada untuk tamu Windows Server 2016 yang berjalan di host Windows Server 2016 Hyper-V.

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

Izinkan 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, itu disinkronkan terhadap waktu host. Skenario ini dapat menyebabkan pencatatan waktu yang tidak konsisten jika kedua metode diaktifkan.

Untuk menyinkronkan secara eksklusif terhadap waktu host, kami sarankan Anda menonaktifkan sinkronisasi waktu NTP dengan salah satu dari dua metode:

• Nonaktifkan server NTP apa pun dalam ntp.conf file.
• Nonaktifkan daemon NTP.

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

Untuk menyinkronkan secara eksklusif melalui NTP, kami sarankan Anda menonaktifkan layanan integrasi TimeSync di tamu.

Catatan

Dukungan untuk waktu yang akurat dengan tamu Linux memerlukan fitur yang hanya didukung di kernel Linux upstream terbaru. Fitur ini belum tersedia secara luas di semua distro Linux. Untuk informasi selengkapnya tentang distribusi dukungan, lihat Komputer virtual Linux dan FreeBSD yang didukung untuk Hyper-V di Windows.

Tentukan layanan waktu andal lokal dengan menggunakan GTIMESERV

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

Catatan

Untuk informasi selengkapnya tentang bendera domain, lihat 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 kembali Unknown Stratum ketika dikueri melalui NTP. Setelah mencoba beberapa kali, DC mencatat Peristiwa Sistem Peristiwa Waktu-Layanan Peristiwa 36.

Jika Anda ingin mengonfigurasi DC sebagai GTIMESERV, konfigurasikan secara manual dengan menggunakan perintah berikut. Dalam hal ini, DC menggunakan komputer lain sebagai jam master. Mesin ini bisa menjadi appliance atau mesin khusus.

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

Catatan

Untuk informasi selengkapnya, lihat Mengonfigurasi layanan Windows Time

Jika DC menginstal perangkat keras GPS, gunakan langkah-langkah berikut untuk menonaktifkan klien NTP dan mengaktifkan server NTP.

Mulailah dengan menonaktifkan klien NTP dan mengaktifkan server NTP dengan 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 Windows Time:

net stop w32time && net start w32time

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

w32tm /config /reliable:yes /update

Untuk memeriksa apakah perubahan dilakukan dengan benar, jalankan perintah berikut, yang memengaruhi hasil yang diperlihatkan di sini:

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 pada platform virtual pihak ketiga

Ketika Windows divirtualisasi, secara default, Hypervisor bertanggung jawab untuk memberikan waktu. Tetapi anggota yang bergabung dengan domain perlu disinkronkan dengan DC 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 dalam domain, dan dinegosiasikan, Anda perlu meminta status komputer tertentu untuk memahami sumber waktu dan rantainya ke jam sumber master. Informasi ini dapat membantu mendiagnosis masalah sinkronisasi waktu.

Jika Anda ingin memecahkan masalah klien tertentu, langkah pertama adalah memahami sumber waktunya dengan menggunakan perintah ini w32tm :

w32tm /query /status

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

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

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

w32tm /monitor /domain:my_domain

Dengan menggunakan daftar, Anda dapat melacak hasilnya melalui domain dan memahami hierarki dan 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 tersebut salah dengan mengaktifkan w32tm pengelogan.

Gunakan 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 sistem operasi tingkat bawah dikonfigurasi saat divirtualisasikan. Berikut adalah daftar kemungkinan skenario dan pengaturan Kebijakan Grup yang relevan:

Domain virtual: Untuk mengontrol DC virtual di Windows Server 2012 R2 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 memberikan sumber waktu yang paling stabil. Entri registri mengharuskan Anda memulai ulang W32Time setelah diubah.

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

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. Tugas 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 dengan menggunakan pengaturan Konfigurasi Klien Windows NTP. Tiga lainnya terletak di bawah System\Windows Time Service dengan menggunakan pengaturan Konfigurasi Global.

Beban sensitif akurasi jarak jauh 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 W32Time untuk memindahkan jam ke belakang. Jika perilaku 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, tetapi jika lebih dari satu detik, atur jam ke waktu yang benar.

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

Catatan

Untuk informasi selengkapnya tentang Kebijakan Grup dan entri terkait, lihat alat layanan Windows Time dan artikel Pengaturan di TechNet.

Pertimbangan IaaS Azure dan Windows

Berikut adalah beberapa poin yang perlu dipertimbangkan untuk infrastruktur sebagai layanan (IaaS) Azure dan Windows.

Komputer virtual Azure: Active Directory Domain Services

Jika Azure VM yang menjalankan Active Directory Domain Services adalah bagian dari forest Active Directory lokal yang ada, maka TimeSync (VMIC) harus dinonaktifkan. Tindakan ini memungkinkan semua DC di forest, baik fisik maupun virtual, untuk menggunakan hierarki sinkronisasi waktu tunggal. Untuk informasi selengkapnya, lihat Menjalankan pengontrol domain di Hyper-V.

Komputer virtual Azure: Komputer yang bergabung dengan domain

Jika Anda menghosting komputer yang bergabung dengan domain ke forest Direktori Aktif, virtual atau fisik yang ada, praktik terbaiknya adalah menonaktifkan TimeSync untuk tamu dan memastikan bahwa W32Time dikonfigurasi untuk disinkronkan dengan DC-nya melalui mengonfigurasi waktu untuk Type=NTP5.

Komputer virtual Azure: Komputer grup kerja mandiri

Jika Azure VM tidak bergabung ke domain, dan bukan DC, kami sarankan Anda menyimpan konfigurasi waktu default dan menyinkronkan VM dengan host.

Aplikasi Windows membutuhkan waktu yang akurat

Berikut adalah beberapa tindakan yang dapat Anda ambil jika aplikasi Windows Anda memerlukan waktu yang akurat.

API Stempel Waktu

Program yang memerlukan akurasi terbesar relatif terhadap UTC, dan bukan berlalunya waktu, harus menggunakan GetSystemTimePreciseAsFileTime API. Menggunakan API ini memastikan bahwa 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 mesin pemfilteran dasar port. Tindakan ini meningkatkan latensi dan meningkatkan throughput Anda. Namun, perubahan pada registri harus dibatasi pada administrator berpengalaman. Solusi ini mengecualikan port agar tidak diamankan oleh firewall. Untuk informasi selengkapnya, lihat referensi berikut ini.

Untuk Windows Server 2012 dan Windows Server 2008, Anda perlu menginstal perbaikan terlebih dahulu. Untuk informasi selengkapnya, lihat Kehilangan datagram saat Anda menjalankan aplikasi penerima multicast di Windows 8 dan di Windows Server 2012.

Memperbarui driver jaringan

Beberapa vendor jaringan memiliki pembaruan driver yang meningkatkan performa relatif terhadap latensi driver dan buffering paket UDP. 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 w32tm log, log peristiwa, dan informasi Monitor 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 dengan menggunakan penghitung Computed Time Offset Performance Monitor. Penghitung ini menunjukkan jam dalam akurasi yang diinginkan.
2. Sumber jam yang mencari Peer Response from di w32tm log. Mengikuti teks pesan adalah alamat IP atau VMIC, yang menjelaskan sumber waktu dan berikutnya dalam rantai jam referensi untuk divalidasi.
3. Status kondisi jam dengan menggunakan w32tm log untuk memvalidasi yang ClockDispl Discipline: \*SKEW\*TIME\* terjadi. Status ini menunjukkan bahwa w32tm aktif pada saat itu.

Pengelogan peristiwa

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

Pengelogan debug W32Time

Untuk mengaktifkan w32tm 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 Mengaktifkan pengelogan debug di layanan Windows Time.

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

Monitor Performa

Layanan Windows Server 2016 Windows Time mengekspos penghitung kinerja, yang dapat digunakan untuk mengumpulkan pengelogan untuk audit. Penghitung ini dapat dicatat secara lokal atau jarak jauh. Anda dapat merekam penghitung Offset Waktu Komputer dan Penundaan Pulang Pergi. Seperti penghitung kinerja apa pun, Anda dapat memantaunya dari jarak jauh dan membuat pemberitahuan dengan menggunakan Manajer Operasi Pusat Sistem. Misalnya, Anda dapat menggunakan pemberitahuan untuk membuat alarm saat Offset Waktu melayang dari akurasi yang diinginkan. Untuk informasi selengkapnya, lihat Paket Manajemen Pusat Sistem.

Contoh keterlacakan Windows

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

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

Poin utamanya adalah Anda melihat pesan yang diawali dengan ClockDispln Discipline, yang merupakan bukti bahwa 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. Informasi ini bisa berupa alamat IP, nama komputer, atau penyedia VMIC, yang menunjukkan bahwa itu disinkronkan dengan host untuk Hyper-V. Contoh berikut menyediakan alamat IPv4 10.197.216.105:

151802 20:18:54.6531515s - Response from 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. Proses ini berlanjut sampai Anda sampai ke jam fisik, seperti GPS, atau sumber waktu yang diketahui, seperti NIST. Jika jam referensi adalah perangkat keras GPS, log dari yang diproduksi mungkin juga diperlukan.

Pertimbangan jaringan

Algoritma protokol NTP memiliki dependensi pada simetri jaringan Anda. Saat Anda meningkatkan jumlah hop jaringan, kemungkinan asimetri meningkat. Untuk alasan ini, sulit untuk memprediksi jenis akurasi apa yang 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. Anda juga 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:

• Protokol Waktu Presisi - IEEE 1588(PTP): PTP memiliki persyaratan yang lebih ketat pada infrastruktur jaringan tetapi sering kali dapat memberikan akurasi submikrodetik.
• Protokol Waktu Jaringan – RFC 1305(NTP): NTP bekerja pada berbagai jaringan dan lingkungan yang lebih besar, yang membuatnya lebih mudah dikelola.

Windows mendukung NTP sederhana (RFC2030) secara default untuk komputer yang bergabung dengan nondomain. Untuk komputer yang bergabung dengan domain, kami menggunakan NTP aman yang disebut MS-SNTP, yang menggunakan rahasia yang dinegosiasikan domain yang memberikan keuntungan manajemen daripada NTP terautentikasi yang dijelaskan dalam RFC1305 dan RFC5905.

Protokol domain dan yang bergabung dengan nondomain memerlukan port UDP 123. Untuk informasi selengkapnya tentang praktik terbaik NTP, lihat Draf IETF Praktik Terbaik Protokol Waktu Jaringan Saat Ini.

Jam perangkat keras yang andal (RTC)

Windows tidak melangkah waktu, kecuali batas tertentu terlampaui, tetapi sebaliknya mendisiplinkan jam. Itu berarti w32tm menyesuaikan frekuensi jam pada interval reguler dengan menggunakan pengaturan Frekuensi Pembaruan Jam, yang default menjadi sekali detik dengan Windows Server 2016. Jika jam berada di belakang, itu mempercepat frekuensi. Jika di depan, itu memperlambat frekuensi. Namun, selama waktu antara penyesuaian frekuensi jam, jam perangkat keras memegang kendali. Jika ada masalah dengan firmware atau jam perangkat keras, waktu pada mesin bisa menjadi kurang akurat.

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

Memecahkan masalah akurasi waktu dan NTP

Anda dapat menggunakan bagian Temukan hierarki untuk memahami sumber waktu yang tidak akurat. Melihat offset waktu, temukan titik dalam hierarki di mana waktu paling berbeda dari sumber NTP-nya. Ketika Anda memahami hierarki, Anda ingin mencoba memahami mengapa sumber waktu tertentu tidak menerima waktu yang akurat.

Dengan berfokus pada sistem dengan waktu yang berbeda, Anda dapat menggunakan alat berikut untuk mengumpulkan informasi lebih lanjut untuk membantu Anda menentukan masalah dan menemukan resolusi. Referensinya UpstreamClockSource adalah jam yang ditemukan dengan menggunakan w32tm /config /status:

• Log peristiwa sistem
• Aktifkan pengelogan dengan menggunakan w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• kunci registri w32Time 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 stabil jam sinkronisasi, tetapi Anda masih melihat bahwa setiap 1-2 menit dari beberapa 100us.	Perbarui firmware atau validasi bahwa perangkat keras yang berbeda tidak menampilkan masalah yang sama.
Latensi jaringan.	Stripchart w32tm menampilkan RoundTripDelay lebih dari 10 mdtk. Variasi dalam penundaan dapat menyebabkan kebisingan sebesar setengah 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, dan Respons Keluar Server NTP dan tentukan penggunaan Anda dibandingkan dengan garis besar Anda.	Dengan menggunakan penghitung kinerja server, tentukan apakah beban berubah dalam 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 melayang.	Peristiwa Time-Service 36 dalam log peristiwa sistem dan/atau teks dalam file log yang menjelaskan bahwa penghitung Jumlah Sumber Waktu Klien NTP adalah dari 1 ke 0.	Pecahkan masalah sumber hulu dan pahami apakah mengalami masalah performa.

Waktu garis besar

Baselining penting agar Anda dapat memahami performa dan akurasi jaringan Anda dan kemudian membandingkannya dengan garis besar di masa mendatang ketika masalah terjadi. Anda ingin membuat garis besar PDC akar atau komputer apa pun yang ditandai dengan GTIMESRV. Kami juga menyarankan agar Anda menggaris bawahi PDC di setiap forest. Terakhir, 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 versus 2012 R2. Namun, Anda hanya memiliki w32tm /stripchart sebagai alat yang dapat Anda gunakan untuk membandingkan karena Windows Server 2012 R2 tidak memiliki penghitung kinerja. Anda harus memilih dua komputer dengan karakteristik yang sama atau meningkatkan mesin dan membandingkan hasilnya setelah pembaruan. Addendum 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. Data ini memastikan bahwa Anda memiliki cukup referensi untuk memperhitungkan variasi dalam 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 mesin yang bergabung dengan nondomain 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 bahwa semua sumber akurat dan stabil. Namun, jika topologi tidak dirancang dengan baik atau sumber waktu tidak stabil, akurasi yang dihasilkan bisa lebih buruk, jadi hati-hati disarankan. Batas server waktu yang didukung yang dapat dirujuk W32Time secara manual adalah 10.

Detik lompatan

Periode rotasi bumi bervariasi dari waktu ke waktu karena peristiwa iklim dan geologis. Biasanya, variasinya sekitar satu detik setiap dua tahun. Setiap kali variasi dari waktu atom tumbuh terlalu besar, koreksi satu detik (atas atau bawah) dimasukkan, yang disebut lompatan detik. Penyisipan 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 masalah 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.

Untuk menonaktifkan fitur:

1. Gunakan Kebijakan Grup untuk mengelola SecureTimeSeeding. Lihat bagian yang mengacu pada pengaturan UtilizeSslTimeData: Pelajari: Kebijakan CSP - ADMX_W32Time.

2. Atau, Anda dapat mengatur nilai registri secara manual. Atur UtilizeSSLTimeData nilai konfigurasi registri ke 0 pada komputer tertentu:

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

3. Jika Anda tidak dapat segera me-reboot komputer, Anda dapat memberi tahu W32Time tentang pembaruan konfigurasi. Pemberitahuan ini menghentikan pemantauan dan penerapan waktu berdasarkan data waktu yang dikumpulkan dari koneksi SSL.

   W32tm.exe /config /update
   

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

5. Untuk menerapkan pengaturan ini di seluruh domain, atur UtilizeSSLTimeData nilai dalam pengaturan Kebijakan Grup W32Time ke 0 dan terbitkan pengaturan. Ketika pengaturan diambil oleh klien Kebijakan Grup, W32Time diberi tahu dan menghentikan pemantauan dan penerapan waktu dengan menggunakan data waktu SSL. Pengumpulan data waktu SSL 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 akhirnya menghadapi pengurasan baterai dan membutuhkan fitur Secure Time Seeding untuk bootstrap waktu mereka.