محتوای آموزشی وبلاگ نت‌آرام
روی سرور مجازی ایران جست‌وجوی به‌روزرسانی شکست می‌خورد و خطای
0x80244022 دیده می‌شود. این کد با پاسخ HTTP 503 یا در دسترس نبودن موقت سرویس ارتباط دارد. بااین‌حال مشخص نمی‌کند پاسخ را خود WSUS، یک پراکسی یا بخش دیگری از مسیر داده است؛ برای حل واقعی باید منبع آپدیت و نقطه اختلال را پیدا کنیم.سرورهای سازمانی ممکن است به‌جای Microsoft Update از WSUS یا ابزار مدیریت سازمان استفاده کنند. تغییر بی‌برنامه این سیاست، دریافت آپدیت‌ها را از مسیر تأییدشده خارج می‌کند. ابتدا فقط تنظیم و ارتباط را می‌خوانیم، سپس بسته به نتیجه از مسئول شبکه یا سرور WSUS برای اصلاح بخش درست کمک می‌گیریم.
۱. زمان خطا و منبع به‌روزرسانی را ثبت کنید
در سرور ویندوز، PowerShell را با Run as administrator باز کنید:
کد / دستورGet-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-Service wuauserv, bits | Select-Object Name, Status, StartType
نسخه و build را کنار زمان دقیق خطا یادداشت کنید. وضعیت سرویس‌ها تصویر همان لحظه است؛ متوقف‌بودن یک سرویس با شروع دستی الزاماً علت اصلی نیست. در Settings و Update history ببینید خطا هنگام جست‌وجو، دانلود یا نصب رخ داده است. اگر شماره KB نیز مشخص است آن را ثبت کنید.
برای خواندن سیاست محلی تنظیم‌شده، بدون تغییر آن:
کد / دستورGet-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue | Select-Object WUServer, WUStatusServer
Get-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -ErrorAction SilentlyContinue | Select-Object UseWUServer
اگر کلید یا مقدار وجود ندارد خروجی ممکن است خالی باشد. وجود یک آدرس WSUS در این کلید به‌تنهایی ثابت نمی‌کند همه انواع اسکن در همه نسخه‌ها از همان منبع انجام می‌شوند؛ سیاست دامنه، Configuration Manager یا تنظیم منبع اسکن نیز می‌تواند نقش داشته باشد. راهنمای Microsoft برای سیاست Windows Update ساختار این تنظیم‌ها را توضیح می‌دهد. مقدار را حذف یا به منبع عمومی تغییر ندهید مگر مدیر سیاست سازمان تصمیم گرفته باشد.
۲. مسیر شبکه به همان منبع را امتحان کنید
اگر منبع شما مثلاً
کد / دستورwsus.example.local با پورت 8530 است، نام و پورت واقعی را از سیاست یا مدیر شبکه جایگزین کنید:Resolve-DnsName wsus.example.local
Test-NetConnection wsus.example.local -Port 8530
netsh winhttp show proxy
اولی نام را به نشانی تبدیل می‌کند. اگر پاسخ DNS نادرست است، تنظیم DNS مورد تأیید دامنه و دسترسی به آن را بررسی کنید. دومی فقط برقراری TCP به پورت نمونه را می‌آزماید؛
TcpTestSucceeded: True ثابت نمی‌کند سرویس WSUS یا اسکن آپدیت سالم است. فرمان سوم پراکسی WinHTTP را نشان می‌دهد؛ ممکن است اطلاعات شبکه داخلی در خروجی باشد. پورت 8530 مثال HTTP متداول WSUS است، نه پورت تضمینی همه محیط‌ها؛ در HTTPS اغلب پورت دیگری تنظیم می‌شود.اگر TCP وصل نمی‌شود، آدرس، پورت، مسیر، فایروال و در دسترس بودن سرور مقصد را با مسئول شبکه بررسی کنید. اگر اتصال برقرار است اما درخواست واقعی 503 می‌گیرد، بررسی سرویس، پراکسی و ظرفیت سمت مقصد را ادامه دهید. هرگز برای حل این خطا تمام فایروال یا بررسی گواهی TLS را خاموش نکنید.
۳. اگر از WSUS استفاده می‌کنید
از مدیر WSUS بخواهید در همان زمان خطا وضعیت IIS، سرویس Update Services، فضای دیسک و رویدادهای Application و System را بررسی کند. در خود سرور WSUS و در PowerShell مدیر، اگر ابزار IIS نصب است:
کد / دستورGet-Service WsusService, W3SVC
Import-Module WebAdministration
Get-WebAppPoolState -Name WsusPool
نام pool ممکن است در محیط سفارشی فرق کند. اگر
WsusPool متوقف است، خطای WAS/IIS و علت توقف را بخوانید. پس از رفع علت و در پنجره مورد تأیید، مدیر WSUS می‌تواند از IIS Manager در بخش Application Pools، pool درست را Start کند. اگر دوباره متوقف می‌شود، شروع مکرر درمان نیست؛ بار، حافظه، محدودیت pool و گزارش خطا باید بررسی شوند.برای تشخیص دسترسی به یک فایل آزمایشی WSUS، Microsoft در برخی سناریوها نشانی
http://WSUS:8530/Selfupdate/wuident.cab را معرفی می‌کند. آن را فقط با نام، scheme و پورت واقعی محیط خود و در مرورگر یا ابزار سازمانی امتحان کنید. موفقیت دانلود یک فایل به‌تنهایی سلامت همه APIها، گواهی‌ها یا فرایند اسکن را اثبات نمی‌کند. راهنمای عیب‌یابی ارتباط WSUS خطاهای مختلف و بخش‌های مربوط را شرح می‌دهد.گاهی 503 به فشار زیاد یا محدودیت حافظه application pool مربوط است. Microsoft برای برخی محیط‌ها تنظیم‌های pool را توضیح داده، اما افزایش بی‌حساب یا حذف سقف حافظه روی سروری با منابع کم می‌تواند سرویس‌های دیگر را مختل کند. ابتدا علت recycle و ظرفیت واقعی را بسنجید و مقدار مناسب همان محیط را با ثبت مقدار قبلی تغییر دهید. پاک‌کردن پایگاه داده WSUS یا نصب دوباره نقش اولین راه‌حل نیست.
۴. اگر منبع Microsoft Update یا پراکسی است
با مسئول شبکه وضعیت مسیر و پراکسی را در زمان خطا بررسی کنید. صفحه خطای 503 ممکن است از واسطه شبکه آمده باشد؛ لاگ پراکسی و مقصد واقعی مشخص می‌کند کدام جزء پاسخ داده است. احراز هویت تعاملی پراکسی ممکن است برای سرویس سیستمی قابل استفاده نباشد. تنظیم مسیر تأییدشده برای حساب و سرویس مربوطه بهتر از واردکردن رمز شخصی در دستور یا غیرفعال‌کردن پراکسی سازمان است.
اگر چند سرور هم‌زمان همان خطا را دارند، مقایسه منبع و زمان آن‌ها می‌تواند علت مشترک را نشان دهد. اگر فقط یک سرور مشکل دارد، تفاوت DNS، پراکسی، سیاست و مسیر آن را با سرور سالم مقایسه کنید. تغییر رجیستری یا پاک‌کردن پوشه SoftwareDistribution بدون شواهد، پاسخ 503 سرور مقابل را تعمیر نمی‌کند.
۵. دوباره اسکن کنید و نتیجه را تأیید کنید
پس از اصلاح مسیر یا سرویس، در پنجره Windows Update دوباره Check for updates را اجرا کنید و تا پایان اسکن منتظر بمانید. از میان آپدیت‌های مجاز، نتیجه دانلود و نصب را نیز در پنجره نگه‌داری بررسی کنید؛ یک TCP موفق به معنی نصب موفق نیست. در محیط WSUS، گزارش وضعیت client و لاگ همان بازه را هم ببینید.
اگر کد عوض شد، متن و مرحله جدید را جدا تحلیل کنید. برای نمونه، خطای
0x800f0922 هنگام نصب مسئله متفاوتی است و راهنمای خطای 0x800f0922 به لاگ CBS می‌پردازد. برای پیگیری، زمان، منبع، پاسخ DNS، نتیجه TCP و پیام دقیق را بدون رمز یا نشانی محرمانه ثبت کنید.اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام