Adobe CC 2019 install using Shared Device Lic

[stephaniemm77]

So I created a brand new package via the Adobe Admin Console using the Share Device Licensing option, I packaged it using Composer and all the apps launch fine but for some reason they are prompting the user to log in to their adobe account. Almost as if the shared licensing didn't pass through. Anyone else having this issue?

[RLR]

Adobe recently changed their licensing method. I believe the last version of Adobe CC to support Device Licenses (not shared device licenses) is 2018. Adobe CC 2019 requires shared device licenses which now makes users sign in:
Once you've migrated to shared device licenses, I don't think you can go back. I've not done this process myself so can't provide much more information (we're still using 2018). I believe there are guides somewhere on how to set logins up.

End-user experience To use an app deployed on a shared device, end users need to sign in with their credentials. When users launch an app on a shared device, they’re prompted to sign in with their credentials. The apps only launch after a successful sign-in. A shared device license does not directly entitle a user to access any services such as storage, libraries, fonts, or stock, among others. However, if the user account has these entitlements these services are available.

https://helpx.adobe.com/uk/enterprise/using/sdl-deployment-guide.html

[bmccune]

We just did this as well in our environment. CC 2018 was the last version with traditonal Device Licenses that did NOT require a login. The new licensing for CC 2019 requires users to login with an Adobe account, even with Shared Device Licenses. If a user does not have one yet, they can create a new one for free.

[jr139]

@bmccune did you guys end up integrating your adobe admin console with AD to generate the accounts for your users? or are you making users create their own accounts? We are going to be forced to make the switch from "Device Licenses" to "Shared Device Licenses" this summer in our K-12 lab environments.

[jchen1225]

That's expected behavior.

• Using Adobe ID, either an existing one or create a new one on the fly.
• Federated ID, you need to add the users to your adobe admin console, you don't need to assign them any products.

Without any app provisioning, they will be able to log in and use the shared device licensing apps that you deployed.

[stephaniemm77]

I believe we are going to use the sync tool to create user accounts and they can login via SSO. This will be a huge switch for workflow for the students...shouldnt cause too much havoc HAHAHAHAHA

[bmccune]

@jr139 We are having our students create their own Adobe accounts, but we are in a College environment where many students taking the classes already have their own Adobe CC accounts that they can use. I'd probably be looking at AD sync in a K-12 environment.

[jcline]

@bmccune this is exactly how we do it, AD sync and that's what creates their adobe id's

[ctarbox]

@jr139. This is the approach we are also taking in our Classroom Environment in Higher Ed,

[blackholemac]

As a K-12 district, we have had to unfortunately go down the road of Shared Device Licensing with Federation and SSO. I'm really not fond of the new approach at all because I don't think I should have to make someone login to use Photoshop, but in theory, we could have any students or staff members want to use the software in these multiple labs. I really wish Adobe would stop doubling down on psycho serialization and activation schemes with their products. As a former graphic artist before I became an Apple guy, I really wish instead they would focus on providing captivating software that gets budding graphic artists interested in the profession while also focusing on keeping the pros going. With the changes they keep making on the licensing and deployment though, we are one day going have to give up and play "evil IT admins" and just say no to installing their software.

[daz_wallace]

Bit of a plug but:

I delivered the following talk covering CC2019 and SDL:
https://dazwallace.wordpress.com/2019/02/20/uou-adobe-sdl/

And if you're going to MacAdmins at PSU conference at the end of July, I'll be delivering a more in-depth version:
https://psumac2019.sched.com/event/398211d6616b34c029ffa8807d6d67ca

[B_Johnston]

My school is about to go through this transition and we have been looking deep into the new shared device licensing model. As others have said on this forum, it will require a login now. There is no avoiding it. Depending on how many users you have, you could just create generic Adobe IDs for them. However, the recommended method going forward is to implement an SSO Federated ID login method with your domain. Here are some helpful links on this.

https://helpx.adobe.com/enterprise/using/sdl-deployment-guide.html

https://helpx.adobe.com/enterprise/using/set-up-identity.html

[Giovanni]

So i created brand new packages with Share device Licensing. Here are my steps

1. Download Photoshop CC 19 with Share Device Licensing,
2. Create package with composer, and make sure The Applications should be root:admin with 755 permission.
3. Upload the Packages to Jamf Admin.
4. Create policy to trigger and install photoshop to a specific target machine. ideally the target is for all Labs but i have a test machine to test the packages.
5. Packages successfully installs on the machine, i am able to open photoshop and use it with a free Adobe account in the Admin account. Here comes the issue, since we have student login with their own student ID, a temp account is create and then when they log off we have a script the delete their temp account. the student ID account is based on AD and when i login with a Domain account i get this error. "We cant verify Subscription"

if i login with the Admin account back i am able to open and use photoshop.
Any Idea. Thank you.

Please let me know if i missing a step.

[DanJ_LRSFC]

One gotcha of SDL licensed packages is you can't install more than one SDL package on the same computer. Well, you can, but then you'll get an error similar to the one pictured above about not being able to verify your subscription. So you can't do it as an "a la carte" style deployment where you create packages for each app and then assign them as needed, you have to create bundle packages with all the apps you need for each area.

On that subject, does anyone know if there's an easy way for me as an administrator to add an app to a machine where I've already installed an SDL package? I really don't want to have to deploy out a whole new 11GB apps bundle.

[georgecm12]

Unrelated to anything having to do with SDL, but you shouldn't need to create a package with Composer.

I just download the package as created by the Admin Console (downloads as a .zip file), expand it (expands out to a .pkg), then upload the expanded .pkg to JSS. Works just fine that way.

[uoscasper]

Has anyone come across the apparently known issue where the SDL doesn't activate the software, and although users can login, all of the apps launch only in a 7-day trial mode?

I've been able to workaround this by assigning a product profile to all imported accounts, but according to Adobe I shouldn't need to.

They are suggesting a full reinstall on all machines to resolve this, but as teaching has now started, this really isn't a viable option for us at the moment.

Has anyone come across a fix to make the shared device work properly, maybe a reactivation tool or something similar?

Thanks.

[allanp81]

@uoscasper When did you create your SDL package? We had to download the SDL package again as Adobe updated something that broke it and produced the exact result you mention.

[uoscasper]

@allanp81 It was July this year. A full removal/reinstall of the entire suite would cause us many problems if that's the only way to resolve it.

[allanp81]

@uoscasper Hmm, check the version if you can. We had re-package ours in July and we ended up with version 1.5 which fixed that exact issue. Luckily we hadn't begun rolling it out but the SDL package is only ~500Mb or so, so not as bad as having to redo the whole suite.

[ega]

As a university we have been dealing with this in some shape or form for the last 3 years. For Adobe CC with 2019 and 2017 versions we have discovered that a package can be created in the Adobe Admin Console which contains ONLY the Shared Device License and Adobe CC app. We make only one set of packages that are named user licenses and we make one package per Application so al a carte installs can be made. What works for us is to run the "Shared Device License Only" installer as priority 15 from Jamf so it always runs AFTER all other Adobe products are installed. For us this converts the named user license to Shared Device License. NOTE that NO MATTER WHAT the end user will have to login to use the product. Period. To help with this login, we got an email today announcing Adobe's support for Google and Azure federated identity. (http://m3-page.info.adobe.com/nl/jsp/m.jsp?c=%405nDILIY7xjSJf9TYevKTU%2BNrIjJwITPQnWxvZ6t3u9U%3D)
Unfortunately there does not yet seem to be support for continuous automated provisioning using the SCIM standard (ie mapping identity groups to product roles). As pointed out earlier there is a difference in the Adobe ID and Adobe Federated ID and these may connect to different resources (storage, products, etc). If you are a Google shop, one interesting feature is noted
"NEW End-User Experience: To facilitate a streamlined login experience for our Google Federation users, Adobe now supports Google SSI support for federated accounts. By selecting the Continue with Google button, users that have Adobe Federated IDs will be routed to their Adobe school accounts. Users that only have Google social accounts will still be routed to their personal accounts (Adobe ID)."
We also ran into case where our client had used their institutional email for personal accounts and adding Federation caused "name space collisions". Be aware of this as there is guidance in the link above under the section marked "IMPORTANT".
I hope this saves some time for someone.

[thebrucecarter]

Another way to reset the licensing is to acquire the Adobe Licensing Toolkit from Adobe, deploy it to /usr/local/bin/, do a:

sudo adobe-licensing-toolkit --deactivate

and then redeploy an empty package from the Adobe Console for SDL, which will just give you the licensing stuff. We had to do this to a couple of broken installations where the licensing information was corrupted.

[uoscasper]

@allanp81 @bcarter5876 @ega Thanks for all that, I will get on with doing that now. I've had a case open with Adobe about this for a week which hasn't provided anywhere near as much help as you all, so thank you!

[bluebox]

Just read this entire thread. Adobe licensing was never really nice, but this SDL model simply sucks, creates more work and problems. It's time to look for alternatives.

[blackholemac]

It was honestly a pain in the can to implement, but once we got it working, it seems to be functional. I'm tired of all the licensing changes though...our techs end up having to check with me every time we do a large Adobe deployment. I'm our Adobe point person in addition to being the Mac guy so my answer can't always be "Go to Self Service" simply because roughly half our Adobe using population are Windows people.