رفع خطای Group Policy Event ID 1058 در Windows Server؛ عیب‌یابی SYSVOL و gpt.ini

اگر پس از اجرای gpupdate /force یا ورود کاربر به دامنه، در Event Viewer خطای Group Policy Event ID 1058 می‌بینید، ویندوز نتوانسته فایل تنظیمات GPO را از مسیر SYSVOL روی Domain Controller بخواند. برای رفع اصولی، ابتدا نام DC و کد خطای داخل Event 1058 را استخراج کنید؛ سپس به‌ترتیب DNS، اتصال TCP 445، دسترسی به مسیر gpt.ini، وضعیت DFS/SYSVOL و در نهایت Replication و Permission را بررسی کنید. تغییر ACL یا حذف GPO بدون تشخیص علت می‌تواند مشکل را گسترده‌تر کند.

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

Group Policy از دو بخش تشکیل می‌شود: اطلاعات GPO در Active Directory و فایل‌های آن در SYSVOL. کلاینت دامنه برای خواندن تنظیمات به فایلی مثل gpt.ini نیاز دارد. وقتی مسیر شبکه‌ای این فایل در دسترس نباشد، پردازش Policy ممکن است متوقف شود؛ در نتیجه تنظیمات امنیتی، اسکریپت ورود، درایوهای شبکه یا پیکربندی‌های رایانه اعمال نمی‌شوند. پیام 1058 لزوماً به معنی خرابی خود GPO نیست: DNS اشتباه، قطع ارتباط با DC، مسدودبودن SMB، Replication ناقص یا مجوز نامناسب هم می‌تواند همین علامت را ایجاد کند.

پیش‌نیاز و سناریوی عیب‌یابی

مثال: دامنه example.local، کنترلر دامنه dc01.example.local و یک کلاینت عضو دامنه Windows Server 2022/2025 یا Windows 10/11. دستورات کلاینت را در PowerShell یا CMD با دسترسی مناسب اجرا کنید؛ دستورات repadmin و dcdiag مخصوص مدیر دامنه و سرور دارای ابزار AD DS/RSAT هستند. قبل از تغییر DNS، GPO، فایروال یا ACL، تنظیمات موجود و زمان رخداد را ثبت کنید. نام دامنه، DC و GUID نمونه را با مقادیر واقعی جایگزین کنید.

مرحله ۱: جزئیات Event ID 1058 را استخراج کنید

در Event Viewer مسیر Windows Logs → System را باز کنید و رویداد با منبع GroupPolicy و شناسه 1058 را پیدا کنید. در تب Details، نام Domain Controller، GUID مربوط به GPO، مسیر فایل و Error Code را یادداشت کنید. برای جمع‌آوری از PowerShell:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1058} -MaxEvents 5 |
  Format-List TimeCreated,Id,ProviderName,Message

خروجی مورد انتظار: پیام حاوی مسیر gpt.ini و علت شکست است. کد 3 معمولاً به پیدا نشدن مسیر، کد 5 به Access denied و خطاهای شبکه به مشکل اتصال اشاره دارند؛ تشخیص را با متن دقیق پیام تکمیل کنید. اگر در System رویدادی پیدا نشد، در Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational رویدادهای هم‌زمان را بررسی کنید.

مرحله ۲: Domain Controller انتخاب‌شده و DNS را بررسی کنید

ابتدا مطمئن شوید کلاینت از DNS داخلی Active Directory استفاده می‌کند، نه صرفاً DNS عمومی. وجود پاسخ DNS به‌تنهایی کافی نیست؛ SRV Record و کشف DC نیز باید سالم باشد.

ipconfig /all
nltest /dsgetdc:example.local
nslookup dc01.example.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.local

Verify: خروجی nltest باید DC معتبر دامنه را نشان دهد؛ رکورد SRV باید DCهای دامنه را برگرداند و آدرس DC با شبکه واقعی سازگار باشد. اگر DNS عمومی روی کارت شبکه عضو دامنه تنظیم شده، مطابق سیاست شبکه آن را به DNS داخلی اصلاح کنید. پس از رفع مشکل DNS، می‌توان ipconfig /flushdns و سپس nltest /dsgetdc:example.local /force را برای آزمایش مجدد اجرا کرد. اگر مشکل گسترده DNS دارید، راهنمای عیب‌یابی DNS در Windows Server را نیز ببینید.

مرحله ۳: اتصال SMB به Domain Controller را تست کنید

فایل‌های SYSVOL معمولاً از طریق SMB خوانده می‌شوند؛ بنابراین دسترسی TCP 445 به DC لازم است. تست را از همان کلاینتی انجام دهید که خطای 1058 دارد:

Test-NetConnection dc01.example.local -Port 445
Test-NetConnection dc01.example.local -Port 135
ping dc01.example.local

خروجی مورد انتظار: مقدار TcpTestSucceeded : True برای پورت 445. پاسخ ندادن Ping به‌تنهایی خرابی SMB را ثابت نمی‌کند؛ ICMP ممکن است مسدود باشد. اگر 445 بسته است، مسیر شبکه، VLAN، ACL روتر و فایروال مبدأ/مقصد را بررسی کنید. برای رفع مشکل، فایروال را سراسری خاموش نکنید؛ فقط Rule لازم برای ارتباط کلاینت و DC را طبق سیاست سازمان اصلاح کنید. برای بررسی عمیق‌تر به مقاله رفع مشکل SMB و Port 445 در Windows Server مراجعه کنید.

مرحله ۴: فایل gpt.ini را از مسیر واقعی SYSVOL بخوانید

از مسیر دقیقی که در Event 1058 نمایش داده شده استفاده کنید؛ مسیر نمونه زیر را بدون جایگزینی GUID واقعی اجرا نکنید. از PowerShell:

$GpoFile = '\\dc01.example.local\SYSVOL\example.local\Policies\{GPO-GUID}\gpt.ini'
Test-Path -LiteralPath $GpoFile
Get-Content -LiteralPath $GpoFile -ErrorAction Stop

اگر Test-Path برابر True است و فایل باز می‌شود، معمولاً بخش پایه اتصال و دسترسی سالم است و باید رویدادهای هم‌زمان یا DC دیگر بررسی شود. اگر مسیر پیدا نمی‌شود، ابتدا از وجود فولدر GUID در DC موردنظر مطمئن شوید. اگر Access denied دریافت می‌کنید، دسترسی Share و NTFS و حساب کاربری/رایانه‌ای که Policy را پردازش می‌کند بررسی شود. بدون تهیه Backup و بررسی وراثت مجوزها، ACL پوشه SYSVOL را بازنویسی نکنید.

مرحله ۵: SYSVOL و NETLOGON را روی DC بررسی کنید

روی Domain Controller با حساب مدیریتی وضعیت Shareها و سرویس Replication را مشاهده کنید:

net share
Get-Service DFSR
Get-WinEvent -LogName 'DFS Replication' -MaxEvents 20 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message

در خروجی net share باید Shareهای SYSVOL و NETLOGON موجود باشند. نبود این Shareها یا رویدادهای خطای DFSR نشان می‌دهد مشکل از سرویس‌دهی DC است و نباید فقط با تغییر DNS کلاینت آن را پنهان کرد. در DCهای چندگانه، وجود gpt.ini و زمان تغییر فایل را روی DCهای مرتبط مقایسه کنید؛ برای تشخیص Replication از دستورات مرحله بعد استفاده کنید.

مرحله ۶: Replication و سلامت Active Directory را ارزیابی کنید

این بخش مخصوص محیط چند DC یا زمانی است که یک DC فایل را دارد و DC دیگر ندارد. روی DC یا سرور دارای RSAT:

repadmin /replsummary
repadmin /showrepl
dcdiag /test:sysvolcheck /test:advertising /v

Verify: خطاهای Replication و تأخیر غیرعادی نباید وجود داشته باشند و تست‌های dcdiag باید مطابق شرایط محیط سالم باشند. repadmin سلامت Replication دیتابیس AD را بررسی می‌کند؛ برای سلامت محتوای SYSVOL لازم است وضعیت DFSR و فایل‌های واقعی را جداگانه بررسی کنید. از اجرای کورکورانه روش‌های authoritative/non-authoritative DFSR یا کپی دستی کل پوشه Policies خودداری کنید؛ این اقدامات در محیط تولید می‌توانند باعث ناسازگاری Policy شوند.

مرحله ۷: دسترسی‌ها و حساب ماشین را بدون تغییر مخرب بررسی کنید

اگر مسیر وجود دارد اما خواندن آن ناموفق است، ابتدا تفاوت بین خطای Access denied و خطای شبکه را مشخص کنید. روی DC وضعیت Permission را فقط بخوانید:

icacls 'C:\Windows\SYSVOL\domain\Policies'
Get-SmbShare -Name SYSVOL | Format-List Name,Path,Description

محل واقعی SYSVOL ممکن است با مسیر نمونه فرق داشته باشد؛ آن را از Get-SmbShare بردارید. همچنین روی عضو دامنه سلامت Secure Channel را بررسی کنید:

Test-ComputerSecureChannel -Verbose

اگر Secure Channel مشکل دارد، قبل از Reset یا خروج و ورود مجدد به دامنه، راهنمای تعمیر Trust Relationship بدون خروج از دامنه را بخوانید. Test-ComputerSecureChannel برای Member Server/Client است و برای تشخیص روی Domain Controller مناسب نیست. اصلاح ACL باید پس از مقایسه با DC سالم و ثبت مجوزهای فعلی انجام شود.

مرحله ۸: پردازش Group Policy را دوباره اجرا و نتیجه را تأیید کنید

بعد از رفع علت اصلی، روی کلاینت عضو دامنه:

gpupdate /force
gpresult /r
gpresult /h "$env:TEMP\gp-1058-report.html"

در PowerShell هم می‌توانید گزارش را با gpresult /h به یک مسیر قابل نوشتن بسازید. معیار موفقیت صرفاً نمایش پیام موفقیت gpupdate نیست: باید در Event Viewer خطای 1058 جدید ثبت نشود، گزارش gpresult GPOهای مورد انتظار را نشان دهد و تنظیم واقعی هدف (برای مثال یک Policy امنیتی یا Drive Mapping) اعمال شده باشد. اگر رویداد ادامه دارد، DC و GUID داخل رویداد جدید را با رویداد قبلی مقایسه کنید؛ ممکن است کلاینت به DC دیگری متصل شده باشد.

خطاهای رایج و روش تفکیک آن‌ها

• کد 3 / Path not found: GUID یا فایل gpt.ini روی DC انتخابی موجود نیست؛ DFSR و مسیر SYSVOL را بررسی کنید.
• Access denied / کد 5: Share/NTFS Permission یا حساب پردازش‌کننده GPO را بررسی کنید؛ ACL را بدون مقایسه و Backup بازنویسی نکنید.
• Network path not found: DNS، نام DC، TCP 445 و مسیر شبکه را بررسی کنید.
• مشکل فقط روی یک کلاینت: DNS همان کلاینت، Secure Channel و Firewall محلی را بررسی کنید.
• مشکل فقط هنگام اتصال به یک DC: Shareها، DFSR و فایل‌های SYSVOL همان DC را با DC سالم مقایسه کنید.
• gpupdate موفق است ولی تنظیم اعمال نمی‌شود: گزارش gpresult، Scope، Security Filtering و WMI Filter مربوط به GPO را بررسی کنید.

نکات امنیتی و Rollback

قبل از هر تغییر، DNS قبلی کلاینت، Ruleهای فایروال، مسیر SYSVOL، Event ID و خروجی‌های gpresult و repadmin را ذخیره کنید. در صورت بدتر شدن وضعیت، فقط تغییرات مشخصی را که خودتان اعمال کرده‌اید بازگردانید (مثلاً DNS یا Rule موقت) و دوباره TCP 445 و دسترسی به فایل را تست کنید. اگر تغییری در Permission لازم شد، از ACL اصلی Export بگیرید و تغییر را روی DC آزمایشی یا پنجره نگهداری انجام دهید. برای مشکل Replication، به‌جای راه‌حل‌های پرریسک، ابتدا Backup معتبر و سلامت DCها را تأیید کنید. برای میزبانی سرویس‌های Windows Server در محیط قابل مدیریت، پلن‌های سرور مجازی وان‌سرور فقط زمانی مرتبط‌اند که زیرساخت خود را طراحی یا توسعه می‌دهید؛ خرید VPS به‌خودی‌خود خطای GPO را رفع نمی‌کند.

جمع‌بندی عیب‌یابی

مسیر تشخیص عملی خطای Group Policy 1058 این است: استخراج Error Code و DC از Event → تست DNS/DC Discovery → تست TCP 445 → خواندن gpt.ini از SYSVOL → بررسی DFSR/Replication/ACL → اجرای gpupdate و کنترل gpresult. این ترتیب کمک می‌کند بدون دست‌کاری بی‌دلیل Active Directory، علت واقعی را پیدا کنید.

مراجع رسمی: Microsoft Learn: Applying Group Policy troubleshooting و Microsoft Learn: DFS Replication overview.