Packaging Licenced Applications Through App Volumes

[bclyde]

I'm having problems with App Volumes and I  cant find any online recourses to help, so reaching out to the community.

In Thinapp you would set your provisioning desktop into capture mode, install your application, open it up, put a product key in, mess about with pop ups saying "don't show again" etc etc then hit build. and all is well. (most of the time)

How do you do that in App Volumes? After I install the application in capture mode I open the newly installed application up, put the licence code in, place a shortcut on the desktop then Click OK to complete, reboot the provisioning desktop and click Complete on the App stack then assign it to a different desktop to test on. The application itself has been packaged fine and appears but it doesn't recognise I put in a licence code when I opened it up earlier nor put a shortcut on the desktop. It seems that anything I do outside the initial install (when still in capture mode) doesn't get captured and carried on to the desktops.

Any help would be appreciated, thanks in advance.

Barry

[Ray_handels]

Ok, i wrote this also in another topic. In this topic this info does apply for sure

If this information is written into the Appdata folder than it won't work as an Appstack doesn't record this information. You can either copy the information into the profile using Windows policies or use the startup.bat file in the appstack (if you attach the disk to a machine that doesn't jave appvolumes installed you can see it) to copy the information. Appvolumes is not capable of using the USERAPPDATA variable (for lack of a better term i just call it like this) that APPV uses to set user specific settings into an application.

[bclyde]

Ah Ok, Thanks for replying.

So in a nutshell, anything other than the initial install will simply not be captured. By copying a shortcut to the desktop it goes in  C:\Users\%username%\Desktop and thus not be copied.

and if by putting in the licence key in on first start-up it goes in AppData you still have a problem. This means that all users will need to put the key in after they launch the application the first time. Madness!

Why would VMware release a fantastic application deployment tool and not allow any customisations to the application after the initial install, it just doesn't make sense. it was soooooo easy to do in ThinApp

[Ray_handels]

It depends on what you thin is easy. We did indeed do this with APPV and it worked great. Only problem with applications like APPV (i don't know ThinApp that well to be hnoest) is that all information was stored in a read write file that you could not access and only remove as a hole thus removing all settings.

For as far as i'm aware they make use of different settings to do this. As said you could be using Microsoft Policies for copying files into APPDATA (works like a charm with item level targeting) or use the startup.bat file in the appstack. You can set all sorst of commands into this file that needs to be executed when being attached to the machine.

You could also be using anything from a writable volume up to persona management and roaming profile to save these settings for users so they only need to do this once.

Also, if you need to have a shortcut on the desktop for all users either install the application withe the ALLUSERS=1 attribute or create the shortcut in the C:\ProgramData\Microsoft\Windows\Start Menu (for all users start menu) or the C:\Users\Public\Public Desktop (all users desktop) so every user that logs in gets the application.

I do understand that, with using a tool like ThinApp it seems like it is an easy solution but to be honest i like the way that Appvolumes does it much better. I am able to set up personal settings for a user by using policies or the bat file but the settings i create in this case are easily changable (because in the Appdata of the user) and customizable per user. If you add this into the ThinApp applications your not that flexible.

[bclyde]

Hi Ray,

Sorry its taken an age to get back to you.

Your answers were extremely helpful and indeed led me on to how I resolved the issue.

If you're in provisioning mode installing an application and it puts a shortcut on your desktop or puts the folders in the start menu, App Volumes wont always pick them up in the capturing process. This is because anything referenced by the local user account or indeed HKEY_CURRENT_USER is totally ignored when you complete the App Stack.

To get the program sticking to the Start Menu Programs make sure your program executable lies in C:\ProgramData\Microsoft\Windows\Start Menu\Programs if it lies in C:\Users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs then it will not capture that and thus not display for other users.

The exact can be said for creating a Desktop Shortcut. If the installer puts the shortcut in C:\Users\%username%\Desktop then its not going to work. Copy the shortcut to C:\Users\Public\Desktop and then it was show for other users.

Barry

[frac200]

Most per user settings are not going to be retained in package. Typically if there are licenses or per user configurations that need to be apply, I use Active Setup to do that with, this way when user logs on they get those per user settings. This is the way I do it and works well for me.

[JHT_Seattle]

I just wanted to chime in to say that for many apps I've built it's possible to copy reg keys from the HKCU to the HKLM to set global settings or licensing.  For other apps it's been possible to enter the license into a text document placed in either the application's install directory or in some subdirectory of the ProgramData folder.  The point is that every app is different, but I haven't had a single licensed app that required me to put anything into a startup file.  I'd recommend when installing an application to a stack that you look for whatever administrative install documents might be out there to see how it would be done as if you were using a tool like SCCM, etc.  Some mechanism where the install would be applied to all users.

[javierms]

Try to capture these apps from the Master Image (Golden Image or whatever you call it): we fix this issue for Visual Studio doing it this way, rather than capturing the app from our usual "secuencing VM"