First one is kind of shaky, the second one is definite.  I will update this post and make note of it if my information changes.  Last month I was receiving “the configuration for your iPad could not be downloaded from [my client’s server] NSURLErrorDomain -999.”  I found all kinds of solutions online relating to management suites, but I’m not even going to mention them because they were irrelevant to the solution in my case.  The only difference in my setup between functioning and non-functioning was the devices I was deploying started coming with iOS 11 instead of iOS 10.

This particular setup is just preparing the devices with Configurator 2, no DEP, then going through the iOS initial configuration of which the major steps are joining the wifi network, accepting enrollment, and logging in with the user’s account.  On initial setup of this system around the middle of 2017 I was receiving errors about SCEP enrollment, which was not being used.  That was fixed by enabling all the setup steps instead of trying to customize them.  (Also, see “4/17/18 note,” below.)

The change I made which fixed this problem was editing the enrollment url from:

https://serverfqdn/devicemanagement/api/device/dep_mdm_enroll

to

https://serverfqdn/devicemanagement/api/device/auto_join_ota_service

This month on trying to deploy another device I started receiving a new error, “the configuration for your iPad could not be downloaded from [my client’s server] “Invalid Profile.” To fix this open Configurator 2 -> Preferences -> Servers -> + -> [enter a name like mdm Jan 2018] -> [for “host name or url” use only the fqdn and no path info so it autodiscovers the full path, i.e. https://fqdn/]. This will fetch the most current cert/info via built-in autoconfig.

After receiving the “Invalid Profile” message I needed to manually erase the device to begin again, but after erasing and re-preparing it the steps went back to working perfectly.

1/25/18 note: My employee was testing this, it failed even with a newly autodiscovered server entry.  However prior to use instead of being brand new (in my case) he used Configurator 2 to erase it.  Using the built-in “Erase All Content and Settings” did allow the process to proceed.  Next new iPad I get I’ll try erasing it prior to preparing it using Configurator 2 and leaving the existing server entry in place.  If that works I’ll update this post.

4/17/18 note: SCEP errors can also occur if port 80 is not open to the profile manager server.

If I’ve made an error or helped you out, I’d love to hear about it. Please email me at mdm@ this domain name (without the www.) Thanks!

[Disclaimer: there are some very powerful commands mentioned casually here.  BE CAREFUL, I assume no liability for you recursively deleting or removing all permissions from your data.  Or for that matter, anything else as a result of a lack of caution or expertise!]

This was an interesting one.  Had a machine that kept having issues during Time Machine (TM) backups.  It completed the first backup successfully and then stalled on one of the next few backups.  In this particular case it’s multiple terabytes over a fairly slow connection so the first backup takes days.

Then it sits “preparing” for as long as you’d care to watch it.  First time this happened I monitored TM activity using Console.app and a backupd search string, nothing was really happening.  So then I stopped TM and tried to cleanup the .inProgress folder so TM could start over.  I was trying to force its recovery after (not completely covered) basic methods didn’t work.

This .inProgress folder completely refused to be deleted.  Nothing worked: started with rm -R and when it complained thought it was the usual system immutable flag.  That the file was locked.  Tried chflags -R nouchg and had no luck.  Tried some advanced variations of that, still nothing.

(Side note: this is my second round with this exact issue, the first time through I made sure the data was backed up elsewhere and formatted the drive, just for the sake of time efficiency.  Since the issue is back I have to address it head on.)

“ls -lahe” revealed files with ACLs set to deny access to everyone.  So I used chmod -RN to recursively remove all permissions.  I kept getting “chmod: Failed to clear ACL on file” and “Operation not permitted” despite being root.

So.  Hmmm.  I can’t remove ACLs prohibiting deletion on files which also have system immutable flags set, meaning I can’t change ACLs via any method.  I should mention that yes, I did check directory structure integrity way earlier in the process.  Taking a step back I realized this was a TM-created issue, so maybe tmutil can come to the rescue again.

Sure enough: Use tmutil listbackups just for verifications and then use tmutil delete snapshot_path [use actual path here sans brackets, e.g. /Volumes/ExternalBackup6TB/Backups.backupdb/ComputerName/2016-09-12-000400.inProgress/]

This returned the error “snapshot_path: No such file or directory (error 2)” AND YET in a separate session escalated appropriately “fs_usage | grep tmutil” showed the truth, that tmutil was furiously cleaning up all those untouchable files.  I later verified that the .inProgress folder had actually been removed.

Problem solved!  Hope this helps someone.  I love to hear when it does (tmutil@ this domain name) but if you’re too busy, no worries!

So you might know that /Applications/Firefox.app/Contents/MacOS/firefox-bin --ProfileManager will launch Firefox’s profile manager. Ran into a bit of a surprise when I couldn’t get the profile manager to open, even by deleting profiles/prefs and caches (using Maintenance.app) plus doing other normal fixes.

Despite Terminal reporting “Error: Access was denied while trying to open files in your profile directory.” the actual problem was the Caches directory in ~/Library/Caches – instead of the client’s short username, root owned the Caches folder. Really surprised this guy wasn’t having more issues.

Thought I’d post this here in case someone else runs into what seems to be a profile folder problem but can’t fix it through the usual Firefox-specific methods. In case that doesn’t tell you all you need to know, check this link for more details, specifically the part surrounding the command you’ll use to fix it which I’ll quote here in case it helps:
sudo chown -R `id -un`:`id -gn` ~/Library/Caches
Please note I haven’t tested that on Yosemite 10.10.5 but the code doesn’t look tricky so it should work fine. It’s just a basic chown command with a couple nested commands that insert your specific username and groupname into the main command. Email me at firefoxprofiles at this domain name if you have questions!