Manually modifying appstack

[SteveWH]

The Appstack capture process seems too simplified in that you hit start, make a change, hit finish, and it bundles everything up into a vmdk. I am use to tweaking packages and permissions as well as trimming the erroneous data that was captured and not needed. Is there a way to open an appstack and see the data it captured? For example mount the vmdk and see the registry keys, files/folders, etc. and then remove data that shouldn't have been captures as well as adjust ACLs etc?

I ask because our helpdesk is receiving reports of odd behavior with an application and I'm wondering if there is conflicting registry keys in an appstack being overlayed. Being able to see what's in the appstack would prove this is happening and being able to then delete the conflicting keys from the appstack would resolve the problem.

[Lakshman]

Yes it is possible.

Attach the AppStack to a clean VM with no App Volumes Agent. (Go to Edit settings -> Add Hardware -> Use an existing virtual disk -> select AppStack VMDK)

Once the AppStack is attached, assign a drive letter (if required) and open the hidden folder 'SVROOT' to view all the files and folders in the AppStack.

[Ray_handels]

Although Lakshman is 100% right there are a few things to keep in mind.

This is a "don't try this at home kids" kinda thing, it's not very easy to just edit the appstack and keep it working after this. The fact that you know how applications in general works gives you a huge benefit though.

After an appstack is sealed it is being set as read only. The moment you try to attach it as persistent it will fail because deletable=false is being set. If you want to actually edit it you need to first create an update and then attach the newly created appstack BEFORE starting the provisioning process the way lakshman said. Then you can edit the appstack, remove files and remove registry keys. If you only want to view the info, just add it as non-persistent.

Also, if you are in an adventurous mode try and attach the snapvol.dat on the root of the appstack. Lots of fun stuff in there .

[mellicott]

Hi Ray,

Slightly confused by your reply as it doesn't fit with my experiences.  Obviously, we can't attach "current" versions of appstacks as they invariably have attachments to them so have become read only.  I usually update an appstack I want to look at/edit, then provision it and immediately finish the provisioning to create a new version with no assignments or attachments.  I then attach that new version as Lakshman described and can edit to my hearts content 🙂

Steve,

Once you've attached the vmdk to your editing machine, and assigned it a drive letter you can, as Ray says, have lots of fun in the registry.  Just in case, here's how ...

Assuming you've assigned your vmdk to drive E:, from a cmd prompt: -

reg load hklm\myvmdk e:snapvol.dat

Then run regedit, and under Local Machine you'll find a root node of myvmdk, and under that 3 sections defining the actual keys being stored, and the details of the files and file structure captured.  Be REAL careful in here, as if you delete the fact that c:\something\or\other exists in here, then the fact that it actually exists in SVROOT will be irrelevant!

Because I'm a stickler for keeping things neat, I do a reg unload hklm\myvmk after I've exited regedit and before I detach the vmdk.

Have fun 🙂

[Ray_handels]

I usually update an appstack I want to look at/edit, then provision it and immediately finish the provisioning to create a new version with no assignments or attachments.  I then attach that new version as Lakshman described and can edit to my hearts content 🙂

The edit before provisioning is more of a heads up that the moment you press done provisioning it is sealed again and set to read only , or at least that's my experience.

You can off course create an update, then go to provisioning, do some stuff and before sealing or accepting done, fiddle around in it as much as you like.

But as you said as well, I did my fair share of roaming around in the appstacks . My experience is to do the manual changes before provisioning just to keep it a bit simple and less error prone.

I will off course try and do some funky stuff in the appstack after the seal before assignment, if that works it's even better. We also had the option to change deleteable=false into deletable=true but that's just looking for trouble

[SteveWH]

This is all great information thank you guys! I wasn't sure I would hear from anyone so I didn't elaborate. I did preliminary research prior to asking this question on the community and found one site:

https://blogs.vmware.com/consulting/2015/08/cloning-appstacks-and-modifying-scripts.html .

It mentions the same steps of adding the vmdk to a VM that doesn't have app volumes installed. The problem is it didn't offer any additional information beyond that.

I followed the steps in the article and realized I needed to add a drive letter to access the 'CVApps' volume. As previously mentioned it appears the volume includes other items related to the operational aspects of app volumes and not just the captured data.

The two items I found during review that seems relavent were the SVROOT folder which appears to be the files/folders that were captured and snapvol.dat which appears to be the captured registry data in addition to metadata related to objects in SVROOT.

The snapvol.dat contains three hives - MACHINE, METADATA, and USER. It seems simple enough - MACHINE is HKEY_LOCAL_MACHINE, USER is HKEY_USERS, and METADATA is the metadata related to the SVROOT contents.

I am wondering how sensitive the app volumes solution is. If I remove a file/folder from SVROOT do I also remove the corresponding entry in the METADATA ? Did I miss anything else beyond SVROOT and snapvol.dat that needs to be taken into consideration to ensure the appstack will work or are these the only two areas in CVApps we care about? Is there any fling or 3rd party tool I am missing that helps with this process or is it really all manual?

I see responses mentioning a concern about the appstack being readonly and not being able to modify the contents unless you click 'update' and then mount the new non provisioned copy. It was suggested the workflow would be to update an existing appstack in the manager to create a copy and then to manually modify the copy, provision it, and then save it and assign to end users. My concern is this contradicts the reasoning for manually editing the appstack. I want to clean the image once it is already provisioning but unassigned. If I were to manually remove entries, and then go into provisioning it may just add the irrelevant data back when it attaches to the reference PC in order to finish the appstack update.

Can someone explain the deleteable flag? It was my understanding if the appstack isn't currently attached to a user I could manually edit it because it wouldn't be referenced. To that end I would remove assignments to the appstack to ensure noone had handles to it, and then manually modify, then rescan in manager and add assignments. Alternatively if it's one actively being used in production environment I would copy it finalize it, and then manually edit it before assigning it to users/groups. Where would the deletable flag come into play in all of this?

[mellicott]

Hi Steve,

Another file you will find very useful is snapvol.cfg.  It controls what "parts" of the PC are not captured during provisioning, ad which parts of the registry are captured to where. In fact, I've been sat here all morning wondering why a Kaspersky management console wasn't working in an appstack for me when I realised that c:\program files\Kaspersky lab is excluded in snapvol.cfg!

If you have an instance where you didn't want the contents of c:\blah\blah\blah in your appstack you could edit it after provisioning, as we've been discussing on this thread, or add c:\blah\blah\blah to snapvol.cfg in an exclude section.

exclude_path=c:\blah\blah\blah

Another thing to remember is that provisioning is like a recording of an install.  We had an instance once where an "update" to some software deleted a file, then wrote a new version of that file to the same place.  The provisioning process recorded the deletion and therefore the file was never made available to Windows, even though I could see it in SVROOT!  Look for svdeleted keys in snapvol.dat.

The blog you mention is also useful.  For instance, to get Visual Studio working well we put a command at the end of the Startup.bat file for licencing.

Product key added to Startup.bat by way of the following lines...
-----------------------------------------------
rem - Added by MJE to apply licence code at startup of each session.

"C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\DDConfigCA.exe"

"C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\StorePID.exe" XXXXX-XXXXX-XXXXX-XXXXX-XXXXX 99999

-----------------------------------------------

There was talk of an "appstack editor" fling but have not heard anything of it for a year or so.

[SteveWH]

I did see talks about snapvol.cfg during my research but it was always mentioned in regards to writable volumes and not appstacks.

Both

https://blogs.vmware.com/euc/2016/03/app-volumes-snapvol-cfg-writable-volume-customize-configure.htm...

and https://docs.vmware.com/en/VMware-App-Volumes/2.12.1/App-Volumes-User-Guide-212-1.pdf

mention  snapvol.cfg for writable volumes and not appstacks.

To make it more confusing there was a KB article: https://kb.vmware.com/s/article/2146963 that talked about an appstack snapvol.cfg and a writable volume snapvol.cfg which hints to what you mentioned - that the snapvol.cfg does infact work for normal appstacks and not just writable volumes despite not being listed in the user guide or blog websites that describe snapvol.cfg .

I will take a look at snapvol.cfg as well to see how it works in our environment. Thank you for the additional info on the svdeleted keys as well as modifying the scripts to perform actions like licensing. 

[SteveWH]

I did find a site http://appvolume.readthedocs.io/en/latest/ that appears to be from the App Volumes dev team.

It has information written by Principal Engineer Matt Conover and Staff Engineer Art Rothstein.

In the guide it clarifies that "SvDriver is a policy-driven driver file responsible for the virtualization of volume contents into the desktop OS. The policy file snapvol.cfg controls the files, directories, registry keys, and processes that are virtualized during application capture on each volume. The log svdriver.log tracks this activity."

This explains how snapvol.cfg is used for both appstack and writable volumes - it is the policy file that svdriver uses for all virtualized volumes used in App Volumes.

Another area discussed that may be helpful in determining what is being captured:

"The SvCapture service performs provisioning and editing functions during application capture, such as generating policy files and metadata. The SvCapture reports this information to the App Volumes Agent and App Volumes Manager. svcapture.log tracks this activity and is available only on the capture machine.

For information to increase the logging level to debug, see Increasing Logging Level for AppVolumes Manager (2101668)."

I haven't reviewed the svcapture log file to see what information is contained but it's nice to know it may provide a summary of what was captured so the person doing the appstack provisioning has better insight. I still believe mounting the vmdk is the best method to review the files/folders/registry keys and policies related to the appstack.