وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

اختلاف ساعت ویندوز سرور عضو دامنه در ماشین مجازی؛ رفع مشکل قدم‌به‌قدم

آموزش بررسی W32Time، منبع ساعت دامنه، DNS و UDP 123 برای رفع اختلاف ساعت ویندوز سرور مجازی.

انتشار:
توسط تیم فنی نت‌آرام
۶ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله اختلاف ساعت ویندوز سرور عضو دامنه در ماشین مجازی؛ رفع مشکل قدم‌به‌قدم در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
روی سرور مجازی ایران ساعت ویندوز با کنترلر دامنه فرق دارد، ورود دامنه گاهی خطا می‌دهد یا برنامه‌ای زمان فایل‌ها را اشتباه ثبت می‌کند. اختلاف ساعت واقعی می‌تواند احراز هویت Kerberos و کار سرویس‌ها را مختل کند؛ تفاوت منطقه زمانی نمایش ساعت نیز ظاهری شبیه آن می‌سازد، بدون اینکه زمان UTC اشتباه باشد.
در این راهنما یک Windows Server عضو دامنه را بررسی می‌کنیم؛ یعنی سروری که خود Domain Controller نیست. منبع ساعت، DNS، ارتباط شبکه و اثر میزبان مجازی را جداگانه می‌سنجیم. کنترلر دامنه و به‌ویژه PDC ریشه جنگل نقش متفاوتی دارند و نباید دستور تنظیم عضو دامنه را بی‌فکر روی آن‌ها اجرا کرد. اگر سرور مستقل و خارج از دامنه است، این روش انتخاب منبع برای آن مناسب نیست.

۱. اول تفاوت منطقه زمانی و اختلاف واقعی را جدا کنید

با Remote Desktop یا کنسول وارد سرور شوید. PowerShell را باز کنید و این دو دستور را اجرا کنید:
کد / دستورGet-Date -Format 'yyyy-MM-dd HH:mm:ss zzz' tzutil /g
دستور اول ساعت محلی و اختلاف آن با UTC را نشان می‌دهد؛ دومی نام منطقه زمانی تنظیم‌شده را می‌گوید. ساعت سرور و کنترلر را با درنظرگرفتن منطقه زمانی و همان لحظه مقایسه کنید. دو دستگاه در مناطق متفاوت می‌توانند ساعت نمایشی متفاوت ولی زمان UTC یکسان داشته باشند. اگر فقط منطقه زمانی اشتباه است، با مدیر سیستم درباره منطقه مورد نیاز هماهنگ کنید و از تنظیم دستی ساعت به‌عنوان درمان مشکل همگام‌سازی پرهیز کنید.
برای دیدن وضعیت عضویت، دستور زیر را اجرا کنید:
کد / دستورGet-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain, DomainRole
PartOfDomain باید برای عضو دامنه True باشد. DomainRole در سرور عضو معمولاً ۳ است؛ مقدار ۴ یا ۵ نشان‌دهنده کنترلر دامنه است و باید از راهنمای جداگانه آن استفاده کرد. اگر اطلاعات با انتظار شما سازگار نیست، قبل از تغییر منبع ساعت نقش سرور را روشن کنید.

۲. منبع فعلی و وضعیت سرویس ساعت را بخوانید

PowerShell را با گزینه Run as administrator باز کنید:
کد / دستورGet-Service W32Time w32tm /query /source w32tm /query /status /verbose w32tm /query /configuration
سرویس باید برای همگام‌سازی در حال اجرا باشد. خروجی source می‌گوید ساعت فعلاً از کجا می‌آید. نام یک کنترلر دامنه می‌تواند طبیعی باشد؛ Local CMOS Clock ممکن است نشان دهد منبع معتبر در دسترس نیست یا ساعت هنوز با منبع خارجی همگام نشده است. به زمان آخرین همگام‌سازی و خطاهای وضعیت نگاه کنید؛ یک نام درست به‌تنهایی ثابت نمی‌کند که همگام‌سازی اخیراً موفق بوده است. تنظیم‌های Effective در configuration و منبع آن‌ها ممکن است از Group Policy بیایند.
برای دیدن رویدادها:
کد / دستورGet-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Time-Service'; StartTime=(Get-Date).AddDays(-2)} -MaxEvents 30 | Format-List TimeCreated, Id, Message
اگر در این بازه رویدادی نباشد ممکن است دستور پیامی برگرداند؛ بازه را متناسب با زمان مشکل انتخاب کنید. به زمان، نام منبع و پیام کامل توجه کنید. لاگ ممکن است نام داخلی شبکه داشته باشد، پس هنگام ارسال آن اطلاعات حساس را حذف کنید.

۳. دسترسی به دامنه و منبع ساعت را بررسی کنید

در PowerShell نام دامنه واقعی را به‌جای نمونه وارد کنید:
کد / دستورnltest /dsgetdc:example.local Resolve-DnsName example.local w32tm /query /peers
دستور اول تلاش می‌کند کنترلر دامنه مناسب را پیدا کند. اگر پیدا نمی‌شود، ابتدا DNS و ارتباط دامنه را اصلاح کنید؛ تنظیم یک NTP عمومی روی تک‌تک اعضا جایگزین سلامت دامنه نیست. خروجی DNS را با تنظیمات مورد تأیید مدیر شبکه مقایسه کنید. دستور سوم peers شناخته‌شده را نشان می‌دهد؛ در مراحل ابتدایی یا تنظیم خاص ممکن است فهرست خالی باشد.
اگر کنترلر مشخصی در دسترس است، نام واقعی آن را جایگزین کنید:
کد / دستورw32tm /stripchart /computer:dc01.example.local /samples:5 /dataonly
این دستور پنج نمونه اختلاف را درخواست می‌کند. پاسخ‌ها به تشخیص دسترسی کمک می‌کنند، اما یک آزمون موفق لزوماً مسیر عملیاتی سرویس W32Time را ثابت نمی‌کند؛ روش استفاده از پورت مبدأ ممکن است متفاوت باشد. NTP از UDP استفاده می‌کند؛ آزمایش TCP پورت ۱۲۳ با Test-NetConnection اثبات بازبودن UDP نیست. اگر timeout گرفتید، نام و DNS را کنترل و با مدیر شبکه مسیر UDP و فایروال را بررسی کنید. راهنمای Microsoft درباره نبود داده ساعت چند علت و روش تفکیک آن‌ها را توضیح می‌دهد.

۴. اگر منبع عضو دامنه اشتباه تنظیم شده است

ابتدا w32tm /query /configuration و تنظیم Group Policy را ثبت کنید. اگر سیاست سازمان منبع مشخصی را الزام می‌کند، با مدیر دامنه هماهنگ شوید؛ تغییر محلی ممکن است بعداً دوباره با سیاست جایگزین شود. اگر تأیید شده این ماشین یک عضو دامنه معمولی است و باید طبق سلسله‌مراتب دامنه همگام شود، در PowerShell مدیر اجرا کنید:
کد / دستورw32tm /config /syncfromflags:domhier /update w32tm /resync /rediscover w32tm /query /source w32tm /query /status
دستور نخست انتخاب منبع را به سلسله‌مراتب دامنه برمی‌گرداند؛ دومی منبع را دوباره پیدا می‌کند و درخواست همگام‌سازی می‌دهد. دو دستور آخر نتیجه را می‌خوانند. اگر سرویس متوقف است، علت توقف و سیاست سازمان را بررسی و در صورت مجازبودن Start-Service W32Time را اجرا کنید. اگر پیام نبود داده ساعت دریافت شد، چند بار تکرار فرمان درمان نیست؛ به بررسی DNS، UDP و وضعیت کنترلر برگردید.
بازگشت به تنظیم قبلی نیازمند ثبت دقیق configuration و سیاست پیشین است. اگر برنامه‌ای به زمان بسیار دقیق یا تغییرناپذیر وابسته است، پیش از هر اصلاح بزرگ ساعت با مسئول آن هماهنگ کنید؛ جهش ناگهانی ساعت می‌تواند روی زمان‌بندی، لاگ و احراز هویت اثر بگذارد. پاک‌کردن کل تنظیمات W32Time یا تغییر رجیستری اولین قدم این عیب‌یابی نیست.

۵. نقش میزبان مجازی را بررسی کنید

اگر بعد از روشن‌شدن، بازگشت snapshot یا انتقال ماشین ساعت دوباره می‌پرد، زمان رخداد و source را یادداشت کنید و تنظیم همگام‌سازی میزبان و مهمان را با مدیر مجازی‌سازی بررسی کنید. رفتار VMware، Hyper-V و سرویس‌های ابری یکسان نیست و گزینه‌های همگام‌سازی هنگام راه‌اندازی یا بازیابی می‌توانند متفاوت باشند. خاموش‌کردن کورکورانه همه راه‌های همگام‌سازی ممکن است مشکل را بدتر کند.
برای عضو دامنه، مستند Microsoft درباره Windows Time استفاده از سلسله‌مراتب دامنه را توضیح می‌دهد. کنترلرهای دامنه مجازی و PDC ریشه تنظیمات و ملاحظات ویژه خودشان را دارند؛ منبع مرجع و سیاست زمان کل دامنه باید توسط مدیر Active Directory تعیین شود.

۶. تأیید کنید مشکل واقعاً رفع شده است

چند دقیقه بعد، w32tm /query /status و w32tm /query /source را دوباره بخوانید: منبع باید با طراحی شبکه سازگار و زمان آخرین همگام‌سازی تازه باشد. اختلاف را با کنترلر معتبر مقایسه و ورود دامنه و برنامه‌ای را که خطا می‌داد امتحان کنید. پس از یک بازراه‌اندازی برنامه‌ریزی‌شده نیز دوباره بررسی کنید. اگر ساعت دوباره تغییر کرد، زمان رخداد را با لاگ W32Time و عملیات میزبان تطبیق دهید؛ در صورت ناسالم بودن منبع بالادستی، رفع تنظیم عضو به‌تنهایی کافی نیست.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام