FSMO چیست؟ چند نوع FSMO داریم؟ کاربرد Operation Masters در اکتیودایرکتوری چیست؟ اهمیت FSMO ها در ساختار اکتیودایرکتوری چیست ؟ در مقاله دومین ویندوزی چیست؟ به این مسئله اشاره کردیم که ساختار اکتیودایرکتوری شامل یک جنگل یا forest است که با درخت ها یا Domain Tree پر میشوند و با نگاه کردن به نام هر یک از این دامین ها میتوان محل آن را در ساختار اکتیودایرکتوی مشخص کرد .
قطعا برای شما دوستان هم این موضوع واضح هست که دامین هایی که در بالای این ساختار سلسله مراتبی یا بهتر بگیم موروثی قرار میگیرن از درجه اهمیت بیشتری نسبت به پایینتری ها برخوردار هستند و متقابلا دامین کنترلر ها هم مهم هستند. اما همه چیز اینطوری نیست که تصور میشه . در این مقاله به شما نقش هایی که بصورت مجزا هر کنترا کننده دامین یا Domain Controller در ساختار جنگل یا Forest در اکتیودایرکتوری ایفا میکنه رو مشاهده خواهید کرد .
قبلا در همین سری از مقالات در مورد چگونگی کارکرد دامین در ویندوز NT صحبت کردیم . همانند ساختار اکتیودایرکتوری ، دامین های تحت ویندوز NT نیز از وجود چندین کنترل کننده دامنه یا domain controller پشتیبانی میکردند . به یاد داشته باشیم که وظیفه Domain Controller احزار هویت کاربران شبکه و اجازه ورود به سیستم ها است . بنابراین اگر دامین کنترلر از مدار خارج شده و قادر به ارائه سرویس نباشد هیچکس نمی تواند به کامپیوترهای شبکه وارد شود .
مفاهیم و اصطلاحات مربوط به شبکه های دامین در دوره آموزش نتورک پلاس آموزش داده شده است
مایکروسافت در طراحی های خود این موضوع را مد نظر داشت و به همین دلیل این امکان را به ویندوز سرور داد تا بتواند یک دامین کنترلر اضافی بر سازمان ایجاد کند تا هنگامی که دامین کنترلر اصلی از کار افتاد بتوانند از آن برای ورود به سیستم ها استفاده کنند که به این دامین کنترلر به اصطلاح Additional Domain Controller هم می گویند .
دارا بودن چندین دامین کنترلر در شبکه این امکان را به سیستم های تحت شبکه و مدیر آن میدهد که فرآیند های شبکه را در میان این چند سرور تقسیم کرده و باعث شوند که بار کاری بین اینها تقسیم شده و سرعت و کارایی سیستم ها بیشتر شود و تنها یک سرور زیر بار کاری قرار نگیرد .
همچنین ویندوز NT میتوانست از وجود چند دامین کنترلر در یک دامین استفاده کند ، در این حالت یکی از دامین کنترلر ها به عنوان دامین کنترلر اصلی یا Primary Domain Controller که به اختصار PDC گفته میشود . همانطوری که قبلا هم اشاره شد یک دامین کنترلر شامل تمامی اشاء موجود در دامین از قبیل حساب های کاربری و کامپیوتری و گروه ها و .. میباشد ، به این پایگاه داده به اصطلاح SAM هم گفته میشود که مخفف کلمه Security Account Manager است . ( البته ما SAM را در ساختار اکتیودایرکتوری امروزی به عنوان پایگاه داده محلی بر روی سیستم ها داریم و دیگر مفهومی به نام SAM در روی دامین های تحت اکتیودایرکتوری وجود ندارد .
در ویندوز NT سرور اصلی یا همان PDC کپی اصلی از اطلاعات دامین را در خود نگهداری میکند و سایر دامین کنترلر های موجود در دامین به عنوان دامین کنترلرهای پشتیبان یا Backup Domain Controller که به اختصار BDC نامگذاری میشود در دامین فعالیت میکنند .
اگر بخواهیم هر تغییری را در ساختار دامین ایجاد کنیم آنرا میبایست در قالب اعمال تغییرات در PDC انجام بدهیم . پس از اعمال این تغییرات PDC اطلاعات خود را با سایر BDC های موجود در دامین یکسان سازی یا به اصطلاح Replicate میکند . در یک وضعیت عادی و نرمال PDC تنها دامین کنترلر در ویندوز NT است که بروز رسانی های میتواند بر روی آن اعمال شود .
اگر PDC ما در ساختار دامین از بین برود یا دچار مشکل شود راه هایی وجود دارد که از آن طریق بتوان دامین کنترلر های BDC را تبدیل به PDC کرد تا در شبکه بتوانند فعالیت کنند . دامین در ساختار اکتیودایرکتوری تا حدودی با این شکل متفاوت است .
اکتیودایرکتوری از یک ساختار Multi Master Replication یا ساده تر بگوییم ساختاری که در آن چندین دامین کنترلر که همگی آنها به عنوان PDC هستند و در شبکه بصورت همزمان فعالیت میکنند و اطلاعات خود را یکسان سازی می کنند ، استفاده میکند . این ساختار یعنی اینکه هر دامین کنترلر یک کپی قابل نوشتن از اطلاعات دامین را در اختیار داشته و به محض اینکه در یکی از این دامین کنترلرها تغییراتی اعمال شده و یا بروزرسانی شود ، همه آنها اطلاعات خود را با یکدیگر یکسان سازی میکنند.
استفاده از ساختار Multi Master Replication به نظر ایده ای بسیار خوب می آید ، اما در اینجاست که یک سری مشکلات از قبیل بوجود آمدن مقایرت در انجام تنظیمات بوجود می آید . تصور کنید که شما به عنوام مدیر دامین تنظیماتی را در ساختار دامین ایجاد میکنید و در همان لحظه یکی دیگر از مدیران شبکه نیز متضاد این تغییرات را در همان ساختار دامین اعمال میکند !!!
در بیشتر موارد اکتیودایرکتوری بروزترین تغییرات را به عنوان آخرین تغییرات مد نظر قرار داده و آنها را ملاک تغییر و اعمال در پایگاه داده خود قرار میدهد . اما در برخی اوقات تنظیمات به اندازه ای حساس و حیاتی هستند که صرفا نمیتوان به چنین نوع ملاک های تغییری اکتفا کرد و تضاد ها بسیار خطرناک خواهند شد .
در چنین مواقعی مایکروسافت راهکارهای پیشگیرانه را به جای راهکارهای ترمیم کننده در نظر میگیرد و آنها را ملاک قرار می دهد .یعنی به جای اینکه پس از بوجود آمدن تداخل و تضاد بین تنظیمات آنرا رفع کند ، قبلا از بوجود آمدن تداخل و تناقض در تنظیمات پیشگیری میکند .
برای مدیریت چنین مسائلی ، مایکروسافت برای هر دامین کنترلر نقش مدیریتی را در ساختار اکتیودایرکتوری در نظر گرفته و در هر دامین صرفا یک دامین کنترلر است که مسئول انجام نقش محول شده به آن می باشد و سایرین وظیفه ای در خصوص آن مسئله نخواهند داشت .
این نقش ها و وظایف را در اصطلاح Flexible Single Master Operation یا به اختصار FSMO و در برخی تلفظ ها FIZMO می نامند . این کار به این معنی است که تمامی دامین کنترلر ها در شبکه دامین اطلاعات خود را با یکدیگر یکسان سازی میکنند اما به محض اینکه رویدادی قرار است بوجود بیاید که تناقض در آن باعث اختلال در کار دامین خواهد شد از دامین کنترلری سئوال میشود که مسئول نگهداری آن وظیقه یا Role در دامین محسوب میشود و سایر دامین کنترلرها ملاک اعمال تغییرات نخواهند بود . به یاد داشته باشید که ما در ساختار اکتیودایرکتوری 3 نقش یا Role در سطح دامین و 2 نقش در سطح Forest داریم که هر یک وظیفه مشخص و معینی برای خود دارند.
این مسئله خیلی مهم است که بدانید که هر یک از این FSMO Role ها بر روی کدامیک از دامین کنترلر های شبکه شما قرار گرفته است . بصورت پیشفرض در یک Forest اولین دامین کنترلر در دامین تمامی 5 نقش را بر روی خود نگه میدارد . همینطور که دامین کنترلرهای اضافی ایجاد میشوند اولین دامین کنترلر نقش های مربوط به هر یکی از دامین ها ( 3 نقش در سطح دامین ) را به تک تک آنها ، ارائه می دهد .
دلیل اصلی اینکه بایستی بدانید که این نقش ها بر روی کدامیک از دامین کنترلرها قرار دارد این است که سخت افزارهای همیشه قدیمی و از رده خارج میشوند . به خاطر دارم که یکی از دوستانم قصد داشت برای شرکتی ساختار اکتیو دایرکتوری را ایجاد کند . قبل از اینکه سرور اصلی به دست ایشان برسد برای تسریع کار از یک دستگاه PC به عنوان سرور استفاده کرده و ویندوز سرور 2003 و اکتیودایرکتوری را بر روی آن نصب کردند تا بتوانند از ابزارهای مدیریتی آن استفاده کنند .
پس از اینکه سرورهای جدید به دست وی رسید ، به جای اینکه یک ساختار جدید Forest ایجاد کند ، سرور جدید را به عنوان یک دامین کنترلر به سیستم قبلی ( دامین قبلی ) معرفی کرد. اینکار به این معنی است که همچنان همان PC که در نقش دامین کنترلر اولیه کار میکرد همچنان همگی FSMO ها را بر روی خودش نگهداری میکرد .
همه چیز خوب بود تا وقتی که این دوست ما خواست که کامپیوتری که قبلا به عنوان دامین کنترلر ایجاد کرده بود یا بهتر بگوییم PC قبلی را از مدار شبکه خارج کند . اگر اینکار به درستی انجام شود مشکل خاصی در ساختار ایجاد نمیشود اما اگر اشتباه انجام شود ممکن است شبکه و ساختار اکتیودایرکتوری شما به کلی دچار مشکل شود .
دوست ما بدون توجه به روشهای جداسازی این دامین کنترلر از شبکه براحتی دستگاه را بصورت فیزیکی از شبکه جدا و هارد دیسک آنرا کاملا Format میکند !!! به یکباره کلیه فعالتیهای اکتیودایرکتوری دچار مشکل شده و مشکلات زیادی در شبکه بوجود می آید .
اگر مدیر شبکه به این نکته توجه داشت که سروری را که از شبکه خارج کرده تمامی نقش های FSMO را بر روی خود داشته ، این مشکلات به هیچ عنوان به وجود نمی آمد . در اینگونه موارد امکان این وجود دارد که سرور قبلی را بدون نیاز به حضور فعال در شبکه از ساختار خارج کرده و تمامی نقش ها را به سرور جدید منتقل کنیم که با این روش مشکلات بوجود آمده براحتی از بین خواهد رفت . ( Seize )
در مورد تک تک نقش هایی که هر یک از این FSMO ها در اکتیو دایرکتوری ایفا میکنند در مقاله بعدی به طور کامل صحبت خواهم کرد . اما در اینجا خیلی سریع عناوین این نقش ها را به شما معرفی میکنم تا با نام آنها آشنایی داشته باشید .
همانطوری که قبلا هم گفتم 5 نقش وجود دارد که 3 تای آنها در سطح دامین و 2 تای آنها در سطح Forest فعالیت می کنند . نقش هایی که در دامین فعالیت میکنند به نام Relative Identifier, Primary Domain Controller Emulator و Infrastructure Master هستند که به اختصار به آنها RID و IMR و PDC Emulator میگوییم . نقش های سطح Forest نیز به ترتیب Schema Master و Domain Naming Master نامگذاری میشوند . در پایین خلاصه ای از فعالیتی که آنها انجام میدهند را معرفی میکنیم :
در مقاله قبلی اشاره کردیم که ساختار اکتیودایرکتوری از یک استراتژی Multimaster Replication یا یکسان سازی داده های چند وجهی استفاده میکند و این استراتژی صرفا در مواردی مستثنی میشد که به شدت میبایست از بروز تضاد و تقابل در شبکه جلوگیری میکردیم . در اینگونه موارد ویندوز برای اعمال نهایی تغییرات به یکی از دامین کنترلر ها که در نقش مسئولیت مورد نظر در اکتیودایرکتوری فعالیت میکند به عنوان ختم کلام نگاه میکند و این دامین کنترلر تغییرات نهایی را تایید و اعمال میکند و از بروز تداخل جلوگیری میکند . در اصطلاح به اینگونه دامین کنترلر ها Flexible Single Operations Master یا FSMO اطلاق می شود .
همانطوری که در قسمت هفتم از این سری مقالات اشاره کردم ما 5 نوع FSMO مختلف داریم . 3 تا از این FSMO ها در سطح دامین و 2 تا از آنها در سطح Forest وجود دارند . FSMO هایی که در سطح Forest فعالیت میکنند به نامهای Schema Master و Domain Naming Master و FSMO هایی که در سطح Domain فعالیت میکنند به ترتیب Relative Identifier Master و Primary Domain Controller Master و Infrastructure Master نام دارند . در ابتدای این سری مقالات قصد نداشتم به سراغ FSMO ها بروم اما با توجه به اهمیت زیادی که این نقش ها در اکتیودایرکتوری و شبکه دارند صلاح دیدم که حتما بصورت مفصل به آنها پرداخته شود .
با اینکه اطمینان دارم شما این مسئله را میدانید اما مجددا آنرا تکرار میکنم ، برای اینکه اکتیودایرکتوری بتواند به درستی در شبکه به فعالیت خود ادامه دهد نیازمند وجود سرویس DNS و دسترسی کاربران به این سرویس و همچنین وجود حداقل یک عدد دامین کنترلر هستیم . وقتی اولین ساختار اکتیودایرکتوری ایجاد میشود معمولا همان دامین کنترلر به عنوان سرور DNS نیز مشغول به فعالیت میشود . همین دامین کنترلر در نقش نگه دارنده این 5 نقش FSMO نیز محسوب میشود .
برای یادگیری بهتر دوره های مهندسی شبکه مایکروسافت ، به دوره آموزش MCSA مراجعه کنید
اگر دامین های دیگری نیز در این Forest ایجاد شوند اولین دامین کنترلر در آن دامین تمامی FSMO های همان دامین را در خود نگه میدارد . FSMO هایی که در سطح Forest فعالیت میکنند صرفا در همان دامین کنترلر اصلی باقی مانده و همان دامین کنترلر در Forest نقش نگه دارنده آنها را بدون توجه به تعداد دامین ها بر عهده میگیرد . این نکته را در ذهن داشته باشید که با بوجود آمدن اولین دامین ، اولین Forest نیز در شبکه ایجاد می شود ، ما در هر دامین بصورت جداگانه 3 نقش و در هر Forest بدون توجه به تعداد دامین های موجود در آن فقط 2 نقش را خواهیم داشت .
اینها را برای شما میگویم تا به این مسئله برسیم که در صورتیکه دامین کنترلری که دارای این نقش ها در اکتیودایرکتوری میباشد از بین رفته و یا دچار اشکال شود چه اتفاقی در شبکه رخ خواهد داد .اگر چنین اتفاقی در شبکه شما بوجود بیاید بدون شک شما به عنوان مدیر این شبکه این مشکل را احساس خواهید کرد ، مشکل ممکن است اینقدر حاد نباشد که بطور کلی شبکه شما را دچار اختلال کند اما اگر دامین کنترلری که این نقش ها در سطح Forest بر روی آن قرار داشته سرویس دهنده DNS نیز باشد به دلیل وابستگی شدید اکتیودایرکتوری به آن ، بدون شک به مشکلی اساس بر خواهید خورد .
اگر DNS سرور بر روی سایر دامین کنترلر ها وجود داشته باشد و در دامین شما چندین دامین کنترلر وجود داشته باشد که این سرویس را بر روی خود داشته باشند ممکن است تا مدتی از مشکل بوجود آمده ناشی از عدم فعالیت این نقش ها برخورد نکنید . ( مگر اینکه نرم افزار مانیتورینگ داشته باشید که در صورت بروز خطا به شما هشدار بدهد )
در حقیقت هیچوقت شما تاثیر ناگهانی را در اثر از بین رفتن FSMO ها در فعالیت شبکه احساس نخواهید کرد ، اما در آینده ای نه چندان دور به مشکلات بزرگتری برخواهید خورد که در صورتیکه این مشکل را حل نکنید بدون شک اکتیودایرکتوری شما دچار مشکلاتی جدی خواهد شد .
خوب در اینگونه موارد میبایست شما عوارض ناشی از عدم وجود این نقش ها را کاملا درک کرده باشید تا به وجود مشکل پی ببرید و اولین نکته در این مورد ، این مطلب است که این نقش های FSMO بر روی کدامیک از سرورهای شما قرار دارد . در اینصورت با توجه به عوارضی که در شبکه در صورت عدم وجود یکی از این نقش ها احساس میشود به سراغ سرور میزبان آن نقش رفته و چک میکنید که آیا این سرور دچار مشکل شده است یا خیر و اولین مرحله از رفع اشکال آنرا انجام خواهید داد .
اکتیودایرکتوری چیزی بیشتر از یک پایگاه داده مرکزی نیست و هر پایگاه داده ای نیز برای خود و مانند سایر پایگاه های داده یک ساختار یا Schema دارد . بر خلاف سایر پایگاه داده های موجود ، ساختار اکتیودایرکتوری ثابت نیست . عملیات های بسیاری در شبکه وجود دارند که باعث میشود این ساختار نیاز به تغییر و پیشرفت داشته باشد . برای مثال نصب سرور Exchange نیاز به این دارد که این ساختار گسترش داده شود و به تناسب نیاز این نرم افزار تغییر کند .
به محض اینکه هرگونه تغییری در ساختاز یا Schema ی مربوط به اکتیودایرکتوری اعمال شود این تغییرات به Schema Master نیز اعمال می شود. نقش Schema Master به عنوان مهمترین و حساسترین نقش در میان FSMO ها وجود دارد و به همین دلیل هم مایکروسافت آنرا مخفی نگه داشته است .
اگر میخواهید بدانید که کدامیک از دامین کنترلر های شما میزبان Schema Master هستند کافیست CD یا DVD ویندوز سرور 2003 یا 2008 را وارد دستگاه کرده و به پوشه I386 رفته و بر روی ADMINPACK.MSI دابل کلیک کنید . در این هنگام ابزارهای مدیریتی مایکروسافت بصورت یکپارچه برای شما نصب خواهد شد .
وقتی نصب نرم افزار بصورت کامل تمام شد ، با استفاده از Run و وارد کردن دستور MMC به کنسول مدیریتی مایکروسافت وارد شوید . بعد از اینکه کنسول مدیریتی باز شد ، از قسمت منوی File گزینه Add Remove Snap In رو انتخاب کنید . بعد از اینکه این قسمت باز شد از لیست باز شده Active Directory Schema را انتخاب کنید و بر روی Close و بعد OK کلیک کنید .
البته قبل از اینکه بتوانید Schema Master را مشاهده کنید بایستی دستور regsvr32 schmmgmt.dll که یک فایل dll است را از قسمت Run سیستم رجیستر کنید که اینکار براحتی با استفاده از وارد کردن همین دستور در قسمت Run امکانپذیر است . پس از اینکه Snap-In مورد نظر به لیست اضافه شد ، بر روی Container مورد نظر که Active Directory Schema میباشد راست کلیک کرده و گزینه Operations Master ار کلیک میکنیم ، در این هنگام به شما محلی که FSMO ی مورد نظر ما که در اینجا schema master است را مشاهده خواهید کرد .
همانطوری که قبلا هم اشاره کرده ام ، یک Forest در اکتیودایرکتوری میتواند شامل چندین دامین باشد . این وظیفه Domain Naming Master هست که مراقب این دامین ها باشد . اگر این نقش از بین برود دیگر قادر نخواهیم بود به ساختارمان دامینی اضافه و یا از آن کم کنیم تا اینکه این نقش را مجددا به حالت اولیه بازگردانیم .
اگر میخواهیم بدانیم که این نقش بر روی کدامیک از سرورها قرار دارد بایستی به کنسول مدیریتی Active Directory Domains and Trusts مراجعه کنیم . بعد از اینکه کنسول مورد نظر باز شد بر روی Container مورد نظر راست کلیک کرده و گزینه Operations Master را انتخاب میکنیم و بعد از باز شدن سروری را که میزبان این نقش می باشد را مشاهده خواهیم کرد .
همانطوری که میدانید اکتیودایرکتوری به مدیران آن اجازه این را میدهد که بتوانند بر روی دامین کنترلر شیء یا Object ایجاد کنند . نکته مهم اینجاست که هر Object در ساختار اکتیودایرکتوری میبایست دارای یک مشخصه منحصر به فرد باشد که به اصطلاح Unique Relative Identifier هم گفته می شود .
برای اینکه تداخلی بین دامین کنترلرها و ایجاد Object ای با مشخصه یکسان در اکتیودایرکتوری بوجود نیاید ، Relative Identifier Master یک Pool یا بهتر بگوییم یک مجموعه از این مشخصه های منحصر به فرد را بصورت گروهی تولید کرده و در اختیار دامین کنترلر های موجود در شبکه میگذارند که از آنها استفاد کرده و شیئی با مشخصه مشابه در اکتیودایرکتوری ایجاد نشود .
به محض اینکه شیئی بر روی یکی از دامین کنترلرها ایجاد شود ، دامین کنترلر مورد نظر از مشخصه های منحصر به فردی که دریافت کرده است یکی را انتخاب و به شیء مورد نظر اختصاص میدهد . وقتی این مجموعه به اتمام رسید دامین کنترلر می بایست از Relative Identifier Master درخواست تعداد بیشتری از این مشخصه ها کند . در اینجاست که اگر سرور Relative Identifier Master دچار مشکل شده باشد شما قادر به ایجاد شیء جدیدی در ساختار اکتیودایرکتوری نخواهید بود .
برای اینکه بدانید کدامیک از دامین کنترلر های شما میزبان RID Master هستند کافیست وارد یکی از آنها شده و به کنسول مدیریتی Active Directory Users and Computers شوید و بر روی نام دامین خود راست کلیک کرده و Operations Masters را انتخاب میکنیم . در اینجا شما میتوانید به تب مورد نظر رفته و سروری را که هم اکنون میزبان RID Master است را مشاهده کنید .
در همین سری از مقالات و در شماره هفتم به نقش PDC Emulator در شبکه های ویندوز NT اشاره ای کردیم . PDC Emulator این قابلیت را به اکتیودایرکتوری می دهد که بتواند با دامین کنترلر های ویندوز NT بصورت همزمان فعالیت و سرویس دهی کند .
ایده اصلی در بوجود آودن چنین نقشی این بود که بعد از بروز رسانی دامین کنترلر از ویندوز NT به ویندوز سرور 2003 یا سرور 2008 ، PDC اولین دامین کنترلری خواهد بود که بروز رسانی میشود و به همین منظور دامین کنترلری که بروز میشود برای اینکه بتواند با سایر دامین کنترلرهای ویندور NT همزمان فعالیت کند به عنوان PDC به سایر دامین کنترلر ها نمایش داده میشد .
امروزه نقش PDC Emulator تا حدود زیادی متفاوت شده است و سازمان های کمی را پیدا خواهید کرد که از ویندوز NT همچنان استفاده کنند .اگر میخواهید محل قرارگیری این Role را مشاهده کنید کافیست همانند قسمت قبل وارد کنسول Active Directory Users and Computers شده و با راست کلیک کردن بر روی نام دامین و انتخاب Operations Masters و تب PDC Emulator محل قرار گیری آنرا مشاهده کنید . در خصوص نقش اصلی که این role در اکتیودایرکتوری ایفا میکند در مقاله ای جداگانه کاملا بحث خواهیم کرد .
در ساختار اکتیودایرکتوری یک Forest میتواند شامل چندین دامین باشد . قطعا این بدین معنا نیست که دامین هایی که در مجموعه Forest وجود دارند کاملا مستقل نسبت به هم فعالیت میکنند . آنها میبایست در وحله های زمانی معین با ساختار Forest و سایر دامین ها ارتباط برقرار کرده و از وضعیت آنها مطلع شوند و این زمانی خواهد بود که Infrastructure Master وارد کار میشود .
وقتی شما یک دامین را ایجاد، حذف و یا تغییر میدهید ، این تغییرات میبایست به تمامی دامین های موجود در ساختار forest اطلاع داده شود . نکته و مشکل اصلی و مهم این است که اکثریت Forest در جریان این تغییرات قرار نخواهند گرفت . این وظیفه Infrastructure Master است که وظیفه اطلاع رسانی اینگونه موارد را بر عهده دارد . اگر Infrastructure Master از بین برود ، تغییراتی که در ساختار دامین بوجود می آید برای سایر دامین ها قابل مشاهده نخواهد بود .
برای مثال اگر شما یک کاربر را تغییر نام بدهید این تغییر در ساختار دامین اطلاع رسانی نشده و در سایر دامین ها همچنان به حالت قبلی باقی خواهد ماند . برای اینکه ببینید که این نقش بر روی کدامیک از دامین کنترلرهای موجود در شبکه قرار دارد کافیست به مانند گذشته وارد کنسول مدیریتی Active Directory Users and Computers شده و بر روی دامین مورد نظر راست کلیک کرده و گزینه Operations Masters را انتخاب کرده و به تب Infrastructure Master بروید و سرور میزبان را براحتی مشاهده کنید .