وصل‌کردن کامپیوتر به دامین و رفع خطاهای رایج

مثال روی یک Windows 11 Pro است که قرار است برای اولین بار به ad.example.com متصل شود. کنترلر DC1، Windows Server 2025 Standard با Desktop Experience و IP برابر 192.168.50.10 دارد؛ همان محیط آموزش نصب اکتیودایرکتوری. عضویت در AD محلی با اتصال به Microsoft Entra ID یا صرفاً افزودن حساب کاری فرق دارد.

Windows Home برای این نوع عضویت مناسب نیست. نسخه و وضعیت فعلی دستگاه را در Settings → System → About بررسی کنید. اگر دستگاه عضو دامین دیگری است، انتقال آن یک کار جدا با بررسی داده و وابستگی‌هاست. اگر قبلاً عضو همین دامین بوده و اکنون پیام Trust می‌دهد، راهنمای خطای Trust Relationship را دنبال کنید.

• نام یکتای کامپیوتر را تعیین کنید؛ در این مثال LAB-PC. نام دستگاه فعال دیگری را تکرار نکنید. اگر تغییر نام نیازمند Restart شد، آن را پیش از Join و با ذخیرهٔ کارهای باز انجام دهید.
• دسترسی محلی مدیریتیِ مجاز را برای زمان قطع ارتباط حفظ و امکان ورود آن را بررسی کنید. در کار از راه دور، پیش از تغییر و Restart مسیر دسترسی جایگزین مشخص باشد.
• از فایل‌های لازم کاربر و تنظیمات وابسته نسخهٔ قابل بازیابی داشته باشید. اگر داده رمزگذاری شده یا برنامه به حساب فعلی وابسته است، روش انتقال و بازیابی آن باید پیش از تغییر روشن شود.
• حساب انجام‌دهندهٔ Join باید مجوز ایجاد حساب کامپیوتر در محل موردنظر، یا مجوز مناسب استفادهٔ دوباره از حساب موجود را داشته باشد. کاربر روزمره لازم نیست عضو Domain Admins شود.

در شبکهٔ سازمان، محل نهایی حساب کامپیوتر را با مدیر دامین مشخص کنید. پیش‌ساختن حساب در OU با مجوز درست می‌تواند بخشی از فرایند سازمان باشد؛ وجود صرف یک Computer Object، مجوز استفادهٔ دوباره از آن را ثابت نمی‌کند.

در آزمایش بدون روتر، کلاینت IP آزاد 192.168.50.50 با ماسک 255.255.255.0 و DNS برابر 192.168.50.10 دارد. اگر از DHCP استفاده می‌کنید، خروجی واقعی کلاینت باید DNS داخلی درست را نشان دهد. DNS عمومی را به‌عنوان جایگزین DNS دامین قرار ندهید. در شبکه‌های دیگر، IP، مسیر و DNS باید متناسب با همان محیط باشند.

ipconfig /all
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.ad.example.com -Type SRV -DnsOnly -NoHostsFile
Resolve-DnsName -Name DC1.ad.example.com -Type A -DnsOnly -NoHostsFile

در ipconfig، آداپتور فعال و DNS واقعی را ببینید. پاسخ SRV باید کنترلر معتبر دامین را معرفی کند و نام DC1 در این مثال باید به 192.168.50.10 برسد. اگر پاسخ پیش‌فرض مشکل دارد، همان پرسش SRV را با افزودن ‎-Server 192.168.50.10 تکرار کنید؛ تفاوت دو نتیجه می‌تواند مسیر DNS تنظیم‌شدهٔ کلاینت را روشن کند.

تاریخ، ساعت و منطقهٔ زمانی را کنترل کنید؛ نمایش ساعت محلی به‌تنهایی کافی نیست و زمان واقعی باید درست باشد. پاسخ Ping یا باز شدن اینترنت، سلامت همهٔ ارتباط‌های لازم AD را ثابت نمی‌کند. در مسیر VPN نیز دسترسی به DC هنگام Join و نخستین ورود دامین لازم است؛ VPNی که فقط بعد از ورود کاربر وصل می‌شود ممکن است این مرحله را پوشش ندهد.

• با حساب دارای دسترسی مدیریتی محلی، Settings → Accounts → Access work or school را باز کنید و Connect را بزنید.
• گزینهٔ Join this device to a local Active Directory domain را انتخاب کنید. مسیر مربوط به Entra ID را به‌جای آن انتخاب نکنید.
• نام کامل ad.example.com را وارد کنید. وقتی اعتبارنامه خواسته شد، حساب دارای مجوز Join را با نام دامین وارد کنید؛ رمز را داخل اسکریپت یا یادداشت عمومی قرار ندهید.
• پس از پیام موفقیت، کارهای باز را ذخیره و دستگاه را Restart کنید. اگر قبل از موفقیت خطا دیده شد، متن و زمان آن را ثبت کنید و به بخش عیب‌یابی بروید.
• در صفحهٔ ورود Other user را انتخاب کنید و با کاربر عادی، مثلاً AD\lab.sales، وارد شوید. این حساب باید از قبل در دامین ساخته و فعال شده باشد؛ حساب انجام‌دهندهٔ Join لزوماً همان کاربر روزمره نیست.

برای ساخت حساب نمونه و گروه‌هایش، راهنمای کاربران و OU را ببینید. نخستین ورود را در حالی انجام دهید که کلاینت به دامین دسترسی دارد؛ فرض وجود ورود ذخیره‌شده برای کاربری که قبلاً روی این دستگاه وارد نشده درست نیست.

نام دامینِ عضو‌شده را در مشخصات سیستم بررسی کنید. در ADUC، حساب LAB-PC باید در محل موردانتظار دیده شود؛ اگر محل خاصی از قبل تعیین نشده باشد، ممکن است در Computers پیش‌فرض ساخته شده باشد. مدیر مجاز می‌تواند آن را به Lab / Workstations منتقل کند، اما باید اثر سیاست‌های OU مقصد را هم بررسی کند.

whoami

در این مثال انتظار داریم هویت AD\lab.sales نمایش داده شود، نه هویتی با پیشوند نام محلی LAB-PC. این معیار پذیرش است و خروجی اجرای ثبت‌شدهٔ نت‌مسترز نیست. یک منبعی را که این کاربر واقعاً مجوزش را دارد باز کنید؛ اگر GPO مشخصی در محدودهٔ اوست، نتیجهٔ آن نیز جداگانه بررسی شود. Join موفق، مجوز همهٔ Shareها یا موفقیت همهٔ سیاست‌ها را تضمین نمی‌کند.

حساب محلی و حساب دامین دو هویت جدا هستند، حتی اگر نام ظاهری یکسان داشته باشند. نخستین ورود با هویت جدید می‌تواند پروفایل دیگری بسازد؛ نبودن فایل‌های دسکتاپ قبلی در آن پروفایل، به‌تنهایی نشانهٔ حذف داده‌ها نیست.

قبل از پاک‌کردن چیزی، حسابی را که وارد شده و محل دادهٔ قبلی را بررسی کنید. انتقال فایل‌ها و تنظیمات باید با پشتیبان، مجوز مالک داده و توجه به برنامه‌ها انجام شود. پوشهٔ پروفایل قبلی را برای «یکی‌کردن» دو حساب حذف یا جایگزین نکنید. به‌ویژه دادهٔ رمزگذاری‌شده ممکن است با کپی ساده قابل استفاده نشود؛ پروفایل قبلی را تا تأیید انتقال کامل نگه دارید.

برای جزئیات، روی همان کلاینت فایل C:\Windows\Debug\Netsetup.log را باز کنید و بخش هم‌زمان با تلاش ناموفق را بخوانید. این لاگ معمولاً از قبل فعال است. خطای آخر، نام DC و زمان را ثبت کنید؛ یک کد جدا از زمینهٔ همان تلاش را تشخیص قطعی فرض نکنید.

در استفادهٔ دوباره از Computer Account، مجوز تغییر حساب و شرایط مالک مورداعتماد هر دو اهمیت دارند. تنظیم قدیمی NetJoinLegacyAccountReuse از به‌روزرسانی‌های اوت ۲۰۲۴ دیگر پشتیبانی نمی‌شود. برای عبور از خطا حساب فعال را حذف نکنید، مالکیت را دستی عوض نکنید و گروه‌های فراگیر را به فهرست اعتماد اضافه نکنید؛ مالک فرایند Join باید حساب و سیاست را اصلاح کند.

نتیجهٔ نهایی باید نام دستگاه و دامین، محل Computer Object، ورود حساب عادی و وضعیت دادهٔ کاربر را مشخص کند. اگر فقط دسترسی پوشه مشکل دارد، عیب‌یابی پوشهٔ اشتراکی را ادامه دهید؛ برای اعمال سیاست هم آموزش GPO مسیر جداگانه دارد.

اگر لازم شد از تصمیم Join برگردید، ابتدا دسترسی محلی، پشتیبان داده و وابستگی برنامه‌ها را بررسی و با مدیر شبکه هماهنگ کنید. خروج از دامین یا حذف حساب کامپیوتر را پاسخ خودکار هر خطا قرار ندهید. دستگاهی که عضو شده و کاربر روی آن داده ساخته، دیگر یک کلاینت آزمایشی خالی نیست.