Important Information for those still using Softgrid 4.1 and 4.2
If you are currently using Softgrid 4.1 or4.2 clients and/or servers, you need to be aware of the following support milestones:
Product |
Availability |
Mainstream Supports Ends |
SoftGrid Application Virtualization 4.1 for Desktops |
5/25/2007 |
7/10/2012 |
SoftGrid Application Virtualization 4.2 for Desktops |
5/25/2007 |
7/10/2012 |
SoftGrid Application Virtualization for Terminal Services 4.1 |
5/25/2007 |
7/10/2012 |
As of last July 11th, these products are now in extended support which means
- No more requests to change product design and
features - No more hotfixes unless using an extended hotfix
support contract.
Once a product moves out of mainstream support, I immediately start advising my customers to move forward. In the case of application virtualization, the reasons for moving to a more modern virtualization engine primarily revolve around more virtualization features and support for more modern operating systems (Windows 7 and Windows 8.) At this point it is a matter of determining what course of action to take – either moving to 4.6 or moving to 5.0. Most of the time, this decision depends on parallel factors (OS migration, ESD implementation, Application Compatibility remediating efforts, etc.) Use the following table to determine your general options for
moving forward:
Product |
Transitional OS Support |
Modern OS Support |
Configuration Manager Integration Support |
Upgrade from 4.1/4.2? |
Engine Co-existence Support |
App-V 4.6 Desktop Client |
Windows XP & Windows Vista |
Windows 7 & Windows 8** |
2007, 2012 |
Yes |
App-V 5.0** |
App-V 4.6 RDS Client |
Windows Server 2003 & Windows Server 2008 |
Windows 2008 R2 & Windows 2012** |
2007, 2012 |
Yes |
App-V 5.0** |
App-V 5.0 Desktop Client |
None |
Windows 7* & Windows 8 |
2012 *** |
No |
4.6** |
App-V 5.0 RDS Client |
None |
Windows Server 2008 R2* & Windows Server 2012 |
2012 *** |
No |
4.6** |
*- requires PowerShell 3.0
**- Requires App-V 4.6 SP2
***- Requires CM 2012 SP1 or later
Getting Your Virtual Applications to 4.6
Should you decide to move to 4.6, besides the obvious infrastructure upgrades, you will need to plan on moving your virtual applications to this newer platform. If you are currently on Windows XP, 4.6 is still the only option. For moving to is 4.6, I generally recommend following the general process below for assessing and remediating virtual application package migration.
- Test existing package. While the injection/virtualization model did change between 4.2 and 4.5, a lot of regressions were identified and fixed – however – in my opinion, this may only be a guarantee in 80-90% of applications.
- Update SFT file using App-V 4.6 SP1 sequencer or later. You can simply open a package and save it under the 4.6 SP1 sequencer and this will often serve the purpose of getting the applications functioning properly on the 4.6 client. You can also automate this by using the App-V sequencer command-line. Refer to this Technet Article - https://technet.microsoft.com/en-us/magazine/gg236638.aspx
- Re-sequence using 4.6 SP1. If all else fails, re-sequence using the 4.6 SP1 sequencer (or later.)
Getting your Applications to 5.0
Should you decide to move to 4.6, your 4.1/4.2 packages will need to follow a different process for migration as there is a drastic change in the sequencer file format (SFT to APPV) as well as the XML governing these packages. Sequencer generates new package format based on the Windows 8 installer (APPX).
There is no direct step for moving these packages to the new formats. For moving to 5.0, I am currently recommending following the general process below for assessing and remediating virtual application package migration.
1.) Update the 4.1/4.2 package using the App-V 4.6 SP1 sequencer or later. You can simply open a package and save it under the 4.6 SP1 sequencer and this will often serve the purpose of getting the applications to the minimum level needed for migration to 5.0 as mentioned above, you can also automate this by using the App-V sequencer command-line.
2.) Test the package functionality using a test client running App-V 4.6 SP1 or later. This step is often left out – but is necessary.
3.) Once the package is a confirmed working 4.6 SP1 package or later, you can proceed with migrating the package using the package conversion module that is included with the App-V 5.0 sequencer. The “AppVPkgConverter” PowerShell module installs with the App-V 5.0 Sequencer.
Please note: It is early in the process for me to give exact specifics as to expected successes – however, I can point out that there are elements that will not convert and will need to be tweaked/adjusted as of the App-V 5.0 Beta 2 release. These will help you determine if you would be better of re-sequencing the application:
- OSD Scripts These will need to be added using the Dynamic Configuration feature of 5.0
- OSD Registry Settings: These will also need to be added using the Dynamic Configuration feature of 5.0
- Dynamic Suite Composition Settings: You will need to use the Virtual Application Connection feature instead.
You will also need to re-sequence in order to take advantage of Virtual Application Extensions Points.