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?
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.
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.
@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.
That's expected behavior.
Without any app provisioning, they will be able to log in and use the shared device licensing apps that you deployed.
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.
Bit of a plug but:
I delivered the following talk covering CC2019 and 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:
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.
So i created brand new packages with Share device Licensing. Here are my steps
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.
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.
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.
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?
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.
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.
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.