Hi all, I am currently working on deploying CS6 Master Collection with munki by using packages built with AAMEE. Since not all users need apps like Dreamweaver, Premiere and Audition, I was wondering how others handle deployment. Currently, I have created a Master Collection package, a Photoshop, Illustrator, and InDesign package, a Dreamweaver and Fireworks package, and a Acrobat Pro X package. The problem I run into is that, since there are shared components (I believe this is the source of the problem), when I install the PS, IL, ID package and later want to install the DW and FW package, munki thinks DW and FW are already installed. I figure the problem is in my pkginfo or catalog, however, is it a better practice to package each major app individually?
As I continue to learn, I figured out the problem with trying to install different packages and why they would cause other to think they were installed. By default, munki imports packages from AAMEE with a installs key pointing to the common Uninstaller. I obviously fixed this using makepkginfo to find out the correct keys.
As I proceed, I'm going to package the major apps independently (PS, ID, IL, DW, BR, FW, Acrobat) and then maybe an Audio/Video Production package for the others (I hope nobody wants flash builder!).
Now my question comes to licensing. My take is that if an Adobe product is being installed via munki, I can create a pre-serialized installation package, since munki runs the installer. If I wanted to bake any of the Adobe apps into an image, I would need to create a trial package and then have munki run the serialization script (via update_for) to actually activate the products once the image has been deployed.
> As I continue to learn, I figured out the problem with trying to install different packages and why they would cause other to think they were installed. By default, munki imports packages from AAMEE with a installs key pointing to the common Uninstaller. I obviously fixed this using makepkginfo to find out the correct keys.
> As I proceed, I'm going to package the major apps independently (PS, ID, IL, DW, BR, FW, Acrobat) and then maybe an Audio/Video Production package for the others (I hope nobody wants flash builder!).
> Now my question comes to licensing. My take is that if an Adobe product is being installed via munki, I can create a pre-serialized installation package, since munki runs the installer. If I wanted to bake any of the Adobe apps into an image, I would need to create a trial package and then have munki run the serialization script (via update_for) to actually activate the products once the image has been deployed.
On Nov 8, 2012, at 9:23 AM, Harry Fike <hfi...@gmail.com> wrote:
> As I continue to learn, I figured out the problem with trying to install different packages and why they would cause other to think they were installed. By default, munki imports packages from AAMEE with a installs key pointing to the common Uninstaller. I obviously fixed this using makepkginfo to find out the correct keys.
I think I'm missing some detail here: are you using a CS6 Suite installer, and building packages that install different subsets of the applications in the suite? If so, yes, munkiimport's behavior here won't provide the needed installs array, and Munki then won't be able to distinguish between different packages built from a single CS6 Suite.
munkiimport's default behavior will work if you build an Adobe Photoshop CS6 installer using install media for Adobe Photoshop CS6, and an After Effects CS6 installer using media for After Effects CS6.
If, however, you start with the CS6 Production Premium Suite and use AAMEE to build a pkg that installs only Photoshop CS6 and a second pkg that installs only After Effects CS6, munkiimport will essentially identify both packages as "CS6 Production Premium Suite" installs and will not distinguish between the two. This would lead to behavior you implied: you install one package, and Munki thinks the other package is installed as well, since it's using the existence of the exact same item in both cases to determine installation status.
> As I proceed, I'm going to package the major apps independently (PS, ID, IL, DW, BR, FW, Acrobat)
Any particular reason for this? If you install Photoshop using a CS6 Suite license, you've burned an entire license. This does not allow you to use the same license to install Illustrator on a different machine. I tend to just install the entire Suite since that's what the license covers.
> and then maybe an Audio/Video Production package for the others (I hope nobody wants flash builder!).
> Now my question comes to licensing. My take is that if an Adobe product is being installed via munki, I can create a pre-serialized installation package, since munki runs the installer.
Yes.
> If I wanted to bake any of the Adobe apps into an image, I would need to create a trial package and then have munki run the serialization script (via update_for) to actually activate the products once the image has been deployed.
On 8 nov. 2012, at 19:09, Gregory Neagle <gregnea...@mac.com> wrote:
>> As I proceed, I'm going to package the major apps independently (PS, ID, IL, DW, BR, FW, Acrobat)
> Any particular reason for this? If you install Photoshop using a CS6 Suite license, you've burned an entire license.
I did the same, we have a campus license which basically allows us to install any CS6 Suite app on any machine.
> This does not allow you to use the same license to install Illustrator on a different machine. I tend to just install the entire Suite since that's what the license covers.
As the entire suite is somewhat heavy, I offer the good people of my university the ability to install a subset of the entire suite (most people are interested only in Photoshop and Acrobat Pro, some in Illustrator as well, only the DP department wants Indesign on top of that.)
I indeed had to modify the installs key to point to the specific app that is installed this way.
To sum up, I created serialized installer packages (including the overrides file to point to an internal update server) using AAMEE and then imported them into munki. I created individual packages for Acrobat, PS, IL, ID, and then packages containing DW+FW, another containing Audition, Encore, Premiere, After Effects, etc, and finally one for the whole Master Collection. Since we have a site license, I do not have to worry about multiple licenses or wasting a license when only installing a subset of the suite. I installed the whole suite from the original ISO/DMG on a freshly imaged machine, generated the installs keys using makepkginfo on each app, and then copied those into the appropriate pkginfo files in the repo. I know this is pretty basic, but hopefully it will help someone else who is learning. Next stop is dealing with updates!
On Thursday, November 8, 2012 1:39:41 PM UTC-5, Arjen van Bochoven wrote:
> On 8 nov. 2012, at 19:09, Gregory Neagle <gregn...@mac.com <javascript:>> > wrote:
> As I proceed, I'm going to package the major apps independently (PS, ID, > IL, DW, BR, FW, Acrobat)
> Any particular reason for this? If you install Photoshop using a CS6 Suite > license, you've burned an entire license.
> I did the same, we have a campus license which basically allows us to > install any CS6 Suite app on any machine.
> This does not allow you to use the same license to install Illustrator on > a different machine. I tend to just install the entire Suite since that's > what the license covers.
> As the entire suite is somewhat heavy, I offer the good people of my > university the ability to install a subset of the entire suite (most people > are interested only in Photoshop and Acrobat Pro, some in Illustrator as > well, only the DP department wants Indesign on top of that.)
> I indeed had to modify the installs key to point to the specific app that > is installed this way.
We're in the process of migrating separate business units into one system management setup, so we have a hojillion different license codes for Adobe tools. To save disk space, we moved the serial number to postflights, which means we share the dmg but have different plists per business unit. This is a long process to resolve, but it's getting there.
(a) We generated "trial" installers using the AAMEE tool.
(b) We have the Adobe PRTK utility as a munki package, called "AdobeProvisioningToolCS6"
(c) Each of our CS6 packages requires the PRTK package in a requires array.
(d) Each CS6 package has a postflight to inject the serial number:
> In regards to serialization, I prefer to do a trial and serialize
> separately. If you have multiple serial numbers this allows you more
> flexibility.
> Nate
> Sent from my iPhone
> On Nov 8, 2012, at 12:23 PM, Harry Fike <hfi...@gmail.com> wrote:
>> As I continue to learn, I figured out the problem with trying to install different packages and why they would cause other to think they were installed. By default, munki imports packages from AAMEE with a installs key pointing to the common Uninstaller. I obviously fixed this using makepkginfo to find out the correct keys.
>> As I proceed, I'm going to package the major apps independently (PS, ID, IL, DW, BR, FW, Acrobat) and then maybe an Audio/Video Production package for the others (I hope nobody wants flash builder!).
>> Now my question comes to licensing. My take is that if an Adobe product is being installed via munki, I can create a pre-serialized installation package, since munki runs the installer. If I wanted to bake any of the Adobe apps into an image, I would need to create a trial package and then have munki run the serialization script (via update_for) to actually activate the products once the image has been deployed.
I thought about doing the trial packages and then running the prtk at first, but since we have the site license, it makes things much simpler. If we do have other licenses pop up (or somebody needs an older version), I'll handle it on an individual basis.
I do plan on baking in the trial version to a few images for labs and using a payload free package to serialize it. Thanks for the example! I guess the best course of action would be to create the trial package, import it into munki, install on the "master" machine, take an image and deploy, and then make the prtk package and update for the trial. After typing all that out, I should just switch to using trial packages and the prtk required script for everything!
Thanks,
-- Harry
Sent from my iPhone.
On Nov 10, 2012, at 9:03 PM, Jim Zajkowski <jim.zajkow...@gmail.com> wrote:
> We're in the process of migrating separate business units into one system management setup, so we have a hojillion different license codes for Adobe tools. To save disk space, we moved the serial number to postflights, which means we share the dmg but have different plists per business unit. This is a long process to resolve, but it's getting there.
> (a) We generated "trial" installers using the AAMEE tool.
> (b) We have the Adobe PRTK utility as a munki package, called "AdobeProvisioningToolCS6"
> (c) Each of our CS6 packages requires the PRTK package in a requires array.
> (d) Each CS6 package has a postflight to inject the serial number:
> The CS5/5.5 packages are the same except for the arguments for the PRTK utility are different - see the PRTK documentation.
> --Jim
> On Nov 8, 2012, at 12:25 PM, Nate Walck <nate.wa...@GMAIL.COM> wrote:
>> In regards to serialization, I prefer to do a trial and serialize
>> separately. If you have multiple serial numbers this allows you more
>> flexibility.
>> Nate
>> Sent from my iPhone
>> On Nov 8, 2012, at 12:23 PM, Harry Fike <hfi...@gmail.com> wrote:
>>> As I continue to learn, I figured out the problem with trying to install different packages and why they would cause other to think they were installed. By default, munki imports packages from AAMEE with a installs key pointing to the common Uninstaller. I obviously fixed this using makepkginfo to find out the correct keys.
>>> As I proceed, I'm going to package the major apps independently (PS, ID, IL, DW, BR, FW, Acrobat) and then maybe an Audio/Video Production package for the others (I hope nobody wants flash builder!).
>>> Now my question comes to licensing. My take is that if an Adobe product is being installed via munki, I can create a pre-serialized installation package, since munki runs the installer. If I wanted to bake any of the Adobe apps into an image, I would need to create a trial package and then have munki run the serialization script (via update_for) to actually activate the products once the image has been deployed.
So I do have one more issue with this. When I first started deploying the AAMEE package for the entire Master Collection, the Installs key generated by munkiimport looked like this: <key>installs</key> <array> <dict> <key>path</key> <string>/Library/Application Support/Adobe/Uninstall/{41C543D4-AC29-4B7E-B95D-D73B7EB2EFBB}.db</string> <key>type</key> <string>file</string> </dict> </array> Any Adobe product that gets installed for CS6 is going to generate this, so like my previous problem, if I install just Acrobat Pro X, and then try to install Master Collection, munki thinks it is already installed. To correct this, I generated the install keys using makepkginfo --file on a clean install and dumped this into a copy of the pkginfo for Adobe CS6 Master Collection and appended Test to the name so it shows up differently in MSU. Ideally munki would have seen that all the Apps in the Installs key were installed and show "Installed" in MSU. On a clean install, this works correctly. However, after running Adobe updates on a machine, MSU (in optional updates) shows the package as Update Available. I would have expected it to say Not Installed, but not Update Available. As a troubleshooting step, I went through the pkginfo for the Test file and removed all of the <key>CFBundleShortVersionString</key> entries so it would just look for the path, however, this still produced the same results. Again, I copied the original pkginfo file, appended "Test" to the name, display name, and file name so it would who up separately in MSU. I then changed only the entries under <installs> and then ran makecatelogs. Any thoughts?
I don't have enough detail about what you've done and what you are seeing. See below.
On Nov 14, 2012, at 5:08 PM, Harry Fike <hfi...@gmail.com> wrote:
> So I do have one more issue with this. When I first started deploying the AAMEE package for the entire Master Collection, the Installs key generated by munkiimport looked like this:
> <key>installs</key>
> <array>
> <dict>
> <key>path</key>
> <string>/Library/Application Support/Adobe/Uninstall/{41C543D4-AC29-4B7E-B95D-D73B7EB2EFBB}.db</string>
> <key>type</key>
> <string>file</string>
> </dict>
> </array>
> Any Adobe product that gets installed for CS6 is going to generate this, so like my previous problem, if I install just Acrobat Pro X, and then try to install Master Collection, munki thinks it is already installed. To correct this, I generated the install keys using makepkginfo --file on a clean install and dumped this into a copy of the pkginfo for Adobe CS6 Master Collection and appended Test to the name so it shows up differently in MSU.
Not sure I follow what you did here.
> Ideally munki would have seen that all the Apps in the Installs key were installed and show "Installed" in MSU.
What does this mean? Are you talking about Optional Software (optional_installs)?
> On a clean install, this works correctly. However, after running Adobe updates on a machine,
How did you do this?
> MSU (in optional updates) shows the package
Which package?
> as Update Available. I would have expected it to say Not Installed, but not Update Available. As a troubleshooting step, I went through the pkginfo for the Test file and removed all of the <key>CFBundleShortVersionString</key> entries so it would just look for the path,
Not sure that will have the desired effect.
> however, this still produced the same results. Again, I copied the original pkginfo file, appended "Test" to the name, display name, and file name so it would who up separately in MSU. I then changed only the entries under <installs> and then ran makecatelogs. Any thoughts?
Can you provide more detail and more specific descriptions of what you did?
> I don't have enough detail about what you've done and what you are seeing. See below.
> On Nov 14, 2012, at 5:08 PM, Harry Fike <hfi...@gmail.com> wrote:
>> So I do have one more issue with this. When I first started deploying the AAMEE package for the entire Master Collection, the Installs key generated by munkiimport looked like this:
>> <key>installs</key>
>> <array>
>> <dict>
>> <key>path</key>
>> <string>/Library/Application Support/Adobe/Uninstall/{41C543D4-AC29-4B7E-B95D-D73B7EB2EFBB}.db</string>
>> <key>type</key>
>> <string>file</string>
>> </dict>
>> </array>
>> Any Adobe product that gets installed for CS6 is going to generate this, so like my previous problem, if I install just Acrobat Pro X, and then try to install Master Collection, munki thinks it is already installed. To correct this, I generated the install keys using makepkginfo --file on a clean install and dumped this into a copy of the pkginfo for Adobe CS6 Master Collection and appended Test to the name so it shows up differently in MSU.
> Not sure I follow what you did here.
I created an AAMEE package containing all Adobe software from CS6 Master Collection. Munkiimport generated the pkgsinfo file in the repo containing the installs key above. The file name of the pkgsinfo file generated is "Adobe CS6 Master Collection-6.plist" and the name key in this file is "Adobe CS6 Master Collection". I then duplicated the pkgsinfo file, renamed it to "Adobe CS6 Master Collection Test-6.plist" and changed the name key to "Adobe CS6 Master Collection Test" so I could modify the file to see what works. After running makecatalogs and adding the Adobe CS6 Master Collection Test to the optional_installs key in my test machines' manifests, both the original and Test packages show up in MSU as installed.
On a "clean" test machine, I installed the entire CS6 Master Collection from the original media/ISO and did not run updates. On this machine I ran makepkginfo --file on each of the main Adobe Apps which I used to generate the installs key below that I then put into the Test pkginfo file:
>> Ideally munki would have seen that all the Apps in the Installs key were installed and show "Installed" in MSU.
> What does this mean? Are you talking about Optional Software (optional_installs)?
You are correct, in Optional Software.
>> On a clean install, this works correctly. However, after running Adobe updates on a machine,
> How did you do this?
If on the machine that I used to generate the installs key from above, I added the Test package to the optional_installs key in its manifest. Running MSU and looking in Optional Software, the Test package shows up as Installed. I also added the Test package to another machine that has had Adobe Updates run on it, and on this machine, Optional Software in MSU the Test package as Update Available.
>> MSU (in optional updates) shows the package
> Which package?
>> as Update Available. I would have expected it to say Not Installed, but not Update Available. As a troubleshooting step, I went through the pkginfo for the Test file and removed all of the <key>CFBundleShortVersionString</key> entries so it would just look for the path,
> Not sure that will have the desired effect.
I thought that if Adobe's versioning for updates didn't make sense (i.e. Audition's version from the original install is 5.0x708 and the updated version is 5.0.2x5), I could remove the CFBundleShortVersionString from the installs keys
...
Maybe a more simple question. If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and it is run when they start up which is about 30 mins before the first students arrive.
“Weaseling out of things is important to learn. It’s what separates us from the animals.....except the weasel” ~ Homer Simpson
________________________________ From: Harry Fike <hfi...@gmail.com> To: munki-dev@googlegroups.com Sent: Thursday, 15 November 2012, 14:42 Subject: Re: [munki-dev] Adobe CS6 packages
Maybe a more simple question. If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
1) The installcheck_script returns non-zero.
or
2) Every item in the installs list exists on the startup disk and has a version >= the version in the installs list.
or
3) Every receipt in the receipts list exists on the startup disk and has a version >= the version in the installs list.
-Greg
On Nov 15, 2012, at 6:42 AM, Harry Fike <hfi...@gmail.com> wrote:
> Maybe a more simple question.
> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
> it is run when they start up which is about 30 mins before the first students arrive.
> “Weaseling out of things is important to learn. It’s what separates
> us from the animals.....except the weasel” ~ Homer Simpson
> From: Harry Fike <hfi...@gmail.com>
> To: munki-dev@googlegroups.com > Sent: Thursday, 15 November 2012, 14:42
> Subject: Re: [munki-dev] Adobe CS6 packages
> Maybe a more simple question.
> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
> I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
> -Greg
> On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
>> it is run when they start up which is about 30 mins before the first students arrive.
>> “Weaseling out of things is important to learn. It’s what separates
>> us from the animals.....except the weasel” ~ Homer Simpson
>> From: Harry Fike <hfi...@gmail.com>
>> To: munki-dev@googlegroups.com >> Sent: Thursday, 15 November 2012, 14:42
>> Subject: Re: [munki-dev] Adobe CS6 packages
>> Maybe a more simple question.
>> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
> for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
> an expert is someone who has made every possible mistake in a narrow field of expertise...
> On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>> I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>> -Greg
>> On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
>>> it is run when they start up which is about 30 mins before the first students arrive.
>>> “Weaseling out of things is important to learn. It’s what separates
>>> us from the animals.....except the weasel” ~ Homer Simpson
>>> From: Harry Fike <hfi...@gmail.com>
>>> To: munki-dev@googlegroups.com >>> Sent: Thursday, 15 November 2012, 14:42
>>> Subject: Re: [munki-dev] Adobe CS6 packages
>>> Maybe a more simple question.
>>> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
sure. it's a work in progress so not complete by any means. i'm using the tools from Adobe to create a local http repo for Adobe CS (by default it syncs CS5, 5.5 and 6. both Win and OS X). the sync took 10 hours for 30gb of updates, slow. It's on one of my Mountain Lion servers but could reside on any box running web services. You then setup up the web services for delivery. This is as far as I have completed. Next is to get the Clients to use the local repo for updates instead of calling home which involves re-configuring Adobe Application Manager (AdobeUpdater.overrides). This is todays task. If your interested i'll report back on the progress. With this setup you can get AAMEE to pull updates from your repo when generating masters instead of calling home also. At this point (in the process) you still need a "window" to run updates as you still require admin authentication. My next task is to look at Codename Remote Update Manager to run updates managed without the need for admin rights and and update "window" so that you get similar functionality to Munki ie managed updates without the need for admin authentication. All the tools are available from Adobe and bar the poor documentation are (so far) easy to implement. As before it's a work in progress and there's much to do but it may be an option for some. We run Win and OS X clients with Master Collection so there's other benefits for us with this.
> On Nov 15, 2012, at 10:03 AM, The Immoral Tristy <theimmoralmajor...@gmail.com> wrote:
>> for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
>> an expert is someone who has made every possible mistake in a narrow field of expertise...
>> On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>>> I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>>> -Greg
>>> On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>>> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
>>>> it is run when they start up which is about 30 mins before the first students arrive.
>>>> “Weaseling out of things is important to learn. It’s what separates
>>>> us from the animals.....except the weasel” ~ Homer Simpson
>>>> From: Harry Fike <hfi...@gmail.com>
>>>> To: munki-dev@googlegroups.com >>>> Sent: Thursday, 15 November 2012, 14:42
>>>> Subject: Re: [munki-dev] Adobe CS6 packages
>>>> Maybe a more simple question.
>>>> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
> sure. it's a work in progress so not complete by any means. i'm using the tools from Adobe to create a local http repo for Adobe CS (by default it syncs CS5, 5.5 and 6. both Win and OS X). the sync took 10 hours for 30gb of updates, slow. It's on one of my Mountain Lion servers but could reside on any box running web services. You then setup up the web services for delivery. This is as far as I have completed. Next is to get the Clients to use the local repo for updates instead of calling home which involves re-configuring Adobe Application Manager (AdobeUpdater.overrides). This is todays task. If your interested i'll report back on the progress. With this setup you can get AAMEE to pull updates from your repo when generating masters instead of calling home also. At this point (in the process) you still need a "window" to run updates as you still require admin authentication. My next task is to look at Codename Remote Update Manager to run updates managed without the need for admin rights and and update "window" so that you get similar functionality to Munki ie managed updates without the need for admin authentication. All the tools are available from Adobe and bar the poor documentation are (so far) easy to implement. As before it's a work in progress and there's much to do but it may be an option for some. We run Win and OS X clients with Master Collection so there's other benefits for us with this.
>> Could you provide details of what you've done?
>> Sent from my iPhone
>> On Nov 15, 2012, at 10:03 AM, The Immoral Tristy <theimmoralmajor...@gmail.com> wrote:
>>> for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
>>> an expert is someone who has made every possible mistake in a narrow field of expertise...
>>> On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>>>> I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>>>> -Greg
>>>> On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>>>> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
>>>>> it is run when they start up which is about 30 mins before the first students arrive.
>>>>> “Weaseling out of things is important to learn. It’s what separates
>>>>> us from the animals.....except the weasel” ~ Homer Simpson
>>>>> From: Harry Fike <hfi...@gmail.com>
>>>>> To: munki-dev@googlegroups.com >>>>> Sent: Thursday, 15 November 2012, 14:42
>>>>> Subject: Re: [munki-dev] Adobe CS6 packages
>>>>> Maybe a more simple question.
>>>>> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
> I understand how Adobe RUM and the local update repo work.
> What I don't understand, and would like to hear from people who are doing this:
> RUM just updates Adobe apps. It doesn't interact with any logged in user. What happens if RUM tries to update Adobe apps that are in use?
> How do you find out what's been updated? How do you get notified of any errors or problems?
> What happens if RUM runs when no-one is logged in? Do all updates apply successfully in that situation?
> -Greg
> On Nov 15, 2012, at 1:44 PM, Tristan Mason <theimmoralmajor...@gmail.com> wrote:
>> sure. it's a work in progress so not complete by any means. i'm using the tools from Adobe to create a local http repo for Adobe CS (by default it syncs CS5, 5.5 and 6. both Win and OS X). the sync took 10 hours for 30gb of updates, slow. It's on one of my Mountain Lion servers but could reside on any box running web services. You then setup up the web services for delivery. This is as far as I have completed. Next is to get the Clients to use the local repo for updates instead of calling home which involves re-configuring Adobe Application Manager (AdobeUpdater.overrides). This is todays task. If your interested i'll report back on the progress. With this setup you can get AAMEE to pull updates from your repo when generating masters instead of calling home also. At this point (in the process) you still need a "window" to run updates as you still require admin authentication. My next task is to look at Codename Remote Update Manager to run updates managed without the need for admin rights and and update "window" so that you get similar functionality to Munki ie managed updates without the need for admin authentication. All the tools are available from Adobe and bar the poor documentation are (so far) easy to implement. As before it's a work in progress and there's much to do but it may be an option for some. We run Win and OS X clients with Master Collection so there's other benefits for us with this.
>>> Could you provide details of what you've done?
>>> Sent from my iPhone
>>> On Nov 15, 2012, at 10:03 AM, The Immoral Tristy <theimmoralmajor...@gmail.com> wrote:
>>>> for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
>>>> an expert is someone who has made every possible mistake in a narrow field of expertise...
>>>> On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>>>>> I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>>>>> -Greg
>>>>> On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>>>>> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
>>>>>> it is run when they start up which is about 30 mins before the first students arrive.
>>>>>> “Weaseling out of things is important to learn. It’s what separates
>>>>>> us from the animals.....except the weasel” ~ Homer Simpson
>>>>>> From: Harry Fike <hfi...@gmail.com>
>>>>>> To: munki-dev@googlegroups.com >>>>>> Sent: Thursday, 15 November 2012, 14:42
>>>>>> Subject: Re: [munki-dev] Adobe CS6 packages
>>>>>> Maybe a more simple question.
>>>>>> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
I looked at that documentation before and that led to some of my confusion. From what I have learned/experienced, I should only get "Update Available" as the status in Optional Software of MSU if the version number increases in <key>version</key> of a pkgsinfo file. Is that correct, or are there other variables that would cause the status to report "Update Available" instead of "Not Installed". My next step is to go through the installs keys in the pkgsinfo one by one to see if Adobe potentially did something strange with one of their updates that either didn't increase the version number logically or maybe moved the location of an application.
> 1) The installcheck_script returns non-zero. > or > 2) Every item in the installs list exists on the startup disk and has a > version >= the version in the installs list. > or > 3) Every receipt in the receipts list exists on the startup disk and has a > version >= the version in the installs list.
> -Greg
> On Nov 15, 2012, at 6:42 AM, Harry Fike <hfi...@gmail.com <javascript:>> > wrote:
> > Maybe a more simple question. > > If munki, while running its install checks against a package's installs > key finds that some of the listed packages are installed and some are not, > does it return Update Available instead of Not Installed?
There is no user interaction. That is why we run it when the machines startup, which is 30 mins before the first class. All the updates, if any, are then done and dusted. Output is written to a log file, simply a "0" if successful or a "1" if not. Munki is not involved in any way.
“Weaseling out of things is important to learn. It’s what separates us from the animals.....except the weasel” ~ Homer Simpson
________________________________ From: Gregory Neagle <gregnea...@mac.com> To: munki-dev@googlegroups.com Sent: Thursday, 15 November 2012, 21:51 Subject: Re: [munki-dev] Adobe CS6 packages
I understand how Adobe RUM and the local update repo work.
What I don't understand, and would like to hear from people who are doing this:
RUM just updates Adobe apps. It doesn't interact with any logged in user. What happens if RUM tries to update Adobe apps that are in use?
How do you find out what's been updated? How do you get notified of any errors or problems?
What happens if RUM runs when no-one is logged in? Do all updates apply successfully in that situation?
-Greg
On Nov 15, 2012, at 1:44 PM, Tristan Mason <theimmoralmajor...@gmail.com> wrote:
sure. it's a work in progress so not complete by any means. i'm using the tools from Adobe to create a local http repo for Adobe CS (by default it syncs CS5, 5.5 and 6. both Win and OS X). the sync took 10 hours for 30gb of updates, slow. It's on one of my Mountain Lion servers but could reside on any box running web services. You then setup up the web services for delivery. This is as far as I have completed. Next is to get the Clients to use the local repo for updates instead of calling home which involves re-configuring Adobe Application Manager (AdobeUpdater.overrides). This is todays task. If your interested i'll report back on the progress. With this setup you can get AAMEE to pull updates from your repo when generating masters instead of calling home also. At this point (in the process) you still need a "window" to run updates as you still require admin authentication. My next task is to look at Codename Remote Update Manager to run updates
managed without the need for admin rights and and update "window" so that you get similar functionality to Munki ie managed updates without the need for admin authentication. All the tools are available from Adobe and bar the poor documentation are (so far) easy to implement. As before it's a work in progress and there's much to do but it may be an option for some. We run Win and OS X clients with Master Collection so there's other benefits for us with this.
>>On Nov 15, 2012, at 10:03 AM, The Immoral Tristy <theimmoralmajor...@gmail.com> wrote:
>>for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
>>>an expert is someone who has made every possible mistake in a narrow field of expertise...
>>>On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>>>I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>>>>-Greg
>>>>On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>>>I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and >>>>>it is run when they start up which is about 30 mins before the first students arrive.
>>>>>________________________________ >>>>> From: Harry Fike <hfi...@gmail.com> >>>>>To: munki-dev@googlegroups.com >>>>>Sent: Thursday, 15 November 2012, 14:42 >>>>>Subject: Re: [munki-dev] Adobe CS6 packages
>>>>>Maybe a more simple question. >>>>>If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
“Weaseling out of things is important to learn. It’s what separates us from the animals.....except the weasel” ~ Homer Simpson
________________________________ From: Gregory Neagle <gregnea...@mac.com> To: munki-dev@googlegroups.com Sent: Thursday, 15 November 2012, 21:51 Subject: Re: [munki-dev] Adobe CS6 packages
I understand how Adobe RUM and the local update repo work.
What I don't understand, and would like to hear from people who are doing this:
RUM just updates Adobe apps. It doesn't interact with any logged in user. What happens if RUM tries to update Adobe apps that are in use?
How do you find out what's been updated? How do you get notified of any errors or problems?
What happens if RUM runs when no-one is logged in? Do all updates apply successfully in that situation?
-Greg
On Nov 15, 2012, at 1:44 PM, Tristan Mason <theimmoralmajor...@gmail.com> wrote:
sure. it's a work in progress so not complete by any means. i'm using the tools from Adobe to create a local http repo for Adobe CS (by default it syncs CS5, 5.5 and 6. both Win and OS X). the sync took 10 hours for 30gb of updates, slow. It's on one of my Mountain Lion servers but could reside on any box running web services. You then setup up the web services for delivery. This is as far as I have completed. Next is to get the Clients to use the local repo for updates instead of calling home which involves re-configuring Adobe Application Manager (AdobeUpdater.overrides). This is todays task. If your interested i'll report back on the progress. With this setup you can get AAMEE to pull updates from your repo when generating masters instead of calling home also. At this point (in the process) you still need a "window" to run updates as you still require admin authentication. My next task is to look at Codename Remote Update Manager to run updates
managed without the need for admin rights and and update "window" so that you get similar functionality to Munki ie managed updates without the need for admin authentication. All the tools are available from Adobe and bar the poor documentation are (so far) easy to implement. As before it's a work in progress and there's much to do but it may be an option for some. We run Win and OS X clients with Master Collection so there's other benefits for us with this.
>>On Nov 15, 2012, at 10:03 AM, The Immoral Tristy <theimmoralmajor...@gmail.com> wrote:
>>for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
>>>an expert is someone who has made every possible mistake in a narrow field of expertise...
>>>On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>>>I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>>>>-Greg
>>>>On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>>>I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and >>>>>it is run when they start up which is about 30 mins before the first students arrive.
>>>>>________________________________ >>>>> From: Harry Fike <hfi...@gmail.com> >>>>>To: munki-dev@googlegroups.com >>>>>Sent: Thursday, 15 November 2012, 14:42 >>>>>Subject: Re: [munki-dev] Adobe CS6 packages
>>>>>Maybe a more simple question. >>>>>If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
I know of at least one update in CS6 that won't update properly at the login window (patching manually or using Munki), the most recent Flash Pro update. It triggers the Extension Manager's installer to install "Toolkit for CreateJS 1.1", and this requires user interaction and a GUI login session.
Amazingly, Adobe released a special "silent installer" following complaints:
Can't test RUM for this particular problematic update, but unless there is some special logic in the update mechanism and/or feed that it can make use of to act differently, RUM would probably fail the same way a manual patch does.
> What happens if RUM runs when no-one is logged in? Do all updates apply successfully in that situation?
> -Greg
> On Nov 15, 2012, at 1:44 PM, Tristan Mason <theimmoralmajor...@gmail.com> wrote:
>> sure. it's a work in progress so not complete by any means. i'm using the tools from Adobe to create a local http repo for Adobe CS (by default it syncs CS5, 5.5 and 6. both Win and OS X). the sync took 10 hours for 30gb of updates, slow. It's on one of my Mountain Lion servers but could reside on any box running web services. You then setup up the web services for delivery. This is as far as I have completed. Next is to get the Clients to use the local repo for updates instead of calling home which involves re-configuring Adobe Application Manager (AdobeUpdater.overrides). This is todays task. If your interested i'll report back on the progress. With this setup you can get AAMEE to pull updates from your repo when generating masters instead of calling home also. At this point (in the process) you still need a "window" to run updates as you still require admin authentication. My next task is to look at Codename Remote Update Manager to run updates managed without the need for admin rights and and update "window" so that you get similar functionality to Munki ie managed updates without the need for admin authentication. All the tools are available from Adobe and bar the poor documentation are (so far) easy to implement. As before it's a work in progress and there's much to do but it may be an option for some. We run Win and OS X clients with Master Collection so there's other benefits for us with this.
>>> Could you provide details of what you've done?
>>> Sent from my iPhone
>>> On Nov 15, 2012, at 10:03 AM, The Immoral Tristy <theimmoralmajor...@gmail.com> wrote:
>>>> for what it's worth I've found it easier just to run a local Adobe update server and avoid Adobe and Munki having any contact...
>>>> an expert is someone who has made every possible mistake in a narrow field of expertise...
>>>> On 16/11/2012, at 6:32 AM, Gregory Neagle <gregnea...@mac.com> wrote:
>>>>> I've never figured out how to sanely/safely integrate Adobe RUM with Munki.
>>>>> -Greg
>>>>> On Nov 15, 2012, at 8:48 AM, Hugh Burt <hubu...@yahoo.co.uk> wrote:
>>>>>> I try and keep things as simple as possible, so our CS6 products are kept updated with Adobe RUM (Remote Update Manager). I used Munki to install it on all the machines and
>>>>>> it is run when they start up which is about 30 mins before the first students arrive.
>>>>>> “Weaseling out of things is important to learn. It’s what separates
>>>>>> us from the animals.....except the weasel” ~ Homer Simpson
>>>>>> From: Harry Fike <hfi...@gmail.com>
>>>>>> To: munki-dev@googlegroups.com >>>>>> Sent: Thursday, 15 November 2012, 14:42
>>>>>> Subject: Re: [munki-dev] Adobe CS6 packages
>>>>>> Maybe a more simple question.
>>>>>> If munki, while running its install checks against a package's installs key finds that some of the listed packages are installed and some are not, does it return Update Available instead of Not Installed?
On the original topic, after working through the different installs keys, I found that Adobe screwed up the versioning for Audition (clean install version 5.0x708, updated to 5.0.2x5), Extension Manager (clean install version 6.0.412, updated to 6.0.4.8), and Speed Grade (clean install version 2012.7766.34, updated to 6.0.4). If I installed the full CS6 suite via munki and then ran Adobe Updates, MSU would want to install the full suite again reporting "Update Available" in Optional Software. Temporarily I fixed the issue by commenting out the entries for each of the above in the the installs key. I believe I can fix Speed Grade by editing its version to 6.0, however, what would be the best way to deal with Audition since it uses "x" as part of the version? I'm not deploying Adobe updates using munki yet, so I won't have a problem at the moment, however, this may creep back to bite me in the future if I don't work around it correctly.
