jhyiesla
Contributor
Contributor

App Volumes Writable Volumes not working

I am doing a POC on  App Volumes.

I have the AV manager installed, the agent installed on the master with linked clones built and one app stack created. This all works OK, so I am confident that connectivity for AV is working OK.  Then I created a writable volume and assigned it to the group Domain Admins, which I am a member of.  This also seemed to go OK.  However, when I log in as me - a domain admin - and make any kind of change to the VM whether installing an app or writing and storing a document it never gets saved. I have looked in the AV manager and I can see where my user has a writeable volume and it's enabled, but the state stays detached.  Even if I log in, the state is detached.  What am I missing?

Thanx... Jon

19 Replies
Gaurav_Baghla
VMware Employee
VMware Employee

Just to Isolate this further Could you please create a Writable for Test account and perform the same test. Domain admin should create Writable but just Wanted to isolate further

Regards Gaurav Baghla Opinions are my own and not the views of my employer. https://twitter.com/garry_14
0 Kudos
jhyiesla
Contributor
Contributor

To be blunt I am totally unimpressed with the Writable Volumes part fo App Volumes.

I did as you suggested and created a separate user and attached a writable volume directly to that user. It still didn't work.. So I detached all writable volumes and remove all app stackassignments. Then I went to the master and attempted to remove the agents, but this left my master in a totally unusable state.  After building a new master I was able to get linked clone desktops working again and then I added back in the AV agent. So now I go back to the AV manger and I attach the app stach to the three desktops that I have created, which worksOK.  Then I create a writable volume and assign it to a new user who has never been on the desktop before. I log into one of the desktops using the View client and I can see the app that I had buried in the appstack. I did notice that when I logged into the desktop, I was prompted to restart because of some change.  I can't do that since these are non-persistent desktops and we refresh them upon reboot, I'd just get a new desktop and have to go through the same thing again. So I went on and created a file on my desktop. Then I logged out and back into a new desktop.  The file was not there, I once again, got th reboot message, and I could see where the writable volume was NOT attached. This doesn't seem that hard, but this is really not working.What could I be doing wrong?

Jon

0 Kudos
ChrisBCarlson
Enthusiast
Enthusiast

what type of template are you running with writeables

For me.

when assigning a writable volume to a computer.

1.make sure no user is logged in and has not logged in before

2.assign writable volume

3. restart computer or computers

4. log into desktop make changes.. log off. (maybe even restart)

5. log back into desktop check if data is still there.

0 Kudos
jhyiesla
Contributor
Contributor

I don't have it pulled up right now but I'm using the user profile and app template - sorry probably not the right name.

I'm not assigning the writable volume to a computer, I'm assigning it to a user. I've made sure that the user has never signed onto the desktop before so there should not be any local profile for him.  However, we are using linked clone desktops that refresh every time the user logs off, so restarting the desktop really doesn't buy me anything since it will be set back to a pristine state.


0 Kudos
ChrisBCarlson
Enthusiast
Enthusiast

is the user and admin? i believe for worktables it has to be an admin.. for whatever reason they couldn't develop the app volume agent to run as a different account? not sure why.

i would suggest making sure it is admin.. if not, make it admin.. if that doesn't work trying making the pool persistent. As a fellow IT admin i hate to tell you to try all these things without knowing if it will work or not, but i guess that is our job :smileylaugh:

0 Kudos
jhyiesla
Contributor
Contributor

yes, the user is a domain admin as well as an admin on the desktop.

And I also notice that the prompt to restart each time I log onto a desktop goes away if I remove the App Vol agent from the master  and then rebuild. If I put it back and rebuild the desktops once again are prompted to restart each time I log onto one of them.

0 Kudos
ChrisBCarlson
Enthusiast
Enthusiast

i know for me when i start the provisioning process or assigning a writable volume to a computer that i reverted a snapshot to. sometimes i have to restart the computer in order for changes to captured. that could be what is going on with you.

0 Kudos
jhyiesla
Contributor
Contributor


OK, perhaps I'm just doing this wrong, but it seems pretty simple.  I add the AV agent to the master, the I create desktops.  Then I go in and I assign my test app stack to all of th desktops and I assign a writable volume to my user. Am I missing something here?  Since these are linked clones with refresh immediately set, restarting the desktop really shoulnd't accomplish anything.  The App Stack seems to work OK, but I never get the writable colume to attach.

If I opt to just not use the writable volume, does Persona management still work OK?

0 Kudos
ChrisBCarlson
Enthusiast
Enthusiast

i am still testing it. i have not tested your scenarios yet. but i will get some time maybe late this week or next week to try and test some of those things so we can see if we are on the same page.

0 Kudos
ecleppe
Contributor
Contributor

Correct me if I'm wrong, but I thought it's either assign both Appstack & Writeable to a computername or assign both a user.

I don't think you can mix up the assignments.

0 Kudos
hockeyguyin714
VMware Employee
VMware Employee

Are you using an evaluation license?  Evaluation license only allows 1 AppStack or Writeable Volume to be attached at any time.

Do you have a user profile on the VMs you are logging into previously?

Is the AppStack attached before you try to upload the Writeable Volume?  If so this is a safety precaution as Writeable Volumes have to be attached first and the restart would be requried.

What is the version number of your App Volumes Manager?  This can be seen by going to the bottom of the App Volumes Manager page.

If you are using Computer assignments as one user suggested you cannot user/OU/group assignments.  This is to avoid multiple users logging on at the same time and or off causing lost data and unwanted removed applications.

0 Kudos
jhyiesla
Contributor
Contributor


I think we figured it out.  I had two issues:

1. Even though using a WV on a Non-persistent desktop is kind of dumb since it gets whacked at reset, apparently you are prohibited from doing it as well.  For my test bed, I was using NP desktops.

2. As one poster pointed out, it appears the AS and WV BOTH need to be pointed either to users or computers.

When I switched to persistent desktops and assigned both to either a user or a computer, the WV worked.

However, given the extreme limitations of such a thing, I fail  to see the real usefulness of the WV. You can't user it on non-persistent desktops, you have to assign it the same as the AS and it gets wiped if you redo the desktop....Don't really see how this is much better than Persona management. IF we go the App Vol direction we'll probably not waster the time and energy on the WV.

0 Kudos
Jason_Marshall
VMware Employee
VMware Employee

The assignments for any App Volumes volume must be to either directly to the machine or the user. You can not mix and match today. Sounds like that was the issue? Assigning one as a machine and the other as a user/group/OU? You absolutely can use a WV on a non-P desktop and in fact that is the primary use case. I wonder if it was the assignments that got confused. BTW this will be addressed in a future version.

0 Kudos
ChrisBCarlson
Enthusiast
Enthusiast

will microsoft updates be captured in the writeable volume?

0 Kudos
JaceJ
Enthusiast
Enthusiast

I believe that depends on a number of factors.

1.  What template are you using.. If you are using the profile only it wouldn't  If you are using UIA only or UIA plus Profile it potentially could under the right circumstances.

2.  How do you apply updates to systems.  If you are on a NonPersistent desktop you should be applying the update only to the master image in which case you shouldn't capture an update in a writable volume.  If you give your users admin rights (Not something I'm a fan of for multiple reasons) and/or you don't manage when updates get deployed then I can see where it's possible it could be captured. 

0 Kudos
ChrisBCarlson
Enthusiast
Enthusiast

this is a persistant desktop with UIA and profile. i am trying to install a powershell update. However it is not working and i read an article were someone was having the same issue and their profile was on a different drive letter and that was causing an issue. So i assume that with this writable it is getting redirected to another drive letter and it is causing this update to fail. at this point i am on the fence on if i want to disable writeable and try and install. but that might mess it up because i will have to re attatch it the same machine were i logged on to. not sure if that will work?

0 Kudos
Jason_Marshall
VMware Employee
VMware Employee

Yes they will and this is kind of the way it works. Since App Volumes is essentially virtualizing the OS anything that would be written to the OS will be virtualized in some way. So even if it does not get stored directly in the Writable volume it will be stored in a temp location on the OS. This means that even if you are using a persistent VM, App Volumes will still essentially make it a non-persistent VM because the changes will still be virtualized. That said ideally App Volumes would be used in a linked clone, PVS, MCS, etc. environment anyway in which case Windows updates should not be turned on in the first place Smiley Wink

cyberfed2727
Enthusiast
Enthusiast

Thank you for this post. We had the same issue. We are doing a test pilot of a fresh 2.10 install.

We struggled with this same issue of not attaching WV's. No where in the official documentation does it mention you cannot mix and match your assignment types (computer vs user assignments).  After finding this post we switched our AS and WV to both use user assignments. Worked immediately.

0 Kudos
Ray_handels
Virtuoso
Virtuoso

To be honest there once was word of this being added as a feature that you can attach both to users and computers. Issue is the writable volume that always needs to e the first disk in the machine because it is the read/write disk. I really hope that this will be implemented in near future.

0 Kudos