Skip to main content
Solved

Adobe CS6 Self Service deployment really slow, serialization check..

  • May 28, 2013
  • 8 replies
  • 48 views
M
Forum|alt.badge.img+7

Hey community,

I have a couple of questions regarding deploying Adobe CS6 Design & Web. I've created a package using AAMEE and just tried to deploy it to my iMac. While it was ultimately successful, it was extraordinarily slow. I timed it at taking 1 hour, 1 minute, 8 seconds to complete. The package was pulling over a wireless N access point with pretty much only me on it at the time, so this worries me for deployment throughout our school district. I noticed throughout some of the install that the jamf binary was stuck at ~97% CPU usage and it seemed to be pulling data from the network for much of the install(curl was quite a busy process too). Should I perhaps have the package cached before I begin installing? I was under the assumption that it would pull the package down and then begin the installation.

Also, is there any way to make sure my products are serialized? I opened them all, and no pop-up asking for anything came up, but I did notice deactivate was greyed out in the Help menu(I did disable updates and such in the built package). We have a K12 site license for 250 machines if that makes any difference. I'm assuming it's all built into the package I built with AAMEE but I'm just being a bit paranoid in the interest of getting it all deployed correctly. :)

Thanks for any input!

Best answer by maxbehr

Over wireless that's not unreasonable. It's a huge package, and it is all copied to the local machine and then installed from there.

As for being serialized, if you don't get a prompt to register or continue a trial, it's safe to assume that the serialization worked.

    8 replies

    mscottblake
    Forum|alt.badge.img+24
    • mscottblake
    • Honored Contributor
    • May 28, 2013

    Give that you are pushing this over wireless, I would expect similar speeds. Your package is likely around 5gb or more and that alone takes time to copy. Then the machine has to perform the installation. Unless you do this over 1g ethernet, I don't see your speeds increasing.

    M
    Forum|alt.badge.img+5
    • maxbehr
    • New Contributor
    • Answer
    • May 28, 2013

    Over wireless that's not unreasonable. It's a huge package, and it is all copied to the local machine and then installed from there.

    As for being serialized, if you don't get a prompt to register or continue a trial, it's safe to assume that the serialization worked.

    M
    Forum|alt.badge.img+7
    • mking529
    • Author
    • Valued Contributor
    • May 28, 2013

    Yeah, wireless isn't ideal for sure, but I'm dealing with laptops that travel all over the place. :) I just tried to copy the package manually from my casper share and it takes ten minutes to copy over, which is fairly acceptable given the size of this software. I'm just curious as to why it keeps pulling network data during the install and "locking up" the way it does. I assumed it would download the whole package then install it.

    J
    Forum|alt.badge.img+7
    • Jpcorzo
    • Contributor
    • May 28, 2013

    Allow me to jump in your post as well. I've had the same problem even when trying to install wired. Adobe CS6 Design standard took over an hour to install while wired and using both methods, direct install and caching then install. Copying manually works great as Mking529 mentioned.

    J
    Forum|alt.badge.img+11
    • Josh_S
    • Contributor
    • May 28, 2013

    The "locking up" effect is actually quite common with packages that rely on a post install script to copy files around. There's basically three major "parts" to an installation. Scripts run prior to copying files. Copying files to a specified location. Scripts run after copying files. If a package only does an initial system check with the prior scripts, copies files, and then does a bit of cleanup after copying files (fixing permissions, serialization, moving files into place, etc.) then the install percentage actually tracks pretty well.

    The problem comes about when a package does the majority of its installation with the pre/post scripts, which Adobe does. The percentage indicator hangs at 97% because the post install script is copying a large amount of data to the system as part of the "clean up" phase. The installer has no idea how long the post install script will actually take to run, but assumes it's about 3% of the installation time. For Adobe, and a few others, it can be much greater than 3% of the installation time so the percentage indicator appears to hang.

    M
    Forum|alt.badge.img+7
    • mking529
    • Author
    • Valued Contributor
    • May 28, 2013

    Sorry, I may not have been clear. When I said jamf binary was stuck at 97% I meant 97% CPU usage. I really have no idea of know where the installer is at because Self Service's front end doesn't tell too terribly much.

    I
    Forum|alt.badge.img+3
    • icemobile
    • New Contributor
    • May 28, 2013

    just wondering, your distribution point is it by any chance SMB?
    deploying cs6 packages from SMB take ages.

    M
    Forum|alt.badge.img+7
    • mking529
    • Author
    • Valued Contributor
    • May 28, 2013

    icemobile you gave me something to think about. My distribution point is an AFP share but it's also enabled for http, which was the way JSS was pulling the package. I decided to try overriding the setting in the policy to use AFP instead. Using AFP the package took somewhere in the neighborhood of 35 to 40 minutes to install. Definitely better! I tried installing the package the old fashioned way on my machine to just see how long it would take that way, and it took about the same amount of time. Guess that's about as good as it's going to get. Thankfully a majority of my deployment for CS6 will be on reimaged machines this summer.

    Thanks for the input everyone!

    Terms & ConditionsCookie settingsAccessibility statement