Config profile question

[bbot]

Our current environment has a config profile scoped to all machines to setup an AD cert and configure wifi using the AD cert. We've migrated to a new CA server and need to reconfigure this. I've tried updating the existing profile, but upon updating, a majority of machines fail over wifi since it tries to remove the profile(kicks them off wifi) before applying the new settings. Wired connection appears to be fine.

I found that I can cache the .mobileconfig file of the new settings on their computer and run profiles -I -F xxxx.mobileconfig and the user will only see a few seconds of downtime.

The only problem with this is that the existing config profile will still remain. Is there a way I can decommission the profile without affecting the users?

[mm2270]

So, just to make sure I understand. You're installing a Config Profile manually that is a replacement to an older similar profile which then needs to be removed once the new one is in place. Is that right?
If so, what I would consider doing is, if needed depending on what version of Jamf Pro you're on, create an Extension Attribute to capture the installed Configuration Profiles on your Macs. Note that this may not be necessary if you are on the latest version of Jamf Pro as that Profiles criteria was recently added in as a default item if I'm not mistaken.
In any event, the end goal would be to create a Computer Smart Group that captures Macs that have that new profile installed on them. This is assuming the new profile has a unique identifier or some other way of identifying it from the old one. Then add that Smart Group into the Exclusion tab for the scope of the old config profile. Once they recon and land in that group, on next check-in, or whatever trigger you choose, they should have the older profile removed from them over MDM since they are now in the Exclusion group.

[bbot]

I am on 9.98. Correct, I am planning to use a .mobileconfig cached locally on the machines, then using "profiles" to install it.

I tried your idea.. unfortunately, putting the machine in the "Exclusion" removes the configuration profile, which also wipes the Wifi setting..leaving the machine disconnected from wifi.

The problem is that the old configuration profile is configured to setup wifi using the same SSID as the new configuration profile. We can't remove the old config profile first as the machine will have no network connection to install the new profile.

After installing the new profile, removing the old configuration profile will delete the SSID from the system preferences, also leaving the user without a wifi connection.

I've attached a screenshot of our existing config profile. The new config profile is identical, except the AD certificate payload is pointing to our new CA server/template.

This is why I want to install the .mobileconfig locally going forward instead of using Config profiles managed by Jamf.

[mm2270]

Ok, so because they are essentially identical to each other other than the different CA server, I can see why you'd be having this issue. I'm not sure, but I feel there is likely a better solution to this that doesn't involve installing a new profile manually and somehow trying to remove the old one. Since simply updating the original profile causes it to be temporarily removed, which bumps it off the net and unable to finish what it started, that does put things into a pickle.

So my assumption is because you've made a new profile, it must have a unique ID from the original. If so, then unless someone comes along with a better solution, I'd say maybe what I'd explore is a package that would deploy 3 things - your .mobileconfig file, a LaunchDaemon and a script called by that LaunchDaemon.
The .mobileconfig could get deployed into /tmp/ and sit there. The LaunchDaemon would of course go into /Library/LaunchDaemons and the script can go anywhere. What it would do is, upon dropping these files in place, have either a script running "After" from the policy or an embedded postinstall script in the package enable the LaunchDaemon (the latter may be preferable). The script called by the LaunchDaemon would look for the mobileconfig in /tmp/, look for the old profile using the profiles -P command, meaning parse the output and look for the old profile's UUID string. If both are there, initiate a removal of the old profile first with profiles -R -p <profile UUID> and then install the new one from temp using what you're already doing with profiles -I -F <path/to/profile.mobileconfig> In other words, reverse the order so that you end up with the new one installed after the old one is removed and the Wi-Fi entry added back in for the user with the new profile.
The only issue is that you could still run into a problem when this is all done with a policy since the connection back to the JSS will still get broken temporarily. That's why I say maybe to have the package itself enable the LaunchDaemon from a postinstall script. At the end, have the script called by the LaunchDaemon remove itself and the LaunchDaemon so they get cleaned off the Mac.

Does the above make sense? Do you think this might work for you?

[bbot]

Thanks for your suggestion @mm2270 . Had to read it a couple times before I understood..but here's why I think it wouldn't work..

Once I initiate a removal of the old profile, the machine loses WiFi. The new config profile needs network to talk to our CA server to generate the new active directory cert. No network connect = failed config policy application. See screenshot for new config profile. It needs to talk to the certificate server and request a certificate from a template.

Long story short, the machine needs access to the corporate network to be able to generate a new certificate, then configure the wifi (using the same SSID) to connect using the new cert.

At the moment, the only possible solution I can think of is having the networking team create a new SSID. The new config profile will be deployed and Macs will be connected to the new SSID. Then I can gracefully remove the config profile which will end up removing the wifi connection to the old SSID. This is our last option if we can't think of anything else.

[bbot]

Just talked with networking and they're open to creating a new SSID for wifi.

Here's my plan
1) Deploy new mobileconfig using "profiles" that connects to new SSID
2) Once all machines are connected to new SSID, delete Casper configuration profiles for wifi. (this may be hard timing wise as some people may be out of office -- vacation, etc..)
3) Once deleted, deploy another new mobileconfig using "profiles" that connects back to the original SSID.
4) Once migrated again, networking team can remove the newly created SSID and things will look just like the way they did.
If networking team is okay with leaving two SSIDs, the migration can be done after step 2.

I'll be writing a script to place in Self Service that'll basically run the "profiles" command to configure wifi. After 3 years of managing wifi through a configuration profile through Casper, I never want to use it again. We've had so many issues with machines falling off the network, pain with renewals, and now pains with changing the CA.

Cert renewal process is very simple. Deploy the mobileconfig again via profiles tool in terminal, it'll request a new cert with a new expiration and reconfigure the wifi with no downtime.

[mm2270]

Ok, yes, I had thought that a new SSID might be the best option, but didn't suggest it since I didn't know if that would be acceptable. But the way you're describing, I think that really is your only option. It sounds like losing any Wi-Fi connectivity before the new profile gets installed simply kills the entire process, so I can't see any other way of doing what you need to other than moving everyone over to a new SSID.

Good luck. Post back once you get through this to let us know how it went.

[bbot]

Thanks for your time Mike!

[bentoms]

@bbot Can you deploy a new profile with a new CA.. alongside the old profile.. then remove the old profile when all devices have the new?

[bbot]

@bentoms I can deploy a new profile with the CA with no issues. The problem comes when removing the old profile. Since the old profile is configured to connect to the same wireless SSID, wifi settings for that network gets deleted and the machine loses wifi.

I'd prefer to keep it out of Configuration profiles in JSS as well. The main reason being that when the certificate expires in 1 year, I'll need to re-deploy the profile to re-new the cert. When re-deploying the config profile, the profile on the machine gets deleted by the JSS, then re-added. During the deletion, the wifi settings will get wiped, leaving the machine without a network connection and causing the deployment of the config profile to fail.

[hpavlic_]

@bbot

We have the same issue in our enviroment. How did you end up solving this issue?

[bbot]

@hpavlic. we had networking create a new ssid. I created a new config profile with all the new settings. I decided to write a script and use the profiles command to install it. The script enabled me to check the pre-req's (i.e machine name was correctly set, AD binding was okay, etc..) before installing the .mobileconfig.

[hpavlic_]

@bbot

Great, can you please share the script you created for checks and installing .mobileconfig?

I am having troubles with installing .mobileconfig profile in user context.

[bbot]

z