رفع خطای Windows Update 0x8024402c در Windows Server؛ عیب‌یابی DNS، Proxy و WSUS

خطای Windows Update 0x8024402C در Windows Server معمولاً یعنی نام سرور مقصد یا Proxy قابل Resolve نیست. مایکروسافت این کد را WU_E_PT_WINHTTP_NAME_NOT_RESOLVED می‌نامد. برای رفع اصولی، ابتدا مشخص کنید سرور از Windows Update عمومی استفاده می‌کند یا WSUS سازمانی؛ سپس DNS، WinHTTP Proxy، Group Policy و اتصال به مقصد واقعی را بررسی کنید. پاک‌کردن پوشه SoftwareDistribution یا Reset کردن مؤلفه‌های Update بدون تشخیص علت، قدم اول مناسبی نیست.

خطای 0x8024402C چیست و چه زمانی رخ می‌دهد؟

این خطا ممکن است هنگام Check for updates، دریافت بسته امنیتی یا نصب Feature on Demand دیده شود. لزوماً به معنی خرابی فایل‌های سیستم نیست؛ ممکن است نام WSUS داخلی، Proxy یا سرور مایکروسافت پیدا نشود. مستند رسمی مایکروسافت درباره 0x8024402C همین معنی را تأیید می‌کند.

سناریو: Windows Server 2022 پس از تغییر DNS یا شبکه، به‌روزرسانی دریافت نمی‌کند. این مسیر عیب‌یابی برای Windows Server 2019، 2022 و 2025 نیز کاربرد دارد؛ هرچند جزئیات رابط کاربری و رفتار سرویس در نسخه‌ها متفاوت است.

پیش‌نیازها و هشدارهای امنیتی

• PowerShell را با Run as administrator باز کنید و نام سرور، IP، Gateway، DNS و زمان خطا را ثبت کنید.
• مشخص کنید سرور عضو Domain است و Policy آن از WSUS استفاده می‌کند یا مستقیماً از Windows Update.
• قبل از تغییر DNS، Proxy یا GPO روی سرور Production، دسترسی Console خارج از RDP و برنامه Rollback داشته باشید.
• روی Domain Controller، DNS را بدون بررسی رکوردهای Active Directory به DNS عمومی تغییر ندهید.

مرحله اول: کد خطا و شواهد را از Windows Update Log جمع کنید

Event Log را بررسی کنید تا کد دقیق، زمان و نام مقصد را پیدا کنید. اگر کانال Operational وجود نداشت یا خالی بود، از Event Viewer و فایل لاگ تولیدشده کمک بگیرید.

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 30 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Format-List

Get-WindowsUpdateLog -LogPath "$env:TEMP\WindowsUpdate.log"

دستور دوم در نسخه‌های جدید Windows برای تبدیل Trace به فایل قابل‌خواندن استفاده می‌شود و ممکن است به منابع تکمیلی نیاز داشته باشد. در لاگ به‌دنبال 0x8024402C، نام Proxy، DNS یا WSUS بگردید. اگر کد دیگری ثبت شده است، راهکار را با همان کد تطبیق دهید.

مرحله دوم: مسیر Windows Update یا WSUS را مشخص کنید

پیش از تست اینترنت، تنظیمات Policy را فقط بخوانید. مقدار WUServer نشانی WSUS را مشخص می‌کند و UseWUServer وضعیت استفاده از سرویس داخلی برای Automatic Updates را نشان می‌دهد. نبود این مقادیر در سروری که از Windows Update عمومی استفاده می‌کند طبیعی است.

$wu = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
Get-ItemProperty -Path $wu -ErrorAction SilentlyContinue |
  Select-Object WUServer, WUStatusServer

Get-ItemProperty -Path "$wu\AU" -ErrorAction SilentlyContinue |
  Select-Object UseWUServer

gpresult /scope computer /r

اگر آدرس WSUS به نام قدیمی اشاره می‌کند، تنظیم را از GPO اصلی بررسی کنید؛ تغییر دستی Registry با Refresh شدن Policy ممکن است برگردد. برای تشخیص مشکلات جداگانه خواندن GPO، راهنمای Group Policy Event ID 1058 و SYSVOL را ببینید.

مرحله سوم: DNS و دسترسی TCP را برای مقصد واقعی آزمایش کنید

اول تنظیمات شبکه را ثبت کنید. نام wsus.example.local و پورت‌های زیر فقط مثال‌اند؛ نام و پورت واقعی را از Policy یا لاگ جایگزین کنید.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4

Resolve-DnsName -Name wsus.example.local
Test-NetConnection -ComputerName wsus.example.local -Port 8530

خروجی موفق Resolve-DnsName باید رکورد A/AAAA معتبر نشان دهد. خطای Name does not exist یا Timeout به بررسی Zone، Forwarder و DNS Client نیاز دارد. اگر نام Resolve می‌شود اما TcpTestSucceeded : False است، Firewall، Route، وضعیت WSUS یا پورت را بررسی کنید؛ 8530/8531 پورت‌های متداول‌اند، نه تضمین پیکربندی شما.

اگر سرور مستقیماً به سرویس عمومی Microsoft وصل می‌شود، Hostname واقعی مشاهده‌شده در لاگ را تست کنید. نمونه زیر صرفاً یک بررسی اولیه است و سلامت تمام Endpointهای Windows Update را اثبات نمی‌کند:

Resolve-DnsName -Name download.windowsupdate.com
Test-NetConnection -ComputerName download.windowsupdate.com -Port 443

اگر مشکل DNS در همه سرویس‌ها دیده می‌شود، آموزش عیب‌یابی DNS Server، Forwarder و Client در Windows Server کمک می‌کند علت عمومی را از خطای مخصوص Update جدا کنید.

مرحله چهارم: WinHTTP Proxy و Proxy مرورگر را مقایسه کنید

سرویس‌های سیستمی ممکن است از تنظیماتی متفاوت از مرورگر استفاده کنند؛ بازشدن سایت در مرورگر به‌تنهایی کافی نیست. بدون تغییر تنظیمات، وضعیت WinHTTP و Proxy کاربر را بخوانید:

netsh winhttp show proxy

Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyEnable,ProxyServer -ErrorAction SilentlyContinue |
  Select-Object ProxyEnable,ProxyServer

اگر نام Proxy قدیمی یا غیرقابل Resolve است، همان نام را با Resolve-DnsName بررسی و تنظیم را مطابق سیاست سازمان اصلاح کنید. اجرای کورکورانه netsh winhttp reset proxy ممنوع است: در شبکه‌ای که Proxy الزامی است، سرویس‌های دیگر را قطع می‌کند. ابتدا مقدار قبلی را ثبت و روش بازگردانی آن را آماده کنید.

مرحله پنجم: اگر WSUS دارید، سرویس و IIS را بررسی کنید

روی سرور WSUS، سرویس Update Services و IIS را بررسی کنید؛ روی کلاینت، به همان Hostname و پورت تنظیم‌شده متصل شوید. از راهنمای رسمی GPO برای WSUS برای تأیید نشانی سرور داخلی استفاده کنید.

# On the WSUS server:
Get-Service -Name WsusService,W3SVC -ErrorAction SilentlyContinue |
  Select-Object Name,Status,StartType

# On the affected client; use the configured port:
Test-NetConnection -ComputerName wsus.example.local -Port 8531

اگر DNS درست است ولی TCP برقرار نیست، Firewall بین کلاینت و WSUS، Binding وب‌سایت IIS، سرویس مقصد و لاگ‌های IIS را بررسی کنید. برای رفع سریع مشکل، TLS یا اعتبارسنجی گواهی را غیرفعال نکنید.

مرحله ششم: اصلاح محدود و قابل بازگشت انجام دهید

• DNS مقصد Resolve نمی‌شود: رکورد، Zone، Forwarder یا DNS Client را در محل درست اصلاح کنید؛ IPهای DNS را تصادفی عوض نکنید.
• Proxy اشتباه است: نام و پورت Proxy را در Policy یا تنظیم مدیریت‌شده تصحیح کنید؛ قبل از هر تغییر مقدار قبلی را ذخیره کنید.
• WSUS قدیمی است: آدرس WUServer و پورت را در GPO معتبر اصلاح کنید و پس از هماهنگی Policy را Refresh کنید.
• DNS درست ولی اتصال TCP ناموفق است: مسیر شبکه، Firewall، سرویس مقصد و TLS را جداگانه عیب‌یابی کنید؛ همه پورت‌ها را باز نکنید.

اگر Windows Server روی VPS قرار دارد و کنترل DNS، مسیر خروجی، Proxy یا دسترسی کنسول برایتان مهم است، هنگام انتخاب زیرساخت، سطح دسترسی و مدیریت شبکه را در پلن‌های سرور مجازی وان‌سرور بررسی کنید. این پیشنهاد فقط برای تصمیم درباره امکانات زیرساخت است؛ تهیه VPS جدید به‌خودی‌خود خطای DNS یا WSUS سرور فعلی را رفع نمی‌کند.

Verify: از کجا بفهمیم خطا واقعاً رفع شده است؟

پس از اصلاح، Resolve و اتصال TCP به مقصد واقعی را تکرار کنید. سپس از Windows Update یک Check for updates انجام دهید و رویدادهای جدید را بررسی کنید؛ صرفاً حذف پیام خطا بدون Scan موفق، اثبات رفع مشکل نیست.

Resolve-DnsName -Name wsus.example.local
Test-NetConnection -ComputerName wsus.example.local -Port 8530

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 15 |
  Select-Object TimeCreated, Id, Message |
  Format-List

اگر ارتباط Update درست شد اما نصب یک Role یا Feature با 0x800F081F یا خطای Component Store همچنان شکست می‌خورد، مسئله مستقل است؛ راهنمای DISM و Component Store در Windows Server را جداگانه دنبال کنید.

Rollback و اشتباهات رایج

اگر بعد از اصلاح ارتباط با WSUS، Domain Controller یا سرویس‌های دیگر قطع شد، DNS یا Proxy ثبت‌شده پیش از تغییر را برگردانید؛ تغییر GPO را هم در همان محل مدیریتی Rollback کنید. روی VPS، Console مستقل از RDP برای بازیابی لازم است.

• اجرای کورکورانه netsh winhttp reset proxy ممکن است دسترسی سازمانی را قطع کند.
• پاک‌کردن SoftwareDistribution پیش از بررسی DNS معمولاً علت این کد را برطرف نمی‌کند.
• Ping موفق، سلامت پورت TCP یا TLS را تضمین نمی‌کند.
• 0x8024402C را با خطاهای Proxy Authentication یا خرابی Component Store یکی فرض نکنید.

منابع فنی: فهرست رسمی کدهای Windows Update و چک‌لیست رسمی Windows Server Update. اول نام مقصد، DNS و مسیر شبکه را ثابت کنید؛ سپس در صورت نیاز به سراغ تغییرات گسترده بروید.