همانطور که می دانید Exchange Server یکی از پر کاربرترین سرور ها و سرویس های مایکروسافت است که در شرکت ها و سازمان های بزرگ و کوچک در حال استفاده می باشد . از آنجایی که دوستان زیادی علاقه به آشنایی و راه اندازی تخصصی این سرور دارند،قرار بر این شد که به امید خدا از این به بعد با سری آموزش های گام به گام Exchange Server در خدمت شما بزرگواران باشیم .امیدوارم که این سری آموزشی مورد توجه علاقه مندان قرار گیرد و به کمک دوستان به بالابردن سطح علمی و تخصصی شیکه کاران عزیز کمک کند.
همچنین وظیفه خود می دانم تا از همسرم که در تهیه و تنظیم این سری از مقالات کمک بسیاری به من کرد کمال تشکر را داشته باشم و از شما دوستان گرامی هم بابت وقتی که برای مطالعه و ارائه نظرات خود می گذارید ،سپاسگزاری کنم.خب دیگه مقدمه چینی بسه!! بریم سراغ اصل مطلب ، شروع کار را با سری شماره 1 و 2 که هر دوی آنها تاریخچه و مقدمه ای مرتبط با Exchange Server از ابتدا تا امروز هستند می پردازیم.
Exchange سرور از سال 1996 مورد استفاده بوده است ولی در آغاز با محصولی که امروزه می شناسیم بسیار متفاوت بوده، Exchange سرور تغییرات زیادی یافت و تکامل پیدا کرد تا همگام با تغییرات علم IT پیش برود.در روزهای اول هارد دیسک ها خیلی گران بوده اند بنابراین از وسایل ذخیره سازی Single در Exchange استفاده می شد. خوشبختانه امروزه هارد دیسک ها ارزان شده و تمرکز بر روی تکنولوژی های متفاوت دارای اهمیت بیشتری شده است.در طول سال ها ورژن های جدیدی از Exchange انتشار یافته که در جدول زیر مروری بر تمامی نسخه های Exchange از ابتدا تا ورژن 2010 دارد.
در اوایل سال 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 دارای یک سرویس دایرکتوری مجتمع شده در خود محصول بود و از سرویس دایرکتوری ارائه شده توسط OS مثل AD استفاده نمی کرد. Exchange 4.0,5.0,5.5 از این نسل بودند.
اولین نسخه محصولات Exchange Server بر پایه استاندارد X.400 بود. همچنین این نسخه اولین ورژن شامل ESE Database بود.ESE Database با ساختار ذخیره سازی Single-Instance کار می کرد ، در واقع در این Instance پیام ها فقط یک بار در Database ذخیره می شدند حتی اگر در چندین Mailbox مختلف بودند . در اینجا بود که مایکروسافت فهمید که باید از سیستم بر پایه فایل به سمت سیستم ها بر پایه Database برود و با این کار فضای مورد استفاده دیسک را کاهش و به همین میزان کارایی سیستم را افزایش دهد. امروزه از تغییر سیستم File-based به سیستم Database-based می توان حدود 25% در فضای هارد دیسک خود صرفهجویی کرد. اگرچه در این نسخه مایکروسافت حجم Databaseرا به 16G محدود کرد که بعدها به یک مسئله کلیدی تبدیل شد.جهت توسعه Exchange 4.0 مایکروسافت تکنولوژی هایی را از سایر شرکت ها خریداری کرد که عبارتند از :
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 و قبل از آن است.
این ورژن برای پشتیبانی از سیستم عامل ویندوز 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 هر دو نرم افزار در یک نرم افزار واحد ترکیب شد که به موفقیت سریع آن منجر شد.
در تاریخ 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 + کاملا کنار گذاشته شود.
شکل 1-1
این نسل در واقع نسل دوم به حساب می آید که از Active Directory به عنوان دایرکتوری سرویس استفاده می کرد که باعث شده بود تا عملکرد Exchange به سرویسی بیشتر از ایمیل منتهی شود.
سرور 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 شناخته میشود، ارائه شد.
این ورژن در تاریخ 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 را نشان می‌دهد.
Figure 1-2 Exchange System Manager in Exchange 2003
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 سرور معرفی کرد:
در مقاله بعدی به توضیح و آشنایی با این 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 یکی از کاربردیترین سیستمهای Messaging در بازار است و همچنین محبوبترین سیستم مورد استفاده در سازمانهاست.برای حفظ رقابت و ادامه توسعه فناوری که در Exchange 2007 آغاز شد، Exchange 2010 چندین قابلیت و ویژگی جدید به همراه آورد.کنسول مدیریت Management Console):Exchange 2010) شامل یک جفت کنسول مدیریت است که به شما امکان اجرای وظایف مدیریتی (Administrative Tasks) یا مدیریت پیکربندیهای Exchange (Exchange’s Configuration) را می دهد.
Exchange Management Console : ابزار EMC کنسول اصلی Administrative برای پیکربندی و مدیریت Exchange است که در شکل 1-3 نشان داده شده است.
Figure 1-3 The EMC
در این کنسول مهمترین تنظیمات برای پیکربندی Exchange وجود دارد و به شما امکان تغییر این Setting داده میشود البته اگر شما Permission لازم برای این کار را داشته باشید.EMC شامل بخشهای اصلی زیر است که به شما در مدیریت Exchange کمک می‌کنند:
Figure 1-4 Show EMS command button
دوستان عزیز در ادامه آموزش های بخش های 1و2 (مقدمه و تاریخچه) به سراغ مقاله سوم از سری مقالات آموزشی Exchange server خواهیم رفت و با سرویس ها و قابلیت های این سرور بیشتر آشنا خواهیم شد ، در این سری از مقالات آموزش Exchange ، توضیحات اولیه از این سرور را آغاز خواهیم کرد
یکی دیگر از ابزارهای جدید EMC در Exchange 2010، Exchange Management Shell Command Log است که تمام Shell Commandهایی را که در EMC راه‌‌اندازی کردهاید، ثبت و ضبط میکند.همان طور که در شکل 1-5 نشان داده شده است، شما میتوانید Command Logging را راه اندازی کنید که به شما در مورد Commandهایی که اجرا کرده اید، اطلاعات جزئی خواهد داد. همچنین می توانید Commandها را در یک فایل CSV، Export کنید.
برای دسترسی و مشاهده Exchange Management Command Log روی Objectهایی که در سمت چپ EMC قرار دارند، راست کلیک کرده و از گزینه های ظاهر شده، View Exchange Management Log را انتخاب کنید.
EMC مبتنی بر Task است که مناسب Command-Line shell روی Windows Power Shell با زبان برنامه نویسی است که می تواند راهی که شما توسط آن مدیریت خود را انجام می دادید، آسان کند. از EMC مانند آنچه در شکل 1-6 نشان داده شده است، استفاده کنید. از این طریق شما میتوانید هر کاری که در EMC میتوانستید انجام دهید و به علاوه آن کارهایی که در EMC در دسترس نبود مثل پیکربندی پورت ارتباط POP3 را اجرا کنید.
تمام Adminهای Exchange باید تحت آموزش قرار بگیرند و پایه و اساس EMC و چگونگی ایجاد Batch Script که کار روزانه آنها را ساده می کند، بیاموزند.
اگرچه EMC اساسا توسط Adminها استفاده خواهد شد، هر کاربر Exchange که Power shell برای آنها فعال باشد ( تنظیمات پیشفرض) هم می‌توانند از EMC استفاده کند به شرطی که به یک Workstation که EMC روی آن نصب باشد، دسترسی داشته باشد. Role-Based Access Control )RBAC) مجموعه cmdlet که یک کاربر می تواند ببیند یا اجرا کند را به کسانی که در Roleها به آنها Permission اختصاص داده شده است، محدود می
کند.
با ارائه ECP درواقع Exchange 2010 یک کنسول مدیریتی Web-based (مبتنی بر وب) دارد که می تواند توسط Adminها و enduserها برای اجرای وظایف مدیریتی معمول برای Exchange 2010 استفاده شود. ECP از مدل RBAC برای Permissionدهی استفاده میکند. بناراین شما تنها میتوانید قابلیتهایی که اجازه دسترسی به آنها را دارید، ببینید. توسط آدرس http:////<CASserver>//ECP که یک آدرس URL است یا از طریق Outlook 2010 میتوانید به این پنل دسترسی یابید. ECP در شکل 1-7 نشان داده شده است.
در 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 محصولی کلان است که بسیاری از جنبه های 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های در سترس را نشان می دهد.
می توان در یک نگاه این Role ها را به صورت کلی به ۵ دسته تقسیم کرد:
اگر بخواهیم به طور مختصر شرح حالی از عملکرد هر کدام از این Role ها را برسی کنیم می توانیم بگوییم:
در این شکل هم نمایی دیگر از Role های گفته شده را خواهیم دید
Figure 1-9 Exchange 2010 Enterprise Topology
همانطور که با هر نسخه جدیدی از نرم افزارها، ویژگیها و قابلیتهای نسخه ی قدیمی در آن کنار گذاشته می شود و از آنجایی که تکنولوژی به طور پیوسته در حال پیشرفت و تغییر است، مایکروسافت نیز با رعایت تعادل در مورد Exchange 2010 یک سری قابلیت های جدید اضافه نموده، کارایی های موجود را حفظ کرده و قابلیت های منسوخ شده را حذف نموده است.البته شما می توانید برای نگه داشتن و استفاده از قابلیت های Exchange 2003 و 2007 از یک سرور Legacy کمک بگیرید که این یک گام میانی است.
اگر در حال حاضر از Exchange 2003 یا 2007 استفاده می کنید لازم است که حتما بدانید که در محیط messaging فعلی شما از چه featureهایی استفاده می شود و پروتکل های مورد نیاز applicationها را نیز بشناسید. این امر از شوکه شدن شما زمانی که یک application به علت تغییر به ورژن 2010 از کار بیفتد، جلوگیری می کند.جدول 1-2 لیست ویژگیهایی از Exchange 2003 است که در نسخه 2010 در دسترس نیست و به جای آنها قابلیتهای جدیدی را که در 2010 موجود است را توضیح می دهد.
اگرچه به نظر میرسد که Exchange 2007 خیلی شبیه به Exchange 2010 است اما تفاوت هایی بین این دو نسخه وجود دارد که در جدول 1-3 آمده است.
نصب 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 در یک 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 نشان داده شده است.
تمام کنسولهای مدیریتی 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 مورد نیاز است و دقیقا طبق نیاز خریداری شود. که این انتخاب سبب صرفهجویی در هزینه‌های شرکت خواهد شد.Licenseهای متداول Exchange بر حسب Server یا Client Access License) CALs) خریداری خواهد شد. البته License دیگری تحت عنوان External Connector وجود دارد که به شما این اجازه را می دهد تا تعداد نامحدودی از Userها را به عنوان سرویس گیرنده پشتیبانی کنید و نگران تمام شدن Licenseهای خود نباشید. (که بیشتر برای ارائه سرویس به کاربران اینترنتی استفاده میشود.)
همانند نسخه‌های قبلی 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 آورده شده است.
تفاوت اصلی Standard و Enterprise در تعداد mailboxهای mountشده روی یک سرور است. به علاوه توسط نسخه استاندارد میتوانید DAGs ایجاد کنید اما به یاد داشته باشید که برای استفاده از ویژگی Clustering در DAG به نسخه Enterprise ویندوز سرور 2008 نیاز خواهید داشت.
Exchange سرور 2010 با دو نسخه از CAL ارائه میشود: Standard CAL و Enterprise CAL ، همیشه باید نسخه Standard CAL را خریداری کرد اما اگر به امکانات پیشرفتهتری مانند Voice mail نیاز داشتیم باید نسخه Enterprise را نیز خریداری کنیم.
EMC شامل گزینهای (Option) است که یک گزارش از Organizational Health تولید میکند و نمای کلی از تشکیلات Exchange به شما می‌دهد که شامل اطلاعات License و خلاصهای از سرور و سرویس گیرندگان Exchange نیز می‌باشد. از طریق این اطلاعات شما میتوانید اطمینان حاصل کنید که Edition و License سرور Exchange شما به درستی خریداری شده است. شکل 1-11 یک نمونه از گزارشات را نشان می‌دهد.Organizational Health مجموعه های زیر از Userها را برای محاسبه CAL اسکن می کند:
Figure 1-11 Viewing Organizational Health in EMC
یکی از بزرگترین تغییرات همانند حرکت به سوی 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
WinRM یک پیاده سازی از WS-Management )WSman) را فراهم میکند. این ویژگی امکان مدیریت از راه دور را از طریق گوش دادن به اتصال مدیریت با استفاده از پورت 80 TCP/IP در درجه اول فراهم میکند. به طور پیش فرض ارتباطات فقط زمانی مجوز میگیرند که توسط سرویسدهنده امنیتی Kerberos یا Negotiate رمزنگاری (encrypt) شده باشند.کنترل دسترسی امنیتی مبتنی بر Role یا RABC یکی از ویژگیهای ساخته شده روی Windows PowerShell 2.0 است. که اجازه می‌دهد تا یک role ایجاد شود و سپس برای فیلتر کردن cmdletها و پارامترهایی که برای مشاهده و اجرا در دسترس هستند به کار برود.
در 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 را بیش از حد فشرده کند را کاهش می‌دهد.
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 EMS Process
زمانی که شما EMS را راه‌‌اندازی میکنید، مراحل زیر قبل از اینکه شما بتوانید از EMS استفاده کنید در background انجام میشود:
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 شده که باعث مدیریت راحتتر تمام این محصولات میشود.
برای کسانی که قبلا در 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 در زیر آمده است:
بخش دوم نام 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 بالایی دارد.
در ادامه آموزش های گام به گام سرور Exchange این بار هدف را بر نحوه‌ی جمع آوری اطلاعات، فاز طراحی و نیازسنجی های لازم جهت پیاده سازی سرویس ها و سرورهای Exchange در نظر گرفته ایم. قرار است شما را با MOF، اجرای استراتژیک یک پروژه و فاز Plan، Deliver و Operate که یکی از اصلی ترین پیش نیازهای پروژه های بزرگ شبکه ای است آشنا کنیم. انشاا... در مقالات بعدی شروع به آموزش تخصصی نصب و جزئیات ساختاری سرویس و سرور Exchange خواهیم پرداخت.شاید این بخش از آموزش های گام به گام در وهله اول کمی مدیریتی و با دید کلی باشد.
اما برای اینکه یک سرویس شبکه ای به طور تمام و کمال به مرحله استفاده و پیاده سازی دائم برسد نیاز است تا قبل از نصب فیزیکی سرویس و تنظیمات آن (که غالبا کار مشخص و ثابتی است) تمام زوایای آن بررسی و Plan دقیقی برای آن در نظر گرفته شود تا از پیاده سازی های چند باره و هزینه های سربار جلوگیری به عمل آید. Microsoft Operations Framework ) MOF )سه فاز دارد: Plan، Deliver و Operate. لایه عملیاتی یا پروسه دیگری به نام Manage نیز وجود دارد که در شکل 2-1 نشان داده شده است. اگرچه نام هر فاز بیانگر این است که در هر مرحله چه اتفاقاتی میافتد اما جزئیات و زیرپروسههای زیادی در هر کدام است و زمانی که با هم ترکیب میشوند شکل کامل MOF را تشکیل می دهند.
فاز Plan شامل استراتژی کلی شرکت است. بخش Deliver توسعه و اجرای استراتژیک پروژههاست. فاز Operate شامل نگهداری سیستمهای توسعهیافته است. بخش Manage یک پروسهی همیشگی و متوالی است که بهبود و توسعه را برای هر یک از فازهای عملیاتی راه‌‌اندازی و اجرا میکند.
اگرچه این متن آموزش MOF نیست این بخش فازهای اساسی برای یک Exchange Server 2010 Deployment و جزئیات اضافهی مورد نیاز را بیان میکند. در ادامه تک تک این فازها که مرتبط با deploy کردن Exchange 2010 است مورد بحث قرار خواهد گرفت.
فاز Plan دوگانه است و معمولا با مشارکت صاحبان کسب و کار، مدیران و معماران فنی کامل میشود، این منابع برای هدایت هر پروژهی IT در هر شرکت مورد نیاز است. اولین گام در فاز Plan شامل ارزیابی ظرفیت مدیریت Solution موجود و سپس برنامه ریزی برای نیازها و ظرفیتهای بیشتر است. دومین گام مربوط به چگونگی ایجاد یک استراتژی تکنولوژی و کسب و کار در حیطه IT Solution برای این شرکت است.
فاز Plan را میتوان به خرید یک اتومبیل تشبیه کرد. ابتدا شما تشخیص میدهید که نیاز به خرید یک ماشین جدید دارید زمانی که اتومبیل فعلی شما جوابگوی نیازهای شما نیست. قدم بعدی این است که شما بودجه خود را بررسی کنید و اینکه چه ویژگیها و قابلیتهایی نیاز دارید و نهایتا اینکه چه زمانی میخواهید اتومبیل را خریداری کنید. به همین ترتیب در فاز Plan تصمیمگیرندگان نیاز برای تغییر را تشخیص میدهند و سپس بالاترین سطح کارایی مورد نیاز انتخاب شده و در آخر زمان اجرا و تکمیل پروژه نیز تعیین میگردد. خروجی این فاز شامل IT mission و اطلاعات بودجهای است. در فاز Plan به تعدادی سوال باید پاسخ داده شود که میتوان آنها را به دو بخش business و technical تقسیم کرد.
اگرچه پرسشها برای هر کسب و کار و در طول زمان تغییر خواهد کرد با این حال لیست زیر در شروع این روند به شما کمک خواهد کرد.
در زیر نمونهای از سولات فنی که در مرحله Plan لازم است به آنها پاسخ داده شود، لیست شده است:
تمام این موارد میتواند منجر به افزایش هزینه و عوارض گردد. اگر الزامات و اهداف به خوبی و وضوح تعریف شوند، خواهید توانست از این هزینه‌های بیمورد جلوگیری کرد و امید بیشتری به پروژه داشت.
الزامات کاربردی در طراحی یک محیط تست، یک Plan آزمایشی و در نهایت در تولید deployment استفاده شود. برای حصول اطمینان از کامل بودن این نیازمندیها میتوانید از مشتریان، سهامداران و کاربران نهایی نظرسنجی یا با آنها صحبت کنید.
زمانی که نرمافزار (software) و خدمات (service) جدیدی به کار گرفته میشود، بدون شک تمام کارکنان به آموزشهای اضافی نیاز خواهند داشت. اگر ویژگی یا چالشهای جدیدی به کار گرفته شده است، حتی ممکن است که نیاز به آموزشهای خاصی برای کارمندان باشد تا بفهمند که چگونه این ویژگیها deliver میشود، چگونه کار می‌کنند و در محیط کسب و کار چگونه مدیریت میشوند. برای جلوگیری از مشکلات احتمالی باید تمام کارکنان هر چه زودتر آموزشهای کامل را ببینند. به علاوه بکارگیری کارمندان IT در پروژه‌ها در حالیکه بار کاری آنها سبک نشده باشد، درست نیست.
در بعضی از موارد، پروژهای ممکن است که به منابع بیشتر با مهارتهای خاص نیاز داشته باشد. در خیلی از شرکتها بخش IT حتی کارکنانی ندارد که به طور مرتب در بحث messaging به کار گرفته شوند. که در این صورت به منابع اضافی با مهارتهای بالا نیاز است، اگر لازم باشد که پروژه در مدت کوتاهی به پایان برسد. در غیر این صورت باید به کارکنان فعلی IT زمان بیشتری بدهید تا در حد سرعت و مهارتهایشان کارهای محول شده را تمام کنند.
در آخر مرحله Plan باید یک document تهیه شود که خلاصه اهداف کسب و کار و تکنولوژی و استراتژی برای شرکت در آن نوشته شده باشد. این سند مکتوب باید شامل توجیه کسب و کار، scope (محدوه) پروژه و معیار موفقیت پروژه باشد، این document ممکن است شامل یک چشمانداز کلی از scope پروژه باشد که روی راه‌‌اندازی پروژه تمرکز دارد. این اطلاعات باید در نهایت توسط مدیران فنی و کسب وکار که مسئول ارائه راهحل هستند، امضا شود.
بعد از تعیین و تعریف اهداف استراتژی تکنولوژی کسب و کار برای ایجاد چشمانداز اهداف پروژه، delivery (ارائه) پروژه میتواند آغاز گردد. برای این مرحله روشهای متعددی قابل استفاده است که ممکن است برای هر کسب و کار متفاوت باشد. مهم نیست که از چه روشی استفاده میکنید، تلاشی که شما در این مرحله میکنید اجازه می‌دهد که در آینده مراحل سادهتر و روانتری داشته باشید. به مثال خرید خودرو برمیگردیم.
فاز deliver همان بخشی است که شما اتومبیلی را شناسایی میکنید که نیازهای شما را برآورده میکند، رانندگی با ماشین را امتحان میکنید و خودرو نهایی خود را انتخاب میکنید، و در آخر کارهای تکمیل مدارک برای خرید خودرو را انجام میدهید.به همین ترتیب در فاز deliver، محصولات و روشها انتخاب شدهاند و سپس برای رسیدن به آنچه در مرحله Plan تعیین شده بود، اجرا میشوند. MOF در این فاز شامل 5 مرحله اصلی است ، Envision (پیشبینی)، Project Planning (برنامه ریزی پروژه)، Build (ساخت)، Stabilize (ثبات) و Deploy (استقرار). این مراحل اصلی در فاز Deliver گنجانده شده اند که برای اطمینان از شفافیت این روند، این قدمها به مراحل بیشتری تقسیم میشوند:
بخش اول از فاز Deliver شناسایی اهداف تکنیکی و کسب و کار تعریف شده در فاز Plan است که روی پروژه messaging اعمال (apply) میشود که برای تعیین چشماندازی از پروژه و دامنه (scope) آن است. تکمیل این مرحله با موفقیت از آنچه به نظر میرسد، مشکلتر است. انجام Legworkها در ابتدای کار نه تنها به شما این اطمینان را می‌دهد که به اهداف و نیازمندیهای اکنون و آینده کسب و کار خواهید رسید
بلکه به شما این پشتیبانی را می‌دهد که نیازهایی که برای تکمیل پروژه به آنها نیاز دارید از طریق منابع مناسب فراهم خواهد شد. اساسا این دیدگاه باید با اهداف کوتاهمدت و بلندمدت کسب و کار با توجه به نیازمندیها و تغییرات کسب و کار هماهنگ باشد. از آنجایی که کسب و کارها با هم متفاوتند، هیچ پاسخی از best practice به شما نخواهد گفت که چگونه این قدم (step) را کامل کنید.
بنابراین در اغلب موارد بهترین Plan مطرح کردن لیستی از سوالات فوق الذکر و تلاش برای یافتن پاسخ آنهاست. البته نه به این معنا که به تمام سوالات پاسخ داده شود بلکه سوالاتی که با کسب و کار شما مرتبط است را انتخاب کرده و به آنها پاسخگو باشید. آنچه که مهم است این است که بحث و گفتگو انجام شده و به دنبال جمعآوری نیازمندیها برویم. در طول این فاز شما باید توضیح دهید که این دیدگاه چگونه روی تمام سطوح وظایف کاربران در سازمان تاثیر خواهد گذاشت.
این دیدگاه در ایجاد طراحی و Plan بازاریابی داخلی استفاده خواهد شد. Vision statement به طور خلاصه اهداف پروژه است که به صورت یک شعار جذاب یا چند پاراگراف یا لیستی از اصول ارائه میشود و به تمرکز روی پروژه کمک میکند. اغلب اوقات Vision statement در مرحله Plan به تصویب میرسد و برای درایو (راه‌‌اندازی) بقیه پروژه به کار میرود و یک چشمانداز کلی برای پروژه ایجاد میکند. برای ایجاد یک چشمانداز (Vision) برای یک پروژه، یک روش مفید و کارآمد رجوع به لیست استاندارد مواردی است IT سازمان به طور معمول بر روی بهبود آنها، تمرکز داشته است مانند:
برای اینکه بدانید به کجا می خواهید بروید باید بدانید که کجا هستید. قبل از ایجاد و اجرای طرح لازم است که اطلاعاتی را جمع آوری و مستندسازی کنید. از جمله اینکه هر عنصری در حال حاضر مستقر و deploy شده، چگونه پیکربندی شده و چگونه استفاده می شود؟ در طول ماه ها و سال ها سیستم messaging با توجه به تغییرات دچار تکامل می شود.
Designهای یک پروژه به صورت اسناد در طول پیاده سازی یا زمانی که تغییرات اساسی رخ می دهد ایجاد و نگهداری می شوند. مطالعه و بررسی دقیق این اسناد قبل از شروع به طراحی پروژه جدید messaging بسیار اهمیت دارد. یک history log مربوط به مدیریت تنظیمات و تغییرات باید اطلاعات مربوط به سیستم و سرور messaging، تنظیمات آنتی اسپم و تنظیمات نرم افزارهای third-party را در خود جمع آوری کرده باشد. استفاده از آن کمک بسیاری به پیاده سازی های سرویس های messaging جدید خواهد کرد.
شناسایی چگونه، چه چیزی، چرا، کجا و کی در ابتدای پروسه این اطمینان را می دهد که طراجی نهایی کاربرپسند و راحت خواهد بود. پیدا کردن برنامه های کاربردی و نیازمندی های جدید در طول فاز deploy سبب تاخیر و افزایش هزینه های ناخواسته در پروژه خواهد شد.
مراقبت باید ادامه یابد تا عینا مشاهده گردد که سیستم به خوبی در حال کار کردن است و نیازهای کاربران را به خوبی برطرف می کند. از آنجایی که این مسائل می توانند بار علاقه مندی کاربران را نشان دهند این اطلاعات باید جمع آوری و به دقت شمارش شوند. حتی اگر بازخورد کاربران منفی باشد هنوز هم مهم هستند چرا که ما را در جهت آموزش کاربران یا تغییر تنظیمات خودمان هدایت می کنند. همچنین باید تمامی applicationهایی که وابسته به سیستم ایمیل موجود هستند را شناسایی کنید.
در ادامه بحث Assest از مقاله قبل در این مقاله تمامی قدم های باقی مانده برای برسی کامل و دقیق اجرای استراتژیک یک پروژه و فاز Plan، Deliver و Operate که یکی از اصلی ترین پیش نیازهای پروژه های بزرگ شبکه ای است را مطرح کرده و برسی های مدیریتی و طراحی را در آن به سر انجام می رسانیم تا از مقاله بعدی به صورت دقیق به فاز اجرا و تنطیمات سرور Exchange بپردازیم و به صورت کاربردی تر و عملیاتی تر به برسی این سرور پر کاربرد مشغول شویم !! بعد از شناسایی نرم افزار های وابسته به Mail نوبت می رسد به مراحل بعد که شامل این موارد می شود:
خیلی از شرکت های تجاری تعدادی Application دارند که با سیستم های Messaging آنها ادغام شده است این برنامه ها ممکن است برای مثال یک سیستم مانیتورینگ باشد که email notification را می فرستد یا نرم افزاری که ارتباط با مشتری را مدیریت می کند، باشد مثل CRM.
برای مثال چه نسخه هایی از outlook مستقر شده است؟ آیا clientهای دیگری غیر از مایکروسافت مثلا apple macintosh یا linux based وجود دارد؟ clientها pop3 یا IMAP4 هستند؟ چه deviceهای mobile در شبکه استفاده شده است؟ آیا نیازی به support کردن clientهای اضافی برای بهبود کارایی هست؟
شناسایی موافقتنامه هایی که در حال حاضر در حال اجرا هستند و تعیین چگونگی اجرای آنها.
و تعیین اینکه آیا هر یک از آنها با یک update قابل استفاده هستند یا خیر؟مستند سازی ساختار طراحی شبکه (Network Infrastructure Design)
هرچه تنظیمات شبکه و Utilizationکه می توانید را جمع آوری کنید. این اطلاعات در فهمیدن مسیری که ترافیک کلاینت ها و پیام های ایمیل طی خواهند کرد و اینکه پهنای باند در دسترس برای راه اندازی ترافیک فعلی و ترافیک آینده چقدر خواهد بود به شما کمک خواهد کرد.
Exchange Server شدیدا به اطلاعات AD DS در مورد Domain و forest functional level و تنظیمات site و link وابسته است. زمانی که تنظیمات کنونی را یادداشت می کنید تمام موانع را نیز یادداشت کنید تا جهت بهتر شدن Exchange server آنها را تغییر دهید.
** تمامی اسناد مربوط به تنظیمات Messaging را بروز رسانی کنید تا مطمئن شوید که تمام داده ی مورد نیاز برای تکمیل plan پروژه را در اختیار دارید. *
** تمامی افراد موثر در مدیریت Exchange و تمام سرویس های وابسته را شناسایی کنید. *
مدیریت Exchange بخش های مختلفی را تحت تاثیر قرار می دهد که برای مثال در یک سازمان بزرگ می تواند شامل AD DS، سرویس های امنیتی، storageها، سرور و شبکه شود. اگر افراد یا بخش های متفاوتی این سرویس ها را کنترل می کنند مطمئن شوید که تمام آنها و نیازمندی هایشان را شناسایی کرده اید.
اغلب مشکلات در طول استقرار نیاز به یک تصمیم یا راهنمای اجرایی دارند تا بتوان بر آن موانع غلبه کرد.
بعد از اینکه اطلاعات شناسایی و جمع آوری شد یک چشم انداز (vision) از مجموعه اهداف و دامنه (scope) برای پروژه می توان تولید کرد. نیازمندی های کسب و کار می تواند با سیستم messaging فعلی مقایسه شود تا هرگونه کمبود شناسایی گردد.
با درک چشم انداز پروژه و آنچه در حال حاضر مستقر است، می توانید بررسی و ارزیابی محصولات، تنظیمات و سرویس هایی که برای رسیدن به پروژه نیاز دارید بپردازید. این مرحله شامل ارزیابی ویژگی های جدید Exchange 2010 است و اینکه تشخیص بدهید کدامیک متناسب با نیاز شماست. همچنین زمان این رسیده است که تعیین کنید چه third-partyهایی لازم است و چه تنظیماتی باید تغییر کند تا استقرار Exchange جدید در محیط کاری نیازهای کسب و کار را برطرف کند. ارزیابی شامل یادگیری optionهای در دسترس است که از طریق شرکت در سمینارها، مطالعه اسناد و ملاقات با فروشندگان محقق می گردد. ارزیابی، استراتژی های مهاجرت را ممکن می سازد.
اگر مهاجرت از Exchange 2003 یا 2007 باشد مراحل خاص و نیازمندی هایی لازم است تا پروژه با موفقیت انجام شود. اما اگر مهاجرت کلا از یک محصول messaging دیگر باشد کارهای اضافه ای نیز باید برای آزمایش optionهای مهاجرت صورت گیرد تا هرگونه محدودیت یا امکانات جدید شناسایی شود و برای استفاده از ابزارهای این مهاجرت و تکنیک های جدیدش باید آموزش های لازم صورت گیرد. خیلی از پروژه ها به علت اینکه زمان کافی برای درک گزینه ها و تاکتیک های استقرار، تنظیمات، مهاجرت و عملکرد سیستم messaging صرف نمی شود با شکست مواجه می شوند.
از آنجایی که گنجاندن تمام بخش های مختلف در ارزیابی اهمیت دارد نباید تنها به بحث نرم افزار اکتفا کرد .
بلکه باید تمام مسایل مربوط به سخت افزار سیستم ، تنظیمات شبکه ،سخت افزار ذخیره سازی (Storage) نرم افزار و سرویس آنتی ویروس ، سیستم پیام رسانی یکپارچه (unified messaging) ، تنظیمات mobile ، ابزارهای مهاجرت و نرم افزار بایگانی را نیز مورد بررسی قرار داد و از عملکرد هر یک از آنها با هم اطمینان حاصل کرد. برای اینکه مطمئن شوید این ویژگی ها در محیط کاری شما همانطور که انتظار داشتید کار می کنند نیاز به ایجاد یک proof-of-concept برای استقرار خود دارید. این کار در یک آزمایشگاه جداگانه انجام می پذیرد. جایی که تست ویژگیهای بدون اینکه روی سیستم های تولید تاثیر داشته باشند، انجام می شود. برای انجام مناسب تست در محیط آزمایشگاه باید جزئیات مربوط به محیط واقعی و مربوط به محصول را کاملا شبیه سازی کرد.
به طور سنتی فرضیات در دو فاز می تواند انجام شود .برخی از افراد معتقد هستند که باید بعد از اتمام طراحی فرضیات را اثبات کرد و بعضی دیگر معتقدند که باید ابتدا هر مرحله را تست و اثبات و در آخر طراحی نهایی را پیاده سازی و تست نمود که این کار در یک محیط کاملا آزمایشگاهی و جداگانه انجام می شود.دراین زمان تمام سوالات و مسائل تست می شوند تا ثابت کنند که نه تنها در مفهوم که در واقعیت نیز همان طور کار می کنند. تست و آزمایش باید شامل همه فعالیت های انجام شده توسط کاربران و مدیران باشد. این روش اجازه می دهد تا طیف وسیعی از قابلیت ها مورد آزمایش قرار بگیرند.
تست بارگزاری باید در یک مقیاس کوچک انجام شود تا سخت افزار مورد نیاز در طول اجرای تولید ارزیابی و تعیین گردد. مستندسازی در این آزمایش ها این اطمینان را می دهد که نتایج مورد نظر به دست خواهد آمد. البته پیاده سازی که نمونه ساده از تولیدات شما در آزمایشگاه کافیست. در این مورد کاملا مراقب طراحی محیط تست باشید و با تست ویژگی هایی که برای سازمان شما حساس هستند شبیه سازی را آغاز کنید. سناریوهای تست مهاجرت به محیط کاری شما مربوط هستند اگرچه ممکن است documentهای مربوط به مهاجرت ساده به نظر برسند اما بایستی با دقت و ریزبینی تمام بررسی و پس از اطمینان از عملکرد صحیح آنها انجام شوند. مرحله Proof of Concept در زیر آمده است:
1-Prepare
بررسی featureها در محیط تست بسیار مهم است. این آزمون اجازه می دهد تا موارد مختلفی بررسی شود از جمله: بررسی فرضیات، بررسی عملکرد و ایجاد طراحی دقیق و صحیح برای استقرار. به علاوه فرصت خوبی برای یادگیری و فهم اطلاعات بیشتر در مورد محصول به دست خواهد آمد. جهت آماده شدن برای این کار تمام نرم افزارها، سخت افزارها و تمامی تنظیماتی که برای طراحی مورد استفاده قرار خواهند گرفت را شناسایی و جمع آوری کنید.
2-Deploy Proof Of Concept
پیاده سازی یک محیط تست ایزوله که بسیار زیاد و در حد امکان شبیه محیط کاری مورد نظر محصول است، شرایط را برای کامل شدن آزمون فراهم می کند.
آزمایش در این مرحله باید شامل حالات بالقوه مهاجرت نیز باشد.
3-Test
سناریو آزمون را اجرا کرده و نتایج حاصله را یادداشت کنید. مطمئن شوید که تمامی تغییرات در سناریوی آزمون را یادداشت کرده اید تا ویژگی های جدید یا آنهایی که تغییر کرده اند فراموش نشوند.
4-Review Test Results
بعد از کامل شدن آزمون مسائل و تغییرات بالقوه باید بررسی شوند، دلایل هر نتیجه غیر منظره ای باید ثبت شوند. به عنوان مثال آزمون شکست می خورد به این علت که یک ویژگی یا کارایی طبق انتظار کار نکرده است یا محدودیت هایی برای درست کار کردن آن به وجود آمده است. این بررسی باید تمامی مسئله های بحرانی را دسته بندی کند و سپس هر مسئله بحرانی باید اصلاح و بر اساس این تغییرات طراحی نهایی به دست آید.
این مرحله ای است که شما در آن تمامی بخشها را کنار اطلاعاتی که جمع آوری کرده اید قرار می دهید تا طراحی ایجاد کنید که برای توسعه فرآیند ها مراحل مرتبط مورد استفاده قرار خواهد گرفت. اگر چه ممکن است که این طرح پس از به کار گیری توسط کاربران و با توجه به 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ها تاثیراتی می پذیرند مثل اینکه لازم باشد کلاینت ها به طور دستی دوباره پیکربندی شوند و یا داده های مربوط به مهاجرت به طور دستی تنظیم شوند.
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 خود به آنها نیاز داشته باشید را فراهم کرده است.
Table 2-4 :
افرادی هستند که به طور مستقیم در پروژه حضور ندارند اما لازم است تا گزارش های پروژه و پیشرفت کار به آنها گزارش داده شود، برای مثال حامیان اجرایی و یا مدیر ارشد اجرایی (مدیر عامل)
اجرای 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 مناسب از کاربران گام های اساسی برداشته شود.
در این مرحله استقرار کامل البته در اندازه ای بسیار بزرگ تر از آنچه که در Pilot پیاده سازی شد، انجام می گردد. در طول مدت پروسه ی Pilot جزئیات و مسائل زیادی مورد استفاده قرار گرفت و حال یک Plan با جزئیات بسیار و دقیق ارائه شده و آماده Deploy شدن است.
Plan استقرار شامل یک برنامه اجرایی دقیق و برنامه ریزی برای هر یک از بخش های استقرار است. که شامل استقرار سرور، آموزش کاربران، استقرار نرم افزار و جابجایی و تنظیمات mailboxهاست. در این قدم هدف تکمیل deployment و حرکت به سمت فاز Operate است.
نهایتا کاربران را در مورد پروژه deploy آگاه کنید و قبل از اعمال هر تغییری که روی کاربران تاثیر می گذارد، حتما آنها را از آن تغییر و پیامدهای آن آگاه کنید. آموزش های لازم را برای کاربران ارائه کرده و قبل از همه adminهای خود را آموزش دهید.
هدف نهایی از فازهای Plan و Deliver این است که سرویس نهایتا در فاز Operate اجرا شده و کار کنند. در این فاز، سرویس هایی که طراحی و deliver شده بودند نیاز به نگهداری در سطح بالایی دارند. به طور مثال اگر شما ماشینی خریداری کنید این فاز شبیه این است که شما ماشین را دریافت کرده و هر روز با آن رانندگی خواهید کرد. زمانی که صاحب خودرو شدید باید لاستیک را عوض کنید، روغن خودرو را چک کنید و در صورت نیاز آن را تعویض کنید و مراقبت های دوره ای را همیشه انجام دهید. در مورد پروژه هم در این فاز باید دائما وضعیت را مانیتور کنید تا در صورتی که alertی داده شده سریعا نسبت به رفع مشکل پیش آمده اقدام کنید.
همان طور که 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 است که این اطلاعات در حد امان باید کامل جمع آوری شوند و این اطلاعات باید شامل تمام جنبه ها باشد که عبارتند از:
کنترل کنید که در همه جا از پروتکل TCP/IP استفاده گردد که Internet Protocol مورد استفاده IPv4 یا IPv6 یا هر دو با هم است. IPآدرس ها چگونه به سرورها اختصاص داده شده اند و اینکه subnet ها بر اساس موقعیت قرارگیری از همان IP باشند.
که شامل لینک های LAN و WAN، روتر و ... است.
که شامل اینترنت، شرکت های شرکا و ... است.
که شامل hub-and-spoke، Ring یا Star و point-to-point است.
که بین پهنای باند تضمین شده (guaranteed bandwidth)، پهنای باند موجود و زمان تاخیر برای هر یک از لینک های مشخص تقسیم می شود.
که شامل فایروال هاست که از لینک های فیزیکی یا deviceهای رمزگذاری لینک شبکه محافظت می کنند که سرعت لینک را کاهش می دهد.
که بعدا در Planning Namespace در همین بخش توضیح داده خواهد شد.
که شامل تمام سرورهایی است که در یک شبکه perimeter قرار دارند به ویژه هر سروری که امکان SMTP-relay را فراهم می کند.
در این بخش، در مورد پایه و اساس فنی در سیستم (DNS) بحث شده است. وشامل مطلبی درباره Namespace planning نیست. جنبه های namespace planning و disjoint namespace یا single label domains در بخش “Planning Namespace” بعدا شرح داده خواهد شد.
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 خواهد داشت. )
berlin-dc01.ITPRO.IR. IN A 10.10.0.10
_ldap._tcp.ITPRO.IR. IN SRV 0 100 389 berlin-DC01.ITPRO.IR.
ITPRO.IR MX 10 fresno-ht01.na.ITPRO.IR
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 را می گیرد.
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 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 موارد زیر را داراست:
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 را بفهمند در غیر این صورت ارتباط با مشکل مواجه خواهد شد.
نرم افزارهای 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 به آدرس زیر رجوع کنید:
از آنجایی که Exchange Server 2010 روی Windows Server 2008 یا R2 راه اندازی می شود ممکن است که شما فکر کنید که به طور اتوماتیک از IPv6 پشتیبانی می کند. با این حال شما باید زمانی که دارید برای IPv6 و Exchange 2010 برنامه ریزی می کنید به چند مسئله توجه کنید. Exchange Server roleهای زیر زمانی که از IPv6 استفاده می کنید ممکن است مسائلی را به وجود بیاورند:
ویژگی هایی مثل IP Allow List Providers یا Sender reputation از IPv6 پشتیبانی نمی کنند چرا که به IP address استاتیک نیاز دارند.
هیچ یک از ویژگی ها از IPv6 پشتیبانی نمی کنند و برای درست کار کردن به IPv4 نیاز دارند.
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.
حتی اگر شما نتوانید یک IPv6 DAG IP address تعریف کنید باز هم از IPv6 پشتیبانی می شود. زمانی که IP آدرسهای استاتیک IPv4 برای یک DAG اختصاص داده می شوند، آن DAG فقط از IPv4 استفاده می کند. زمانی که static IPv4 تعیین نشود، Exchange از DHCP از دستیابی به IPv4 استفاده می کند و همچنین منابع مربوط به IPv6 را نیز create می کند.
Exchange Server از Windows network stack برای اجرای هر request استفاده می کند. هر درخواست به دو عامل بستگی دارد:
اول 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) گرفته خواهد شد.
یکی دیگر از جنبه های مهمی که هنگام 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های زیر را در نظر گرفته و از آنها استفاده کنید:
توجه داشته باشید که dataی کلاینت را از سرور Exchange یا سرور mail ( زمانی که از یک سیستم non-Exchange استفاده می کنید.) به مدت حداقل دو روز ( در اوج ساعات کاری نه در روزهای آخر هفته) جمع آوری کنید تا بتوانید به یک نمودار جامع از performance data دست یابید.بعد از اینکه نتایج را جمع کردید، می توانید آنها را با جدول 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) خواهد آمد.
ارتباط با اینترنت یا شبکه های خارجی (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 قرار می گیرند تا دسترسی به اینترنت را پشتیبانی کنند عبارتند از:
نکته:
برای کاهش سطح 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 مایکروسافت استفاده نمی کنید، مسائل کلیدی زیر را برای انتخاب فایروالی با بالاترین استاندارد امنیتی در نظر بگیرید:
به عنوان بهترین روش، اگر می خواهید که دسترسی اینترنتی به سرور Exchangeتان داشته باشید، همیشه از یک reverse proxy یا application-layer firewall استفاده کنید. اگرچه برخی از شرکت ها، مخصوصا در بخش های کوچک یا متوسط، هیچ نوع امنیتی بین اینترنت و سرورهایشان پیاده سازی نمی کنند. اگر شما نیز یک فایروال application-layer را پیاده سازی نکرده اید، توصیه های زیر را در نظر بگیرید:
این شرایط برای شما حداقل امنیت را فراهم می کند اما هنوز ممکن است که بخشی از داده های کاربران شما روی اینترنت انتشار پیدا کند. با این حال از هیچ بهتر است.
لیست زیر راه هایی برای پیشگیری از pitfall های (تله-مشکلات) بالقوه در سمت توپولوژی شبکه ارائه می کند. اول باید هر مشکلی که وجود دارد را حل کرد تا بعد بتوان Exchange server 2010 را روی location مورد نظر نصب کرد.
شما هشتمین بخش از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم .
اکتیو دایرکتوری سرویس مجتمع و توزیع شده ای است که به همراه سیستم عامل ویندوز سرور ارائه می شود. بسیاری از applicationها از جمله Exchange server 2010 با AD مجتمع (integrate) شده اند. این عامل سبب ایجاد یک لینک بین user accountها و applicationها می شود که نتیجه آن فعال شدن یک single sign-in برای تمام appها می باشد. به علاوه قابلیت replication اکتیو دایرکتوی موجب فعال سازی distributed application برای replicate کردن داده های application-configuration می شود.
دیتابیس 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 تشکیل شده است.
قبل از اینکه Exchange Server 2010 بتواند اطلاعات را در AD ذخیره کند، لازم است تا پارتیشن schema اصلاح (modify) شود به صورتی که objectهای مرتبط با Exchange ( مثل اطلاعات مربوط به connector یا mailbox ) و attributeها ( مثل Exchange Mailbox server یا user object ) در یک Active Directory schema تعریف شود.
schema partition یک طرح کلی از تمام objectهای AD و attributeهای آنها را نگهداری می کند. این پارتیشن دارای دو نوع اطلاعات است:
از آنجایی که Exchange به Active Directory وابسته است، هر ورژن Exchange ورژن های مختلفی از schema را پیاده سازی می کند. برای شناسایی ورژن schema فعلی Exchange ویژگی ms-Exchange-Schema-Version-Pt اضافه شده است. با کمک این attribute می توانید با نگاه کردن به rangeUpper با توجه به جدول 3-2 ورژن Exchange را تشخیص دهید.
در شکل 3-3 می توانید ورژن Exchange Schema را در Exchange سرور 2010 یا 2007 که SP2 است و در حال حاضر روی سیستم نصب است را ببینید.
به علاوه با استفاده از ویژگی 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 باشید.
این پارتیشن اطلاعات مرتبط با 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 این موضوع نشان داده شده است.
این پارتیشن 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 در دسترسند را شرح می دهد.
البته تنها سرورهای DNS که در DC راه اندازی (run) شده اند می توانند به application partitionها دسترسی داشته باشند، بنابراین تمام DNS zoneهایی که در این پارتیشن ذخیره شده اند Active Directory–integrated هستند.
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 وجود دارد:
Set-ADServerSettings –PreferredServer <DC FQDN>
در کنار 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 در دسترس نیست.
برای Exchange Server 2010 ، AD و Domainها باید چندین نیازمندی را داشته باشند. زمان ارزیابی برای طراحی current AD باید نکات زیر را در نظر بگیرید:
برای اجرا و پیاده سازی forest روش های زیر وجود دارد:
شکل 3-6 انواع forest را نشان می دهد و اینکه در چه forestی user account mailboxها و Exchange serverها در دسترسند.
یک AD forest مجموعه ای از یک یا چندین domain tree است که common configuration و schema information را با هم share کرده اند. یک forest یک مرز امنیتی security boundary است، به طور پیش فرض هیچ accountی از بیرون از forest نمی تواند اصول امنیتی برای دستیابی به اطلاعات داخل forest را بیابد.
یک طراحی Active Directory forest کاراکترهای زیر را فراهم می کند:
multi-forest یا cross-forest از حد اقل دو loosely connected forest تشکیل شده است که به صورت مستقل از هم عمل می کنند اما تا حدودی به هم متصلند. این forest شامل ویژگی های زیر است:
یک resource forest شامل یک یا چندین account forest و یک Exchange forest است که شامل تمام سرورهای Exchange، mailboxeها و distribution listها است.
account forest شامل user accountها و security groupها است. این 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 پایان یافت نوبت به بحث و بررسی domain می رسد. این بحث تنها زمانی لازم است که شما یک محیط multi-domain داشته باشید و Exchange implementation شما بخشی از یک single forest design باشد.
در این قبیل environment، شما نیاز دارید تا تصمیم بگیرید که آیا می خواهید تمام سرورهای Exchange را روی یک domain (single)، یا روی Exchange-dedicated domain نصب کنید یا Exchange را روی جایی که user accountهای شما ذخیره شده اند، قرار دهید. در پیاده سازی به روش single forest باید روش های زیر را برای Domain در نظر بگیرید.
اگر Exchange serverها و userها در یک domain باشند این روش single domain است. این روش دارای ویژگی های زیر است:
در یک multi-domain forest وقتی که یک دامنه (domain) فقط برای میزبانی (hosting) سرورهای Exchange و مدیریت distribution lists ایجاد می شود، می توان یک single Exchange-dedicated domain را یافت. که دارای خصوصیات زیر است:
در این روش Exchange serverها مستقیما در همان domain هستند که userهایشان در آن هستند، بنابراین Exchange سرورها در بین domainهای مختلف هستند. این شیوه دارای خصوصیات زیر است:
در یک محیط کاری multi-domain باید مطمئن شوید که در EMC و EMS محدوده (scope) درست را پیکربندی کرده اید. Cmdlet زیر یک forest-wide scope را پیکربندی (configure) می کند:
Set-ADServerSettings -ViewEntireForest:$true
شما نهمین بخش از سری آموزش های گام به گام و طبقه بندی شده Exchange server 2010 را با ما همراه بودین ، از وقت و حوصله شما ممنونیم .