VMware View/Horizon and fun with file editing/saving

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
Published: Wednesday, 08 July 2015 21:25

A bit of a confusing header but I haven't found a better one. Let me explain what I mean.

Today I visited a customer that has a quite big VMware View/Horizon installation. Nearly all workstations are virtualized and managed by the VDI product of VMware. So far so good, the environment runs pretty well, more than 1000 persistent desktops are currently provisioned and actively used.

The customer found a strange problem today and asked us for help. The problem: one of his admins, working on a virtualized workstation, works with batch jobs to do his daily business. If he runs one of the batch jobs, opens the batch file after the job completed and tries to save any modification in the file, he gets an "access denied because the program is currently in use by another process". Strange because the batch job itself is really simple and the CMD is already closed because of an exit statement at the end of the batch. Process explorer and Windows Ressource Monitor don't show any process running that has a file handle on that batch file. Waiting for 2-3 minutes and then try to save the modified file again solves the problem.


I thought about UAC active on the workstation (it is a Windows 7 VM) so we did the same tests again but this time we opened the editor with administrative rights. No success, the file couldn't be saved, the same error message appeared. UAC was not the reason.

The VM runs Trend Micro OfficeScan. Since Antivirus programs are responsible for a huge amount of strange problems we disabled the scan engine and tried again but still no success.

We tested with another Windows 7 system not managed by VMware View/Horizon but within the same Active Directory and thus getting the same GPOs. That worked, with or without UAC. 

Using a Windows XP VM in the same View farm with the same GPOs succeeded too so it had obviously something to do with the combination of VMware View and Windows 7.

I'm not a View expert but the only thing View does on a Windows 7 system is to install it's client on it to communicate with the View infrastructure. Nothing that could cause such a behavior in my opinion.

So we decided to check what exactly is done from the very beginning up to the logon to the user in it's virtual workstation. The process is also quite simple: the VM is provisioned from a standard golden master image, is powered up, receives GPOs and the user logs on. Since the problem was reproduceable on any Windows 7 VM and with any user account we used, no matter if it was a local administrator or a simple user, the problem must be within the golden master image.

The golden master image is a blank Windows 7 installation with latest patches, a set of default software, the View agent and.... a special optimization for the OS to be used as a View VM. The special optimization is done by a script that implements best-practices for View installations like setting some special registry entries, optimizing general behavior and disabling some unneeded services to save memory. Disabling unneeded Windows services is a good thing but you should be always aware of the function of a special service and if it is really adviseable to disable a given service.

In our case one of the default Windows services, the "Application Experience" service was set from manual to disabled. The problem with this service is that if it is disabled the Windows Explorer sometimes holds locks on a recently opened file for an extended period of time. In our case, after running the batch in the CMD, the explorer held a lock on that file much longer than usual. When we opened the file a few seconds after the batch completed, the lock was still there and thus saving modifications on the batch file was denied.

Setting the service to manual, starting the service and reproduce the whole test we were able to save any modification in any timeframe after the batch job ran.

Quite curious that there is a service that is responsible for faster unlocking of files but hey, that's Windows. So always make sure you only stop that Windows services you definetly don't need in any way. Better spend some kb or mb for unneeded services than running around and search for the reason you can't save recently opened files....