USB-C Multi-port adapter constantly prompts to install drivers

If you've run into the issue of the multi-port adapter constantly prompting to install drivers even after you've already installed the drivers (particularly annoying, since it requires a reboot), apparently the solution is to plug the power cable in through the multi-port adapter (instead of through a separate port). Worked for me that way.

Hat tip to Zak Nilsson on the MacAdmins Slack for making me aware of this fix.

Can’t change Safari homepage in Sierra, even with no profiles managing homepage

So I came across something weird that's affected only my 10.12.4 clients (none of my 10.11.6 clients seem to be affected by this). Even though I have only one Safari profile enabled, which is set-once and doesn't manage the homepage, my 10.12.4 clients are unable to change the homepage in Safari manually. Whatever the homepage was is stuck like that. If you enter a new homepage in the Safari preferences, it will just not take and revert back to the old homepage once you hit Enter or click out of the address entry field.

The only workaround I've found for this is to delete all profiles (again, even though I don't have any profiles managing the Safari homepage):

sudo profiles -D
Are you sure you want to delete all configuration profiles? [y/n]:y
reboot the computer, and then reinstall (via Munki) all the previously installed profiles (yes, including the set-once profile for Safari that was installed before)... and then I'm able to change the homepage on the client manually. Very bizarre.

Also, after testing on a couple of other clients, there do seem to be situations in which the Safari profile was never set at all, and you still can't modify the homepage, even after deleting any other profiles and rebooting, and it's not account-specific either (freshly created account experiences it, too). It's a real head-scratcher.

Automating an AutoPkg Munki import when vendors don’t package installers properly

You may have, when using (or creating) a .munki AutoPkg recipe, come across a situation in which you run it:

autopkg run -v NAMEOFITEM.munki
and then get something back like this:
Item NAMEOFITEM already exists in the munki repo as OLDNAMEOFITEM.
even though you're sure the item is newer than the one in the Munki repo.

That has to do with the find_matching_item_in_repo() function the MunkiImporter processor uses to determine whether the item exists already or not.

It compares a number of things between the to-be-imported item and what's already in the Munki repo—installer item hash, installs, receipts, files and paths, etc. If any of those matches up, MunkiImporter considers it a match.

So, for example, if you have BADLYPACKAGEDBYVENDOR 3.7.3, which is an update for BADLYPACKAGEDBYVENDOR 3.7.2, but the receipts for both are just 1 (yes, 1 and not 3.7.2 or 3.7.3), the MunkiImporter processor will see the two as the same and not do "another" import of the same item. Likewise, if the version in the app bundle is 3.7 and not 3.7.2 or 3.7.3, the MunkiImporter processor will see them as the same. I've even run into situations in which a vendor artificially ups the number but the "new" package or .app bundle is exactly the same. In that case, the installer hash will be the same, and the MunkiImporter processor will see them as the same.

So what do you, apart from complain to the vendor and pray it fixes the problem?

There may not be anything you can do apart from force an import. You may find a convoluted workaround, though. For LockDown Browser, I had to create an installs array based on the executable and also essentially override the useless receipts array. You might have to do something similar, depending on how bad the vendor package is.

When an AutoPkg recipe fails to import a .dmg

If you ever have an AutoPkg recipe that seems to be working fine for weeks or even months and then suddenly fails with a message like this one:

Error in local.munki.FileZilla: Processor: MunkiImporter: Error: creating pkginfo for
/Users/USERNAME/Library/AutoPkg/Cache/local.munki.FileZilla/FileZilla.dmg failed: Could not mount
(doesn't have to be FileZilla—could be anything), you may not see the .dmg is mounted in Disk Utility (or even diskutil list), but you can check to see if it's a phantom mount by seeing if it shows up in the output of
hdiutil info
If it does show up there, then run
hdiutil detach /dev/diskFILLINLOCATION
and then re-run the recipe. Should be fine after that.

Acknowledgements: Thanks to Eric Holtam for the tip—just documenting it here for anyone else who may benefit from it.

Apple TV “the code is incorrect” error… when the code is correct!

We ran into a weird scenario where a user could not connect to Apple TV with a passcode. We tried all the usual troubleshooting stuff:

  • Does it work with another computer? Yes, it does.
  • Does it work with another user on the same computer? No, it doesn't.
  • Toggle Bluetooth? Makes no difference.
  • Reboot the AppleTV and the computer. No difference.
  • Double-check the key mapping is fine on the Mac itself. It is.
  • Try to connect to a different Apple TV. Same problem.
  • Is the time correct? Seems to be.
Ah, but that ended up being the problem (kudos to my colleague, Jerold, for finding this)—even though the time and date were technically "correct," we had to turn on location services and then set the time zone to be detected automatically in order for the Mac to connect to the Apple TV.

That's weird. It's weird because the time and date were definitely correct, and it's weird because other Macs do not have the time zone set to be detected automatically and are still able to connect to Apple TVs on campus.

But if you run into this issue where you're prompted for a passcode to connect to an Apple TV, and it keeps giving you the code is incorrect when you're absolutely sure you've typed the correct code, consider setting the time zone for automatic detection.

Google Drive “low space, can’t sync” in selective sync

I recently ran into a weird situation in which the Google Drive desktop app was complaining about there not being enough space to add a folder to my selective sync options. It made no sense. I had at least 100 GB of free space on my drive, and I wanted to additionally sync only another 3 MB in one subfolder.

How could an additional 3 MB take up more than 100 GB of space?

Well, it turns out there's a bug in Google Drive. The first time you do a selective sync, the trash storage isn't taken into account when Google Drive compares it to the free space on your local drive. But in subsequent changes to your selective sync, the trash storage is taken into account, so if you have a lot in your trash, you can't modify your selective sync.

I've reported the bug to Google. In the meantime, if you run into this issue, empty your Google Drive trash (through the web browser, not the app), and then wait about 24 hours. You should then be able to modify the selective sync again.

When shared files show up blank

Can't say this will be the fix every time, but if you use Google Drive to share with others and the shared notes show up blank, it's likely that you didn't save the notes before sharing.

People can get used to Google Docs autosaving documents as you type (almost in real time) and forget that not all online apps do that. Manually save before sharing your

Can’t paste from Google Docs to Microsoft Word on Mac

Obviously not the one solution for any time this happens, but I've come across this only once (just now), and this is what worked.

The problem was the user was copying from a Google Doc and then trying to paste into a Word doc. Nothing pasted, even though the Edit menu item flashed blue as if it was trying to paste.

I thought at first that maybe it just couldn't paste outside of Google Docs itself (has been known to happen), but the text pasted just fine into a TextEdit file.

And Word itself could copy and paste text to itself (if you typed something in the Word doc and then pasted into the Word doc, it pasted just fine).

Through just trial and error, I eventually stumbled upon the solution, which was to go (in Word) to Edit, select Paste Special, and then select Unformatted Text. The paste went through just fine.

Fix Evernote sticky notes for Windows remembering a ton of empty windows

We have a Windows user who uses Evernote Sticky Notes, and a whole bunch of blank notes would appear (at least 20 of them) every time the application was launched (at login), and they would have to be manually closed.

I thought renaming the Evernote folders in C:\Users\username\AppData would fix it, but that did nothing.

Turns out the remembered notes are in the registry. So I copied the contents of the notes temporarily to Notepad, ran regedit.exe and then deleted HKEY_CURRENT_USER\Software\EDO-Soft\Sticky Notes.

Relaunched Evernote Sticky Notes, created new notes for the legitimate (not blank) notes I'd previously copied to Notepad, and that fixed it. Quitting out of Evernote Sticky Notes and relaunching it brought back only the new notes and not the numerous blank ones.

Getting Wabbit Emu to work on a Mac retina display


Huge shoutout to @damienbarrett on the Mac Admins Slack Team for the fix. I'm just documenting it here, in case anyone else runs into this problem and is searching for the solution.


You launch up Wabbit Emu and try to run your TI-## calculator ROM, and the onscreen buttons don't match up with what's actually happening on the emulated screen. For example, you might click the Clear button and see the number 1 appear instead.


First, quit out of Wabbit Emu completely (Cmd-Q).

wabbitemu01 Right-click on and select Get Info.

wabbitemu02 Scroll down a bit until you see four checkbox options. Check (or tick) the Open in Low Resolution box, and then close that window.

Now when you open up WabbitEmu, the appropriate onscreen buttons should work.

Scripting it

If you want to script this change, check out pudquick's Python script to set LSHighResolutionModeIsMagnified. You may have to modify it, of course, since it uses TextEdit as an example app:

lowres_app_path = u'/Applications/'
lowres_app_id = u'org.revsoft.WabbitEmu'
Then you can drop it in as a login script (via Outset, for example).

Just keep in mind that after the script runs, the user will have to log out and log back in again for the change to take effect.