رفع خطای AD Replication 1722 در Windows Server؛ عیب‌یابی RPC، DNS و Firewall

خطای Active Directory replication error 1722 (0x6BA): The RPC server is unavailable یعنی Domain Controller مقصد هنگام همگام‌سازی نتوانسته ارتباط RPC لازم را با شریک Replication برقرار کند. ابتدا با repadmin /replsummary و repadmin /showrepl جفت DC و پارتیشن ناموفق را مشخص کنید؛ سپس DNS، دسترسی شبکه، TCP 135، پورت‌های پویا و سرویس‌های مرتبط را به‌ترتیب بررسی کنید. این خطا به‌تنهایی دلیل حذف DC، خاموش‌کردن فایروال یا اجرای اجباری Replication نیست.

خطای 1722 در Active Directory دقیقاً چه چیزی را نشان می‌دهد؟

این پیام در repadmin، dcdiag یا Event Viewer ممکن است با متن The RPC server is unavailable دیده شود. کد Win32 برابر 1722 و مقدار هگز آن 0x6BA است. خطا می‌تواند از نام اشتباه DC، رکورد DNS قدیمی، مسیر شبکه قطع‌شده، فایروال بین دو DC یا Endpoint Mapper و Dynamic RPC ناشی شود. راهنمای رسمی مایکروسافت برای Replication Error 1722 همین مسیر تشخیص را توضیح می‌دهد.

این مقاله مخصوص Replication میان Domain Controllerها است؛ اگر فقط یک کامپیوتر عضو دامنه نمی‌تواند وارد شود، مسئله ممکن است Secure Channel باشد و باید مسیر تعمیر Trust Relationship بدون خروج از دامنه را جداگانه بررسی کنید.

پیش‌نیازها و احتیاط‌های محیط Production

• PowerShell یا Command Prompt با دسترسی مدیریتی مجاز روی DC یا سرور دارای RSAT/AD DS Tools.
• نام FQDN و IP هر دو Domain Controller، نام Site، زمان شروع خطا و اطلاعات تغییرات اخیر DNS/Firewall.
• دسترسی کنسول مدیریتی مستقل از RDP، برنامه نگهداری و System State Backup معتبر قبل از تغییرات حساس.
• در مثال‌ها dc01.contoso.local مقصد و dc02.contoso.local شریک Replication است؛ مقادیر را با محیط واقعی جایگزین کنید.

هشدار: روی DC از Snapshot یا Rollback ماشین مجازی به‌عنوان روش عمومی بازیابی AD استفاده نکنید. فایروال را به‌صورت سراسری غیرفعال نکنید و سرویس NTDS را بدون برنامه بازیابی Restart نکنید.

مرحله ۱: DC و پارتیشن ناموفق را با repadmin پیدا کنید

repadmin /replsummary
repadmin /showrepl dc01.contoso.local /errorsonly
dcdiag /s:dc01.contoso.local /test:Replications /v

خروجی مورد انتظار: در /replsummary ستون Failures و Largest Delta وضعیت هر DC را نشان می‌دهد. در /showrepl به Source DSA، Naming Context، زمان آخرین تلاش و عبارت 1722 (0x6ba) توجه کنید. اگر تنها یک Partner مشکل دارد، عیب‌یابی را روی همان مسیر محدود کنید؛ اگر چندین DC خطا دارند، DNS یا مسیر شبکه مشترک را بررسی کنید.

برای شواهد تکمیلی روی Domain Controller:

Get-WinEvent -FilterHashtable @{
  LogName='Directory Service'
  StartTime=(Get-Date).AddHours(-24)
} -MaxEvents 30 |
  Select-Object TimeCreated,Id,LevelDisplayName,Message |
  Format-List

صرف وجود خطای قدیمی در Event Log نشانه خرابی فعلی نیست؛ زمان رخداد را با آخرین تلاش Replication تطبیق دهید.

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

Active Directory برای یافتن DCها و شریک Replication به DNS داخلی سالم متکی است. ابتدا DNS Client خود DC و سپس پاسخ رکوردهای A و SRV را از DNS داخلی بررسی کنید:

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName -Name dc02.contoso.local -Type A -Server 10.0.0.10
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.contoso.local -Type SRV -Server 10.0.0.10
nltest /dsgetdc:contoso.local

Verify: رکورد A باید IP درست و قابل دسترس DC را نشان دهد و SRV به DCهای واقعی دامنه اشاره کند. اگر رکورد قدیمی یا اشتباه است، منشأ آن را در Zone و ثبت DNS بررسی کنید؛ با تغییر DNS Client به 8.8.8.8 روی Domain Controller مشکل AD را «حل» نکنید. برای تشخیص دقیق Zone، Forwarder و Client، راهنمای عیب‌یابی DNS در Windows Server کمک می‌کند.

اگر هم‌زمان DNS Event ID 4013 رخ می‌دهد، ممکن است DNS منتظر Initial Synchronization باشد؛ در این حالت بررسی DNS Event ID 4013 و راه‌اندازی AD DS را هم دنبال کنید. خطای 4013 با 1722 یکی نیست.

مرحله ۳: ارتباط TCP 135 و مسیر RPC را تست کنید

Endpoint Mapper معمولاً روی TCP 135 پاسخ می‌دهد، اما موفقیت این تست به‌تنهایی سلامت Replication را ثابت نمی‌کند؛ ارتباط بعدی از پورت RPC پویا استفاده می‌کند. روی DC مقصد یا میزبان دارای دسترسی شبکه:

Test-NetConnection -ComputerName dc02.contoso.local -Port 135
Test-NetConnection -ComputerName dc02.contoso.local -Port 389
Test-NetConnection -ComputerName dc02.contoso.local -InformationLevel Detailed

در خروجی، TcpTestSucceeded : True برای پورت ۱۳۵ فقط دسترسی به Endpoint Mapper را تأیید می‌کند. شکست آن می‌تواند به DNS، Routing، ACL، فایروال یا خاموش‌بودن سرور مربوط باشد. موفقیت ۳۸۹ نیز جایگزین تست RPC پویا نیست.

در نسخه‌های جدید Windows Server، محدوده پیش‌فرض پورت‌های پویا معمولاً 49152–65535/TCP است، اما تنظیمات واقعی و محدودسازی احتمالی RPC باید در محیط بررسی شوند. بازکردن کورکورانه این محدوده برای کل اینترنت خطرناک است؛ دسترسی لازم را فقط بین DCهای مجاز و طبق طراحی شبکه فراهم کنید. مستند مایکروسافت درباره عیب‌یابی Replication و Firewall نقش TCP 135 و RPC پویا را توضیح می‌دهد.

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

Get-Service -Name RpcSs,NTDS,Netlogon,DNS |
  Select-Object Name,Status,StartType
w32tm /query /status
ipconfig /all

روی Domain Controller، سرویس‌های ضروری باید با وضعیت متناسب با نقش سرور اجرا شوند. اگر RpcSs یا NTDS وضعیت غیرعادی دارد، ابتدا Event Log و علت توقف را پیدا کنید. اختلاف زمان قابل توجه، اختلال Kerberos یا مشکل دسترسی نیز ممکن است علائم Replication ایجاد کند؛ اما همه خطاهای احراز هویت را به‌اشتباه 1722 فرض نکنید.

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

سیاست‌های Windows Defender Firewall، فایروال دیتاسنتر، Security Group، VPN بین Siteها یا ACL روتر ممکن است فقط بخشی از ترافیک RPC را مسدود کنند. مسیر dc01 → dc02 و مسیر معکوس را جداگانه با تیم شبکه بررسی کنید. هر تغییر آزمایشی باید محدود به IPهای DC، پروتکل و بازه موردنیاز، ثبت‌شده و دارای زمان بازگشت باشد.

اگر هم‌زمان Group Policy خطای 1058 دارد، علت می‌تواند دسترسی به SYSVOL یا SMB باشد و نباید بدون بررسی با مشکل RPC یکسان فرض شود. در این وضعیت، عیب‌یابی Group Policy Event ID 1058 و SYSVOL مسیر مستقل تشخیص است.

اگر Domain Controller روی Windows VPS اجرا می‌شود

در محیطی که DC روی سرور مجازی خودمدیریت میزبانی می‌شود، پیش از تصمیم درباره تغییر زیرساخت، دسترسی کنسول، تنظیمات شبکه مجازی، سیاست فایروال میزبان و امکان ارتباط بین DCها را بررسی کنید. هنگام ارزیابی زیرساخت جدید می‌توان پلن‌های سرور مجازی وان‌سرور را از نظر منابع و الزامات مدیریتی مقایسه کرد؛ اما خرید VPS یا جابه‌جایی DC خطای 1722 سرور فعلی را خودکار برطرف نمی‌کند و قابلیت‌های شبکه موردنیاز باید پیش از استقرار تأیید شوند.

مرحله ۶: رفع مشکل را Verify کنید

پس از اصلاح علت مشخص‌شده (مثلاً رکورد DNS اشتباه یا قانون فایروال محدودکننده)، اجازه دهید Replication طبق زمان‌بندی عادی تلاش کند و وضعیت را دوباره بخوانید. بدون ضرورت و تأیید سلامت مسیر، همگام‌سازی اجباری کل Forest اجرا نکنید.

repadmin /replsummary
repadmin /showrepl dc01.contoso.local /errorsonly
dcdiag /s:dc01.contoso.local /test:Replications

خروجی سالم: تلاش‌های جدید با موفقیت ثبت شوند، خطای 1722 در Partner موردنظر تکرار نشود و Failure Count کاهش یابد. صفرشدن خطاهای قدیمی در Event Viewer شرط موفقیت نیست؛ زمان و نتیجه جدید مهم‌اند. اگر خطا ادامه دارد، گزارش DNS، ۱۳۵ و Firewall را با نام Source/Destination و Timestamp برای بررسی عمیق‌تر جمع‌آوری کنید.

Rollback و خطاهای رایج هنگام تعمیر

• اگر DNS Client یا رکورد Zone را تغییر دادید و نتیجه بدتر شد، فقط همان تغییر مستندشده را به مقدار قبلی بازگردانید؛ رکوردها را کورکورانه حذف نکنید.
• اگر Rule موقت Firewall اضافه شد، پس از آزمون آن را طبق Change Record حذف یا به سیاست تأییدشده تبدیل کنید؛ فایروال را برای رفع موقت خطا خاموش نگذارید.
• اگر مشکل در یک Site خاص است، قبل از هر تغییر Topology یا Site Link، مسیر شبکه و DNS همان Site را بررسی کنید.
• تست موفق TCP 135 به معنی بازبودن همه پورت‌های RPC نیست؛ همچنین Ping ناموفق لزوماً به معنی قطع Replication نیست، چون ICMP ممکن است مسدود باشد.
• تغییر هم‌زمان DNS، فایروال و تنظیمات Replication باعث از بین رفتن شواهد می‌شود؛ یک متغیر را در هر مرحله اصلاح و Verify کنید.

با این ترتیب، به‌جای دستکاری گسترده Active Directory، علت واقعی RPC server unavailable (1722) در مسیر مشخص دو Domain Controller پیدا و اصلاح می‌شود.