Category: Adobe

Determining Adobe Creative Cloud sign-in status on a Mac

brunerd

Adobe Creative Cloud app can get in weird state that blocks users from seeing their apps.

The official solution from Adobe is to delete the file /Library/Application Support/Adobe/OOBE/Configs/ServiceConfig.xml and “restart” Adobe CC, however in the real world you need to sign out and sign back in for the fix to take effect. The folks in the Adobe forums also found that you can change the value of the AppsPanel key from false to true and that does the trick too. Either way it still requires the user to sign-out of Adobe CC and back in.

Now, if you are a MacAdmin with a script that either deletes or modifies ServiceConfig.xml, you will ideally tell the user to Sign Out of Creative Cloud for the fix to take effect. Wouldn’t it be nice to be able to check they’ve done so and prompt them appropriately (or not)? For sure, right!?

There’s a per-user file with ideal behavior, that gets created upon sign-in and removed upon sign out: ~/Library/Application Support/Adobe/Creative Cloud\ Libraries/LIBS/librarylookupfile While its presence shouldn’t be taken as absolute proof that the sign-In is valid, it can be helpful when you need to alert the user what their next steps are. Here’s a simple example that just echoes out the status:

#!/bin/bash
#consoleHasAdobeCCSignIn - Copyright (c) 2022 Joel Bruner - MIT License

function consoleHasAdobeCCSignIn()(
	consoleUser=$(stat -f %Su /dev/console)

	#if root grab the last console user
	if [ "${consoleUser}" = "root" ]; then
		consoleUser=$(/usr/bin/last -1 -t console | awk '{print $1}')
	fi
	
	sudo -u ${consoleUser} sh -c 'ls ~/Library/Application\ Support/Adobe/Creative\ Cloud\ Libraries/LIBS/librarylookupfile &>/dev/null'
	return $?
)


if consoleHasAdobeCCSignIn; then
	result="Signed In"
else
	result="Signed Out"
fi

echo "Adobe CC status ($(stat -f %Su /dev/console)): $result"
Example output

In a fully fleshed out script you could use my shell function shui to pop-up a sharp looking AppleScript alert to your user if they need to sign out or just sign in. You can even use the icon in your pop-up.

You could also use the consoleHasAdobeCCSignIn function in a Jamf Extension Attribute for tracking which Macs have actually signed into Adobe CC and possibly reclaim unused licenses. I’ll leave the uses and script cobbling to you the reader, as an exercise. Thanks for reading!

Adobe CS 5.5 InDesign 7.5.1 Update: we fixed our bug and broke every plugin you use

brunerd

Seriously Adobe? You release CS 5.5 May 2011 and InDesign CS5 plugins seem to load just fine, but then just last week, you release an update to InDesign, and under Resolved Issues you list: “CS5 plug-ins can be loaded in CS5.5, leading to code conflicts and instability  [2867833]”, translated: “Every plugin you thought worked in CS 5.5, doesn’t really, so we aren’t allowing them to load anymore.”

Boo.
You suck.

Make Acrobat Pro 9 for Mac shut the hell up!

brunerd 6 Comments

So, if you deploy Acrobat Pro to a corporate environment you already know what an aggravating experience it is to try and deploy updates to Adobe products. Silent install? Sure. Silent Update? No. Standard Mac .pkg? No.

So you figure out all the files with loggen, Tracker, fseventer, or whatever your tool, then build your own package with Iceberg. Great. Then you find your “standard” users without admin privileges are getting bothered by Adobe’s SelfHeal BS.

Few things going on here that I’ll try and explain, the code formatting should be copy paste-able check it in a text editor, but all line breaks should be preserved.

Make sure you copy in the new Acrobat Internet-Plugin if the user is using that:
if [ -d "/Library/Internet Plug-Ins/AdobePDFViewer.plugin" ]; then
rm -rf "/Library/Internet Plug-Ins/AdobePDFViewer.plugin";
cp -R "/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SelfHealFiles/Library/Internet Plug-Ins/AdobePDFViewer.plugin" "/Library/Internet Plug-Ins/";
fi

These next keys really make it complain if it can’t find them, and yes even if you don’t use the plugin it looks for WebBrowserUsePath, so make sure it’s there, and NoViewerSelfHealNeeded gets a new date put after it for every release! Wow neato, a fun easter egg hunt, thanks Adobe!
defaults write /Library/Preferences/com.adobe.acrobat.90.sh "NoViewerSelfHealNeeded Dec 21 2009" -bool TRUE
defaults write /Library/Preferences/com.adobe.acrobat.pdfviewer WebBrowserUsePath -string "file://localhost/Applications/Adobe%20Acrobat%209%20Pro/Adobe%20Acrobat%20Pro.app/"
defaults write /Library/Preferences/com.adobe.acrobat.pdfviewer AdobePDFDriver -string "file://localhost/Applications/Adobe%20Acrobat%209%20Pro/Adobe%20Acrobat%20Pro.app/"

Now is the truly ridiculous part: if those files and keys aren’t found Acrobat ask for an administrator password and then proceed to write them in current users ~/Library/Preferences! What your users don’t know is they can click Cancel a couple times and it will still write them out, but your they’ve already called you to remote in and authenticate them – you lose! Why Adobe?! WHY!?! Asking for an admin password when you’ll just write it to ~/Library/Preferences?

PDF Printer – Here’s the files you need:
/Library/Printers/PPDs/Contents/Resources/en.lproj/ADPDF9.PPD
/Library/Printers/PPD Plugins/AdobePDFPDE900.plugin
/usr/libexec/cups/backend/pdf900
They are all found in:/Applications/Adobe Acrobat 9 Pro/Adobe Acrobat Pro.app/Contents/MacOS/SelfHealFiles/AdobePDFPrinter/

After you’ve copied them to their places, you can run Adobe install script:
/Applications/Adobe\ Acrobat\ 9\ Pro/Adobe\ Acrobat\ Pro.app/Contents/MacOS/SelfHealFiles/AdobePDFPrinter/cupshup.pl

I also figured this out in lpadmin too:
lpadmin -p AdobePDF9 -E -P /Library/Printers/PPDs/Contents/Resources/en.lproj/ADPDF9.PPD -v pdf900://distiller/ -D "Adobe PDF 9.0"

Even if you’ve copied in the PPD, the PDE plugin, the cups backend, and setup the printer, it’ll still think its damaged because you don’t have the PPD in Korean, Japanese, and two type of Chinese! So, must use PlistBuddy to correct this (because defaults is tricky to use when a dictionary is nested in an array – WHY Adobe?!)

Quiet the printer “repair”:
/usr/libexec/PlistBuddy -c "set :0:IsInstalledKey NO" /Library/Application\ Support/Adobe/Acrobat/SHExpectedMissingFileTypes.plist
For Tiger users the path is: /Library/Receipts/iTunesX.pkg/Contents/Resources/PlistBuddy

It’s almost shut the hell up, but the Adobe Updater might decide to pop-up and urge your user to call you up to run updates, so shut it up you got to jump through some hoops, its an “XML” file Adobe style so defaults won’t work on it, nor will plistbuddy, that and it’s a per user setting, so they must run it once to make the file, then you can change it:
cat ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.dat | sed 's/1\<\/AutoCheck\>/0\<\/AutoCheck\>/' > ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.new; mv ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.new ~/Library/Application\ Support/Adobe/Updater6/AdobeUpdaterPrefs.dat

Yes, Adobe has a document for this but it seems only to remove the ability to check for updates within the app?!

Trivia: You might want to copy in the new AcroEFGPro90SelfHeal.xml file, although running “repair” from Acrobat will copy in the new file and for some odd Adobe reason, the self heal inside the app uses Mac line endings but when magically moved to /Library/Application Support/, it has Unix line endings changing the size by 2282 bytes (and also the place of a key as well?). This was a read herring in my research.
cp -f /Applications/Adobe\ Acrobat\ 9\ Pro/Adobe\ Acrobat\ Pro.app/Contents/MacOS/AcroEFGPro90SelfHeal.xml /Library/Application\ Support/Adobe/Acrobat/AcroEFGPro90SelfHeal.xml

Adobe: CS5 had better not use InstallerVISE, iNosso, bindiff, Java, XML, or whatever convoluted processes you are clinging to, just use the dang pkg format that Apple has provided – sheesh. Is this overwrought complex system supporting “make-work” jobs for programmers?

Create a standard .pkg for Acrobat Reader

brunerd

It’s time to patch Acrobat Reader again! And leave it to Adobe to use a patcher app (or Installer Vise, or a downloader, or a some crazy Javascript/XML/AIR based installer) to make things hard for mass deployment to be achieved (and no I don’t think the Deployment Kit for CS4 makes much sense!).

Perhaps soon they’ll have a full version of Reader available for download in a seemingly standard .pkg file, but don’t be fooled! If you admin Macs like I do you might have noticed it uses the iNosso plugin to uncompress it’s payload and it is totally incompatible with ARD’s Install Package. It just fails.

But fear not, I am a big fan of Iceberg and it’s ability to make the painstaking process of installing Adobe apps so much easier. And I want to share the love. So here take this.

I put a small how-to in the zip file with a sparse set of instructions and caveats. Basically you install Acrobat Reader in the normal way, install Iceberg, open the iceberg project, and build. You’ll then have a pkg that ARD can push out.

If you have questions — Google it! ;)
(OK you can leave a comment, but for gawd’s sake not “How do I use this?” — seriously!)