rpiercey
Contributor
Contributor

App Volumes 4.1 2006 Template does not have AppCapture.exe

I have updated to 4.1 2006 and deployed the new template. When I try to capture an application the process does not start.... I see the following in the logs:

[2020-07-29 19:31:37.937 UTC] [svservice:P1832:T2188] HttpQueryVolumeUpdate: succeeded

[2020-07-29 19:31:37.942 UTC] [svservice:P1832:T2188] Creating mount point at "\SnapVolumesTemp\MountPoints\{7078ee87-0000-0000-0000-100000000000}\"

[2020-07-29 19:31:37.949 UTC] [svservice:P1832:T2188] "\\?\Volume{7078ee87-0000-0000-0000-100000000000}\" mounted at "\SnapVolumesTemp\MountPoints\{7078ee87-0000-0000-0000-100000000000}\"

[2020-07-29 19:31:37.950 UTC] [svservice:P1832:T2188] MountSnapVolumeByPath: Checking for the presence of [\\?\Volume{7078ee87-0000-0000-0000-100000000000}\appcapture.exe]

[2020-07-29 19:31:37.950 UTC] [svservice:P1832:T2188] CVolumeResourceHandler::OnNewVolumePost: [{00000000-0000-0000-0000-000000000001}]-[{7078EE87-0000-0000-0000-100000000000}]-[\Device\HarddiskVolume5].

[2020-07-29 19:31:37.951 UTC] [svservice:P1832:T2188] MountSnapVolumeByPath: Checking for the presence of [\\?\Volume{7078ee87-0000-0000-0000-100000000000}\appcapture.exe]

[2020-07-29 19:31:37.951 UTC] [svservice:P1832:T2188] CAppManager::EnableAppsInVolume: Enable Apps in Volume ({00000000-0000-0000-0000-000000000001}).

[2020-07-29 19:31:37.952 UTC] [svservice:P1832:T2188] Creating mount point at "\SnapVolumesTemp\MountPoints\{7078EE87-0000-0000-0000-100000000000}\"

[2020-07-29 19:31:37.953 UTC] [svservice:P1832:T2188] Checking for appcapture on "\Device\HarddiskVolume5" (event appcapture)

[2020-07-29 19:31:37.953 UTC] [svservice:P1832:T2188] RunScript_AppCaptureProgram: creating thread to check provisioning state (Event appcapture) on "\SnapVolumesTemp\MountPoints\{7078EE87-0000-0000-0000-100000000000}\" Go Process.

[2020-07-29 19:31:37.953 UTC] [svservice:P1832:T2188] CVolumeResourceHandler::SignalBaseDiskReady: Couldn't open wemcapture_basediskready event. The system cannot find the file specified (2/00000002)

[2020-07-29 19:31:37.954 UTC] [svservice:P1832:T8484] MountSnapVolumeByPath: Checking for the presence of [\\?\Volume{7078ee87-0000-0000-0000-100000000000}\appcapture.exe]

[2020-07-29 19:31:37.954 UTC] [svservice:P1832:T8484] ProvisioningInProgress was deleted.

[2020-07-29 19:31:37.956 UTC] [svservice:P1832:T8484] RegistryPath was deleted.

[2020-07-29 19:31:37.956 UTC] [svservice:P1832:T8484] AppID was deleted.

[2020-07-29 19:31:37.956 UTC] [svservice:P1832:T8484] NewVolumeUUID was deleted.

[2020-07-29 19:33:59.649 UTC] [svservice:P1832:T2316] CPU USAGE -> AVG  10 | MAX  54 |

[2020-07-29 19:34:24.190 UTC] [svservice:P1832:T2316] CPUMonitoringThreadProc: CPU monitoring thread exited

The Image shows the files that exist on the new Template from 4.1

6 Replies
rpiercey
Contributor
Contributor

I copied the AppCapture.exe from the Client install to the template (mounted in a non packaging machine) and I am able to capture Packages.

0 Kudos
FredericLOUKA
Contributor
Contributor

Hi rpiercey,

I have exactly the same problem than you. Could you explain me where you copied the capture you found on the ISO ?

I had the same idea than you but didn't the time to test it.

Do I have top copy this executable in my provisioning machine when my template is mounted (in the snapvolumetemp folder) or in another location ?

Thank for having post this pb on the forum !

0 Kudos
Shreyskar
VMware Employee
VMware Employee

Your appcapture.exe resides under C:\program files x86\cloudvolumes\agent directory on app volumes agent machine(It can be capture VM or base VM)

0 Kudos
FredericLOUKA
Contributor
Contributor

Hi and thanks Shreyskar.

I opened a SR because I did not understand what exactly I had to do and uploaded the logs on VMware's TFTP.

I will give you an update as soon as I can.

Fred

0 Kudos
sjones_GBM
Contributor
Contributor

Did you get a response for this I am seeing this on AVM 4.4.0 and 4.4.1 2103 as well. Copying it resolves the initial issue but after installing and clicking OK the package status is cancelled.

0 Kudos
Drizzt-DoUrden
Contributor
Contributor

Lemme share with everyone the steps I went through to do this so there's no confusion because I JUST had to do it.

 

1. You can use ANY machine that has the App Volumes Agent installed on it for this. Go into C:\Program Files (x86)\CloudVolumes\Agent. In there you will see an executable called AppCapture.exe. Copy this file to a location that you can get to from ANY virtual machine like a network share or something.

2. Log on to a VM that DOES NOT have the App Volumes Agent on it. Go into the settings of the VM in vCenter by right clicking the VM and clicking "Edit Settings". Click ADD NEW DEVICE at the top and select "Existing Hard Disk". Here you will need to know what Datastore your appvolumes templates are in. To do that go to your App Volumes manager and click Configuration then click Storage and it will show you the default storage location of the appvolumes/packages_templates. Go to that location in the VM you're editing the settings in. Make sure you go to the YOURDATASTORE/appvolumes/packages_templates location and not the YOURDATASTORE/appvolumes/packages location. Mount the "template.vmdk" to the machine. Click ok, then click ok again.

3. Go back into the machine you mounted the VMDK to and go into Disk Management (right click the start menu and you can get to it there) and find the new mounted volume. Right click it and click "Change drive letter and paths..." and give it a drive letter (whatever you want, doesn't matter). Once you do that the drive will show up. Now remember that executable you saved? Grab that and copy it to the desktop of the VM that you're on and then copy it to that drive. Once in there shut the machine down and remove that disk in vCenter. DO NOT and I repeat DO NOT click the check box to delete it from disk when you remove it or you will be screwed. Once you're all done with this you should be able to package an app again. 

4. ???

5. Profit

 

I hope this helps out anyone in the future. VMware is completely overwhelmed right now with tickets because of the pandemic so it's up to us to help each other out.

0 Kudos