Writable Volumes TEMP profile folders

[RexP0wer]

We are in the process of migrating from roaming user profiles to VMware App Volumes (ver. 4.3) writable volumes and we are also using VMware DEM (ver. 2009) with View 7.13 (linked-clones, floating assignment)

I have a case open for my question below with VMware but they haven't been helpful so far.

On my View Master Image, I have a domain admin account, Admin.NBName (in this example, NBName is the NetBios domain name) that I use for scheduled tasks that run after a user logs on to the View desktop. (one of these scheduled tasks checks for the successful load of the user's roaming profile and the successful attachment of their Writable Volume, logs this to a UNC path file and then removes the user's roaming profile attribute from their AD account).

What I'm seeing with some of my users, is an accumulation of very small (2.9 MB) directories in their Writable's SVROOT\Users directory along with their SVROOT\Users\<username> directory. For example, SVROOT\Users\Admin.NBName, SVROOT\Users\Admin.NBName.000, SVROOT\Users\Admin.NBName.001, SVROOT\Users\Admin.NBName.002 etc, or SVROOT\Users\TEMP, SVROOT\Users\TEMP.NBName, SVROOT\Users\TEMP.NBName.000, SVROOT\Users\TEMP.NBName.001, SVROOT\Users\TEMP.NBName.002, etc. These directories will have the Admin.NBName's NTUser.Dat

Some users will have combos of both, some might jsut have lots of TEMP directories. If I mount their writable, I can see that snapvol.dat has references in MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid to these Admin or TEMP directories. The SID of this domain admin (Admin.NBName) will instead point to C:\Users\TEMP or one of the other variants listed above. I'm assuming that this is partly due to the line, virtualize_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid which is in my snapvol.cfg file. I feel like this line is not doing me any good, but I can't find any guidance one way or another about whether to lose this.

I've only been using AppVolumes for about 6 months, but this seems sub-optimal. Should I be concerned about this? My snapvol.cfg file virtualizes \Users I'd like it to only virtualize \Users\<username> but all my tests with this (virtualize=\Users\%USERNAME%) have been disasters.

I am also aware of AppVolumes custom batch scripts capabilities but I can't find any examples of these and don't know whether I could even use them to clean up directories like these.

I also have not found anything in the svservice.log to show my why this is happening, is their some means of capturing this info? Has anyone else encountered this?

[Jubish-Jose]

Hello @RexP0wer 

I don't have a solution to your problem and not sure why it happens, but personally I will avoid App Volumes wherever possible. Its not a stable solution IMO. App Volumes 2.x was non-usable but 4.x is far better.

I don't know about your exact use case, but have you considered Microsoft FSLogix for profile management? We are using it for almost a year and so far its been stable. There are plenty of resources available about it, let me know if you want more info. 

[RexP0wer]

Thanks popvm.  We considered FSLogix about a year ago, but got too sweet an offer not to go with App Volumes.  I have seen others echo your sentiments in forums like this.  But for now, the overall performance we've had with AV Writable Volumes has been good.

For though moment, I'm confident that there's a workaround (should one be necessary). But I do appreciate your input.  Thanks

[RexP0wer · Accepted solution]

I was able to fix this issue. The problem was the scheduled (logon-triggered) tasks running under the Admin.NBName account. Once one of these tasks started, the SID of the Admin.NBName would be loaded under HKEY_USERS and AppVol virtualization would capture both HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid & HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid. Since the Admin.NBName SID already existed on the master image, a SID-bak key would be created and the SID key would then get one of these new TEMP paths.

The solution was to convert the scheduled tasks to run under the SYSTEM account, which took some work for the task that was accessing UNC paths and changing AD attributes. After I had converted the tasks to SYSTEM tasks, I was able to completely remove the Admin.NBName profile from the master image.  No more problem.