5 Worst Practices To Avoid For Improving Microsoft Exchange Server’s Performance

With Microsoft Exchange Server at the center of much of the world's commercial interactions infrastructure at present, attaining best messaging system performance -- whether authentic or apparent has turned out to be an essential part of every Exchange manager’s job. No matter what the reason is, if "email is slow," your help desk phones will start ringing, and in case if email is down, your prospect at the corporation may be restricted.

By taking a different approach towards MS Exchange Server's performance, I have come up with 5 worst practices which should be avoided in order to make Exchange servers perform at their best.

Worst Practice #1: Block the RAM available to Exchange Server

It appears like each day we notice an e-mail from someone inquiring why store.exe is consuming a big part of Exchange Server's memory. This is regularly accompanied by queries on how to choke store.exe to bind its memory utilization.

No matter by what manner you accomplish it, throttling RAM for Exchange is an awful thing. Exchange has been designed to use as much memory as it can find its "hands" on. You should allow it.

This means that you should not install MS Exchange on the same server as SQL Server, for example, while this will consequence in severe memory disputation issues, and can considerably ruin the performance. Likewise, co-locating Exchange on a global catalog server or a domain controller is not suggested.

Worst Practice #2: Schedule backups and system maintenance during peak usage

One of the areas that businesses often pay no attention is the overlap among resource-intensive procedures affecting Exchange server. We have frequently seen organizations allow their every night backups spill out over into the "morning rush" of employees arriving at work and logging on to their systems to check e-mail, and then doubt why "e-mail is slow."

You require to clearly recognize how long your nightly backups are running on all of your Exchange servers. We suggest keeping track of backup windows for all your servers in whatsoever method you choose (i.e., Visio, Word, Excel, etc.), and then also tracking when your nightly Exchange server repairs is running.

You should also document time of "peak usage."

You can then evaluate your records and adjust your Exchange backups and system maintenance break consequently, so they can equalize from one another and from your phase of peak usage -- favorably throughout the times of "low usage."

  

Worst Practice #3: Treat "high accessibility" as a future project

High accessibility should be the state of mind of your company, and something that all Exchange administrator should endeavor for, as compared to particular company needs.

Some questions to ask yourself:

• What measures and practices can be executed to accomplish steady accessibility that meets or surpasses your end users' requirements and management's prospects?
• Where are opportunities for performance improvement?
• What are practical accessibility targets for your corporation?
• What can you do to endeavor in the direction of determining performance and accessibility?
• What are key performance indicators (KPIs) of achievement against these targets?

 If you're facing Exchange performance issues, ignoring IOPS (read from disk + write to disk operations) is one of the worst things you can do. The days of being concerned with CPU or memory bottlenecks are mostly gone for Exchange server administrators. Now, disk throughput is the No. 1 factor you need to think about.

Worst Practice #4: Leave "IOPS" for the consultant

If you are not aware with IOPS ("IO/Sec" or "I/OS per second"), you actually require to do some reading on disk latency and how this influence disk throughput in relation to your Exchange servers. This applies to any Exchange manager, but turns out to be an actual distress if you are:

Engaged in buying, provisioning or constructing a newfangled Exchange server.

 

In an atmosphere where MS Outlook 2000/2003 end users often find "RPC Cancel Requests." (They are those irritating pop-ups that state somewhat like "Outlook is retrieving data from the Microsoft Exchange Server <servername>. You can revoke the request or minimize this notification to the Windows task bar until MS Outlook shuts the notification automatically.")

Worst Practice #5: Using the same configuration for all Exchange Server roles

In case you didn't (puff) go after the recommendation we gave in Worst Practice #4, we will be a bit more precise. You must optimize Exchange disk arrangement based on server responsibility.

For example, if you are trying to optimize a mailbox server and you wish to put your database transaction log files (not to be puzzled with message tracking log files) on a different set of spindles (i.e., preferably a RAID1 set), your binaries on a different set of spindles (i.e., RAID1), your page file on a different disk (no RAID), and lastly your databases on a different set of spindles (i.e., preferably a RAID0+1 set).

If you are optimizing a high volume SMTP gateway, you need to ensure the mail root directory (<drive>: \Program Files\Exchsrvr \Mailroot) is spread transversely as many spindles as possible (i.e., RAID0+1 favored).

If you keep on performing the above practices which are not recommended, then these worst practices might corrupt or damage your exchange database files. Then in that case, what will you do? You need to then make use of any recovery software which can repair your corrupt or damaged files.  These tools provide advanced scanning algorithms that can assist you in repairing and recovering from severe corruption situations and one such reliable and proficient tool available in the market is "Stellar Phoenix Exchange Server Recovery" which is a one of the most widely-used software by small to large corporations to repair and recover their exchange database files.