After which, one of my Exchange 2016 Mailbox Servers puked it's guts out every time I tried a PowerShell cmdlet; restarting the EMS resulted in WinRM errors as well. The machine was also running slow, so I checked task manager and sure enough, RAM was pegged at 99% from an IIS Worker Process.
On a lot of blogs and forums, in order to see what's consuming resources, people say to install procmon, find the PID, get the process name, kill it with an elevated CMD, etc.
I for one, really don't like installing extra software on my Exchange servers. Also, killing an entire IIS service will almost always bounce your client connections, because in Exchange 2013/2016 TONS of backend services run off of IIS. Luckily, there's a much easier way to find out which IIS pool is hogging your resources, and we can recycle that specific pool without killing your connections.
The Fix:
Open IIS Manager (not IIS 6.0)
Click your server name, and then Worker Processes

Click the Virtual Bytes heading twice to sort in descending order.
In my case its the MSExchangePowerShellAppPool consuming all that RAM:
**Note** You can get the PID from here without having to install something like procmon ;)
Make sure to close the EMS
Click Application Pools
Right-click MSExchangePowerShellAppPool or whichever pool is consuming your resources.
Hit Recycle:
Give it a minute and try the EMS again
That looks much better!
Now, go yell at your infra guys to stop doing destructive things in the middle of a work day!
No comments:
Post a Comment