SI's blog about technology
If iTunes 12.8 on macOS High Sierra isn't seeing iOS devices, you may get a prompt to install software to see the iOS device, and then the installation may seem to take a while. For example, you may see this for a long time (over 20 minutes):
And even this might stay for a few minutes:
Once that's installed, it should work. If you don't see that prompt on one machine but do see it on another, you can grab the installer from /Library/Updates/041-14491 and install that manually.
If you enabled the guest account on macOS, you probably want to have Display login window as be List of users (instead of Name and password).
That way, the guest sees the guest account is available and clicks on it, and then it logs into the guest account.
If, however, you do have Name and password, your guest will have to type guest in as the username. I thought you had to leave the password blank. Someone else in our office thought you had to type guest as the password. Turns out you can type anything you want in the password field, and it will let you in as guest, as long as the guest account is enabled and as long as you type in guest as the username.
That said, we have experienced the guest account not working at all on some machines (running 10.13.6) with the login window as Name and password. It doesn't seem to be consistent. Sometimes toggling guest off and back on will fix it. Other times, no. So, your mileage may vary.
If you are on iOS 12.0.1 and getting a you've reached this page because we have detected that cookies are disabled in your browser error message every time you try to add a Google account to Mail—and you're certain that cookies in Safari are indeed not blocked—update iOS (to 12.1, as of this writing), and that message will go away, and you can go ahead and add Google accounts.
If you go to Admin Panel > Emails > Settings > Incoming Emails, right now (as of release 1.10.4—the latest stable release as of this writing), you'll see something called Fetch on auto-cron, which isn't super useful, because it will fetch emails only if an agent is logged into osTicket.
There is an external scheduler option. Unfortunately (again, as of 1.10.4), that Using External Task Scheduler link is broken. I believe it's supposed to go to RECURRING TASKS SCHEDULER (CRON JOB).
There, you see on a *nix system, you're supposed to put in a cron job of
I even tried changing the user to root instead of nobody (but if you create a cron job using
It didn't work until I substituted in this line instead:
I had to leave out the user altogether. Also, again according to the Ubuntu community docs, you should be able to put an */# in front of the four asterisks to run it every # minutes, but I found the command executed properly if I just put a single number in there.
Any cron job experts out there who can explain this, I'd love to learn more of the nuances of how this all works (or doesn't work)?
Erik Gomez did a presentation in 2017 on his InstallApplications project:
Macbrained SF Pinterest April 2017
Now that Apple's deprecating monolithic imaging, a lot of workflows have gone to DEP=>MDM=>something else (like Munki).
After doing some testing with InstallApplications, I think we're probably going to stick with our custom script workflow, but I didn't want our tinkering with it to be in vain, so hopefully some of these notes should help another school, org, or company that wants to get its feet wet with InstallApplications and may actually find it better suited for their situation than for ours.
This isn't a comprehensive guide on how to set up InstallApplications—just some implementation notes that may help people on a few of the things we got hung up on when trying it. For more comprehensive details on InstallApplications, check out the README for it and also this blog post: CUSTOM DEP - PART 9: A PRACTICAL EXAMPLE OF INSTALLAPPLICATIONS, CRYPT, DEPNOTIFY AND MUNKI.
You will need a signing certificate for InstallApplications.
The kind you want, though, can't be obtained by an admin. It has to be created by the Team Agent.
When you add a certificate, make sure you select macOS from the drop-down menu, and then select Developer ID.
Then select Developer ID Installer
Once you go through the steps of setting up the certificate, you should have a certificate on your Mac to import into your Keychain. Import it into your login (not system) keychain.
Then, make a note of this part: Developer ID Installer: YOURDEVELOPERDESCRIPTION (AWHOLEBUNCHOFSTUFF). You'll use that later in the build-info.json file.
When you download the project from GitHub (or git clone it), you'll see a bunch of files and folders.
For the simplest set up, the only things you'll modify are build-info.json and com.erikng.installapplications.plist.
The generatejson.py file you'll use to generate a .json to put on a server somewhere (or build into your package).
When you run munkipkg on the InstallApplications project folder, you'll get a .pkg in the build folder, which you can upload to your MDM.
Special note to other Mosyle users out there—don't be silly like me and forget to check the checkbox after you upload your InstallApplications .pkg file.
Hat tip to jacobfgrant on the Mac Admins Slack for telling me the minimal files to modify.
One teacher had an issue in MathType that involved saved formulas in a Word doc shrinking after editing and saving them again (even if the edit involved no actual changes).
The weird thing is that we tried with another user on the same machine with the same document and couldn't replicate the behavior, so it seemed to be tied to the user profile, but then later, with a fresh user profile, the issue still seemed to persist. So maybe that was a weird anomaly (it not shrinking)?
I did a bit more digging and Googling and came across this answer from WIRIS:
"[F]ine if merely viewed or printed" means, as far as I can tell, if you have already existing formulas that haven't been edited.This is an issue with Retina displays, so that's one possible workaround: if you have a non-Retina display, use that when inserting or editing equations. The equations will be fine if merely viewed or printed when using a Retina display, but when you insert or edit one is when the sizing issue happens.
As Charles suggested in an earlier reply, "Consider reverting to Version 16.15." This is, in fact, Microsoft's recommendation as well. The answer on an earlier question in the Microsoft Community answers forum describes how to do that.
We tried reverting to 16.15, and that seemed to fix the issue.
For Munki users trying to downgrade Word to address this particular MathType issue, this is what worked for us:
Example of the preinstall_script:
This downgrade procedure is modeled after the general approach to downgrading via Munki, outlined on the wiki.
P.S. The shrinking MathType formula problem persists in Word 16.17 (Word 2019).
In the past, I'd used the fake installer approach to stop users from upgrading to the newest macOS version.
But with macOS 10.14 (Mojave), I started blocking using Santa (see Using Santa to block an .app for more details on general Santa use). It's likely this Santa-blocking approach also works for High Sierra and Sierra as well—I just haven't tested it on those.
Just download Mojave to your Mac, and then run
Then run a modified version of this command (substituting in the actual SHA-256 hash for the placeholder) to add it to the Santa blacklist:
We were able to test this on two Mojave installers downloaded using two separate Apple IDs, so the binary seems to be the same regardless of which Apple ID is used to download it.
If a user then tries to run the Mojave installer, she or he will see a message like this:
Again, since it's based on the binary (and since you don't want to block by Apple certificate—which you may not be able to do anyway with Santa?—so you have to block by binary), you would have to create a new rule for every new macOS installer that comes out (10.14, 10.14.1, 10.14.2, 10.14.3... 10.15, 10.15.1... 10.16... and so on).
Thanks to @elios (on Mac Admins Slack) for pointing out that this probably would not block the startosinstall binary from running. I was able to test and verify blocking the .app binary does not, in fact, block the startosinstall binary from running.
Also, by default, Santa will get the binary for InstallAssistant_springboard. If you want to be super aggressive, you might also want to block the InstallAssistant and InstallAssistant_plain binaries. Otherwise, the user can still run those two to get the GUI assistant to launch up.
So you really have to ask yourself how aggressively you want to block Mojave. Are you preventing users from just accidentally upgrading? Or do you want to prevent from upgrading even the most determined users who have admin privileges?
If you want to block startosinstall as well, you can do that. Just find (and subsequently block) the SHA-256 hash it:
If you block startosinstall, then try to install the upgrade with Munki, you'll see it mount the .dmg, then stop. The log entries will look something like this:
In Licensing GSP Deployments by Terminal Command , I covered the officially sanctioned way to license GSP5 for Macs.
I believe that was still working even as of 10.13.5. It certainly was working in 10.12.
Unfortunately, with 10.13.6—unless you had an already activated GSP when you upgraded to 10.13.6 from 10.13.5 or earlier—you might get error messages like
in the GUI, even if you're using an admin account.
So I opened a ticket with McGraw Hill, and they said:
Lo and behold, that was the the old non-sanctioned, unofficial way I used to license GSP5 on Macs.The license for all users is stored in the "/Library/Application Support/The Geometer's Sketchpad/" so it must be a permissions issue with that folder, either creating it for a new install, or accessing it when deregistering an old install.
If you copy the "The Geometer's Sketchpad" folder for a non-admin user install (which would be found in "~/Application Support/The Geometer's Sketchpad", to the global /Library/Application Support/ folder, that should also work, provided that the folder permissions allow read/write.
Tested it out on 10.13.6. Works!
So, yeah, use the old way until McGraw Hill figures out what's going on.
No real tutorial here, just a link to a great resource on this via Stack Overflow:
Cutting the videos based on start and end time using ffmpeg
Cutting with ffmpeg takes a lot less longer than rendering out via iMovie, and it results in a similarly sized output file instead of a giant one
P.S. My boss just showed me how you can do this in Quicktime with Edit > Trim. Much easier!
If you notice you can't install new macOS updates on a Mac, it could be that it's still in the process of FileVault encrypting.
For example, here's a machine that's on macOS 10.13.4.
softwareupdate can't find any updates.
And even if you try to manually install the 10.13.6 combo update, you get macOS High Sierra 10.13.6 Update can't be installed on this disk. This volume does not meet the requirements for this update.
And, yup—lo and behold! The FileVault encryption is still in progress. Once that's done, the 10.13.6 update should install just fine.