2012R2 application deployments with multiple parts

[Jake]

Good morning,

 

I would appreciate if someone could advise on a couple of questions, please - I have been searching for a while.

 

One of the applications I am deploying has several parts to it and I am trying to understand how best to manage this applications deployment.

The application is Promethean ActiveInspire and as part of the installation there are the following MSIs that need to be installed;

 

ActivDriver x64.msi, ActivDriver x86.msi, ActivInspire.msi, ActivInspireCoreRes.msi, ActivInspireHelp.msi and ActivInspireHWRRes.msi

 

So, is it necessary to Create Application for each MSI and then deploy each application part to my collection(s) or can I send all parts in one go as a single Application?

 

I tried to add them as additional Deployment Types, but I don't think this is right, and only the Priority 1 MSI appears to be installed and the wording on the Deployment Types pane suggests to me this is only to give the administrator an option to deploy a single application but offer multiple deployment types dependent on platform or perhaps other requirements.

 

So, assuming my understanding above is correct, is there a more tidy way to deploy an application that has multiple parts to it without going down the route of some ugly scripts?

 

Secondly, when updating applications, is it necessary to use the supersedence option - and if so, is it necessary to keep each revision of a piece of software? There is a suggestion here of using batch scripts to call installers/uninstallers but this doesn't seem especially elegant, especially with the application above with multiple parts.

 

Using SCCM 2012 R2 CU1 on Windows Server 2008 R2

SCCM in my environment deploys Windows Updates and updates for Adobe Reader and Adobe Flash Player via SCUP.

I know there are 3rd parties that offer SCUP catalogs for updating regularly updated applications e.g. Java etc but my laughable budgets sadly won't stretch that far.

 

Many thanks

Jake

 

[Peter van der Woude]

The best and most future ready solution would be to created separate applications for all of them. Indeed one application with multiple deployment types won't works as it goes through all the deployment types (by priority) and installs the first applicable one.

[Jake]

The best and most future ready solution would be to created separate applications for all of them. Indeed one application with multiple deployment types won't works as it goes through all the deployment types (by priority) and installs the first applicable one.

Thank you, that is really dissapointing though .

 

Any recommendations on the practice of updating applications? is supercedence THE way to do it? And, if so, is it necessary to all software versions within SCCM?

[jr19]

I am curious about this also. I have never had great luck installing/updating applications. My most recent deployment of Acrobat X was lackluster at best. It was very hit or miss as far as whether or not the installation was successful. Of course, every time I test these things in a test environment, they go smoothly. Drop the same procedure into a production environment and wacky things start to happen.

[Mikey C]

So, assuming my understanding above is correct, is there a more tidy way to deploy an application that has multiple parts to it without going down the route of some ugly scripts?

 

Have you tried using a Task Sequence? These are not just for OSD, as the name suggests they are simlpy deployments of a Sequence of Tasks.

 

I would simply create applications for each one, and then put them in the correct order in the task sequence.

 

 

Secondly, when updating applications, is it necessary to use the supersedence option - and if so, is it necessary to keep each revision of a piece of software? There is a suggestion here of using batch scripts to call installers/uninstallers but this doesn't seem especially elegant, especially with the application above with multiple parts.

 

Using SCCM 2012 R2 CU1 on Windows Server 2008 R2

SCCM in my environment deploys Windows Updates and updates for Adobe Reader and Adobe Flash Player via SCUP.

I know there are 3rd parties that offer SCUP catalogs for updating regularly updated applications e.g. Java etc but my laughable budgets sadly won't stretch that far.

 

It is not necessary to use the supersedence option, but it may be necessary depending on the Application. If you update the package content, and detection method for an application (specifically in your case, updated the Application with a different MSI) then the App will probably not be discovered any longer, and devices that App is deployed to will then run the Deployment Type (or Program in old school lingo). This may be an effective method to upgrade devices, so long as the MSI will happily install on top of existing devices without the need for a prior uninstall. This is not always the case though, so careful testing is required. But for many of our Apps (Foxit Reader Enterprise for example), we simply updated the MSI and then SCCM will evaluate the software as no longer being installed and run the new MSI, and update all devices that the Application is deployed to.

[mpiechota]

Good morning,

 

I would appreciate if someone could advise on a couple of questions, please - I have been searching for a while.

 

One of the applications I am deploying has several parts to it and I am trying to understand how best to manage this applications deployment.

The application is Promethean ActiveInspire and as part of the installation there are the following MSIs that need to be installed;

 

ActivDriver x64.msi, ActivDriver x86.msi, ActivInspire.msi, ActivInspireCoreRes.msi, ActivInspireHelp.msi and ActivInspireHWRRes.msi

 

So, is it necessary to Create Application for each MSI and then deploy each application part to my collection(s) or can I send all parts in one go as a single Application?

 

I tried to add them as additional Deployment Types, but I don't think this is right, and only the Priority 1 MSI appears to be installed and the wording on the Deployment Types pane suggests to me this is only to give the administrator an option to deploy a single application but offer multiple deployment types dependent on platform or perhaps other requirements.

 

So, assuming my understanding above is correct, is there a more tidy way to deploy an application that has multiple parts to it without going down the route of some ugly scripts?

 

Secondly, when updating applications, is it necessary to use the supersedence option - and if so, is it necessary to keep each revision of a piece of software? There is a suggestion here of using batch scripts to call installers/uninstallers but this doesn't seem especially elegant, especially with the application above with multiple parts.

 

Using SCCM 2012 R2 CU1 on Windows Server 2008 R2

SCCM in my environment deploys Windows Updates and updates for Adobe Reader and Adobe Flash Player via SCUP.

I know there are 3rd parties that offer SCUP catalogs for updating regularly updated applications e.g. Java etc but my laughable budgets sadly won't stretch that far.

 

Many thanks

Jake

 

Did you come up with a solution to this? If not - after taking a crash course this weekend I have one that works. You *do* need to add each MSI to it's own application, so create one for each. But.. from there go back into each and use "dependencies" So, ActivInspire.msi is dependent on ActivInspireCoreRes.msi. ActiveInspireCoreRes.msi is dependent on ActivInspireHelp.msi. ActivinspireHelp.msi is dependent on ActivInspireHWRRes.msi. I keep the ActivDriver on it's own. When you do that, and deploy, it ties them all together and installs in order. Did the same for ITunes and QuickTime.

[ersatyle]

i know this is old but as it came up from a google search

 

my way to do this (notably for activInspire) is to wrap those installer with the PowerShell App Deployment Toolkit as I really don't want to create 5 or 6 applications at each new version and manage the supersedence and dependencies

 

the task sequence idea is good also but you loose the ability to deploy to a user collection and you still have to create 5 or 6 package (or 1 pacakge and 6 program)

 

hope that helps.

[Inf3rnoPanda]

My example is not quite so complicated, but I built an 'Application' with two deployment types to install Microsoft Visual C++ Redistributable, one each for 32-bit and 64-bit. When it's a 32-bit OS I only need the x86 version to install, however on a 64-bit OS I need both the x86 and x64 versions to install.

Deployment Types:
x64 is Priority 1, with requirement that it is running Windows 64-bit. It also has a dependency for the next deployment type.

x86 is Priority 2, with no requirements set. It has no dependencies.

Result:
When a Windows 64-bit client goes to install Microsoft Visual C++ Redistributable, it checks the first deployment type and meets it's requirement,and so commences install.
It is dependent on the x86 install, so it will go ahead and install that first.
Now satisfied it has met it's dependencies, it will install x64.

When a Windows 32-bit client goes to install Microsoft Visual C++ Redistributable, it checks the first deployment type, however does not meed it's requirement, so passes to the next on the list, which has no requirements, and so commences install.
It installs the x86 deployment type and reports success.

Clearly you still need to enter in all of the deployment type configuration which is the bulk of most applications, however at least you can publish it as one Application in your catalog.

Edited June 24, 2017 by Inf3rnoPanda

[jakobdahl]

On 6/24/2017 at 9:17 AM, Inf3rnoPanda said:

My example is not quite so complicated, but I built an 'Application' with two deployment types to install Microsoft Visual C++ Redistributable, one each for 32-bit and 64-bit. When it's a 32-bit OS I only need the x86 version to install, however on a 64-bit OS I need both the x86 and x64 versions to install.

Deployment Types:
x64 is Priority 1, with requirement that it is running Windows 64-bit. It also has a dependency for the next deployment type.

x86 is Priority 2, with no requirements set. It has no dependencies.

Result:
When a Windows 64-bit client goes to install Microsoft Visual C++ Redistributable, it checks the first deployment type and meets it's requirement,and so commences install.
It is dependent on the x86 install, so it will go ahead and install that first.
Now satisfied it has met it's dependencies, it will install x64.

When a Windows 32-bit client goes to install Microsoft Visual C++ Redistributable, it checks the first deployment type, however does not meed it's requirement, so passes to the next on the list, which has no requirements, and so commences install.
It installs the x86 deployment type and reports success.

Clearly you still need to enter in all of the deployment type configuration which is the bulk of most applications, however at least you can publish it as one Application in your catalog.

This is the way to go. In my case it is Acrobat Reader + patch, first it needs to install the program with msi fil and then update with msp

The option to use a new application with supersedence want work, because a new computer needs to have the base program installed before it can be pathed