محتوای آموزشی وبلاگ نت‌آرام
Windows Update روی سرور مجازی ایران می‌گوید برای تکمیل به‌روزرسانی باید سیستم دوباره راه‌اندازی شود. گاهی نصب برنامه دیگری هم تا انجام ریبوت متوقف می‌ماند. در بیشتر مواقع این پیام طبیعی است: بخشی از تغییر باید هنگام خاموش و روشن‌شدن ویندوز انجام شود. اما اگر بعد از یک ریبوت کامل همچنان پیام برگردد، ممکن است عملیات دیگری در صف باشد یا نصب قبلی کامل نشده باشد.
از پاک‌کردن نشانگرهای رجیستری برای ناپدیدشدن پیام خودداری کنید؛ پنهان‌کردن علامت الزاماً کار ناتمام را کامل نمی‌کند. ابتدا زمان ریبوت را با نیاز سرویس هماهنگ می‌کنیم، بعد وضعیت و لاگ همان آپدیت را می‌خوانیم.
۱. معلوم کنید چه کاری منتظر راه‌اندازی مجدد است
با حساب مدیر وارد کنسول یا Remote Desktop شوید. در Settings، بخش Windows Update و Update history را باز کنید و شماره KB، وضعیت و زمان آخرین تلاش را یادداشت کنید. اگر نصب‌کننده برنامه دیگری پیام داده، نام آن را نیز ثبت کنید؛ همه پیام‌های restart pending از یک جزء نیستند. در محیط سازمانی ممکن است WSUS یا ابزار مدیریت، زمان ریبوت را کنترل کند؛ ابتدا سیاست همان محیط را بدانید.
در PowerShell مدیر اطلاعات نسخه و آخرین بوت را بخوانید:
کد / دستورGet-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, InstalledOn
زمان آخرین بوت را با زمان نصب مقایسه کنید. اگر بعد از نصب هنوز بوت جدیدی نداشته‌اید، پیام منتظر ریبوت احتمالاً طبیعی است. فهرست
Get-HotFix همه وضعیت‌های ممکن بسته‌ها را کامل نشان نمی‌دهد؛ نتیجه را همراه Update history و لاگ بخوانید.۲. پیش از ریبوت، سرویس و بازیابی را آماده کنید
زمانی را انتخاب کنید که اختلال برای کاربران کم باشد. از آن‌ها بخواهید کارهای باز را ذخیره کنند و اگر پایگاه داده، فروشگاه یا نرم‌افزار حساس دارید، مسئول آن روش توقف و بررسی پس از بوت را مشخص کند. از بکاپ قابل بازیابی و دسترسی کنسول پنل مطمئن شوید؛ اگر بعد از ریبوت RDP بالا نیامد، کنسول برای دیدن وضعیت لازم است.
فضای درایو ویندوز و وضعیت سرویس‌ها را بخوانید:
کد / دستورGet-Volume | Select-Object DriveLetter, FileSystemLabel, SizeRemaining, Size
Get-Service wuauserv, trustedinstaller | Select-Object Name, Status, StartType
درایو ویندوز باید فضای کافی برای عملیات update و فایل‌های موقت داشته باشد. مقدار مناسب به همان بسته و شرایط سرور بستگی دارد. TrustedInstaller می‌تواند در حالت عادی شروع دستی داشته و در آن لحظه متوقف باشد؛ صرف این وضعیت دلیل خرابی نیست. اگر سیستم هم‌اکنون در حال نصب یا بازگردانی تغییرات است، اجازه دهید کار کامل شود و برق یا ماشین را به‌زور قطع نکنید.
۳. یک ریبوت کنترل‌شده انجام دهید
در پنجره هماهنگ‌شده، از منوی Start گزینه Restart را انتخاب کنید یا در PowerShell مدیر اجرا کنید:
کد / دستورRestart-Computer
این فرمان اتصال شما و کاربران را قطع می‌کند. از کنسول پیشرفت را ببینید؛ ممکن است سرور پیش از ورود، تنظیم آپدیت را تکمیل کند یا در صورت شکست تغییرات را برگرداند. زمان انجام عملیات به حجم تغییر و سرعت ذخیره‌سازی بستگی دارد. اگر مدت طولانی بدون پیشرفت مانده، پیش از خاموش‌کردن اجباری، وضعیت storage، کنسول و برنامه بازیابی را با مدیر سیستم بررسی کنید.
پس از بالا آمدن،
LastBootUpTime را دوباره ببینید، وارد Windows Update شوید و وضعیت همان KB و سرویس‌های حیاتی را بررسی کنید. اگر پیام برطرف شده و سرویس‌ها سالم‌اند، کار تمام است. اگر آپدیت دیگری تازه نصب شده، ممکن است یک درخواست ریبوت جدید مربوط به آن باشد؛ زمان و شماره KB را از هم جدا کنید.۴. اگر پس از ریبوت همچنان پیام باقی است
در Event Viewer مسیر Applications and Services Logs، سپس Microsoft، Windows، WindowsUpdateClient و Operational را باز کنید. رویدادهای زمان نصب و ریبوت را بخوانید. گزارش سیستم و Application را نیز برای خطاهای همان زمان بررسی کنید. برای جست‌وجوی یک کد مشخص در CBS، PowerShell مدیر را باز کنید:
کد / دستورSelect-String -Path "$env:windir\Logs\CBS\CBS.log" -Pattern '0x80070bc9','reboot required','failed' | Select-Object -Last 40
این فقط فهرستی از خط‌های مطابق را نشان می‌دهد. یک خط قدیمی یا عبارت عمومی
failed بدون ارتباط زمانی تشخیص قطعی نیست. متن اطراف زمان حادثه و شناسه بسته را باز کنید. خروجی ممکن است اطلاعات داخلی داشته باشد؛ قبل از اشتراک‌گذاری آن را پاک‌سازی کنید. برای ساخت WindowsUpdate.log خوانا در نسخه‌های پشتیبان می‌توانید از Get-WindowsUpdateLog استفاده کنید؛ تولید فایل و مسیر خروجی را مطابق نسخه خود بررسی کنید.۵. راهکار را مطابق خطای پیدا‌شده انتخاب کنید
اگر خطا به سرویس TrustedInstaller و سیاست دامنه اشاره می‌کند، تنظیم آن را در Group Policy با مدیر سازمان بررسی کنید. Microsoft توضیح می‌دهد که در یک سناریوی مشخص، سیاستی که نوع شروع سرویس را قبل از ریبوت به مقدار نامناسب برمی‌گرداند می‌تواند تکمیل تراکنش را مختل کند. دستور سراسری تغییر سرویس برای همه سرورها مناسب نیست؛ ابتدا لاگ و سیاست واقعی را تطبیق دهید.
اگر CBS خطای
0x80070bc9 همراه با شواهد خرابی وضعیت servicing نشان می‌دهد، ممکن است شرایط خاصی مانند خرابی مؤلفه‌های تراکنش وجود داشته باشد. راهنمای Microsoft برای 0x80070BC9 پیش‌نیاز بکاپ و مسیر تعمیر متناسب با آن سناریو را شرح می‌دهد. پاک‌کردن دستی کلیدهای pending یا پوشه‌های سیستمی جای این تشخیص را نمی‌گیرد.اگر مسئله کمبود منبع تعمیر DISM است، راهنمای خطای 0x800f081f کمک می‌کند منبع متناسب با نسخه سیستم پیدا شود. اگر خطای نصب
0x800f0922 است، راهنمای اختصاصی آن را ببینید. کد و مرحله خطا تعیین می‌کنند کدام مسیر مناسب است.۶. تأیید نهایی و پیشگیری
پس از رفع علت و هر ریبوت لازم، وضعیت همان KB، زمان آخرین بوت و رویدادهای جدید را بررسی کنید. سپس سرویس وب، پایگاه داده، ورود و سایر کارهای مهم سرور را با آزمایش واقعی بسنجید. اگر یک ابزار مدیریت سازمانی گزارش جداگانه دارد، وضعیت آن را هم با سرور مقایسه کنید.
برای نوبت‌های بعد، زمان نگه‌داری مشخص، اعلان به کاربران و بررسی پس از بوت داشته باشید. سرور را صرفاً برای پاک‌کردن یک پیام بارها ریبوت نکنید. Microsoft نیز در راهنمای reboot pending نسبت به حذف دستی نشانگرهای رجیستری هشدار می‌دهد.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام