Why is eseutil running on Exchange 2010 in the middle of the day. All of a sudden I got ten calls from end users regarding outlook unresponsive/crashing. I check exchange and processor is pegged at 100 ESEUTIL is the culprit. I checked the online maint schedule and it is default from 1am-5am. So not sure if that is the issue. Anyway - trying to identify why ESEUTIL is running at all. I dont want to stop the process cause we all know how deep that process runs! How can I figure out what ESE is doing? Thanks - SJMP

I ran procmon and saw that ESE was doing a directory query - I also saw that wbengine was running and a local backup was kicked off. Would this be the cause of ese going nuts? As soon as I cancelled the backup everything returned to normal.

That tool shouldn't be running at all. If it is, then the information store service should be stopped because it hasn't got access to the files. I would be looking to see if you can find what started it - scheduled task, third party utility etc. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources

On Tue, 16 Nov 2010 16:28:52 +0000, SJMP wrote: >I ran procmon and saw that ESE was doing a directory query - I also saw that wbengine was running and a local backup was kicked off. Would this be the cause of ese going nuts? As soon as I cancelled the backup everything returned to normal. A backup wouldn't run eseutil. For ESEUTIL to run the database has to be dismounted. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Someone would have to have down this manually, or perhaps a scheduled process/program that utilizes ESEutil, but it will not just start on its ownTroy Werelius www.Lucid8.com

I see it run during a VSS backup (and only VSS backups are supported in 2010) It operates on the snapshot which is how the database keeps running. Microsoft recommends that backup vendors check consistency using an API but still allows them to call ESEUTIL. So it depends on the backup software (VSS requestor) http://msdn.microsoft.com/en-us/library/bb891802(EXCHG.140).aspx

To build on to what cn9 said, I have seen many "snap shot" backups try to kick off an ESEUTIL scan of the snapped database (that they levereage the VSS API for) on the actual mailbox server it was snapped on. Bad idea if you ask me unless you have plenty of resources and the disks of the snapped version of the database aren't share with the production database. I.E. If you have 10 disks in a SAN RAID, and a single RAID volume (depending on your terminology) and you snap a copy of the database in the middle of the day to create a second LUN, and then try to scan the database on that second LUN with ESEUTIL, you will most likely impact your primary database because of the shared disks, and also shart bits if you didn't do a "snap clone". In short - contact your backup vendor and confirm that they aren't trying to run ESEUTIL on your production server as a result of the backup, and if they are what you can do to mitigate issues.

If the backup software here is wbengine (Windows Server Backup) then it's pretty basic and you can't really do any fancy offloading. And also if you have database copies, i.e. a DAG, it's best to back those up instead of the active one. That said I've occasionally run VSS backups in the middle of the day, on a server with thousands of users (using another product though, but one that also calls eseutil) ... Disk latency certainly spiked from a monitoring perspective, but nobody noticed- at least not enough to complain :) And this was with no dedicated disks for the snapshot... totally shared. Might be worth looking to see what exactly is being stressed during this scenario (disk, CPU, memory?) - check with perfmon.

cn9 That was the issue. as soon as I killed the backup webengine and eseutil went away. Thanks,