به گزارش خبر دپارتمان فناوری اطلاعات گروه عظام، در راستای مسئولیت اجتماعی خود در زمینه نشر دانش، تصمیم به انتشار آموزش Exchange 2019 به عنوان یکی از برترین ایمیل سرورهای دنیا، گرفته است. قسمت دوم از این آموزش تقدیم شما مخاطبین عزیز می گردد:
پیکربندی دیتابیس در (EAC (Exchange Admin Center:
Server -----> Databases TAB
در این قسمت می توان با کلیک بر روی + یک دیتابیس جدید ایجاد کرد و نیز با کلیک بر روی ... یک دیتابیس را Mount یا Dismount (فعال و غیر فعال) نمود. همچنین در این قسمت با کلیک بر روی آیکن قلم، می توان یک دیتابیس، را Edit کرد. پنجره Edit یک دیتابیس شامل قسمت های زیر می باشد:
- General TAB: در این قسمت در باکس Name، می توان یک دیتابیس را Rename کرد و اطلاعاتی از قبیل تاریخ آخرین Backup، وضعیت دیتابیس و ... را کسب نمود.
- Maintenance TAB: در این قسمت، در باکس Journal recipient، با تعیین یک Mailbox، یک کپی از تمامی ایمیل های ورودی و خروجی کاربرانی که بر روی این دیتابیس دارای Mailbox هستند، در Mailbox تعیین شده، قرار می گیرد.
فرآیند Database Maintenance در Exchange به صورت کاملا" اتوماتیک صورت می گیرد. Exchange در زمینه Maintenance دو نوع فعالیت انجام می دهد:
الف- (Online Maintenance (OLM
ب- (Online Defragmentation (OLD
OLM بصورت پیش فرض ساعت 1 بامداد هر روز آغاز می شود در صورتیکه OLD پیوسته و مستمر است. فعالیت های زیر به صورت کاملا اتوماتیک توسط OLM و OLD انجام می پذیرد:
- پاکسازی آیتم ها و Mailbox های Delete شده از دیتابیس
- متراکم سازی فضای دیتابیس
- Defrag نمودن دیتابیس
در این قسمت اگر چک مارک (Enable background database maintenance (24*7 ESE Scanning زده شود (که به صورت Default وجود دارد)، فعالیت های Maintenance به صورت مداوم و پیوسته انجام می شود و اگر این چک مارک برداشته شود، فعالیت های Maintenance تنها در زمان های تعیین شده در قسمت Maintenance Schedule انجام خواهد یافت. با استفاده از دکمه Customize می توان ساعات مورد نظر Maintenance را نیز تعیین کرد.
زدن چک مارک Don’t mount this database at startup، سبب می شود که پس از Restart شدن سرویس Information Store، این دیتابیسMount نشود. استفاده از این گزینه زمانی صورت می گیرد که بخواهیم زمان در دسترس بودن یک دیتابیس، تنها توسط Exchange Administrator تعیین شود
از گزینه This database can be overwritten by a restore زمانی استفاده می شود که بخواهیم یک فایل دیتابیس را از Backup آن، Restore کنیم. تلاش برای Restore نمودن یک دیتابیس بدون زدن این چک مارک، سبب بروز خطا در فرآیند Restore خواهد شد.
همانگونه که می دانیم، هر Transaction Log File، بعد از رسیدن به سایز 1 MB، Rename می شود و سپس یک Transaction Log File جدید ایجاد می گردد. با ادامه این روند، تعداد Transaction Log File هایی که به سایز 1 MB رسیده اند، افزایش می یابد و فضای دیسک سخت را بیش از پیش اشغال می نمایند. برای پاکسازی Transaction Log File هایی که به سایز 1 MB رسیده اند و تعداد آنها در حال افزایش است، دو راهکار وجود دارد:
- پس از انجام یک Full Backup و یا Incremental Backup، این فایل ها به صورت اتوماتیک پاکسازی خواهند شد.
- با زدن چک مارک Enable Circular logging، تنها چهار Transaction Log File ایجاد می شود. هنگامی که Transaction Log File چهارم به سایز 1 MB می رسد، چرخه به Transaction Log File اول باز می گردد و این فایل Overwrite می گردد. هنگامی که این فایل نیز به حداکثر حجم خود رسید، Transaction Log File دوم Overwrite خواهد شد و چرخه به همین ترتیب ادامه می یابد و بدین ترتیب هیچگاه تعداد Transaction log File ها از چهار فایل متجاوز نخواهد شد.
از این قابلیت باید زمانی استفاده شود که ظرفیت ذخیره سازی، دارای محدودیت جدی باشد. توصیه مایکروسافت، استفاده نکردن از این قابلیت، در زمانی که بخواهیم از سرویس Volume Shadow Copy برای انجام عملیات Third-Party Backup and Recovery استفاده کنیم، می باشد. در صورتیکه Circular Logging، فعال (Enable) شود:
- تنها عملیات Recovery از نوع Point in Time میسر خواهد بود
- عملیات Backup از نوع Differential و Incremental امکان پذیر نخواهد بود
- هنگامی که عملیات Backup یا Recovery انجام می شود، Restore نمودن دیتابیس های جداگانه امکان پذیر نخواهد بود.
- Limits TAB:
- (Issue a warning at (GB: در این قسمت می توان تعیین نمود در صورتی که حجم هر Mailbox قرار گرفته بر روی این دیتابیس، به عدد وارد شده در این قسمت رسید، یک ایمیل هشدار برای آن کاربر ارسال گردد.
- (Prohibit Send at (GB: در این قسمت می توان تعیین کرد در صورتیکه حجم هر Mailbox قرار گرفته بر روی این دیتابیس به عدد وارد شده در این قسمت رسید، آن کاربر قادر به ارسال ایمیل نباشد (اما دریافت ایمیل همچنان ادامه خواهد داشت)
- (Prohibit Send and receive at (GB: در این قسمت می توان تعیین نمود در صورتیکه حجم هر Mailbox قرار گرفته بر روی این دیتابیس، به عدد وارد شده در این قسمت رسید، آن کاربر قادر به ارسال و نیز دریافت ایمیل نباشد.
- (Keep deleted items for (days: در این قسمت می توان تعیین نمود که Exchange، آیتم هایی را که از فولدر Deleted Items نیز Delete شده اند و یا از سایر فولدر ها Hard Delete (یعنی SHIFT+Delete) شده اند، تا چند روز نگاه داری نماید (بصورت Default، 14 روز می باشد). برای Recover نمودن این آیتم ها در Outlook، در Folder TAB، قسمت Clean Up، بر روی Recover Deleted Items کلیک می کنیم.
- (Keep deleted mailboxes for (days: در این قسمت می توان تعیین نمود که Exchange یک Mailbox را که Delete شده است، قبل از اینکه به صورت همیشگی پاکسازی نماید، تا چند روز نگاهداری کند. (بصورت Default، 30 روز می باشد)
برای Recover نمودن یک Mailbox که Delete شده است، قبل از Purge شدن آن (پاکسازی به صورت همیشگی)، باید در EAC، قسمت recipients، در Mailboxes TAB، بر روی ... کلیک نمود و گزینه Connect a mailbox را انتخاب نمود. آنگاه لیستی از Mailbox های Disconnect شده ظاهر می شود. سپس Mailbox مورد را انتخاب می کنیم و بر روی Connect کلیک می کنیم. در مرحله بعد، لیستی از User Account هایی که Mail-Enabled نیستند، ظاهر می شود و از این لیست، کاربر مورد نظر را انتخاب می کنیم. بدین ترتیب، Exchange، آن Mailbox را که Delete شده است، به کاربر انتخاب شده Connect خواهد نمود.
- اگر چک مارک Don’t Permanently delete items until the database is backed up، زده شود، هیچ Mailbox یا آیتمی، Purge نمی شود (بصورت همیشگی Delete نمی شود) تا هنگامی که از آن دیتابیس، Backup گرفته شود. بدین ترتیب اطمینان حاصل می شود که در صورت لزوم، یک کپی از Mailbox یا آیتم Delete شده، از Backup گرفته شده، قابل Recovery است.
- Client Settings TAB: در این قسمت تعیین می شود که Outlook هایی که به Mailbox های قرار گرفته بر روی این دیتابیس Connect می شوند، کدام (Offline Address Book (OAB را Download نمایند.
نکته: با Remove کردن یک Database، فایل .edb آن Remove نمی شود و باید بصورت Manually، از روی سرور Delete شود.
انتقال یک یا چند Mailbox از یک دیتابیس به دیتابیس دیگر در EAC:
Recipients TAB -----> mailboxes TAB
کاربر یا کاربران مورد نظر را انتخاب می کنیم، آنگاه در Details Pane، گزینه Move Mailbox To another database را انتخاب می کنیم. سپس در پنجره new local mailbox move، قسمت New migration batch name، یک نام برای عملیات انتقال تعیین می کنیم. در قسمت Archive تعیین می کنیم که تنها Mailbox اصلی و یا تنها Archive Mailbox و یا هر دو، به دیتابیس مقصد انتقال پیدا کنند. در باکس Target database، دیتابیس مقصد برای Mailbox اصلی را تعیین می کنیم و در باکس Target archive database، دیتابیس مقصد برای Archive Mailbox را (در صورت وجود) انتخاب می کنیم. در مرحله بعدی، گزینه های Default را تغییری نمی دهیم و بر روی new کلیک می کنیم.
(Meta Cache Database (MCDB و Dynamic Database Cache
همانگونه که پیشتر ذکر شد، در Exchange 2019، بر خلاف نسخ پیشین، تنها یک Server Role وجود دارد (Mailbox Server Role) و Client Access Role به صورت یک سرویس، Client Access Service در سرور Mailbox اجرا می گردد.
Client Access Service به عنوان حد واسط Connection ها با سرور Mailbox عمل می کند. این Connection ها می توانند از نوع:
Microsoft Office Outlook
Outlook On Web
Mobile Device
POP/IMAP SMTP
باشند. سرویس Client Access، عملیات Authentication، Redirection و Proxy را هنگامی که یک Request به سمت سرور Mailbox ارسال می گردد، انجام می دهد.
سرویس دیگری که پیش از در سرور Client Access Role قرار داشت و اکنون در سرور Mailbox اجرا می شود، سرویس Front End Transport Service است. این سرویس، پروتکل های ارتباطی و فیلترینگ فرستنده و گیرنده را ارائه می کند و همچنین تعیین می کند که در دسترس ترین سرور Mailbox برای ارتباط و ارسال درخواست، کدام سرور می باشد.
با توجه به آنچه ذکر شد، بطور کلی می توان گفت سرویس Client Access، فضای نام واحد، احراز هویت و امنیت را ارائه می کند. درخواست ها را به سرور Mailbox درست هدایت می کند و عنوان حد واسط میان Client و سرور Mailbox عمل می کند و سرویس Front End Transport، عملیات Protocol Filtering، محافظت شبکه و نیز یافتن Mailbox را انجام می دهد.
سرور Mailbox، میزبانی Mailbox ها و نیز دیتابیس ها با قابلیت Database Availability Group (به منظور High Availability) را بر عهده دارد و نیز ارتباطات OWA، ActiveSync و Outlook Anywhere را اداره می کند.
در یک محیط، Exchange 2019 به همراه Exchange 2010 نمی تواند وجود داشته باشد. در چنین محیطی، همراه با Exchange 2019، سرور Exchange 2013 که دارای CU21 یا بالاتر باشد، می تواند وجود داشته باشد.
نکته: می توان Exchange 2019 را در یک محیط موجود از Exchange 2013 یا Exchange 2016 نصب کرد و سپس تمامی Mailbox ها را بر روی سرور جدید، Move کرد.
زمانی که Exchange 2019 با Exchange 2013 یا exchange 2016 به صورت همزمان وجود دارند، زمان همزیستی یا Coexistence نامیده می شود. البته در مورد Exchange 2013، باید CU21 و در مورد Exchange 2016 باید CU11 بر روی آن نصب شده باشد.
نکته: به فرآیند انتقال Mailbox ها در یک محیط همزیست، Transitioning گفته می شود. این فرآیند Upgrade نیست.
