I've been looking at my Exchange 2013 servers this week and wondering about the IIS application pools. There are a number of issues that make me wonder about recycling the app pools, the worst being that on several of my servers I see the MSExchangePowerShellAppPool having allocated in excess of 6GB memory.

Are there any recommendations, or a white paper about the virtues or hazards of recycling the Exchange 2013 IIS Application pools?

If recycling is not a bad thing, what how should it be configured:
- on a scheduled basis?  weekly, daily, every 6 hours ?
- triggered on an event?  after consuming more thatn xxx GB memory ?

Does anyone have any thoughts on tis subject?

Tom

Recycling app pool may not work in such scenario. It may end up creating another working process and the old one remain alive. Temp workaround is to restart the server.

For long term solution, I suggest the following,

• Update Exchange to latest CU
• Update .Net Framework to the latest version and hotfix rollup
  
• Patch Windows OS with the latest critical update

• Edited by Li Zhen 16 hours 31 minutes ago

Recycling app pool may not work in such scenario. It may end up creating another working process and the old one remain alive. Temp workaround is to restart the server.

For long term solution, I suggest the following,

• Update Exchange to latest CU
• Update .Net Framework to the latest version and hotfix rollup
  
• Patch Windows OS with the latest critical update

• Edited by Li Zhen Tuesday, July 21, 2015 2:57 PM

In my experience, IIS is pretty good about killing the initial working process if it does not gracefully bleed off within a time limit. I am trying to avoid server reboot and user impact.

The advice you provided is not bad at all, but it is not at all what I am looking for.

I'm looking for any advice for Operational procedures to put in place ( or NOT ) to keep everything running smooth.

Tom

Your statement is true only if IIS and .Net Framework are up to date. Since there is memory leak, it's good indication that at least one of them is not updated. In this situation recycling app pool may not help. I saw lots of such incidents.

Hi Tom,

Thank you for your question.

Is there Event id 701 in application log?

This Warning event indicates that MSExchangePowerShellLiveIDAppPool is using more memory than the committed memory limit for the process.

In Microsoft Exchange Server 2013, all PowerShell cmdlet calls are executed remotely in either MSExchangePowerShellAppPool or in MSExchangePowerShellLiveIDAppPool in IIS. These calls are executed by a Windows process (w3wp.exe). This occurs regardless of whether the PowerShell.exe process runs locally or remotely. The Windows System Resource Manager service maintains the committed memory limit. The service monitors the committed memory usage of matched processes. The service also enforces the user-defined action whenever the committed memory usage of the process exceeds its limit.

Event 701 indicates that the online defragmentation feature has finished a full defragmentation. In Exchange 2013, the architecture for online defragmentation was moved out of the Mailbox database maintenance process and now runs in the background 24 hours a day, seven days a week.

You don't have to configure any settings for this feature. Exchange monitors the database as it uses it, and small changes are made over time to keep the database defragmented for space and contiguity. If the database analyzes a range of pages and finds that they are not as sequential as they should be, it starts an async thread to defragment that section of the B-tree or table. Online defragmentation is also throttled so that it does not adversely affect client performance.

We could refer to the following link:

https://technet.microsoft.com/en-us/library/hh343965%28v=exchg.140%29.aspx

Notice: it also apply to Exchange 2013.

If there are any questions regarding this issue, please be free to let me know.

Best Regard,

Jim