UCMAPI.EXE Locks Outlook OST File


  • Hello,
    I am investigating an issue in our environment where the Microsoft Lync client is locking the Outlook .ost file and preventing Outlook from updating it.  This results in the user not receiving any e-mail.  The offending process is UCMAPI.EXE, which upon examination using ProcExp shows a number of "mutant" handles manipulating the .ost file.  Upon terminating those handles, the .ost is freed up, the sharing violation ceases and the user is able to receive mail again.
    Please advise.
    Thank you,
    Tuesday, December 13, 2011 3:12 PM

All replies

  • Hello Doug,

    Since we are also using Lync with Outlook in our environment, this behavior haven't been found or reported so far.

    So, I'd like to know, how many computers are get affected with this issue? And since when did you find this begin to happen?

    Be sure to have the latest update installed, especially the Service Packs.

    It might be helpful to run Windows in clean boot mode to check if this issue will still occur.


    Max Meng
    Forum Support

    Come back and mark the replies as answers if they help and unmark them if they provide no help.
    If you have any feedback on our support, please contact

    Wednesday, December 14, 2011 9:22 AM
  • Hi Max,

    Thanks for responding.  This issue has apparently been happening for quite some time...even when we were primarily using Office Communicator.  However, the somewhat simple solution of closing and re-launching Outlook and Communicator/Lync kept the problem under control.  Recently, this issue has spiked and our Help Desk has been dealing with more of these issues.  We began an enterprise deployment of Lync perhaps 1-2 months ago so my investigation is focused on that product since that's the direction we're moving.  The number of computers impacted is at least in the hundreds if not thousands over the past year or so.  It seems to be random in nature...unable to repro on my end.  The Lync deployment seems to be a trigger for the increased number of incidents.  We are about to deploy Office 2010 SP1 and I have proposed deploying the most recent cumulative update for Lync to the enterprise in the hope that it has a positive impact.  I was hoping someone else has seen this and could offer suggestions...the hits on the web even remotely similar to our problem are amazingly few.  I have several pieces of data showing the issue in progress if you're interested.  Otherwise, we will try the Office and Lync updates and if there's no positive change, will open a case with product support in January.



    Douglas Cote
    Wednesday, December 14, 2011 2:15 PM
  • OK, let's see the result after all the pathes have been installed.

    If possible, you can post the data in this post, or you can send to: icff'a' (replace 'a' with @), thanks.

    Max Meng

    TechNet Community Support

    Thursday, December 15, 2011 1:45 AM
  • Hi Doug,

    Just checking to see if you have Office 2010 SP1 installed and how is everything going?

    Max Meng

    TechNet Community Support

    Tuesday, December 20, 2011 7:04 AM
  • Hi,
    I'm marking the reply as answer as there has been no update for a couple of days.
    If you come back to find it doesn't work for you, please reply to us and unmark the answer.

    Max Meng

    TechNet Community Support

    Wednesday, December 21, 2011 3:22 PM
  • Thanks Max.  I'm getting caught up after taking time off over the holidays.  Our attempt to deploy SP1 actually failed.  Many users were suddenly unable to open the Online Archive in Outlook after the installation.  A rebuild of their mail profile seems to resolve the issue but having users take manual steps to resolve is not practical in our environment.  Not sure if you've heard of this before but it's a show stopper here and is preventing us from going to SP1 until we can get some kind of fix.  So, for now, we are focused on trying to update the Lync client to the latest build to see if that helps reduce Help Desk volume related to the locked .ost issue.



    Douglas Cote
    Tuesday, January 10, 2012 6:58 PM
  • Has anyone found a solution for this? I've had the same problem for awhile now, even after upgrading to the latest version of Lync and applying all patches and updates. I've found the only way to unlock the .ost file is to kill the ucmapi.exe process.
    Tuesday, May 22, 2012 7:32 PM
  • We're also seeing this behavior in our environment. Seems to be happening randomly and we're unable to reproduce.
    Monday, June 18, 2012 3:53 PM
  • We have been battling this issue since the rollout of MS Lync in our Windows 7 environment. Our users call in to report that Outlook has stopped updating. When we have the user end the UCMAPI.EXE process using the Task Manager, Outlook updates immediately. We tried installing a "Lync patch" (Lync.msp); but, that did not resolve the issue and the same users who received the patch--as well as others who did not--continue to have this issue. We tried opening a ticket with MS support, and we made their suggested changes to our Lync environment. Issue still persists.
    Wednesday, July 25, 2012 6:30 PM
  • We're seeing the same issue ourselves. We're running windows 7 and Lync both fully patched.

    Each time the ost error manifests we see 3 locks against the ost form the process UcMapi.exe. The PID is the same but we have 3 different handles. Killing these file locks allows Outlook to launch ok.

    We don't see the issue if Lync is closed and launched after Outlook, it's preventing us from rolling Lync out further though as we want to enable auto-start. Annoyingly it does seem to be an intermittent issue that we can't reproduce on demand.

    Nina - or indeed anyone else - did you ever find a fix?

    Kind regards.

    Thursday, August 23, 2012 9:46 AM
  • Exactly the same issue here, with W7/Lync/O2010 fully patched. pskill ucmapi fixes it.
    • Edited by ajkessel Tuesday, August 28, 2012 1:21 PM
    Tuesday, August 28, 2012 1:19 PM
  • Add us to the "same issue" list.  With Lync set to start with Windows we have random OST file hangs.  End Task on UCMapi.exe and their email comes in instantly.

    Anyone from Microsoft listening out there???  



    We ended up writing a small program that sits in memory, but not visible to the user, which all of our computers run at start up.  

    Every 10 seconds it looks to see if Outlook.exe is running.  When it finds Outlook.exe running it Ends the UCMapi.exe task, then terminates itself.

    Not a perfect solution (what if the user closes Outlook and re-launches it), but it catches 99% of the phone calls for this issue to our Help Desk and we'll take that as a win.

    • Edited by DHeck Tuesday, March 19, 2013 6:11 PM Updating info
    Wednesday, November 28, 2012 2:45 PM
  • It happens to us as well.

    we use USMT 5 to migrate user profiles and our exchange/lync server is hosted over the WAN in our head office.

    so far re-creating the mail profile mitigates the issue where just opening/closing outlook/lync has a pretty high re-occurance rate.

    Seems to me like a possible bug, maybe related to USMT or maybe a latency issue with running over the WAN?

    Thursday, February 07, 2013 10:46 PM
  • I've experienced the same issue too since deploying the latest Lync patch (KB2815347). In my case, if a user closes outlook while using Lync (and the ucmapi process is running) then they cannot reopen outlook due to the ost file being locked out. This can also happen if the ucmapi process starts before the user starts outlook.

    I investigated the issue and i have come to the conclusion that it the way the patch has been deployed that has cause the issue.

    I deployed the Lync.msp patch via a startup script in a GPO, the startup script was basic but did the job, but the because it was so basic, it meant that every time a computer started up, it would install this patch. Not exactly a big deal, i didn't notice any issues in testing etc. So when i encountered this issue i decided to uninstall and reinstall the patch.

    This resolved the issue. Maybe because the patch was installing over itself, it causes this issue.

    This may help if you have deployed in a similar way, let me know if it does.



    Wednesday, May 08, 2013 9:17 AM
  • Just adding to the thread of how I solved it (it may not directly work with others)

    1. If MS Lync is active, exit the application (Check if the process closes down - used sysinterals "Process Explorer). This should release the .ost or .pst handle.
    2. If your .ost or .pst is corrupted (or just plain out of commission) run scanpst or scanost to repair it.
    3. Re-run outlook. It should run fine.
    4. As for having MS Lync automatically run at boot time, you may want to consider to run "manually" or re-define order of booting of applications (having Outlook start first).


    Paul Leeves

    Wednesday, June 26, 2013 2:15 PM
  • So do we have a fix for this problem (rather than just a work-around) ? 

    Our organisation is still having this problem.  We are on Windows 7 /Office Profesional Plus 2010.... our service desk is so familar with the problem they knew what it was right away and was able to implement the work-around straight away.....

    Sunday, September 29, 2013 10:20 PM
  • I have the same issue with one user.  We have thousands of users, but it's only happening to this one.  Would a reinstall of the Outlook and Lync client have any effect?
    Tuesday, October 08, 2013 3:00 PM
  • Hi rimetree, I have been encountering the same problem with my clients but not all, we are running Exchange 2010, LYNC 2010 and Outlook 2010 32bit running in Windows 7 32bit. When Connection to Microsoft Exchange going lost and reconnect this will happen, Once i terminated the ucmapi.exe process from the client, then Outlook opens normal. It would be appreciate if someone come up with possitive solution on this.

    Thanks in Advance,


    Thursday, April 03, 2014 5:00 AM
  • Same problem here, is a fix to be expected or not?
    Friday, June 13, 2014 7:19 AM
  • NikoV - the issue has been around for over 3 1/2 years so I wouldn't expect a fix ever for it.  The only way we got around this is to run a custom program in the background that the user never sees.  The program looks for Outlook.exe to run then kills UCMapi.exe and terminates itself.



    Friday, June 13, 2014 1:13 PM
  • So, I have this expectation that if an error is reported in Dec of 2011 that I wouldn't get that error in 2014.

    Is that too high of an expectation?

    Friday, August 22, 2014 3:31 PM
  • We are having the same issue with the UCMAPI.EXE error and found problem is directly attributed to Lync. Our company is subscribed to Office 365, and have several issues with Lync, including crashing, messages do not get sent out-but able to receive, and loads of Freezing and crashing. I had to uninstall Lync all together, as I find it far more troublesome than what it is worth.

    I personally run Windows 8, and have Outlook 2013.


    Tuesday, September 23, 2014 4:32 PM
  • I know this is a really old thread that I started years ago, but we are now in the final stages of deploying Office 2013. Believe it or not, the send/receive issue persists and is still generating a large volume of calls to our help desk. Because the fix is so easy, we haven't dug into root cause, but it's time we understand why send/receive fails and how to prevent it permanently. Any more information on this front?



    Douglas Cote

    Thursday, January 28, 2016 9:46 PM
  • Hey IDK if this was resolved or not. but I figured out that my Lync was holding on the .ost file because under properties it was checked to "run as admin".

    So I deselected that and now it works like a charm!

    Hopefully is quick easy fix like mine was.


    Paulo Chavez

    Wednesday, May 11, 2016 5:22 PM