Had an interesting application deployment issue. The issue was described to me like this:
- We deploy an upgrade to the application, which is an ACCESS database app (ah the wonderful world of enterprise applications) that connects to a backend SQL. The file being replaced is a .MDB file located under C:\Program Files
- When deployed via SCCM the version of the application doesn’t change
- However if we copy the exact same file as the user used by the SCCM package into C:\Program Files, the application shows the new version
- It has been confirmed Users group has been given Full Control of the folder containing the MDB file
- In both cases – working & broken – the file in Windows Explorer shows exact same file date/size
The broken example showed this:
After user manually copied the .MDB file which was EXACTLY the same into the C:\Program Files location, the application worked.
Finally the last clue – which is enough to tell you the cause – when another user logged on and copied the file, it still didn’t work!
What’s going on.
A quick ProcMon (http://live.sysinternals.com/ProcMon.exe) quickly demonstrated the cause:
The MDB is not being loaded from Program Files directory at all. It’s being loaded from user’s virtual store, located under %LOCALAPPDATA%\VirtualStore for the file system…
This occurred, because I guess in some past time users attempted manual upgrade. Without local admin it got redirected into Virtual Store. So they were now using a per-user copy of the application. When SCCM upgraded the application it ran as SYSTEM and replaced the version in Program Files; but users continued on with their old copy in the user profile.
Many times virtualization will work to your benefit saving you time mitigating crappy applications that put user settings to HKLM and Program Files (if you are not lucky enough to be using Citrix/App-V/ThinApp/&c)…but in other cases it can make for some interesting problems.
In this case we applied the NoVirtualization SHIM to Microsoft ACCESS to ensure the virtualized folders were not used.
To create the SHIM we used Microsoft Application Compatibility Toolkit (http://www.microsoft.com/download/en/details.aspx?id=7352)
We launched Compatibility Administrator (32-bit) and selected Create New Application Fix
We could then deploy the saved fix using sdbinst <NameOfFix.sdb>
Other articles on Windows virtualization of file & registry:
New UAC Technologies for Windows Vista
Tales of Application Compatibility Weirdness – Demystifying UAC Virtualization
Exploring User Account Control Virtualization