Jump to content


bennettjd

Deploy application and then after deploy update to application

Recommended Posts

Using SCCM 2012 and deploying applications. Say I deploy Adobe Acrobat 9 Pro (9.0.0) now say 1 month goes by and there is an update to 9.1.0. How would I deploy that to the already installed 9.0.0 and then update the install to the collection so it installs 9.0.0 and then updates to 9.1.0? I am using ad groups to collection and then advertising to the collection. I would like to perform the updates even though they are up to 9.4.1 and have to increment.

 

Most of this is to clean up old installs that have not been patched. I have more applications then just this one?

 

Do I create a new application for each of the updates or is there a better way?

Share this post


Link to post
Share on other sites

SCCM 2012 has nice feature called supersedence read more info here http://technet.microsoft.com/en-us/library/gg682071.aspx

Supercedene the old application with new one ..so when the new application is avilable ,it removes the old application and install the current one.

But you will have to make the arragement for this to remove old and install new one.

Share this post


Link to post
Share on other sites

Updates are not covered by the application model and by supersedence. This works only for msi files/major versions.

Best practice for Adobe 9 is still AIP for new installations, which should only include the quarterly updates. Already deplyoed installations will be patched by the msp files, either by SCUP or by a package which holds all msp files and a script which installs the needed updates step by step.

  • Like 1

Share this post


Link to post
Share on other sites

Peter33, What is AIP? Can you post a link to that? I just got the SCUP installed and got the 3 Adobe catalogs added in. Acrobat X, Adobe Reader, and FlashPlayer. Is there away to get more catalogs from Adobe?

 

Another instance of updates that i might not have a msp, and I might have to look at SCUP for is like classroom management software that updates every 2 months. It is an exe? I did not know if I would update the application install or would i create a new application in sccm and then do something to tell the clients to update?

Share this post


Link to post
Share on other sites

Sorry, my fault. Adobe only supports Adobe X for SCUP. There was a catalog for adobe 9 available 2 years ago. But it's gone now. Think that was just some sort of test and we also never used it. I prefered the script wrapper. for updating version 9.

An AIP is and administrative msi installation (msiexec /a) where you can directly apply all needed msp files. Make sure that you don't apply security updates to it or it will break the installation and no further patches can be applied. Here are 2 links.

 

http://blogs.adobe.c..._tai/archives/9

http://helpx.adobe.c...t-reader-7.html

 

For every quarterly update you have to modify the base package/application and to update your distribution points. This way new installations are always being installed (almost) fully patched. You need an additional package that will update the already deployed installations with the latest patch. Of course you could also create a completely new package for every new single patch. A script wrapper which uses a wmi query to verify the installed version is useful though. Saves a lot of unneeded errors.

 

Thinking about Eswars post again ... you also could abuse the application and supersedence model though, because scripts are allowed where msp files are not. But Adobe 9 would not be a good candidate for that. It needs a ton of patches. I would use it only for major versions.

Share this post


Link to post
Share on other sites

So you guys recommend either using

1. SCUP for Adobe updates or

2. using AIP and deploying a new slipstreamed MSI with the patches that supersceedes the fist package.

 

You couldn't just use a new package that superscedes the main package with a command like this:

msiexec /i "AdbeRdr1010_en_US.msi" patch="\\sccm1\SCCM Sources\Acrobat Reader 10x\AdbeRdrUpd1012.msp" /q

 

I've tried but have run into some issues getting it to deploy.

Share this post


Link to post
Share on other sites

So I have official given up on trying to patch the MSI and am using the AIP/Slipstream method. My only concern is that my CCMCACHE will get significantly bigger over time.

Share this post


Link to post
Share on other sites

So if i need to run updates for application "x" at version 4.0.0.

So I deploy application x.

What i want to know what is the best practice or best way to start the updates? Now the updates have to be deployed in order.

So 2 months there is 4.0.3

Then 2 months there is a 4.1.0.

Also how does it handle if I deploy Application X and then create an update through SCUP. Will sccm try to re install X to 4.0.0 or will it leave it alone and allow 4.0.3 to be applied with nothing after that.

Share this post


Link to post
Share on other sites

So you guys recommend either using

1. SCUP for Adobe updates or

2. using AIP and deploying a new slipstreamed MSI with the patches that supersceedes the fist package.

 

You couldn't just use a new package that superscedes the main package with a command like this:

msiexec /i "AdbeRdr1010_en_US.msi" patch="\\sccm1\SCCM Sources\Acrobat Reader 10x\AdbeRdrUpd1012.msp" /q

 

I've tried but have run into some issues getting it to deploy.

 

 

Actually i am using the Settings Management to create role based non compliant collections to deploy the latest patches for the current installations of Adobe X Reader, Standard and Professional. The Settings Management has the benefit that i have always a quick overwiew of the compliance of my installations.

AIPs are obsolete for Adobe X because the patches are now incremental. It makes no sense anymore because you have to start over from the beginning for every patch now. For Acrobat 9 it's still the way to go though.

Share this post


Link to post
Share on other sites

@ Peter 33

No sure I understand what "Setting Management" is? Is that something in SCUP? My plans is to do the following:

 

Assume 10.0.1 is already packaged because no MSP is needed. We can talk about transforms if you like but that is a separate issue.

1. msiexec /a "PATHTO\AdbeRdr1010_en_US.msi"

2. Go through the prompts and put the files in a Network Location

3. msiexec /a "NetworkPATHTO\AdbeRdr1010_en_US.msi" /p "PATHTO\AdbeRdrUpd10.11.msp

4. Create A new package called Adobe Acrobat 10.1.2 and point to the Network MSI. You will notice that the MSI is now expanded and should only be about 2 mb. This means you can not move the folders until after you create the package.

5. Supersede Adobe Acorboat 10.1.0 with Acrobat 10.1.2 and check uninstall.

6. Deploy Application to you Test Group.

 

Now if you want to apply transform and lets say remove the desktop icon or turn off update you would simply create the transform with the ADobe Reader Customization Tool X and at Transform=Nameoftransform.mst in the Commandl ine and deploy

 

@bennettjd

With the current Adobe Strategy. You can apply the msp for 10.1.4 to the 10.1.0 package and not have any issues. You can set SCCM to Uninstall the existing package if you like in the supersede

Share this post


Link to post
Share on other sites

Hi Howard,

 

Settings Management is the former "Desired Configuration Management". It has nothing to do with SCUP, but it's a pretty nice feature and much improved compared to 2007.

Anyways, why the admin install for version 10? You have to create a new AIP for every single patch again and the file transfer of the caching will be slowed down, because all files are being extracted and not held in the msi anymore. For the Reader this might be still ok, but for the Pro version that will be thousands of files.

Also the supersedence should not be used to deploy minor version patches. As you said this will uninstall the old version and then install the new version. Not really the way you want deploy security patches. For Adobe X Pro the whole process would take like 30-40 minutes.

 

My Adobe X applications for the base installations are script wrappers installing the msi together with a transforms file and right after that the latest available patch.

For the patching of already deployed installations i am using regular packages.

Share this post


Link to post
Share on other sites

Fair point peter. I am a bit of a noob with SCCM. THe last time I used this tool was SMS so a lot has changed for me. I will do my research on Settings Management as it sounds like a powerful tool. Could you post an example of the script you are using to deploy your MSP's and take me through the workflow?

 

For Example:

 

Day 1 Adobe Releases Reader X 10.1.0 - You deliver the simple MSI to a target machine/user Collection

Day 45 Adobe Release Reader X 10.1.1 - How do you deliver the MSP to your existing Collection.

Day 90 Adobe releases Reader X 10.1.2 - How do you deliver the MSP to the same collection plus you added 100 Machines/People, how do they get the application. Do you deploy the base MSI plus Each Patch or do you only deliver 10.1.0 and the MSP for 10.1.2.

 

What does this look like in your Software Library? What does your Collection Look Like? Are there multiple Applications are you using Packages to accomplish this?

 

Sorry for all the questions but you have me intrigued as I thought I had this nailed already.

Share this post


Link to post
Share on other sites

All right. After all this i was completely rethinking the whole process again, because i noticed that i still had too much overhead. So i started to simplify my adobe installations.

Here is what i did.

 

1. Creating the Base Application for the MSI in the Software Library

- the source directory contains the MSI the MST and the Setup.ini

-create new application

- manually specify the application information

- add a deployment type

- Windows Installer Native

- edit the program tab in the deployment type

msiexec /i AdbeRdr1010_de_DE.msi TRANSFORMS=AdbeRdr1010_de_DE.mst /q

- edit the requirements tab and add windows 7 as requirement

 

2. Creating the Patch Application

- the source directory contains the MSP and the VBS file

- create new application

- manually specify the application information

- add deployment type

- Script Installer Native

- installation program : cscript.exe patchadobe.vbs

- specify how deployment is detected -> Product code of the Base MSI but version of the Patch File

- Installation requirements : Windows 7

- Installation Dependencies: add the Base Application for Adobe Reader

 

 

Here is the script wrapper for the patching

--------------------------------------------------------------

Set sho = Wscript.CreateObject("Wscript.Shell")

strCommand = "msiexec.exe /p AdbeRdrUpd1013.msp /q"

intRet = sho.run(strCommand,0,True)

wscript.quit(intRet)

----------------------------------------------------------------

 

 

Finally deploy both applications to your "all windows 7 systems" collection

 

For the next patch, let's say its 10.1.4 just replace the MSP file in the source directory of the patch application and the name of the file in the script. Then edit the deployment type in the patch application and change the version number in the deployment type detection. Update the distribution points and you are done.

Share this post


Link to post
Share on other sites

I am trying to customize the Office Communicator 2007 R2 Application that came with the Application Model Kit in the SCCM 2012 SDK.

 

We use Office Communicator, but have it patched. I was trying to work out a way to patch it all in one deployment type, but as I am reading various posts, it sounds like this is not possible. The post above has a good description, but I also had another idea.

 

Could I create a deployment type called "Office Communicator 2007 R2 November 2012 Patch", specify this in the command line "msiexec /p 3.5.6907.266Patch.msp /norestart /qb" and add a dependency for the Office Communicator 2007 R2 deployment type that came from the Application Model Kit?

 

That's what I have right now and I'm jsut beginning to test with it.

 

One thing I wondered about is the Detection Rule that came with the Application Model Kit "Office Communicator 2007 R2" deployment type. I changed that so that it refers to the Product code from the MSI that I have.

 

I'll let you know how it goes

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...