VMware Horizon Community
iforbes
Hot Shot
Hot Shot
Jump to solution

Visio 2013

I installed Outlook 2010 into the base. Visio 2013 has been deployed into an AppStack. Everytime a user starts Visio, it goes through the initial Visio setup. How do i avoid this initial setup happening everytime?

Reply
0 Kudos
1 Solution

Accepted Solutions
Lakshman
Champion
Champion
Jump to solution

Please make sure that the provisioning machine also has Outlook 2010 (or other Office applications that are on the base image) preinstalled.

View solution in original post

Reply
0 Kudos
20 Replies
Lakshman
Champion
Champion
Jump to solution

Please make sure that the provisioning machine also has Outlook 2010 (or other Office applications that are on the base image) preinstalled.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Thanks! Yup, I just noticed that Office wasn't installed on the provisioning machine. I'll report back if successful.

Reply
0 Kudos
joshopper
Hot Shot
Hot Shot
Jump to solution

I still had this issue in 2.9 regardless of whether or not Office was installed on the capture machines. I moved to 2.10 and it resolved this issue but now I have the NTLM errors.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Yup. Worked for me on 2.10. I'm not getting NTLM errors. Where are you seeing those?

Reply
0 Kudos
joshopper
Hot Shot
Hot Shot
Jump to solution

The NTLM errors is a known issue with 2.10 where the AppVolume Agent is checking in and not finding the machine in DNS. It is really only an issue for non-persistent desktops I would suspect as they are checking in on one of many DCs and the AppVol server may check in on a different machine and not find the non-persistent machine and the agent chokes and disabled virtualization. I have a SR in with VMware. There is another thread about it but I can also post the results here when I get a solid answer.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Ahh. Good to know. I'm working with persistent desktops for now. Question. With persistent desktops we don't need writable volumes, as the PD is capturing local profile info, correct? When we start using non-persistent desktops with App Volumes, that's where we'll need writable volumes to "persist" local profile info, correct? I just wanted to get clarification on that.

Reply
0 Kudos
joshopper
Hot Shot
Hot Shot
Jump to solution

Writable volumes are not required for non-persistent desktops. I am creating AppStacks of all manner of applications and delivering them as read-only. The writable volumes are only if you want users to be able to install their own apps.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Well, I think writable volumes are to retain any writable data. That could mean UIA, but it also means storing registry and program data specific to a user. For example, you might push out Adobe Reader as an AppStack. If you want each user to be able to configure and "persist" the way they configure Adobe Reader (i.e I might deselect some options) you'll need a writable volume for your users. This is obviously becasue non-persistent desktop will lose any user specific info as soon as the user logs off and the vm is refreshed. So, without deploying a persistent desktop, or having some sort of UEM platform, writable volumes is required to persist user specific data (including but not limited to UIA).

Reply
0 Kudos
joshopper
Hot Shot
Hot Shot
Jump to solution

OK, I never really considered that use for AppStacks but indeed we use Profile Unity.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Yup. PU is an excellent UEM type tool for non-persistent desktops.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Hey Iforbes

I dont totally agree with you there. The bad thing about PU (or any profile management tool for that matter) is that you manually need to tell the applications which information it needs to store. So you have to manually do soemthing to get it to work. Second is that all profile settings are normally on a different storage and you need to pull that data over the network. If it is just a small file it will be no problem but if you look at addons for Firefox or Chrome you might end up with a few 100 Meg to get over the line.

When using writable volume the information is directly available because you will most likely place the writable volume on the same storage as the virtual machine. This is just a set and forget option and works quite well with knowlegde workers.

But this is just my 2 cents Smiley Happy Smiley Happy

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Hi Ray. Good points. I've used PU in the past and while it's a good tool I have to agree that since it stores config info on a CIFS share that network can impact login times. Question. I read that App Volumes after 2.9 now deprecate writable volumes local profile? Does that mean writable volumes will no longer store local profile data? For example, if I deliver an app via an AppStack and the user makes a change to that app, does the writable volume still store that info for the user? I know VMware is trying to push people towards UEM, but I'm confused as to what writable volumes will no longer be able to provide when running version 2.10 and going forward. Do you know?

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Good question iforbes and i really hope that Jason can elaborate on that one specially with 3.0 coming up.

At first VMWare indeed said that Writable volume support would be deprecated but I for one (not the only one here) was very dissapointed to find that out.

Mostly because of the points I made in my previous post. Luckily I was not the only one and Jason made a post on the forums here stating that "writable volumes are not going anywhere".

The 2.10 version does still have a UIA (User Installed Applicatione) and profile template which means that personal settings are still stored in the writable volume. They did drop the profile only template though. But to be farely honest back in the CloudVolumes days there only was 1 writable volume option. The other template is a UIA only template and this template only stores locally installed user applications. The biggest issue here is that if you use this users will install applications themselves but wont have any personalization on these applications as the IT guys wont have any notion of applications installed into the UIA writable volume and cant do anything with UEM or PU or any profile tool for that matter. You would end up with **shrug** roaming profiles... Smiley Happy

To this day noone at VMWare could give a definitive answer if writable volumes will still be there in 3.0. I really hope it will be there and they should use Immidio FlexProfiles (UEM) as an option to use personal settings cross platform and workplace management (like creating printers or shortcuts etc.). So let's just keep our fingers crossed here Smiley Wink.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

UIA aren't going anywhere with respect to VDI. The ability for users to install their own apps but IT still be able to deploy a stateless desktop to the user, is important. I'd say Liquidware Labs was the first to recognize this with their FlexApp solution. OK, so it sounds like I'll have to deploy UIA+profile template in order to persist application settings for users (since I'm not deploying any UEM just yet). This does pose the problem of now users have UIA space to install apps, which I don't want but if that's the only way to persist the AppStack user specific config/reg info, then so be it.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Just don't make them admin and they cant install applications..

The only issue we had is explaining users that syncing your entire Dropbox account into a virtual machine is not "the way to go" Smiley Happy. Do keep in mind that not only applications that are installed ar being preserved into the writable volume, also folders created on the C drive (if permission allow them to) or files and folders in other locations on the local machine.

Reply
0 Kudos
iforbes
Hot Shot
Hot Shot
Jump to solution

Good point. I forgot to mention that I've deployed persistent desktops with AppStacks. I wanted to use AppStacks as a more efficient way to deploy apps. After reading many of the discussions I've realized that there are drawbacks in using AppStacks with persistent desktops. Notably, folders or data stored on the c:\ will be destroyed when the persistent desktop is logged out/restarted. I don't really understand why AppStacks needs to destroy any data/new folders/files on the c:\ though. The entire point of a persistent desktop is a persistent disk. So, why as soon as an AppStack is added to the equation, the persistent disk goes out the window?

On one hand VMware says View supports persistent and non-persistent desktops, and then come out with a solution that deploys apps more easily BUT really is only designed for a non-persistent desktop. There are some reasons around application licensing that we need to ensure a user gets the exact same desktop each time they logon (i.e. same computername, IP, MAC, etc). While I can get away with static DHCP reservations for non-persistent desktops, how can I guarantee a user that they will log onto the same computer each time for a non-persistent pool?

Btw, I just tested adding an AppStack to a persistent desktop (no writable volume). When I changed the preferences of the application and restarted the desktop, my application preferences persisted. So, the View persistent disk does infact persist application config preferences. The only issue at this point is the fact that when a user has to create a folder or a file on c:\ (some database clients do this), and AppStack(s) are also attached, it will destroy the folder/file on the c:\ during logoff/restart. I'll probably have to add a writable volume just to persist the folder/file. *sigh*

Reply
0 Kudos
sachindsharma
VMware Employee
VMware Employee
Jump to solution

Ray_handels, writeable volumes are still available in App Volumes 3.0. You'll notice that with all new editions of App Volumes, User Environment Manager capabilities are available too.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

@ Iforbes: Good point, we never thought of it like that to be honest. We needed to have non persistent desktop because we are in an educational environment and wanted to have a 1 stop shop for both students and employees. For us it would not be easy to use persistent desktop. And with floating pools you cannot gurantee that a user gets the exact same machine every time he or she logs in.

You could try to exclude the specific folder you need on the C drive from the appstack. My understanding is that it wont be removed than if you log off because the filter driver doesn't do anything with it. Not 100% sure though but it is worth a test.

@sachindsharma: With writable volumes available in 3.0 you also mean UIA + Profile?? If so you just made me a very happy camper Smiley Happy. And as said before, I do see the benefit of UEM on top of writable volumes mostly to have a good backup of personal settings (this is still an issue with writable volumes although we do have a workaround), create personal settings on a machine and to use these settings between different machines, both virtual and fysical.

Reply
0 Kudos
sachindsharma
VMware Employee
VMware Employee
Jump to solution

@ray_handels UIA + Profile is supported in 3.0.

Reply
0 Kudos