Can someone post in a nutshell why i should be going to version 4?
My environment is hitting a hard wall where I can't upgrade view past 6. Technically I could upgrade my connection servers to 7.10 or 7.11, but i would have to continure to use view agent 6 because that's the highest version view agent, a zero client tera1 chip will connect to. I don't have App volumes but will start building that shortly and will have to go with 2.18 and not 4 because App Volume 4 is compatible with 7.10 and 7.11.
Right now there isn't a massive difference. v4 looks to be migrating away from the idea of managing collections of apps and instead individual apps with versioning (allowing you to have different people have different versions of the app if there are compelling reasons to do this, say plugin compatibility). 2.18 is LTS though so it'll be supported for a bit longer yet (2.18.1 is out already).
You should probably be looking at plans to move away from view 6 though (even if its new hardware migration) because eventually none of it is going to be supported and its better to be ahead of the game.
The biggest advantage I can see now in version 4.0 is that you can create a package for every application. It depends on your use case of course but if you have applications that are now installed in multiple appstacks because you don;t want to have to many appstacks this is much better.
Looking at administrative effort, Appvolumes 4.0 is much nicer and easier to use than the old 2.x version. But I gues it is a matter of taste.
And View 6 is a definite no go as far as I'm concerned. Try and upgrade to 7 as fast as possible.
In support of what the previous replies have stated about individualizing the packages, 4.x looks be more aligned with the JMP server and it's ability to provision to a more individual's needs.
think I will stick with 2.x why cause to repackage every application is crazy understand paid applications and standalone but let’s say your like me and have every user gets a corporate stack with everything a base user needs.
example
7zip
Firefox
Chrome
Flash
Outlook add-ins
Adobe Reader
Putty
NotepadC++
plus many more let’s say 30 individual apps in one stack
all this work takes me about 15mins install reboot done
with 4.0 do the 30 in individual apps would take hours
plus let’s not forget about log on times.
tried to do multiple applications in 4.0 says it will run on windows 10x86 WTF I did all this on x64 how on earth do I get this added to also run on windows 10x64 bit and or Win7 I know it’s dead but still.
anyway personally I know with 2.x I can at least tell it run on win x86/64 server 2008/12,16 etc
Personally I think if you can change it on 4.0 to tell it run on Windows versions xyz that would be nice to know how.
thanks,
Here's a link on how to add it to different OS'ses but as said on another post I would not do that.
https://vdr.one/app-volumes-4-0-app-stack-os-mount-hacking/
That being said. You can still have multiple applications within 1 package and call the application Base.
The reason why I would not suggest doing this in Appvolumes 4.0 (and the reason why i really like the way it is setup now with 4.0) is that if you do have multiple applications (let's say 20) and you only need to change one you would need to change the entire appstack which could cause other applications not to work. Apart from that maybe someone wants to have a different version of one of those specific applications. you would need to create multiple appstacks to provide everyone with their specific version. Let alone testing the entire appstack every time even though you only update 1 application.
Still. At the end it depends on what you are trying to achieve with Appvolumes and DEM i guess and whichever suites your needs best. I do think that in the end the 2 version will disappear.
For what it is worth. You can still setup 2.x appstacks within version 4. Take a look at the techzone info.
Not if your using 4.0 client you can’t
If you install 2.x client you can have the 2.x
Um on a side note
Noticed you cant on 4.0 delete multiple applications which is annoying testing creating random applications.
With 2.0 select the app stacks hit delete nice and simple 2 step process not individual that sucks personally for me.
Also doing a package and finding it sets it to Windows 10x86 is really annoying and i am tempted to do the database fix as above.
VMWARE gives us the ability to change what operating systems applications can be assigned to please.
Also doing a package and finding it sets it to Windows 10x86 is really annoying and i am tempted to do the database fix as above.
Is this a label you're seeing that indicates Win10x86? Or are you unable to attach the Package to an x64 system? If it's the former, this could be a simple bug in the gui that wouldn't impact usability. If it's the latter, it obviously affects usability of the product.
So for migrations VMWare have a fling for this: App Volumes Migration Utility | VMware Flings
It'll (hopefully) take an existing app stack and just convert it to the new 4.0 format, meaning you can migrate now and then slowly re-provision your apps in to single appvolumes over time. I mean you are updating the apps anyway right?
I'm holding off until I see 4.1 (or 4.0.1 at least) as its supposed to bring back the 'limit attachments' checkbox which we actually use here (I have a small 3 machine dev pool to test various updates/changes)
I don't really get this "feature". You could always put one app in an appstack and if I really wanted call it a package. This isn't exactly anything new. The only problem is if you had 20 appstacks (packages) it would take forever to login, which of course in app volumes 4.0 it takes forever to login with 20 packages applied anyway, so...
The other issue is there is a limit to the disks you can have per storage controller on the VMs themselves:
The maximum number of disks depends by the controller type:
SCSI is the default and most don't change it so you can go to 60 virtual disks. That is 59 packages that you can have max from what I can tell unless I'm reading this wrong and you would have to have 4 storage controllers to do it.
Sorry, it is 60 virtual disks per controller so in theory you could have 240 virtual disks. Still I don't like having a ton of virtual disks attached to every VM in my environment.
Restriction aside (at least in my environment users tend to have a dozen or less apps, with the "common to everyone" apps in the base image) you can indeed already do this with the exist appvolumes. I in fact already do this with the existing appvolumes and we haven't upgraded to 4.0 yet. My understanding was it was more of a logical change in that you now get apps in the interface with versions listed under each app, rather than the existing version were you just get a big long list of appstacks split up however you happen to be naming them. I know I'll be using the versioning quite heavily when we eventually upgrade as I've already pretty much started to use my own versioning system in the current version (i include a date a build number in the appstack name).
I was hoping the 'under the hood' changes they were making would have speed up app stack attachments to the point where having 20-30 appstacks per user wouldn't be an issue. Right now its bearable to log in (at least on my setup) with 5-10 appstacks but realistically anything past that makes logging in take so long you start to get complains.
In my head I've been treating 4.0 more like 2.19 (with 2.18 being LTS anyway) with the caveat that once you've upgraded there is no going back.
I see quite some posts of people saying that login with 4.0.1 is slower than 2.18 (or older versions) but I don't see that at all.
Looking at my use case (and I guess many more), even i you have 1 base appstack with 15 applications (we also have one of those) we still decided to create 1 package per application. If you only need to update 1 application you can simply update that 1 version and assign it to 1 person to test it as a single assingment takes precedence over a marker or group assignment. If you don't see the benefit of that my guess is yoyu didn;t really push to the limit of appvolumes yet.
We also had an issue with adding more than 14 appstacks but looking at logs this seemed to be quite obvious as we needed a new scsi adapter for the extra disk and you can't hot add that. But with a testing machine with W10 not optimised and no virusscanner and stuff (as said, very simple test) we added 16 appstacks and login time was about 20 seconds. And this waas not only simple applications but also big ass Adobe stuff.
My guess is that we all try to cramp up a bit to much on the virtual machines like DEM, virusscanning and then some that slows down the logon of the machine. also modern apps are a really quick logon killer for W10..
Bit late.. we came to the conclusion that we can no longer choose to assign an 4.0 Application to a specific OS afterwards anymore. Of course, we know the risks of unreliable behavior.. but still for simple applications it was an outcome.
We now first have to decide whether to provision the software on Windows 10 or Windows 2016/2019. Or make use of a Desktop Application pool to provide the Application directly via our portal.
Below the rich option list from 2.14 we miss 😉
Totally agree i advise back on 02-Mar-2020 14:41
I did a package (NotepadC++) on windows 10x64 1809
Once package complete gone to assign to the rest of my test machine which are Windows 10x64 1809 and wont assign checked and the application will only attach to windows 10 x86
I've been waiting for VMware to release the new version that allows us the ability to change this.
You guys did see this link right?
Here's a link on how to add it to different OS'ses but as said on another post I would not do that.
https://vdr.one/app-volumes-4-0-app-stack-os-mount-hacking/
I suspect that the newer version will support this and also the computer prefix but it seems as if 4 first needed to come out so people could see it.
They are now adding the stuff from the old 2.x version to it I believe.
Hi Ray,
Been waiting patiently for an update.
over 3 months and counting I suspect it will be a big change coming just hoping this is the case keen to use the latest and greatest as I would assume Office 2019 will be Supported and touch wood we don’t have issues with Visio/Project and have the ability to change OS.
Thanks,
Nathan