VMware Horizon Community
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Tips for having separate Visio 2010 and Project 2010 stacks?

Individually, neither app is an issue, but when applying both of them which ever app is applied last has no issue.  The other one prompts an Office re-configuration at first launch.  It does that just fine and proceeds to open normally, but that's still 60 seconds of inconvenience, every time.

Is there another trick to having separate stacks for these two apps when applying them both?  The Office 2010 suite is installed to the parent image, they're all the same SP level (SP2).

Reply
0 Kudos
1 Solution

Accepted Solutions
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Reporting back in to say that Plan B worked.

Capturing each app while the other one is already installed resulted in success building separate app stacks.  For each app I installed only the app (deselected shared files and tools) and the only update I included in the "Updates" folder (used to install updates automatically during install) was the core SP2 msp for the app (none of the proof or proofing msp files, no mui updates, no clientshared updates, etc, since I didn't select them for install in the first place).  Keeps the stacks relatively smaller, too.

For whatever reason the app stack for each app still reports the MUI and shared components as being captured, but versions report as "(null)".  No big deal to me, I guess.

View solution in original post

Reply
0 Kudos
19 Replies
Ray_handels
Virtuoso
Virtuoso
Jump to solution


For as far as i'm aware (please guys, correct me if i'm wrong) having office applications within multiple appstacks is not supported. So you either need to install the entire suite (office, Visio and Poject) within the golden image or create one appstack that holds all three applications.

Also, office needs to use KMS licensing to be able to work with Horizon/Appvolumes.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Well, the idea was to keep them separate because they are licensed separately, and not every person is licensed for one or the other (or both).  It's just odd because if I apply only one of the two apps (Project OR Visio) everything just works, no problem.  It's only when the 2nd app (whichever one it is) is applied that upon first launch it needs to reconfigure.  It still works, just takes the extra few minutes to repair itself.

For my latest stacks of each app I installed only the application (no shared files or tools) with a slipstreamed SP2 update (in the updates folder).

We're already set for KMS licensing, and that's not an issue.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

It is not that odd that it happens with the second application being loaded. The point is that appstacks are being merged into eachtother and thus have different and conflicting shared components that you cannot not install (strange sentence but you get the idea right?? Smiley Happy)

Also, if you dont have a writable volume the repair will be triggered every time you log in. And even worse, if you have a writable volume, the repair will be written within that writable volume filling up the writable volume pretty hard with almost 1GB of data. We  did see that it worked afterwards.

We also noticed another issue if using KMS. It could be that during sequencing that it does an ospp.vbs /act and thus changing the security database of Office's KMS. This could also lead to corruption when starting up but then you should see an error that states that the product is not licensed..

Looking at the licences, you could try and install both Visio and Project into the base image, hide the C drive if feasible and create start menu icons targeted at the licensed users.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

The thing is, I just can't fully agree that there are conflicting components.  Either app, on it's own, when added to the existing parent image that includes Office 2010 SP2, works just fine, no repair.  It's only when both are added.  I have a few more time-consuming ideas to try before I conclude there's nothing left to try 😉

The shortcuts workaround is a good idea, but we have so few instances where someone needs either or both of these apps that I'm hesitant to install them both into the parent image.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Just for the record Smiley Happy

It's not that i dont agree with you but for as far as i know (havent read all documentation, could be they changed it) in Appvolums documentation it is stated that this is the case, either install it in the base or as 1 appstack. We had the exact same issue as you are having know. At first we even tried to have 3 different appstacks, 1 for office, one for visio, one for project..

The only thing that eventually worked is all in the base image.. If this is feasible and the perfect solution? IMHO it isnt; but at least it works this way.

Reply
0 Kudos
SL39
Contributor
Contributor
Jump to solution

*Bump for this thread!  As for many of you I am also having issues with repairing and KMS activations.  Has anyone been successful at virtualizing application using either App Volumes or KMS?

Reply
0 Kudos
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

Ray is correct on this. Either all in the base or all in a single AppStack. the reason is KMS licensing itself. Office and all ancillary Office components store license information in a single file. So if you have just Office that is the license. if you have just Visio, that is the license. The problem now happens that if you take an AppStack with Office it does not have a license for Visio. You then attach an Appstack with Visio and it does not have a license for Office.. So they must all in a single AppStack and then be assigned accordingly. Adding support for multiple Office AppStacks is being worked on but whatever is done must not break MS licensing as well.

To answer SL39, yes it does work but you must follow the best practice guide and be using the correct media (must be from Microsoft License Fulfilment and have MLF in the ISO name..)

https://www.vmware.com/pdf/app-volumes-user-guide.pdf Page 44.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Shouldn't I get the repair screen, then, if even just one of the two app stacks were applied to my base that includes Office already?  In my results, Office + 1 App Stack (either Project OR Visio) = no issue.  Office + 2 App Stacks (Project AND Visio) = whichever app stacked last is repaired.

Maybe I'll try this - installing both apps to my parent, grabbing the resulting license file, deploying it after the stacks are applied.

Plan B is to capture Visio on a machine that has Office and Project already installed, then capture Project on a machine that already has Office and Visio installed.  That way both of my captured apps act as if the other app is already installed.  It's more work to capture, but if it works it'll be worth it in the long run.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Reporting back in to say that Plan B worked.

Capturing each app while the other one is already installed resulted in success building separate app stacks.  For each app I installed only the app (deselected shared files and tools) and the only update I included in the "Updates" folder (used to install updates automatically during install) was the core SP2 msp for the app (none of the proof or proofing msp files, no mui updates, no clientshared updates, etc, since I didn't select them for install in the first place).  Keeps the stacks relatively smaller, too.

For whatever reason the app stack for each app still reports the MUI and shared components as being captured, but versions report as "(null)".  No big deal to me, I guess.

Reply
0 Kudos
SL39
Contributor
Contributor
Jump to solution

Hi Jason,

Thanks for the reply I have verified that we are using installs from the Microsoft site including MLF in the iso's.  After reading JHT_Seattle's last response I'm going to try unselecting all components such as tools and shared files from the install and only leave the app (project/visio) installed.  Are there anymore specifics not outlined in the user guide?

Reply
0 Kudos
whibr
Enthusiast
Enthusiast
Jump to solution

I'm testing with Office 2013 ProPlus with KMS licensing, and will also want to add Project and Visio.  Not sure if Office 2010 is the same, but how did you deal with the activation in the base image (or App Stack)?  Any additional recommendations you found around the activation when capturing the app stacks would be helpful.  I've been trying /act and ospprearm.exe when provisioning with ok results, but not sure if that is necessary.  Our clones are refresh on log off.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

I haven't started working with Office 2013 yet, though it looks like our company wants to migrate to O365 soon (essentially 2013).  In my case with Office 2010, though, I did not have to rearm Office.  I'm not sure how my process deviates from what seems to be the norm, but I didn't have to run any commands to prep Office before either building stacks for each app (Visio / Project) or before building a non-persistent pool around it.  Our pools are configured to refresh at log off as well.

Reply
0 Kudos
whibr
Enthusiast
Enthusiast
Jump to solution

Nice. I now have the full Office ProPlus 2013 in the parent base image.  Works great in the clones, with the users also getting a writable (profile only) upon first login to the pool.  Using the Office Customization Tool, I created a MSP file to make a [Desktop Folder] shortcut as part of the installation. I then provisioned a Project Standard 2013 app stack applying this MSP file during installation.  If this Project app stack is next assigned to a user that hasn't yet logged in to the pool (and doesn't have their profile/writeable initialized), the Project 2013 shortcut on the desktop appears as expected.  But if this app stack is assigned to a user that has already previously logged in and has been using a writable, then the desktop shortcut never appears.  The Project app is there, it works fine if you launch it from the Start > All Programs menu, but I would like the shortcut to appear for the users when they have been assigned the app stack.  Any ideas?

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Make sure the desktop shortcut is added to the All Users Desktop in the stack itself?  I've had to remind myself to make sure of that for almost every app stack I've created.  Users > Public > Desktop.

Reply
0 Kudos
whibr
Enthusiast
Enthusiast
Jump to solution

Thanks for the reminder, but I'm still experiencing some odd anomalies.  I decided to blow away the writable and create a new writable using the "uia_plus_profile" template instead this time.  Logged in to the pool one time with no appstacks assigned just to create the profile into the writable.  Then in the OCT, I removed the desktop shortcut entry from the MSP file, re-provisioned the appstack with Project, and manually drag-drop a shortcut into the folder C:\Users\Public\Desktop before completing the provisioning process.  All went well, and I attach the stack on next login,  Project shortcut on desktop showed up just fine.  Logoff, then login again to ensure it carries forward to another random pool desktop...success.  My last test is to unassign the appstack at logoff from the AD group it was assigned (my user account is member of this group).  I logoff and log back in, and the desktop shortcut is still there even though the Project appstack is no longer attached.  Under Start > All Programs > Microsoft Office 2013 there is still a Project 2013 entry, but when I click on it it doesn't work and I get a message saying that the product is not installed.  I logged off again and on, same result...desktop shortcut is still present also.  I will do some more testing and hopefully I can figure something out.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

I'm trying to parse everything you're trying, but I'm much more of a visual learner Smiley Happy

So here's what I'd do:  Use the profile WV, not the uia + profile WV, since your users aren't installing anything, from what I could tell.  Provision/Install Project manually, without the .msp, since installing the .msp would require Windows Update to be enabled, which you don't really want/need to do anyhow.  For my Visio/Project installs I unselected every component other than the core app, and I had an "Updates" folder where I placed the SPx update that matched whatever Office was patched to already (you'll have to extract the individual patches from the SP, then just use the core SP patch, not all of the mui patches, etc).  If you need/want a desktop shortcut, send it from the Start Menu to the desktop, then cut/paste that shortcut to the Public desktop folder.  Clear temp files, launch the app, whatever (just make sure it works), then complete the stack.

The real point of my original post, though, was to find a way to have separate stacks for Visio and Project, but not have them screw each other up if assigned to the same user/computer.  For that I found that if I built a Visio stack on a machine that already had Office + Project installed, it worked, and if I built a Project stack on a machine that already had Office + Visio installed, it would work as well.  Neither screws the other one up this way.  I imagine that'll work with 2013 as well.

Reply
0 Kudos
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

BTW work has been done to this for the upcoming version :smileycool: Stay tuned.

"Make sure the desktop shortcut is added to the All Users Desktop in the stack itself?  I've had to remind myself to make sure of that for almost every app stack I've created.  Users > Public > Desktop."

And yes this should probably be a line in the Best Practice section...

Reply
0 Kudos
whibr
Enthusiast
Enthusiast
Jump to solution

I will, and hopefully version next will arrive soon...  I've spent way too much time trying to tweak and work out a functioning deployment with just basic corporate-needed apps.  No success, just too buggy and not reliable yet for our use.

Reply
0 Kudos
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

I am sorry you are having these issues. We are still working out a few kinks with Office and the next version is very soon. Not trying to make any excuses but Office is a bit of a bear to virtualize and keep license compliant across so many varied environments. I hope you give 2.6 a shot and I think you will be pleasantly surprised with the improvements.

Reply
0 Kudos