میلاد اسحاقی
کارشناس سرویس های شبکه مایکروسافت

اکسچنج سرور (Exchange Server) چیست؟ از تاریخچه تا آماده سازی

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

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
  1. تاریخچه Exchange Server
    1. سال های قبل از Exchange
    2. Exchange Server قبل از Active Directory
    3. Exchange Server 4.0 چه بود؟
    4. Exchange 5.0 چه بود؟
    5. Exchange 5.5 چه بود؟
    6. معرفی Exchange server 2000 And 2003
    7. معرفی Exchange 2000
    8. تاریخچه Exchange server 2003
    9. Exchange Server 2007 و بعد از آن
    10. مروری بر Exchange Server 2010
  2. توضیحات اولیه
    1. ثبت تمامی دستورات وارد شده در اکسچنج Exchange Management Shell Command Log
    2. Shell مدیریتی اکسچنج سرور یا Exchange Management Shell
    3. پنل مدیریتی و کنترلی یا Exchange Control Panel)ECP)
    4. وظایف و نقش های موجود در اکسچنج سرور یا Exchange Server Roles
  3. قابلیت ها و نسخه ها
    1. ویژگی‏های تغییر یافته ‏ی Exchange 2003 و 2007
    2. تفاوت Exchange on-premise و Exchange online
    3. License های Exchange Server 2010
    4. Edition های Exchange Server 2010
    5. Exchange Server 2010 Client Access Licenses
  4. امکانات پاورشل
    1. Exchange Organizational Health
  5. Windows PowerShell and Exchange 2010
    1. پایه ‏های Windows PowerShell
  6. طراحی و سوالات فنی
    1. Framework پروژه های پیاده سازی Exchange سرور
    2. برنامه ریزی برای پیاده سازی پروژه های Exchange سرور
    3. طرح ریزی و نقشه در پروژه های Exchange سرور
    4. سوالات کسب و کار (business)
    5. سوالات فنی (Technical)
    6. ارائه پروژه یا Delivery
    7. Envision (پیش‏بینی) : قدم اول
    8. توافقنامه ها و تعهدات سازمانی SLA یا Service Level Agreement
    9. Assess (ارزیابی) : قدم دوم
  7. فازهای اجرایی
    1. قدم سوم (step 3) : ارزیابی راه حل
    2. قدم چهارم Step 4): Proof of concept )
    3. قدم پنجم Step 5) : Create A Design)
    4. قدم ششم Step 6) : Develop a Deployment)
    5. قدم هفتم Step 7) : Implement a Pilot)
    6. قدم هشتم Step 8) : Execute Deployment)
    7. فاز Operate
    8. فاز Manage
  8. نکات مهم قبل نصب
    1. بررسی توپولوژی شبکه
    2. بررسی توپولوژی فعلی شبکه و توپولوژی برنامه ریزی شده
    3. Domain Name System )DNS)
    4. DNS and Active Directory
    5. DNS Recordهای مورد استفاده توسط Exchange 2010
    6. Split DNS
    7. تفاوت Fixed IP Address با Dynamic IP Address
    8. Internet Protocol )IPv4 and IPv6)
    9. IPv6 for Windows
    10. IPv6 for Exchange Server 2010
    11. Understanding Client Load Patterns
    12. Perimeter Network
    13. پیشنهادات تکنیکی برای جلوگیری از Pitfalls
  9. آماده سازی اکتیودایرکتوری
    1. ارزیابی و برنامه ریزی برای AD
    2. چگونه Exchange 2010 از AD استفاده می کند
    3. The Schema partition
    4. Domain partition
    5. Application partition
    6. Active Directory replication Impact on Exchange 2010
    7. Active Directory requirements
    8. تفاوت Single و Multi-Forest Implementation
    9. Single Forest
    10. Multi-Forest
    11. Resource forest
    12. Hybrid forest
    13. Single vs. Multi-Domain Implementation
    14. Single Domain
    15. Single Exchange-Dedicated Domain
    16. Multi-domain

همچنین وظیفه خود می دانم تا از همسرم که در تهیه و تنظیم این سری از مقالات کمک بسیاری به من کرد کمال تشکر را داشته باشم و از شما دوستان گرامی هم بابت وقتی که برای مطالعه و ارائه نظرات خود می گذارید ،سپاسگزاری کنم.خب دیگه مقدمه چینی بسه!! بریم سراغ اصل مطلب ، شروع کار را با سری شماره 1 و 2 که هر دوی آنها تاریخچه و مقدمه ای مرتبط با Exchange Server از ابتدا تا امروز هستند می پردازیم.

تاریخچه Exchange Server

Exchange سرور از سال 1996 مورد استفاده بوده است ولی در آغاز با محصولی که امروزه می شناسیم بسیار متفاوت بوده، Exchange سرور تغییرات زیادی یافت و تکامل پیدا کرد تا همگام با تغییرات علم IT پیش برود.در روزهای اول هارد دیسک ها خیلی گران بوده اند بنابراین از وسایل ذخیره سازی Single در Exchange استفاده می شد. خوشبختانه امروزه هارد دیسک ها ارزان شده و تمرکز بر روی تکنولوژی های متفاوت دارای اهمیت بیشتری شده است.در طول سال ها ورژن های جدیدی از Exchange انتشار یافته که در جدول زیر مروری بر تمامی نسخه های Exchange از ابتدا تا ورژن 2010 دارد.

وب سایت توسینسو


سال های قبل از Exchange

در اوایل سال 1990 سیستم های messaging زیادی در بازار موجود بود. از جمله متوان به محصولات ارائه شده توسط شرکت های بزرگی مثل Siemens’s MailX ، IBM Profs ، Novell group wise اشاره کرد.در آن زمان 2 استاندارد برای سیستم های messaging وجود داشت یکی X400 و دیگری استاندارد اینترنتی SMTP ، البته در آن زمان X400 بیشتر رایج بود و بعدها SMTP به خاطر رشد سریع ارتباطات اینترنتی به محبوبیت جهانی دست پیدا کرده بود.سیستم Mail مایکروسافت، یک سیستم پیام رسان File based را پیشنهاد داد که تمام پیام ها در یک فایل Share شده ذخیره می شد و کاربران از طریق بستر شبکه ی LAN به صندوق پستی شان دسترسی پیدا می کردند.

تجهیزات نصب و راه اندازی Mail سرور مایکروسافت به نام Post Office شناخته می شد که برای ارسال پیام ها بین Post office ها از یک MTA( Message Transfer Agent) استفاده می شد.در آن زمان نسخه های محدود شده Mail مایکروسافت که در ویندوز 95 موجود بودند از قابلیت Route بین Post office ها محروم بودند.اولین نسخه نمایشی Microsoft Mail در سال 1988 منتشر شد در آن زمان پشته شبکه برای شبکه های Apple Talk طراحی شده بود آخرین نسخه Microsoft Mail یعنی نسخه ی 3.5 که شامل چندین MTA بود به علت تاخیر نسخه Exchange منتشر شد.

Exchange Server قبل از Active Directory

اولین نسل از Exchange Server دارای یک سرویس دایرکتوری مجتمع شده در خود محصول بود و از سرویس دایرکتوری ارائه شده توسط OS مثل AD استفاده نمی کرد. Exchange 4.0,5.0,5.5 از این نسل بودند.

Exchange Server 4.0 چه بود؟

اولین نسخه محصولات Exchange Server بر پایه استاندارد X.400 بود. همچنین این نسخه اولین ورژن شامل ESE Database بود.ESE Database با ساختار ذخیره سازی Single-Instance کار می کرد ، در واقع در این Instance پیام ها فقط یک بار در Database ذخیره می شدند حتی اگر در چندین Mailbox مختلف بودند . در اینجا بود که مایکروسافت فهمید که باید از سیستم بر پایه فایل به سمت سیستم ها بر پایه Database برود و با این کار فضای مورد استفاده دیسک را کاهش و به همین میزان کارایی سیستم را افزایش دهد. امروزه از تغییر سیستم File-based به سیستم Database-based می توان حدود 25% در فضای هارد دیسک خود صرفه‏جویی کرد. اگرچه در این نسخه مایکروسافت حجم Databaseرا به 16G محدود کرد که بعدها به یک مسئله کلیدی تبدیل شد.جهت توسعه Exchange 4.0 مایکروسافت تکنولوژی هایی را از سایر شرکت ها خریداری کرد که عبارتند از :

  • X.400 MTA or Transport : این بخش از بخشی از شرکت به نام DC of Enfield در انگلستان به دست آمد. کد آنها در بین صدها ماژول، پراکنده شده بود که نهایتا X.400 MTA را تشکیل می داد.
  • X.500 Directory : این بخش از کدهای 3COM می آمد که در اصل برای Cairo نوشته شده بود. ساختار آن از نوع Object-Oriented بود که برای قرار گرفتن در ویندوز NT4.0 پیشنهاد شده بود.
  • Information Store : برنامه اصلی مایکروسافت برای SQL Server استفاده از آن در یک Database به نام JetBlue بود. هرچند مایکروسافت از این تکنولوژی برای توسعه محصولات SQL استفاده کرد و از آن برای بهبود JetBlue هیچ بهره‏ای نبرد. تیم Exchange پایگاه داده JetBlue ( که به نام ESE هم شناخته می‏شود ) پذیرفت و از آن زمان از همان Database استفاده می‏شود.
وب سایت توسینسو

Exchange 4.0 در تاریخ 31 مارس 1996 پس از 39 ماه تاخیر به روی کار آمد. هرچند بر اساس همان کدهای اولیه نبود و تغییراتی داشت. اما رسما Exchange 4.0 جانشین Microsoft Mail شد. بنابراین برای تعیین نسخه از همان آخرین ورژن که Microsoft Mail 3.5 بود ادامه یافت. Exchange 4.0 شامل ساختار دایرکتوری X.500-based است که بعدها مایکروسافت از همین ساختار برای پایه گذاری AD استفاده کرد.کنسول مدیریت مرکزی Exchange 4.0 تحت عنوان Exchange Administrator) Admin.exe) معرفی شد و این سرور در حدود 500 صندوق پستی را در هر سرور پشتیبانی می‏کرد .

  • جالب است بدانید

سخت افزار مورد نیاز برای Exchange 4.0 در سال 1996 شامل پردازنده 486 ( 66MHz )، RAM 64MB و هارد دیسک 4GB بود. Exchange 4.0 توسط Exchange client 4 و تقویم کاربردی به نام Microsoft Schedule +7 پیکربندی و تنظیم می‏شد. امروزه می‏توان Exchange 4.0 را در پوشه System Public تحت عنوان Schedule +free/busy ببینید. که شامل زمان‏های آزاد و مشغول برای کاربران Outlook 2000 و قبل از آن است.

Exchange 5.0 چه بود؟

این ورژن برای پشتیبانی از سیستم عامل ویندوز NT4.0 و تکنولوژی‏هایی مثل LDAP v2 و SMTP معرفی شد.برای مایکروسافت کاملا واضح بود که تکنولوژی های اینترنتی به سرعت رشد خواهند کرد بنابراین سعی کرد روی تمام انواع پروتکل های اینترنتی مثل SMTP، NNTP و POP3 تسلط پیدا کند.این حرکت از زمانی که بیل گیتس یادداشت معروف خودش تحت عنوان " همه چیز برای اینترنت " را نوشت آغاز شد. در آن یادداشت تمام گروه های مهندسی مایکروسافت مجبور شده بودند تا هرچه سریع‏تر چگونگی و راه های پشتیبانی اینترنتی تمام محصولات را ارائه دهند.

در این تغییرات Exchange نیز اولین سرویس ایمیل تحت وب را با نام (Exchange Web Access EWA) معرفی کرد که بعدها به Outlook Web Access) OWA) و سپس به Outlook Web Application) OWA) تغییرنام داد. Exchange 5.0 در تاریخ 27 فوریه 1997 منتشر شد.Exchange client 5.0 و Microsoft Schedule +7.5 به عنوان نرم افزارهای سرویس گیرنده معرفی شدند . در اواسط سال 1997 در Outlook 8.0 هر دو نرم افزار در یک نرم افزار واحد ترکیب شد که به موفقیت سریع آن منجر شد.

وب سایت توسینسو

Exchange 5.5 چه بود؟

در تاریخ 5 نوامبر 1997 در کمتر از نصف سال برای تولید منتشر شد. Exchange 5.5 از symmetric multiprocessing ( چندپردازشی متقارن ) پشتیبانی می‏کرد. هم چنین برای دو نسل متفاوت پردازنده های Intel و DEC’s Alpha قابل استفاده بود . اگرچه پردازنده های Alpha قدرتمندتر بود اما Exchange هیچ وقت حتی برای بهره برداری از مزایای پردازنده های 64 بیتی Alpha از آن استفاده نکرد زیرا اعتقاد داشت که Platform محبوبی نبوده و هرگز به موفقیت تجاری دست پیدا نمی‏ کند.

ماکزیمم حجم Database در این نسخه از 16GB به 16TB افزایش یافت. دو این License با این نسخه ارائه شد: Standard و Enterprise. در نوع استاندارد فضای Database، 16GB بود و در نوع Enterprise حجم آن تا 16TB و قابلیت Fail-over Clustering تا حداکثر دو Node پشتیبانی می‏کرد. پشتیبانی از IMAP4 و LDAP v3 نیز به قابلیت های این نسخه اضافه شد. همچنین X.400، Site و Microsoft Mail را نیز پشتیبانی می‏کرد.

  • جالب است بدانید

Exchange 5.5 یک نسخه ویژه برای وزارت دفاع آمریکا ارائه کرد که تحت عنوان Defense Messaging System) DMS ) شناخته می‏شود.یکی از بزرگترین مشکلات Exchange 5.5 که در محیط های بزرگ خود را نشان می داد پشتیبانی از تنها 202 Exchange Site بود که اگر نیاز به تعداد بیشتری از این مقدار بوجود می آمد در این نسخه به مشکل برای یکسان کردن Address Book ها که به صورت واحد به اشتراک گذاشته بودند ، پیش می آمد.

این نکته هم قابل ذکر است که Exchange 5.5 یک سیستم پیام رسان قوی و قابل اطمینان بود که شرکت های زیادی را به استفاده از این نسخه کشانده بود و حتی برای مدت های طولانی استفاده از این نسخه ادامه داشت و دلیل برای تغیر آن توسط شرکت های مذکور وجود نداشت.Exchange Administrator که در شکل 1-1 نشان داده شده است برای بیشتر Admin ها بسیار قابل فهم و کار آمد بود و همچنین از نطر رابط و پشتیبانی کلاینت ، Exchange 5.5 کاملا مبتنی بر Outlook V8.03 بود و باعث شد تا Exchange Client و Schedule + کاملا کنار گذاشته شود.

اکسچنج سرور 2000 و 2003

شکل 1-1

معرفی Exchange server 2000 And 2003

این نسل در واقع نسل دوم به حساب می آید که از Active Directory به عنوان دایرکتوری سرویس استفاده می کرد که باعث شده بود تا عملکرد Exchange به سرویسی بیشتر از ایمیل منتهی شود.

معرفی Exchange 2000

سرور Exchange 2000 اولین برنامه کاربردی بود که کاملا به سرویس دایرکتوری مایکروسافت ، یعنی Active directory وابستگی داشت. Exchange 2000 در تاریخ 31 اوت 2000 انتشا یافت و نسخه آن 6.0 به حساب می آمد.این نسخه به سیستم عامل ویندوز سرور 2000 نیاز داشت و دیگر از ویندوز NT4.0 پشتیبانی نمی کرد. همچنین برنامه Exchange Admin به Exchange system manager) ESM ) تغییر یافت که بر پایه Microsoft Management Console) MMC) کار می کرد.

در سطح پایگاه داده Exchange ، مفهوم Storage Group پیاده سازی شد و کارایی Exchange برای میزبانی از چندین Mailbox ، توسعه یافت.در این نسخه Exchange Server قادر به میزبانی بیش از بیست Database بوده و Failover Cluster را از دو Node به چهار Node افزایش یافته است. Multiple Public Folder با قابلیت سلسله مراتبی معرفی شد و API و MAPI که تنها یک مرحله از سلسله مراتب را پشتیبانی می‏کردند به سرعت حذف شدند.همچنین در Exchange 2000 از MTA بر پایه X.400 به SMTP MTA تغییر رویه داده شد.به علاوه برای سهولت انتقال کاربران از Exchange 5.5 به Exchange 2000 از ابزار ADC استفاده می‏شد. در این نسخه اولین پیام رسان آنی ( Live Communication Server ) که امروزه به نام OCS یا به‏روزتر آن یعنی LYNC شناخته می‏شود، ارائه شد.

تاریخچه Exchange server 2003

این ورژن در تاریخ 30 ژوئن 2003 به عنوان نسخه 6.5 روانه بازار شد که بیشتر بر پایه Exchange 2000 نوشته شده بود. Exchange 2003 اولین Exchange بر پایه AD بود که به طور گسترده توسط مشتریان پذیرفته شد و بسیاری از شرکت‏های بزرگ محیط کاری خود را از Exchange 5.5 به Exchange 2003 تغییر دادند.Exchange 2003 روی ویندوز سرور 2000 و 2003 راه‏اندازی می‏شود. در کنار Stability (ثبات) و قدرت زیاد در این نسخه، یک زوج Key Client Access Feature برای Exchange معرفی شد: مورد اول معرفی مد Cached Exchange با Outlook 2003 بود که موجب بهبود کارایی استفاده از پهنای باند به خصوص در مورد کاربران راه دور می‏شد.

مورد دوم توانایی اتصال کاربران Outlook با استفاده از RPC Over https برای دسترسی به سرور Exchange با استفاده از اتصالات VPN بود. استفاده از RPC over https ( که بعدها به Outlook Anywhere تغییر نام داد ) فقط به یک اتصال http برای synchronize کردن e-mail نیاز دارد.کارایی در Exchange 2003 توسط سرور Mobile Information 2001,2002 مایکروسافت که برای ارائه Active Sync در Exchange مجتمع شده بود تا کاربران سیار ( Mobile Client) را پشتیبانی کند ( که به نام Window Mobile 5 شناخته می‏شود)، افزایش یافت. ویژگی Push-mail که از تکنولوژی Directpush استفاده می‏کند ( که به نام AUTDV2 نیز شناخته می‏شود ) که توسط Exchange 2003 Service Pack 2 اجرا می‏شود.

Exchange 2003 Service Pack حجم جدیدی از Database معادل 75GB را در Standard Edition ارائه می‏دهد. در Enterprise ماکزیمم حجم Database همان 16GB باقی ماند.در این نسخه آنتی اسپم و آنتی ویروس ها پیشرفت زیادی کردند، بنابراین Exchange 2003 SP1 ویژگی IMF (Intelligent Messaging Filter) را معرفی کرد که پیام‏ها را Scan و در صورت اسپم بودن آنها را Reject می‏کردند. آنتی ویروس‏های پیچیده‏تر و پیشرفته‏تر API برای ساختار بهتر جهت جلوگیری از Third-Partyهایی که راه حل‏هایی برای مختل کردن کار آنتی ویروس‏ها داشتند به Exchange اضافه شد تا از سیستم محافظت کنند.

شکل 1-2 سیستم مدیریت Exchange مورد استفاده در نسخه 2003 را نشان می‏دهد.

آموزش Exchange Server


Figure 1-2 Exchange System Manager in Exchange 2003

Exchange Server 2007 و بعد از آن

Exchange Server 2007 را می‏توان نسل سوم Exchange سرورها در نظر گرفت. این نسخه از پایه دوباره ساخته شد و نه تنها به یک پردازنده 64بیتی نیاز دارد، اولین نسخه از Exchange است که EMC (Exchange Management Console) را جایگزین ESM)Exchange System Manager) کرد که تمام گزینه‏های پیکربندی را داراست. پیکربندی بسیاری از تنظیمات پیشرفته نیازمند Windows PowerShell است که این گزینه بزرگترین گام حرکت به سوی Exchange 2007 بود.

  • جالب است بدانید

Adminهای Exchange قبل از کار کردن با Windows PowerShell باید کمی برنامه‏نویسی یاد بگیرند. گرچه خیلی زود این مورد به یکی از مهم‏ترین عوامل موفقیت تبدیل شد چرا که Adminها توانستند کارهای مدیریتی را خیلی سریع و به آسانی به حالت خودکار دربیاورند.EMC بر پایه Windows PowerShell بود که هنوز هم در مورد Exchange 2010 همین طور است. هر گزینه‏ای که شما در EMC انتخاب می‏کنید باعث یک Windows PowerShell cmdlet در Background می‏شود.Exchange 2007 پنج role سرور معرفی کرد:

  • Mailbox
  • Client Access Server
  • Hub Transport
  • Edge Transport
  • Unified Messaging

در مقاله بعدی به توضیح و آشنایی با این Role ها می پردازیم و نقش هر یک را برسی می کنیم . Roleهای خاص Exchange server را می‏توان در صورت نیاز اضافه یا حذف کرد. و تنها نصب کدی که برای role مورد نظرمان نیاز است، کافیست. یعنی مثل نسخه‏های قبل نیاز به نصب تمام کدها و Role نیست.Exchange 2007 بار دیگر مفهوم Message Routing را تغییر داد و برای تکیه کامل بر AD Site Mode و استفاده از سایت‏های (AD Site&Service)AD و Site Links برای مسیریابی‏های داخلی، Routing Groupها را حذف کرد.

کانکتورهای X.400 کنار گذاشته شدند و Storage Groupها را برای پشتیبانی از Replicationهای متوالی تغییر کرده و اصلاح شدند و روی یک Single Server تا پنجاه Database می‏توان ایجاد کرد.از نظر Failover Clustering، Exchange 2007 تکنولوژی Log File Shipping را اضافه کرد و پایه Database Availability Group برای Exchange 2010 گذاشته شد.

بنابراین علاوه بر اجرای Single-Copy Cluster)SCC) سنتی که به یک دیسک Shareشده نیاز داشت – مثل چیزی که در سیستم SAN (Storage Area Network) اجرا می‏شد – این نسخه از CCR)Cluster Continuous Replication) و LCR)Local Continuous Replication) نیز پشتیبانی می‏کند به این معنا که Failover Clustering را بهبود می‏بخشد. به این روش که Dataهای مربوط به Transaction Log که باید برای Update شدن Database یک کپی از آن روی یک سرور دیگر (CCR) یا روی دیسک (LCR) فرستاده شود را Replicate می‏کند.Exchange 2007 SP1، SCR)Standby Continuous Replication) را معرفی می‏کند که یک Message Database را به یک Exchange سرور راه دور Replicateمی‏کند.

Exchange 2007 فولدر Public را با جابجا کردن کنسول مدیریت از ESM به EMC حذف کردند اما به علت فیدبک کاربران مجددا در Exchange 2007 SP1 آن را در یک کنسول جداگانه که در EMC Toolbox راه ‏اندازی می‏شود، ارائه کردند.Exchange 2007 برای دور شدن از Public Folder،Auto discovery و سرویس Availability را که توسط Outlook 2007 و Clinetهای بعد از آن استفاده می‏شد را ارائه کرد.آوردن صدا به Mailbox یکی دیگر از تغییراتی بود که مایکروسافت در هسته Exchange 2007 اعمال کرد.Unified Messaging Server role برای فراهم کردن امکان دسترسی به Mailbox از طریق Voice اضافه شد. و به عنوان یک سیستم پست صوتی (Voice Mail) برای Office Communication Server 2007 R2 به کار گرفته شد.از دیدگاه Client برای اولین بار در تاریخ، Exchange server 2007 شامل یک Message Client جداگانه از OWA نبود.

مروری بر Exchange Server 2010

Exchange Server 2010 یکی از کاربردی‏ترین سیستم‏های Messaging در بازار است و همچنین محبوب‏ترین سیستم مورد استفاده در سازمان‏هاست.برای حفظ رقابت و ادامه توسعه فناوری که در Exchange 2007 آغاز شد، Exchange 2010 چندین قابلیت و ویژگی جدید به همراه آورد.کنسول مدیریت Management Console):Exchange 2010) شامل یک جفت کنسول مدیریت است که به شما امکان اجرای وظایف مدیریتی (Administrative Tasks) یا مدیریت پیکربندی‏های Exchange (Exchange’s Configuration) را می ‏دهد.

Exchange Management Console : ابزار EMC کنسول اصلی Administrative برای پیکربندی و مدیریت Exchange است که در شکل 1-3 نشان داده شده است.

ٍآموزش تصویری Exchange 2007

Figure 1-3 The EMC

در این کنسول مهم‏ترین تنظیمات برای پیکربندی Exchange وجود دارد و به شما امکان تغییر این Setting داده می‏شود البته اگر شما Permission لازم برای این کار را داشته باشید.EMC شامل بخش‏های اصلی زیر است که به شما در مدیریت Exchange کمک می‏کنند:

  • Exchange Configuration : شامل بخش Organization-wide configuration است که نه تنها روی یک Exchange سرور بلکه روی تمام سرورها تاثیر می‏گذارد. برای مثال پیکربندی DAGs (Database Availability Groups) و تنظیمات Mailbox Database در این سطح انجام می‏شود.
  • Server Configuration : به شما امکان مشاهده و تغییر تنظیمات Server based را می‏دهد که فقط روی یک سرور خاص اعمال می‏شوند. مثل Server-specific OWA یا تنظیمات POP3 یا اختصاص یک Dial-Plan (برنامه شماره گیری) به یک سرور Messaging یکپارچه (Unified Messaging Server).
  • Recipient Configuration : در این بخش شما تمام کارهای Recipient-related ( مرتبط با recipient ) را انجام می‏دهید مثل فعالسازی یک mailbox یا ایجاد یک لیست توزیع (Distribution list) یا ایجاد یک تماس (Contact).
  • Toolbox: شامل ابزارهای مختلفی است که به شما در Configure، Monitor و Troubleshoot کردن تنظیمات کمک می‏کند. مثل Queue Viewer و Best Practice Analyzer. توضیحات کامل و دقیق هر کدام از این بخش ها را در مقالات بعدی و در سایت ITpro دنبال کنید !
  • Show Exchange Management Shell Command: دکمه Show Exchange Management Shell Command بسیار مفید و کارآمد است اما به طور گسترده و بهینه در EMC سرور Exchange 2010 شناخته نشده است. این دکمه در گوشه پایین سمت چپ پنجره Dialog Box قرار دارد که برای نمایش و تنظیم Properties روی Objectهای Exchange استفاده می‏شود که در شکل 1-4 نشان داده شده است. زمانی که روی این دکمه کلیک کنید، پنجره‏ای باز می‏شود و Windows PowerShell Commandهایی که قرار است بعد از زدن دکمه OK یا Apply توسط Exchange اعمال شود را نشان می ‏دهد.
آموزش تصویری Exchange server

Figure 1-4 Show EMS command button

توضیحات اولیه

دوستان عزیز در ادامه آموزش های بخش های 1و2 (مقدمه و تاریخچه) به سراغ مقاله سوم از سری مقالات آموزشی Exchange server خواهیم رفت و با سرویس ها و قابلیت های این سرور بیشتر آشنا خواهیم شد ، در این سری از مقالات آموزش Exchange ، توضیحات اولیه از این سرور را آغاز خواهیم کرد

ثبت تمامی دستورات وارد شده در اکسچنج Exchange Management Shell Command Log

یکی دیگر از ابزارهای جدید EMC در Exchange 2010، Exchange Management Shell Command Log است که تمام Shell Commandهایی را که در EMC راه‏اندازی کرده‏اید، ثبت و ضبط می‏کند.همان طور که در شکل 1-5 نشان داده شده است، شما می‏توانید Command Logging را راه‏ اندازی کنید که به شما در مورد Commandهایی که اجرا کرده ‏اید، اطلاعات جزئی خواهد داد. همچنین می ‏توانید Commandها را در یک فایل CSV، Export کنید.


Figure1-5
  • شکل 1-5 : مشاهده لاگهای دستورات در Shell

برای دسترسی و مشاهده Exchange Management Command Log روی Objectهایی که در سمت چپ EMC قرار دارند، راست کلیک کرده و از گزینه‏ های ظاهر شده، View Exchange Management Log را انتخاب کنید.

Shell مدیریتی اکسچنج سرور یا Exchange Management Shell

EMC مبتنی بر Task است که مناسب Command-Line shell روی Windows Power Shell با زبان برنامه نویسی است که می ‏تواند راهی که شما توسط آن مدیریت خود را انجام می ‏دادید، آسان کند. از EMC مانند آنچه در شکل 1-6 نشان داده شده است، استفاده کنید. از این طریق شما می‏توانید هر کاری که در EMC می‏توانستید انجام دهید و به علاوه آن کارهایی که در EMC در دسترس نبود مثل پیکربندی پورت ارتباط POP3 را اجرا کنید.

Figure 1-6
  • Figure 1-6 The EMC

تمام Adminهای Exchange باید تحت آموزش قرار بگیرند و پایه و اساس EMC و چگونگی ایجاد Batch Script که کار روزانه آنها را ساده می‏ کند، بیاموزند.

اگرچه EMC اساسا توسط Adminها استفاده خواهد شد، هر کاربر Exchange که Power shell برای آنها فعال باشد ( تنظیمات پیشفرض) هم می‏توانند از EMC استفاده کند به شرطی که به یک Workstation که EMC روی آن نصب باشد، دسترسی داشته باشد. Role-Based Access Control )RBAC) مجموعه cmdlet که یک کاربر می‏ تواند ببیند یا اجرا کند را به کسانی که در Roleها به آنها Permission اختصاص داده شده است، محدود می‏

کند.

پنل مدیریتی و کنترلی یا Exchange Control Panel)ECP)

با ارائه ECP درواقع Exchange 2010 یک کنسول مدیریتی Web-based (مبتنی بر وب) دارد که می‏ تواند توسط Adminها و enduserها برای اجرای وظایف مدیریتی معمول برای Exchange 2010 استفاده شود. ECP از مدل RBAC برای Permissionدهی استفاده می‏کند. بناراین شما تنها می‏توانید قابلیت‏هایی که اجازه دسترسی به آنها را دارید، ببینید. توسط آدرس http:////<CASserver>//ECP که یک آدرس URL است یا از طریق Outlook 2010 می‏توانید به این پنل دسترسی یابید. ECP در شکل 1-7 نشان داده شده است.


Figure 1-7
  • Figure 1-7 Exchange Control Panel

در ECP می‏توانید چندین task مرتبط با User و Group را اجرا کنید، مثل modifyکردن تنظیمات mailbox و ایجاد distribution groups که امروزه Public group نامیده می‏شوند. همچنین می‏توانید Mail controls مثل ruleهای Journal یا Transport را پیکربندی کنید. به علاوه قادر به اجرای taskهای Reporting مثل Searching Delivery Report یا View و export کردن Auditing Reports خواهید بود. در زمینه کارهای مرتبط با Phone and Voice نیز می‏توانید تنظیماتی اعمال کنید. مثلا quarantining a device و configure کردن یک Active Sync Policy. در Chapter 4 اطلاعات بیشتری در مورد ECP کسب خواهید کرد.

  • نکته: یک قابلیت جدید در Exchange 2010 SP1 این است که برای استفاده از ECP نیازی به یک mailbox-enabled account ندارید. در جایی که شما از accountهای متفاوتی برای کارهای مدیریتی استفاده می‏ کنید این یک تغییر کاملا کارآمد در محیط است.
  • واما ..... بریم سراغ Role های Exchange

وظایف و نقش های موجود در اکسچنج سرور یا Exchange Server Roles

Exchange 2010 محصولی کلان است که بسیاری از جنبه ‏های Messaging که در Single Productها موجود بوده را به صورت مجتمع در خود دارد. این مجموعه شامل یک موتور مسیریابی Messaging (Messaging Routing engine) پیچیده است که می‏تواند حجم زیادی از e-mailها را زمانی که anti-spam، antivirus و compliance check در حال apply شدن است، پردازش کند. محدوده وسیعی از client protocolها از یک نمونه ساده مثل POP3 تا موارد پیشرفته‏تر مثل MAPI را پشتیبانی می‏کند.

به علاوه طراحی‏های مختلف سخت‏افزاری را از یک سرور simple multi-role به طراحی‏ های مبتنی بر DAG (Database Availability Group) جدید تطبیق می‏دهد که این امر برای ارائه دسترسی در سطح بالاست. جمع شدن تمام قابلیت ‏ها در یک محصول ممکن است کاربر را از نظر تجهیزات سخت‏افزاری مورد نیاز با مشکل روبرو کند. بنابراین مایکروسافت به شما اجازه انتخاب می‏دهد تا تنها roleهایی که نیاز دارید را install کنید. شکل 1-8 تمام Exchange Server roleهای در سترس را نشان می ‏دهد.

Figure 1-8
  • Figure 1-8 Exchange 2010 Server Roles Overview

می توان در یک نگاه این Role ها را به صورت کلی به ۵ دسته تقسیم کرد:

  1. Client Access Server
  2. Mail Box Server
  3. Hub Transport Server
  4. Edge Transport Server
  5. Unified Messaging

اگر بخواهیم به طور مختصر شرح حالی از عملکرد هر کدام از این Role ها را برسی کنیم می توانیم بگوییم:

  • ۱. Roleهای Client Access Server مسئول توزیع connectionهای client است: Outlook، OWA، Outlook Anywhere، Exchange Active Sync، Exchange Web Service)EWC) و پروتکل‏های POP3 و IMAP4.Pipelineها به ارتباطات user-based مرتبط با سرور mailbox خاتمه دادند و مسئول سرویس‏های اضافه مثل Auto discover، Availability و Exchange Web (Services (EWS است. در فصل 4 به تفصیل درباره‏ی Client Access Server Role بحث خواهد شد.
  • ۲. دیتابیس mailbox و درنتیجه dataهای mailbox روی Mailbox Server Role ذخیره می‏شوند. دیتابیس Public Folder نیز روی Mailbox Server Role ذخیره می‏شود. Roleهای mailbox برای ساختن Server Role Tolerance شامل DAGهاست. در فصل 6 می‏توانید اطلاعات بیشتری در مورد Mailbox Role به دست آورید.
  • ۳. تمام Message Routingها توسط Roleهای Hub Transport Server که مسئول تحویل (delivery) پیام به mailbox مقصد درست هستند و به علاوه وظیفه مسیریابی پیام‏ها به محیط‏های خارجی مثل اینترنت را نیز برعهده دارند. در فصل 5 به این موضوع بیشتر پرداخته خواهد شد.
  • ۴. درست مثل Hub Transport، Roleهای Edge Transport نیز برای اهداف Routing پیام‏ها هستند. اما این roleسرورهای خاص می‏توانند در یک zone مشخص برای ارسال و دریافت پیام از اینترنت قرار بگیرند. به علت موقعیت قرارگیری، این roleها دارای قابلیت آنتی اسپم و آنتی ویروس جهت محافظت از محیط Internal شما نیز هستند. در فصل 7 توضیحات بیشتری داده خواهد شد.
  • ۵. Roleسرورهای Unified Messaging (UM)، Messaging صدا (Voice) و e-mail را با هم ترکیب می‏کند که سبب integrate (مجتمع) شدن شبکه‏های تلفنی در Exchange خواهد شد. این roleها به شما امکان این را می‏دهند تا از Exchange به عنوان سیستم Voice Mail برای تجهیزات OCs 2007 R2 استفاده کنید. در فصل 9 با جزئیات بیشتری در این زمینه آشنا خواهید شد.

در این شکل هم نمایی دیگر از Role های گفته شده را خواهیم دید

Figure1-9

Figure 1-9 Exchange 2010 Enterprise Topology

قابلیت ها و نسخه ها

ویژگی‏های تغییر یافته ‏ی Exchange 2003 و 2007

همان‏طور که با هر نسخه جدیدی از نرم افزارها، ویژگی‏ها و قابلیت‏های نسخه‏ ی قدیمی در آن کنار گذاشته می‏ شود و از آنجایی که تکنولوژی به طور پیوسته در حال پیشرفت و تغییر است، مایکروسافت نیز با رعایت تعادل در مورد Exchange 2010 یک سری قابلیت‏ های جدید اضافه نموده، کارایی‏ های موجود را حفظ کرده و قابلیت‏ های منسوخ شده را حذف نموده است.البته شما می‏ توانید برای نگه داشتن و استفاده از قابلیت‏ های Exchange 2003 و 2007 از یک سرور Legacy کمک بگیرید که این یک گام میانی است.

اگر در حال حاضر از Exchange 2003 یا 2007 استفاده می‏ کنید لازم است که حتما بدانید که در محیط messaging فعلی شما از چه featureهایی استفاده می‏ شود و پروتکل‏ های مورد نیاز applicationها را نیز بشناسید. این امر از شوکه شدن شما زمانی که یک application به علت تغییر به ورژن 2010 از کار بیفتد، جلوگیری می‏ کند.جدول 1-2 لیست ویژگی‏هایی از Exchange 2003 است که در نسخه 2010 در دسترس نیست و به جای آنها قابلیت‏های جدیدی را که در 2010 موجود است را توضیح می ‏دهد.

table 2-1
Table 2-1

اگرچه به نظر می‏رسد که Exchange 2007 خیلی شبیه به Exchange 2010 است اما تفاوت‏ هایی بین این دو نسخه وجود دارد که در جدول 1-3 آمده است.

Table1-3

تفاوت Exchange on-premise و Exchange online

نصب Exchange به صورت سنتی به سخت ‏افزاری نیاز داشت که در Data-center شما قرار می‏ گرفت، به علاوه برای اجازه راه ‏اندازی لازم بود که License نرم‏ افزار خریداری می‏ شد و در آخر به Adminهایی که سرورها را مدیریت کنند، احتیاج داشت.در اوایل سال 2006، مایکروسافت ایده Software as a Service (SaaS) را برای تولید سرویس کاربردی on-demand معرفی کرد و آن را in-the-cloud messaging service Exchange online نامید.برای ایجاد وجه تمایز بین Exchange online و installationی که شما در شرکت خودتان پیاده می‏ کنید، Exchange 2010 از عبارت( on-premise (on-prem استفاده کرده است چون سرورها روی premiseهای شما راه ‏اندازی می‏شوند. نسخه امروزی Exchange online بر پایه Exchange 2010 است. دو گزینه متفاوت برای ارائه Exchange وجود دارد که به صورت زیر است:

  • Exchange on-premise : این نسخه به طور کلی به مشتریان اختصاص داده شده است، سرور Exchange در یک Data-center برای مشتریان قرار داده شده است (در premise مشتریان) و License شامل یک قیمت ثابت برای هر دو مجوز سخت ‏افزاری و نرم‏افزاری است.
  • Exchange online : این سرویس یه عنوان سرویس multi-tenant یا hosting ارائه شده است. به طور کلی برای تعداد زیادی از مشتریان استاندارد شده است. صدور مجوز (License) بر حسب تقاضا (on-demand) است یعنی اینکه شما تنها برای mailboxهایی که استفاده می ‏کنید، مبلغی پرداخت می‏کنید.

در این حالت سرورهای Exchange در یک Datacenter مشترک قرار داده می ‏شوند و شما برای ارتباط با آن از یک اتصال secureشده از طریق اینترنت استفاده خواهید کرد. مایکروسافت سرویس‏های Exchange online را تحت عنوان BPOS (Business Productivity Online Services) line ارائه می ‏دهد.سرور Exchange 2010 اولین نسخه از Exchange است که یک رویکرد واقعی از ترکیب سرویس‏های Exchange online را ارائه می‏ دهد. این ورژن به طور کلی برای این طراحی شده است که به شما اجازه بدهد تا userهای حساس را روی premiseهای خودتان میزبانی کنید و بقیه را به cloud یا Exchange online بفرستید.همزیستی (Coexistence) بین کاربران از ویژگی ‏های جدید Exchange 2010 است. این ویژگی تحت عنوان Federation Service اجازه می‏ دهد تا اطلاعات mailboxها مثل زمان Free//Busy آنها با دیگر company (شرکت‏ها) به اشتراک گذاشته شوند. این مطلب در شکل 1-10 نشان داده شده است.

Table 1-10
  • شکل 10 - اکسچنج سرور در محیط SaaS

تمام کنسول‏های مدیریتی Exchange 2010 مثل EMC قادر به مدیریت تنظیمات هردو نسخه online و on-premise هستند. بنابراین راه‏ اندازی یک سازمان Exchange که در آن سرویس hybrid ارائه می‏ شود سبب کاهش هزینه‏ های mailbox برای شرکت خواهد شد. ویژگی‏ها شامل جابجایی mailboxها از on-premise به online است زمانی که کاربر آن mailbox بر اساس یک schedule، log in می‏ کند درست مثل ECP که کنترل self-service را برای کاربران پشتیبانی می ‏کند. البته مایکروسافت تنها شرکتی نیست که hosted Exchange 2010 را ارائه می‏ کند.

بعضی از شرکت‏ها hosted Exchange را برای مدت 10 سال یا بیشتر است که دارند و تجربه بیشتری در این فضا دارند. تفاوت Exchange online این است که مایکروسافت محصولی را توسعه داده است که به سادگی در یک محیط hosted کار کند، همان طور که در یک سازمان on-premise کار می‏ کرده است.

مقالات ما روی Exchange on-premise تمرکز دارد اما در فصل 10 (Federated Sharing) اطلاعاتی راجع به اینکه چگونه یک سازمان Exchange دیگر را به محیط Exchange خود متصل کند، در اختیار خوانندگان عزیز انجمن تخصصی فناوری اطلاعات ایران قرار می ‏دهیم. در واقع شامل اطلاعاتی درباره چگونگی اتصال Exchange به Exchange online است.برای کسب اطلاعات بیشتر در مورد Exchange online به آدرس زیر مراجعه کنید:

http://www.microsoft.com/online/exchange-online.mspx.

License های Exchange Server 2010

مسئله مهمی که اغلب نادیده گرفته می‏ شود این است که چه ورژن و چه License از Exchange مورد نیاز است و دقیقا طبق نیاز خریداری شود. که این انتخاب سبب صرفه‏جویی در هزینه‏های شرکت خواهد شد.Licenseهای متداول Exchange بر حسب Server یا Client Access License) CALs) خریداری خواهد شد. البته License دیگری تحت عنوان External Connector وجود دارد که به شما این اجازه را می‏ دهد تا تعداد نامحدودی از Userها را به عنوان سرویس گیرنده پشتیبانی کنید و نگران تمام شدن Licenseهای خود نباشید. (که بیشتر برای ارائه سرویس به کاربران اینترنتی استفاده می‏شود.)

Edition های Exchange Server 2010

همانند نسخه‏های قبلی Exchange نسخه 2010 نیز شامل دو ورژن است : Enterprise و Standard ، هر دو Edition به وسیله یک Product key فعال می‏شوند به این معنا که با داشتن یک product key معتبر می‏توان بین نسخه‏های enterprise و standard سوئیچ کرد. اگرچه نسخه Standard سرور Exchange 2010 برای شرکت‏های کوچک هدف‏گذاری شده است اما می‏تواند برای roleهای خاصی از Exchange سرور مثل Hub Transporter و Unified Messaging از آن استفاده کرد. نسخه Enterprise می‏تواند mount کردن 100 database را به صورت همزمان پشتیبانی کند. که به این علت برای شرکت‏های بزرگ مناسب‏تر است.در جدول 1-4 ویژگی‌های در دسترس هر Edition آورده شده است.

Table1-4


تفاوت اصلی Standard و Enterprise در تعداد mailboxهای mountشده روی یک سرور است. به علاوه توسط نسخه استاندارد می‏توانید DAGs ایجاد کنید اما به یاد داشته باشید که برای استفاده از ویژگی Clustering در DAG به نسخه Enterprise ویندوز سرور 2008 نیاز خواهید داشت.

  • نکته : برای تمام roleهای سرور می‏توانید از نسخه Standard استفاده کنید و تنها زمانی که سرور mailbox شما به بیش از پنج database به صورت همزمان نیاز دارد از نسخه Enterprise استفاده کنید.
  • نکته: اگر شما نگران این هستید که نسخه Trial شما بعد از expire شدن با چه مشکلی روبرو خواهد شد باید خیلی سریع بگوییم که هیچ مشکلی!!! به جز اینکه چندین پیغام هشداردهنده با این موضوع که سرور Exchange شما نیاز به خرید License دارد. شما همچنان روی نسخه Standard باقی خواهید ماند البته دیگر هیچ پشتیبانی از طرف مایکروسافت برای Exchange سرور خود نخواهید داشت.

Exchange Server 2010 Client Access Licenses

Exchange سرور 2010 با دو نسخه از CAL ارائه می‏شود: Standard CAL و Enterprise CAL ، همیشه باید نسخه Standard CAL را خریداری کرد اما اگر به امکانات پیشرفته‏تری مانند Voice mail نیاز داشتیم باید نسخه Enterprise را نیز خریداری کنیم.

  • نکته: هردو نسخه این CALها می‌‏‌توانند بر روی هردو Edition سرور اجرا شوند مثلا Standard CAL بر روی Enterprise Edition و بالعکس می‌توانند راه‌‌اندازی شوند. جدول 1-5 ویژگی‌های نسخه‏های CAL را نشان می‌دهد.
Table 1-5

امکانات پاورشل

Exchange Organizational Health

EMC شامل گزینه‏ای (Option) است که یک گزارش از Organizational Health تولید می‏کند و نمای کلی از تشکیلات Exchange به شما می‏دهد که شامل اطلاعات License و خلاصه‏ای از سرور و سرویس گیرندگان Exchange نیز می‏باشد. از طریق این اطلاعات شما می‏توانید اطمینان حاصل کنید که Edition و License سرور Exchange شما به درستی خریداری شده است. شکل 1-11 یک نمونه از گزارشات را نشان می‏دهد.Organizational Health مجموعه‏ های زیر از Userها را برای محاسبه CAL اسکن می ‏کند:

  • Unified Messaging Users
  • Managed Custom Folder Users
  • Advanced ActiveSync Policy
  • Archived Mailbox Users
  • Retention Policy Users
  • Searchable Users
  • Journaling Users


Figure 1-11

Figure 1-11 Viewing Organizational Health in EMC

Windows PowerShell and Exchange 2010

یکی از بزرگترین تغییرات همانند حرکت به سوی AD در Exchange 2000 ،رفتن به سمت استفاده از Windows PowerShell برای پایه‏گذاری مدیریت اتوماتیک taskها در Exchange 2007 بود.Windows PowerShell یک Interface (واسط) command-line است که برای تهیه و ارائه یک واسط مدیریتی متنی و قابل برنامه‏ریزی ایجاد شد. شاید استفاده از این محیط برای خیلی از ادمین های عزیز کمی سخت و یا غیر جذاب باشد اما این نکته مهم را نباید فراموش کرد که این ابزار بسیار سودمند و کار راه انداز خواهد بود. بر پایه موفقیت Exchange 2007 و Windows PowerShell ، Exchange 2010 به طور شدید با Windows PowerShell 2.0 و Win Remote Management 3.0 (WinRM) برای ایجاد یک سیستم Role-based Access Control ادغام شد که یک راه‏حل امن و scalable برای scripting ارائه کرد.برای اشنایی بیشتر با Power Shell و Cmdlet این لینک هم به شما کمک خواهد کرد:

http://technet.microsoft.com/en-us/library/hh848794.aspx


Powershell-Cmdlet

WinRM یک پیاده ‏سازی از WS-Management )WSman) را فراهم می‏کند. این ویژگی امکان مدیریت از راه دور را از طریق گوش دادن به اتصال مدیریت با استفاده از پورت 80 TCP/IP در درجه اول فراهم می‏کند. به طور پیش فرض ارتباطات فقط زمانی مجوز می‏گیرند که توسط سرویس‏دهنده امنیتی Kerberos یا Negotiate رمزنگاری (encrypt) شده باشند.کنترل دسترسی امنیتی مبتنی بر Role یا RABC یکی از ویژگی‏های ساخته شده روی Windows PowerShell 2.0 است. که اجازه می‏دهد تا یک role ایجاد شود و سپس برای فیلتر کردن cmdletها و پارامترهایی که برای مشاهده و اجرا در دسترس هستند به کار برود.

  • نکته: RBAC در Windows PowerShell 2.0 به شما این اجازه را می‏دهد تا تنها cmdletهایی که Permission دسترسی به آنها را دارید ببینید. برای مثال اگر شما عضو Organizational Management Role Group باشید نمی‏توانید cmdletهای New-Mailbox Export Request را ببینید چون برای دیدن این cmdlet به Mailbox import export role نیاز دارید.

در Exchange 2007 باید Windows PowerShell Runspace و Exchange snap-in روی workstation مدیریتی نصب می‏شد و همچین یک اتصال full RPC لازم بود تا بتوان Exchange سرور را مدیریت کرد. این شرایط در domain و شبکه‏ های پیچیده مشکل‏ ساز شده بود. به علاوه باید روی هر station مدیریتی فایل‏های باینری Exchange نصب و نگهداری و در مواقع لزوم (زمانی که ورژن جدیدی ارائه می‏شد) Update شوند. همان طور که قبلا گفته شد با Exchange 2010 و Windows PowerShell 2.0 تمام ارتباطات domain (مدیریتی) که در حال حاضر در دسترسند از پورت 80 یا 443 TCP استفاده می‏کنند و نه هیچ پورت TCP تصادفی دیگر.و این یعنی بهبود دسترسی و مدیرت Exchange از طریق Powershell .

از آنجایی که این پورت‏ها معمولا برای دسترسی به اینترنت باز گذاشته می‏شوند می توان ازطریق encrypt کردن آنها ازبستر فایروال راحت‏ترو بسیار امن تراز راه دورارتباط گرفت. اگرچه framework مدیریتی Exchange 2007 ویژگی‏های زیادی را از طریق Windows PowerShell به ارمغان آورد اما کمبودهایی نیز داشت. در EMS در Exchange 2007، cmdletها همان طور که توضیح داده شد روی سرور اجرا می‏شدند.

بنابراین شما هیچ قدرتی برای کنترل منابعی که این cmdletها استفاده می‏کردند، نداشتید.در Windows PowerShell 2.0 ارتباطات به واسطه‏ی WSMan راه‏اندازی می‏شوند که امکان کنترل ارتباطات را فراهم می‏کند و این احتمال که Admin بر اثر اعمال taskهایی برخلاف Exchangeسرور کارایی Client را بیش از حد فشرده کند را کاهش می‏دهد.

    • نکته:وقتی به صورت remote به یک Exchangeسرور متصل می‏شوید، شما بدون واسطه نمی‏توانید بفهمید که به کدام سرور متصل شده‏اید. برای تشخیص Exchangeسروری که به آن متصلید از Get-PSSession f ComputerName cmdlet استفاده کنید.
Get-PSSession | fl ComputerNamecmdlet***

تفاوت اصلی بین Exchange 2007 و Windows PowerShell 1.0 با Exchange 2010 و Windows PowerShell 2.0 دراین است که Exchange snap-in زمانی که EMS را باز می‏کنید به طور Locally بارگذاری (Load) نمی‏شود. در عوض Windows PowerShell با استفاده از سرور WinRM به نزدیکترین Exchange 2010 متصل می‏شود، عملیات چک کردن Authentication اجرا می‏شود و در نهایت یک نشست از راه دور (remote session) برای شما ایجاد می‏شود. شکل 1-12 روند Login کردن به EMS در Exchange 2010 را نشان می ‏دهد.


Figure 1-12

Figure 1-12 EMS Process

زمانی که شما EMS را راه‏اندازی می‏کنید، مراحل زیر قبل از اینکه شما بتوانید از EMS استفاده کنید در background انجام می‏شود:

  1. وقت که EMS یک نشست جدید راه دور Windows PowerShell را باز می‏کند که توسط IIS روی سرور راه دور establish شده، IIS در این زمان User را authenticate (شناسایی) می‏کند.
  2. WSMan virtual directory (Windows PowerShell Vdir) با سرور تماس برقرار کرده و اطلاعات مربوط به شناسایی کاربر را می‏گیرد.
  3. ماژول Exchange RBAC Unmanaged Authorization برای بررسی اینکه فرآیند Logon می‏تواند ادامه یابد یا خیر، اجرا می‏شود. بعد از این مرحله با AD جهت احراز هویت (authorize) کاربر تماس می‏گیرد. در صورت موفقیت، WSMan دستور ادامه پروسه را می‏دهد. اگر عملیات authorize با موفقیت انجام نشود، WSMan دستور توقف ادامه فرآیند را می‏دهد.
  4. WSMan اطلاعات اصلی کاربر را به Windows PowerShell fan-in provider می‏فرستد. یک fan-in provider اجازه می‏دهد تا تعداد زیادی اتصال به یک سرویس برقرار شود. PowerShell fan-in provider به IIS اجازه می‏دهد تا Windows PowerShell را call (فراخوانی) کند.
  5. Windows PowerShell اطلاعات اصلی کاربر را به registered authorization Module ( Exchange RBAC Managed Authorization Module) رد می‏کند که مشخصات اتصال User را با AD آنالیز کرده و initial session state را برای بازگرداندن به Windows PowerShell آماده می‏کند. Initial session state شامل cmdlet و پارامترهایی است که اتصال user را باز می‏کند.
  6. ماژول Exchange RBAC Managed Authorization این اطلاعات را از طریق initial session statement به Windows PowerShell برمی‏گرداند.
  7. یک (runspace) فضای کار client روی سرور داخل IIS worker process ایجاد می‏شود. و PowerShell پروکسی‏های راه دور مجازی را برای داخل IIS worker process جهت تحویل به client پیکربندی می‏کند.
  8. Runspace با استفاده از عملیات Import-PSSession روی کلاینت بازگشته و import (وارد) می‏شود.

Windows PowerShell نه تنها برای Exchange که برای سایر محصولات نیز قابل دسترسی است. شامل محصولات مایکروسافت مثل System Center Operations Manager ، Systems Center Virtual Machine Manager، System Center Data Protection Manager ، Microsoft SQL Server 2008 و خیلی ویژگی‏ها در Windows Server 2008 R2 می‏شود. سایر محصولات third-party نیز Windows PowerShell را به عنوان یک Interface مدیریتی دربردارند. این حرکت سبب ایجاد انگیزه در یادگیری و حرفه‏ای شدن در استفاده از Windows PowerShell شده که باعث مدیریت راحت‏تر تمام این محصولات می‏شود.

پایه ‏های Windows PowerShell

برای کسانی که قبلا در Exchange 2007 با Windows PowerShell کار کرده‏اند، خوشبختانه تغییرات کوچکی در Windows PowerShell ایجاد شده هرچند که اغلب آنها زیرساختی هستند و برای کسانی که هیچ تجربه‏ای در Windows PowerShell Exchange 2010 ندارند، توضیحات زیر کمک بزرگی به شما خواهد کرد.Windows PowerShell یک محیط عملیاتی object-based است که برای ارائه یک Interface قوی مدیریتی ساخته شده است.

هر کدام از actionهای Windows PowerShell تحت عنوان cmdlet شناخته می‏شوند. نام این cmdletها همیشه با یک فعل شروع می‏شود و بعد از آن یک خط فاصله و سپس یک نام می‏آید. به طور مثال برای بازیابی اطلاعات درباره یک mailbox شما باید cmdlet با نام Get-Mailbox را run کنید. بعضی از فعل‏ های به کار رفته در cmdlet در زیر آمده است:

  • Add : این گزینه یک object را در یک object دیگر که از قبل موجود بوده، قرار می‏دهد. مثلا Add-DistributionGroupMember یک شیء (object) mail-enabled را به یک distributiongroup اضافه می‏کند.
  • Get : این گزینه اطلاعات را بازیابی می‏کند. ( هیچ تنظیماتی را تغییر نمی‏دهد.). به طور مثال Get-Mailbox اطلاعات یک یا چندین mailbox را فراخوانی می‏کند.
  • New : این گزینه یک نمونه جدید از یک object یا task را ایجاد می‏کند. مثلا New-Mailbox یک mailbox جدید ایجاد می‏کند.
  • Remove : این گزینه یک شیء را از یک object دیگر حذف یا از آن جابجا می‏کند. به طور مثال Remove-DistributionGroup آن distribution گروه خاص را حذف می‏کند.
  • Set : این گزینه تنظیمات را تغییر می‏دهد. برای مثال Set-Mailbox تنظیمات یک mailbox خاص را تغییر می‏ دهد.

بخش دوم نام cmdlet که بعد از خط فاصله می‏آید هدف فعل ماست. دوبخشی بودن cmdlet باعث می‏شود تا تشخیص عملیاتی که ما به آن نیاز داریم راحت‏تر شود. به طور مثال اگر ما نیاز داشته باشیم که یک database جدید ایجاد کنیم باید در cmdletها دنبال آنی باشیم که با New شروع می‏شود و در آخر آن نیز کلمه database باشد. (New-MailboxDatabase)

به علاوه هر cmdlet شامل پارامترهایی است که برای کنترل عملیات cmdlet اجرا می‏شوند. مثلا Set-Mailbox شامل پرامترهای زیادی است مانند Identity ، DisplayName ، HiddenFromAddressListEnabled ، IssueWarningQuota ، LitigationHoldEnabled و ... . بیش از 100 پارامتر برای Set-Mailbox وجود دارد. برای مثال برای تنظیمات mailbox کاربری به نام Joel می‏خواهید warning quota to 2 GB را راه‏اندازی کنید. برای این کار cmdlet زیر را اجرا کنید:برای مثال

Set-Mailbox -Identity Joel -IssueWarningQuota 2GB

پارامتر Identity در هر cmdlet در واقع objectی است که شما می‏خواهید object دیگری را برای آن اجرا کنید. به طورمعمول در cmdletها پارامتر Identity در جایگاه اول قرار می‏گیرد که می‏توانیم آن را حذف کنیم. برای درک بهتر این مسئله مثال بالا را بدون پارامتر Identity می‏نویسیم:

Set-Mailbox Joel -IssueWarningQuota 2GB

که این cmdlet نتیجه‏ای مشابه cmdlet بالایی دارد.

طراحی و سوالات فنی

Framework پروژه های پیاده سازی Exchange سرور

در ادامه آموزش های گام به گام سرور Exchange این بار هدف را بر نحوه‌ی جمع آوری اطلاعات، فاز طراحی و نیازسنجی های لازم جهت پیاده سازی سرویس ها و سرورهای Exchange در نظر گرفته ایم. قرار است شما را با MOF، اجرای استراتژیک یک پروژه و فاز Plan، Deliver و Operate که یکی از اصلی ترین پیش نیازهای پروژه های بزرگ شبکه ای است آشنا کنیم. انشاا... در مقالات بعدی شروع به آموزش تخصصی نصب و جزئیات ساختاری سرویس و سرور Exchange خواهیم پرداخت.شاید این بخش از آموزش های گام به گام در وهله اول کمی مدیریتی و با دید کلی باشد.

اما برای اینکه یک سرویس شبکه ای به طور تمام و کمال به مرحله استفاده و پیاده سازی دائم برسد نیاز است تا قبل از نصب فیزیکی سرویس و تنظیمات آن (که غالبا کار مشخص و ثابتی است) تمام زوایای آن بررسی و Plan دقیقی برای آن در نظر گرفته شود تا از پیاده سازی های چند باره و هزینه های سربار جلوگیری به عمل آید. Microsoft Operations Framework ) MOF )سه فاز دارد: Plan، Deliver و Operate. لایه عملیاتی یا پروسه دیگری به نام Manage نیز وجود دارد که در شکل 2-1 نشان داده شده است. اگرچه نام هر فاز بیانگر این است که در هر مرحله چه اتفاقاتی می‏افتد اما جزئیات و زیرپروسه‏های زیادی در هر کدام است و زمانی که با هم ترکیب می‏شوند شکل کامل MOF را تشکیل می‏ دهند.

Figure 2-1
  • Figure 2-1 The MOF life cycle

فاز Plan شامل استراتژی کلی شرکت است. بخش Deliver توسعه و اجرای استراتژیک پروژه‏هاست. فاز Operate شامل نگهداری سیستم‏های توسعه‏یافته است. بخش Manage یک پروسه‏ی همیشگی و متوالی است که بهبود و توسعه را برای هر یک از فازهای عملیاتی راه‏اندازی و اجرا می‏کند.

برنامه ریزی برای پیاده سازی پروژه های Exchange سرور

اگرچه این متن آموزش MOF نیست این بخش فازهای اساسی برای یک Exchange Server 2010 Deployment و جزئیات اضافه‏ی مورد نیاز را بیان می‏کند. در ادامه تک تک این فازها که مرتبط با deploy کردن Exchange 2010 است مورد بحث قرار خواهد گرفت.

طرح ریزی و نقشه در پروژه های Exchange سرور

فاز Plan دوگانه است و معمولا با مشارکت صاحبان کسب و کار، مدیران و معماران فنی کامل می‏شود، این منابع برای هدایت هر پروژه‏ی IT در هر شرکت مورد نیاز است. اولین گام در فاز Plan شامل ارزیابی ظرفیت مدیریت Solution موجود و سپس برنامه ‏ریزی برای نیازها و ظرفیت‏های بیشتر است. دومین گام مربوط به چگونگی ایجاد یک استراتژی تکنولوژی و کسب و کار در حیطه IT Solution برای این شرکت است.

فاز Plan را می‏توان به خرید یک اتومبیل تشبیه کرد. ابتدا شما تشخیص می‏دهید که نیاز به خرید یک ماشین جدید دارید زمانی که اتومبیل فعلی شما جوابگوی نیازهای شما نیست. قدم بعدی این است که شما بودجه خود را بررسی کنید و اینکه چه ویژگی‏ها و قابلیت‏هایی نیاز دارید و نهایتا اینکه چه زمانی می‏خواهید اتومبیل را خریداری کنید. به همین ترتیب در فاز Plan تصمیم‏گیرندگان نیاز برای تغییر را تشخیص می‏دهند و سپس بالاترین سطح کارایی مورد نیاز انتخاب شده و در آخر زمان اجرا و تکمیل پروژه نیز تعیین می‏گردد. خروجی این فاز شامل IT mission و اطلاعات بودجه‏ای است. در فاز Plan به تعدادی سوال باید پاسخ داده شود که می‏توان آنها را به دو بخش business و technical تقسیم کرد.

سوالات کسب و کار (business)

اگرچه پرسش‏ها برای هر کسب و کار و در طول زمان تغییر خواهد کرد با این حال لیست زیر در شروع این روند به شما کمک خواهد کرد.

  • اهداف استراتژیک کسب و کار سازمان چیست؟ اهداف استراتژیک و طرح‏ها شامل پروژه‏ها و گرایش بازار است که در حال حاضر روی شرکت تاثیر می‏گذارد و همچنین آنهایی که ممکن است در چند سال آینده روی شرکت تاثیرگذار باشند.مستندسازی این اهداف در ایجاد چشم‏انداز IT (IT vision) کمک بزرگی می‏کند که سبب می‏شود تا کل نیازهای شرکت مجسم شوند. برای دستیابی به هدف حداقل سه هدف کوتاه‏مدت و سه هدف بلندمدت را لیست کنید. این اهداف ممکن است شامل گرایش و روند بازار مثل افزایش فشار برای پاسخگویی بهتر سرویس به مشریان یا دستیابی به certificate (گواهینامه) باشد. هدف بلندمدت ممکن است برای این شرکت عمومی شدن در تجارت یا رقابت در یک بازار جدید باشد که نیاز به مقررات و آئین نامه جدید دارد. داشتن این اطلاعات، کارایی، ویژگی، سخت افزار و نرم‏افزارهای third-party مورد نیاز برای ارزیابی و دستیابی به این نیازها را شکل می‏دهد.
  • اهداف مالی این پروژه‏ها چیست؟ برای هر پروژه‏ای یک سری محدودیت وجود دارد. این منابع ممکن است مالی، مربوط به پرسنل یا حتی محدودیت زمانی باشد. قبل از شروع هر پروژه تمام این موارد این را شناسایی کنید. مواجه با این محدودیت بعد از شروع پروژه ممکن است پروژه را محکوم به شکست کند. یکی از این اهداف بودجه‏ای ممکن است کاهش هزینه‏های سخت‏افزار و نرم‏افزار برای یک solution خاص باشد یا شاید کاهش هزینه‏های عملیاتی به وسیله کاهش تعداد کارکنان.
  • آیا موانع داخلی در کسب و کار هست که سبب ایجاد تاخیر یا تغییر اهداف در نیازهای کار گردد؟
  • آیا پروسه یا بخشی از کسب و کار داخلی هست که نیاز به توجه بیشتری داشته باشد تا موفقیت پروژه بیمه شود؟ علاوه بر اینکه این بخش‏ها و پروسه‏ها باید به عنوان ریسک شناسایی شوند باید مستندسازی شده و در محلی قرار بگیرند.
  • کدام وظایف باید توسط کارکنان فعلی IT و مشاوران داخلی انجام شود و کدام کارها باید برون‏سپاری گردد؟ بعضی از وظایف ممکن است برای کسب و کار بسیار استراتژیک باشد نیاز به تخصص یا مهارت خاصی داشته باشد بنابراین ممکن است آنها را به یک شرکت مشاوره یا رائه‏کننده خدمات برون‏سپاری کنیم. سرویس‏هایی مثل مدیریت Unified Messaging یا سرویس‏های anti-spam ممکن است جزء این گروه باشد.
  • دلایل کسب و کار برای استفاده از یک تکنولوژی چیست؟ آیا درایورهای تجارتی برای مهاجرت یا پیاده‏سازی جدید یا تکنولوژی جدید وجود دارد؟ اغلب بهبود بهره‏وری یا کاهش هزینه‏های کلی دلیل استفاده از تکنولوژی‏های جدید است. در این موارد، بازگشت سرمایه‏گذاری و کل هزینه مالکیت پارامترهایی هستند که باید در نظر گرفته شوند و همچنین بررسی این موضوع که آیا سخت‏افزار و نرم‏افزارهای قدیمی‏تری هستند که برای جلوگیری از هزینه‏های نگهداری لازم باشد که از کار کنار گذاشته شوند.
  • چه تجهیزات صنعتی خاصی مورد نیاز است؟ امروزه بسیاری از صنایع در حیطه قانون الزامات خاصی دارند از جمله بیمه حمل و قانون پاسخگویی (HIPAA)، کارت‏های پرداخت صنعت امنیت اطلاعات استاندارد (PCI DSS) و ... . این نیازمندی‏ها می‏تواند مشخصات طراحی محیط را به کلی تغییر دهد. در هر پروژه این شرایط نیاز به شناسایی و ترسیم یک چشم‏انداز کلی دارد.

سوالات فنی (Technical)

در زیر نمونه‏ای از سولات فنی که در مرحله Plan لازم است به آنها پاسخ داده شود، لیست شده است:

  • مهم‏ترین اهداف تکنولوژی برای سازمان شما چیست؟ معمولا یکی از سرویس‏های اصلی کسب و کار محیط Messaging است. بنابراین تصمیمات اتخاذ شده در این زمینه می‏تواند سبب پیشرفت یا رکود توانایی‏های سازمان برای رسیدن به اهداف استراتژیک کسب و کار شود. اهداف اصلی را لیست کنید این اهداف ممکن است شامل بهبود همکاری (collaboration)، بهبود در دسترس بودن (Availability)، بهبود کارایی کاربر راه دور (remote user) و Unified Messaging باشد. این ویژگی‏ها ممکن است دربرگیرنده هر کدام از دیگر ویژگی‏های native (بومی) Exchange server 2010 یا سرویس‏های third-party باشد که با Exchange 2010 کار می‏کنند.
  • تجهیزات و نیازمندی‏های service-level سیستم messaging و سرویس‏های مرتبطی که باید فراهم شود، چیست؟ شناسایی نیازمندی‏های service-level روی افزونگی (redundancy) سیستم، انواع موافقتنامه‏های سرویس مورد نیاز برای سخت‏افزار مورد استفاده و موافقتنامه‏های organization-level بین بخش‏های مختلف برای اطمینان از رسیدن به شرایط مدنظر تاثیر خواهد گذاشت.

تمام این موارد می‏تواند منجر به افزایش هزینه و عوارض گردد. اگر الزامات و اهداف به خوبی و وضوح تعریف شوند، خواهید توانست از این هزینه‏های بی‏مورد جلوگیری کرد و امید بیشتری به پروژه داشت.

  • الزامات کاربردی برای سیستم messaging چیست؟ در بیشتر موارد الزامات استراتژیک برای سیستم ایمیل کنونی خیلی با نسخه جدید تفاوت نخواهد داشت. بدون شک کاربران نیاز به ارسال ایمیل به دیگر کاربران سیستم messaging خواهند داشت همان‏طوری که در اینترنت این کار را می‏کنند. زمانی که الزامات کاربردی را تعریف می‏کنید بهترین زمان برای به تصویر کشیدن کارایی و قابلیت‏هایی است که ممکن است مورد نیاز باشند. چیزهایی مثل anti-spam، unified messaging یا حتی در مواردی که لازم است user خاصی قادر به چاپ یا forward نوع خاصی از ایمیل نباشد.

الزامات کاربردی در طراحی یک محیط تست، یک Plan آزمایشی و در نهایت در تولید deployment استفاده شود. برای حصول اطمینان از کامل بودن این نیازمندی‏ها می‏توانید از مشتریان، سهامداران و کاربران نهایی نظرسنجی یا با آنها صحبت کنید.


  • کدام مهارت‏ها و منابع IT برای سازمان، استراتژیک هستند؟ زمانی که تصمیم می‏گیرید که چه گروهی مسئول ارائه و عامل سرویس messaging است، لازم است که مهارت‏ها و اولویت‏ها نیز ارزیابی شوند. شاید پروژه‏های خاصی هستند که برای سازمانی بحرانی هستند و لازم است که توسط کارکنان داخلی انجام شود، در حالیکه سایر پروژه‏ها لازم باشد که برون‏سپاری شوند.

زمانی که نرم‏افزار (software) و خدمات (service) جدیدی به کار گرفته می‏شود، بدون شک تمام کارکنان به آموزش‏های اضافی نیاز خواهند داشت. اگر ویژگی یا چالش‏های جدیدی به کار گرفته شده است، حتی ممکن است که نیاز به آموزش‏های خاصی برای کارمندان باشد تا بفهمند که چگونه این ویژگی‏ها deliver می‏شود، چگونه کار می‏کنند و در محیط کسب و کار چگونه مدیریت می‏شوند. برای جلوگیری از مشکلات احتمالی باید تمام کارکنان هر چه زودتر آموزش‏های کامل را ببینند. به علاوه بکارگیری کارمندان IT در پروژه‏ها در حالیکه بار کاری آنها سبک نشده باشد، درست نیست.

در بعضی از موارد، پروژه‏ای ممکن است که به منابع بیشتر با مهارت‏های خاص نیاز داشته باشد. در خیلی از شرکت‏ها بخش IT حتی کارکنانی ندارد که به طور مرتب در بحث messaging به کار گرفته شوند. که در این صورت به منابع اضافی با مهارت‏های بالا نیاز است، اگر لازم باشد که پروژه در مدت کوتاهی به پایان برسد. در غیر این صورت باید به کارکنان فعلی IT زمان بیشتری بدهید تا در حد سرعت و مهارت‏هایشان کارهای محول شده را تمام کنند.

  • چه ابزارها (tools) و برنامه ‏های کاربردی third-party باید در طراحی موجود باشد؟ به عنوان بخشی ار نیازمندی‏های استراتژیک، تصمیم در مورد اینکه چه ابزارهای استراتژیک و applicationهایی لازم است که در solution مجتمع شوند، بسیار مهم است. اضافه کردن یک application در هسته پروژه می‏تواند سبب تغییرات در طراحی و ناسازگاری گردد. وقتی که روی یک پروژه‏ی بزرگ کار می‏کنید که شامل تغییرات زیادی است، از هرگونه کاری که سبب ایجاد تغییرات متعدد یک مرتبه شود، خودداری کنید. یک تغییر نیاز به تغییر دیگری دارد تا کامل شده و به صورت کاملا هماهنگ و موزون کار کند. قبل از شروع به حرکت باید تصمیم بگیرید که چگونه اندازه تغییرات را کنترل کنید زمانی که آن تغییر تنها روی upgradeهای اساسی و ضروری ( سرورها یا clientها) تاثیر خواهد داشت یا شامل سرویس‏ها و applicationهای جدید نیز خواهد شد.
  • چه تعداد user لازم است گنجانده شود و کجا باید واقع شوند ( قرار بگیرند)؟ تعیین تعداد و موقعیت userهایی که توسط پروژه messaging تاثیر می‏پذیرند به تعیین scope پروژه و scalability مورد نیاز سیستم messaging کمک خواهد کرد. آشنایی با تنظیمات شبکه و پهنای باند موجود برای هر یک از سایت‏ها ضروری است که در تعیین منابع در دسترس که برای هر موقعیت لازم است به ما کمک می‏کند.

در آخر مرحله Plan باید یک document تهیه شود که خلاصه اهداف کسب و کار و تکنولوژی و استراتژی برای شرکت در آن نوشته شده باشد. این سند مکتوب باید شامل توجیه کسب و کار، scope (محدوه) پروژه و معیار موفقیت پروژه باشد، این document ممکن است شامل یک چشم‏انداز کلی از scope پروژه باشد که روی راه‏اندازی پروژه تمرکز دارد. این اطلاعات باید در نهایت توسط مدیران فنی و کسب وکار که مسئول ارائه راه‏حل هستند، امضا شود.

ارائه پروژه یا Delivery

بعد از تعیین و تعریف اهداف استراتژی تکنولوژی کسب و کار برای ایجاد چشم‏انداز اهداف پروژه، delivery (ارائه) پروژه می‏تواند آغاز گردد. برای این مرحله روش‏های متعددی قابل استفاده است که ممکن است برای هر کسب و کار متفاوت باشد. مهم نیست که از چه روشی استفاده می‏کنید، تلاشی که شما در این مرحله می‏کنید اجازه می‏دهد که در آینده مراحل ساده‏تر و روان‏تری داشته باشید. به مثال خرید خودرو برمی‏گردیم.

فاز deliver همان بخشی است که شما اتومبیلی را شناسایی می‏کنید که نیازهای شما را برآورده می‏کند، رانندگی با ماشین را امتحان می‏کنید و خودرو نهایی خود را انتخاب می‏کنید، و در آخر کارهای تکمیل مدارک برای خرید خودرو را انجام می‏دهید.به همین ترتیب در فاز deliver، محصولات و روش‏ها انتخاب شده‏اند و سپس برای رسیدن به آنچه در مرحله Plan تعیین شده بود، اجرا می‏شوند. MOF در این فاز شامل 5 مرحله اصلی است ، Envision (پیش‏بینی)، Project Planning (برنامه‏ ریزی پروژه)، Build (ساخت)، Stabilize (ثبات) و Deploy (استقرار). این مراحل اصلی در فاز Deliver گنجانده شده ‏اند که برای اطمینان از شفافیت این روند، این قدم‏ها به مراحل بیشتری تقسیم می‏شوند:

  • Envision (پیش‏بینی)
    1. قدم اول (step 1) : Envision : شناسایی کسب و کار و نیازمندی‏های فنی.
    2. قدم دوم (step 2) : Assess (ارزیابی)
    3. قدم سوم (step 3) : ارزیابی راه‏حل (Solution) جدید و طرح‏های بالقوه.
    4. قدم چهارم (step 4) : ایجاد یک چرکنویس از فرضیات موجود برای اثبات آنها.
    5. قدم پنجم (step 5) : ایجاد یک طرح.
    6. قدم ششم (step 6) : توسعه deployment و به دست آوردن buy off
    7. قدم هفتم (step 7) : پیاده‏سازی pilot. شروع آزمایشی pilot، تنظیم (adjust) کردن Plan و استقرار کامل.
    8. قدم هشتم (step 8) : Deploy
    9. قدم نهم (step 9) : بررسی پس از اجرا

Envision (پیش‏بینی) : قدم اول

بخش اول از فاز Deliver شناسایی اهداف تکنیکی و کسب و کار تعریف شده در فاز Plan است که روی پروژه messaging اعمال (apply) می‏شود که برای تعیین چشم‏اندازی از پروژه و دامنه (scope) آن است. تکمیل این مرحله با موفقیت از آنچه به نظر می‏رسد، مشکل‏تر است. انجام Legworkها در ابتدای کار نه تنها به شما این اطمینان را می‏دهد که به اهداف و نیازمندی‏های اکنون و آینده کسب و کار خواهید رسید

بلکه به شما این پشتیبانی را می‏دهد که نیازهایی که برای تکمیل پروژه به آنها نیاز دارید از طریق منابع مناسب فراهم خواهد شد. اساسا این دیدگاه باید با اهداف کوتاه‏مدت و بلندمدت کسب و کار با توجه به نیازمندی‏ها و تغییرات کسب و کار هماهنگ باشد. از آنجایی که کسب و کارها با هم متفاوتند، هیچ پاسخی از best practice به شما نخواهد گفت که چگونه این قدم (step) را کامل کنید.

بنابراین در اغلب موارد بهترین Plan مطرح کردن لیستی از سوالات فوق الذکر و تلاش برای یافتن پاسخ آنهاست. البته نه به این معنا که به تمام سوالات پاسخ داده شود بلکه سوالاتی که با کسب و کار شما مرتبط است را انتخاب کرده و به آنها پاسخگو باشید. آنچه که مهم است این است که بحث و گفتگو انجام شده و به دنبال جمع‏آوری نیازمندی‏ها برویم. در طول این فاز شما باید توضیح دهید که این دیدگاه چگونه روی تمام سطوح وظایف کاربران در سازمان تاثیر خواهد گذاشت.

این دیدگاه در ایجاد طراحی و Plan بازاریابی داخلی استفاده خواهد شد. Vision statement به طور خلاصه اهداف پروژه است که به صورت یک شعار جذاب یا چند پاراگراف یا لیستی از اصول ارائه می‏شود و به تمرکز روی پروژه کمک می‏کند. اغلب اوقات Vision statement در مرحله Plan به تصویب می‏رسد و برای درایو (راه‏اندازی) بقیه پروژه به کار می‏رود و یک چشم‏انداز کلی برای پروژه ایجاد می‏کند. برای ایجاد یک چشم‏انداز (Vision) برای یک پروژه، یک روش مفید و کارآمد رجوع به لیست استاندارد مواردی است IT سازمان به طور معمول بر روی بهبود آنها، تمرکز داشته است مانند:

توافقنامه ها و تعهدات سازمانی SLA یا Service Level Agreement

  1. آیا agreement (توافق)‏های فعلی کافیست؟
  2. آیا agreementهای کنونی قابل حصول هستند؟
  3. چه سخت ‏افزار و نرم‏ افزار جدیدی برای توسعه سیستم‏ها مجاز هستند؟
  • Operational costs (هزینه ‏های عملیاتی) : بسیاری از مطالعات نشان داده است که اکثریت هزینه‏های عملیاتی مربوط به هزینه‏های سیستم هاست. این هزینه‏ها اغلب شامل نیروی انسانی، سیستم‏های Power و cooling و نگهداری (maintaining) سخت‏افزار و نرم‏افزار است.
  • Network costs (هزینه‏ های شبکه) : موقعیت و محل سرورها و clientها و مقدار، اندازه و تعداد پیام‏هایی که بین سیستم‏ها جریان دارد روی طراحی و هزینه‏های شبکه تاثیر خواهد گذاشت.
  • Backup and restore cost and performance improvements (هزینه‏های پشتیبان‏گیری، بازیابی و بهبود و توسعه کارایی) : تکنیک‌ها و ویژگی‌های جدیدی که در دسترس هستند ممکن است مقدار داده مورد نیاز جهت backup را کاهش دهند. Exchange server 2010 درهایی به سوی تغییرات جامع و کلی در فلسفه و فرایندهای backup باز کرده است. این گزینه‌ها باید مورد ارزیابی قرار بگیرند.
  • Exchange enhancement که امکان mailboxهای بزرگ‏تر را فراهم می‌کند : یکی از عمده‌ترین پیشرفت‌های Exchange 2010 قابلیت توسعه و ارائه mailboxهای بزرگ‌تر است که کارایی و تاثیرگذاری خیلی بیشتری نسبت به نسخه‌های قبلی Exchange دارد.
  • کاهش هزینه‌های Licensing : بخشی از هزینه‌های اولیه هر message solution هزینه license نرم‌افزارهاست. یکی از پیچیدگی‌های این کار این است که شما تعداد و نوع license مورد نیاز جهت تکمیل پروژه را به درستی برآورد کنید.
  • Return on investment (ROI (بازگشت سرمایه و ملاحظات بودجه) : در اکثر پروژه‌ها ملاحظات بودجه نیاز به بررسی گسترده دارد. با وجود هزینه‌های اضافه و تصویب بودجه برای آنها بازگشت این هزینه‌ها نیز یکی از چشم‌اندازهای مهم پروژه‌های کاری می‌باشد.
  • شناسایی و رعایت الزامات : گاهی اوقات قوانین ملزم می‌کنند دسترسی به داده باید ردیابی و ثبت (track and log) شود. گواهینامه هایی مثل PCI DSS نیز نیاز دارند که eventها و access logها بایگانی شوند و در دوره های معینی از زمان برای بررسی در دسترس باشند.
  • نیازهای message archiving ( بایگانی پیام) : نگهداری پیام خیلی سریع به یک نیاز دنیای کسب و کار امروز تبدیل شد. این مسئله تصمیم گیرندگان IT سازمان را در موقعیت و شرایطی قرار می دهد تا فضای آرشیو را با توجه به ایمیل های مورد استفاده تعیین و بهینه کنند. در برخی از سازمان ها بخش حقوقی اداری به جای وضع و استفاده از بعضی از قوانین و مقررات تقاضای ثبت و نگهداری پیام ها را به بخش IT می دهند در این وضعیت تعیین دقیق قابلیت های مورد نیاز برای آرشیو کردن به شما در تشخیص اینکه منابع و ویژگی های حال حاضر کافی هستند یا اینکه به محصولات اضافه تری نیاز دارید، کمک زایدی خواهند کرد.
  • قابلیت های آنتی ویروس و آنتی اسپم : گرچه قابلیت ضداسپم به صورت built in در Exchange server قرار دارد و نسبت به نسخه های گذشته به طور چشمگیری بهبود یافته است، اما خنثی کردن اسپم پیچیده می تواند بسیار دشوار باشد. در زمینه آنتی ویروس تعداد زیادی از محصولات آنتی ویروس مناسب با نیازهای کسب و کار شما وجود دارد.
  • نیازمندی های امنیتی : این نیازمندی ها که با یک طرح خوب برای تنظیمات مناسب امنیت شبکه، نرم افزار آنتی ویروس، استفاده از updateهای نرم افزار شروع می شود و به موارد امنیتی اضافه تری در طراحی ختم می شود. این امر می تواند سبب تقسیم وظایف کاری بین کارمندان IT شود.
  • یکپارچه سازی نرم افزار با ساختار موجود : آیا برنامه های مهم با سیستم messaging که برای کسب و کار بسیار حیانی است، یکپارچه شده اند؟ این برنامه ها باید با سیستم messaging جدید کاملا تست شده و از عملکرد صحیح آنها با ساختار messaging اطمینان حاصل شود و در صورت نیاز از third-partyها و یا updateهای جدیدی استفاده شود.
  • برنامه ریزی عملکرد : تعیین سخت افزار مناسب و پارامترهای مرود نیاز برای عملکرد برنامه جهت اطمینان از عملکرد رضایت بخش برای کاربران نهایی بسیار مهم است. از آنجایی که محیط های متفاوتی وجود دارد، اطلاعات جمع آوری شده از موارد استفاده واقعی محیط پیام رسان کنونی می تواند ما را به سمت ورودی های دقیق برای ایجاد یک Plan عملکرد هدایت کند.
  • برنامه ریزی ظرفیت و مدیریت : پس از اینکه سیستم messaging مستقر شد چرخه طبیعی کسب و کار به سمت تغییرات در محیط کاری حرکت خواهد کرد. این تغییرات می تواند به طور مثال در تعداد یا سایز mailboxها باشد. همان طور که الگوهای استفاده تغییر می کند تنظیمات و پیکربندی سیستم messaging هم باید تغییر کند. برای داشتن بهترین Plan باید معیارها و پارامترهای مهم به صورت دوره ای جمع آوری شوند تا مسیر این تغییرات مشخص گردد. پس از این اقدامات باید برای این تغییرات تنظیمات لازم انجام شود. مثلا اگر کسب و کاری به صورت فصلی نیاز به افزایش ظرفیت دارد Plan باید شامل اضافه کردن سرورهای مازاد برای راه اندازی و بارگذاری های فصلی باشد.

Assess (ارزیابی) : قدم دوم

برای اینکه بدانید به کجا می خواهید بروید باید بدانید که کجا هستید. قبل از ایجاد و اجرای طرح لازم است که اطلاعاتی را جمع آوری و مستندسازی کنید. از جمله اینکه هر عنصری در حال حاضر مستقر و deploy شده، چگونه پیکربندی شده و چگونه استفاده می شود؟ در طول ماه ها و سال ها سیستم messaging با توجه به تغییرات دچار تکامل می شود.

Designهای یک پروژه به صورت اسناد در طول پیاده سازی یا زمانی که تغییرات اساسی رخ می دهد ایجاد و نگهداری می شوند. مطالعه و بررسی دقیق این اسناد قبل از شروع به طراحی پروژه جدید messaging بسیار اهمیت دارد. یک history log مربوط به مدیریت تنظیمات و تغییرات باید اطلاعات مربوط به سیستم و سرور messaging، تنظیمات آنتی اسپم و تنظیمات نرم افزارهای third-party را در خود جمع آوری کرده باشد. استفاده از آن کمک بسیاری به پیاده سازی های سرویس های messaging جدید خواهد کرد.

شناسایی چگونه، چه چیزی، چرا، کجا و کی در ابتدای پروسه این اطمینان را می دهد که طراجی نهایی کاربرپسند و راحت خواهد بود. پیدا کردن برنامه های کاربردی و نیازمندی های جدید در طول فاز deploy سبب تاخیر و افزایش هزینه های ناخواسته در پروژه خواهد شد.

مراقبت باید ادامه یابد تا عینا مشاهده گردد که سیستم به خوبی در حال کار کردن است و نیازهای کاربران را به خوبی برطرف می کند. از آنجایی که این مسائل می توانند بار علاقه مندی کاربران را نشان دهند این اطلاعات باید جمع آوری و به دقت شمارش شوند. حتی اگر بازخورد کاربران منفی باشد هنوز هم مهم هستند چرا که ما را در جهت آموزش کاربران یا تغییر تنظیمات خودمان هدایت می کنند. همچنین باید تمامی applicationهایی که وابسته به سیستم ایمیل موجود هستند را شناسایی کنید.

فازهای اجرایی

در ادامه بحث Assest از مقاله قبل در این مقاله تمامی قدم های باقی مانده برای برسی کامل و دقیق اجرای استراتژیک یک پروژه و فاز Plan، Deliver و Operate که یکی از اصلی ترین پیش نیازهای پروژه های بزرگ شبکه ای است را مطرح کرده و برسی های مدیریتی و طراحی را در آن به سر انجام می رسانیم تا از مقاله بعدی به صورت دقیق به فاز اجرا و تنطیمات سرور Exchange بپردازیم و به صورت کاربردی تر و عملیاتی تر به برسی این سرور پر کاربرد مشغول شویم !! بعد از شناسایی نرم افزار های وابسته به Mail نوبت می رسد به مراحل بعد که شامل این موارد می شود:

  • شناسایی و اولویت بندی برنامه های کاربردی در حال استفاده به ترتیب اهمیت آنها برای قابلیت های کسب و کار.

خیلی از شرکت های تجاری تعدادی Application دارند که با سیستم های Messaging آنها ادغام شده است این برنامه ها ممکن است برای مثال یک سیستم مانیتورینگ باشد که email notification را می فرستد یا نرم افزاری که ارتباط با مشتری را مدیریت می کند، باشد مثل CRM.

  • شناسایی clientهایی که در حال دسترسی به ایمیل هاهستند.

برای مثال چه نسخه هایی از outlook مستقر شده است؟ آیا clientهای دیگری غیر از مایکروسافت مثلا apple macintosh یا linux based وجود دارد؟ clientها pop3 یا IMAP4 هستند؟ چه deviceهای mobile در شبکه استفاده شده است؟ آیا نیازی به support کردن clientهای اضافی برای بهبود کارایی هست؟

  • مستند سازی موافقتنامه های service level و organization level

شناسایی موافقتنامه هایی که در حال حاضر در حال اجرا هستند و تعیین چگونگی اجرای آنها.

  • تعیین فهرستی از سخت افزارهایی که در حال حاضر در حال استفاده هستند.

و تعیین اینکه آیا هر یک از آنها با یک update قابل استفاده هستند یا خیر؟مستند سازی ساختار طراحی شبکه (Network Infrastructure Design)

هرچه تنظیمات شبکه و Utilizationکه می توانید را جمع آوری کنید. این اطلاعات در فهمیدن مسیری که ترافیک کلاینت ها و پیام های ایمیل طی خواهند کرد و اینکه پهنای باند در دسترس برای راه اندازی ترافیک فعلی و ترافیک آینده چقدر خواهد بود به شما کمک خواهد کرد.

  • موقعیت فعلی قرارگیری سرورهای Messaging، تعداد و سایز mailboxهای local و کپی public folder، تعداد و متوسط سایز پیام های ارسالی و دریافتی را نیز شناسایی کنید.
  • تنظیمات مربوط به AD DS را شناسایی کنید.

Exchange Server شدیدا به اطلاعات AD DS در مورد Domain و forest functional level و تنظیمات site و link وابسته است. زمانی که تنظیمات کنونی را یادداشت می کنید تمام موانع را نیز یادداشت کنید تا جهت بهتر شدن Exchange server آنها را تغییر دهید.

** تمامی اسناد مربوط به تنظیمات Messaging را بروز رسانی کنید تا مطمئن شوید که تمام داده ی مورد نیاز برای تکمیل plan پروژه را در اختیار دارید. *

** تمامی افراد موثر در مدیریت Exchange و تمام سرویس های وابسته را شناسایی کنید. *

مدیریت Exchange بخش های مختلفی را تحت تاثیر قرار می دهد که برای مثال در یک سازمان بزرگ می تواند شامل AD DS، سرویس های امنیتی، storageها، سرور و شبکه شود. اگر افراد یا بخش های متفاوتی این سرویس ها را کنترل می کنند مطمئن شوید که تمام آنها و نیازمندی هایشان را شناسایی کرده اید.

  • یک مسیر یا طرح اجرایی برای مواقع غیر مترقبه در نظر بگیرید.

اغلب مشکلات در طول استقرار نیاز به یک تصمیم یا راهنمای اجرایی دارند تا بتوان بر آن موانع غلبه کرد.

بعد از اینکه اطلاعات شناسایی و جمع آوری شد یک چشم انداز (vision) از مجموعه اهداف و دامنه (scope) برای پروژه می توان تولید کرد. نیازمندی های کسب و کار می تواند با سیستم messaging فعلی مقایسه شود تا هرگونه کمبود شناسایی گردد.

قدم سوم (step 3) : ارزیابی راه حل

با درک چشم انداز پروژه و آنچه در حال حاضر مستقر است، می توانید بررسی و ارزیابی محصولات، تنظیمات و سرویس هایی که برای رسیدن به پروژه نیاز دارید بپردازید. این مرحله شامل ارزیابی ویژگی های جدید Exchange 2010 است و اینکه تشخیص بدهید کدامیک متناسب با نیاز شماست. همچنین زمان این رسیده است که تعیین کنید چه third-partyهایی لازم است و چه تنظیماتی باید تغییر کند تا استقرار Exchange جدید در محیط کاری نیازهای کسب و کار را برطرف کند. ارزیابی شامل یادگیری optionهای در دسترس است که از طریق شرکت در سمینارها، مطالعه اسناد و ملاقات با فروشندگان محقق می گردد. ارزیابی، استراتژی های مهاجرت را ممکن می سازد.

اگر مهاجرت از Exchange 2003 یا 2007 باشد مراحل خاص و نیازمندی هایی لازم است تا پروژه با موفقیت انجام شود. اما اگر مهاجرت کلا از یک محصول messaging دیگر باشد کارهای اضافه ای نیز باید برای آزمایش optionهای مهاجرت صورت گیرد تا هرگونه محدودیت یا امکانات جدید شناسایی شود و برای استفاده از ابزارهای این مهاجرت و تکنیک های جدیدش باید آموزش های لازم صورت گیرد. خیلی از پروژه ها به علت اینکه زمان کافی برای درک گزینه ها و تاکتیک های استقرار، تنظیمات، مهاجرت و عملکرد سیستم messaging صرف نمی شود با شکست مواجه می شوند.

از آنجایی که گنجاندن تمام بخش های مختلف در ارزیابی اهمیت دارد نباید تنها به بحث نرم افزار اکتفا کرد .

بلکه باید تمام مسایل مربوط به سخت افزار سیستم ، تنظیمات شبکه ،سخت افزار ذخیره سازی (Storage) نرم افزار و سرویس آنتی ویروس ، سیستم پیام رسانی یکپارچه (unified messaging) ، تنظیمات mobile ، ابزارهای مهاجرت و نرم افزار بایگانی را نیز مورد بررسی قرار داد و از عملکرد هر یک از آنها با هم اطمینان حاصل کرد. برای اینکه مطمئن شوید این ویژگی ها در محیط کاری شما همانطور که انتظار داشتید کار می کنند نیاز به ایجاد یک proof-of-concept برای استقرار خود دارید. این کار در یک آزمایشگاه جداگانه انجام می پذیرد. جایی که تست ویژگیهای بدون اینکه روی سیستم های تولید تاثیر داشته باشند، انجام می شود. برای انجام مناسب تست در محیط آزمایشگاه باید جزئیات مربوط به محیط واقعی و مربوط به محصول را کاملا شبیه سازی کرد.

قدم چهارم Step 4): Proof of concept )

به طور سنتی فرضیات در دو فاز می تواند انجام شود .برخی از افراد معتقد هستند که باید بعد از اتمام طراحی فرضیات را اثبات کرد و بعضی دیگر معتقدند که باید ابتدا هر مرحله را تست و اثبات و در آخر طراحی نهایی را پیاده سازی و تست نمود که این کار در یک محیط کاملا آزمایشگاهی و جداگانه انجام می شود.دراین زمان تمام سوالات و مسائل تست می شوند تا ثابت کنند که نه تنها در مفهوم که در واقعیت نیز همان طور کار می کنند. تست و آزمایش باید شامل همه فعالیت های انجام شده توسط کاربران و مدیران باشد. این روش اجازه می دهد تا طیف وسیعی از قابلیت ها مورد آزمایش قرار بگیرند.

تست بارگزاری باید در یک مقیاس کوچک انجام شود تا سخت افزار مورد نیاز در طول اجرای تولید ارزیابی و تعیین گردد. مستندسازی در این آزمایش ها این اطمینان را می دهد که نتایج مورد نظر به دست خواهد آمد. البته پیاده سازی که نمونه ساده از تولیدات شما در آزمایشگاه کافیست. در این مورد کاملا مراقب طراحی محیط تست باشید و با تست ویژگی هایی که برای سازمان شما حساس هستند شبیه سازی را آغاز کنید. سناریوهای تست مهاجرت به محیط کاری شما مربوط هستند اگرچه ممکن است documentهای مربوط به مهاجرت ساده به نظر برسند اما بایستی با دقت و ریزبینی تمام بررسی و پس از اطمینان از عملکرد صحیح آنها انجام شوند. مرحله Proof of Concept در زیر آمده است:

1-Prepare

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

2-Deploy Proof Of Concept

پیاده سازی یک محیط تست ایزوله که بسیار زیاد و در حد امکان شبیه محیط کاری مورد نظر محصول است، شرایط را برای کامل شدن آزمون فراهم می کند.

آزمایش در این مرحله باید شامل حالات بالقوه مهاجرت نیز باشد.

3-Test

سناریو آزمون را اجرا کرده و نتایج حاصله را یادداشت کنید. مطمئن شوید که تمامی تغییرات در سناریوی آزمون را یادداشت کرده اید تا ویژگی های جدید یا آنهایی که تغییر کرده اند فراموش نشوند.

4-Review Test Results

بعد از کامل شدن آزمون مسائل و تغییرات بالقوه باید بررسی شوند، دلایل هر نتیجه غیر منظره ای باید ثبت شوند. به عنوان مثال آزمون شکست می خورد به این علت که یک ویژگی یا کارایی طبق انتظار کار نکرده است یا محدودیت هایی برای درست کار کردن آن به وجود آمده است. این بررسی باید تمامی مسئله های بحرانی را دسته بندی کند و سپس هر مسئله بحرانی باید اصلاح و بر اساس این تغییرات طراحی نهایی به دست آید.

قدم پنجم Step 5) : Create A Design)

این مرحله ای است که شما در آن تمامی بخشها را کنار اطلاعاتی که جمع آوری کرده اید قرار می دهید تا طراحی ایجاد کنید که برای توسعه فرآیند ها مراحل مرتبط مورد استفاده قرار خواهد گرفت. اگر چه ممکن است که این طرح پس از به کار گیری توسط کاربران و با توجه به Feedback آنها بارها و بارها تغییر کرده تا یک طرح رضایت بخش تهیه شود

طراحی یک Solution جدید نیازمند ایجاد یک Plan دقیق برای چگونگی تنظیمات و نصب Exchange Server (EXS) 2010 -2013 خواهد بود

برای مثال انواع مختلف کاربران ، نرم افزار های مورد نیاز ، چگونگی اتصال و تنظیمات شبکه باید شرح و توضیح داده شود

تمامی این المان ها باید با Scope و Vision استقرار پروژه همراستا باشد

مراحل اصلی گام create a Design شامل این موارد است :

1-Define Client Standards:

بسیاری از سازما ن ها Upgrade ویا Refresh کردن تنظیمات Client ها را انتخاب می کنند .یک تعریف استاندارد برای پشتیبانی باید شامل تنظیمات سیستم عامل ،تنظیمات آنتی ویروس و ورژن Microsoft outlook باشد.برای کاربران نرم افزار OWA ممکن است استاندارد ها شامل تنظیمات ، پیکربندی و ورژن مرورگر (Browser) آنها نیز باشد.هماهنگی Upgrade های Client ها در طول مدت فاز استقرار (Deployment) ممکن است منابع اضافی نیاز داشته باشد. اگر جه این تغییرات بای کاربران نهایی نتایج مطلوبی خواهد داشت و به آنها اجازه می دهد که از تمام قابلیت های جدید استفاده کنند.

2-Define network and security design:

Plan استقرار exchange لازم است که شامل 2 بخش اصلی امنیت و شبکه باشد (Security and Network )

امنیت باید به عنوان یک بخش حیاتی از ارتباطات کسب و کار در نظر گرفته شود.Option های امنیتی می تواند شامل رمزنگاری پیام در سطح Transport ،فایروال، تشخیص نفوذ و پیشگیری از آن ،Logging و غیره باشد

3-Define antivirus and anti spam design:

در سال های اخیر Email برای مجرمان تبدیل به یک ابزار حمله برای بسیاری از ویروس، اسپم ها و طرح های phishing شده است که برای آنها بسیار سودآور می باشد. طراحی آنتی ویروس و آنتی اسپم شامل محصولاتی است که مورد استفاده قرار خواهند گرفت، جایی که این محصولات مستقر می شوند و اینکه آیا این سرویس ها برون سپاری خواهند شد و یا اینکه به صورت داخلی استفاده می شوند.

4-Define Application Compatibility and Integration:

Exchange 2010 پایه و اساس messaging collaboration در شرکت هاست بنابراین خیلی از کسب و کارها، پروسه ها و محصولات با Exchange ادغام شده و توسط آن توسعه داده می شوند. برای مثال می توان از برنامه های کاربردی line of business، محصولات unified communication و برنامه های Workflowمی شود.

به علت اینکه اینها تغییرات قابل توجهی در چگونگی کار کرد exchange server دارند، در طول مدت تست کردن در مرحله Proof of Concept و کارکردن با فروشندگان این مسئله خیلی اهمیت دارد که مطمئن باشیم که applicationها بهد از مهاجرت کار خواهد کرد.

5-Define Infrustructure Changes:

در بسیاری از موارد برای بهینه سازی شبکه و تنظیمات Storage ها برای استقرار exchange لازم است تا تغییراتی ایجاد شود.اطمینان از اینکه Admin ها ی Network و Storage نیازمندی های ویژگی های جدید exchange را درک کرده اند این نتیجه را در بر خواهد داشت که این گروه قادرند تمامی نگرانی ها را مرتفع کرده و هر تغییر مورد نیاز برای مهاجرت را شرح داده و توصیف کنند.

6-Define and Remidiate Risks:

زمانی که تغییرات در حال اجرا هستند ، مخصوصا در سیستم های مهم همیشه نوعی خطر وجود دارد . برای مثال زمانی که Mail box ها در حال جابجایی هستند،زمانی که مهندسان در حال کامل کردن یک Task برای اولین بار هستند و زمانی که Restore ها مورد تست و بازبینی قرار نگیرند ، همه و همه به نوعی ریسک محسوب می شوند.

تکمیل کارهای زیاد در زمان کم باعث عدم تایید تست و حصول نتیجه خواهد شد .

7-Develop Communication Plan:

ارتباط بین اعضای تیم، سرمایه گذاران و کاربران نهایی برای اجرای یک پروژه ضروریست. اگر افراد کلیدی اطلاعاتی که برای آماده شدن و ارتباط با استقرار پروژه لازم است را در اختیار نداشته باشند به یکی از این دو مشکل برمی خورند: یا تکمیل بخشی از Plan که به طور فردی مربوط به آنهاست با شکست مواجه می شود و یا دچار ناامیدی می شوند. برخی از این مسائل را می توان به پیروی از شیوه های good change management کاهش داد. همچنین ارتباط با سایر گروه هایی که ممکن است با این تغییرات تحت تاثیر قرار گرفته باشند باید تضمین شود. برای مثال تیم شبکه ممکن است برای جایگزینی زیرساخت های فایروال ها برنامه ریزی کرده باشند که تبعا به زمان بیشتری برای configure کردن سرویس ها نیاز خواهند داشت. ارتباط good intra group می تواند این تغییرات برنامه ریزی شده را خیلی زود شناسایی کند تا این اطمینان حاصل شود که schedule تست شده با کمترین ریسک کار خواهد کرد.

8-Develop marketing and training Plan:

برای دستیابی به ویژگی ها و کارایی های جدید سیستم messaging، نحوه به بازار ارائه کردن محصول برای کاربران نهایی به بازار بسیار مهم است. این بازاریابی باید از طریق آموزش ادامه یابد. این بازاریابی شامل آموزش Adminها و به همان نسبت آموزش به end userهاست.

9-Define Detailed Architecture:

ایجاد یک معماری برای سیستم پیام رسانی نیازمند ترکیب و هماهنگی بین تکنولوژی ها و رشته های متفاوتی است. برای موفقیت باید تمام بخش ها زمانی که پروژه کامل است در کنار هم کار کنند . طراحی معماری باید شامل تمام این componentها باشد تا مطمئن شویم که پروژه موفق خواهد شد.

10-Define Migration Process:

طراحی باید شامل روند مهاجرت باشد که در آن چگونگی اجرای طرح و چگونگی مهاجرت کاربران به طراحی جدید شرح داده خواهد شد. اغلب این بخش را نادیده می گیرند و می گذارند تا در طول پروسه ی استقرار شکل گرفته و تعریف شود اما بهترین شیوه برای تعریف روند مهاجرت در این زمان است. چون این مسئله به طور مستقیم روی واسط های کاربران نهایی با سیستم messaging تاثیرگذار است.

پروسه ی مهاجرت باید به طور کامل تست شده و در هر مرحله به صورت کاملا مفصل ثبت و مستندسازی شود. در بعضی از موارد end userها تاثیراتی می پذیرند مثل اینکه لازم باشد کلاینت ها به طور دستی دوباره پیکربندی شوند و یا داده های مربوط به مهاجرت به طور دستی تنظیم شوند.

قدم ششم Step 6) : Develop a Deployment)

Plan توسعه استقرار (DAD) نتیجه تمام فازهای قبلی از جمله Design، Proof of Concept، Create a Project Plan است. بنابراین کار در اینجا کامل شده است. ایجاد یک plan تاثیرگذار به تبحر تکنیکی و فنی فوق العاده ای نیاز دارد. به علاوه به مدیریت پروژه و مهاجرت های کسب و کار هم نیاز دارد. تغییراتی که برای رفتن از Solution فعلی به Solution جدید نیاز است، و سرمایه گذاران و ذینفعان و منابع پروژه باید به خوبی شناسایی شوند. مراحل اصلی این فاز در زیر بیان شده است:

1- Creating Design Milestones:

استفاده از طراحی ایجاد شده منجر به توسعه نقاط عطف پروژه می شود که خود به گام های جداگانه ای به نام Pilot تقسیم می شود. هر کدام از این گام ها باید شامل منابع تخمینی مورد نیاز برای کامل شدن آنها باشد.

2-Obtain Project Resources:

یک سیستم messaging در داخل سازمان افراد زیاد و مجموعه ای از مهارت ها را نیاز دارد. برای مثال در پروژه هایی که پیاده سازی کوچکی دارند ممکن است یک نفر role متعددی را داشته باشد در حالی که در یک پروژه بزرگ ممکن است چندین نفر به یک role اختصاص داده شوند. مطمئن شوید که با این منابع خیلی زود تعامل برقرار کنید و یک schedule زمانی دقیق برنامه ریزی کنید تا پروژه های دیگری با پروژه استقرار Exchange 2010 تداخل یا همزمانی نداشته باشد.

3-Define Education and Training Requirements and Communication Plan:

کاربران باید برای استفاده از ویژگی های جدید سیستم messaging آموزش های لازم را ببینند. آماده سازی کافی و لازم کاربران برای آشنایی با تغییرات یکی از مهم ترین مسائلی است که اغلب نادیده گرفته می شود. با اینکه این قدم مهم سبب حصول اطمینان از رضایت کاربران نهایی از پروژه خواهد بود. ارتباطاتی که لازم است تعریف و تعیین شود شامل ارسال notificationها به کاربران نهایی است که تحت تاثیر قرار گرفته اند. همچنین Plan شامل این است که چه زمانی اعضای پروژه از وضعیت پروژه مطلع شوند.

4-Obtain Executive Buy-in:

Solution و طرح مقدماتی را برای اسپانسرهای مالی و اجرایی ارائه کنید و بازخورد آنها را بررسی کنید. هر تغییر و تنظیمی که بر اساس بازخورد آنها لازم است، اعمال کنید و نهایتا برای تطمیع حامیان اقدام کرده و حرکات لازم برای ارائه پروژه را انجام دهید. این نکته حیاتی را فراموش نکنید که بدون حمایت اسپانسرها بعید است که شما در پروژه خود موفق شوید.

همان طور که قبلا هم گفته شد به دست آوردن تعامل درست بین منابع پروژه بسیار ضروری و مهم است. با دقت برنامه ریزی کنید و تمامی گروه های لازم برای انجام کار را در نظر بگیرید. جدول 2-4 لیست برخی از اعضای گروه که شما ممکن است برای استقرار پروژه Exchange خود به آنها نیاز داشته باشید را فراهم کرده است.

ّFigure 2-4

Table 2-4 :

افرادی هستند که به طور مستقیم در پروژه حضور ندارند اما لازم است تا گزارش های پروژه و پیشرفت کار به آنها گزارش داده شود، برای مثال حامیان اجرایی و یا مدیر ارشد اجرایی (مدیر عامل)

قدم هفتم Step 7) : Implement a Pilot)

اجرای Pilot بعد از اینکه یک Design قابل اجرا و مصوب اجرا گردید و یک Plan برای پروژه طراحی و در محیط آزمایشی امتحان شد، شروع می شود. Pilot در واقع مرحله ای است که در آن پیکربندی اولیه کامل شده و یک زیرمجموعه از کاربران جهت بررسی عملکرد و روند مهاجرت به شرایط جدید مهاجرت داده می شوند. این پروسه قابلیت و توانایی تست و تنظیم Plan پروژه را برای ما مهیا می کند و باعث کاهش مواجهه با مشکلات غیر منتظره در طول استقرار واقعی می انجامد. به علاوه فرصتی فراهم می کند تا یک feedback از کاربران در مورد چگونگی ویژگی های خاص و کارایی استقرار جدید به دست ما برسد.

استقرار Pilot باید برای اطمینان از اینکه تمام برنامه ریزی ها (plan) و طراحی ها (design) درست کار می کند، استفاده گردد. همچنین فرصتی فراهم می شود تا در فاز Plan به گونه ای تغییرات لازم ایجاد گردد که در اجرای اصلی پروژه به راحت ترین شکل ممکن Plan به سرانجام برسد. بهترین کار این است که پس از اجرای Pilot اول و اعمال تغییرات لازم یک Pilot دیگر اجرا کنید این کار احتمال پیدا شدن مشکلات جدید را کاهش داده و یک شانس اضافه برای یافتن problem های باقیمانده به شما می دهد. همچنین بهتر است که Pilot را به فازهای مختلف تقسیم کنیم تا هر فاز و component در حال تست را به خوبی شناسایی و بر روی آن تمرکز کنیم. برای مثال Pilot مربوط به بخش Edge Transporter به عنوان یک فاز در نظر گرفته می شود. در طول اجرای Pilot، زمان پیاده سازی واقعی تخمین زده می شود. قدم های اصلی Pilot به شرح زیر است:

1-Pilot Planning:

Pilot در واقع ماکت استقرار است. در نتیجه برای دستیابی و اجرای آن نیاز به سعی و تلاشی مشابه deployment دارد. در طول آماده سازی Plan باید بخش های طراحی که باید تست شوند تعیین و نعریف و در بخش های جداگانه ای مجزا شود تا بتواند بدون تداخل با سیستم User Messaging تست شوند. در این مرحله دپارتمان و کارمندان کلیدی که باید در این Pilot گنجانده شوند نیز شناسایی می شوند.

2-Implementing the Core Exchange Infrastructure:

پیاده سازی Pilot نیاز به بررسی وضعیت Core سرور دارد که می توان گفت شامل تست زیرساخت برای راه اندازی اولیه می باشد.

3-Pilot Deployment:

زمانی که تغییرات و کنترل های مناسب و لازم انجام شد deployment می تواند آغاز شود. در طول استقرار اگر مسئولین هر قدم از مراحل یادداشت برداری کنند بسیار مفید خواهد بود. مخصوصا اگر مرحله ها با آنچه قبلا مستند سازی شده فرق داشته باشد. در واقع Pilot آخرین زمان مناسب برای ایجاد تغییرات جزئی لازم و مورد نیاز و همچنین مستندسازی نهایی است.

4-Evaluate the Pilot Process:

تیم Pilot باید با تلاش و پشتکار زیاد پیشرفت های Pilot را زیر نظر گرفته و آنها را ارزیابی کنند. و از این طریق تمامی مسائل پیش آمده را شناسایی و حل کنند. برای استخراج نظر و بازخورد کاربران علاوه بر اینکه باید نظرسنجی را برای کاربران ساده کرد باید سوالات خاصی نیز پرسیده شود. تا در گرفتن feedback مناسب از کاربران گام های اساسی برداشته شود.

قدم هشتم Step 8) : Execute Deployment)

در این مرحله استقرار کامل البته در اندازه ای بسیار بزرگ تر از آنچه که در Pilot پیاده سازی شد، انجام می گردد. در طول مدت پروسه ی Pilot جزئیات و مسائل زیادی مورد استفاده قرار گرفت و حال یک Plan با جزئیات بسیار و دقیق ارائه شده و آماده Deploy شدن است.

Plan استقرار شامل یک برنامه اجرایی دقیق و برنامه ریزی برای هر یک از بخش های استقرار است. که شامل استقرار سرور، آموزش کاربران، استقرار نرم افزار و جابجایی و تنظیمات mailboxهاست. در این قدم هدف تکمیل deployment و حرکت به سمت فاز Operate است.

نهایتا کاربران را در مورد پروژه deploy آگاه کنید و قبل از اعمال هر تغییری که روی کاربران تاثیر می گذارد، حتما آنها را از آن تغییر و پیامدهای آن آگاه کنید. آموزش های لازم را برای کاربران ارائه کرده و قبل از همه adminهای خود را آموزش دهید.

فاز Operate

هدف نهایی از فازهای Plan و Deliver این است که سرویس نهایتا در فاز Operate اجرا شده و کار کنند. در این فاز، سرویس هایی که طراحی و deliver شده بودند نیاز به نگهداری در سطح بالایی دارند. به طور مثال اگر شما ماشینی خریداری کنید این فاز شبیه این است که شما ماشین را دریافت کرده و هر روز با آن رانندگی خواهید کرد. زمانی که صاحب خودرو شدید باید لاستیک را عوض کنید، روغن خودرو را چک کنید و در صورت نیاز آن را تعویض کنید و مراقبت های دوره ای را همیشه انجام دهید. در مورد پروژه هم در این فاز باید دائما وضعیت را مانیتور کنید تا در صورتی که alertی داده شده سریعا نسبت به رفع مشکل پیش آمده اقدام کنید.

فاز Manage

همان طور که message deployment به سمت فاز Operate حرکت کرد، بسیاری از افرادی که در پروژه deploy بودند به roleهای دیگری منتقل می شوند. در این زمان لازم است تا componentهای دیگری به میان آید تا بر نگهداری solution و ادامه تامین تامین نیازهای کسب و کار، نظارت کند. این جایی است که لایه Manage از MOF مطرح می گردد. در واقع لایه Manage یک فرآیند دنباله دار است که تضمین می کند که تمامی فازها طبق طراحی و به راحتی انجام می گردند و به صورت مستمر و دائم کار نظارت و برسی در حال انجام است.

خب دوستان ITpro یی ، در دو مقاله قبل سعی کردیم که به صورت کامل به برسی MOF و نحوه پیاده سازی پروژه های بزرگ در سطح شبکه بپردازیم ، البته شاید برای دوستانی که بیشتر عملیاتی و اجرایی هستند ، این دو مقاله کمی ( شایدم یکم بیشتر از کمی !!) تئوری و دانشگاهی ! بود اما برای اینکه هدف ما ارائه بسته کامل آموزشی سرور Exchange می باشد ، بنابر این کامل بودن و جامع بودن مطالب از اولویت بالایی برخوردار است و به امید خدا سعی بر این است تا به صورت عملیاتی و اجرایی هم به برسی جزئیات این سرور پرداخته و مطالب کاربردی تری نیز در این بسته آموزشی ارائه شود .

نکات مهم قبل نصب

این بخش تمامی componentهایی را که لازم است تا زمان پیاده سازی اولیه Exchange 2010 آنها را در نظر گرفت معرفی می کند. این componentها کمک می کند تا Exchange بر مبنایی محکم پیاده سازی شود و به علاوه پتانسیل های موجود در سازمان را شناسایی می کند.

بررسی توپولوژی شبکه

بررسی و تعیین توپولوژی شبکه ای که Exchange روی آن نصب می شود اهمیت حیاتی دارد که این بررسی در گام دوم (Step 2: Assess) از فاز Delivery (که در بخش هفتم این آموزش گنجانده شده است) انجام می گیرد. ایجاد تغییرات در زیرساخت های شبکه اغلب زمان قابل توجهی را خواهد گرفت زیرا تیم Exchange لزوما مسئول ایجاد این تغییرات در شبکه نیستند و communicationها و مذاکرات لازم که به طور معمول مورد نیاز هستند اکثرا قبل از ایجاد تغییرات باید شکل بگیرند به خصوص در سازمان های بزرگی که از OSهای ناهمگونی پشتیبانی می کنند.شناسایی تغییرات مورد نیاز و حصول اطمینان از اجرای بدون مشکل آنها در مراحل اولیه Design زمان زیادی را هنگام پیاده سازی Exchange 2010 برای ما صرفه جویی میکند.این بخش یک مرور کلی روی الزامات مرتبط با Network برای Exchange 2010 دارد.

بررسی توپولوژی فعلی شبکه و توپولوژی برنامه ریزی شده

گام اول جمع آوری تمام اطلاعات در مورد شبکه Internal، فضای پیرامون شبکه و فضای external است که این اطلاعات در حد امان باید کامل جمع آوری شوند و این اطلاعات باید شامل تمام جنبه ها باشد که عبارتند از:

  • Physical network topology ( توپولوژی فیزیکی شبکه)

کنترل کنید که در همه جا از پروتکل TCP/IP استفاده گردد که Internet Protocol مورد استفاده IPv4 یا IPv6 یا هر دو با هم است. IPآدرس ها چگونه به سرورها اختصاص داده شده اند و اینکه subnet ها بر اساس موقعیت قرارگیری از همان IP باشند.

  • Internal physical network connections or links ( لینک ها یا اتصالات فیزیکی شبکه داخلی)

که شامل لینک های LAN و WAN، روتر و ... است.

  • External physical network connections ( اتصالات فیزیکی شبکه خارجی)

که شامل اینترنت، شرکت های شرکا و ... است.

  • Interconnection of physical network connections ( نحوه اتصال فیزیکی شبکه )

که شامل hub-and-spoke، Ring یا Star و point-to-point است.

  • Physical network speed ( سرعت شبکه)

که بین پهنای باند تضمین شده (guaranteed bandwidth)، پهنای باند موجود و زمان تاخیر برای هر یک از لینک های مشخص تقسیم می شود.

  • Network protection that might interfere ( حفاظت شبکه ای در شبکه هایی که ممکن است در آنها تداخل رخ دهد)

که شامل فایروال هاست که از لینک های فیزیکی یا deviceهای رمزگذاری لینک شبکه محافظت می کنند که سرعت لینک را کاهش می دهد.

  • در دسترس بودن پورت فایروال برای سیستم های داخلی و خارجی
  • سرور name resolution مورد استفاده شده در موقعیت و بین موقعیت ها (DNS/WINS)
  • فضاهای نام (Namespace) تعریف شده در DNS

که بعدا در Planning Namespace در همین بخش توضیح داده خواهد شد.

  • Perimeter network servers (سرورهای Perimeter شبکه)

که شامل تمام سرورهایی است که در یک شبکه perimeter قرار دارند به ویژه هر سروری که امکان SMTP-relay را فراهم می کند.

Domain Name System )DNS)

در این بخش، در مورد پایه و اساس فنی در سیستم (DNS) بحث شده است. وشامل مطلبی درباره Namespace planning نیست. جنبه های namespace planning و disjoint namespace یا single label domains در بخش “Planning Namespace” بعدا شرح داده خواهد شد.

DNS and Active Directory

Microsoft Windows از استاندارد DNS به عنوان سرویس اصلی name registration و name resolution برای AD استفاده می کند. به همین دلیل به عنوان یک نیاز اساسی لازم است تا تمام clientها و سرورها به طور قابل اطمینانی در namespace مناسب در queryهای DNS، resolve شوند. DNS یک پایگاه داده سلسله مراتبی (hierarchically)، توزیع یافته (distributed) و مقیاس پذیر (scalable) فراهم می کند که در آن host می تواند رکوردهای خود را به صورت خودکار update کند. این رکوردهای پویا (dynamic) زمانی که از Active Directory–integrated DNS zones استفاده می کنید به طور کامل با AD مجتمع (integrate) می شوند.لیست زیر بهترین پیشنهادها برای تنظیمات DNS است زمانی که شما Exchange 2010 را روی AD خود پیاده سازی می کنید:

  • از سرویس های DNS Server که جزئی از Windows Server است، استفاده کنید. که برای شما ویژگی هایی از جمله update اتوماتیک و zoneهای AD–integrated DNS را فراهم می کند. به طور مثال، domain controllers (DC) انواع سرویس های شبکه ای در DNS را register می کند بنابراین سایر کامپیوترها در forest می توانند به آنها دسترسی داشته باشند.
  • اگر نمی توانید از سرور Windows DNS برای AD استفاده کنید، مطمئن شوید که DNS از رکوردهای SRV پشتیبانی می کند و updateهای اتوماتیک رکوردهای Locator DNS (SRV and A records) را allow کنید. اگر شرکت شما از BIND استفاده می کند، مطمئن شوید که از BIND 8.x یا بعد از آن استفاده می کنید.
  • تمام zoneهای DNS را به عنوان Active Directory–integrated در AD ذخیره کنید تا از منافع مربوط به replicate بین DNS و AD توسط یک مکانیسم واحد استفاده کنید. که سبب می شود تا برای troubleshooting نیاز به ابزارهای مختلف نداشته باشیم.
  • Dynamic Update را به صورت Secure پیکربندی کنید تا فقط کلاینت های authorize شده اجازه register کردن host name و IP addressشان را داشته باشند.
  • فقط Forward Lookups Zoneهایی که مورد نیاز Exchange 2010 است را پیکربندی کنید. لازم نیست که Reverse Lookup Zoneها را پیکربندی کنید چرا که توسط Windows 2008 یا Exchange 2010 استفاده نخواهند شد.

برای دسترسی به اطلاعات بیشتر در این زمینه به آدرس زیر مراجعه کنید:

DNS

DNS Recordهای مورد استفاده توسط Exchange 2010

(این بخش مروری بر مهم ترین رکوردهای DNS خواهد داشت. )

    • A Records : A record یا Host record تبدیل (mapping) یک host name به IP address را فراهم می کند. Host record برای هر DC و سایر hostهایی که لازم است توسط Exchange یا سایر کلاینت ها در دسترس باشند، لازم است. A recordها از IPv4 استفاده می کنند. در زیر نمونه ای از یک A record را می بینید:
berlin-dc01.ITPRO.IR. IN A 10.10.0.10
    • SRV Records : تمام سرورهای Exchange 2010 از DNS برای تعیین موقعیت valid domain controller یا global catalog استفاده می کنند. به طور پیش فرض هر زمان که DC سرویس Netlogon را شروع می کند، DNS را با service (SRV) recordهایی که آن DC را به عنوان سرور DC و global catalog معرفی می کنند، بروزرسانی می کنند.SRV resource records رکوردهای DNS هستند. این رکوردها سروری که روی شبکه سرویس خاصی را ارائه می دهد، شناسایی می کنند. به طور مثال یک SRV record می تواند شامل اطلاعاتی باشد که به client کمک کند تا یک DC server را در یک Domain خاص یا یک site پیدا کند. به همین دلیل SRV recordها برای DC سرورها و global catalog سرورها با چندین مقدار مختلف register می شوند تا اجازه دهند که در طول زمان پروسه ی Active Directory discovery، سرورهای Exchange بتوانند server DC یا global catalog مناسب را پیدا کنند.یک گزینه register کردن DNS با نام site است که این امکان را فراهم می کند که کامپیوتری که Exchange server را راه اندازی کرده است بتواند سرورهای DC و global catalog را در Local AD سایت پیدا کند. Exchange Server همیشه مایل است که dc server یا/و global catalog سروری از همان Site که Exchange در آن نصب شده است انتخاب کند.در اینجا مثالی از SRV Record را می بینید:
_ldap._tcp.ITPRO.IR. IN SRV 0 100 389 berlin-DC01.ITPRO.IR.
    • MX Records : رکورد Mail Exchanger )MX) یک resource record است که این امکان را فراهم می کند که سرورها سایر سرورها را برای تحویل یک internet e-mail که از Simple Mail Transfer Protocol )SMTP) استفاده کرده است، پیدا کنند. یک رکورد MX سرورهای SMTP که پیام های inbound در یک Domain DNS خاص را می پذیرند، شناسایی می کند. هر رکورد MX شامل یک Host name و یک preference value است. زمانی که شما چندین SMTP سرور که از اینترنت قابل دسترس است را به کار می گیرید، می توانید به همه ی آنها preference value یکسان بدهید تا round-robin را بین SMTP سرورها فعال کنید. به علاوه می توانید به یکی از MXها مقدار کمتری برای preference value در نظر بگیرید. در این صورت تمام پیام به سمت این سروری که preference value کمتری دارد Route می شوند مگر اینکه این سرور از دسترس خارج باشد. در زیر نمونه ای از یک MX Record را می بینید:
ITPRO.IR MX 10 fresno-ht01.na.ITPRO.IR
  • SPF Records : در Exchange Server 2010 از رکوردهای Sender Policy Framework )SPF) برای پشتیبانی از ID spam filtering فرستنده استفاده می کند. اگر بخواهید که از این قابلیت استفاده کنید باید SPF recordها را در DNS پیکربندی کنید. در این باره در بخش های بعدی (Edge Transport and Messaging Security) به تفصیل توضیح داده خواهد شد.

Split DNS

Split DNS یا split-brain DNS در مورد راه اندازی zoneهای جداگانه در DNS به کار می رود بنابراین آن DNS requestهایی که از اینترنت آمده اند به IP address های متفاوتی resolve خواهند شد با توجه به اینکه درخواست ها از internal workstations شما آمده باشد یا از serverها. به عبارت دیگر همان طور که در شکل 8-1 نشان داده شده است اگر یک internet client بخواهد آدرس mail.litware.com را resolve کند، IP addressی را دریافت می کند که مربوط به یک فایروال خارجی (External Firewall) است که بر روی perimeter (پیرامون،محیط) شبکه نشسته است. Internal client در این جا یک IP address مرتبط با internal Client Access server را می گیرد.

Split DNS

Figure 8-1 How split DNS works

مزیت استفاده ار split DNS کمک به کنترل دسترسی کلاینت هاست. کلاینت های internal به جای استفاده از سیستم های خارجی از سیستم های داخلی استفاده می کنند. به عبارت دیگر sessionهای کاربران داخلی توسط برنامه های firewall راه اندازی نمی شود و شما IP address یا host name های داخلی را در اینترنت در معرض دید و خارج از حفاظت قرار نمی دهید. به علاوه می توانید دسترسی hostهای خاصی که در پیرامون (perimeter) شبکه هستند یا force userها را محدود کنید تا فقط یک مسیر ارتباطی خاص را بگیرند. بنابراین در سازمان هایی که roleهای سرور در معرض اینترنت قرار می گیرند، بهترین روش پیاده سازی split DNS است.

تفاوت Fixed IP Address با Dynamic IP Address

شما باید باید بدانید که سرویس دهنده اینترنت به شرکت شما از یک fixed IP addresses برای دسترسی به اینترنت استفاده می کند یا یک dynamic IP addresses. اگر سرورهای شما که با بیرون ارتباط دارند، مثل Edge Transport servers، دارای یک fixed IP address باشند و ورودی های DNS شامل رکوردهای MX یا A به همین ترتیب register شده باشند، شما می توانید به بهترین روش کار کرده و با بیرون ارتباط داشته باشید. از آنجایی که هزینه fixed IP address برای برخی سازمان ها به خصوص شرکت های کوچک بالاست بعضی ها ترجیح می دهند که Exchange سرور 2010 را بر پایه Internet Providerهایی بنا کنند که تنها یک Dynamic IP ارائه می کند. اگر در چنین موقعیتی قرار دارید باید یک Dynamic DNS Service در نظر بگیرید که به شما اجازه بدهد تا Dynamic IP address خود را در سرویس DNS آنها register کنید. و مطمئن شوید که Dynamic DNS service موارد زیر را داراست:

  • IP addresses شما زمانی که تغییر می کند باید به صورت خودکار درDNS ثبت (register) شود. Router شما و/یا ارائه دهنده Dynamic DNS service باید از این IP پشتیبانی کند.
  • IP updateها به صورت real time در DNS، replicate شوند تا مطمئن شویم که این تغییرات به صورت همزمان و فورا توسط اینترنت شناخته شده اند.
  • برای اینکه سرورهای خارجی SMTP بدانند که چطور پیام ها را به Domain شما بفرستند باید DNS رکورد Domain شما شامل MX record باشد.
  • Dynamic DNS service باید به شما یک SMTP relay host برای فرستادن پیام به اینترنت ارائه کند در غیر این صورت به علت تغییر IP اگر به صورت مستقیم پیام را بفرستید سرور شما را به عنوان یک اسپم در نظر می گیرد. بسیاری از SMTP serverها IPهای dynamic را مورد اطمینان ندانسته و بنابراین پیام ها رسیده از طریق آنها را قبول نمی کنند. اگر نکات فوق را رعایت کنید هنگام کار با Exchange 2010 زمانی که از Dynamic IP استفاده می کنید مشکلی نخواهید داشت.

Internet Protocol )IPv4 and IPv6)

Internet Protocol Version 4)IPv4) به طور معمول برای ارتباط بین دو device در اینترنت با هم استفاده می شود. جانشین IPv4، Internet Protocol Version 6 (IPv6) نامیده می شود که در سال 1996 در RFC 2460 تعیین شد. IPv6 برای رفع برخی کاستی های IPv4 ارائه شد از جمله محدودیت آدرس های IPv4 و کمبود توسعه. به علت اینکه طول IPv6 معادل 128 بیت است ( در مقابل IPv4 که 32 بیت بود) دیگر با کمبود تعداد IP مواجه نخواهیم بود و به تعداد تمام حشره ها و حیوانات زنده و هر کس دیگری روی زمین آدرس IP وجود خواهد داشت.( البته فکر کنم تعداد حشره ها و حیوانات زنده را اشتباهی شمردن!! :دی) متاسفانه IPv6 یک فرمت از IPv4 نیست و یک پروتکل کاملا جدید است. بنابراین یک شبکه IPv4 نمی تواند به صورت مستقیم با یک شبکه IPv6 ارتباط داشته باشد و بالعکس. تمام deviceهای شبکه مثل روتر باید IPv6 را بفهمند در غیر این صورت ارتباط با مشکل مواجه خواهد شد.

IPv6 for Windows

نرم افزارهای client و سروری برای استفاده از IPv6 باید از آن پشتیبانی کنند. سیستم عامل های سروری مایکروسافتی زیر از IPv6 پشتیبانی می کنند:

(Windows Server 2003 IPv4 is installed and enabled; IPv6 is not installed by default.)
(Windows Server 2008 IPv4 and IPv6 are installed and enabled by default.)
(Windows Server 2008 R2 IPv4 and IPv6 are installed and enabled by default.)

نه تنها سرورها که کلاینت ها نیز باید از IPv6 پشتیبانی کنند. سیستم عامل های کلاینتی زیر از IPv6 پشتیبانی می کنند:

Windows XP Service Pack 1(SP1) or later (IPv4 is installed and enabled; IPv6 is not
installed by default.)
(Windows Vista IPv4 and IPv6 are installed and enabled by default.)
(Windows 7 IPv4 and IPv6 are installed and enabled by default.)

برای کسب مطالب بیشتر در مورد IPv4 و IPv6 به آدرس زیر رجوع کنید:

IP V6

IPv6 for Exchange Server 2010

از آنجایی که Exchange Server 2010 روی Windows Server 2008 یا R2 راه اندازی می شود ممکن است که شما فکر کنید که به طور اتوماتیک از IPv6 پشتیبانی می کند. با این حال شما باید زمانی که دارید برای IPv6 و Exchange 2010 برنامه ریزی می کنید به چند مسئله توجه کنید. Exchange Server roleهای زیر زمانی که از IPv6 استفاده می کنید ممکن است مسائلی را به وجود بیاورند:

  • Hub or Edge Transport

ویژگی هایی مثل IP Allow List Providers یا Sender reputation از IPv6 پشتیبانی نمی کنند چرا که به IP address استاتیک نیاز دارند.

  • Unified Messaging

هیچ یک از ویژگی ها از IPv6 پشتیبانی نمی کنند و برای درست کار کردن به IPv4 نیاز دارند.

  • Client Access Server

Autodiscover and EWS Web services endpoints because you cannot configure an IIS binding for an IPv6 address—WCF throws a Watson exception if you try to configure it.

  • (Database Availability Group (DAG

حتی اگر شما نتوانید یک IPv6 DAG IP address تعریف کنید باز هم از IPv6 پشتیبانی می شود. زمانی که IP آدرسهای استاتیک IPv4 برای یک DAG اختصاص داده می شوند، آن DAG فقط از IPv4 استفاده می کند. زمانی که static IPv4 تعیین نشود، Exchange از DHCP از دستیابی به IPv4 استفاده می کند و همچنین منابع مربوط به IPv6 را نیز create می کند.

Exchange Server از Windows network stack برای اجرای هر request استفاده می کند. هر درخواست به دو عامل بستگی دارد:

  1. Name resolution ( زمانی که درخواست شروع می شود)
  2. Packet type ( هنگام دریافت درخواست)

اول name resolution تعیین می کند که چگونه درخواست از یک کامپیوتر به کامپوتر دیگر آغاز شود که بر اساس آن (IP address (IPv4 or IPv6) که اول resolve شده بود، تصمیم گیری می شود. زمانی که name resolution با یک IPv6 برمی گردد این آدرس برای آغاز درخواست به کار می رود.

دوم، packet type با midstream ورژن IP ترکیب نمی شود. اگر درخواست (Request) از یک IPv4 بیاید پاسخ (Response) نیز از یک IP4 استفاده خواهد کرد و به همین شکل در مورد IPv6. برای ویژگی هایی که از IPv6 پشتیبانی نمی کنند، Exchange باعث می شود که درخواست با شکست مواجه شود و کلاینت یک درخواست دیگر با استفاده از IPv4 می فرستد. بنابراین یک IPv6 request حتی به Unified Messaging role سبب ایجاد مشکل نخواهد بود بلکه فقط نادیده (ignore) گرفته خواهد شد.

Understanding Client Load Patterns

یکی دیگر از جنبه های مهمی که هنگام Planning سرور Exchange 2010 باید در نظر گرفت، client load patterns فعلی است، یعنی ترافیک بین کلاینت های Outlook ( یا سایر mail clientها) و Exchange server.محدوده این کارها به اینکه کلاینت های mail شما در حال حاضر چه هستند، بستگی دارد. اگر بیشتر کلاینت های شما از POP3 و IMAP4 استفاده کنند، load روی سرور Exchange به طور قابل توجهی پایین تر خواهد بود در نتیجه می توانید برای تعداد بیشتری کلاینت روی یک سرور برنامه ریزی کنید.

اگر از کلاینت های مبتنی بر MAPI استفاده می کنید مثل Microsoft Outlook 2003 یا Outlook 2007 لازم است تا ببینید که متوسط کاربران از چه Profile استفاده کرده اند تا بتوانید تاثیر ترافیک به سمت سرور Exchange را درک کنید. می توانید از اطلاعات به دست آمده از سیستم مانیتورینگ خود بهره ببرید مثل Microsoft System Center Operations Manager البته اگر در دسترس باشد. همچنین می توانید از Windows Performance Monitor برای جمع آوری اطلاعات درباره عملکرد کلاینت ها استفاده کنید. performance counterهای زیر را در نظر گرفته و از آنها استفاده کنید:

  • Messages sent/received per day
  • Average message size
  • Messages read per day
  • Messages deleted per day
  • Outlook Web Access logon and logoff per day

توجه داشته باشید که dataی کلاینت را از سرور Exchange یا سرور mail ( زمانی که از یک سیستم non-Exchange استفاده می کنید.) به مدت حداقل دو روز ( در اوج ساعات کاری نه در روزهای آخر هفته) جمع آوری کنید تا بتوانید به یک نمودار جامع از performance data دست یابید.بعد از اینکه نتایج را جمع کردید، می توانید آنها را با جدول 8-1 مقایسه کرده و تشخیص دهید که چگونه پروفایل کلاینت هایتان را بر اساس رایج ترین پروفایل های مایکروسافت طبقه بندی کنید.

Table 8-1

Table 8-1 Common Client Profiles

زمانی که تشخیص دادید که client load pattern نوعی شما چیست، باید برای اجرای یک ابزار load-generating مثل Exchange Load Generator 2010 برای بررسی عملکرد سخت افزار سرور Exchange خود برنامه ریزی کنید.

اطلاعات بیشتر در مورد اینکه چگونه برای سخت افزار Exchange خود برنامه ریزی کنید و اینکه چگونه از Exchange Load Generator استفاده کنید در بخش های بعد (Hardware Planning for Exchange server 2010) خواهد آمد.

Perimeter Network

ارتباط با اینترنت یا شبکه های خارجی (External) نیز بسیار مهم است. اطلاعات بیشتر در مورد پورت های فایروال یا پروتکل هایی که باید پیکربندی شوند بعدا در بخش Planning Network port requirement خواهد آمد. این بحث شامل optionهای امنیتی مثل IPsec یا VPN که اجازه می دهد تا کلاینت از روی اینترنت به طور مستقیم به شبکه داخلی شان متصل شوند نخواهد بود.

Deployment پیشنهاد شده برای Exchange server 2010 برای دستیابی به اینترنت شامل 2 فایروال یا روتر در یک سناریوی فایروال back-to-back است که به شما اجازه می دهد تا بین دو شبکه یک perimeter network اجرا کنید. یک فایروال خارجی (External firewall) با اینترنت مواجه و روبرو است و از شبکه perimeter محافظت می کند.

سپس یک فایروال داخلی (Internal firewall) بین شبکه perimeter و شبکه داخلی شرکت قرار می گیرد.در شبکه perimeter هر سروری که internet-facing است قرار می گیرد مثل Edge Transport role of Exchange Server 2010. مایکروسافت از طراحی هایی که فایروالی بین Mailbox سرور، Client Access و ... قرار می دهد، پشتیبانی نمی کند. چرا که این roleها از پورت های dynamic استفاده می کنند که می تواند به طور ناخواسته توسط فایروال block شود. تنها Exchange 2010 role که برای استقرار در یک perimeter network پشتیبانی می شود، Edge Transport role است.

نکته مهم :

Edge Transport server role نباید هرگز عضو domain داخلی شما باشد، بلکه باید یک سرور stand-alone یا عضو یک perimeter AD forest قابل دسترس باشد.

رایج ترین سرورهایی که در perimeter قرار می گیرند تا دسترسی به اینترنت را پشتیبانی کنند عبارتند از:

  • یک smart host برای route کردن پیام های SMTP بین شبکه های internal و external مثل Edge Transport server role یا هر smart host دیگری.
  • یک reverse proxy یا فایروال application-layer که ترافیک های client-related را پشتیبانی می کند مثل (Autodiscover، Outlook Web App ( OWA که قبلا به نام Outlook Web Access شناخته می شد).، Outlook Anywhere، ActiveSync، POP3، IMAP4، SMTP و ... به سمت شبکه internal. Microsoft Forefront TMG و Microsoft ISA Server 2006 نمونه هایی از فایروال application-layer هستند. با این حال چالش های scalability را برای پروکسی سرورهای reverse مبتنی بر software را دست کم نگیرید. هر پیاده سازی که در آن لازم باشد تا بیش از 100000 connection به صورت همزمان و مداوم handle شود باید روی یک solution سخت افزاری تمرکز کند.

نکته:

برای کاهش سطح attack در internal forest نباید سرور Client Access را روی perimeter network قرار دهید. از آنجا که حساب کاربری (account) سرور Client Access کامپیوتر Exchange دارای بالاترین اجازه دسترسی (privilege) است ممکن است که توسط یک attacker برای خراب کردن Active Directory شما به کار رود. در عوض از یک فایروال application-layer مثل Microsoft Forefront Threat Management Gateway-TMG) برای publish کردن سرویس های سرور Client Access به اینترنت استفاده کنید.

اگر از فایروال application-layer مایکروسافت استفاده نمی کنید، مسائل کلیدی زیر را برای انتخاب فایروالی با بالاترین استاندارد امنیتی در نظر بگیرید:

  • Pre-authenticate traffic برای جلوگیری از ورود ترافیک های unauthenticated به شبکه شرکت.
  • Packet inspection فایروال های Application-layer این اجازه را می دهد تا پروتکل های attack شناخته شده قبل از ورود به شبکه داخلی شرکت شما شناسایی شوند.
  • Intrusion Detection System )IDS) (سیستم های تشخیص نفوذ) به بیان ساده حملات (attack) را روی سیستم شناسایی می کنند. اگر حمله ها داخلی باشد، شاتس موفقیت آنها بالا و تشخیص (detect) آنها مشکل خواهد بود چرا که ممکن است شبیه یک ترافیک معمولی به نظر برسند، در حالی که اگر proxy شروع به ارسال درخواست RPC به دیگر سرورها کند، یا سعی کند که از فایروال عبور کند، block و log خواهد شد.
  • Fixed Ports/IP Addresses فقط پورت ها و IP آدرس های خاصی برای ورود به محیط شبکه شرکت مجاز هستند.
  • Group Membership allowance این قابلیت را فراهم می کند تا فقط گروه خاصی بتوانند به applicationهای خاصی دسترسی داشته و مجاز به استفاده از آنها باشند. برای مثال my current customer به کارگران ساعتی این اجازه را نمی دهد که به mail externally دسترسی داشته باشند.
  • Load balancing آرایه ای از سرورهای reverse proxy است که می توانند ترافیک شبکه را برای یک single URL توزیع کنند.

به عنوان بهترین روش، اگر می خواهید که دسترسی اینترنتی به سرور Exchangeتان داشته باشید، همیشه از یک reverse proxy یا application-layer firewall استفاده کنید. اگرچه برخی از شرکت ها، مخصوصا در بخش های کوچک یا متوسط، هیچ نوع امنیتی بین اینترنت و سرورهایشان پیاده سازی نمی کنند. اگر شما نیز یک فایروال application-layer را پیاده سازی نکرده اید، توصیه های زیر را در نظر بگیرید:

  • یک فایروال بین شبکه internal و external قرار دهید و فقط پورت و پروتکل هایی که به آنها نیاز دارید را باز بگذارید.
  • یک server certificate برای تمام سرورهای Exchange خود پیاده سازی کنید. ( که می تواند یک single certificate باشد که شامل domain names های مورد نیاز باشد.)
  • به یک SSL برای رمزنگاری (encrypt) کردن ارتباطات کلاینت ها نیاز دارید. ( برای Outlook client traffic).
  • اگر POP3 یا IMAP4 را فعال کرده اید برای SMTP و SSL به TLS نیاز دارید.
  • مطمئین شوید که هر عملیات نیاز به احراز هویت (authentication) دارد.
  • برای Outlook Web App احراز هویت بر مبنای فرم (Forms-based authentication) را پیاده سازی کنید.

این شرایط برای شما حداقل امنیت را فراهم می کند اما هنوز ممکن است که بخشی از داده های کاربران شما روی اینترنت انتشار پیدا کند. با این حال از هیچ بهتر است.

پیشنهادات تکنیکی برای جلوگیری از Pitfalls

لیست زیر راه هایی برای پیشگیری از pitfall های (تله-مشکلات) بالقوه در سمت توپولوژی شبکه ارائه می کند. اول باید هر مشکلی که وجود دارد را حل کرد تا بعد بتوان Exchange server 2010 را روی location مورد نظر نصب کرد.

  • مطمئن شوید که سرعت شبکه فیزیکی سایتی که میزبانی سرور Exchange 2010 را به عهده دارد حداقل 64 kbps از پهنای باند در دسترس است.
  • Exchange سرور 2010 از یک محیط کاملا بر مبنای TCP/IP v6 (IPv6) پشتیبانی نمی کند. اگر می خواهید در هر جای شرکت IPv6 پیاده سازی کنید، مطمئن شوید که آنها آدرس IPهای ورژن 4 (IPv4) را نیز پشتیبانی می کنند در غیر این صورت ممکن است کاربران در برقراری ارتباط با سرور Exchange 2010 دچار مشکل شوند.
  • IP subnet ها باید به موقعیت های شرکت map شوند و هیچ overlap ی نباید بین locationها وجود داشته باشد. گرچه گاهی اوقات یک موقعیت دارای چندین IP subnet است که این مسئله خوب است. اگر IP subnetها چندین موقعیت فیزیکی را در بر می گیرند، مطمئن شوید که لینک WAN بین آنها با سرعت لینک LAN هماهنگ باشد. (10Mbps یا بیشتر)
  • مطمئن شوید که site ADهای شما با IP subnetهای هر location مطابقت دارد.
  • برای network name resolution باید از DNS استفاده شود.
  • AD از منابع رکوردهای SRV)service) در DNS برای register کردن یک لیست از DCها برای استفاده کلاینت ها بهره می برد. اگر از Windows Server 2008 DNS Service برای AD استفاده نمی کنید، مطمئن شوید که نرم افزار سرور DNS شما از resource رکوردها پشتیبانی می کند.
  • برای دریافت پیام ها از اینترنت، یک رکورد mail exchanger )MX) مناسب در DNS برای domain name شرکت نیاز است .

شما هشتمین بخش از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم .

آماده سازی اکتیودایرکتوری

ارزیابی و برنامه ریزی برای AD

اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود.

چگونه Exchange 2010 از AD استفاده می کند

دیتابیس AD برای هر domain به سه بخش تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008 و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.

همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

The Schema partition

قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود.

schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:

  • Schema classes : objectهایی که می توانند ایجاد شوند.
  • Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است.

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange سرور 2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است.

Configuration partition

این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید.

Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

Domain partition

این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox، database’s mailbox و public folder proxy را ذخیره می کند.

شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

Application partition

این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

Active Directory replication Impact on Exchange 2010

Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند.

به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد.

دو امکان برای غلبه بر تاخیر replication وجود دارد:

  • EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید:

Set-ADServerSettings –PreferredServer <DC FQDN>

    • از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
  • repadmin tool

در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست.

Active Directory requirements

برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای طراحی current AD باید نکات زیر را در نظر بگیرید:

  • سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003 -32bit or 64bit باشد.
  • اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
  • AD باید حداقل در Windows Server 2003 forest functionality mode باشد.
  • Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
  • تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل Windows Server 2003 domain functional level باشند.
  • به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

تفاوت Single و Multi-Forest Implementation

برای اجرا و پیاده سازی forest روش های زیر وجود دارد:

  • Single Forest
  • Multi-forest
  • Resource Forest
  • Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.

!! *ارزیابی و برنامه ریزی برای AD*  
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود. 

!! *چگونه Exchange 2010 از AD استفاده می کند*
دیتابیس AD برای هر domain به سه قسمت تقسیم می شود که عبارتند از logical partitions ( که به نام schema partition شناخته می شود.)، configuration partition و domain partition. Windows Server 2008  و R2 ابزاری به نام Repadmin دارد که می توان از آن برای لیست کردن پارتیشن های در دسترس AD استفاده کرد. شکل 3-2 نتیجه سناریوی Litware را نشان می دهد که در آن از دستور (command) Repadmin /showrepl استفاده شده است.
همان طور که در شکل نشان داده شده است، AD از پارتیشن های configuration، schema، application و domain تشکیل شده است. 


||http://tosinso.com/files/get/c47ca1f3-520c-4b29-93b7-741cb8895424||

!! *The Schema partition*
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود. 
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
* Schema classes : objectهایی  که می توانند ایجاد شوند. 

* Schema attributes : ویژگی هایی که برای هر یک از objectها قابل استفاده است. 

از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.


||http://tosinso.com/files/get/e9db966b-a63b-4bd0-897e-bee483530660||

در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange  سرور  2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.


||http://tosinso.com/files/get/fa86cd9f-9875-4fed-a733-7518105ec671||

به علاوه با استفاده از ویژگی rangeUpper می توانید تشخیص دهید که آیا schema update با موفقیت به domain controller محلی replicate شده است یا خیر. برای این کار باید به DC متصل شده و سپس بررسی کنید که آیا این attribute دارای current value هست یا خیر و از این طریق مطمئن شوید که schema update، replicate شده است. 

*Configuration partition*
	این partition شامل اطلاعات پیکربندی برای AD forest است. به علاوه بعضی از applicationهای distribute شده و سایر سرویس ها اطلاعاتشان را در configuration partition ذخیره می کنند. اطلاعاتی که در configuration partition هستند بین کل forest جابجا (replicate) می شوند بنابراین هر domain controller (DC) و هر global catalog (GC) یک کپی ( المثنی ) از این اطلاعات دارند. این پارتیشن هر نوع (type) از اطلاعات پیکربندی را در یک container جداگانه ذخیره می کند. container یک AD object است شبیه organizational unit (OU) که از آن برای سازماندهی سایر objectها استفاده می کردید. 
Exchange Server 2010 اطلاعاتی مثل global settings، address lists، connections و... را در configuration partition ذخیره می کند. شکل 3-4 به شما نشان می دهد که چگونه می توانید اطلاعاتی که Exchange Server 2010 در این پارتیشن را ذخیره می کند را ببینید. با استفاده از ADSI Edit یا Active Directory Sites and Services قادر به دیدن این اطلاعات هستید ( البته باید Show Services Node را فعال کنید.). به علاوه باید عضو گروه Organizational Management یا View-Only Management باشید. یعنی باید دارای Exchange Organizational permissions باشید. 


||http://tosinso.com/files/get/377ecb29-63b0-49a9-ba7a-c1f9c5993e7e||

!!  *Domain partition*
این پارتیشن اطلاعات مرتبط با domain را در containerهایی مثل OU نگهداری می کند. این پارتیشن شامل اطلاعاتی درباره users، groups و computers در آن domain است. domain partition روی هر domain controller از آن domain خاص ذخیره می شود. هر سرور global catalog یک زیرمجموعه از اطلاعات هر domain partition در forest را دارد مثل یک کپی کامل از own domain’s objects. به طور مثال یک سرور global catalog در یک domain متفاوت شامل اطلاعات یک user خواهد بود، اطلاعاتی مثل user’s display name یا SMTP addresses اما password آن را نخواهد داشت.

 برای هر Exchange-prepared domain ( به این معنا که برای آن domain، Exchange Setup /PrepareDomain راه اندازی شده باشد)، Exchange Server 2010 یک OU که Microsoft Exchange System Objects نامیده می شود، ایجاد می کند که در آن objectهای سیستمی مرتبط با Exchange مثل mailbox،  database’s mailbox و public folder proxy را ذخیره می کند. 
شما می توانید با نگاه کردن به ویژگی ObjectVersion در Microsoft Exchange System Objects OU روی همان domain متوجه شوید که domain شما Exchange Domain–Prepared هست یا خیر. برای Exchange 2010، باید RTM مساوی 12639 باشد، که در شکل 3-5 این موضوع نشان داده شده است. 

||http://tosinso.com/files/get/3c14770d-8510-4e5b-bb31-19ef0ed0f88f||

!! *Application partition*
این پارتیشن application dataهای خاص که برای آن application مورد نیاز است را نگهداری می کند. مزیت اصلی این پارتیشن replication flexibility است. شما می توانید  DCهایی را جهت نگهداری یک کپی از application partition تعیین کنید و این DCها می توانند شامل زیرمجموعه ای از DCهایی در کل forest باشند.در حال حاضر تنها application که از application partition استفاده می کند DNS است، برای ذخیره zoneهای DNS در این پارتیشن مثل AD باید zoneها را مجتمع (integrate) کنید. Exchange Server 2010 از application partitions برای ذخیره اطلاعات استفاده نمی کند. جدول 3-3 application partitionهایی که به طور معمول در AD در دسترسند را شرح می دهد.


||http://tosinso.com/files/get/1d855066-899c-4fa5-9129-8f23a23bffbe||

البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.

!! *Active Directory replication Impact on Exchange 2010*
Active Directory replication یک component حیاتی از Exchange 2010 است. همان طور که توضیح داده شد، پارتیشن های مختلفی داده های مرتبط با پیکربندی Exchange را ذخیره می کنند. این data با استفاده از AD replication mechanisms  به صورت اتوماتیک بین Active Directory sites جابجا (replicate) می شوند. 
به علت اینکه Exchange 2010 برای درست کار کردن متکی به مکانیسم های replication است، ممکن است که در طول پیکربندی با تاخیر مواجه شوید که به سبب تاخیر replication است. به عنوان مثال اگر یک سرور Exchange را در دامنه emea.litware.com پیکربندی کنید در حالی که current computer شما در na.litware.com قرار داشته باشد خواهید دید که آن تنظیمات به طور آنی (immediate) در دامنه emea.litware.com قابل دسترس نخواهند بود. بلکه لازم است تا زمانی که AD replication انجام می گیرد و تغییرات به domain ارسال (replicate) شود، منتظر بمانید. به طور معمول replication بین siteها هر 15 دقیقه یا بیشتر با توجه به تنظیمات AD Site Link شما انجام می گیرد. 
دو امکان برای غلبه بر تاخیر replication وجود دارد:
* EMCیا EMS خود را پیکربندی کنید بنابراین می توانید از یک DC که در target Domain تعیین شده است، به صورت مستقیم استفاده کنید. برای مثال در EMS می توانید DC ارجح را با استفاده از cmdlet زیر تعیین کنید: 
Set-ADServerSettings –PreferredServer <DC FQDN> 
* 	از Repadmin برای push کردن replication به target Domain استفاده کنید. برای کسب اطلاعات بیشتر در مورد Repadmin tool به آدرس زیر مراجعه کنید:
<left>
!! |repadmin tool::http://www.microsoft.com/downloads/details.aspx?familyid=c6054092-ee1e-4b57-b175-5aabde591c5f&displaylang=en|
<left>
در کنار Active Directory replication، اطلاعات مربوط به Active Directory sites and IP site link نیز برای message routing بین Exchange serverها ضروری است. Exchange 2010 از cost assignment که بخشی از هر IP site link است برای تعیین کم ترافیک ترین مسیر زمانی که چندین مسیر برای یک مقصد وجود دارد، استفاده می کند. این اطلاعات توسط Hub Transporter role مورد استفاده قرار می گیرد تا تصمیم بگیرد که کدام Exchange Hub Transport server برای فرستادن message استفاده شود زمانی که target Exchange Hub Transport server در دسترس نیست. 

!! *Active Directory requirements*
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای  طراحی current AD باید نکات زیر را در نظر بگیرید:
* 	سروری که Schema Master role روی آن run می شود باید حداقل ویندوز سرور -SP1 2003    -32bit or 64bit باشد. 
* اگر می خواهید که Exchange Server 2010 را نصب کنید باید روی سرورهای GC در هر AD site، ویندوز سرور 2003 SP1 یا جدیدتر از آن (32bit or 64bit) را نصب کنید. در صورتی که هنوز در محیط کاری GCهایی با سیستم عامل های قدیمی تر از این دارید، پیشنهاد می شود که تمام DCهای خود را جهت جلوگیری از هر مشکلی upgrade کنید.
* AD باید حداقل در Windows Server 2003 forest functionality mode باشد. 
* 	Windows Server 2008 functionality mode پشتیبانی می شود اگر Exchange organization شما شامل Exchange 2007 and/or 2010 باشد.
* 	تمام Domainها باید شامل سرورهای Exchange Server 2010 باشند یا اینکه سرویس گیرندگان باید حداقل  Windows Server 2003 domain functional level باشند.
* به علت اهمیت GC در یک Exchange Server organization، شما باید حداقل یک GC در هر AD site پیاده سازی (deploy) کنید که شامل یک Exchange 2010 server باشد.

!! *تفاوت Single   و Multi-Forest Implementation*
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
* Single Forest
* Multi-forest
* Resource Forest
* Hybrid Forest

شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.


||http://tosinso.com/files/get/4c7790cc-e0ae-4ef5-b69e-006244ceca3b||


!! *Single Forest*
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی  security boundary  است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد. 
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
* 	یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
* 	بدون محدودیت برای Exchange و Outlook functionality

!! *Multi-Forest*
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
* 	سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند. 
* Userها بخشی از forestهای مختلف هستند.
* 	می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند. 
* 	در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
* 	Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship  را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند. 
* 	همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

!! *Resource forest*
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است. 
account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:
* Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
* 	مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند. 
* 	شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
* 	مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید. 
* 	با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود. 
* به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

!! *Hybrid forest*
hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:
* 	هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled. 

* شامل هر دو mailbox یعنی resource و  active است. 
* 	در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
* 	فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

!! *Single vs. Multi-Domain Implementation*
بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد.  این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد. 
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

!! *Single Domain*
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
* 	ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
* 	مدیریت مرکزی 
* 	در مواردی که تنها یک Domain داریم قابل استفاده است.

!! *Single Exchange-Dedicated Domain*
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
* 	سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد. 
* 	مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
* 	در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

!! *Multi-domain*
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
* 	در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود. 
* 	اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود. 
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true

شما نهمین قسمت از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم . 

نویسنده : میلاد اسحاقی
منبع : |جزیره سرویس های شبکه مایکروسافت وب سایت توسینسو::https://microsoft.tosinso.com|
هرگونه نشر و کپی برداری بدون ذکر منبع دارای اشکال اخلاقی می باشد

Single Forest

یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی security boundary است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد.

یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:

  • یک single forest که با Exchange organization مطابقت (match) دارد. ( این ساده ترین و رایج ترین روش است.)
  • بدون محدودیت برای Exchange و Outlook functionality

Multi-Forest

multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:

  • سازمان های شامل multiple Exchange اغلب آدرس های multiple SMTP هستند.
  • Userها بخشی از forestهای مختلف هستند.
  • می تواند شامل سرویس دهندگان متعددی باشد که می توانند همان forest خودشان را مدیریت کنند اما به سایر forest ها دسترسی ندارند.
  • در مواردی که یک شرکت یک شرکت دیگر را خریداری می کند بدون اینکه با Active Directory forest موجود خود را مجتمع کند، رواج دارد.
  • Forestها باید برای اینکه بتوانند بین هم حرکت کنند یک trust relationship را به اشتراک بگذارند ( share کنند). Forestها می توانند از Exchange perspective با استفاده از یک linked mailboxes به هم متصل شوند که البته محدودیت هایی دارد مثلا یک کاربر نمی تواند به راحتی mailbox یک کاربر دیگر که در forest دیگری قرار دارد را باز کند.
  • همسان سازی (Synchronization) اطلاعات در دسترس بودن (availability information) و اطلاعات public folder بین forestها اغلب اوقات خیلی پیچیده است.

Resource forest

یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است.

account forest شامل user accountها و security groupها است. این forest شامل ویژگی های زیر است:

  • Mailboxها به user accountهای غیرفعال attach شده اند و به user accountها در account forest مرتبط (associate) شده اند.
  • مدیریت (Administration) بین account forest سازمان و Exchange forest جداگانه است. در اکثر موارد شما یک resource forest در محیط hosting خود ایجاد می کنید. یک سرویس دهنده که با استفاده از یک one-way trust به account forest متصل است، resource forest را ارائه می دهد. که به شما این اطمینان را می دهد که سرویس دهنده در هیچ حالتی اجازه ای در account forest شما ندارد و فقط می تواند resource forest را مدیریت کند.
  • شما می توانید قابلیت ها و امکانات بیشتر و بهتری از Exchange را با استفاده از یک clean resource forest که به طور کامل توسط Exchange administrator کنتر ل می شود، داشته باشید.
  • مفهوم messaging in a cloud – مثل Microsoft BPOS یا پیاده سازی Exchange روی یک hosting platform – می تواند مثل یک resource forest implementation به نظر بیاید.
  • با جابجایی DL membership یک کاربر به یک forest دیگر سبب کاهش token bloat می شود.
  • به علت اینکه تمام mailboxها بخشی از یک resource forest یکسان هستند، هیچ محدودیتی برای قابلیت های Exchange و Outlook وجود ندارد. ( اگر این شرایط نبود، این پیاده سازی Hybrid بود.)

Hybrid forest

hybrid forest شامل مفهوم resource forest و single forest است – بنابراین hybrid forest نه تنها شامل user accountها و resource mailboxها است ( مثل user-disabled objects و mailbox-enabled object )، همچنین شامل active mailboxها (mailbox-enabled user accountها در جایی که Exchange server در همان forest باشد) نیز هست. این شیوه ی forest دارای ویژگی های زیر است:

  • هر forest شامل یک ترکیب از user accountهای enable و disable است که یا mail enabled هستند یا mailbox enabled.
  • شامل هر دو mailbox یعنی resource و active است.
  • در جاهایی که از یک یا به یک مدل از resource forest مهاجرت شده است یا در سازمانی که برای بعضی از بخش های کار یک resource forest دارد اما همچنان از resource forest به عنوان primary forest برای دیگر بخش های کسب و کار استفاده می کند، رایج است.
  • فقط کاربران همین Exchange organization محدودیتی برای قابلیت های Exchange و Outlook ندارند.

Single vs. Multi-Domain Implementation

بعد از اینکه طراحی forest پایان یافت نوبت به بحث و بررسی domain می رسد. این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد.

در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.

Single Domain

اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:

  • ساده ترین پیاده سازی و در نتیجه راحت ترین مدیریت را دارد.
  • مدیریت مرکزی
  • در مواردی که تنها یک Domain داریم قابل استفاده است.

Single Exchange-Dedicated Domain

در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:

  • سرورهای Exchange در dedicated domain خودشان نگهداری می شوند. اشکال آن در این است که domain اضافه به معنی هزینه های اضافه است که از استقرار و مدیریت دامنه ی اضافی نشئت می گیرد.
  • مدیریت Exchange در یک dedicated domain می تواند به طور کلی وابسته به مدیریت AD یک forest باشد. به این معنا که مدیر (Admin) می تواند تمام کارهای مدیریتی را روی سرورهای Exchange انجام دهد بدون اینکه لازم باشد تا اجازه مدیریت در سایر دامنه های AD را داشته باشد.
  • در جاهایی که برای Exchange خود یک سرویس دهنده داخلی دارید، رایج است.

Multi-domain

در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:

  • در جاهایی که مدیریت Exchange بین بخش ها یا گروه های مختلف مجزا شده است که هر کدام دارای Domain خودشان هستند، استفاده می شود.
  • اگر یک طراحی geographic domain داشته باشید و بخواهید Exchange سرورها را به دامنه مربوط به خودشان اضافه کنید، از این شیوه استفاده می شود.

در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:

Set-ADServerSettings -ViewEntireForest:$true

شما نهمین بخش از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم .


میلاد اسحاقی
میلاد اسحاقی

کارشناس سرویس های شبکه مایکروسافت

میلاد اسحاقی ، مدرس و مشاور شبکه های مبتنی بر مایکروسافت ، مدیر IT خبرگزاری دانشجو ، بیش از 6 سال سابقه تدریس مستمر در موسسات معتبر و مراکز دولتی ، عاشق یادگیری و آموزش ، عاشق مایکروسافت و سرویس های وابسته ، دارای مدارک بین المللی MCSE 2012 در حوزه مایکروسافت

17 شهریور 1392 این مطلب را ارسال کرده

نظرات