I'm about to upgrade our view installation from 3.0 to 3.1.2.
I don't know which version of composer is installed. I'm using linked clones for all my vms. I have one major golden image with 8 snaps(links) off of it.
From my reading I plan on upgrading the view server first. Then installing the latest composer. Then I'll install the new view view agent (where do I install the agent when I'm using linked clones?)
Anything I missed or should know?
I'm preparing to do the same thing and frustrated by the lack of upgrade documentation. I worked with my VMware account team to develop a more detailed upgrade step, which does include a recommendation to upgrade View Composer first. When I get back to the office tomorrow, I'll update this with those steps. Keep in mind that I haven't performed the upgrade yet, so I can't speak to the thoroughness / accuracy of the steps.
As promised, here are the steps from my VMware account team. Hope this is helpful.
Capture the configuration of the Connection Server. To capture this go to the configuration tab of Admin-UI. The most important are Servers and Global Settings (Take the screen shots)
Capture the summary of each pool so that you have all the information (Take the screen shots)
Take the backup of ADAM to a network location (vdmexport > N:\myVDMConfig.ldf ). Vdmexport is located in "C:\Program Files\VMware\VMware View\Server\bin" directory.
Backup the VMware View Composer DB
Upgrade of Servers
The upgrade should be performed during a period of light use. So monitor your environment and find out a time slot when it is used less. During this time no provisioning should be done.
Take the snapshot of the Connection Server
Upgrade the View Composer first
Now upgrade the Connection Server
Upgrade of Agents
For linked-clone pools
Create a snapshot of the master VM. Install the new agent and then recompose all the VMs in the pool with this new snapshot. This is for persistent pool.
For non-persistent pool, take the snapshot of the master VM install the new agent on it. Use the new snapshot for creating pools.
For full-clone pools
Use third party software to upgrade the agent on all the desktops. Or upgrade agent individually on all the desktops.
Upgrade of Client
For VMware Web Client
When the user logs in using the browser they will be prompted that an upgrade is available and it can be downloaded from the CS.
For VMware Thick Client
The user can download the thick client executables from a web site and then upgrade the client.
For Wyse Thin Client
The user or IT should upgrade the firmware.
Test the connectivity from client to the desktop and make sure everything is working fine.
I have tried the upgrade from view 3.0 to 3.1 and got a lot of problems, last week i upgraded an environment with a newly fresh installation and this path works without any problems. Even when doing an deinstallation of the connection broker and a new install gives me problems with the admin interface. Starting from scratch is for me the way to go.
Thank you for the information. Looks like this really needs to be planned out well. I'm just very concerned about losing my linked clones. That would cause me a lot of pain.
Please reply back on how your upgrade went. One thing I didn't think of is needing to update the wyse thin clients. Not sure how I'm going to do that since they are all remote.
I'll be performing the upgrade this weekend. I'll post the results. Regarding the Wyse, I'm particularly interested in the new View feature that allows some thin client information such as hostname, IP address, etc. to be exposed to the VM. However, this feature requires Wyse ThinOS v6.4.x. If you're using Wyse V10Ls, pushing out new firmware (or reverting back to old firmware) is extremely easy if you're using FTP to push configurations to the devices. Simply place the firmware files (V10L_wnos and V10L_boot) in the WNOS folder on the FTP server. If you're using Wyse devices running Windows, you just need the deploy the updated View client.
Nope, i have done the complete rollout again, the configuring part only takes a couple off minutes for the 8 difference pools, the rollout of the 400 VMs takes a lot of time
The main reason we have done the upgrade to 3.1.2 is that some of the solved issues were exactly the problems i got.
You have to update the agent in the virtual machines to, so you have to do some recreation of the VMs.
I have many problems with view (if it view !) vm from my pool freeze etc ... I have 70 vm in my pool, my view version is 3.1.1
my vdi broker is hercules , The stability of the vm in the pool is inconsistant... Is it possible for you to tell me , wich problems
you have encoutered with your view version before the upgrade 3.1.2 .
As promised, I'm posting the results of my upgrade from View 3.0.0 to View 3.1.2. I performed the upgrade yesterday (Sunday), so today was the first full day. As was recommended, I upgraded View Composer first, then the View Manager (View Connection Server) server next. I did not encounter any problems with the upgrade of the servers. Once that was done, I performed a number of tests, including client tests (e.g. USB functionality, logoff/logon, etc.) and admin tests (e.g. pool manipulation, VM creation/deletion, etc.).
All tests were successful except one fairly big one. In addition to updating my parent VM with the new View Agent, I need to upgrade all VMs with the new agent (we don't use Recompose because we still allow users to install apps via SMS onto their respective VM). In testing the upgrade, I found that installing the agent causes the VM to lose its association with its computer account. This is a really big problem. Further testing revealed that installing any agent (including uninstalling and reinstalling View Agent v3.0.0) causes the same problem.
As a result, I can't install the new View Agent on any of my existing VMs. I don't think I'll have any problem with upgrading the parent VM, because I can un-join / re-join it to the domain before creating the snapshot. However, I haven't done this yet.
I've opened a case with VMware, so hopefully they'll be able to determine the cause of the problem soon. Other than this (which doesn't seem to be specific to 3.1.2 at all, the upgrade was a complete success!
Most problems were related to stopping services, like the composer service so no new vms were provisioned, other problems were corrupted vms caused by the composer service.
3.1.2 resolved most of the problems, one still exist and i have opened a SR for it, i have configured a pool that after a session is disconnected for 600 minutes, the user is logged of, i'm currently still seeing sessions which are more then 3 days disconnected.