Bug Alert

Patching Access 2013 Runtime to Fix "File Already In Use" Bug

Step-by-step process to patch the 2021 Holiday Bug for Office/Access 2013. These same steps can be adapted to patch other versions, too.

Mike Wolfe

Jan 8, 2022 • 6 min read

As I've already written about, a December "Patch Tuesday" security update from Microsoft introduced a bug that affects shared Access database files.

Whenever a user with an affected copy of Access connects to a backend database, then any other user that attempts to connect to the same database receives the error, "File already in use." Until recently, I had managed to avoid this error as most of our clients use the Access 2013 Runtime to run our applications.

However, that changed yesterday when I got an email, a voicemail, and many, many automated bug reports announcing the arrival of the 2021 Holiday Bug.

The Patch that Broke the Access 2013 Runtime

In this specific situation, the sudden outbreak of the bug at our client could be traced to a manual rollout of the Office 2013 Security Update, KB5002104.

After this update is installed, Microsoft Access databases that are stored on a network share can't be accessed by multiple users simultaneously.

I recognized the error message immediately, but it took me quite awhile to identify the source of the error. I mistakenly assumed that it must have originated with one of the handful of users with a Click-to-Run (C2R) version of Access. I completely ignored the Access 2013 Runtime installs, as I did not realize the security update had just been pushed out in my client's environment. Moral of the story: make sure to check in with everyone in the IT department about recent updates before going crazy with your troubleshooting.

PDQ Deploy: Efficient Deployment of Both the Bug and the Fix

The bad news was that PDQ Deploy had pushed the buggy security update out to dozens of computers. The good news is that I was able to push out the manual fix just as efficiently using PDQ Deploy.

If you are not familiar with PDQ Deploy, I encourage you to check it out. We have a professional license (a bargain at $500/year if you do any network admin work), but the steps below should work within the constraints of the free version.

The fix for the Access 2013 version of the bug is KB2965317.

This update fixes the following issues:

Access databases that are stored on a network share can't be accessed by multiple users simultaneously in Microsoft Office 2013 after security update KB5002104 is installed.

Creating the PDQ Deploy Update Package

Step 1. Download the Executable

The first step is to download the update executable file.

For this client, every user was running the 32-bit version of the Access 2013 Runtime. So, the rest of the screenshots will show the 32-bit fix. If you have 64-bit users, you will need to deploy a separate package for those users. Remember, the 32-bit vs. 64-bit refers to the bitness of Office, not Windows. It's very common to have a 32-bit Office install on 64-bit Windows.

I downloaded the 32-bit English version of the bug fix to match my client's environment:

Step 2. Extract the .msp File

The .exe file is a self-extracting zip file. The actual update is inside an .msp file embedded in the .exe.

After downloading the .exe file, I used 7-Zip to extract the .msp file (right-click > "7-Zip" > "Open archive").

To help keep things organized, I renamed the extracted .msp file by prepending the associated KB article number:

KB2965317-ace-x-none.msp

Step 3. Create the PDQ Deploy Package

Next, I created a new installation package in PDQ Deploy.

The package had a single "Install" step as shown below:

The Install File name has to be available via the network when run from the target computer. You can save the .msp file to a network folder if you want, but I just used the built-in Admin share (\\ComputerName\C$\...) to reference the file on the same computer where PDQ Deploy is running from.

PDQ Deploy recognizes this as an MSI installer, so the MSI Options dropdown appears, along with all the exit codes that indicate the install succeeded (truth be told, I copied this package from an earlier one; I'm not sure if PDQ Deploy includes all of these Success Codes by default, or if I manually added one or more of them at some point in the past):

0: Action completed successfully. ERROR_SUCCESS
1641: The installer has started a reboot. This error code not available on Windows Installer version 1.0. ERROR_SUCCESS_REBOOT_INITIATED
3010: A reboot is required to complete the install. This does not include installs where the ForceReboot action is run. This error code not available on Windows Installer version 1.0. ERROR_SUCCESS_REBOOT_REQUIRED
2359302: The update to be installed is already installed on the system. WU_S_ALREADY_INSTALLED (decimal equivalent of 0x00240006)

Note that if you are not using PDQ Deploy and you just want to create a silent installer to deploy via login script or remote powershell or whatever your tool of choice is, you can use the following command line directly:

msiexec.exe /p "KB2965317-ace-x-none.msp" /qn /norestart /log output.log

Obviously, you may need to adapt the above command line for your usage. For example, the relative reference to the .msp file may need to be an absolute reference and you may want to log to a different file (or none at all). But this should get you pointed in the right direction.

Step 4. Deploy the Package to Affected Machines

The final step is to actually deploy the package to the affected machines.

In my case, I was able to perform a "Redeploy" to the same machines that had the bug applied earlier in the day. I simply swapped out the buggy KB5002104 package for the KB2965317 package I defined above.

The install only took a few minutes per machine. Within an hour everything was back to normal. Until the next bug...