[SOLVED] App Volumes: Unable to mount provisioning volume

[D81]

Hi

I've recently installed a new App volume server (v2406) and I have created a new Application for test purpose.

After creating the application --> Packages --> Package

Then  I select the package VM -->  Package --> ERROR: Unable to mount provisioning volume 

This is the log error: 

I've tried to fix it by reinstalling the agent on the packaging VM, but It hasnt fix the problem.

Any idea about what may be?

Thanks

Edited Tuesday at 04:22 PM by D81
SOLVED

[D81]

I think I've found the problem:

1. I installed the horizon agent on the packaging machine
2. Later I joined the packaging machine to the domain and also I have changed the hostname at the same time.
3. Then I performed a first attempt to do the "package process" and it shows the error.
4. I tried by reinstalling the app vol agent with no luck and lauch the package process again but the error persist

So when I've check the logs on the app vol manager I've realized that the package VM was still appearing with its old hostname... So I assume that if I create a new package VM, install the AV agent and join it to the domain (without changing any hostname) it should work.

I will test id and post the result...

[D81]

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:

[Robin Harmsen]

Is the packaging machine on the vCenter cluster which you have configured as Machine Manager?
Seems like AppVolumes is unable to locate the VM in order to attach the created package/vmdk

Edited September 12 by Robin Harmsen

[D81]

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...

[D81]

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??

[StephenWagner7]

Here's a few ideas for testing:

• Try the app, but remove the exclamation marks when creating the App on App Volumes
• 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
• 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
• Confirm that all your permissions are proper for all your Horizon/App Volumes service accounts (AD, vSphere, etc)

 

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?

[D81]

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 

Edited Tuesday at 07:27 AM by D81
edit with some feedback

[D81]

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...

 

Edited Tuesday at 09:50 AM by D81
update feedback

[D81]

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.

 

[StephenWagner7]

Hi @D81,

If ESXi mounting is working, but vCenter is not, you most likely have permission issues for your App Volumes service account.

Side note, have you confirmed all your versions are good on the interoperability matrix?

[D81]

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.

[D81]

duplicated post

Edited 20 hours ago by D81
duplicated