از نصب Server تا ساخت Domain؛ هر مرحله را با دلیل و روش بررسی یاد بگیر
در این پک یک شرکت فرضی را از Server خام به Domain عملیاتی میرسانیم. هرجا تنظیمی انجام میدهیم، دلیلش را توضیح میدهیم و هرجا خطای رایجی وجود دارد، میگوییم اگر آن خطا را دیدی چه چیزی احتمالاً خراب است و قدم بعدی چیست
مسیر نصب این آموزش بر اساس Windows Server 2025 Desktop Experience نوشته شده. بخش AD DS با Server Manager آموزش داده میشود تا برای مخاطب تازهکار قابل فهم باشد
قبل از نصب؛ سناریوی Server را مشخص کن
پیش از Boot کردن فایل ISO، باید دقیقاً مشخص باشد این Server قرار است چه نقشی در شبکه داشته باشد. اگر قرار است این Server به Domain Controller تبدیل شود، از همان ابتدا نام Server، برنامه آدرسدهی، طراحی DNS، محل Backup و نقشهای موردنیاز را مشخص کن. نصب بدون برنامه مشخص معمولاً بعداً با مشکلاتی مثل تغییر نام، IP نامناسب یا تنظیم اشتباه DNS خودش را نشان میدهد.
- نام پیشنهادی Server را از قبل تعیین کن؛ مثل DC01
- IP ثابت رزروشده را مشخص کن
- Subnet، Gateway و طراحی DNS را از قبل ثبت کن
- اگر Server مجازی است، Snapshot را جای Backup کامل و قابل بازیابی در نظر نگیر
توضیح تکمیلی
پیش از نصب باید نقش Server روشن باشد. نام، IP، DNS و روش Backup از همان ابتدا باید با نقشی که برای Server در نظر گرفته شده هماهنگ باشند تا بعداً مجبور به اصلاح پایههای زیرساخت نشوی.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
پیش از نصب باید نقش Server روشن باشد. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. در این تمرین، انتخابهای Setup را با نقش نهایی Server مقایسه کن تا اثر هر تصمیم را بعد از نصب هم ببینی.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: پیش از نصب باید نقش Server روشن باشد.
نکته اصلی این درس
پیش از نصب باید نقش Server روشن باشد.
نسخه و Installation Option را درست انتخاب کن
Windows Server 2025 را میتوان بهصورت Server Core یا Server with Desktop Experience نصب کرد. برای این مسیر آموزشی، Desktop Experience انتخاب بهتری است چون Server Manager، ADUC، DNS Manager و GPMC را بهصورت GUI میبینی. در بعضی محیطهای عملیاتی، Server Core میتواند انتخاب مناسبی باشد، اما برای شروع یادگیری GUI قابل فهمتر است.
- اگر گزینهای عبارت Desktop Experience ندارد، GUI کامل نصب نمیشود
- بعداً نمیتوانی بهسادگی Core را به Desktop Experience تبدیل کنی؛ انتخاب را قبل از نصب جدی بگیر
توضیح تکمیلی
این مرحله درباره انتخاب نسخه مناسب Windows Server است. Standard و Datacenter و همچنین Server Core و Desktop Experience تفاوتهای واقعی دارند و انتخاب باید بر اساس License، قابلیتهای موردنیاز و روش مدیریت Server انجام شود.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
این مرحله درباره انتخاب نسخه مناسب Windows Server است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. نسخه Windows Server را بر اساس Role، امکانات موردنیاز و مجوز واقعی انتخاب کن تا بعد از نصب مجبور به اصلاح یک تصمیم پایهای نشوی.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: این مرحله درباره انتخاب نسخه مناسب Windows Server است.
نکته اصلی این درس
این مرحله درباره انتخاب نسخه مناسب Windows Server است.
Boot از ISO یا USB
در سرور فیزیکی باید Boot Order یا Boot Menu را طوری تنظیم کنی که Server از USB/DVD بوت شود. در VM کافی است ISO را به Virtual CD/DVD متصل و Boot را از ISO انجام بدهی.
- اگر Press any key را رد کنی ممکن است سیستم دوباره از Disk قبلی Boot شود
- در سرور واقعی کلید Boot Menu بسته به Vendor متفاوت است
توضیح تکمیلی
Boot از ISO یا USB فقط برای شروع Setup است. نکته مهم این است که پس از اولین Restart، Server از Disk نصبشده ادامه دهد و دوباره وارد Setup از ابتدا نشود.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
Boot از ISO یا USB فقط برای شروع Setup است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. Boot از ISO یا USB فقط نقطه شروع Setup است؛ بعد از نصب باید مطمئن شوی Server از Disk درست بوت میشود و Media نصب دیگر در مسیر Boot باقی نمانده است.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Boot از ISO یا USB فقط برای شروع Setup است.
نکته اصلی این درس
Boot از ISO یا USB فقط برای شروع Setup است.
Language و Keyboard
در Windows Server 2025 ابتدا صفحه انتخاب زبان، Time/Currency و سپس Keyboard را میبینی. این تنظیمها روی تجربه اولیه Setup اثر دارند اما بعداً قابل تغییرند. Keyboard اشتباه در مرحله Password میتواند باعث شود فکر کنی رمز را درست میزنی ولی Character دیگری ثبت شود.
- برای Administrator Password به Layout کیبورد دقت کن
- اگر رمز دارای Symbol است، جای کلیدها را قبل از ادامه بررسی کن
توضیح تکمیلی
Language، Region و Keyboard روی روند Setup و مخصوصاً وارد کردن Password اثر دارند. تفاوت Keyboard Layout میتواند باعث شود رمزی که تصور میکنی وارد کردهای با چیزی که Windows ثبت کرده متفاوت باشد.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
Language، Region و Keyboard روی روند Setup و مخصوصاً وارد کردن Password اثر دارند. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. تنظیم Language، Region و Keyboard را قبل از ادامه کنترل کن، چون همین انتخابهای ساده میتوانند هنگام ورود Password و کار مدیریتی باعث خطای انسانی شوند.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Language، Region و Keyboard روی روند Setup و مخصوصاً وارد کردن Password اثر دارند.
نکته اصلی این درس
Language، Region و Keyboard روی روند Setup و مخصوصاً وارد کردن Password اثر دارند.
Select setup option
گزینه Install Windows Server را انتخاب میکنی و تأیید میکنی نصب پاک انجام میشود. این مرحله را روی Server دارای Data بدون Backup انجام نده چون Clean Install میتواند اطلاعات موجود را از بین ببرد.
- اگر Server قبلاً Data دارد، قبل از ادامه Backup مستقل داشته باش
- Disk مقصد را با Disk دیتا اشتباه نگیر
توضیح تکمیلی
در این قسمت وارد نصب واقعی Windows Server میشوی. اگر Server یا Disk مقصد Data دارد، قبل از ادامه باید مطمئن باشی Backup لازم وجود دارد و Clean Install روی سیستم درست انجام میشود.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
در این قسمت وارد نصب واقعی Windows Server میشوی. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. در مراحل نصب هر گزینه را با وضعیت نهایی مورد انتظار Server تطبیق بده و قبل از ادامه بدان آن انتخاب بعد از نصب چه اثری خواهد داشت.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: در این قسمت وارد نصب واقعی Windows Server میشوی.
نکته اصلی این درس
در این قسمت وارد نصب واقعی Windows Server میشوی.
Licensing Method و Edition
در Windows Server 2025 ممکن است گزینه Product Key یا Pay-as-you-go ببینی. سپس Edition متناسب با License را انتخاب میکنی. Standard و Datacenter قابلیتها و حقوق مجازیسازی متفاوت دارند؛ انتخاب Edition باید مطابق License واقعی سازمان باشد.
- نسخه Evaluation را معادل License نهایی محیط عملیاتی در نظر نگیر
- Edition اشتباه میتواند بعداً Activation یا Feature Planning را پیچیده کند
توضیح تکمیلی
Licensing Method و Edition باید با مجوز واقعی سازمان هماهنگ باشند. نسخه Evaluation برای Lab مناسب است اما نباید بدون برنامه به محیط عملیاتی منتقل شود.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
Licensing Method و Edition باید با مجوز واقعی سازمان هماهنگ باشند. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. Edition و روش Licensing باید از همان ابتدا با مجوز و نیاز واقعی سازمان هماهنگ باشند تا Server در محیط عملیاتی با محدودیت یا عدم انطباق روبهرو نشود.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Licensing Method و Edition باید با مجوز واقعی سازمان هماهنگ باشند.
نکته اصلی این درس
Licensing Method و Edition باید با مجوز واقعی سازمان هماهنگ باشند.
Desktop Experience را قبل از نصب بررسی کن
هنگام انتخاب Image مطمئن شو عبارت Desktop Experience در نام Edition مورد نظر وجود دارد. اگر آن را نبینی، احتمالاً Server Core نصب خواهد شد.
- اگر بعد از نصب Desktop و Server Manager ندیدی، ممکن است Core انتخاب کرده باشی
- برای این پک آموزشی Desktop Experience را انتخاب کن
توضیح تکمیلی
Desktop Experience نوع رابط و شیوه مدیریت Windows Server را تعیین میکند. انتخاب آن باعث میشود محیط گرافیکی کامل و ابزارهایی مثل Server Manager در دسترس باشند؛ در مقابل Server Core رابط محدودتری دارد و بیشتر برای مدیریت از راه دور یا خط فرمان مناسب است.
در عمل چه کار میکنیم؟
- در فهرست Imageها گزینه دارای عبارت Desktop Experience را پیدا کن
- نام کامل Edition انتخابشده را بخوان
- پس از نصب وجود Desktop و Server Manager را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Server Core بهجای Desktop Experience انتخاب شده | بعد از نصب Desktop کامل و Server Manager به شکل مورد انتظار دیده نمیشود |
| Desktop Experience با عضویت Domain اشتباه گرفته شده | این گزینه شیوه مدیریت Windows Server را تغییر میدهد، نه مفهوم Domain را |
چطور نتیجه را بررسی کنیم؟
- در صورت انتخاب Desktop Experience، Desktop کامل و Server Manager در دسترس باشند
- بدانی Server Core نیز میتواند Roleهای Server را اجرا کند و تفاوت اصلی در رابط مدیریت است
مثال عملی
Desktop Experience نوع رابط و شیوه مدیریت Windows Server را تعیین میکند. در یک Lab دو VM نصب میکنی؛ یکی Server Core و دیگری Desktop Experience. هر دو میتوانند AD DS را اجرا کنند، اما روش مدیریت آنها متفاوت است. این مقایسه دقیقاً نشان میدهد Desktop Experience چه چیزی را تغییر میدهد.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Desktop Experience نوع رابط و شیوه مدیریت Windows Server را تعیین میکند.
نکته اصلی این درس
میدانم Desktop Experience روی محیط مدیریتی Windows Server اثر میگذارد و آن را با عضویت Domain اشتباه نمیگیرم.
Disk و Partition
در صفحه Select location to install Windows Server، Disk مورد نظر برای نصب را با دقت انتخاب کن. در یک Lab ساده میتوانی فضای Unallocated را انتخاب کنی تا Setup Partitionهای لازم را بسازد. در محیط عملیاتی، چیدمان دیسک باید با طراحی RAID و Storage سازمان هماهنگ باشد.
- Disk Number را فقط از روی اندازه حدس نزن
- اگر Storage Controller Disk را نشان نمیدهد، ممکن است Driver لازم باشد
- در Legacy BIOS با چند Disk، ترتیب Disk میتواند روی نصب اثر بگذارد
توضیح تکمیلی
انتخاب Disk مهمترین بخش نصب از نظر حفظ Data است. باید Disk مقصد را با Capacity، RAID و Storage Plan شناسایی کنی و فقط Partitionهایی را تغییر بدهی که مطمئن هستی مربوط به نصب جدید هستند.
در عمل چه کار میکنیم؟
- Diskها را با Capacity و Storage Plan شناسایی کن
- فقط Partitionهای مربوط به نصب جدید را تغییر بده
- Disk مقصد را قبل از Next دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Disk اشتباه انتخاب شده | Data موجود ممکن است حذف شود |
| Disk در Setup دیده نمیشود | Driver Storage Controller یا تنظیم RAID را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
انتخاب Disk مهمترین بخش نصب از نظر حفظ Data است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. در بخش Disk هر انتخاب مستقیماً با حفظ Data و ساختار Storage ارتباط دارد؛ مقصد نصب را فقط بعد از شناسایی دقیق Disk و Partition انتخاب کن.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: انتخاب Disk مهمترین بخش نصب از نظر حفظ Data است.
نکته اصلی این درس
انتخاب Disk مهمترین بخش نصب از نظر حفظ Data است.
Ready to install و شروع Copy
پیش از انتخاب Install، Edition، Disk مقصد و نوع نصب را یک بار دیگر بررسی کن. پس از شروع نصب، Server ممکن است چند بار Restart شود. هنگام Restart، دوباره کلیدی برای Boot از Media نصب فشار نده؛ در غیر این صورت Setup ممکن است از ابتدا اجرا شود.
- Loop شدن Setup معمولاً از Boot دوباره روی ISO/USB رخ میدهد
- در VM بعد از اولین Restart Boot Order را کنترل کن
توضیح تکمیلی
Ready to install آخرین فرصت برای مرور Edition، نوع نصب و Disk مقصد است. بعد از شروع Copy فایلها، اصلاح اشتباهات این بخش معمولاً نیاز به توقف یا نصب مجدد دارد.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
Ready to install آخرین فرصت برای مرور Edition، نوع نصب و Disk مقصد است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. صفحه Ready to install آخرین نقطه کنترل قبل از اعمال تغییرات است؛ Edition، نوع نصب و Disk مقصد را یکبار دیگر با برنامه نصب تطبیق بده.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Ready to install آخرین فرصت برای مرور Edition، نوع نصب و Disk مقصد است.
نکته اصلی این درس
Ready to install آخرین فرصت برای مرور Edition، نوع نصب و Disk مقصد است.
Administrator Password
بعد از نصب، برای حساب Built-in Administrator رمز قوی تعیین میکنی. این حساب در مرحله قبل از Domain تنها حساب مدیریتی اصلی سیستم است. رمز را در Password Manager سازمانی نگهداری کن و آن را در فایل متنی معمولی ذخیره نکن.
- اگر Password Policy قبول نکرد، پیچیدگی و طول رمز را بررسی کن
- Keyboard Layout اشتباه یکی از علتهای رایج عدم ورود بعد از نصب است
توضیح تکمیلی
Administrator Password اولین Credential مدیریتی Server است. این رمز باید قوی، امن و در Password Manager سازمانی قابل بازیابی باشد.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
Administrator Password اولین Credential مدیریتی Server است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. Password اولیه Administrator بخشی از امنیت پایه Server است؛ آن را طبق Policy سازمان تنظیم کن و نحوه نگهداری امن Credential را از همان ابتدا مشخص داشته باش.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Administrator Password اولین Credential مدیریتی Server است.
نکته اصلی این درس
Administrator Password اولین Credential مدیریتی Server است.
اولین Login و Desktop
بعد از Login، Windows Server 2025 Desktop Experience ظاهری نزدیک به Windows 11 دارد و Server Manager معمولاً باز میشود. هنوز Server برای تبدیل شدن به DC آماده نیست؛ ابتدا نام، IP، DNS و Update را تنظیم میکنیم.
- قبل از نصب Role، Server را Rename کن
- قبل از Promotion به DC، IP را Static کن
توضیح تکمیلی
اولین Login فقط پایان نصب سیستمعامل است. قبل از نصب Roleها باید وضعیت نام Server، Network، Time، Update و Storage بررسی شود.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
اولین Login فقط پایان نصب سیستمعامل است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. اولین Login را پایان کار ندان؛ بعد از ورود باید وضعیت Driver، Update، Network، Time و Eventهای اولیه را کنترل کنی تا Server برای مرحله بعد آماده باشد.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: اولین Login فقط پایان نصب سیستمعامل است.
نکته اصلی این درس
اولین Login فقط پایان نصب سیستمعامل است.
Rename Server
نام Computer را از نام تصادفی Setup به یک نام سازمانی مثل DC01 تغییر بده. تغییر نام قبل از Promotion خیلی سادهتر و تمیزتر از Rename کردن یک Domain Controller بعد از راهاندازی است.
- نام کوتاه، قابل مستندسازی و یکتا انتخاب کن
- بعد از Rename معمولاً Restart لازم است
توضیح تکمیلی
نام Server بخشی از هویت مدیریتی آن در DNS، Monitoring و مستندات است. بهتر است قبل از Promotion یا نصب سرویسهای حساس، نام نهایی و یکتا تعیین شود.
در عمل چه کار میکنیم؟
- نام نهایی را از Naming Convention بردار
- Server را Rename کن
- Restart انجام بده
- با hostname نام جدید را تأیید کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
نام Server بخشی از هویت مدیریتی آن در DNS، Monitoring و مستندات است. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. نام Server را از همان ابتدا مطابق Naming Convention سازمان انتخاب کن، چون DNS، Monitoring، Inventory و مستندات بعدی به همین هویت وابسته میشوند.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: نام Server بخشی از هویت مدیریتی آن در DNS، Monitoring و مستندات است.
نکته اصلی این درس
نام Server بخشی از هویت مدیریتی آن در DNS، Monitoring و مستندات است.
Static IP
Domain Controller نباید به IP متغیر DHCP وابسته باشد. IPv4 ثابت، Subnet، Gateway و DNS را طبق IP Plan تنظیم کن. اولین DC که نقش DNS را هم دارد، باید پس از راهاندازی از تنظیم DNS Client متناسب با طراحی همان Domain استفاده کند.
- IP انتخابی داخل Scope DHCP نباشد مگر Reservation/Exclusion درست تعریف شده باشد
- Gateway اشتباه باعث قطع دسترسی به شبکههای دیگر میشود
- Subnet اشتباه میتواند ارتباط Local را نامنظم کند
توضیح تکمیلی
Static IP برای Domain Controller یک الزام عملی است. IP، Subnet، Gateway و DNS باید همگی از IP Plan گرفته شوند و با DHCP Range و طراحی شبکه تداخل نداشته باشند.
در عمل چه کار میکنیم؟
- IPv4 Properties کارت شبکه اصلی را باز کن
- IP، Subnet، Gateway و DNS را از IP Plan وارد کن
- خروجی ipconfig /all را با مقادیر ثبتشده مقایسه کن
- Gateway و DNS را جداگانه تست کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| IP Conflict | IP انتخابی روی دستگاه دیگری استفاده میشود یا داخل Range آزاد DHCP قرار دارد |
| Gateway یا Subnet اشتباه | ارتباط Server با شبکههای دیگر یا حتی بعضی مقصدهای Local دچار مشکل میشود |
| DNS اشتباه | Domain Join، GPO و پیدا کردن DC مختل میشوند |
چطور نتیجه را بررسی کنیم؟
- ipconfig /all مقادیر IP Plan را نشان دهد
- Gateway قابل دسترس باشد
- DNS مورد نظر پاسخ بدهد
مثال عملی
Static IP برای Domain Controller یک الزام عملی است. برای DC01 آدرس 192.168.10.10 در نظر گرفته شده، اما Scope DHCP از .10 شروع میشود. اگر Exclusion وجود نداشته باشد، DHCP میتواند همان IP را به Client دیگری بدهد و Conflict ایجاد شود.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Static IP برای Domain Controller یک الزام عملی است.
نکته اصلی این درس
میدانم Static IP یک DC باید با IP Plan، DHCP، Gateway و DNS هماهنگ باشد.
DNS قبل از Promotion
DNS مهمترین بخش AD است. برای اولین DC در یک Forest جدید، در Lab معمولاً DNS Client را روی IP خود Server تنظیم میکنیم یا طبق Design محیط آماده میکنیم. برای DC اضافی، قبل از Promotion باید به DNS معتبر Domain موجود اشاره کند.
- روی NIC یک Domain Controller، DNS عمومی مانند 8.8.8.8 را بهعنوان DNS اصلی Domain تنظیم نکن
- اگر DNS اشتباه تنظیم شده باشد، Domain Join، دریافت GPO، Kerberos و پیدا کردن Domain Controller میتوانند دچار مشکل شوند
توضیح تکمیلی
DNS در Active Directory فقط برای اینترنت نیست. DC و Clientها برای پیدا کردن Domain Controller و سرویسهایی مثل Kerberos و LDAP به DNS داخلی Domain وابستهاند.
در عمل چه کار میکنیم؟
- DNS Client روی NIC را بررسی کن
- Resolver داخلی متناسب با سناریوی Domain را تنظیم کن
- نام Server و Domain را با nslookup آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| DNS عمومی روی NIC DC | رکوردهای داخلی Active Directory از آن Resolver پیدا نمیشوند |
| نام Domain Resolve نمیشود | DNS Client، Zone و رکوردهای لازم را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- نام Domain و DC از DNS داخلی Resolve شوند
- DNS Client روی NIC با طراحی Domain مطابقت داشته باشد
مثال عملی
DNS در Active Directory فقط برای اینترنت نیست. Server اینترنت دارد اما Wizard نمیتواند Domain موجود را پیدا کند. DNS روی یک Resolver عمومی تنظیم شده است؛ بنابراین مشکل اینترنت نیست، Server رکوردهای داخلی Active Directory را پیدا نمیکند.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: DNS در Active Directory فقط برای اینترنت نیست.
نکته اصلی این درس
میدانم DNS داخلی برای پیدا کردن سرویسهای Active Directory ضروری است.
Windows Update و Time
قبل از ساخت DC، Updateهای مهم را نصب و Time را کنترل کن. اختلاف زمان شدید بعداً روی Kerberos و Authentication اثر میگذارد. در Lab هم این مرحله را حذف نکن.
- اگر Time Zone اشتباه است اصلاح کن
- بعد از Domain، Time Hierarchy را طبق ساختار AD مدیریت کن
توضیح تکمیلی
پیش از Promotion، Server باید از نظر Update، Pending Restart، Time Zone و ساعت در وضعیت پایدار باشد. اختلاف زمان میتواند Authentication را مختل کند.
در عمل چه کار میکنیم؟
- وضعیت فعلی Server را قبل از تغییر ثبت کن
- تنظیم این مرحله را با برنامه نصب و مستندات شبکه مقایسه کن
- پس از اعمال تغییر، Server را از همان جنبه دوباره بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| انتخاب بدون بررسی انجام میشود | تنظیم نهایی ممکن است با برنامه نصب سازگار نباشد |
| نتیجه فقط از داخل Setup بررسی میشود | بعد از نصب باید همان مورد را در Windows دوباره کنترل کنی |
چطور نتیجه را بررسی کنیم؟
- تنظیم این مرحله بعد از نصب نیز همان وضعیت مورد انتظار را داشته باشد
- هیچ Warning مهمی بدون بررسی باقی نمانده باشد
مثال عملی
پیش از Promotion، Server باید از نظر Update، Pending Restart، Time Zone و ساعت در وضعیت پایدار باشد. در Lab عمداً یک انتخاب اشتباه کوچک ایجاد کن و نتیجه را بعد از نصب ببین. قبل از Promotion، Update، Pending Restart، Time Zone و ساعت Server را پایدار کن تا خطاهای پایهای وارد فرآیند Domain Controller نشوند.
نکته محیط عملیاتی
در محیط عملیاتی، تغییرهای نصب باید با License، Backup، Storage و Change Plan هماهنگ باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: پیش از Promotion، Server باید از نظر Update، Pending Restart، Time Zone و ساعت در وضعیت پایدار باشد.
نکته اصلی این درس
پیش از Promotion، Server باید از نظر Update، Pending Restart، Time Zone و ساعت در وضعیت پایدار باشد.
قبل از کلیک کردن روی Install AD DS، Active Directory را واقعاً بفهم
بخش بعدی عمداً ساده نوشته شده تا مخاطب فقط اسم اصطلاحات را حفظ نکند و بتواند ارتباط Domain، DNS، DC، OU و GPO را در ذهنش بسازد
Active Directory دقیقاً چیست؟
Active Directory Domain Services یک Directory Service است؛ یعنی اطلاعاتی مثل User، Computer، Group، Printer و Policy را بهصورت مرکزی نگه میدارد و کمک میکند کاربران و کامپیوترها در شبکه شناسایی، احراز هویت و مدیریت شوند. بهجای اینکه روی هر PC جداگانه User بسازی، هویت مرکزی داری.
توضیح تکمیلی
Active Directory Domain Services یک Directory Service مرکزی برای مدیریت User، Computer، Group و Policy است. هدف آن این است که هویت و مدیریت شبکه از حالت پراکنده روی تکتک سیستمها خارج شود.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Active Directory Domain Services یک Directory Service مرکزی برای مدیریت User، Computer، Group و Policy است. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Active Directory Domain Services یک Directory Service مرکزی برای مدیریت User، Computer، Group و Policy است.
نکته اصلی این درس
Active Directory Domain Services یک Directory Service مرکزی برای مدیریت User، Computer، Group و Policy است.
Domain چیست؟
Domain یک مرز منطقی مدیریتی و نامگذاری در AD است. وقتی Client عضو domain مثل corp.example.com میشود، میتواند با حساب Domain وارد شود و Policyها و دسترسیهای مرکزی را دریافت کند.
توضیح تکمیلی
Domain یک ساختار منطقی است که Objectها و Policyهای مشترک را در یک فضای نام مشخص نگه میدارد. Client عضو Domain میتواند با حساب Domain وارد شود و تنظیمات مرکزی را دریافت کند.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Domain یک ساختار منطقی است که Objectها و Policyهای مشترک را در یک فضای نام مشخص نگه میدارد. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Domain یک ساختار منطقی است که Objectها و Policyهای مشترک را در یک فضای نام مشخص نگه میدارد.
نکته اصلی این درس
Domain یک ساختار منطقی است که Objectها و Policyهای مشترک را در یک فضای نام مشخص نگه میدارد.
Forest چیست؟
Forest بالاترین ساختار منطقی AD DS است. یک Forest میتواند یک یا چند Domain داشته باشد و Schema و Configuration مشترک دارد. اولین Domainی که میسازی Forest Root Domain است.
توضیح تکمیلی
Forest بالاترین مرز منطقی Active Directory است. Schema و Configuration در سطح Forest مشترکاند و اولین Domain همان Forest Root Domain خواهد بود.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Forest بالاترین مرز منطقی Active Directory است. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Forest بالاترین مرز منطقی Active Directory است.
نکته اصلی این درس
Forest بالاترین مرز منطقی Active Directory است.
Tree چیست؟
اگر چند Domain با فضای نام پیوسته داشته باشی، Tree شکل میگیرد؛ مثلاً corp.example.com و tehran.corp.example.com. برای شرکتهای کوچک معمولاً یک Domain کافی است و نباید بیدلیل ساختار را پیچیده کرد.
توضیح تکمیلی
Tree زمانی معنا دارد که چند Domain با فضای نام پیوسته داخل یک Forest داشته باشی. برای بیشتر شرکتهای کوچک، OUها نیازهای مدیریتی را بدون ساخت Child Domain برطرف میکنند.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Tree زمانی معنا دارد که چند Domain با فضای نام پیوسته داخل یک Forest داشته باشی. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Tree زمانی معنا دارد که چند Domain با فضای نام پیوسته داخل یک Forest داشته باشی.
نکته اصلی این درس
Tree زمانی معنا دارد که چند Domain با فضای نام پیوسته داخل یک Forest داشته باشی.
Domain Controller چیست؟
Domain Controller سروری است که AD DS روی آن اجرا میشود و Database دایرکتوری، Authentication و سرویسهای مرتبط را ارائه میدهد. Domain Controller فقط سروری برای ساخت User نیست؛ یکی از اجزای اصلی سامانه هویت و احراز هویت سازمان است.
توضیح تکمیلی
Domain Controller سروری است که AD DS را اجرا میکند و در Authentication، Directory و معمولاً DNS نقش مرکزی دارد. از دسترس خارج شدن DC میتواند چند سرویس حیاتی را همزمان تحت تأثیر قرار دهد.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Domain Controller سروری است که AD DS را اجرا میکند و در Authentication، Directory و معمولاً DNS نقش مرکزی دارد. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Domain Controller سروری است که AD DS را اجرا میکند و در Authentication، Directory و معمولاً DNS نقش مرکزی دارد.
نکته اصلی این درس
Domain Controller سروری است که AD DS را اجرا میکند و در Authentication، Directory و معمولاً DNS نقش مرکزی دارد.
DNS چرا برای AD حیاتی است؟
DNS در Active Directory فقط برای تبدیل نام Domain به IP استفاده نمیشود؛ AD از رکوردهایی مانند SRV برای پیدا کردن Domain Controller و سرویسهایی مانند LDAP و Kerberos استفاده میکند. به همین دلیل DNS اشتباه یکی از شایعترین علتهای مشکلات Domain است.
توضیح تکمیلی
DNS برای AD نقش سرویس مکانیابی دارد. رکوردهای SRV به Clientها کمک میکنند Domain Controller و سرویسهای Kerberos و LDAP را پیدا کنند.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| DNS عمومی روی NIC DC | رکوردهای داخلی Active Directory از آن Resolver پیدا نمیشوند |
| نام Domain Resolve نمیشود | DNS Client، Zone و رکوردهای لازم را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- نام Domain و DC از DNS داخلی Resolve شوند
- DNS Client روی NIC با طراحی Domain مطابقت داشته باشد
مثال عملی
DNS برای AD نقش سرویس مکانیابی دارد. Client میتواند یک IP بیرونی را Ping کند ولی Domain Join خطا میدهد. وقتی DNS Client به DNS داخلی تغییر میکند، رکوردهای SRV پیدا میشوند و DC Discovery انجام میشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: DNS برای AD نقش سرویس مکانیابی دارد.
نکته اصلی این درس
میدانم Clientهای Domain برای پیدا کردن DC به رکوردهای DNS داخلی و SRV وابستهاند.
OU چیست؟
Organizational Unit ظرف منطقی برای مرتبکردن User، Computer و Group و همچنین Link کردن GPO یا Delegation است. OU را بر اساس نیاز مدیریتی، اعمال GPO و Delegation طراحی کن؛ نه صرفاً برای مرتبتر شدن ظاهر درخت Active Directory.
توضیح تکمیلی
OU برای سازماندهی Objectها، اعمال GPO و Delegation استفاده میشود. OU خوب باید دلیل مدیریتی داشته باشد و فقط برای مرتبتر شدن ظاهر AD ساخته نشود.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
OU برای سازماندهی Objectها، اعمال GPO و Delegation استفاده میشود. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: OU برای سازماندهی Objectها، اعمال GPO و Delegation استفاده میشود.
نکته اصلی این درس
OU برای سازماندهی Objectها، اعمال GPO و Delegation استفاده میشود.
Object چیست؟
در Active Directory هر User، Computer، Group و OU یک Object است و مجموعهای از Attributeها دارد. مثلاً User دارای Name، UPN، SID و Membership است. با فهم Object و Attribute، Active Directory را بهعنوان یک Directory Service میبینی، نه فقط مجموعهای از پنجرههای مدیریتی.
توضیح تکمیلی
در Active Directory هر User، Computer، Group و OU یک Object است و اطلاعات آن در Attributeها نگهداری میشود. فهم این موضوع کمک میکند AD را فراتر از پنجرههای GUI ببینی.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
در Active Directory هر User، Computer، Group و OU یک Object است و اطلاعات آن در Attributeها نگهداری میشود. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: در Active Directory هر User، Computer، Group و OU یک Object است و اطلاعات آن در Attributeها نگهداری میشود.
نکته اصلی این درس
در Active Directory هر User، Computer، Group و OU یک Object است و اطلاعات آن در Attributeها نگهداری میشود.
Schema چیست؟
Schema تعریف میکند چه نوع Objectها و Attributeهایی در Forest وجود دارند. تغییر Schema موضوع حساسی است و معمولاً در کار روزمره پشتیبان نباید بدون برنامه و Backup انجام شود.
توضیح تکمیلی
Schema تعریف میکند چه Object Classها و Attributeهایی در Forest معتبر هستند. چون تغییر Schema اثر Forest-wide دارد، باید بسیار کنترلشده انجام شود.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Schema تعریف میکند چه Object Classها و Attributeهایی در Forest معتبر هستند. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Schema تعریف میکند چه Object Classها و Attributeهایی در Forest معتبر هستند.
نکته اصلی این درس
Schema تعریف میکند چه Object Classها و Attributeهایی در Forest معتبر هستند.
Global Catalog چیست؟
Global Catalog بخشی از اطلاعات Objectهای Forest را نگه میدارد تا جستجو و بعضی سناریوهای Logon و Universal Group Membership کار کنند. اولین DC یک Forest جدید Global Catalog است.
توضیح تکمیلی
Global Catalog بخشی از اطلاعات Objectهای Forest را برای جستوجو و بعضی سناریوهای Logon نگه میدارد. نقش آن در Forest چند Domain بیشتر دیده میشود.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
Global Catalog بخشی از اطلاعات Objectهای Forest را برای جستوجو و بعضی سناریوهای Logon نگه میدارد. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Global Catalog بخشی از اطلاعات Objectهای Forest را برای جستوجو و بعضی سناریوهای Logon نگه میدارد.
نکته اصلی این درس
Global Catalog بخشی از اطلاعات Objectهای Forest را برای جستوجو و بعضی سناریوهای Logon نگه میدارد.
LDAP و Kerberos را ساده بفهم
LDAP پروتکلی برای دسترسی و Query گرفتن از اطلاعات Directory است. Kerberos پروتکل اصلی احراز هویت در Domainهای مدرن Windows است. وقتی DNS یا Time خراب باشد، Kerberos میتواند شکست بخورد و کاربر خطاهای Logon یا دسترسی ببیند.
توضیح تکمیلی
LDAP و Kerberos دو وظیفه متفاوت دارند: LDAP برای دسترسی به Directory و Kerberos برای Authentication استفاده میشود. DNS و Time از پیشنیازهای مهم Kerberos هستند.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
LDAP و Kerberos دو وظیفه متفاوت دارند: LDAP برای دسترسی به Directory و Kerberos برای Authentication استفاده میشود. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: LDAP و Kerberos دو وظیفه متفاوت دارند: LDAP برای دسترسی به Directory و Kerberos برای Authentication استفاده میشود.
نکته اصلی این درس
LDAP و Kerberos دو وظیفه متفاوت دارند: LDAP برای دسترسی به Directory و Kerberos برای Authentication استفاده میشود.
FSMO Roleها چیستند؟
AD چند عملیات خاص را روی Roleهای مشخص متمرکز میکند: Schema Master، Domain Naming Master، RID Master، PDC Emulator و Infrastructure Master. لازم نیست از همان ابتدا همه جزئیات را حفظ کنی، ولی باید بدانی خاموشکردن یا Demote کردن DC بدون بررسی Roleها خطرناک است.
توضیح تکمیلی
FSMO Roleها عملیات خاص Active Directory را مدیریت میکنند. قبل از Demote کردن یا از دست دادن یک DC باید بدانی این Roleها روی کدام Server قرار دارند.
در عمل چه کار میکنیم؟
- تعریف موضوع را با یک مثال ساده شبکهای مرور کن
- آن را با مفاهیم نزدیکش مقایسه کن تا مرز هرکدام روشن شود
- در AD یا ابزار مدیریتی مرتبط، نمونه واقعی همان مفهوم را مشاهده کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| مفهوم با اصطلاح نزدیکش اشتباه گرفته میشود | تعریف و مثال هر دو را کنار هم مقایسه کن |
| موضوع فقط حفظ میشود | آن را با یک Object یا سناریوی واقعی در AD مرتبط کن |
چطور نتیجه را بررسی کنیم؟
- بتوانی مفهوم را با یک مثال واقعی توضیح بدهی
- تفاوت آن را با اصطلاحات نزدیکش بدانی
مثال عملی
FSMO Roleها عملیات خاص Active Directory را مدیریت میکنند. این مفهوم را روی یک Domain آزمایشی با User، Computer یا Group واقعی پیدا کن و آن را با نزدیکترین مفهوم مشابه مقایسه کن. مشاهده عملی باعث میشود اصطلاح فقط به شکل تعریف حفظ نشود.
نکته محیط عملیاتی
در محیط عملیاتی، این موضوع بخشی از طراحی بلندمدت Active Directory است و نباید فقط برای مرتبتر شدن Console تغییر کند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: FSMO Roleها عملیات خاص Active Directory را مدیریت میکنند.
نکته اصلی این درس
FSMO Roleها عملیات خاص Active Directory را مدیریت میکنند.
از Server معمولی تا اولین Domain Controller
در این قسمت مسیر Server Manager و Active Directory Domain Services Configuration Wizard را قدمبهقدم اجرا میکنیم. تصاویر این مراحل داخل خود آموزش قرار گرفتهاند و هیچ تصویر شبیهسازیشدهای استفاده نشده
نصب Role: Active Directory Domain Services
در Server Manager از Manage → Add Roles and Features وارد Wizard شو. Role-based or feature-based installation را انتخاب کن، Server مقصد را انتخاب کن و Active Directory Domain Services را تیک بزن. Add Features را بزن تا ابزارهای مدیریتی مرتبط هم اضافه شوند.
توضیح تکمیلی
نصب AD DS Role فقط قابلیت Active Directory را به Windows Server اضافه میکند. Server تا زمانی که Promote نشود Domain Controller نخواهد شد.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
نصب AD DS Role فقط قابلیت Active Directory را به Windows Server اضافه میکند. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: نصب AD DS Role فقط قابلیت Active Directory را به Windows Server اضافه میکند.
نکته اصلی این درس
نصب AD DS Role فقط قابلیت Active Directory را به Windows Server اضافه میکند.
Role نصب شد؛ هنوز DC نشده
نصب Role مربوط به AD DS بهتنهایی Server را به Domain Controller تبدیل نمیکند. پس از پایان نصب Role، باید گزینه Promote this server to a domain controller را اجرا کنی تا فرایند Promotion آغاز شود. اگر Wizard را بستی، Notification/Tasks در Server Manager امکان ادامه را میدهد.
توضیح تکمیلی
Promotion مرحلهای است که Server واقعاً به Domain Controller تبدیل میشود. در ابتدای Wizard باید دقیقاً مشخص کنی Forest جدید، Domain جدید یا DC اضافی میسازی.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
Promotion مرحلهای است که Server واقعاً به Domain Controller تبدیل میشود. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Promotion مرحلهای است که Server واقعاً به Domain Controller تبدیل میشود.
نکته اصلی این درس
Promotion مرحلهای است که Server واقعاً به Domain Controller تبدیل میشود.
ساخت New Forest
برای اولین DC، Add a new forest را انتخاب کن و نام Root Domain را وارد کن. از نام تکبخشی مانند COMPANY برای Root Domain استفاده نکن. نام DNS کامل مثل corp.example.com مناسبتر است. نام داخلی را طوری انتخاب کن که با Naming Strategy سازمان سازگار باشد.
توضیح تکمیلی
در New Forest، Root Domain Name پایه فضای نام Active Directory و DNS میشود. نام اشتباه یا تایپی در این مرحله یک تغییر کوچک نیست و روی کل Forest اثر میگذارد.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
در New Forest، Root Domain Name پایه فضای نام Active Directory و DNS میشود. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: در New Forest، Root Domain Name پایه فضای نام Active Directory و DNS میشود.
نکته اصلی این درس
در New Forest، Root Domain Name پایه فضای نام Active Directory و DNS میشود.
Domain Controller Options و DSRM
در این صفحه در این صفحه Functional Level، گزینه DNS Server، وضعیت Global Catalog و DSRM Password را میبینی. برای اولین DC در Forest، DNS و GC معمولاً انتخاب هستند. DSRM Password برای ورود به Directory Services Restore Mode استفاده میشود و باید جداگانه و امن نگهداری شود.
توضیح تکمیلی
Domain Controller Options تنظیمهایی مثل DNS Server، Global Catalog و DSRM Password را مشخص میکند. این گزینهها به سرویسدهی DC و سناریوهای Recovery مربوطاند و باید با طراحی محیط هماهنگ باشند.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
Domain Controller Options تنظیمهایی مثل DNS Server، Global Catalog و DSRM Password را مشخص میکند. DSRM Password هنگام Promotion ثبت نشده و سالها بعد در زمان Recovery کسی آن را نمیداند. این مشکل در روز بحران ایجاد نشده؛ از روز نصب برنامه بازیابی ناقص بوده است.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Domain Controller Options تنظیمهایی مثل DNS Server، Global Catalog و DSRM Password را مشخص میکند.
نکته اصلی این درس
میدانم DSRM Password یک Credential بازیابی مستقل است و باید امن نگهداری شود.
DNS Options و Delegation
در Forest جدید ممکن است Warning مربوط به DNS Delegation ببینی. در بسیاری از Labها یا زمانی که Parent Zone قابل مدیریت وجود ندارد، این Warning مانع Promotion نمیشود. مهم است فرق Warning و Error را بفهمی و بیدلیل Installation را متوقف نکنی.
توضیح تکمیلی
در DNS Options ممکن است Warning مربوط به Delegation دیده شود. این Warning همیشه مانع Promotion نیست و باید بر اساس وجود یا نبود Parent DNS Zone تحلیل شود.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| DNS عمومی روی NIC DC | رکوردهای داخلی Active Directory از آن Resolver پیدا نمیشوند |
| نام Domain Resolve نمیشود | DNS Client، Zone و رکوردهای لازم را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- نام Domain و DC از DNS داخلی Resolve شوند
- DNS Client روی NIC با طراحی Domain مطابقت داشته باشد
مثال عملی
در DNS Options ممکن است Warning مربوط به Delegation دیده شود. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: در DNS Options ممکن است Warning مربوط به Delegation دیده شود.
نکته اصلی این درس
در DNS Options ممکن است Warning مربوط به Delegation دیده شود.
Additional Options و NetBIOS
Wizard برای Domain یک NetBIOS Name پیشنهاد میدهد. معمولاً نسخه کوتاه Domain است. آن را با نامهای موجود شبکه و Legacy Applicationها مقایسه کن و بعد ادامه بده.
توضیح تکمیلی
NetBIOS Name نام کوتاه Domain است و در بعضی سناریوهای قدیمیتر یا نمایش DOMAIN\user دیده میشود. بهتر است کوتاه، یکتا و قابل تشخیص باشد.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
NetBIOS Name نام کوتاه Domain است و در بعضی سناریوهای قدیمیتر یا نمایش DOMAIN\user دیده میشود. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: NetBIOS Name نام کوتاه Domain است و در بعضی سناریوهای قدیمیتر یا نمایش DOMAIN\user دیده میشود.
نکته اصلی این درس
NetBIOS Name نام کوتاه Domain است و در بعضی سناریوهای قدیمیتر یا نمایش DOMAIN\user دیده میشود.
Database، Logs و SYSVOL
در Paths محل NTDS Database، Log و SYSVOL مشخص میشود. در Lab میتوانی Default را نگه داری. در محیط بزرگتر Design Storage میتواند متفاوت باشد. AD Database، Log و SYSVOL را روی ReFS قرار نده.
توضیح تکمیلی
Database، Log و SYSVOL اجزای مهم AD DS هستند. در Lab معمولاً مسیرهای پیشفرض کافیاند، اما در محیطهای بزرگتر ممکن است Storage Design متفاوتی وجود داشته باشد.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
Database، Log و SYSVOL اجزای مهم AD DS هستند. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Database، Log و SYSVOL اجزای مهم AD DS هستند.
نکته اصلی این درس
Database، Log و SYSVOL اجزای مهم AD DS هستند.
Review Options
قبل از Install همه انتخابها را دوباره بررسی کن. View script هم میتواند معادل PowerShell تنظیمات Wizard را نشان دهد و برای مستندسازی مفید باشد.
توضیح تکمیلی
Review Options برای مرور نهایی تنظیمات Promotion است. نام Domain، نوع Deployment، DNS، GC و مسیرها باید با طراحیای که از ابتدا ثبت شده مطابقت داشته باشند.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
Review Options برای مرور نهایی تنظیمات Promotion است. در Lab قبل از زدن Next، از صفحه فعلی Wizard Screenshot بگیر و انتخابها را با طراحی Forest مقایسه کن. اگر گزینهای تغییر کرد، دلیل آن را در Note ثبت کن.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Review Options برای مرور نهایی تنظیمات Promotion است.
نکته اصلی این درس
Review Options برای مرور نهایی تنظیمات Promotion است.
Prerequisites Check
Wizard قبل از Promotion شبکه، DNS، Permission و پیشنیازهای دیگر را بررسی میکند. Warning و Error را یکسان در نظر نگیر. Error باید برطرف شود؛ Warning باید بررسی و بر اساس طراحی محیط تحلیل شود و ممکن است با Design تو قابل قبول باشد.
توضیح تکمیلی
Prerequisites Check آخرین بررسی خودکار پیش از Promotion است. Error باید برطرف شود؛ Warning باید فهمیده و بر اساس طراحی محیط ارزیابی شود.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
Prerequisites Check آخرین بررسی خودکار پیش از Promotion است. Prerequisites Check یک Warning مربوط به DNS Delegation نشان میدهد اما Error بازدارندهای ندارد. قبل از توقف نصب باید بررسی شود آیا Parent Zone در این طراحی اصلاً وجود دارد یا نه.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Prerequisites Check آخرین بررسی خودکار پیش از Promotion است.
نکته اصلی این درس
میتوانم Warning و Error در Prerequisites Check را از هم تفکیک کنم.
Promotion و Restart
بعد از Install، Server به DC تبدیل و Restart میشود. پس از Boot، Login Context تغییر میکند و حسابهای Domain در دسترساند. حالا باید DNS، AD DS، SYSVOL و سلامت اولیه DC را بررسی کنی.
توضیح تکمیلی
بعد از Promotion و Restart، فقط Login موفق کافی نیست. AD DS، DNS، SYSVOL، NETLOGON و Eventهای مهم باید جداگانه بررسی شوند.
در عمل چه کار میکنیم؟
- صفحه فعلی Wizard را کامل بخوان
- انتخابها را با سناریوی New Forest یا Domain موجود تطبیق بده
- قبل از Next نام Domain، Server و گزینههای اصلی را دوباره بررسی کن
- پس از پایان Wizard نتیجه را از ابزار دیگری نیز کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| گزینه Wizard بدون توجه به سناریو انتخاب میشود | نتیجه Promotion با طراحی Forest سازگار نخواهد بود |
| Warning و Error یکی فرض میشوند | Error را رفع و Warning را تحلیل کن |
چطور نتیجه را بررسی کنیم؟
- گزینههای Wizard با طراحی Forest و Domain مطابقت داشته باشند
- پس از Promotion سرویس مرتبط بدون خطای بحرانی کار کند
مثال عملی
بعد از Promotion و Restart، فقط Login موفق کافی نیست. Server بعد از Promotion بالا میآید و Login موفق است، اما SYSVOL Share دیده نمیشود. این یعنی هنوز نباید DC را سالم فرض کرد و باید وضعیت Replication و Eventهای مرتبط بررسی شود.
نکته محیط عملیاتی
در محیط عملیاتی، Promotion و تنظیمات مرتبط با آن باید با Backup، Naming، DNS و برنامه بازگشت انجام شوند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: بعد از Promotion و Restart، فقط Login موفق کافی نیست.
نکته اصلی این درس
میدانم Login موفق بعد از Promotion بهتنهایی سلامت DC را ثابت نمیکند.
خطا را ببین و محدوده مشکل را سریع پیدا کن
| پیام یا نشانه | برداشت و قدم بعدی |
|---|---|
| AD DS Role نصب میشود اما Promote گزینه ظاهر نمیشود | Server Manager Notification را Refresh کن، Role Installation Result را بررسی کن، Server Manager را دوباره باز کن و مطمئن شو AD DS Role واقعاً Installed است |
| Prerequisite: DNS delegation warning | در New Forest یا ساختاری که Parent DNS Delegation قابل ایجاد نیست میتواند Warning باشد؛ اگر Root Domain جدید است معمولاً مانع نصب نیست، اما Design DNS را بررسی کن |
| Prerequisite: RPC server unavailable | Firewall، WMI/RPC، Network Connectivity و Remote Management را بررسی کن |
| Join: DNS name does not exist | Client DNS اشتباه، Zone یا SRV Record مشکل، یا نام Domain اشتباه |
| GPO: Denied (Security) | Security Filtering یا Read/Apply Group Policy Permission را بررسی کن |
| DHCP: Authorization failed | ارتباط DHCP Server با AD، Credential/Permission و DNS/Domain Connectivity را بررسی کن |
| File Share: System error 53 | Name Resolution، SMB، Firewall یا مسیر UNC اشتباه |
| File Share: Access is denied | Authentication، Share Permission، NTFS Permission و Group Membership |
| Trust relationship failed | Machine Account Password/Secure Channel، DNS، Time یا Computer Account |
| Kerberos errors | Time skew، DNS، SPN یا ارتباط با DC/KDC را بررسی کن |
بعد از Promotion چه چیزهایی را بررسی کنیم؟
Server Manager را باز کن و مطمئن شو AD DS و DNS بدون Alert بحرانی هستند. سپس DNS Zone، AD Users and Computers و Event Viewer را بررسی کن. وجود Desktop و Login موفق کافی نیست؛ سرویسهای هویت باید سالم باشند.
توضیح تکمیلی
Health Check اولیه بعد از Promotion کمک میکند قبل از Join کردن Clientها، مشکلات پایه DNS، SYSVOL یا Directory Service شناسایی شوند.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Health Check اولیه بعد از Promotion کمک میکند قبل از Join کردن Clientها، مشکلات پایه DNS، SYSVOL یا Directory Service شناسایی شوند. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Health Check اولیه بعد از Promotion کمک میکند قبل از Join کردن Clientها، مشکلات پایه DNS، SYSVOL یا Directory Service شناسایی شوند.
نکته اصلی این درس
Health Check اولیه بعد از Promotion کمک میکند قبل از Join کردن Clientها، مشکلات پایه DNS، SYSVOL یا Directory Service شناسایی شوند.
Active Directory Users and Computers
ADUC ابزار اصلی برای مدیریت User، Group، Computer و OU است. از Server Manager → Tools → Active Directory Users and Computers بازش کن. قبل از ساخت Userهای واقعی، ساختار OU را طراحی کن.
توضیح تکمیلی
Active Directory Users and Computers ابزار اصلی مدیریت User، Group، Computer و OU است. محل Objectها در AD روی GPO و Delegation اثر مستقیم دارد.
در عمل چه کار میکنیم؟
- OU مقصد را انتخاب کن
- User را طبق Naming Standard بساز
- Password و Account Options را تنظیم کن
- Membership لازم را از طریق Groupها اعمال کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Active Directory Users and Computers ابزار اصلی مدیریت User، Group، Computer و OU است. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Active Directory Users and Computers ابزار اصلی مدیریت User، Group، Computer و OU است.
نکته اصلی این درس
Active Directory Users and Computers ابزار اصلی مدیریت User، Group، Computer و OU است.
OU Design ساده و درست
برای یک شرکت کوچک میتوانی OUهایی مثل Users، Computers، Servers و سپس Departmentهای لازم داشته باشی. ساختار را فقط وقتی لایهلایه کن که برای GPO، Delegation یا مدیریت نیاز داری. OU زیاد بدون هدف، عیبیابی GPO را سخت میکند.
توضیح تکمیلی
OU Design باید ساده و هدفمند باشد. هر OU بهتر است برای GPO، Delegation یا تفکیک مدیریتی دلیل مشخصی داشته باشد.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
OU Design باید ساده و هدفمند باشد. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: OU Design باید ساده و هدفمند باشد.
نکته اصلی این درس
OU Design باید ساده و هدفمند باشد.
ساخت User
در OU مناسب New → User را بزن، نام، Logon Name و Password Policy را تنظیم کن. گزینه User must change password at next logon برای User جدید معمولاً مفید است. Account را مستقیم داخل Domain Admins نگذار مگر واقعاً Administrator باشد.
توضیح تکمیلی
ساخت User فقط وارد کردن نام و Password نیست. User باید در OU درست قرار بگیرد، Naming Standard را رعایت کند و دسترسیهایش از طریق Groupها مدیریت شوند.
در عمل چه کار میکنیم؟
- OU مقصد را انتخاب کن
- User را طبق Naming Standard بساز
- Password و Account Options را تنظیم کن
- Membership لازم را از طریق Groupها اعمال کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
ساخت User فقط وارد کردن نام و Password نیست. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: ساخت User فقط وارد کردن نام و Password نیست.
نکته اصلی این درس
ساخت User فقط وارد کردن نام و Password نیست.
Group را درست بفهم
Group برای مدیریت دسترسی است. بهجای دادن Permission مستقیم به تکتک Userها، User را عضو Group کن و Permissionها را تا حد امکان به Groupها اختصاص بده. این کار تغییر نیرو و Audit را سادهتر میکند.
توضیح تکمیلی
Group برای سادهکردن مدیریت دسترسی استفاده میشود. بهجای تغییر ACL برای هر User، Membership گروه تغییر میکند و Resource دستنخورده میماند.
در عمل چه کار میکنیم؟
- نقش یا Resource مورد نظر را مشخص کن
- Group با Type و Scope مناسب بساز
- Membership را طبق طراحی اضافه کن
- Permission را روی Group دسترسی اعمال کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Group برای سادهکردن مدیریت دسترسی استفاده میشود. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Group برای سادهکردن مدیریت دسترسی استفاده میشود.
نکته اصلی این درس
Group برای سادهکردن مدیریت دسترسی استفاده میشود.
Security Group و Distribution Group
Security Group برای Permission و Access Control استفاده میشود. Distribution Group بیشتر برای Email Distribution طراحی شده و برای NTFS Permission انتخاب اصلی نیست.
توضیح تکمیلی
Security Group برای Permission و Access Control استفاده میشود؛ Distribution Group بیشتر برای توزیع پیام طراحی شده است. انتخاب Type باید با هدف Group سازگار باشد.
در عمل چه کار میکنیم؟
- نقش یا Resource مورد نظر را مشخص کن
- Group با Type و Scope مناسب بساز
- Membership را طبق طراحی اضافه کن
- Permission را روی Group دسترسی اعمال کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Security Group برای Permission و Access Control استفاده میشود؛ Distribution Group بیشتر برای توزیع پیام طراحی شده است. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Security Group برای Permission و Access Control استفاده میشود؛ Distribution Group بیشتر برای توزیع پیام طراحی شده است.
نکته اصلی این درس
Security Group برای Permission و Access Control استفاده میشود؛ Distribution Group بیشتر برای توزیع پیام طراحی شده است.
Group Scope: Global، Domain Local، Universal
در یک Domain ساده، الگوی رایج این است که Userها عضو Global Group مربوط به Role/Department شوند و Global Group عضو Domain Local Group مربوط به Resource شود. سپس Permission روی Resource به Domain Local داده شود.
توضیح تکمیلی
Group Scope تعیین میکند اعضای Group از کجا میتوانند باشند و Group در کجا استفاده شود. در یک Domain ساده، Global و Domain Local در الگوی AGDLP نقش مهمی دارند.
در عمل چه کار میکنیم؟
- نقش یا Resource مورد نظر را مشخص کن
- Group با Type و Scope مناسب بساز
- Membership را طبق طراحی اضافه کن
- Permission را روی Group دسترسی اعمال کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Client آدرس 169.254 میگیرد | Lease از DHCP دریافت نشده است |
| DNS یا Gateway اشتباه به Client میرسد | Optionهای Scope را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Client Lease معتبر بگیرد
- Gateway و DNS دریافتی با طراحی شبکه مطابقت داشته باشند
مثال عملی
Group Scope تعیین میکند اعضای Group از کجا میتوانند باشند و Group در کجا استفاده شود. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Group Scope تعیین میکند اعضای Group از کجا میتوانند باشند و Group در کجا استفاده شود.
نکته اصلی این درس
Group Scope تعیین میکند اعضای Group از کجا میتوانند باشند و Group در کجا استفاده شود.
AGDLP به زبان ساده
Accounts → Global Groups → Domain Local Groups → Permissions. یعنی User را مستقیم روی Folder Permission نده؛ User را عضو گروه شغلی کن، آن گروه را داخل گروه دسترسی Resource بگذار و Permission را روی گروه Resource اعمال کن.
توضیح تکمیلی
AGDLP کمک میکند نقش کاربر را از Permission Resource جدا کنی: Account داخل Global Group، آن Group داخل Domain Local و Permission روی Domain Local قرار میگیرد.
در عمل چه کار میکنیم؟
- نقش یا Resource مورد نظر را مشخص کن
- Group با Type و Scope مناسب بساز
- Membership را طبق طراحی اضافه کن
- Permission را روی Group دسترسی اعمال کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
AGDLP کمک میکند نقش کاربر را از Permission Resource جدا کنی: Account داخل Global Group، آن Group داخل Domain Local و Permission روی Domain Local قرار میگیرد. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: AGDLP کمک میکند نقش کاربر را از Permission Resource جدا کنی: Account داخل Global Group، آن Group داخل Domain Local و Permission روی Domain Local قرار میگیرد.
نکته اصلی این درس
AGDLP کمک میکند نقش کاربر را از Permission Resource جدا کنی: Account داخل Global Group، آن Group داخل Domain Local و Permission روی Domain Local قرار میگیرد.
Computer Object و Join به Domain
قبل از Join، Client عضو Domain باید DNS داخلی همان Domain را استفاده کند. سپس در Windows 11 از System Properties یا Settings نام Domain را وارد کن و نام کاربری و رمز عبور یک حساب مجاز را وارد کن. پس از نمایش پیام Welcome to the domain، سیستم را Restart کن تا عضویت در Domain کامل شود.
توضیح تکمیلی
Computer Object نماینده دستگاه عضو Domain است. Join موفق به DNS داخلی، زمان مناسب، نام یکتا و Credential مجاز نیاز دارد.
در عمل چه کار میکنیم؟
- روی Client خروجی ipconfig /all را بررسی کن
- نام Domain و DC را Resolve کن
- زمان Client را کنترل کن
- Join یا Secure Channel را تست کن
- بعد از Restart با Domain User وارد شو
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Domain could not be contacted | DNS و مسیر ارتباط با DC را بررسی کن |
| The specified domain does not exist | نام Domain و Zone DNS را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Computer Object در AD صحیح باشد
- Login با Domain User موفق باشد
- Client بتواند DC را از DNS پیدا کند
مثال عملی
Computer Object نماینده دستگاه عضو Domain است. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Computer Object نماینده دستگاه عضو Domain است.
نکته اصلی این درس
Computer Object نماینده دستگاه عضو Domain است.
خطای Domain Join: Domain could not be contacted
اول DNS را بررسی کن، نه Firewall را بهصورت تصادفی. Client باید بتواند Domain Name و DC را از DNS داخلی Resolve کند. `nslookup domain` و بررسی DNS Client از مهمترین تستها هستند.
توضیح تکمیلی
خطای Domain could not be contacted معمولاً به DNS یا Network Path مربوط است. عیبیابی را از ipconfig، DNS Server و Resolve شدن نام Domain و DC شروع کن.
در عمل چه کار میکنیم؟
- روی Client خروجی ipconfig /all را بررسی کن
- نام Domain و DC را Resolve کن
- زمان Client را کنترل کن
- Join یا Secure Channel را تست کن
- بعد از Restart با Domain User وارد شو
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Domain could not be contacted | DNS و مسیر ارتباط با DC را بررسی کن |
| The specified domain does not exist | نام Domain و Zone DNS را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Computer Object در AD صحیح باشد
- Login با Domain User موفق باشد
- Client بتواند DC را از DNS پیدا کند
مثال عملی
خطای Domain could not be contacted معمولاً به DNS یا Network Path مربوط است. یک Client اینترنت دارد اما Join انجام نمیشود. بررسی ipconfig /all نشان میدهد DNS روی مودم تنظیم شده است. بعد از اصلاح DNS، نام Domain و DC قابل Resolve میشوند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: خطای Domain could not be contacted معمولاً به DNS یا Network Path مربوط است.
نکته اصلی این درس
خطای Domain could not be contacted معمولاً به DNS یا Network Path مربوط است.
خطای Domain Join: The specified domain does not exist
ممکن است Domain اشتباه تایپ شده، DNS Zone قابل دسترس نباشد، Client DNS اشتباه داشته باشد یا DC در دسترس نباشد. برای Join کردن، نام Domain را وارد کن؛ IP مستقیم Domain Controller جای نام Domain را نمیگیرد.
توضیح تکمیلی
The specified domain does not exist میتواند از نام اشتباه Domain، DNS نامعتبر یا نبود Zone و رکوردهای لازم ایجاد شود. قبل از بررسی Trust، خود نام و DNS را ثابت کن.
در عمل چه کار میکنیم؟
- روی Client خروجی ipconfig /all را بررسی کن
- نام Domain و DC را Resolve کن
- زمان Client را کنترل کن
- Join یا Secure Channel را تست کن
- بعد از Restart با Domain User وارد شو
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Domain could not be contacted | DNS و مسیر ارتباط با DC را بررسی کن |
| The specified domain does not exist | نام Domain و Zone DNS را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Computer Object در AD صحیح باشد
- Login با Domain User موفق باشد
- Client بتواند DC را از DNS پیدا کند
مثال عملی
The specified domain does not exist میتواند از نام اشتباه Domain، DNS نامعتبر یا نبود Zone و رکوردهای لازم ایجاد شود. یک Client اینترنت دارد اما Join انجام نمیشود. بررسی ipconfig /all نشان میدهد DNS روی مودم تنظیم شده است. بعد از اصلاح DNS، نام Domain و DC قابل Resolve میشوند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: The specified domain does not exist میتواند از نام اشتباه Domain، DNS نامعتبر یا نبود Zone و رکوردهای لازم ایجاد شود.
نکته اصلی این درس
The specified domain does not exist میتواند از نام اشتباه Domain، DNS نامعتبر یا نبود Zone و رکوردهای لازم ایجاد شود.
Trust Relationship Failed
این خطا معمولاً وقتی Machine Account Password بین Client و AD همخوان نیست یا Secure Channel خراب شده رخ میدهد. قبل از Remove/Join مجدد، DNS، Time، Computer Account و Secure Channel را بررسی کن.
توضیح تکمیلی
Trust Relationship Failed معمولاً به Secure Channel بین Computer و Domain مربوط است. DNS، Time و Computer Account باید قبل از Rejoin بررسی شوند.
در عمل چه کار میکنیم؟
- روی Client خروجی ipconfig /all را بررسی کن
- نام Domain و DC را Resolve کن
- زمان Client را کنترل کن
- Join یا Secure Channel را تست کن
- بعد از Restart با Domain User وارد شو
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Trust Relationship Failed | Secure Channel، Time و Computer Account را بررسی کن |
| Rejoin بدون بررسی علت | ممکن است مشکل DNS یا Time همچنان باقی بماند |
چطور نتیجه را بررسی کنیم؟
- Computer Object در AD صحیح باشد
- Login با Domain User موفق باشد
- Client بتواند DC را از DNS پیدا کند
مثال عملی
Trust Relationship Failed معمولاً به Secure Channel بین Computer و Domain مربوط است. یک VM از Snapshot قدیمی Restore شده و Trust Error میدهد. قبل از حذف Computer Object، Time، DNS و Secure Channel بررسی میشوند تا علت اصلی مشخص شود.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Trust Relationship Failed معمولاً به Secure Channel بین Computer و Domain مربوط است.
نکته اصلی این درس
Trust Relationship Failed معمولاً به Secure Channel بین Computer و Domain مربوط است.
GPO چیست؟
Group Policy تنظیمات مرکزی User و Computer را اعمال میکند. یک GPO بهتنهایی روی همه Objectها اعمال نمیشود؛ باید به Site/Domain/OU Link شود و Scope، Security Filtering و ترتیب پردازش روی نتیجه اثر دارند.
توضیح تکمیلی
GPO مجموعهای از تنظیمات User و Computer است که از طریق Site، Domain یا OU Scope میشود. وجود GPO در GPMC بهتنهایی ثابت نمیکند روی Client اعمال شده است.
در عمل چه کار میکنیم؟
- OU و Object هدف را مشخص کن
- Link و Security Filtering را بررسی کن
- Policy را روی Client Refresh کن
- نتیجه را با gpresult کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| GPO در gpresult دیده نمیشود | OU، Link و Scope را بررسی کن |
| Denied (Security) | Security Filtering و Permissionهای Apply/Read را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- gpresult GPO مورد نظر را Applied نشان دهد
- Setting واقعی روی Client دیده شود
مثال عملی
GPO مجموعهای از تنظیمات User و Computer است که از طریق Site، Domain یا OU Scope میشود. یک GPO در GPMC ساخته شده و gpupdate نیز موفق است، اما تنظیم روی Client دیده نمیشود. gpresult نشان میدهد Object در Scope درست نیست؛ تکرار gpupdate بدون اصلاح Scope نتیجهای ندارد.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: GPO مجموعهای از تنظیمات User و Computer است که از طریق Site، Domain یا OU Scope میشود.
نکته اصلی این درس
GPO مجموعهای از تنظیمات User و Computer است که از طریق Site، Domain یا OU Scope میشود.
ساخت و Link کردن GPO
در Group Policy Management روی OU مورد نظر راستکلیک کن و گزینه Create a GPO in this domain, and Link it here را انتخاب کن. برای GPO نام واضح انتخاب کن، آن را Edit کن و فقط Settingهای موردنیاز را فعال کن. GPO را بیدلیل روی کل Domain Link نکن.
توضیح تکمیلی
ساخت GPO باید با نام واضح، Scope محدود و Setting مشخص انجام شود. Link روی Domain Root بدون نیاز میتواند تعداد زیادی سیستم را ناخواسته تحت تأثیر قرار دهد.
در عمل چه کار میکنیم؟
- OU و Object هدف را مشخص کن
- Link و Security Filtering را بررسی کن
- Policy را روی Client Refresh کن
- نتیجه را با gpresult کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| GPO در gpresult دیده نمیشود | OU، Link و Scope را بررسی کن |
| Denied (Security) | Security Filtering و Permissionهای Apply/Read را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- gpresult GPO مورد نظر را Applied نشان دهد
- Setting واقعی روی Client دیده شود
مثال عملی
ساخت GPO باید با نام واضح، Scope محدود و Setting مشخص انجام شود. یک GPO در GPMC ساخته شده و gpupdate نیز موفق است، اما تنظیم روی Client دیده نمیشود. gpresult نشان میدهد Object در Scope درست نیست؛ تکرار gpupdate بدون اصلاح Scope نتیجهای ندارد.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: ساخت GPO باید با نام واضح، Scope محدود و Setting مشخص انجام شود.
نکته اصلی این درس
ساخت GPO باید با نام واضح، Scope محدود و Setting مشخص انجام شود.
Computer Configuration و User Configuration
Computer Configuration هنگام پردازش Computer Account اعمال میشود؛ User Configuration به User مربوط است. اگر Policy کاربر را در OU Computer Link کردهای بدون Loopback، ممکن است انتظار تو برآورده نشود.
توضیح تکمیلی
Computer Configuration و User Configuration دو Scope متفاوت دارند. برای عیبیابی باید بدانی Setting به Computer Account مربوط است یا User Account.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Computer Configuration و User Configuration دو Scope متفاوت دارند. یک GPO در GPMC ساخته شده و gpupdate نیز موفق است، اما تنظیم روی Client دیده نمیشود. gpresult نشان میدهد Object در Scope درست نیست؛ تکرار gpupdate بدون اصلاح Scope نتیجهای ندارد.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Computer Configuration و User Configuration دو Scope متفاوت دارند.
نکته اصلی این درس
Computer Configuration و User Configuration دو Scope متفاوت دارند.
gpupdate و gpresult
`gpupdate /force` Refresh را درخواست میکند اما علت GPO خراب را جادوئی حل نمیکند. `gpresult /r` و گزارش HTML کمک میکنند بفهمی چه GPOهایی Applied یا Denied شدهاند.
توضیح تکمیلی
gpupdate برای Refresh کردن Policy است و gpresult برای فهمیدن نتیجه واقعی. اگر GPO خارج از Scope یا Denied باشد، تکرار gpupdate /force مشکل را حل نمیکند.
در عمل چه کار میکنیم؟
- OU و Object هدف را مشخص کن
- Link و Security Filtering را بررسی کن
- Policy را روی Client Refresh کن
- نتیجه را با gpresult کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| GPO در gpresult دیده نمیشود | OU، Link و Scope را بررسی کن |
| Denied (Security) | Security Filtering و Permissionهای Apply/Read را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- gpresult GPO مورد نظر را Applied نشان دهد
- Setting واقعی روی Client دیده شود
مثال عملی
gpupdate برای Refresh کردن Policy است و gpresult برای فهمیدن نتیجه واقعی. یک GPO در GPMC ساخته شده و gpupdate نیز موفق است، اما تنظیم روی Client دیده نمیشود. gpresult نشان میدهد Object در Scope درست نیست؛ تکرار gpupdate بدون اصلاح Scope نتیجهای ندارد.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: gpupdate برای Refresh کردن Policy است و gpresult برای فهمیدن نتیجه واقعی.
نکته اصلی این درس
میدانم gpupdate Policy را Refresh میکند و gpresult نتیجه واقعی اعمال GPO را نشان میدهد.
GPO اعمال نمیشود؛ دلایل رایج
DNS اشتباه، Link روی OU اشتباه، User/Computer در OU دیگری، Security Filtering، WMI Filter، Permission خواندن GPO، Replication و نیاز به Restart/Sign out از دلایل مهم هستند.
توضیح تکمیلی
وقتی GPO اعمال نمیشود باید OU، Link، Security Filtering، WMI Filter، DNS و Replication را مرحلهبهمرحله بررسی کنی.
در عمل چه کار میکنیم؟
- OU و Object هدف را مشخص کن
- Link و Security Filtering را بررسی کن
- Policy را روی Client Refresh کن
- نتیجه را با gpresult کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| GPO در gpresult دیده نمیشود | OU، Link و Scope را بررسی کن |
| Denied (Security) | Security Filtering و Permissionهای Apply/Read را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- gpresult GPO مورد نظر را Applied نشان دهد
- Setting واقعی روی Client دیده شود
مثال عملی
وقتی GPO اعمال نمیشود باید OU، Link، Security Filtering، WMI Filter، DNS و Replication را مرحلهبهمرحله بررسی کنی. یک GPO در GPMC ساخته شده و gpupdate نیز موفق است، اما تنظیم روی Client دیده نمیشود. gpresult نشان میدهد Object در Scope درست نیست؛ تکرار gpupdate بدون اصلاح Scope نتیجهای ندارد.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: وقتی GPO اعمال نمیشود باید OU، Link، Security Filtering، WMI Filter، DNS و Replication را مرحلهبهمرحله بررسی کنی.
نکته اصلی این درس
وقتی GPO اعمال نمیشود باید OU، Link، Security Filtering، WMI Filter، DNS و Replication را مرحلهبهمرحله بررسی کنی.
نصب DHCP Role
DHCP را از Add Roles and Features نصب کن. در Domain باید DHCP Server باید در Active Directory مجاز (Authorize) شود تا سرویس بهصورت معتبر Lease بدهد. بعد Scope را طبق Subnet واقعی بساز.
توضیح تکمیلی
نصب DHCP Role فقط سرویس را اضافه میکند. در Domain، DHCP Server باید Authorize شود و سپس Scope متناسب با Subnet ساخته شود.
در عمل چه کار میکنیم؟
- Scope و Subnet را بررسی کن
- Exclusion و Reservationها را با IP Plan مقایسه کن
- Optionهای Gateway و DNS را کنترل کن
- روی Client Lease جدید بگیر و ipconfig /all را ببین
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Client آدرس 169.254 میگیرد | Lease از DHCP دریافت نشده است |
| DNS یا Gateway اشتباه به Client میرسد | Optionهای Scope را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Client Lease معتبر بگیرد
- Gateway و DNS دریافتی با طراحی شبکه مطابقت داشته باشند
مثال عملی
نصب DHCP Role فقط سرویس را اضافه میکند. Clientها IP میگیرند اما Domain Join و GPO مشکل دارند. بررسی Lease نشان میدهد Option 006 آدرس DNS عمومی را توزیع میکند؛ DHCP کار میکند ولی Option DNS اشتباه است.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: نصب DHCP Role فقط سرویس را اضافه میکند.
نکته اصلی این درس
نصب DHCP Role فقط سرویس را اضافه میکند.
Scope، Exclusion و Reservation
Scope محدوده Lease است. Exclusion بخشی از Range است که DHCP نباید واگذار کند. Reservation یک IP مشخص را به MAC Client خاص میبندد. Server، Printer و تجهیزات ثابت را بدون Plan داخل Dynamic Range قرار نده.
توضیح تکمیلی
Scope محدوده IPهای قابل واگذاری است، Exclusion بخشی از Range را خارج میکند و Reservation یک IP مشخص را به MAC مشخص اختصاص میدهد.
در عمل چه کار میکنیم؟
- Scope و Subnet را بررسی کن
- Exclusion و Reservationها را با IP Plan مقایسه کن
- Optionهای Gateway و DNS را کنترل کن
- روی Client Lease جدید بگیر و ipconfig /all را ببین
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Client آدرس 169.254 میگیرد | Lease از DHCP دریافت نشده است |
| DNS یا Gateway اشتباه به Client میرسد | Optionهای Scope را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Client Lease معتبر بگیرد
- Gateway و DNS دریافتی با طراحی شبکه مطابقت داشته باشند
مثال عملی
Scope محدوده IPهای قابل واگذاری است، Exclusion بخشی از Range را خارج میکند و Reservation یک IP مشخص را به MAC مشخص اختصاص میدهد. Clientها IP میگیرند اما Domain Join و GPO مشکل دارند. بررسی Lease نشان میدهد Option 006 آدرس DNS عمومی را توزیع میکند؛ DHCP کار میکند ولی Option DNS اشتباه است.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Scope محدوده IPهای قابل واگذاری است، Exclusion بخشی از Range را خارج میکند و Reservation یک IP مشخص را به MAC مشخص اختصاص میدهد.
نکته اصلی این درس
Scope محدوده IPهای قابل واگذاری است، Exclusion بخشی از Range را خارج میکند و Reservation یک IP مشخص را به MAC مشخص اختصاص میدهد.
DHCP Options مهم
Option 003 برای Gateway، Option 006 برای DNS Server و Option 015 برای DNS Domain Name از گزینههای مهم DHCP هستند. اگر DHCP آدرس DNS اشتباه را به Clientها ارائه کند، صدها Client همزمان مشکل Domain پیدا میکنند.
توضیح تکمیلی
DHCP Options اطلاعات مهمی مثل Gateway و DNS را به Client میدهند. Option اشتباه میتواند تعداد زیادی Client را همزمان دچار مشکل کند.
در عمل چه کار میکنیم؟
- Scope و Subnet را بررسی کن
- Exclusion و Reservationها را با IP Plan مقایسه کن
- Optionهای Gateway و DNS را کنترل کن
- روی Client Lease جدید بگیر و ipconfig /all را ببین
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Client آدرس 169.254 میگیرد | Lease از DHCP دریافت نشده است |
| DNS یا Gateway اشتباه به Client میرسد | Optionهای Scope را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Client Lease معتبر بگیرد
- Gateway و DNS دریافتی با طراحی شبکه مطابقت داشته باشند
مثال عملی
DHCP Options اطلاعات مهمی مثل Gateway و DNS را به Client میدهند. Clientها IP میگیرند اما Domain Join و GPO مشکل دارند. بررسی Lease نشان میدهد Option 006 آدرس DNS عمومی را توزیع میکند؛ DHCP کار میکند ولی Option DNS اشتباه است.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: DHCP Options اطلاعات مهمی مثل Gateway و DNS را به Client میدهند.
نکته اصلی این درس
DHCP Options اطلاعات مهمی مثل Gateway و DNS را به Client میدهند.
Client از DHCP آدرس IP دریافت نمیکند
اگر Client 169.254 دارد، Link/VLAN/Scope/Authorization/Relay را بررسی کن. اگر فقط یک Client مشکل دارد، Adapter و Cable را هم بررسی کن. اگر همه Clientهای VLAN مشکل دارند، احتمال مشکل Scope، Server یا Relay بیشتر است.
توضیح تکمیلی
وقتی Client از DHCP آدرس نمیگیرد، باید محدوده خرابی مشخص شود: یک Client، یک VLAN یا کل شبکه. آدرس 169.254.x.x یکی از نشانههای رایج نگرفتن Lease است.
در عمل چه کار میکنیم؟
- Scope و Subnet را بررسی کن
- Exclusion و Reservationها را با IP Plan مقایسه کن
- Optionهای Gateway و DNS را کنترل کن
- روی Client Lease جدید بگیر و ipconfig /all را ببین
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Client آدرس 169.254 میگیرد | Lease از DHCP دریافت نشده است |
| DNS یا Gateway اشتباه به Client میرسد | Optionهای Scope را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Client Lease معتبر بگیرد
- Gateway و DNS دریافتی با طراحی شبکه مطابقت داشته باشند
مثال عملی
وقتی Client از DHCP آدرس نمیگیرد، باید محدوده خرابی مشخص شود: یک Client، یک VLAN یا کل شبکه. Clientها IP میگیرند اما Domain Join و GPO مشکل دارند. بررسی Lease نشان میدهد Option 006 آدرس DNS عمومی را توزیع میکند؛ DHCP کار میکند ولی Option DNS اشتباه است.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: وقتی Client از DHCP آدرس نمیگیرد، باید محدوده خرابی مشخص شود: یک Client، یک VLAN یا کل شبکه.
نکته اصلی این درس
وقتی Client از DHCP آدرس نمیگیرد، باید محدوده خرابی مشخص شود: یک Client، یک VLAN یا کل شبکه.
File Server و Share
یک Folder را Share کردن دو لایه Permission دارد: Share Permission و NTFS Permission. دسترسی نهایی کاربر حاصل ترکیب Share Permission و NTFS Permission است و محدودیت هر دو لایه باید در نظر گرفته شود. برای مدیریت سازمانی از Group استفاده کن.
توضیح تکمیلی
File Server دو لایه Permission دارد: Share و NTFS. Access نهایی باید با Groupهای دسترسی و تست واقعی Userها بررسی شود.
در عمل چه کار میکنیم؟
- Groupهای دسترسی را مشخص کن
- Share و NTFS Permission را جدا بررسی کن
- با User آزمایشی نتیجه را تست کن
- در صورت اختلاف، Effective Access و Group Membership را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Access Denied | Share Permission، NTFS Permission و Membership را جدا بررسی کن |
| User بیش از حد دسترسی دارد | Groupهای اضافی، Inheritance و Full Control را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- User مجاز سطح دسترسی مورد انتظار را داشته باشد
- User غیرمجاز دسترسی اضافه نداشته باشد
مثال عملی
File Server دو لایه Permission دارد: Share و NTFS. کاربر عضو گروه Read است اما میتواند فایل حذف کند. Effective Access نشان میدهد از طریق Group دیگری Modify گرفته است؛ بنابراین باید Membership را اصلاح کرد، نه اینکه Share را از نو ساخت.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: File Server دو لایه Permission دارد: Share و NTFS.
نکته اصلی این درس
File Server دو لایه Permission دارد: Share و NTFS.
NTFS Permission ساده و حرفهای
Read برای مشاهده، Modify برای ایجاد/ویرایش/حذف و Full Control علاوه بر آن امکان تغییر Permission و Ownership را میدهد. به User عادی Full Control نده، مگر اینکه واقعاً نیاز مدیریتی مشخصی وجود داشته باشد.
توضیح تکمیلی
NTFS Permission سطح عملیات روی فایل و Folder را تعیین میکند. Read، Modify و Full Control باید بر اساس نیاز واقعی کاربر انتخاب شوند.
در عمل چه کار میکنیم؟
- Groupهای دسترسی را مشخص کن
- Share و NTFS Permission را جدا بررسی کن
- با User آزمایشی نتیجه را تست کن
- در صورت اختلاف، Effective Access و Group Membership را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Access Denied | Share Permission، NTFS Permission و Membership را جدا بررسی کن |
| User بیش از حد دسترسی دارد | Groupهای اضافی، Inheritance و Full Control را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- User مجاز سطح دسترسی مورد انتظار را داشته باشد
- User غیرمجاز دسترسی اضافه نداشته باشد
مثال عملی
NTFS Permission سطح عملیات روی فایل و Folder را تعیین میکند. کاربر عضو گروه Read است اما میتواند فایل حذف کند. Effective Access نشان میدهد از طریق Group دیگری Modify گرفته است؛ بنابراین باید Membership را اصلاح کرد، نه اینکه Share را از نو ساخت.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: NTFS Permission سطح عملیات روی فایل و Folder را تعیین میکند.
نکته اصلی این درس
NTFS Permission سطح عملیات روی فایل و Folder را تعیین میکند.
Inheritance
Permission والد میتواند به Child منتقل شود. قبل از Disable inheritance بفهم کدام Permissionها inherited هستند. حذف کورکورانه inheritance یکی از علتهای اصلی Access Deniedهای پیچیده است.
توضیح تکمیلی
Inheritance باعث میشود Permissionهای Parent به Child منتقل شوند. قبل از قطع Inheritance باید بدانی کدام دسترسیها موروثی هستند و حذف یا تبدیل آنها چه اثری دارد.
در عمل چه کار میکنیم؟
- Groupهای دسترسی را مشخص کن
- Share و NTFS Permission را جدا بررسی کن
- با User آزمایشی نتیجه را تست کن
- در صورت اختلاف، Effective Access و Group Membership را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Access Denied | Share Permission، NTFS Permission و Membership را جدا بررسی کن |
| User بیش از حد دسترسی دارد | Groupهای اضافی، Inheritance و Full Control را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- User مجاز سطح دسترسی مورد انتظار را داشته باشد
- User غیرمجاز دسترسی اضافه نداشته باشد
مثال عملی
Inheritance باعث میشود Permissionهای Parent به Child منتقل شوند. کاربر عضو گروه Read است اما میتواند فایل حذف کند. Effective Access نشان میدهد از طریق Group دیگری Modify گرفته است؛ بنابراین باید Membership را اصلاح کرد، نه اینکه Share را از نو ساخت.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Inheritance باعث میشود Permissionهای Parent به Child منتقل شوند.
نکته اصلی این درس
Inheritance باعث میشود Permissionهای Parent به Child منتقل شوند.
Effective Access
اگر User میگوید دسترسی ندارد، فقط لیست ACL را نگاه نکن. Effective Access و Group Membership را بررسی کن. Deny صریح و Nested Groupها میتوانند نتیجه را تغییر دهند.
توضیح تکمیلی
Effective Access نشان میدهد User در نهایت چه دسترسیای دارد. Membership چند Group، Inheritance و Deny میتوانند نتیجه را متفاوت از چیزی کنند که در یک ACL منفرد دیده میشود.
در عمل چه کار میکنیم؟
- Groupهای دسترسی را مشخص کن
- Share و NTFS Permission را جدا بررسی کن
- با User آزمایشی نتیجه را تست کن
- در صورت اختلاف، Effective Access و Group Membership را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Access Denied | Share Permission، NTFS Permission و Membership را جدا بررسی کن |
| User بیش از حد دسترسی دارد | Groupهای اضافی، Inheritance و Full Control را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- User مجاز سطح دسترسی مورد انتظار را داشته باشد
- User غیرمجاز دسترسی اضافه نداشته باشد
مثال عملی
Effective Access نشان میدهد User در نهایت چه دسترسیای دارد. کاربر عضو گروه Read است اما میتواند فایل حذف کند. Effective Access نشان میدهد از طریق Group دیگری Modify گرفته است؛ بنابراین باید Membership را اصلاح کرد، نه اینکه Share را از نو ساخت.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Effective Access نشان میدهد User در نهایت چه دسترسیای دارد.
نکته اصلی این درس
Effective Access نشان میدهد User در نهایت چه دسترسیای دارد.
Access-Based Enumeration
ABE باعث میشود Userهایی که Permission ندارند Folder/Shareهای غیرقابلدسترسی را در Browse نبینند. ABE بهتنهایی Permission ایجاد نمیکند؛ فقط نمایش را بر اساس Permission موجود محدود میکند.
توضیح تکمیلی
Access-Based Enumeration فقط نمایش Folderهای غیرقابلدسترسی را محدود میکند. ABE Permission ایجاد نمیکند و امنیت واقعی همچنان به Share و NTFS Permission وابسته است.
در عمل چه کار میکنیم؟
- Groupهای دسترسی را مشخص کن
- Share و NTFS Permission را جدا بررسی کن
- با User آزمایشی نتیجه را تست کن
- در صورت اختلاف، Effective Access و Group Membership را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Access Denied | Share Permission، NTFS Permission و Membership را جدا بررسی کن |
| User بیش از حد دسترسی دارد | Groupهای اضافی، Inheritance و Full Control را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- User مجاز سطح دسترسی مورد انتظار را داشته باشد
- User غیرمجاز دسترسی اضافه نداشته باشد
مثال عملی
Access-Based Enumeration فقط نمایش Folderهای غیرقابلدسترسی را محدود میکند. کاربر عضو گروه Read است اما میتواند فایل حذف کند. Effective Access نشان میدهد از طریق Group دیگری Modify گرفته است؛ بنابراین باید Membership را اصلاح کرد، نه اینکه Share را از نو ساخت.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Access-Based Enumeration فقط نمایش Folderهای غیرقابلدسترسی را محدود میکند.
نکته اصلی این درس
میدانم ABE فقط نمایش را محدود میکند و Permission ایجاد نمیکند.
Map Drive با GPO
برای Map کردن Driveهای سازمانی میتوانی از Group Policy Preferences استفاده کنی و Drive Letter، UNC Path و Targeting را مشخص کن. اگر Mapping نیامد، اول GPO Result، DNS و دسترسی به Share را بررسی کن.
توضیح تکمیلی
Map Drive با Group Policy Preferences به Scope GPO، مسیر UNC، DNS و Permission User وابسته است. برای عیبیابی باید هرکدام جداگانه تست شوند.
در عمل چه کار میکنیم؟
- OU و Object هدف را مشخص کن
- Link و Security Filtering را بررسی کن
- Policy را روی Client Refresh کن
- نتیجه را با gpresult کنترل کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| GPO در gpresult دیده نمیشود | OU، Link و Scope را بررسی کن |
| Denied (Security) | Security Filtering و Permissionهای Apply/Read را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- gpresult GPO مورد نظر را Applied نشان دهد
- Setting واقعی روی Client دیده شود
مثال عملی
Map Drive با Group Policy Preferences به Scope GPO، مسیر UNC، DNS و Permission User وابسته است. کاربر عضو گروه Read است اما میتواند فایل حذف کند. Effective Access نشان میدهد از طریق Group دیگری Modify گرفته است؛ بنابراین باید Membership را اصلاح کرد، نه اینکه Share را از نو ساخت.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Map Drive با Group Policy Preferences به Scope GPO، مسیر UNC، DNS و Permission User وابسته است.
نکته اصلی این درس
Map Drive با Group Policy Preferences به Scope GPO، مسیر UNC، DNS و Permission User وابسته است.
Remote Desktop و مدیریت Remote
RDP ابزار مفیدی برای مدیریت از راه دور است، اما دسترسی آن باید محدود و کنترلشده باشد. Firewall، NLA، Group مجاز و مسیر شبکه را بررسی کن. در دسترس قرار دادن مستقیم RDP روی اینترنت روش مناسبی برای مدیریت Server نیست.
توضیح تکمیلی
Remote Desktop ابزار مدیریت از راه دور است اما باید محدود و کنترلشده باشد. NLA، Firewall، گروه مجاز و Network Path همگی روی اتصال اثر دارند.
در عمل چه کار میکنیم؟
- NLA و فعال بودن RDP را بررسی کن
- User یا Group مجاز را کنترل کن
- Firewall و Network Path را تست کن
- اتصال را از مسیر مدیریتی امن آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Remote Desktop ابزار مدیریت از راه دور است اما باید محدود و کنترلشده باشد. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Remote Desktop ابزار مدیریت از راه دور است اما باید محدود و کنترلشده باشد.
نکته اصلی این درس
Remote Desktop ابزار مدیریت از راه دور است اما باید محدود و کنترلشده باشد.
Event Viewer؛ قبل از حدس Log را بخوان
System، Application، DNS Server و Directory Service Logها برای تشخیص مهماند. فقط وجود کلمه Error را معیار قرار نده؛ زمان Incident، Event ID، Source و Message را کنار هم ببین.
توضیح تکمیلی
Event Viewer زمانی مفید است که Event را با زمان Incident، Source و Event ID تحلیل کنی. هر Error قرمزی الزاماً علت مشکل فعلی نیست.
در عمل چه کار میکنیم؟
- زمان Incident را ثبت کن
- Log مرتبط را باز کن
- بازه زمانی را Filter کن
- Event ID، Source و Message را کنار هم بخوان
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Error قدیمی بهعنوان علت انتخاب میشود | زمان Event را با زمان Incident مقایسه کن |
| فقط Errorها دیده میشوند | Warningهای مرتبط همان بازه را هم بررسی کن |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Event Viewer زمانی مفید است که Event را با زمان Incident، Source و Event ID تحلیل کنی. کاربر میگوید سرویس ساعت 10:15 قطع شده است. با Filter همان بازه، Event مرتبط با Service پیدا میشود و Errorهای نامرتبط روزهای قبل کنار گذاشته میشوند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Event Viewer زمانی مفید است که Event را با زمان Incident، Source و Event ID تحلیل کنی.
نکته اصلی این درس
Event Viewer زمانی مفید است که Event را با زمان Incident، Source و Event ID تحلیل کنی.
Services
سرویس Running بودن به معنی سالم بودن Function نیست. Netlogon، DNS Server، KDC و AD DS مرتبطاند. Serviceهای یک Domain Controller را بدون شناخت اثر آنها Stop یا Restart نکن.
توضیح تکمیلی
Running بودن یک Service فقط State آن را نشان میدهد و سلامت کامل Function را ثابت نمیکند. روی DC، Restart سرویسهای حیاتی باید با شناخت اثر انجام شود.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Running بودن یک Service فقط State آن را نشان میدهد و سلامت کامل Function را ثابت نمیکند. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Running بودن یک Service فقط State آن را نشان میدهد و سلامت کامل Function را ثابت نمیکند.
نکته اصلی این درس
Running بودن یک Service فقط State آن را نشان میدهد و سلامت کامل Function را ثابت نمیکند.
Backup از Domain Controller
Backup معمولی فایلها برای بازیابی کامل Active Directory کافی نیست. System State Backup و استراتژی Backup/Restore مناسب DC اهمیت دارد. Snapshot در Hypervisor را جای Backup معتبر Active Directory در نظر نگیر.
توضیح تکمیلی
Backup از Domain Controller باید امکان Recovery واقعی Active Directory را فراهم کند. Snapshot بهتنهایی جای Backup آزمودهشده را نمیگیرد.
در عمل چه کار میکنیم؟
- نوع Backup موردنیاز را مشخص کن
- موفقیت Job را بررسی کن
- محل Backup را کنترل کن
- روش Restore را در Lab آزمایش و مستند کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Snapshot بهعنوان تنها Backup | Recovery کامل AD تضمین نمیشود |
| Backup بدون Restore Test | قابل بازیابی بودن داده ثابت نشده است |
چطور نتیجه را بررسی کنیم؟
- آخرین Backup موفق مشخص باشد
- روش Restore مستند و آزمایش شده باشد
مثال عملی
Backup از Domain Controller باید امکان Recovery واقعی Active Directory را فراهم کند. Backup هر شب Success است اما هیچ Restore آزمایشی انجام نشده است. تا زمانی که Recovery امتحان نشود، موفق بودن Job بهتنهایی ثابت نمیکند سرویس قابل بازیابی است.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Backup از Domain Controller باید امکان Recovery واقعی Active Directory را فراهم کند.
نکته اصلی این درس
میدانم Backup زمانی قابل اعتماد است که روش Restore آن هم آزموده شده باشد.
dcdiag را برای Health Check یاد بگیر
`dcdiag` مجموعه تستهایی روی DC اجرا میکند. خروجی خطا را با توجه به نام Test و جزئیات آن بررسی کن؛ بعضی Warningها وابسته به Design هستند. DNS Test و Advertising از بخشهای مفیدند.
توضیح تکمیلی
dcdiag مجموعهای از تستهای سلامت DC را اجرا میکند. باید Failure را بر اساس نام Test و Context آن تحلیل کنی، نه اینکه هر Warning را خرابی قطعی بدانی.
در عمل چه کار میکنیم؟
- dcdiag را اجرا کن
- Failureها را بر اساس نام Test جدا کن
- DNS و Advertising را دقیقتر بررسی کن
- نتیجه را با Event Viewer مقایسه کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| هر Warning خرابی قطعی فرض میشود | نام Test و Context را بررسی کن |
| Failure بدون Event Log بررسی میشود | نتیجه را با Logهای مرتبط مقایسه کن |
چطور نتیجه را بررسی کنیم؟
- Failure مهم بدون علت باقی نمانده باشد
- DNS و Advertising وضعیت قابل قبول داشته باشند
مثال عملی
dcdiag مجموعهای از تستهای سلامت DC را اجرا میکند. dcdiag یک Warning کوچک و یک Failure در Advertising نشان میدهد. بررسی از Failure شروع میشود چون میتواند روی معرفی DC به Clientها اثر مستقیم داشته باشد.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: dcdiag مجموعهای از تستهای سلامت DC را اجرا میکند.
نکته اصلی این درس
میتوانم خروجی dcdiag را بر اساس نام Test و Failure تحلیل کنم.
repadmin و Replication
در محیطی که چند Domain Controller وجود دارد، Replication یکی از اجزای حیاتی Active Directory است. `repadmin /replsummary` دید کلی Failureها میدهد. اگر فقط یک DC داری، هنوز مفهوم Replication را یاد بگیر چون اضافهکردن DC دوم یکی از قدمهای مهم Availability است.
توضیح تکمیلی
repadmin وضعیت Replication بین DCها را نشان میدهد. Partner، Error Code و Last Success مهمترین سرنخها برای تشخیص مشکل هستند.
در عمل چه کار میکنیم؟
- repadmin /replsummary را اجرا کن
- Partner دارای Failure را پیدا کن
- Error Code و Last Success را ثبت کن
- DNS، RPC و Eventهای Directory Service را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| RPC server unavailable | Network، Firewall و RPC را بررسی کن |
| DNS lookup failure | Resolve شدن نام DCها را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- Replication Failure غیرمنتظره وجود نداشته باشد
- Last Success بهروز باشد
مثال عملی
repadmin وضعیت Replication بین DCها را نشان میدهد. User روی DC01 ساخته میشود اما روی DC02 دیده نمیشود. repadmin نشان میدهد Replication چند ساعت Fail بوده است؛ مشکل از ADUC نیست.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: repadmin وضعیت Replication بین DCها را نشان میدهد.
نکته اصلی این درس
میتوانم Replication Failure را با Partner، Error Code و Last Success بررسی کنم.
DC دوم چرا مهم است؟
Domainی که فقط یک Domain Controller دارد، از نظر Availability یک نقطه شکست مهم دارد. در محیط واقعی معمولاً حداقل دو DC با DNS و Backup مستقل منطقی است تا خرابی یک Server کل Authentication و DNS سازمان را متوقف نکند.
توضیح تکمیلی
DC دوم زمانی ارزش Availability ایجاد میکند که واقعاً مستقل، سالم و Replicate شده باشد. دو VM روی یک Storage مشترک هنوز میتوانند یک Failure Domain واحد داشته باشند.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
DC دوم زمانی ارزش Availability ایجاد میکند که واقعاً مستقل، سالم و Replicate شده باشد. دو DC وجود دارند اما هر دو روی یک Host و یک Storage هستند. خرابی همان Storage هر دو DC را از دسترس خارج میکند؛ تعداد VM بهتنهایی Availability ایجاد نمیکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: DC دوم زمانی ارزش Availability ایجاد میکند که واقعاً مستقل، سالم و Replicate شده باشد.
نکته اصلی این درس
DC دوم زمانی ارزش Availability ایجاد میکند که واقعاً مستقل، سالم و Replicate شده باشد.
DNS مشکل دارد؛ از کجا شروع کنیم؟
روی Client `ipconfig /all` را ببین، DNS Server را بررسی کن، سپس `nslookup` برای Domain و DC بزن. روی DNS Manager وجود Zone و رکوردهای SRV را بررسی کن. استفاده از DNS عمومی روی Client عضو Domain یکی از خطاهای پرتکرار در محیط Active Directory است.
توضیح تکمیلی
عیبیابی DNS در Domain باید از Resolver روی Client شروع شود و تا Zone و رکوردهای SRV روی DNS Server ادامه پیدا کند.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
عیبیابی DNS در Domain باید از Resolver روی Client شروع شود و تا Zone و رکوردهای SRV روی DNS Server ادامه پیدا کند. File Server با IP باز میشود ولی با نام نه. nslookup برای نام Server پاسخ NXDOMAIN میدهد؛ مسیر شبکه سالم است و بررسی باید روی DNS Record متمرکز شود.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: عیبیابی DNS در Domain باید از Resolver روی Client شروع شود و تا Zone و رکوردهای SRV روی DNS Server ادامه پیدا کند.
نکته اصلی این درس
عیبیابی DNS در Domain باید از Resolver روی Client شروع شود و تا Zone و رکوردهای SRV روی DNS Server ادامه پیدا کند.
کاربر نمیتواند با حساب Domain وارد Windows شود
وضعیت Password و Lockout، شبکه، DNS، زمان سیستم، دسترسپذیری Domain Controller و وضعیت Account را بررسی کن. اگر Cached Logon کار میکند ولی Domain Resource نه، ممکن است Client به DC دسترسی نداشته باشد.
توضیح تکمیلی
مشکل Login با حساب Domain میتواند از Account، Lockout، DNS، Time یا دسترسی به DC باشد. قبل از Resetهای مکرر Password باید مشخص شود Authentication کجا شکست میخورد.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
مشکل Login با حساب Domain میتواند از Account، Lockout، DNS، Time یا دسترسی به DC باشد. Laptop خارج از شبکه با Cached Credential وارد Windows میشود اما داخل شرکت Domain Resourceها در دسترس نیستند. این تفاوت نشان میدهد Connectivity به DC و DNS باید بررسی شوند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: مشکل Login با حساب Domain میتواند از Account، Lockout، DNS، Time یا دسترسی به DC باشد.
نکته اصلی این درس
مشکل Login با حساب Domain میتواند از Account، Lockout، DNS، Time یا دسترسی به DC باشد.
Account Lockout
Lockout ممکن است از Password قدیمی روی موبایل، Service، Scheduled Task، Mapping یا Credential ذخیرهشده ایجاد شود. اگر فقط User را Unlock کنی و منبع Credential اشتباه را پیدا نکنی، Lockout دوباره تکرار میشود.
توضیح تکمیلی
Account Lockout معمولاً نتیجه تکرار Credential اشتباه از یک دستگاه، Service یا Task دیگر است. Unlock کردن بدون پیدا کردن منبع مشکل فقط راهحل موقت است.
در عمل چه کار میکنیم؟
- زمان Lockout را ثبت کن
- Credentialهای ذخیرهشده را بررسی کن
- Serviceها و Scheduled Taskها را کنترل کن
- پس از اصلاح منبع، تکرار Lockout را بررسی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| فقط User Unlock میشود | Credential اشتباه دوباره Lockout ایجاد میکند |
| منبع Password قدیمی پیدا نشده | Service، Task، موبایل و Mappingها را بررسی کن |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Account Lockout معمولاً نتیجه تکرار Credential اشتباه از یک دستگاه، Service یا Task دیگر است. کاربر Password خود را عوض کرده اما هر چند دقیقه Account دوباره Lock میشود. یک Scheduled Task روی سیستم دیگری هنوز Password قبلی را استفاده میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Account Lockout معمولاً نتیجه تکرار Credential اشتباه از یک دستگاه، Service یا Task دیگر است.
نکته اصلی این درس
Account Lockout معمولاً نتیجه تکرار Credential اشتباه از یک دستگاه، Service یا Task دیگر است.
DSRM Password را فراموش نکن
DSRM Password با Password حساب Domain Administrator یکسان نیست. برای Recovery Mode لازم است و باید امن و مستند در Password Manager سازمانی نگهداری شود.
توضیح تکمیلی
DSRM Password یک Credential بازیابی جدا از Domain Administrator است. ممکن است مدتها استفاده نشود اما در شرایط Recovery حیاتی باشد.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
DSRM Password یک Credential بازیابی جدا از Domain Administrator است. یک تغییر کوچک و قابل کنترل روی Object آزمایشی انجام بده، نتیجه را از دید Client بررسی کن و سپس همان تغییر را برگردان. این روش ارتباط تنظیم مدیریتی و اثر واقعی آن را روشن میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: DSRM Password یک Credential بازیابی جدا از Domain Administrator است.
نکته اصلی این درس
DSRM Password یک Credential بازیابی جدا از Domain Administrator است.
Demote کردن DC
برای خارج کردن یک Domain Controller از Domain، صرفاً Role را حذف یا Server را خاموش نکن. Demotion باید با Wizard/روش صحیح انجام شود، پیش از Demotion باید وضعیت FSMO Roleها، DNS، Global Catalog و Replication بررسی شود. Force Removal فقط در شرایط خاص و با Metadata Cleanup بعدی استفاده میشود.
توضیح تکمیلی
Demote کردن DC نیاز به بررسی FSMO، DNS، Global Catalog و Replication دارد. Force Removal مسیر عادی خروج یک DC سالم نیست.
در عمل چه کار میکنیم؟
- FSMO و GC را بررسی کن
- Replication و DNS را کنترل کن
- Demotion را از Wizard انجام بده
- بعد از پایان، DNS و AD Sites and Services را بازبینی کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| Force Removal بدون نیاز | Metadata قدیمی باقی میماند |
| وابستگی DNS Clientها نادیده گرفته میشود | پس از خاموش شدن DC بخشی از Clientها DNS از دست میدهند |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
Demote کردن DC نیاز به بررسی FSMO، DNS، Global Catalog و Replication دارد. DC02 قرار است از مدار خارج شود اما DHCP هنوز IP آن را بهعنوان DNS دوم به Clientها میدهد. قبل از Demotion باید این وابستگی اصلاح شود.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: Demote کردن DC نیاز به بررسی FSMO، DNS، Global Catalog و Replication دارد.
نکته اصلی این درس
میدانم قبل از Demote کردن DC باید FSMO، DNS، GC و Replication بررسی شوند.
سناریوی واقعی شرکت از صفر
فرض کن شرکت ۳۰ کاربر دارد. DC01 با IP ثابت ساخته میشود، Forest `corp.example.com` ایجاد میشود، OUهای Users/Computers/Servers و Departmentها ساخته میشوند، گروههای دسترسی تعریف میشوند، Clientها Join میشوند، GPO پایه اعمال میشود، DHCP DNS داخلی را میدهد و File Server با Group Permission مدیریت میشود.
توضیح تکمیلی
سناریوی واقعی شرکت باید همه مراحل را به هم وصل کند: نصب Server، Promotion، OU، User، Group، GPO، DHCP، File Server، Backup و Health Check.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
سناریوی واقعی شرکت باید همه مراحل را به هم وصل کند: نصب Server، Promotion، OU، User، Group، GPO، DHCP، File Server، Backup و Health Check. برای یک شرکت ۳۰ نفره ابتدا یک Client آزمایشی Join میشود. بعد از تأیید DNS، GPO و دسترسی File Server، مهاجرت سایر سیستمها مرحلهای ادامه پیدا میکند.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: سناریوی واقعی شرکت باید همه مراحل را به هم وصل کند: نصب Server، Promotion، OU، User، Group، GPO، DHCP، File Server، Backup و Health Check.
نکته اصلی این درس
سناریوی واقعی شرکت باید همه مراحل را به هم وصل کند: نصب Server، Promotion، OU، User، Group، GPO، DHCP، File Server، Backup و Health Check.
چکلیست تحویل
نام و IP Server مستند است، DNS داخلی صحیح است، Backup فعال است، حداقل حسابهای Admin کنترل شدهاند، OU/GPO/Group Naming مشخص است، DHCP Scope و Exclusion مستند است، Share/NTFS Permission تست شده، Client Join و Logon تست شده و Eventهای بحرانی بررسی شدهاند.
توضیح تکمیلی
چکلیست تحویل نشان میدهد زیرساخت فقط روشن و فعال نیست، بلکه مستند، قابل تست و قابل بازیابی هم هست.
در عمل چه کار میکنیم؟
- وضعیت فعلی را از ابزار مدیریتی مربوط بخوان
- فقط تغییر مرتبط با همین موضوع را انجام بده
- نتیجه را از دید Client یا سرویس مقصد دوباره آزمایش کن
خطاهای رایج و دلیل آنها
| نشانه یا اشتباه | دلیل یا بررسی بعدی |
|---|---|
| تغییر بدون ثبت وضعیت قبلی | مقایسه نتیجه و Rollback سخت میشود |
| چند تغییر همزمان | مشخص نمیشود کدام تغییر روی نتیجه اثر گذاشته است |
چطور نتیجه را بررسی کنیم؟
- نتیجه از دید Client یا سرویس واقعی با انتظار مطابقت داشته باشد
- وضعیت نهایی در مستندات یا Ticket ثبت شده باشد
مثال عملی
چکلیست تحویل نشان میدهد زیرساخت فقط روشن و فعال نیست، بلکه مستند، قابل تست و قابل بازیابی هم هست. Server روشن است و کاربران کار میکنند، اما Scope DHCP، محل Backup و DSRM Password مستند نشدهاند. از نظر پشتیبانی پروژه هنوز کامل تحویل نشده است.
نکته محیط عملیاتی
در محیط عملیاتی، قبل از تغییر باید Scope اثر، وضعیت فعلی و روش بازگشت مشخص باشند. نکته اختصاصی این مرحله برای مستندسازی و تصمیم فنی: چکلیست تحویل نشان میدهد زیرساخت فقط روشن و فعال نیست، بلکه مستند، قابل تست و قابل بازیابی هم هست.
نکته اصلی این درس
چکلیست تحویل نشان میدهد زیرساخت فقط روشن و فعال نیست، بلکه مستند، قابل تست و قابل بازیابی هم هست.
سه Lab که باید بعد از مطالعه انجام بدهی
یک Windows Server 2025 نصب کن، IP ثابت بده، DC01 نامگذاری کن، Forest جدید بساز و DNS/ADUC را بررسی کن
یک Windows 11 را با DNS داخلی Join کن، OU بساز، Client را منتقل کن و یک GPO ساده اعمال و با gpresult بررسی کن
سه Group برای Read/Modify/No Access بساز، Share و NTFS Permission را اعمال کن، ABE فعال کن و با سه User نتیجه را تست کن
