Poll // App-V 5.0 Default Full VFS Write

Question

Curious who has as default the 'Full VFS Write' enabled when sequencing. Why or why not?

Answer 1

But when you need to enable Full VFS write for an application, do you perform extra monitoring or other security related measures on that application?
If you don't do anything extra on those packages, I don't see why you would call enabling Full VFS write a security related thing.
Sorry to be persuasive.. I'm trying to write app-v 5.0 packaging guidelines which will be used by offshore packaging factory's. So I'm trying to write my guidelines as general and as easy possible so intakers
don't have to struggle with seeking where to put permissions.
The reason this is difficult to answer is because it really has nothing to do with App-V and will be pretty business ISO specific.
At the company I work at, our standard is to enable the VFS write option, but we also don't make developers jump through hoops if an MSI based install requires its own install directory opened up. 
So forget App-V, what would be your standard in a typical (re)packaging environment?
That said, there are always 2 sides to the coin with enterprise application compatibility and App-V (really application repackaging).  The tighter your standards the lower your success rate will be to repackage software.  Remember, just because
a software is a vendor/in house MSI doesn't mean it isn't opening up random folders for everyone to have write access!
VERY VERY simply put, our standard is to make App-V applications work.  Coming from a long history of working MSI based packaging, its difficult (putting that lightly) to go back to a developer or vendor and ask they do something differently so we can
repackage to App-V -- even if their coding practices are bad (writing per user info to the install directory, etc).  Right or wrong the response tends to be 'did it used to work?' or, 'did it work when you installed my MSI with admin rights?'.
Like I said, I open up VFS write in App-V 4/5, I also enable all COM options in the GUI advanced tab of the sequencer.  We are actually thinking about turning OoP COM and IP COM = true also.  We aren't really concerned with application isolation,
because this has all been worked out over the last decade of traditional installs.  Sure it comes in handy here and there, but I would always sign up for the less isolated/higher functionality App-V (streaming with 0 isolation would be pretty cool!). 
My 2 cents is to look at the existing process, and also look at what your developer relations / in house expectations if you have an app that requires permissions. 
And keep in mind a few random thoughts:
Registry writing is always enabled, a standard user can write to the virtualized HKLM keys
What will you do if you require open writing to a VFS directory? 
What will you do if you require open writing to a physical directory (that you cannot virtualize)?
What will your exception process look like? (because their will always be exceptions)
What is your ultimate goal to App-V packaging?  App-V success rate? Creating an easy to follow workflow, where easy to App-V packages are spit out, and others are returned to traditional packaging methods?