Ray_handels's Accepted Solutions

Yes and no. Yes, the snapvol.cfg is not indeed added into the GI which is very nice because you can edit it once for all users. You should first create a folder C:\Program Files (x86)\CloudVolumes\Agent\Config\Custom (the custom at the end is important). Within this folder you can then create a new folder (just check the default directory for naming convention) like app for appstacks or uia for writable uia only and add a snapvol.cfg in that folder.

Hey. Also a small note here. Writables only work with VDI, not with RDSH so you can skipp that part. What it does is it attached a disk that is read/write and all changes ae being saved to this disk. The Appvolumes filter driver then merges it with the machine as if you are using a local machine. Writable is always attached to either a user or a machine. You can however exclude very specific information from what appvolumes should store on the writable.   Does app volume saves all users data (downloads,copied files,....) in any folders of RDSH pool and user profile? If you do not redirect that information yes it will. I will always suggest to redirect Downloads, Pictures and Documents, do NOT let than land in a writable. Does app volume migrate  profile and files of a user that before assigning writable volume logged on locally ? No it will not. The first time a user attaches a writable to his or her VDI when logging in that's the moment it starts to build up the writable. If you disable the writable the user can log into a complete fresh machine. Does writable volumes works good for profile? Depends on what you try to achieve. If you are only worried about specific parts of the profile I'd suggest going with DEM. If you need everything (and i really mean everything) than writables could be an option for you.

I think you should look for the admin guide on how to setup Appvolumes. What you are asking here is how do I set it up. Try setting it up and if you have any questions feels free to ask. Basicly (so just a few poniters) you install the agent within the virtual machine (your Golden Image) and point that to the manager you installed. Within the manager you can create apopstack. When you want to create an appstack make sure to have a packaging machine (which is a clone of your GI without View agents) and install it inthere. Log in with a local admin account on the machine but to add it to the domain. It won't attach an appstack when logging into your packaging machine.

Installing on the GI always works for as far as I can tell. There is one forum post here in which is stated that you can reset the PidCode with an exe and reset the license hash with an application. If you add Visual Studio in an appstack that's the only way I have seen it working.   Installaing Visual Studio is extrmeley straightforward, just as you would when installing in normally on a machine.

Looking at version 4 of Appvolumes you need to rethink in how you would like to add applications. Why are you putting 4 applications in one appstack? We did this because otherwise logon would be very slow and there was a suggested limitation of 10 appstacks per machine. So it was completely viable to put multiple application into one appstack, even better this was best practice. Now to version 4. When looking at attachment you can add about 60 appstacks (15 disks per SCSI controller, 4 SCSI controllers on a VDI), is that something i would do? No not really but it is possible. Looking at login times with APpvolumes 4 we see that having about 15 appstacks there login is just as quick as about 5 to 6 appstacks in version 2. So the need to create 1 appstack with multiple applications is no longer needed per se. So you have the option to create an "Appstack" (it is called package in 4) for every application. I would suggest doing so as it will make your live a lot easier because no need to update 1 appstack with multiple application and being afraid of messing it up the entire appstack for that 1 applications. That being said you can still add multiple application int 1 application/package in version 4. This still works and you can still fiddle around with assignments. The current option is there to make your live a bit easier because you can very quickly update an application, just set it to current. You also have the option to assign an older or newer version to a specific subset of users by assigning to a package and not the current marker.

Nope, is an issue with Appvolumes that has been addressed a while back and came back in Appvolumes 4. You need to set the nodefaultdriveletter value for the appstack, here's the official KB article. VMware Knowledge Base Downside is that you need to edit this or all appstacks..... Good news is that it will al least work after that... And as you can see it says CVApps, not CVWritable. This is your appstack, not the writable.

Hey, here are some pointers. - What machine to use for creating App Volumes, clean machine, with or without office? I'd suggest creating a clone of you Golden Image, this way the machine is almost the same as the machine users are getting. Add it to the domain (off course change the name if the GI is also domain member), and log in with a local admin. Also make sure to place the machine account in an OU that has no policies whatsoever. Otherwise you might endup with poliies in your appstack. - Do you need to start the application during capturing (such as by ThinApp). It highly depends on the application. Looking at THinApp or Appv you can also capture first time run keys that are stored in HKCU or C:\Users. An appstack does not record these settings and thus there is no need to start the application for those settings. If you need to add a reg you you obviously need to start the application. My rule of thumb would be NOT to start the application. - We are going to use NVIDIA GPU in our environment, do we need to create the App Volumes on a machine with the NVIDIA GPU? Nope, you don't. The appstack does not depend on the existence of the vGPU. - Sometimes during installation hardware needs to be connected, for finalizing the driver, how can we do that. I'd say you can't. You would need to install the drivers either in the GI of as an MSI during packaging. It also depends which drivers you are installing. If you look at print drivers for example. Appvolumes has a build in feature to restart the spooler after it attaches all appstacks. This is due to the fact that an appstack could hold a print driver (looking at you Adobe Pro) and it needs to be attached afterwards. If it is some sort of a kernel driver or maybe even a smartcard driver that you need to log in it can't be loaded after startup of the machine. Keep in mind that the appstack is attached during login (or you must assign it to a machine). I would suggest installing those drivers into the GI.

there are some features that are not yet implemented in version 4.0 and there are a few bugs that they still need to fix for it to be 100% stable. To be honest I have been using 4.0 now for a while and am quite excited about it up until now. 2 features that are not yet implemented is selecting multiple OS'ses for an appstack so you need to create it on both W10 and Server 2016 and the other one is that you cannot use a machine prefix when assigning appstacks. Also keep in mind that 2.x works very differently than 4.x as it comes to assigning applications. In 2.x if you wanted to add a lot of applications for a specific user you needed to bond them together and assign them as 1 appstack. In 4.0 you create an application/Appstack per application which is much easier in assigning applications to different users. Logging in with 20 appstacks still is quick.

It seems as if one of the created datastores can no longer be found or has been removed from the vcenter. You could try and remove that datastore from the database but I would suggest creating a ticket with VMware. Your other option (if this is a fresh install and you only have a few appstacks) would be to reinstall the manager and recreate the database. If you connect to the exact same datastores where the applications and writables are stored you can import them automatically. Only thing you need to do again is assign the packkages/appstacks again.

There are events being added into event viewer in which it states that all appstacks are merged. Also, Ivanti and Appvolumes is not the best of all combinations.. I have heard of quite some issues getting those to work nicely together.

If a writable has never been used then yes, I would suggest recreating them. The only thing that normally is being changed on a new template (you do need to upgrade the templates as well, otherwise there is no need to recreate them) is the snapvol.cfg. This is the filde that determines what files and folders are being excluded on the writable. Sometimes changed within this file will make the writable better. You could try and compare both version of the snapvol.cfg to see if a lot has changed within those versions.

At the end of the day what I want to achieve is to have 2 sites and appstacks and writables available at both sites at all times. A user at Site 2 might never have to log in to Site 1 but in case of disaster I would like to have that synchronized and available in both places Simple answer, no you can't. If you look at appstacks, these are read only and thus can be "copied" or synced to all datastores and be attached there because after sealing, they never change. If you look at writable disks, these change every time you log on. If you were to have 2 physical locations where the same writable is being stored Appvolumes would not know which location to choose from, also if you attach the writable from datastore A, change stuff, log off and log on again and receive writable from datastore B you won't have the change available on your writable. Only thing you can do is move the writable from datastore A to datastore B if a user moves from locations..

I believe that this is the infamous MSI installation issue. Try removing the cumulitive update patch or try upgradeing to version 2.17, i believe the issue is fixed there. There is a thread regarding this issue..

Apparantly they did change that behaviour in the last few version as we were able to install visual studio 2018 using our package machine. If you are able to use a newer version of the product I would give that a try. To be fair about it. This is not really an issue of Appvolumes as it is more of an issue with Microsoft. I normally would not think that free software does check some sort of GUID when installing, because it is a free license but apparantly Microsoft thinks otherwise.

The appstack is read only and it does not contain any user data like APPV. Thing is these are physical paths and there is no isolation so Appvolumes will not be able to store any info that is whithin the c:\user of HCKU into an Appstack. So you are not doing anything wrong, it is just how it is build. If these are just files you could try and copy them during logon with UEM. Or run an install every tiome a user logs in to install that functionality. If you ask me, installing software into the user profile is just bad programming. Normally you would be able to get an administrative installer that puts data into the program files folders. If not you should be looking at workarounds.

Hey sjesse, This has been discussed in one of the topics on the forum, i believe the question was related to moving Appvolumes to a new storage. What we needed to do was first create the new storage, add it to vcenter and import it in Appvolumes (just just re scan at storages, it will automatically add it). Add this new storage to the storage group so it will sync appstacks automatically and then remove the storage you won't be using anymore. You can do the re scan for Appstacks after that and it will mark the appstack as missing on that old storage. Then you would need to alter the database, go to the snapvol_files table and remove the appstacks from the specific datastore you removed. In this table only the ID of the datastore is shown, make sure to write that down before removing the datastore. Reasoning behind this is because if it would automatically remove these records in a worst case scenario this could happen if a datastore for whatever reason was not available it would remove all references to this datastore, that's not something you would like to do.

First of all I would highly suggest upgrading to a newer version, 2.10 is very old and has some bugs in it. Try going for 2.15 first if your reluctant to go to 2.16. Can i reboot the Windows 2012 box hosting Appvolumes Manager 2.10. ( Standalone). Or do i have to detach all Appstacks first ? Yes you can reboot Appvolumes manager even if it is a standalone machine, you don't need to detach first although I would not suggest using just a single Appvolumes server. Thing is that users logging in wont get their appstacks attached (not the biggest of your issues, just relog after Appvolumes manager is up) but if a user logs off and your Appvolumes manager is down it wont reconfigure that machine so the appstacks are still attached. You would need to manually reconfigure those machines. If it is just a few it might be an option. If i do reboot Appvolumes Manager , what is the effect on currently attached appstacks. They stay attached. and Lastly when Appvolumes Services start. will it sync and discover all attached Appstacks ? No, not really. Normally twice a day Appvolumes checks for stale records and will detach the ones it find where a machine has an appstack attached but no user logged in. Still, I would not suggest rebooting a single Appvolumes server during production..Either create a second one so you do have it load balanced or do this during off hours.

Normally when you try to install Appvolumes manager it will try and create a database on the SQL server you selected. Because it tries to do this with a computer account (the service start as local service I believe) you should make sure that the computer account has correct permissions. I would remove the manager installation, reinstall it and select overwrite database if available. Normally this should do the trick. Only do this if this is an empty database!!

It's GOlden image --> Appstacks --> Writable. And although I can't conclude for 100% I believe the last appstack that is assigned wins. Looking at Java isn't it that it will seek for any available JRE versions and assign one of them? You should be able to select the proper version to use and safe that setting using UEM.