نحوه ی پاک و حذف کردن فایل های لاگ در Exchange 2013

در محیط Exchange 2013  شاید تعجب کرده باشید، که چرا Drive C یا پارتیشنی که Exchange  را نصب کرده اید به سرعت پر می شود.

این ناشی از میزان لاگ های Exchange 2013 به صورت پیش فرض است.

از نسخه Exchange 2013 CU6 ، فایل هایی با پسوند .elt ساخته می شود، دراین نسخه فایل هایی با حجم 50MB با حداکثر تعداد 100 فایل  ایجاد خواهد شد، که برای کسب و کار های کوچک ایده آل نیست.

از دیگر Feature ها که فایل های log  هفتگی و روزانه ایجاد می کند Diagnostic logs (Health explorer) است، که می تواند فایل هایی بیش از 5 گیگ در هفته یا ماه ایجاد کند، که با توجه به محدودیت سخت افزاری ممکن است به این حجم از فضا نیاز داشته باشید.

از دیگر عوامل می توان به لاگ های IIS  اشاره نمود ، این سرویس می تواند فایل هایی با اندازه 1 بیت تا بیش از 500MB  ایجاد نماید.

در پایان، لاگ فایل هایی که می توانند مقداری از فضای شما را پر نمایند لاگ های HTTP Proxy  هستند، این سرویس لاگ فایل هایی به صورت ساعتی از 4MB به بالا ایجاد می کند.

در این مقاله توضیح خواهیم داد این  Logها را چگونه مدیریت نمایید، و در پایان یک اسکریپت PowerShell  را معرفی خواهیم نمود که به صورت خودکار لاگ فایل ها را حذف خواهد کرد.

 

 

Diagnostic Logs:

Health Manager اطلاعاتی در مورد سلامتی سیستم جمع آوری می کند، که اطلاعت خوبی هم به شما ارائه می کند ولی اگر با محدودیت فضا مواجه هستید یا مثلا درایور شما دارای محدودیت 80GB می باشد و در چند روز آینده پر می شود، شما می توانید این ویژگی را غیرفعال نمایید.

Service.msc  را باز نمایید.

سرویس Microsoft Exchange Health Manager Service را پیدا نمایید، سپس دابل کلیک و از بخش startup گزینه disabled  را انتخاب نمایید، اگر سرویس در حالت Running  است آن را Stop  نمایید.

سرویس Microsoft Exchange Diagnostics Service را مانند مرحله بالا disable و stop  نمایید.

در مرحله بعد Task Scheduler را باز کنید.

مسیر زیر را دنبال نمایید.

Microsoft -> Windows -> PLA

دو task  ، همانند تصویر بالا مشاهده خواهید کرد، اول آنها رو Stop  کنید و سپس disable نمایید، در مرحله بعد باید لاگ فایل های که توسط Diagnostics ساخته شده اند را پاک نمایید.

 

به مسیر زیر بروید:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostic

در این مسیر دو فولدر با نام های DailyPerformanceLog و PerformanceLogsToBeProcessed مشاهده خواهید کرد، شما می توانید تمامی لاگ فایل های موجود در این دو فولدر را پاک نمایید.

 

:ETL Files

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

به مسیر زیر بروید:

C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces

مطابق شکل بالا، log فایل های زیادی وجود دارند، شما می توانید همه را انتخاب و بدون مشکل حذف نمایید، با این کار حدود چند گیگ از فضای شما خالی می شود.

در فولدرDiagnostics  یکسری فولدر دیگر برای لاگ ها وجود دارد، مسیر زیر را دنبال نمایید.

C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs

 

مشابه بالا، فایل های Log زیادی در این مسیر وجود دارد که می توانید همه را پاک نمایید.

تغییر در :Registry

شما می توانید مقدار پیش فرض 100 فایل لاگ را به مقدار  دلخواهتان در رجیستری تغییر بدید.

  • Key: MaxTraceFileCount
  • Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\16.0\Search\Diagnostics\Tracing

IIS Log Files:

لاگ فایل های IIS به صورت پیش فرض در مسیر C:\inetpub نوشته می شوند، شما همچنین می توانید این فولدر را به یک درایو دیگر انتقال دهید.

این فایل ها می تواند بالای 200MB از فضای شما را اشغال نماید، برای پاک کردن آنها به مسیر زیر بروید:

C:\inetpub\logs\LogFiles

در این فولدر شما دو فولدر دیگر با نام W3SVC1  و W3SVC2  مشاهده می کنید، فایل های log  در این دو فولدر را هم می توانید پاک نمایید.

همچنین در مسیر زیر دو فولدر با نام های بالا نیز وجود دارند ، همانند بالا می توانید فایل های log  در این دو فولدر را هم پاک نمایید.

C:\Program Files\Microsoft\Exchange Server\V15\Logging\RpcHttp

HTTP Proxy Logs

آخرین مسیری که شما می توانید لاگ فایل ها را مشاهده نمایید مسیر زیر می باشد:

C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy

در هر یک از فولدرهای مسیر بالا log  فایل هایی تا سایز 10MB ساخته می شود که می توانید همه را پاک نمایید.

 

 

 

تبریک

شما اکنون توانستید چند گیگ از فضای هارد خود را آزاد نمایید.

PowerShell Script:

همچنین می توانید از اسکریپت زیر در Task Scheduler برای پاک کردن لاگ ها به صورت دوره ای استفاده نمایید.

 

آشنایی با پروتکل احراز هویت DMARC ایمیل

(DMARC (Domain-based Message Authentication, Reporting & Conformance آخرین و پیشرفته ترین پروتکل احراز هویت می باشد. اما مانند SPF و DKIM گاهی اوقات به درستی قابل درک نمی باشد.

DMARC تضمین می کند که ایمیل های قانونی به درستی در برابر استانداردهای DKIM و SPF تایید شده اند و فعالیت های جعلی از دامنه های تحت کنترل سازمان (دامنه های ارسال فعال، دامنه های ارسال نشده و دامنه های ثبت شده دفاع می کنند) مسدود شده است. دو مقوله اصلی DMARC، Alignment و Reporting هستند.

ویژگی DMARC Alignment از جعل کردن آدرس Header From جلوگیری می کند.

  • تطبیق نام دامنه در Header From با Envelope From در طی بررسی SPF
  • تطبیق نام دامنه در Header From با نام دامنه در امضای DKIM

 

نحوه کار DMARC:

پروتکل DMARC

برای پاس شدن DMARC، یک پیغام باید احراز هویت SPF و SPF Alignment و/یا احراز هویت DKIM و DKIM Alignment را پاس کند، یک پیغام در احراز هویت DMARC رد خواهد شد اگر در هر دو (1) SPF  یا SPF Alignment و (2)   DKIM یا DKIM Alignment رد شود.

DMARC به فرستنده ها اجازه می دهد تا به ارائه دهندگان ایمیل در مورد چگونگی برخورد با ایمیل های ناخواسته از طریق DMARC Policy کمک کند، تا هر گونه حدس و گمان در نحوه برخورد با ایمیل هایی که احراز هویت DKIM آنها Fail  شده از بین برود، فرستنده ها می توانند:

  • نظارت بر همه ایمیل ها برای درک اکوسیستم احراز هویت ایمیل خود و اطمینان از اینکه ایمیل های قانونی به درستی تایید می شوند
  • قرنطینه پیغام هایی که در احراز هویت DMARC رد شده اند ( انتقال به فولدر Spam )
  • Reject کردن پیغام هایی که در احراز هویت DMARC رد شده اند.

 

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

DMARC اولین و تنها تکنولوژی است که می تواند از آدرسHeader From  که کاربران در ایمیل خود می بیند محافظت نمایند، این کار نه تنها به محافظت مشتریان و سازمان کمک می کند بلکه مجرمان سایبری را دلسرد می کند چون کمتر به سراغ سازمانی که دارای رکورد DMARC است می روند.

آشنایی با پروتکل احراز هویت DKIM ایمیل

(DomainKeys Identified Mail (DKIM پیچیده ترین پروتکل تصدیق ایمیل می باشد، این مقاله به صورت اختصاصی به معرفی پروتکل DKIM خواهیم پرداخت. با ما همراه باشید:

(DomainKeys Identified Mail (DKIM یک پروتکل است که به سازمان ها اجازه می دهد تا انتقال پیام را به گونه ای که توسط ارائه دهندگان ایمیل قابل تایید باشد، انجام دهند. این تاییدیه توسط احراز هویت رمزنگاری شده (Cryptographic authentication) و از طریق کلید های Public  و Private  انجام می پذیرد.

DKIM  کمی پیچیده می باشد، در ادامه سعی می کنیم، به زبانی ساده آن را برای شما شرح دهیم.

 

گام اول: شناسایی عناصر یک پیغام برای Sign در DKIM

یک فرستنده ایمیل ابتدا باید تصمیم بگیرد که کدام Elements های یک ایمیل را می خواهد در فرایند Sign  قرار دهد، آن ها باید تصمیم بگیرند که کل پیام (Header,Body) یا فقط یک یا چند فیلد خاص در هدر ایمیل در جریان این فرایند رمزنگاری قرار بگیرد.، Element هایی که قرار است در Sign DKIM  قرار بگیرند نباید در حین انتقال پیام تغییر کنند، در غیر اینصورت احراز هویت DKIM رد یا Fail  می شود.

برای مثال، اگر یک ایمیل از Yahoo  به Gmail   forward شود، یاهو یک متن در بالای ایمیل مانند (forward By yahoo mail)  اضافه می کند و Body  ایمیل دچار تغییر می شود، اگر Body  جز Element  های امضا شده در فرایند DKIM  باشد، احراز هویت در ایمیل Forward  شده Fail  خواهد شد.

با این حال، اگر تنها یک Element از Header مانند فیلد From در فرایند امضای DKIM قرار گرفته باشد، و ایمیل از Yahoo به Gmail  forward شود، احراز هویت DKIM  تایید می شود، زیرا آن بخشی از ایمیل که تغییر کرده است در فرایند امضای DKIM  قرار نگرفته بوده است.

گام دوم: فرایند رمزنگاری

فرستنده باید یک سری تنظمیات بر روی Platform ایمیل خود انجام دهد، که به صورت خودکار یک Hash از Element هایی که قرار است در فرایند Sign قرار بگیرند ساخته شود. فرایند Hash، متن را تبدیل به یک رشته متنی منحصر بفرد می کند.

<From: Ehsan Ataei <IT@PardisMail.com

Subject: Testing

:Maps to the following unique hash string

3303baf8986f910720abcfa607d81f53

قبل از ارسال ایمیل، رشته متنی Hash  شده با استفاده از Private Key  رمزنگاری می شود، کلید خصوصی از ترکیب نام دامنه و Selector (هر اسمی امکان پذیر می باشد، بیشتر بر اساس نوع کاربری ایمیل انتخاب می شود) ساخته می شود، که به شما این قابلیت را می دهد که چندین کلید خصوصی قانونی برای یک دامنه داشته باشید( که برای مدیریت ایمیل و اهداف امنیتی مهم می باشد)، و فقط فرستنده به کلید خصوصی دسترسی دارد. بعد از کامل شدن فرایند رمزنگاری ایمیل ارسال می شود.

 

گام سوم: تایید DKIM Signature با کلید عمومی:

Mail سرور گیرنده بعد از دریافت ایمیل، متوجه می شود که ایمیل دارای امضای DKIM  می باشد، که نشان دهنده نام دامین و Selector  است که فرایند رمزنگاری را امضا کرده اند، دریافت کننده ایمیل یک پرس و جو Query DNS برای پیدا کردن کلید عمومی براسا Domain\Selector  برای تایید امضا انجام می دهد.

کلید عمومی دارای خصوصیات منحصربفردی است که تنها با کلید خصوصی که ایمیل را امضا کرده است، مطابقت دارد،که به عنوان keypair match هم شناخته می شود، که ارائه دهندگان ایمیل را قادر به رمزگشایی امضای DKIM   و بدست آوردن رشته اصلی Hash میسازد.

ارائه دهندگان ایمیل  سپس با استفاده از Element های شرکت کننده در امضای DKIM دوباره یک Hash از این عناصر میسازد، سپس هش را با هش بدست امده از DKIM Hash مقایسه می کند، اگر دو Hash  با هم مطابقت داشته باشند، ما می دانیم که:

  • دامنه با امضای DKIM مالک ایمیل می باشد، در غیر اینصورت فرایند رمزگشایی در وهله اول کار نخواهد کرد.
  • عناصر ایمیل که توسط DKIM امضا شده بودند در هنگام ارسال تغییری نکرده اند (زیرا اگر تغییر کرده بودند، Hash ها با یکدیگر مطابقت نداشتند).

 

ارائه دهندگان ایمیل که امضای DKIM را تایید می کنند، می توانند از اطلاعات مربوط به امضاکننده به عنوان بخشی از یک برنامه برای کاهش حملات Spam,Spoofing و Phishing  استفاده کنند، هر چند که DKIM به دریافت کنندگان ایمیل برای انجام، اقدامی خاص کمک نمی کند، بستگی به پیاده سازی DKIM می توان اطمینان حاصل کرد که پیام در نقل و انتقالات دستخوش تغییرات بوده است یا خیر

 

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

DMARC، آخرین و پیشرفته ترین پروتکل در احراز هویت ایمیل می باشد و این مشکل را با تضمین اینکه دامنه قابل مشاهده برای کاربر نهایی همان دامنه ای است که توسط SPF و DKIM بررسی و تایید شده است حل می کند. علاوه بر این، ارائه دهندگان صندوق پستی را با دستورالعمل مشخصی در مورد اینکه کدام ایمیل ها باید توسط DKIM  احراز هویت شوند و کدامیک نه کمک رسانی می کند.

چگونگی اضافه کردن reCAPTCHA به Outlook Web App

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

در این مقاله می خواهیم در مورد نحوه اضافه کردن قابلیت امنیتی Google reCAPTCHA به صفحه OWA در Exchange Server صحبت کنیم.
قبل از شروع کار بهتر است اطلاعاتی در مورد این سرویس داشته باشید طبق اطلاعاتی که در سایت ویکی پدیا (https://fa.wikipedia.org/wiki/%D8%B1%DB%8C%E2%80%8C%DA%A9%D9%BE%DA%86%D8%A7) درج شده است در واقع reCAPTCHA نسخه جدید و بهینه CAPTCHA می باشد که این قابلیت جهت تفکیک ربات از انسان هنگام دسترسی به یک وب پیج کمک می‌کند. در نتیجه از طریق این قابلیت مطمئن می شوید که یک انسان قصد دسترسی به سایت مورد نظر را دارد. این قابلیت توسط لویز فن آخن، بن مائورر، کالین مک میلن، دیوید ابراهام و مانوئل بلوم در دانشگاه کارنگی ملون در محوطه دانشکده پیتسبرگ توسعه داده شد و سپس در سال 2009 به مالکیت گوگل در آمد.
همانطور که می‌دانید یکی از راههای اتصال کاربران به Exchange Server از طریق وب یا همان OWA می باشد که به صورت امن و از طریق پورت 443 انجام می شود اما ماهیت وب آسیب پذیر می‌باشد و نیاز است از طریق راهکاری جانبی نسبت به امن سازی بیشتر آن اقدامات لازم را انجام دهیم. یکی از این راهکارها اضافه کردن قابلیت Google reCAPTCHA می باشد. از طریق Google reCAPTCHA ابتدا مطمئن می‌شویم که کلاینتی که قصد لاگین به OWA دارید یک کاربر می‌باشد یا یک روبات. سپس از طریق نام کاربری و رمز عبور که برای کاربر نهایی در نظر گرفته شده است امکان لاگین و دسترسی به میل باکس فراهم می‌شود.
مراحل انجام کار به این صورت می‌باشد که ابتدا از طریق اکانت گوگل نسبت به ایجاد و رجیستر کردن یک سرویس reCAPTCHA برای دامین مورد نظر اقدام کنید و سپس از طریق کدهای اعلامی و تنظیمات لازم در Exchange Server امکان استفاده از این سرویس امنیتی در OWA فراهم شود.
مراحل انجام کار به صورت زیر می‌باشد:
1- ابتدا با سرچ کردن کلید واژه google recaptcha به صفحه https://www.google.com/recaptcha/intro/v3.html وارد شوید.
2- سپس با نام کاربری اکانت خود در Gmail لاگین کرده و نسبت به رجیستر دامین و اخذ کد برای reCAPTCHA اقدام کنید.

3- سپس با کلیک بر روی SUBMIT کد رجیستری مورد نیاز را دریافت کنید.

 

همانطور که مشاهده نمودید دریافت کد رجیستری reCAPTCHA به سادگی و در چند مرحله ساده انجام شد. مرحله بعدی مربوط به استفاده از این کدها در OWA می‌باشد.

در نظر داشته باشید که کل این فرآیند برنامه نویسی می‌باشد و برای متخصصین برنامه نویسی بسیار ساده می‌باشد اما شاید برای ادمینهای شبکه کاری سخت و پیچیده باشد. اگر مراحل این مقاله را به همین ترتیب و با دقت انجام دهید بدون نیاز به دانش برنامه نویسی به سادگی می‌توانید از قابلیت امنیتی Google reCAPTCHA در Exchange Server خود استفاده کنید.
4- به سروری که در آن Exchange Server را نصب نموده اید لاگین کنید و وارد مسیر زیر شوید:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth

از طریق notepad یک فایل با نام recaptcha.aspx ایجاد کنید و آن را باز کنید. محتویات زیر را عیناً در این فایل جایگذاری کنید.

<% @ Page AspCompat=True Language = “VB” %>
<%
‘ Put your own private key in the next line
Dim strPrivateKey As String = “SECRET KEY”
Dim strResponse = Request(“response”)
Dim objWinHTTP As Object
objWinHTTP = Server.CreateObject(“WinHTTP.WinHTTPRequest.5.1”)
objWinHTTP.Open(“POST”, “https://www.google.com/recaptcha/api/siteverify”, False)
objWinHTTP.SetRequestHeader(“Content-type”, “application/x-www-form-urlencoded”)
Dim strData As String = “secret=” & strPrivateKey & _
“&response=” & strResponse
objWinHTTP.Send(strData)
Dim strResponseText = objWinHTTP.ResponseText
Response.Write(strResponseText)
%>

Secret Key دریافت شده گوگل را به جای “SECRET KEY” جایگذاری کنید. فایل را ذخیره نموده و ببندید.
5- در همین مسیر فایلی به نام logon.aspx وجود دارد، ابتدا یک کپی از این فایل تهیه نمایید تا در صورت بروز مشکل امکان بازگشت به حالت فعلی را داشته باشید. سپس فایل را طریق نرم افزار notepad باز نموده و تغییرات زیر را در آن اعمال نمائید.
– از طریق میانبر CTRL-F نسبت به جستجوی پاراگراف زیر اقدام نمایید:

form action=”/owa/auth.owa” method=”POST” name=”logonForm”

سپس این محتوای داخل action را حذف نمایید، نتیجه نهایی می بایست به صورت زیر شود:

form action=” ” method=”POST” name=”logonForm”

 

– مجددا از طریق میانبر CTRL-F پاراگراف زیر را جستجو نمائید:

<div><input id=”passwordText”

– بلافاصله در خط بعدی محتوای زیر را اضافه نمائید:

<tr>
<td>
<script type=”text/j-avascript”>
function myClkLgn()
{
var oReq = new XMLHttpRequest();
var sResponse = document.getElementById(“g-recaptcha-response”).value;
var sData = “response=” + sResponse;
oReq.open(“GET”, “/owa/auth/recaptcha.aspx?” + sData, false);
oReq.send(sData);
if (oReq.responseText.indexOf(“true”) != -1)
{
document.forms[0].action = “/owa/auth.owa”;
clkLgn();
}
else
{
alert(“کد تأیید تکمیل نشده است” + “\n” +”reCAPTCHA is not valid”);
}
}
</script>
<script src=”https://www.google.com/recaptcha/api.js” async defer></script>
<div class=”g-recaptcha” data-sitekey=”SITE KEY”></div>
</td>
</tr>

– Site Key دریافت شده از گوگل را جایگزین SITE KEY کنید.
– مجدداً از طریق میانبر CTRL-F پاراگراف زیر را جستجو کنید:

<div on-click=”clkLgn()” class=”signinbutton” role=”button” tabIndex=”0″ >

به جای واژه clkLgn واژه myClkLgn را جایگزین کنید. نتیجه نهایی می بایست به صورت زیر شود:

<div on-click=”myClkLgn()” class=”signinbutton” role=”button” tabIndex=”0″ >

اکنون بدون اینکه نیاز به ری استارت سرور یا سرویس IIS داشته باشید قسمت گرافیکی مربوط به سرویس Google reCAPTCHA را در OWA خود مشاهده می‌کنید.
در نظر داشته باشید برای اینکه این قابلیت به درستی انجام شود سرور ایمیل باید به URL زیر دسترسی داشته باشد:

https://www.google.com/recaptcha/api.js

اگر اینترنت ایمیل سرور را از طریق فایروال محدود نموده‌اید حتما دسترسی به این URL را برای سرور فراهم کنید.

 

قابلیت های جدید Exchange Server 2019

در این مقاله ما قصد داریم تا شما را با ویژگی های نرم افزار Exchange Server 2019 اشنا کنیم با ما همراه باشید.

ابتدا به مواردی که باید سیستم شما برای نصب این نرم افزار دارا باشد می پردازیم:

  • Windows server 2019
  • .Net Framework 4.7.2
  • AD FFL 2012R2+
  • 128-256 GB RAM for Mailbox Server, minimum of 64 GB for Edge Transport
  • 8 گیگا بایت رم

توصیه من به شما این است که این نرم افزار را بر روی ویندوز سرور نسخه  core نصب کنید

حذف نقش Unified Messaging 

در این نسخه مایکروسافت با نقش UM خداحافظی کرده است. سازمان های که از این نقش استفاده می کردند از شنیدن آن خوشحال نخواهند شد.

پر واضح است اولین سوالی که برای  سازمانهایی که از voicemail استفاده می کنند به وجود خواهد آمد این است که چگونه این بخش را به نسخه Exchange 2019 انتقال بدهند در حالی که وجود ندارد.

در واقع این نقش حذف شده است و تنظیمات آن در Outlook هم حذف شده است. اما چند راه حل دیگر در Exchange 2019  برای شما پیشنهاد شده تا نگرانی های شما را برطرف کند.

شرکت مایکروسافت در  Exchange 2019 قابلیت UM حذف کرده و سازمانهایی که از این نقش در سازمانهای خود استفاده می کنند می توانند از راه حلهای زیر استفاده کنند:

استفاده از  cloud voicemail که به  Office 365 و یا استفاده از ویژگی cloud voicemail بعنوان یک محیط ترکیبی نیازمند می باشد.

استفاده از راه حل third-party voice mail

استفاده از Skype for Business 2019

سازمانهایی که از قابلیت UM استفاده می کردند می توان قبل از ارتقا نرم افزار خود به Exchange 2019 به پیاده سازی یکی از راه حلهای بالا بپردازند.

 امنیت بهتر 

نسخه  Exchange 2019 دارای امنیت بهتری نسبت به نسخه های قبلی می باشد وشرکت مایکروسافت توصیه کرده است که در صورتی که خواهد امنیت بالاتر و سرعت بهتری و کارایی بیشتر هستید این نرم افزار را بر روی   windows server core نصب کنید.

در صورتی که این نرم افزار را در  windows server core نصب کردید می توانید MMC ، و Event Viewer بصورت Remote استفاده کنید.

 کارائی و مقیاس پذیری بهتر

در نسخه پیشین این نرم افزار از Workstation GC استفاده شده بود که تنها   تعدادی محدود از اپلیکیشنها را اجرا می کرد . این قابلیت همچنین باعث کاهش تاخیر در عملیاتهایی که  بدون توقف در حال اجرا هستند میشد اما اشکالی که وجود داشت اجازه استفاده از تمام قدرت CPU را نمی داد.

در نسخه 2019 این نرم افزار  (Garbage Collection (GC جایگزین Workstation GC شده است و مشکل موجود در نسخه های پیشین حل شده است و به این ترتیب سرور قادر به انجام کارهای بیشتر بوده و کارائئ سرور ارتقا می یابد.

در نسخه 2019 این نرم افزار از memory  بهره وری بیشتری می شود.

عملکردهای (Tiered storage, Metacache database (MCDB و dynamic cache چگونگی  استفاده از حافظه را باز طراحی می کنندکه باعث بالا رفتن کارای خواهد شد.

برای دسترسی  همزمان به SSD و JBOD از Tiered storageاستفاده خواهد شد همچنین همانطور که می دانید SSD  سریعتر و دارای عمر کوتاه تری است اما JBOD کندتر و ارزانتر و قابل اعتمادتر می باشد

از  JBOD برای ذخیره همه داده ها استفاده می شود و از SSD به عنوان محل ذخیره سازی داده هایی استفاده خواهد شد

در نسخه 2019 این نرم افزار این عمل با استفاده از MCDB انجام خواهد شد و  SSD محل  قرارگیری داده های جدید و کوچک خواهد بود.

 تغییرات در جستجو

در نخه جدید 2019 از BING برای جستجو استفاده می شود.  و نحوه ی کار آن بدین صورت است ذکه فایل ها را در هر MailBox  h می کند و بدین ترتیب سرعت جستجو کاربران افزایش خواهد یافت.

 Client Access Rules

در این نسخه شما قادر به دادن دسترسی   Exchange admin center و  PowerShell به کاربران می باشید و این دسترسی می تواند به صورت محدود یا کامل باشد. اما برای انجام این کار معیارهایی وجود دارد که شامل    IP Address، نحوه احراز هویت و قدرت دسترسی کاربرانمی باشد. بنابراین دسترسی غیر مجاز به سیستم ما از بین خواهد رفت.

شما قادر هستید تا برای مدیریت   Client Access Rules از PowerShell   استفاده کنید.

اما اگر شما دز سازمان خود جلسات را سازماندهی می کنید اگر به قسمت تقویم بروید سه تغییر را مشاهده خواهید کرد:

Default End Date

Do Not Forward

improved calendar management

اما تغییرات دیگری که در این نسخه شاها آن هستید عبارتند از :

ارتقا  Exchange 2019  به نسخه بالاتر  بدون از دست رفتن سرویس Exchange

استفاده از کاراکترهای غیر انگلیسی در ایمیل آدرس

نسخه اولیه Exchange 2019 قادر به نصب بر روی سرور 2016 نیز می باشد اما نسخه نهای این نرم افزار تنها بر روی  ویندوز سرور 2019 قابل نصب می باشد.