allvolattached.bat not in template.vmdk!

[VirtualSven]

Be aware, if you want to use the batch-file "allvolattached.bat" make sure to rename the batch-file which is located on the appstack template vmdk "allvolsattached.bat". Allvolsattached.bat will not be used because of the 's'. It should be "allvolattached.bat".

[solgaeDK]

Thanks for the reply - However, it appears the allvolattached.bat script doesn't work as in App Volumes 2.10.

I originally used this script for capturing recent versions of vCenter Client integration plugin (CIP) to copy the certificate files generated by the CIP install to the appropriate place, since the CIP install generates them on C:\ProgramData\VMware\CIP directory which is not captured by default. However, upon re-capturing the appstack using the 2.10 appstack template, and putting in the allvolattached.bat script (renaming the existing one and adding in the required commands), I found that the script was not executing at all.

The log file svservice.log shows the following (removed the timestamp):

[svservice:P828:T432] RunScript: user script (event allvolattached) on "\SnapVolumesTemp\MountPoints\{6e1b3ff1-c7cb-11e5-8302-005056b14caa}\" go processing.

[svservice:P828:T432] RunExecutableAsUser: Path "\SnapVolumesTemp\MountPoints\{6e1b3ff1-c7cb-11e5-8302-005056b14caa}\allvolattached.bat"

[svservice:432] RunExecutableAsUser failed: no session available

It appears that either certain things got broken, or its behavior has changed in version 2.10.

I moved my commands to shellstart.bat for now, which allowed me to work around the issue, but it appears the allvolattached.bat script doesn't work as intended in 2.10 appstack template.

[iforbes]

How do we access the bat files in the volume vmdk's? Are these hidden volumes on the desktop? I'd like to be able to view these bat files but don't understand how to get to them.

[VirtualSven]

Mount the vmdk to a clean VM without the App Volumes agent.

[VirtualSven]

I think you're right, doesn't work at my customers location as well. :smileyangry:

[Ray_handels]

Strange.. Just for testing purposes (got a little scared after your posts ) i created a new basic W7 machine and I am still able to attach a writable volume persistent so i can actually change it and attach the snapvol.dat or change any .bat file.

Regarding the appstacks i can attach them nonpersistent and look into them as I please..

You can't change the appstack off course if provisioned because it has the readonly bit but nothing seems to have changed in V 2.10 in regards to changing info in the VMDK.

[solgaeDK]

Ray,

Changing the files within the VMDK is not a problem....for the most part. Right after provisioning is done, I'm unable to manually mount the appstack VMDK to a non-appvolumes-enabled VM due to file lock, which, before 2.10, is usually resolved by triggering a rescan of the appstack, which releases the locks. In 2.10, however, triggering a rescan causes failures in the task Ensure files and metadata for AppStacks are fresh when you have any existing appstacks attached to the virtual desktop, with System Messages log showing the entry: Job error: Refresh AppStacks #<Thread:(hex value)> undefined method `parts' for #<SnapvolAttachment:(hex value)>. So the file lock doesn't get released because of the rescan task failing.

I end up making a copy of the appstack vmdk and metadata files to somewhere else and mount that copy to the non-appvolumes-enabled VM to make modifications to the bat file. Then, I delete the existing appstack from the Manager, copy the modified vmdk and metadata files back to the original location, and trigger an import task and reassign once the appstack shows up again.

However, even after all that, the allvolattached.bat script does not work, with the log file aforementioned in my earlier reply. Things really aren't looking good in version 2.10.