This project has moved and is read-only. For the latest updates, please go here.

New application branch deployment best practises

Topics: Configuration Issue
Aug 12, 2016 at 10:32 AM
Sorry if the title is inappropriate, I did my best and find no better way.
Here is the scenario
Application version 11 is deployed in the enterprise. Everytime a new update (.msp) is released it is published in Wsus Package Publisher and it supersedes all previous ones.
Application version 12 is released while Application 11 is still maintained and it will get new updates.
The enterprise cannot migrate to Application 12 entirely because it doesn't support the legacy windows xp.
So the idea is the following:
  • all new computers will migrate to Application 12
  • legacy xp computers will get the .msp update for version 11
Currently the windows 7 and 8 computers have application 11 and its last update approved.
Which is the best way to achieve the goal ?
I suppose it is better create a new Product name for Application 12 and change the approval for application 11 removing all computers which are not windows xp.

Any suggestions ?


Any reference to Adobe Reader Dc is purely casual.
Sep 1, 2016 at 8:57 AM
Hi Filippo,

to keep things overlookable I personally would indeed rather use a different product name for version 12. But as I just checked, Adobe use "Adobe Reader" as product name for all its versions in their catalogues and unfortunately it doesn't seem to be possible to alter the product name when importing an update from a catalogue to WPP.

To only provide Win XP machines with version 11 and only higher OS versions with version 12, you could use IsInstallable rules (type Windows version).

Regards, Felix
Sep 1, 2016 at 9:46 AM
jFMd wrote:
To only provide Win XP machines with version 11 and only higher OS versions with version 12, you could use IsInstallable rules (type Windows version).
I have all the computers divided into groups based on their OS, so I can approve new applications only for some groups. What is not clear to me is how to deal with the previously approved application 11.
At the moment application 11 and its updates are approved for windows 8 and 7 too. I can remove approvals for those groups or I can repackage everything inserting an appropriate 'IsInstallable' rule.


Sep 1, 2016 at 10:32 AM
Edited Sep 1, 2016 at 10:37 AM
two ways:

Number One
Create Product- orientated Computergroups in WSUS, like:
  • Product V 12
  • Product V 11
and put the XP Clinets in Product V 11 and W7 and higher in Product V12
Approve the Updates in WPP to the correspondending Group: Product V11 Updates to Product V11 Group with XP Clients inside and so on. - finish. Easy and for Beginners :-)

Its ok to have OS orientated groups, but for softwaredeployment you need also software orientaded grooups.

Number two
use the rules in WPP! , like jFMd tell you. You missunderstand what he says, Ininstable rules does not need other groups.
Configure "IsInstallable rules" for Product V11 Updates and Product V12 Updates and set corresponding OS Versions. Than you can deploy it to all Clients, the rule will check if installation is possible or not
Sep 1, 2016 at 11:38 AM

I definitely recommend to set up test groups for this migration on your WSUS. and ply around with a couple of test machines and in a later stage with production machines.
Check if version 12 can be installed as an update to version 11 or if it is being installed additionally to v11. Also if it is installed additionally, if the original msi package could be uninstalled afterwards via "Approval for uninstallation". If OS is the only criteria for migration to v12 or not, should be easy to handle everything with the OS groups you have already on your WSUS and just use all packages from the Adobe Software Catalogues...

Regards, Felix
Sep 3, 2016 at 6:05 PM
Edited Sep 3, 2016 at 6:05 PM
HI Filippo,

we had same here, some clints WinXP has to run for a few years sick!.
Using INstallRules is the best way and you will have less effort to maintain the updates.

Assign V11 only to "EqualTo" (or if you like "LessThanOrEqualTo") Winxp in "is installed" and "is installable" section.
This updates will only shown to win xp clients.

Assing V12 only to "GreaterthanorEqualTo" Windows7 in both sections.
Your WinXP clients wil not see them.

The Wixp rule have to look like this: <bar:WindowsVersion Comparison="LessThanOrEqualTo" MajorVersion="5" MinorVersion="1" ProductType="1"/>
The Win7 Rule: <bar:WindowsVersion Comparison="GreaterThanOrEqualTo" MajorVersion="6" MinorVersion="1" ProductType="1"/>

Benefit of using OS based assigning: If you accidently add a memberserver to a wrong group, "he" will not see that update or application.