Mac Admin

Migrating macOS Devices from one Jamf Pro instance to another using ReEnroller – Part 2: Process and Troubleshooting

So this is part 2 of my mini series on using ReEnroller. Part 1 can be found here and covers the initial setup. This part will look to cover the process and some basic troubleshooting, as well as some post migration tasks.

Process

So if you followed my guide from last time, you should hopefully have a working migration process. With the configuration I’ve talked through, the process that the ReEnroller will carry out is:

  1. User triggers the ReEnroller package installation workflow
  2. The policy will install the ReEnroller package and “Completes”
    1. Due to this, I’d suggest added a ‘policy completion’ message to the policy to let users know the rest will run in the background
  3. ReEnroller will now launch and start doing its thing:
    1. ReEnroller will now move the current Jamf enrolment pieces to one side
    2. If MDM enrolled, it will now try a local removal of the MDM Profile.
    3. If this fails, it’ll try and call the MDM API removal policy on the source server. This runs an unmanage command – the only way to remove a DEP un-removable MDM Profile
      1. If this fails too, ReEnroller will revert the enrolment back to the source server
    4. ReEnroller will now create a new enrolment invitation on the destination server and enrol to it
      1. If this fails, ReEnroller will revert the enrolment back to the source server. If the MDM Profile was removed, ReEnroller will use the Jamf binary to enrol the MDM side without UAMDM.
    5. ReEnroller will now use the Jamf binary to enrol the MDM side, but without UAMDM
    6. Once reenrolled, the “migration complete” policy will be called to confirm all was successful
      1. Once again, if this fails, ReEnroller will revert the enrolment back to the source server. If the MDM Profile was removed, ReEnroller will use the Jamf binary to enrol the MDM side without UAMDM.
    7. Migration should now be complete, but will not be UAMDM’d
    8. If at any point ReEnroller failed the migration, it’ll repeatedly try again every 30 minutes (unless you change this setting in the ReEnroller application)

Troubleshooting

If you’re seeing issues with the migration, there are a few things you can check:

  • The ReEnroller process actually logs its work in the jamf.log at /var/log/jamf.log. This should be the first place to check for errors
  • You should also check the logs for the policies to check if they did run, and if they had any errors! This should be the “migration complete” policy and (if used) the API MDM removal policy.

What about UAMDM?

As mentioned above, these MDM Profile enrolments are via the Jamf binary and so will result in a non-UAMDM enrolment. I’d suggest documenting the process to accept the MDM profile and sharing this out with your end users. For this same reason, you shouldn’t block the Profiles System Preference Pane on migrated devices.

Jamf has an option to nag users to accept this, but they’ll need the user to launch Self Service, or to allow Self Service notifications (something you can’t force-on until the device is UAMDM’d)!

I heard a rumour…

What about the next macOS, Big Sur? I heard a rumour that it may add further obstacles to command line profile installation, and these would break the ReEnroller workflow above. At this stage, I can only suggest testing with Big Sur and filing feedback with Apple / Jamf / the ReEnroller project.

Outro

That should complete the ReEnroller mini-series! Hopefully it’ll help guide you through the process to a working solution, or a base to make your own tweaks and changes.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard
Mac Admin

Migrating macOS Devices from one Jamf Pro instance to another using ReEnroller – Part 1: Setup

So over the last few weeks I’ve seen a few questions pop up around the usage of the Jamf ReEnroller solution, and using it to migrate macOS devices from one Jamf Pro instance to another. It just so happens I’ve had to do this for a few customers to onboard them into datajar.mobi, so I thought I’d share what I’ve learnt!

I’m planning on a two post mini-series with this part 1 covering some background information as well as suggested setup details. Part 2 will look to cover the process and some troubleshooting tips.

What is ReEnroller?

ReEnroller is a tool created by the folks at Jamf. It produces an installer package that deploys an application and settings to migrate a macOS device from one Jamf Pro system to a second one. Ideal if moving providers or changing the Jamf Management URL.

Using an API script, it can also remove an MDM Profile that is set to be “Unremovable” via a ADE (previously DEP) enrolment.

Limitations

Don’t forget that the system you’re using to migrate is also running the migration, so this can be fragile. Also Apple doesn’t provide a supported way to migrate MDM solutions other than a full wipe and redeploy. It is fairly likely you’ll have a few devices (maybe more) which fail to migrate at all and will need a manual intervention, possibly even including a wipe to bring them back into service.

Also this won’t provide a User Approved MDM (UAMDM) enrolment, so your users will need to manually hit that “Approve” button post-migration. As a result, you’ll want to not block access to the “Profiles” System Preference Pane.

Lastly, in my experience, you need to have the destination Jamf Pro instance running the same or newer Jamf Pro version to minimise the risk of failed migrations.

Oh and depending how things end up, this process might not work on macOS Big Sur. More on this in part 2.

Where do I find more information or documentation?

Jamf have some documentation on the use of ReEnroller on the GitHub README file, but this doesn’t provide detailed implementation instructions. It does mention this line: Be sure to view the help for detailed usage instructions.

To view the implementation instructions, grab a copy of the application from the releases page, launch it and click the “?” next to the “Build” button. This will provide some detailed documentation on usage and implementation of ReEnroller.

Oh and also this blog series might help 😉

Setup work

For this walkthrough, I’ll be using the term “source” to mean the current or old Jamf Pro instance the device is currently enrolled in, and “destination” to mean the new Jamf Pro instance.

So in order to setup the Jamf ReEnroller we’ll need to:

  • Create a Jamf API account in the destination instance (and a second one in the source instance if you need to remove an ‘unremovable’ MDM profile)
  • Add the script to run an API command to remove an ‘unremovable’ MDM profile, if required
  • Create and upload the ReEnroller installer package into the source Jamf Pro instance
  • Create a policy in the source Jamf Pro instance to run the ReEnroller installer package (and possibly a second one for the MDM removal script, if required)
  • Create a policy in the destination Jamf Pro instance to run a one line command to confirm the migration is successful

Lets walk through each step in more detail

Create the Jamf Pro API enrolment account on the destination Jamf Pro instance

So first things first, we need to create an API enrolment account on the destination Jamf Pro instance. This will be used by the App to create an invitation enrolment and perform the enrolment.

  1. Log into your destination Jamf Pro server and create a new account. I’d suggest the username “ReEnrollerAPIEnrolment” to make things simple.
  2. Give it a long and complex password and set the privilege set to “Enrollment Only”.

(Optional) Create the Jamf Pro API MDM removal account on the source Jamf Pro instance

If you’ve enrolled macOS devices into your source server with DEP and a non-removable MDM Profile (option shown below), you’ll need to setup an account on the source Jamf Pro instance in order to remove the profile.

  1. Log into your source Jamf Pro server and create a new account. I’d suggest the username “ReEnrollerAPIMDMRemoval” to make things simple.
  2. Give it a long and complex password, set the privilege set to “Custom” and give it the following permissions only:
  • Jamf Pro Server Objects > Computers > Allow Create and Read
  • Jamf Pro Server Actions > Send Computer Unmanage Command > Allow

(Optional) Add the Jamf Pro API script to remove the MDM profile in the source Jamf Pro instance

Again, if you need to use the API to remove the MDM profile to migrate devices, we’ll need to add a script to the source Jamf Pro instance.

  1. Log into your source Jamf Pro server and create a new script. I’d suggest sticking with the default name of apiMDM_remove.
  2. For the content of the script, use the contents of this file from the GitHub repo. This should ensure that you’re using the most up to date version.
  3. Set the parameter names to the below:
  • Parameter 4 – Username
  • Parameter 5 – Password
  • Parameter 6 – Server

(Optional) Add the Jamf Pro policy to remove the MDM profile in the source Jamf Pro instance

Again-again, if you need to use the API to remove the MDM profile to migrate devices, we’ll need to add a policy to the source Jamf Pro instance.

  1. Log into your source Jamf Pro server and create a new policy. I’d suggest calling it something obvious like “API MDM Removal”.
  2. Set the Execution Frequency to “Ongoing” and the Trigger to “Custom”. In the Custom Event box, enter apiMDM_remove.
  3. Add the API script we added above (default name of apiMDM_remove)
  4. In the Username and Password parameter boxes, enter the details of the API MDM removal account we created above (suggested username of ReEnrollerAPIMDMRemoval)
  5. In the server parameter box, enter the source Jamf Pro instance address
  6. Under the Scope tab, configure “All Computers” as the target
  7. Save the policy

Create the Jamf Pro policy to confirm the migration in the destination Jamf Pro instance

We now need to create a ‘completed’ policy in the destination Jamf Pro server. The ReEnroller workflow will trigger this policy to confirm the migration has been successful.

  1. Log into your destination Jamf Pro server and create a new policy. I’d suggest calling it something obvious like “Migration Confirmation”.
  2. Set the Execution Frequency to “Ongoing” and the Trigger to “Custom”. In the Custom Event box, enter jpsmigrationcheck.
  3. Add the Files and Processes payload
  4. In the Execute Command box, enter the following (all on one line)
    1. touch /Library/Application\ Support/JAMF/ReEnroller/Complete
  5. Under the Scope tab, configure “All Computers” as the target
  6. Save the policy

Create the ReEnroller installer package with the required settings

Now we have some decisions to make. We need to use the ReEnroller Application to generate a package that will do the actual work. Below I’ll cover each option and offer my opinion on what to use. Feel free to experiment as long as you do plenty of testing afterwards!

First things first, download the latest copy of ReEnroller from the GitHub releases. Once obtained, launch the application.

Lets go through each box and option:

  • New Jamf Server URL – Set this to the destination Jamf Pro instance’s URL
  • Username – Set this to the username of the API Enrolment account (suggest name of ReEnrollerAPIEnrolment)
  • Password – Set this to the matching password of this account

  • Management Account – Enter the desired Management Account. If you already have a management account on the device, I’d suggest using those details unless you have a specific need to use something else.
  • Password / Verify Password – Enter the desired Management Account password. Again, if you already have a management account on the device, I’d suggest using those details unless you have a specific need to use something else.
    • Randomly Generate Password – Alternatively, you can use a randomly generated password and specify the number of characters.
      • Note: If you do go for the random password you’ll need to add a “Reset Management Account Password” payload to the migration complete policy in the destination server
  • Create the account if it does not exist – Tick to create the Management Account automatically. I’d suggest having this ticked
  • Hide the account – Hide the Management Account from the GUI. Set this to what you need
  • Configuration Profile – If you’re deploying a Wifi profile via MDM, you’ll need to upload a copy of the profile here. This will ensure the device stays connected to a network during the entire migration process.
    • Remove when done – If using a profile for Wifi, tick this to remove that profile after ReEnroller is done
  • Use for new enrollment – If you tick this, the outputted package will not work for migrations! Do not tick this if you’re using this solution to migrate devices
  • Remove profiles marked in DEP as not to be removed – If these devices are pre macOS 10.13, this will remove the MDM profile (needed if you’re migrating to a new server). If the device has a DEP non-removable MDM profile, it’ll use the policy we created above (recommended name “API MDM Removal”) to unenrol and remove the profile. I’d suggest ticking this.
  • Use existing site membership – Tick if you’re using Sites in Jamf and want the devices to try and enrol into the same Site on the destination instance
  • Enroll in site [XXXX] – Use this to instead specify a Site you want these device to enrol into
  • Skip MDM Verification – If you aren’t using APNs on the destination (for some reason?) you can skip this test. I’d suggest leaving this unticked
  • Create ‘Migration Complete’ policy on the new Jamf Server – You can leave this unticked as we’ve done this ourselves. This means we can use an enrolment only account with ReEnroller – much better security!
  • Run policy after verifying migration. Policy ID [XX] – If you have a specific policy you need to run on the destination server after migration, enter the policy ID number here. This could be a progress screen or some initial setup items you need on all Macs.
  • Call Automated Device Enrolment – When enabled, this can trigger an ADE / DEP prompt enrolment to the user. It’ll still require the user to perform a number of tasks so I prefer to not use this
  • Remove ReEnroller folder after migration – When ticked, it’ll clean up any leftovers! Handy to have unticked for testing but I’d strongly suggest ticking this option to make sure nothing sensitive is left behind.

  • Maximum number of retries [XX] – ReEnroller will retry automatically if it finds any issues (more on this in part 2). I’d suggest leaving this blank to have ReEnroller keep retrying until its successful.
  • Retry interval – ReEnroller will retry after 30 minutes by default. This is a pretty good default setting I’d suggest leaving as-is, but feel free to change if you need to.
  • Create Separate Packages – If ticked, this will create a separate package for the Launch Daemon and the migration tools. I’d personally not bother!
  1. Your ReEnroller application should look something like the above.
  2. Click the Build button to produce your ReEnroller package.
  3. Upload this to your source Jamf Pro Server

Create the Jamf Pro policy to run the ReEnroller installer package in the source Jamf Pro instance

Almost there! We now need to create a policy on the source Jamf Pro instance to run the ReEnroller package. This will be a fair bit of personal choice but generally speaking I’d suggest:

  • Obviously add the ReEnroller Package to the policy!
  • Set the frequency to “Ongoing”, the scope to “All Computers” (after testing) and put it in Self Service only
  • Give it a nice logo and a good description
  • Consider informing the user of the whole process in the description and require that they view it before running the policy
  • As a last ditch, you can switch it to a “recurring check in” trigger to get those last few devices over the line.

Test!

And lastly, test. Test, test, test and test some more. Then test again for good luck. the process can be fragile in the best of cases but you can at least test it enough to be confident of the best possible outcome.

Outro

Phew that was a long one. In part 2 I’ll look to cover the process, and any troubleshooting advise I can provide.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard
Mac Admin

Uninstalling Adobe Software

Indeed it’s another Adobe post! How to remove Adobe software is a question that often comes up in the #adobe channel and, as with most things, there’s a number of ways to achieve this.

Nuke and Pave

The simplest method, but the one with the most collateral damage. Simple erase and reinstall the macOS onto the device to remove the Adobe software.

This can be done through the GUI, the command line, or external installation media. I’m planning to cover these options in a little more detail soon over on the dataJAR blog.

Uninstaller Package

If you’ve ever created an Adobe deployment package within the Creative Cloud Packager (CCP) or the admin console (https://adminconsole.adobe.com/) your finished project will contain two packages:

  • An installation Package, and
  • An uninstallation Package

You can upload this uninstaller package into your Mac software deployment tool of choice (Munki has an ‘uninstallpkg‘ flag to pass when uploading both packages) and “install” this to remove the corresponding software. Now it’s not as precise and will remove any matches for the major version (e.g. any “Animate 2020” uninstaller will remove any version of “Animate 2020” but won’t remove “Animate CC 2019”).

More information: Adobe | Uninstall Creative Cloud products

Uninstall “All the Things” Package

If you still have access to the older Creative Cloud Packager (CCP), it’s possible to generate an “uninstall all the things” package. I’ve detailed this in a previous post here – Using Adobe Creative Cloud Packager to create an uninstaller in preparation for Adobe Creative Cloud 2019 Shared Device License deployment.

Note: CCP wasn’t designed to be used on macOS Catalina (10.15) or newer and has had some reliance on 32-bit processes. This will probably also be the case for the uninstaller packages it generates. This may limit the usefulness to you.

More information: Adobe | Uninstall Creative Cloud products (different to the above article!)

Command Line

Lastly, there is indeed the command line option. All “Hyper Drive” Adobe installers (which is almost all, if not all of them for the last few years) will also deploy the means to run a command line uninstall of the software.

The syntax for this on Mac is as follows (that’s all on one line):

"/Library/Application Support/Adobe/Adobe Desktop Common/HDBox/Setup" --uninstall=1 --sapCode=PHSP --baseVersion=17.0 --platform=osx10-64 --deleteUserPreferences=true

This is broken down into the below:

  • "/Library/Application Support/Adobe/Adobe Desktop Common/HDBox/Setup"
    • Path to the command, note the quotes due to the spaces
  • --uninstall=1
    • Provide the number 1 to the uninstall flag to specify this is to uninstall
  • --sapCode=PHSP
  • --baseVersion=17.0
    • The base, or major version, of the application you wish to target. These will never match the PR version (e.g. CC 2019) so again Adobe has a (mostly) up to date reference table here – Adobe | Applications that can be deployed without their base versions. If you’re looking for older versions of Application base versions, check out the “Previous versions” disclosure arrow further down that page.
  • --platform=osx10-64
    • This differentiates between macOS and Windows. To be honest, as you’re running this on a Mac, I’m not sure why you need to specify the platform, but best to just use this as is!
  • --deleteUserPreferences=true
    • True here will also try to remove the user’s preferences. I’d suggest setting this to ‘false‘ unless you have a specific reason to remove those settings
  • --removeAll=All
    • (Not shown above) This will uninstall all installed Adobe suite applications
  • --eulaAccepted=1
    • (Not shown above) This is an undocumented feature (thanks Foigus!) to automatically accept the EULA when removing all installed software

As you can imagine, this command will need to be ran as root, however your software deployment / script running solution can achieve this. This will also probably need some trial and error to properly get right so ensure to always test!

More information: Adobe | Deploy packages

Note: This section has been removed from the non-localised version of the page above (link here) and may be deprecated. I’m awaiting clarification on this.

Creative Cloud Cleaner Tool

Adobe provide a cleaner tool that can remove installations back to CS3. It has both a GUI application and a command line binary, but the binary will require you to create your own XML file to feed into it.

More information: Adobe | Use the Creative Cloud Cleaner Tool to solve installation issues

Outro

That’s it, 5 different(-ish) ways to remove Adobe software should you need to. Thanks to Foigus on the MacAdmin Slack for at least half of these suggestions!

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard
Mac Admin

Deploying Adobe Shared Device License (SDL) Over Older Versions of Creative Cloud

It’s another Adobe Blog! One thing I covered in my recent talk at PSU’s MacAdmins Campfire Sessions (Link: What’s new with Adobe 2020 in Education – Content) was what happens when you deploy Adobe SDL 2020 over the top of older Creative Cloud deployments. I’ve decided to use this post to expand upon this further.

Why would you need to?

Licensing aside, Adobe normally has allowed (and worked ok) with mixes of versions of the same software installed at the same time. I’ve often seen Macs running multiple copies of Photoshop, InDesign or Illustrator from various suite versions together.

The main reasons for this tend to revolve around compatibility:

  • Compatibility with plugins for certain projects
  • Compatibility with files (perhaps other internal colleagues or customers/venders have files saved in older formats)

Whatever the reason, it is indeed possible to deploy SDL packages over the top of older packages and still be able to use them.

Scenario 1: Deploying Adobe Shared Device Licensed 2020 Applications over Shared Device Licensed CC 2019 Applications

This scenario should work fine with no changes to the behaviour on devices. The newer 2020 applications will be deployed as SDL, and with the CC 2019 applications already being SDL, you shouldn’t see any changes.

Scenario 2: Deploying Adobe Shared Device Licensed 2020 Applications over Named User Licensed CC 2018 and/or older Applications

This scenario should also work fine, with no changes to the behaviour on devices. The newer 2020 applications will be deployed as SDL, and as the CC 2018 or older applications don’t understand SDL, they’ll continue to use NULs whilst they are valid.

Note: macOS Catalina requires Adobe CC 2019 or newer to be fully supported so this may rule out your use of this scenario!

Scenario 3: Deploying Adobe Shared Device Licensed 2020 Applications over Serial Number Licensed CC 2018 and/or older Applications

This scenario should also work fine, with no changes to the behaviour on devices. The newer 2020 applications will be deployed as SDL, and as the CC 2018 or older applications don’t understand SDL, they’ll continue to use SNLs, whilst they are valid.

Note: There have been some reports where the SDL deployment somehow removes the SNL. If you hit this, feel free to raise a ticket with Adobe.

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

Scenario 4: Deploying Adobe Shared Device Licensed 2020 Applications over Device Licensed (legacy) CC 2018 and/or older Applications

So this scenario should work fine, however in most cases you’ll be migrating from DL to SDL. 30-days after you click the “Migrate” button, those DLs will deactivate and stop working. To be honest, I don’t see the value in this and I wouldn’t recommend it.

Source: https://helpx.adobe.com/uk/enterprise/using/sdl-faq.html

Outro

Another Adobe post and another Adobe Licensing post! Hopefully this will prove useful to someone 😊

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard
Mac Admin

Moving devices from Adobe Shared Device License to Adobe Named User License

Hey folks, this question came up a while ago in the MacAdmins #adobe Slack channel, and recently reappeared so I thought I’d document it!

In some cases you may need to convert an already deployed Mac away from Adobe’s Shared Device Licensing (SDL) and change it to unlicensed or Named User Licensing (NUL). This is indeed possible but there are a few hoops to jump through.

I know, I just need to deactivate the license!

Well, yes and no.

It is indeed possible to deactivate an SDL using either the portal or the Adobe Licensing Toolkit (Deactivating Adobe Shared Device Licenses). However, as soon as an Adobe ID is used to log into the Adobe Apps, the SDL is re-activated.

“However, as soon as a users sign into Adobes app on each of these machines, the machines are immediately licensed again.” – Source

Ok, what else should I do?

So before you go ahead with the second part, I’d still strongly recommend you deactivate the license either via the Admin Console or using the Adobe Licensing Toolkit. If not, you may be stuck with a ‘used’ SDL in your portal that it won’t be easy to flush out.

So the next step came from an older discussion in the #adobe channel

This directory lives at /Library/Application Support/Adobe/OperatingConfigs

Once you’ve de-activated the license, removing this directory and restart the Mac. This can either be manually, or via a script.

The next time you launch an Adobe App, you’ll be asked to login with an Adobe ID account with a license, or to start an Adobe trial! Removing this directory actually permanently removes the SDL from this Mac.

Outro

Another Adobe post 😉 I hope it makes things a little easier for someone out there!

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard
Mac Admin

Deactivating Adobe Shared Device Licenses

Hey folks, this post documents the two methods to deactivate Adobe Shared Device Licenses (SDL).

Some of you may be lucky enough to have unlimited SDLs to deploy out (I believe it’s those with ETLA agreements), but that does leave others who have to keep track of where they are in use.

How do I find out how many I’ve used?

Log into the Adobe Console at https://adminconsole.adobe.com with one of the your deployment administration accounts. On the main overview page, lookout for an item called “Creative Cloud All Apps for XXXX – Shared Device” (e.g. “Creative Cloud All Apps for K-12 – Shared Device”). This will then show you how many licenses you have, and how many have been deployed and activated. In the example below, we have 350 licenses paid for, and 24 used.

If you’re one of the luck ones with unlimited licenses, you’ll see your used license count on the left, and “1” on the right, as shown below

How do I find out where they’ve been used?

This one has a few more steps, log into the Adobe Console at https://adminconsole.adobe.com with one of the your deployment administration accounts. Navigate to “Products” in the top menubar, then select your SDL in the left hand side. Once here, click on the profile you are using (most folks will just be using one single profile).

Almost there! Once viewing the profile, click the ellipsis (“…”) in the upper right corner, and select “Create Report”. This will create and download a CSV report.

How do I deactivate those licenses from the console?

This method is recommended if the activated devices have been wiped, or no longer bootable. It’s also useful if you’re feeling lazy, but this will deactivate licenses for all devices under that profile.

First navigate to the same area you produced your report above. In the same ellipsis menu, you’ll see an option to “Recover Licenses”. Click this and confirm.

This will deactivate the license for any devices under this profile, which could be all of your devices. There is a possibility that this can cause issues if you have rendering jobs in progress, or users logged in and using the Adobe Apps, so please ensure to minimise this risk. Maybe only run this out of hours?

For devices that are in use, they will automatically re-activate the next time a user logs in with an Adobe ID:

“However, as soon as a users sign into Adobes app on each of these machines, the machines are immediately licensed again.” – Source

How do I deactivate those licenses from the device?

If the device/s in question are still operational, you can deactivate the SDL on the device by using the Adobe Licensing Toolkit. More details on using this tool can be found here, but we’ll summarise the steps below:

  1. Log into the Adobe Console at https://adminconsole.adobe.com with one of the your deployment administration accounts.
  2. Navigate to “Packages” > “Tools” > “Licensing Toolkit” > ” Download for Mac”
  3. Open the downloaded disk image
  4. Put the included “adobe-licensing-toolkit” binary somewhere on the device (or run from the disk image if that option is available on this device)
  5. Run the binary with the flag --deactivate with admin rights

e.g. sudo ./adobe-licensing-toolkit --deactivate

Again, if someone logs in with an Adobe ID on that device after running the deactivate command, the device will automatically reactivate its SDL:

“However, as soon as a users sign into Adobes app on each of these machines, the machines are immediately licensed again.” – Source

I’ll discuss how to permanently remove the SDL from a device in a future post!

Outro

Another Adobe post 😉 I hope it makes things a little easier for someone out there!

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard
Mac Admin

Session Video is now live from MacAdmins Campfire Sessions 2020 (PSU 2020)

Hi folks,

The amazing team at PSU have been working hard releasing session videos within days of them being delivered. You can find the entire playlist on YouTube here.

Once again I delivered another Adobe talk! You can find a direct link to the video here, as well as an updated resources post here.

Again, I’d like to take the time to thank the great crew at PSU who made (and continue to make) a remotely delivered awesome conference a success. Fingers crossed that I’ll be able to make next years one!

And if you’re around for the next two Thursdays from 6PM BST, they’re still going. Details here.

Standard
Mac Admin

What’s new with Adobe 2020 in Education – Content

Hi all,

If I time this right, this post should be going live about halfway through my talk at the PSU Campfire Sessions on Adobe 2020 and Shared Device Licenses in Education. 

This talk is a update of my previous talk Adobe CC2019 in Education – PSU 2019

Video

Slides

whats-new-with-adobe-2020-in-education-v2.0Download

Link Dump

As promised, heres a list of URLs from the presentation, as well as some further reading suggestions:

Thanks again to everyone who could attend!

Standard
London Apple Admins, Mac Admin

MacAdmins at PSU 2020: Campfire Sessions – What’s new with Adobe 2020 in Education

Last year I had the privilege of speaking at MacAdmins at PSU around Adobe 2019 and it’s use in education. You can find more on that here.

This year, I’m lucky enough to have another session, which I’ll be using to present on Adobe again, including some changes from 2019 to 2020.

MacAdmins Campfire Sessions?

With the current pandemic still affect most of the world, this year the folks at PSU elected to switch out the usual on-site deliver of the conference, in favour of a 2-session per week, remote delivery, over 9 weeks.

These are completely free and run 6PM to 8PM BST (local time for me). Ideal if you’re stuck at home after work! Once you’re signed up and registered for each session, you’ll be emailed joining links the day before each session. You can also join everyone on Slack in the #psumac channel.

As mentioned, sign up is free and can be done here.

What’s new with Adobe 2020 in Education

As if my Adobe drum has been sitting ideal too long, I’ll be delivering an updated and refined version of the talk I gave last year, including any new things with 2020 from CC2019.

Over a year has passed since Adobe announced the new Shared Device Licenses. What’s changed? What hasn’t? How many bottles of [beverage] will you need to get you through it?
In this session we’ll look to cover the changes since that first release of CC 2019, SDL and now 2020. We’ll revisit the various deployment workflows and suggestions for taming this beast. Based on experiences from the front line and real world examples.

My talk will be on Thursday 16th July at 6:00PM BST (UK) time, and you can register for it here.

Resources and Recording

The session is being recorded and I’ll add links to that and resources as soon as they’re available.

I hope to see you there!

Standard