JHT_Seattle's Accepted Solutions

Yup - recreated the stack, but did not launch the app post installation.  Finalized the stack, tested, all working as expected with the 2.10.0 agent.
Apparently the issue is more with the 2.6.0 agent.  When I updated a VM to the 2.7.0 agent, the PATH variable is correct and reflects what was added in the stack.
Final follow up: We did indeed implement the following AV exclusions: C:\Program Files (x86)\CloudVolumes C:\SnapVolumesTemp C:\SVROOT We did also rebuild our parent image natively in ... See more...
Final follow up: We did indeed implement the following AV exclusions: C:\Program Files (x86)\CloudVolumes C:\SnapVolumesTemp C:\SVROOT We did also rebuild our parent image natively in our vCenter v6 environment.  As a result, all logon issues with multiple stacks have been resolved.
So I temporarily set up a 2.5.0 environment and recreated the Toad for Oracle stack with the 2.5.0 template.  Lo and behold, it works!  I imported the stack into my 2.5.2 environment and it attac... See more...
So I temporarily set up a 2.5.0 environment and recreated the Toad for Oracle stack with the 2.5.0 template.  Lo and behold, it works!  I imported the stack into my 2.5.2 environment and it attaches at user logon without any disconnect issues.  I think this note made it into the SR as well.
It was permissions, but not to the msdb database.  I had set default schema for the user to [dbo], but what worked was [db_owner] (it always had the db_owner role, btw).  Small change, started se... See more...
It was permissions, but not to the msdb database.  I had set default schema for the user to [dbo], but what worked was [db_owner] (it always had the db_owner role, btw).  Small change, started services, all systems go.
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 ap... See more...
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.
Funny, my problem is that every old version of the Client works with everything, meaning there's no mechanism to direct users to newer versions or restrict what versions can be used to access our... See more...
Funny, my problem is that every old version of the Client works with everything, meaning there's no mechanism to direct users to newer versions or restrict what versions can be used to access our up-to-date environment.  So, don't worry!  Your users can keep on using any old version of the View Client (for now) with any version of any OS (OSX or Windows) and it will continue to work with any version of Horizon View. (5.0+).  I'm not saying there won't be quirks to using old versions of the client here and there, but on a weekly basis we discover some user with one of the old 5.x clients installed and accessing our 6.0.1 environment.  Here's hoping with 6.1 VMware will break something!