802.1x configuration profile installation issues

roiegat
Contributor III

So been having some issues with installing 802.1x profiles recently and decided to get a second opinion here.

So here's the scoop: We have a profile for wire and wireless mobileconfig file we put down in a folder on during the imaging process. Before it gets installed there is a check to ensure the computer active directory has the two AD groups it needs to be part of. I also have a check in there to make sure the CA is up and running just in case. If the last two failed for any reason, it has a sleep for 60 seconds to allow it to recover (since we have scripts on the backend to add the groups in AD). All machines are currently being imaged with 10.10.3 build.

Now the reason we put it on the hard drive and install it that way is because we can't (and won't) have an APN for security reasons. So if there is another method you guys can think of, please chime in.

So the issue is that while this works fine on about 75% of the installs, it seems to fail on about 25% of the machines. Seems like older machines are getting more failures then successes. When it fails it gets the following error:

"profiles install for file:'80211xWireless.mobileconfig' and user:'root' returned 1 (The operation couldn’t be completed. (InternalError error 1.))"

The script currently re-tries to install it using a 2 minute sleep between tries and only tries 5 times.

The command we use in the script to install the configuration profile is as follows:

sudo Profiles -I -F 80211xWireless.mobileconfig

(we cd into the directory before running this command)

Anyone have the same issues? Any ideas what to try?

2 REPLIES 2

m_entholzner
Contributor III
Contributor III

Have you thought about putting your script into a package? For example: Your config profile will be installed in /private/tmp. Then add a postinstall script with "profiles -IvF /private/tmp/yourprofile 2>&1 >> /your/logfile.log". The 2>&1 will put all the output into the log file. I would recommend to use the -v option because of debugging.

The advantage of using a package is, that you can choose the priority very granular and put it into your imaging workflow. This is working like a charm for us.

roiegat
Contributor III

It essentially does that at this point. One package contains the two configuration profiles and puts them in a correct folder. The reason we have it separate is because scripts go after packages. Since there needs to be a lot of configurations in place first (AD binding, network activity, and computer name added to the right roles in AD) we need to have the install script in after the package comes down.

In the script itself everything is logged to a log file. That's where I got the error message above.

I'm currently looking more on the backend to see if the CA server is working as expected.