[Casper] Distribution of Adobe CS3 and CS4 suites

[Ernst, Craig S.]

You don't really need to guess the order...just run through an Adobe Updater
cycle once after a fresh install and observe the order it installs it in. =)

Craig E

On 10/30/09 10:14 AM, "Don Montalvo" <donmontalvo at gmail.com> wrote:

> Great idea. I'd also like to see Casper intelligently sort the many
> dozens of Adobe CS4 updates that we need to pull down and push out. So
> we don't have to guess the order.
> 
> Don
> 
> On Oct 30, 2009, at 6:39, "Ernst, Craig S." <ERNSTCS at uwec.edu> wrote:
> 
>> The other thing that I forgot to mention was a feature request I put
>> in
>> regarding patching. I had asked for them to make an additional tab
>> on your
>> Adobe install where you select the applications to install and input
>> your
>> license code that had all the Adobe updaters listed, you could check
>> them,
>> and they would get applied immediately after the main Adobe install
>> would
>> run. This way the process is totally integrated into their processes.
>> 
>> Good idea? Bad idea? Thoughts?
>> 
>> Craig E
>> 
>> 
>> On 10/29/09 8:59 PM, "Ernst, Craig S." <ERNSTCS at uwec.edu> wrote:
>> 
>>> This absolutely works for the CS4 patches, just dropping the
>>> downloaded ones
>>> directly into the JSS. I use it as part of my install process.
>>> 
>>> Just install your Adobe CS4 base, run Adobe Updater to download the
>>> updates,
>>> just don't install them, and put them into the JSS. I also make
>>> note of the
>>> order that the Adobe Updater wants to install the patches.
>>> 
>>> A self-service policy to install CS4 performs a sequence of three
>>> different
>>> policies called by a script. As a self-service it's nice because
>>> the user is
>>> already logged in.
>>> 
>>> - First Adobe CS4 Base installs
>>> - Second Adobe CS4 patches install
>>> - Lastly all of my traditional composer packages lay over top for
>>> Reader and
>>> Pro, installs PDF9 printer, and a recon cycle.
>>> 
>>> This is my basic process for FirstRun as well except for all of the
>>> intricacies for making the patching part happen. What happens here
>>> is that a
>>> script at the end of FirstRun is triggered that calls a policy that
>>> adds a
>>> local user, installs an autologin package for that user, and then
>>> reboots
>>> the system.
>>> 
>>> When the system reboots it auto logs on, a policy looking for that
>>> user is
>>> triggered to perform the patches and lay over packages. Since a
>>> user is
>>> logged in things are fairly reliable. At the end it removes the
>>> auto login
>>> stuff, installs a startup item, and reboots again.
>>> 
>>> The startup item runs, deletes the user and home for patching, and
>>> runs a
>>> recon.
>>> 
>>> Of course there are a myriad of scripts and policies for these two
>>> things to
>>> work, but it does work. I had some issues for a little while with my
>>> FirstRun install because a different policy was installing at
>>> FirstRun that
>>> required a reboot so it would reboot mid FirstRun and then it was a
>>> nasty
>>> loop since FirstRun never had the chance to delete itself. =)
>>> 
>>> I really do hope I have time to get this all typed up in greater
>>> detail.
>>> 
>>> Craig E
>>> 
>>> 
>>> On 10/29/09 8:41 PM, "Don Montalvo" <donmontalvo at gmail.com> wrote:
>>> 
>>>> It would seem like you'd need to pull into Casper a few dozen
>>>> updates
>>>> so they can each be pushed out individually. If this works, it's a
>>>> winner to me (at least until they fire all of the Adobe installer
>>>> developers responsible for this fiasco, and hire fresh blood who can
>>>> give us proper pkg installers <g>).
>>> 
>>> _______________________________________________
>>> Casper mailing list
>>> Casper at list.jamfsoftware.com
>>> http://list.jamfsoftware.com/mailman/listinfo/casper
>>