• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / MSExchangeRepl Error: The process cannot access the file because it is being used by another process

MSExchangeRepl Error: The process cannot access the file because it is being used by another process

July 9, 2013 by Paul Cunningham 3 Comments

Recently my Get-DAGHealth.ps1 report alerted me that the active copy of a mailbox database in the DAG was on a server that was not the first activation preference. This indicated that an unplanned failover had occurred overnight.

A review of the event logs on the server revealed the following event:

Index : 29023683
EntryType : Error
InstanceId : 489
Message : msexchangerepl (3644) An attempt to open the file “D:\Logs\Mailbox Database 1\E01.log” for read only access failed with system error 32 (0x00000020): “The process cannot access the file because it is being used by another process. “. The open file operation will fail with error -1032 (0xfffffbf8).

This indicated that a file lock had occurred, although the server has interpreted that as memory exhaustion and has failed over the database.

Index : 29023694
EntryType : Error
InstanceId : 3221487736
Message : At ’08/07/2013 10:25:19 AM’ the Exchange store database ‘Mailbox Database 1’ copy on this server appears to have failed due to insufficient memory. For more details about the failure, consult the Event log on the server for other “ExchangeStoreDb” events. A successful failover restored service.

After considering the possible causes of a file lock occurring for a transaction log file I discovered that the antivirus software on the server did not have an exclusion configured for the transaction log path. Transaction log files are one of many recommended exclusions for file-level antivirus scanning.

If you are experiencing unplanned failovers of databases in your DAG I recommend reviewing your antivirus exclusions.

Exchange Server Antivirus, DAG, Database Availability Group, Exchange 2010

Comments

  1. Kingston says

    November 24, 2015 at 6:02 pm

    Hi Paul,

    I am gettin the same error,

    Log Name: Application
    Source: ESE
    Date: 24/11/15 10:13:44 AM
    Event ID: 489
    Task Category: General
    Level: Error
    Keywords: Classic
    User: N/A
    Computer: xxxxxxxxxxxxxxxxxxxxxx
    Description:
    msexchangerepl (8216) An attempt to open the file “M:DAG1-LOGDAG1-DB25LOGE03.log” for read only access failed with system error 32 (0x00000020): “The process cannot access the file because it is being used by another process. “. The open file operation will fail with error -1032 (0xfffffbf8

    I followed your below link to check the exclustions and confirmed that we have already exclustion added to the EDB and logs

    https://www.practical365.com/powershell-script-exchange-2013-antivirus-exclusions/
    As per your advice i checked on the server and i can see exclustions are added already

    Need your advice

    Thanks

    Reply
  2. John Gidlund says

    June 22, 2014 at 8:24 am

    Paul, I am getting this very same error. I am in the middle of migrating from Exchange 2010 to 2013 (DAG Setup) and every time I kick off a migration batch I run into this error. When it happens the mailbox will actually fail over to another DAG member. Seems the only fix is to reboot the server and then it replicates properly. I have run Process Monitor and Exchange is the only thing that appears to have access to the database and/or log file. I am on Exchange 2013 Standard RU3 running SEP with exclusions. According to Symantec SEP is Exchange aware without adding exclusions: http://www.symantec.com/business/support/index?page=content&id=TECH97707

    Any thoughts?

    Reply
    • Paul Cunningham says

      June 26, 2014 at 1:30 pm

      I’m sure SEP is supposed to be Exchange aware but if you want to exclude it as a potential cause then removing it from the server would be a good test.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland