Ray_handels's Posts

Hey Eric,   We have the exact same issue and I also see that the record pae-GSSAPIConfigDN for the servers are not configured for 4 of the servers. When looking at the OU=Authenticator,OU=Properties,DC=vdi,DC=vmware,DC=int settings I see 6 records, 5 of which are filled with information of 2 of the connection servers (which also have the pae-GSSAPIConfigDN record in it) but 4 connection servers don't seem to have any information in both options.    Did you have any reference between the servers and the authenticator to be able to fill in the correct information? Regards, Raymond

Hey Guys, We are using CB CLoud but are seeing the exact same behaviour when importing reg keys form the zip file. Any news on exclusion you should be making for DEM or any best practices other than the ones shown on the official channels?? They tend to not always work.

Hello @DEMdev    has been a while since I have been on the forums, been a bit busy :). We are seeing this exact same issue on a 2019 fileserver with DFS. When adding the actual location to the fileserver the application is not being blocked but still, if we go to the dfs share we cannot open the application there. With the exact same issue as noted in the other posts that we don't see the dem error message but with th group policy message. Any idea on a solution??  

Hey ctrim,   What is the actual issue you are having? Just to make one thing clear about Appvolumes appstacks, they only hold machine information, no user information. So anything within the HKCU or C:\Users folder is not registered within an appstack. If you need to have specific user setting you should be using DEM for that. Normally this is also within your Horizon license. All user settings are managable with that. You could go the writable way but I would not suggest that to be honest.

Hey @Micheal_A that's strange because we have the exact same issue and they are stating that it is being checked by by engineering. I do have another workaround which is not supported, at least that's my guess. Will point out here that I am not a VMware employee and use at your own risk :). When you run a select * from snapvols command towards the database there is a column there that is called Attachment_count, this holds the info if a snapvol is indeed attached. If you manually change that to 0 you are able to remove the application and it will remove the packages as well. As a cross check I would also make sure to also use the following  select * from snapvol_attachment where snaopvol_id = <ID of the snapvol>. This should not return any results, otherwise it actually does have an attachment towards some machine but at least you'll know which one it is. But to me this seems to be a bug in how Appvolumes registrates the attachments in the database. It should normally run a check for every snapvol (which actually is a package) if it still has attachments in the snapvol_attachments table.

Oh man, sorry now I understand.. Man did not read that correctly. When migrating from version 2.x to 4.x the option to deliver the application "On Demand" (directly even if the user is logged in) has been removed because they were either unable or not willing to add this feature because it did have some issues with the 2.x version, mostly the option to remove the application when the user is logged in.   It seems that the 2.x agent is capable or "importing" a manually added disk immediately whereas the 4.x agent is unable to do so. That being said, the new Appvolumes 4.x agent (2111) has a new feature which is called App on Demand. My guess is that this is what you need or want to have. Do keep in mind (haven't had a chance to test it) that you need to create a new package and mark in On Demand Apps On Demand Now applications can be delivered on-demand when a user clicks to launch the application from the desktop and start menu just as if the application was already installed natively on the Windows machine.  The setting is available for newly created packages and the admin has an option to select on-demand for this new type of delivery, or classic, to have the user and computer assigned applications delivered at login and startup as they have in the past.

I do understand that the manager won't see that but the thing is that the template (the VMDK all appstacks are based on) or so much different that I don't think you will be able to use a 2.x VMDK on a 4.x agent so what you are seeing is by design, at least that would be my understanding. What happens if you browse to the Firefox installation folder after attaching the 2.x appstack to a 4.x machine?

Hmm, wrond account i logged in with :). If you exclude soemthing from DEM the only downside is that it will not be placed back when you log in again, that's about it. Depends on how important the info is.  

Short version of the answer, no you can't.  I would also suggest not using the migration tool as Appstacks are build totally differently in Appvolumes 4. I know it is an option but we have some bad experience with it in regards to stability and performance. Also, in 2.x you bundled applications for a better performance while logging in, in 4.x you want to have an appstack for every single application.

You did make sure that you attached a drive letter to the disk? Normally these are created with a disk setting that it does not automatically receive a drive letter. Also make sure to show hidden and system files.

It is not really best practice to set Office applications to Flex because it is integrated with the OS to much to do that. Did you check waht info is stored within the common.zip file? Are these the shared office settings? You could try to check and see if it is possible to exclude certain paths but looking at our config I don't see those large files in our environment. I'd suggest looking into the .zip file to see what is the cause of the large file.

For as far as I know if one is assigned to the current version (and thus assigned to the marker package) and one group is assigned to the package, the package assignment wins. I have tested this and it works if you assign the package to a specific user account, I haven't tested it with a group though but my guess is that it is the same. Do keep in mind that this is only possible with version 4.x of Appvolumes.

Did you try adding the disk to a machine that does not have an Appvolumes agent so you can actually see what is being stored on the writable volume? We have seen this issue mostly within TEMP folders that are not being excluded from the writable. That being said, 10GB is not enough. We used to have 20GB which workd quite well if configured correctly (which is NOT out of the box ).

Yes there is a workaround that has been documenten bij Laurens van Duijn but to be honest I would nog suggest doing that because you need to alter the database for that. When you look at his post you will see that it has a lot (and I mean a lot :)) of disclaimers that you should NOT be doing this https://vdr.one/app-volumes-4-0-app-stack-os-mount-hacking/

No it is not possiblew to do it like that. If you need to change an appstack with a snapvol.cfg it means manually editing the appstack after you create an updated version of the Appstack. For writables you could use the upload file option within the maager. a GPO does NOT change anything in regards to the snapvol.cfg in the appstack itself.  

You can simply add that user with a package assignment to the V2 version even if it has the V1 version also assigned due to group membership. You will see that the package assignment always wins from the marker assignment. This is a very neat featuire of the Appvolumes 4.x version.