Error stating Outlook OST file is in use and cannot be accessed

After I rebooted a Windows 10 PC subsequent to a software update on the system, when I attempted to reopen Microsoft Outlook 2016, I saw the message below:

Outlook Data File


Black exclamation
mark in yellow triangle The file C:\Users\jasmith1\AppData\Local\Microsoft\Outlook\john.a.smith@exmple.com.ost is in use and cannot be accessed. Close any application that is using this file, and then try again. You might need to restart your computer.

When I clicked on "OK", I saw the following message:

Excel Shortcuts and Productivity Hacks 2.0
Excel Shortcuts and Productivity Hacks 2.0
1x1px

Microsoft Outlook


Black exclamation
mark in yellow triangle Cannot start Microsoft Outlook. Cannot open the Outlook window. The set of folders cannot be opened.

When I started the Task Manager and clicked on "More details", I didn't see Outlook in the process list. Nor did I see it listed when I ran the tasklist command from a command prompt.

C:\>tasklist | find /i "Outlook"

C:\>

Based on the article, Outlook: Solve “The file username.ost is in use and cannot be accessed” Error, I then checked for instances of processes named named "Communicator", "Lync", or "ucmapi". I saw UcMapi.exe and lync.exe were running.

C:\>tasklist | find /i "ucmapi"
UcMapi.exe                    5660 Console                    1     49,844 K

C:\>tasklist | find /i "Communicator"
EACommunicatorSrv.exe         3416 Services                   0     46,320 K

C:\>tasklist | find /i "Lync"
lync.exe                      8372 Console                    1    124,080 K

C:\>

I killed the UcMapi and Lync processes using their process identifiers (PID) with the taskkill command.

C:\>taskkill /pid 5660
SUCCESS: Sent termination signal to the process with PID 5660.

C:\>taskkill /pid 8372
SUCCESS: Sent termination signal to the process with PID 8372.

C:\>tasklist | find /i "ucmapi"

C:\>tasklist | find /i "Lync"

C:\>

I was then able to start Outlook without the error messages appearing. Based on a posting I read at a Microsoft Community site, Office 2013 - UCMAPI.exe (Lync) locks Outlook OST-file, a similar problem may occur with Outlook 2013. The poster noted:

This question has been asked before, but I will try again with some more information for our situation. We are running Office 2013 and are experiencing a problem with UCMAPI..exe, a process used by Lync, when patching Office updates. This can happen with Office and Outlook patches and possibly with Lync patches (not tested). Lync is set to autorun at launch and UCMAPI.exe wil typically start within 30 seconds after Lync opens. If a computer installs a patch as specified, before Outlook is opened, Outlook will fail to open with the following error message (translated to english):

Outlook data file
Cannot access the file.
C:\Users\<Username>\AppData\Local\Microsoft\Outlook\Microsoft Exchange - Default Outlook profile.ost". It's in use. Close any program using the file and try again. You might have to restart your computer.

In Event Viewer there will also be a warning from Restart Manager:
Application "C:\Program Files (x86)\Microsoft Office\Office 15\lync.exe" (pid 5092) cannot be restarted - Application SID does not match Conductor SID..

Closing UCMAPI.exe will as explained in other threads and from other sites fix the problem as a workaround, but we would prefer to have less intrusive work around or preferably have the problem resolved in a future patch. We have also had an external consultant firm reproduce the error. The problem has been easy to reproduce by testing uninstallation and installation of KB2956151 (march) and KB2965270 (april).

If Outlook is open during patching it will work as normal, but might fail to open if it is closed and reponed. Using ProcessMonitor we have seen UCMAPI.exe run UnlockFileAll on the OST-file when the process is closed, but it seems the LockFile is initiated by Lync before the patch is installed. Search from internet seems to suggest Outlook and Lync sharing file handles to the OST-file, but patching seems to mess upp these "handles" .