DFSR Event ID 2213 معمولاً پس از خاموشی غیرعادی یا توقف نامناسب سرویس DFS Replication ثبت می‌شود؛ دیتابیس ESE روی یک Volume ممکن است Dirty Shutdown داشته باشد و Replication برای جلوگیری از ناسازگاری متوقف شود. ابتدا Event، Volume GUID و وضعیت دیگر اعضای Replication را بخوانید؛ سپس از همه Replicated Folderهای Volume بکاپ بگیرید. فقط پس از احراز شرایط و تطبیق با مستند Microsoft، متد ResumeReplication را اجرا کنید. اجرای کورکورانه آن می‌تواند به تضاد نسخه فایل‌ها و از دست‌رفتن داده منجر شود.
تفاوت DFSR 2213 با خطاهای اکتیودایرکتوری
DFSR وضعیت همگام‌سازی فایل‌ها و SYSVOL را مدیریت می‌کند، اما AD Replication تراکنش‌های دایرکتوری را منتقل می‌کند. بنابراین خروجی سالم repadmin تضمینی برای سالم بودن DFSR نیست. اگر هم‌زمان RPC Server Unavailable دارید، مراحل تشخیص AD Replication 1722 را جداگانه دنبال کنید.
در راهنمای رسمی Microsoft برای Event 2213 توضیح داده شده که در برخی نسخه‌ها و سناریوها DFSR به‌جای ادامه خودکار، بازیابی را متوقف می‌کند. بخش‌های نسخه‌ای آن عمدتاً Windows Server 2008 R2 و 2012 را توصیف می‌کنند؛ هیچ فرمانی را بدون بررسی نسخه، رویداد واقعی و نقش سرور تعمیم ندهید.
پیش‌نیاز و هشدار قبل از بازیابی
با دسترسی مدیریتی روی Domain Controller یا DFSR Member درست وارد شوید، نام ماشین و Volume آسیب‌دیده را یادداشت کنید، و Eventها را روی تمام DCهای مرتبط مقایسه کنید. قبل از Resume باید از تمام پوشه‌های Replicated موجود روی Volume مشکل‌دار و در صورت وجود پوشه‌های PreExisting و ConflictAndDeleted، نسخه پشتیبان مستقل و قابل‌بازیابی تهیه شود. برای SYSVOL، صحت و تازگی فایل‌های GPO در DCهای دیگر را نیز بررسی کنید.
هشدار Production: حذف دیتابیس DFSR، حذف SYSVOL، تغییر رجیستری برای اجبار AutoRecovery یا اجرای Authoritative/Non-authoritative Sync روش عمومی رفع 2213 نیستند و ممکن است موجب Data Loss شوند. اگر Event 4012 یا مشکل Initial Sync دارید، این مقاله به‌تنهایی مجوز Resume نیست.
گام اول: Event 2213، 2212، 2214 و 4012 را بررسی کنید
فرمان‌های زیر فقط اطلاعات را می‌خوانند. در Event 2213، GUID و مسیر Volume را از پیام واقعی کپی کنید، نه از نمونه‌های اینترنتی.
Get-WinEvent -FilterHashtable @{
LogName = 'DFS Replication'
Id = 2213,2212,2214,4012
StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated,Id,Message |
Format-List
Get-Service -Name DFSRرویداد 2213 نشانه توقف مرتبط با Dirty Shutdown است؛ 2214 در روند مورد بحث می‌تواند نشان دهد بازیابی به پایان رسیده است. رویداد 4012 به محدودیت Content Freshness اشاره می‌کند و عیب‌یابی جداگانه دارد. نبود رویداد در بازه انتخابی، اثبات سالم بودن سرویس نیست؛ بازه و Log درست را کنترل کنید.
گام دوم: SYSVOL، Replication Group و وضعیت AD را جداگانه بخوانید
در Domain Controller، وضعیت Shareهای SYSVOL و NETLOGON را بررسی کنید. سپس از WMI برای مشاهده وضعیت پوشه‌های Replicated استفاده کنید:
net share
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
Select-Object ReplicationGroupName,ReplicatedFolderName,State
repadmin /replsummaryدر خروجی WMI، مقدار State = 4 در سناریوی مستند Microsoft وضعیت Normal است. repadmin فقط برای تشخیص اختلال هم‌زمان AD Replication است؛ سلامت DFSR را تأیید نمی‌کند. اگر مشکل اصلی خواندن فایل gpt.ini است، راهنمای Group Policy Event ID 1058 و SYSVOL را هم بررسی کنید.
گام سوم: Volume GUID صحیح را پیدا کنید
از کلاس DfsrVolumeConfig اطلاعات Volumeهای ثبت‌شده را دریافت و با GUID داخل Event 2213 مقایسه کنید:
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrVolumeConfig |
Select-Object VolumeGuid
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
Select-Object ReplicationGroupName,ReplicatedFolderName,Stateاگر WMI خطا می‌دهد یا GUID موردنظر پیدا نمی‌شود، مرحله Resume را متوقف کنید. سرور، سطح دسترسی، وضعیت سرویس و نقش DFSR باید ابتدا تصحیح شوند. وجود Volume هم‌نام روی دو سرور به معنی یکسان بودن وضعیت آن‌ها نیست.
گام چهارم: بکاپ مستقل و بررسی نسخه معتبر داده‌ها
Microsoft پیش از ResumeReplication، بکاپ همه Replicated Folderهای Volume آسیب‌دیده را ضروری می‌داند؛ چون بازگشت Replication ممکن است نسخه‌های متعارض را بر اساس مکانیزم حل تعارض انتخاب کند. بکاپ باید مستقل از Volume آسیب‌دیده باشد و بتوان محتوا را از آن بازیابی کرد. محتوای SYSVOL و فایل‌های GPO را با DC سالم مقایسه کنید و پیش از تغییر، گزارش Eventها را نگه دارید.
صرف داشتن Snapshot یا روشن‌بودن یکی از DCها، جایگزین تأیید نسخه سالم فایل‌ها نیست. اگر چند عضو Replication متوقف شده‌اند، بدون مشخص‌کردن مرجع داده سالم، همه را پشت‌سرهم Resume نکنید.
گام پنجم: ResumeReplication فقط پس از تأیید شرایط
عملیات زیر تغییر‌دهنده است و تنها بعد از بکاپ، بررسی تمام اعضا و تأیید حجم داده معتبر انجام می‌شود. در مستند قدیمی Microsoft از WMIC استفاده شده است؛ در نسخه‌هایی که کلاس WMI در دسترس باشد، می‌توان متد را از PowerShell فراخوانی کرد. ابتدا فقط تطابق GUID را بررسی کنید:
$VolumeGuid = 'GUID_FROM_YOUR_2213_EVENT'
$Volume = @(Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrVolumeConfig |
Where-Object { $_.VolumeGuid -eq $VolumeGuid })
if ($Volume.Count -ne 1) {
throw 'Volume GUID not uniquely matched. STOP.'
}
$Volume | Select-Object VolumeGuidعبارت GUID_FROM_YOUR_2213_EVENT عمداً placeholder است و باید با GUID واقعی همان Event جایگزین شود. پس از تأیید نهایی و مجوز تغییر:
# CHANGES DFSR STATE: run only after verified backup and approval
$Volume | Invoke-CimMethod -MethodName ResumeReplicationاگر متد روی سرور در دسترس نبود، فرض نکنید هر ابزار جایگزین نتیجه یکسانی می‌دهد؛ از فرمان درج‌شده در متن Event و مستند نسخه نصب‌شده استفاده کنید. موفقیت متد لزوماً به معنی تکمیل Replication فایل‌ها نیست.
Verify: بررسی نتیجه بازیابی و Shareهای حیاتی
پس از اقدام، Eventهای جدید و وضعیت Replicated Folderها را پایش کنید. Event 2214 پس از Resume در سناریوی مستند نشانه مثبتی است. برای SYSVOL وضعیت Initial Sync و Shareها را جداگانه تأیید کنید.
Get-WinEvent -FilterHashtable @{
LogName = 'DFS Replication'
Id = 2213,2214,4012,4604,4614
StartTime = (Get-Date).AddHours(-4)
} -ErrorAction SilentlyContinue |
Sort-Object TimeCreated -Descending |
Select-Object TimeCreated,Id,Message
Get-CimInstance -Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
Select-Object ReplicationGroupName,ReplicatedFolderName,State
net shareموفقیت نهایی را با توقف خطاهای تکرارشونده، بازگشت وضعیت عادی Replication، وجود Shareهای مورد انتظار، و تطابق فایل‌های مهم روی اعضای مربوط بسنجید. یک خروجی لحظه‌ای بدون انتقال فعال، به‌تنهایی سلامت DFSR را ثابت نمی‌کند.
چه زمانی خطا با Resume ساده حل نمی‌شود؟
اگر Event 4012، مشکل Initial Sync، Shareهای غایب در چند DC یا اختلاف شدید داده‌ها وجود دارد، باید مسیر بازیابی مخصوص آن وضعیت طراحی شود. مستند Microsoft درباره SYSVOL و NETLOGON غایب هشدار می‌دهد که حذف دیتابیس DFSR یا بازسازی غیرضروری می‌تواند باعث از دست رفتن داده شود.
اگر هم‌زمان DNS روی DC برای بارگذاری Zoneهای AD-integrated متوقف مانده، مسئله جداگانه DNS Event ID 4013 و Active Directory DNS Startup را بررسی کنید؛ این Event معادل توقف DFSR نیست.
رابطه مشکل با زیرساخت Windows VPS
اگر Domain Controller یا DFSR Member روی Windows VPS خودمدیریت میزبانی می‌شود، امکانات دسترسی مدیریتی به کنسول، بکاپ، پایداری ذخیره‌سازی و سیاست Restart در انتخاب زیرساخت اهمیت دارند. هنگام برنامه‌ریزی یا ارتقا، می‌توان پلن‌های سرور مجازی وان‌سرور را از منظر نیاز واقعی سیستم و سطح دسترسی بررسی کرد؛ پشتیبانی از سناریوی خاص و الزامات بکاپ را جداگانه تأیید کنید. تغییر VPS دیتابیس DFSR موجود را به‌صورت خودکار ترمیم نمی‌کند.
Rollback، خطرات و اشتباه‌های رایج
ResumeReplication دکمه Undo عمومی ندارد. اگر پس از بازیابی تعارض یا حذف فایل‌ها دیده شد، اعمال تغییرات بیشتر را متوقف کرده و با تکیه بر بکاپ معتبر و طرح بازیابی متناسب با وضعیت Domain، مسیر اصلاح را تعیین کنید. در SYSVOL، بازیابی Authoritative یا Non-authoritative بدون تشخیص مرجع سالم و هماهنگی تیم Active Directory خطرناک است.
- کپی‌کردن GUID نمونه به‌جای GUID همان Event 2213 و همان سرور.
- حذف دستی دیتابیس DFSR، SYSVOL یا پوشه‌های ConflictAndDeleted.
- اجرای مکرر Resume بدون بررسی Event 2214 و وضعیت اعضای Replication.
- نادیده گرفتن Event 4012 و خطاهای Initial Sync.
- اشتباه گرفتن Replication اکتیودایرکتوری با Replication فایل‌های DFSR.
- اجرای بازیابی قبل از تهیه بکاپ از همه Replicated Folderهای Volume مشکل‌دار.
ترتیب ایمن عیب‌یابی این است: خواندن Event → تشخیص Volume → بررسی سایر اعضا → بکاپ مستقل → Resume کنترل‌شده → Verify.