Troubleshooting Applications

[himcrucified]

What's the best way to go about troubleshooting applications that are attached along with a user writable volume? For instance, if I have an appstack that contains Acrobat Pro XI and then one of my users reports that it's throwing up an error message how should I troubleshoot it? On one hand I don't want to make the problem worse by doing something stupid like reinstalling the app from the user's desktop, but on the other hand I understand that some application problems legitimately need fixed from the user's desktop.

In the example above I can take that same appstack and attach it to another user's VM and it works just as expected, however, even if I unassign and reassign the same appstack to the user's desktop who's experiencing the problem it makes no difference (not that I expected that it would). I guess my question boils down to how much troubleshooting is too much? Or how far is too far?

When we used Unidesk there was an option to "reinstall" the application layer which would override any user changes that were written to their personalization layer (the changes they made which likely broke the app in the first place). Obviously, no such option exists in AppVolumes so what do I do?

How are you guys tacking this problem? I know one answer is to avoid writable volumes altogether and go 100% with UEM but I'm wondering what other routes people are taking?

[sjesse]

I don't use writeables for this reason. the troubleshooting I've seen has been give them a new app stack I look forward to seeing what responses you get.

[himcrucified]

I suspect then that this is why they implemented the backup option for writable volumes. If you run into a problem then just restore from last week's backup? Thanks for chiming in sjesse​. I too look forward to what others have to say. 🙂

[himcrucified]

Another route that jumps out at me is to not use AppStacks unless you you absolutely have to, that way you can troubleshoot the application in a traditional fashion to your heart's content since it's a UIA. Not ideal but it seems viable.

[Ray_handels]

Hey.

I partly agree with sjesse on this one. We do use writable volumes and if you don't have an extreme thorough knowledge of how the writable i build up your screwed.. The quickest most painless way is to just recreate the writable or indeed restore a back-up from a previous point in time (if you have a back-up to restore that is).

The thing with a writable is that it is a dumb bucket and it catches everything so also stuff you don't want it to capture. What you could do (if you have a writable which a user does not mind you breaking it) is to attach it to a machine that does not have an Appvolumes agent and read through the information there. Most probably ther will either be some sort of delete of applications in the writable (which masks applications in the appstack/Golden Image) or there are files that don't need to be there at the first place.

Also, before going this route you need to manually change the vmdk file (NOT the flat file or metadata file of the writable) and change the ddb.deletable value from false to true, otherwise you cannot attach the writable to another machine. So yes, troubleshooting is quite cumbersome..

[sjesse]

It depends on your use cases, do your users really need UIA? Mine don't and haven't, if they need something they request it, but that won't work for everyone. I'm interested in trying the new profile only appstack which may help with some of the wierder profile issues I run into with UEM. I'm hoping that makes sure the entire profile is saved,which will save thinks like click once apps and per user installed apps that get placed in the users profile.

[Ray_handels]

Hey Sjesse,

Yes it does, strange thing is that the profile only template used to be there in the past, was removed but they didn't want to support that anymore and to my surprise it is back again .

When looking at UIA, yes we do have a need for a lot of users (researchers) to be able to install and update software themselves. This works quite well but after a while the writable is to messed up to work with. On the other hand, this would also happen with their physical machine so to be honest I don't see a difference there.

When looking at the profile solution of the writable. The nice thing is that it takes everything, also these annoying addons or cache files created by FireFox and Chrome and thus making that login faster and everything is there after logon. If you would like to capture everything with UEM (yes we tried with catch-all settings in UEM) you either have a very large zip file or are still missing some stuff.

Only downside was (yes, it is fixed now) is that you couldn't exclude content from the user profile within the writable. In the snapvol.cfg you can exclude all folders and registry keys you would like to exclude (like policies or virus scanning tools e.g.). With version 2.14 you could not exclude files and folders in the c:\users\%username% making the profile corruption prone. In version 2.15 they added a feature (or fixed it, just how you look at it ) that you are able to exclude profile folders thus giving you more management over what is stored in the writable and what is stored in UEM. Getting this to work 100% is still a very tedious job but does you the possibility to gradually change what is being captured and stored where.

Still, if you haven't used writables before make sure to first start testing before going all in.

[himcrucified]

Thank you for the replies, the information is very helpful. Is there any good documentation on how to exclude certain things from the writable?

[sjesse]

There are others but I think this has the basics

Using the VMware App Volumes snapvol.cfg File to Customize Writable Volumes | VMware End-User Comput...

[himcrucified]

Got it! That's helpful, thank you.

From the perspective of telling my level 1 techs what to do in terms of troubleshooting helpdesk tickets that are related to AppVolumes issues it seems like having them either restore a writable from a backup or recreating it is the best courses of action. While I'll take the approach of tweaking the writable config file when needed to alleviate the amount of problems we encounter in the first place. At this point I don't know what additional exclusions I want to make but I'm sure we'll get a better idea as time goes on.

[himcrucified]

It would also be really cool if there was an area where folks shared the exclusions they've found helpful (like the example of excluding C:\Temp in the article you mentioned). Does such a place exist in the forums?

[Ray_handels]

No it doesn't and yes it would be nice. Still everyone has a different approach to it. We don't exclude c:\Temp on purpose because we have a lot of IT users that store their information in this folder. We are looking at trying to exclude folders like %TEMP% (which is in your appdata\local) and Temporary Internet Files but then if you are going to exclude folders in the profile you would need a different approach to saving those settings..