D81

Thanks @StephenWagner7 for the tips, then would you recomend to use GPO or DEM for folder redirection? is there any pros and cons from each choice?

duplicated post

OK thanks for the clarifications... anyway we will not use that feature any more. By te way the Interoperability matrix is fine, no incompatibilities detected.

New update, after talking with the Omnisa support technician, he had told me that the "ESXi mount" option is not recommended in our case. The explanation is here: https://kb.omnissa.com/s/article/92921 In summary that feature is going to be deprecated due to many issues with it and it is not recommened for App Vol4.

Thanks for sharing... I plan to use GPO or DEM for folder redirection and use it for My documents, Desktop, Images and probably nothing else. The rest of the folders would be excluded from FSlogix so when the user log off the Instant clone will destroy them.

Hi everybody! Big update here, after checking the issue with a work colleage, we have found the source of the problem... First of all we have performed a test by manualy attach of the testpackage.vmdk to the packaging VM and we have confirmed that the disk was correctly attached, also when doing the manual disk attach the App Volumes Agent has automaticaly started the pacaking process. So we performed a complete installation of the Notepad++ application as if we were packaging it. However after rebooting the packaging VM to end the package process, we realize that the App volumes manager still didnt detected the package, instead it was showing the "PACKAGE" option to start the package process as if nothing had happened on the packaging machine. We have also noticed that on the vCenter there were no tasks acctions or alerts when we launched the initial package attachment. So at that point we suspected that the issue was related with the communication between App Vol manager and the vCenter or the ESXs. Then we check configuration of the vCenter on the App Vol Manager and we disabled this feature to avoid the direct mounting of the packages by the ESXI servers And voilà! that fixes the issue!!! So at this point we are able to perform the packages normaly without problem only if we disable the "Mount ESXi" feature. However we would like to know why that "mount ESXi" feature is not working cause as far as we know it allows a better performance and thus we would like to reenable it on the future. Could anybody provide us with the requirements to use that feature? For example: Which ports should be available on the ESXs and from which source? Should the iCMP be available? Notice that the "ping" is not allowed on this LAN for security reasons Thanks PS. we have also feedback from the support ticket, the Omnisa engineer has detected a GPO that is blocking the attachment of disks so he has asked us to move the Packaging machine VM to an OU without GPOs and test it there. I will post the results later...

Hi @StephenWagner7 Thanks for your tips! Im providing a few feedback: Try the app, but remove the exclamation marks when creating the App on App Volumes OK, I've created a new app with "testname" instead of "Notepad++" and it didnt work Packaging VM should be clean Windows, domain joined, OSOT tool ran (which minor mods from default config), with NO AV, NO firewall, NO horizon agent, and nothing installed except for the App Volumes Agent Rearding this point the VM: - it is a clean Windows with last updates, domain joined and no horizon agent and it has the App Vol Agent - however it has Antivirus and Firewall, also I have never ran OSOT on it So tomorrow I will do a test deactivating the AV, the Firewall and run the OSOT <-- Tested without firewall, without AV and after running OSOT, but it didnt fix the problem Your instant clones base image should NOT be domain joined, should be clean, Windows, no other apps. Horizon agent should be installed, OSOT ran, and after OSOT finalization you should install the App Volumes Manager Right now I have not being able perform the package on the packagingmachine so I still has not reach the stage where the app volumes package will be attached to the instant clone, anyway whenever that stage will be reached I could confirm thah the golden image will be created in the way you mentioned. Confirm that all your permissions are proper for all your Horizon/App Volumes service accounts (AD, vSphere, etc) The AD account has local admin rights on the packaging VM, should it has any other permission? Regarding the vCenter I use a service account with the permissions described on this article: https://docs.vmware.com/en/VMware-App-Volumes/2309/app-volumes-admin-guide/GUID-8C79E140-A8DA-4A1F-B09D-DE9A332114E2.html Regarding the ESX I use a service account with the permissions described on this article: https://thevirtualist.org/app-volumes-permissions-on-esxi-host/ Anyway, I will try to temporary change the role permissions on both vCenter and ESX service accounts and set them to "Administrator" role to obtain full permissions and check if that was the problem. <-- Tested without "Administrator" and full permissions on vCenter and ESXs, but it didnt fix the problem A few other questions, what OS are your running on your App Packaging and Instant Clone golden image? If it's Windows 11, did you follow the proper procedures to deal with TPMs? Both App Packaging and Instant Clone are Windows 11 Pro. Regarding TPM procedure, I'm not sure what you mean with that. But I remember that some months ago when the VMware cluster was build, the hosts didnt have TPM chip on them so the initial deployment of the Horizon platfrom was performed without TPM on the W11 machines. To allow that we used a trick that consist into modify the Windows registry to bypass the TPM check during windows installation. Later the host were provided with TPM devices so there were no need to perform that trick again, however I'm not sure if the VM used for packaging was created with TPM trick or without it. Anyway I will check it just to be sure. <-- I've check the TPM2.0 availability on the packaging machine and it was OK, so that was not the problem Bytheway I have also created an Omnisa support ticket and I will post the feedback to help othe users with the same problem. <-- I opened the support ticket last friday, they requested me the serviceagent log and I sent it to them, but stil no answer

Hi Im implementing an horizon 8 enviroment with instant clones + FSlogix to store the configurations of the user profiles. Initialy we are not using Office containers, so everything will be stored by default on the FSLogix container (The user will also use GPO for folder redirection). So in order to avoid a big growing of the default FSlogix container, based on your experience what folders would you add to the exclusion list for FSlogix? Would you create a specific "clearing" script to be launched during the logoff? If so, what would you include on that script? Thanks in advance

I have reinstaled the whole App volumes manager and the package agent from zero and it still gives me the same error when trying to perform the package procedure. ...any other idea??

Yeah! I would like to have a MS DBA on my site but I haven't one so I have to perform all the tasks alone. Anyway I have created the blank database on one SQL server and then I have created te AG without problem with the wizzard. Later I have deployed the App Vol manager and registered it with the listener of the AG instead of the Cluster. It worked fine... Thanks

One more thing, In order to use the listener of the AG during the App Vol Manager installing configuration, I must first create the AG. However during the AG creation wizzard the first step that it requieres to me is to chose the desired Database. In this case there is no database on the SQL servers. So as far as I understand the only way to solve that situation is to first create a "blank" SQL database in one of the SQLservers, then create the AG (as well as the listener), then launch the App Vol manager installation and set the "AG listener" on the correponding field of the SQL config. ....Is that correct?

Yes it is, however I have deinstalled the app vol manager and I will perform a new installation just in case I did something wrong. I will post the results...

Thanks again for the clarifications. Yes, this is a test enviroment however it will be set to deployment enviroment after the test will end. I have deleted the database as well as the AG and I will perform a new installation of the App Vol Manager to configure the Listener instead of the Cluster name as you mentioned. However regarding the "sa", I was initialy planing to use a specific sql user for this however it didnt work. As it was exposed in this thread the only way to dont get the self-certificate error is by using the "sa" user and also not having any GPO applied during the manager deployment. https://community.omnissa.com/forums/topic/68528-appvol-manager-cant-generate-self-signed-certificate That said, this SQL cluster will be dedicately only for the App Vol enviroment, no other databases will be hosted there.

Hi First of all, thank for your help. I must say that this is the first time I configure an AG so probably I've done something wrong, anyway here you are the answers: Did you setup AppVolumes to use the Availability Group Listener or just one of the SQL Servers? I have cofigured a Listener on the AG, however when I installed the App Vol and I configured the Database server parameters I didnt specify the "listenername", instead I specified the "Clustername". Should I have set the "listenername"? Did you setup the right within SQL on both servers to be the same? In an AG you will need to manually keep the users and right the same, unless you use a contained database. Yes, both servers have the same users and permisions (bytheway Im using the "sa" user) Is the database joined to the AG? Yes and it is sync.

Update... After creating a new Package machine, join it to domain and installing the app vol agent, the package still doesnt work Here it is the log: