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?
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
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?
what type of template are you running with writeables
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.
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.
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:
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.
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.
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?
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.
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.
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.
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.
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.
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?
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
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.
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.