Why doesn't Restart immediately do what it says?

[stevenjklein]

Restart immediately is mis-labled. It should be called Restart after this and all other in-scope policies with the same trigger finish. (But that probably wouldn't fit in that drop-down menu.)

Problem:
For two policies with Trigger: Startup, both set to Restart immediately, I want and expect this:
1. Policy 1 runs
2. Mac restarts
3. Policy 2 runs
4. Mac restarts again

What actually happens is that both policies run sequentially, then the Mac restarts. This is equally true if you have 10 such policies; the Mac doesn't restart until after all 10 have run.

Is there any easy way to make it do what it says?

[milesleacy]

I believe this exists for economy of restarts.

I may be reading too much into your post, but it seems to me that you have a dependency here, that you want action X and a restart to occur before action Y and its associated restart.

My recommendation would be to adjust scoping.

I assume you have conditions for "action X needs to happen", even if that condition is "action X needs to happen to every managed Mac", and that this condition is represented by the scope of policy X.

If you want action Y to happen after action X and its restart, then I would create another condition "action X has happened, but action Y hasn't happened". This will be the scope for policy Y.

To better illustrate, let's say, for the sake of argument, that...
"action X" = "install Photoshop"
"action Y" = "install Photoshop plugin"
I want all my Macs to have Photoshop
I need to restart after installing Photoshop, but before installing the Photoshop plugin
I want all Macs with Photoshop to have the Photoshop plugin
I need to restart after installing the Photoshop plugin

To accomplish this, I create...
A smart computer group of computers that do not have Photoshop installed. (Group A)
A smart computer group of computers that have Photoshop installed but do not have the Photoshop plugin installed. (Group B)
A policy, scoped to group A, that installs Photoshop and restarts.
A policy, scoped to group B, that installs the Photoshop plugin and restarts.

Does this make sense?

[stevenjklein]

Your dependency assumption is correct. For newly-enrolled Macs, I have a policy that runs a script to rename the Mac. Then I want the new name reported to JSS. Should be easy, right?

I set the script priority to before, and included Update Inventory. But the inventory continued to report the old name.

Thinking that renames maybe take a while, I added a 60 second delay to the end of my script. That didn't help either. It seems that recon keeps reporting the old name until the Mac restarts. So I tried the restart action, which also didn't work. That's when I started this thread.

Following your advice, I can create a Smart Group to include only Macs with in-policy names, and then scope policy 2 to that group.

However, when I wrote about policy 1 and 2, I was trying to simplify the issue. In actual fact, it's really policy 1, 2, 3, … up to policy 16. Since I didn't want to edit 15 policies, I was hoping to find a shortcut.

(These policies only apply to new Macs being set up for the first time; I normally wouldn't dream of running 10 minutes worth of policies at startup.)

If you have another suggestion, I'm eager to hear it. Otherwise, I'll go the smart group & scope route.

[bpavlov]

You can add a jamf recon to the script and it will run an inventory update immediately/before the policy finishes.

[milesleacy]

@stevenjklein

I suspect that not all of the 16 policies have such dependencies, do they?

Is there a reason that you need the changed name to appear in inventory before policy 2 executes?

It also might be worth asking, 'What is the value of setting the computer name?'
There is a lot of FUD around the 'computer name' value. It is not a relevant value for most purposes that system administrators and IT staff need to care about. I'd be happy to discuss further, perhaps in a different thread as I don't want to derail this one with a tangent.

[jason_bracy]

I haven't tried this, but you could probably scope Policy 2 to a Smart Group created by Policy 1.

Since my understanding is that the JSS has a list of policies in scope and runs all of those with the trigger, and then after running all of the policies will restart the Mac if "Restart Options" is configured.

By creating a Smart Group after Policy 1 runs, Policy 2 will not be in scope during the first restart.

[stevenjklein]

@bpavlov : I tried that, but it didn't work either. As I discovered (and mentioned above), the name change doesn't take effect until after a reboot. (Curiously, if a user is logged in when the name is changed, the change takes effect immediately.)

@milesleacy : Regarding this:

Is there a reason that you need the changed name to appear in inventory before
policy 2 executes?

There was at the time I posted my question, but I've since worked around it.

Policy 1 renamed the Macs, and policy 2 joined them to our AD domain. I needed the name changed before joining to AD, to make sure it was joined with the correct name. (You can try adding a few dozen Macs named Local Admin's MacBook Pro to your domain, but it won't work!)

My fix was to scope my Join AD policy to my smart group Macs with correct names. So all the other policies run, then the Mac restarts, then the Join AD policy runs. Problem solved.

Thanks so much for your help.

[jason_bracy]

@stevenjklein : So I have a similar workflow. I enroll all of my Macs manually and have a policy to rename the Mac and then a policy that installs some default software and then restarts. I then have the Join AD policy run at startup. So my policies look like this:

1. 1 - JSS Enroll: (Trigger: Enrollment Complete) Start Message: Enrolling to JSS Run Script Set Computer Name Dock Item Self Service (Add To Beginning) Run Script Hidden Admin Account Run Script lpadmin Run Script Security Defaults Run Script Start Audit Log Update Inventory Complete Message: Enrollment Completed
2. Install Security Software (Trigger: Enrollment Complete) Available Offline Start Message: This computer will restart immediately after installation. Please save anything you are working on before continuing. Run Script Token Driver Install Update Inventory Change startup disk to Current Reboot immediately if nobody is logged in Reboot immediately if somebody is logged in
3. Bind to AD: (Trigger: Startup, Check-in, Self Service) - (Scope: Not Bound) Start Message: Joining Computer to Active Directory Run Script Set Computer Name Bind to Active Directory Update Inventory Complete Message: Computer joined to Active Directory

I include the Computer Name script at Enrollment and before bind just in case. Also here is my script if that helps any:

#!/bin/bash
systemsetup -setnetworktimeserver ntp.ADntpserver.com
serial=`ioreg -l | grep IOPlatformSerialNumber | awk '{print $4}' | 
cut -d " -f 2` 
computername="$serial-M"
scutil --set LocalHostName "$computername"
scutil --set ComputerName "$computername"
scutil --set HostName "$computername"

jamf recon

It basically sets the Computer Name to the serial Number and adds a suffix of "-M". It also sets the Time Server so there aren't any time drift issues with AD

[gachowski]

Wouldn't custom events/triggers work?

C

[milesleacy]

I manage only the hostname value.

Computer name and LocalHostName are for mdns and Apple-proprietary systems. These names are trivial for the user to change. Changing hostname requires deliberate action via CLI.

AD does not care what your Mac's computer name value is. It only cares that you use a consistent (and MS-compliant) value for the AD "Computer ID" value. I use the hostname for this because it is easy to manage, difficult for the user to change, and users rarely have occasion to care about what their hostname is, whereas if they want to use AirDrop or other Apple ad hoc connectivity systems, they are rather likely to change the other two values.

[tlarkin]

I am guessing that there is a naming convention dependency and that AD uses naming conventions as a reporting/scoping mechanism for computer groups. That is the only time it would matter I would think.

However your answers have already been stated. If you must have a specific naming convention before your BIND to AD, rename the Mac and then BIND the name in the JSS doesn't matter because AD will never get that info from the JSS. It only matters on the client, so even a recon isn't needed. Unless you need the naming convention to show up in the JSS as part of a scoping mechanism.

[stevenjklein]

Unless you need the naming convention to show up in the JSS as part of a scoping mechanism.

@tlarkin Your message is a reminder to me of how difficult it can be to remember all of the relevant issues when posting a question.

I needed the naming convention to show up for another reason (not scoping).

Here's the important part I left out of my earlier postings on this subject. I have another policy called Sync JSS name that uses the Maintenance task Reset Computer Names to change the computer name on computers to match the computer name in the JSS. I do this because some of our users arbitrarily change their computer names, which they aren't supposed to do. This policy fixes that problem.

So what was happening was this:
1. My policy to set the name into compliance would run.
2. Then my policy to force the name to match the name in the JSS would run, undoing the work of the first policy.
3. My policy to join it to AD would run, and it would get joined with a name like HelpDesk's MacBook Pro.

To prevent this problem, I needed these things to happen in this order.
1. The policy to set the correct name would run, then
2. That new name would be sent to my JSS, then
3. The join to AD policy could run.
4. Finally, Sync JSS name could run without screwing things up.

Thanks

[seann]

Why not make your own custom reboot framework? A dummy package/policy could easily accomplish this, along with a policy on startup to remove this package.