Imaged computers suddenly won't enroll

[powellbc]

Tonight I installed a publicly signed SSL cert on our Windows based JSS (9.32), following the instructions here: https://jamfnation.jamfsoftware.com/article.html?id=115. I did this manually, not in the JSS interface.

After installing everything seemed ok in terms of client communications, except after the SSL cert was installed clients would not enroll post imaging, and firstrun scripts were not executing. The only (not acceptable) workaround was to log in using our casper management account (which was created), then reboot. Then, the script would execute, but the machines were still not enrolled.

The Jamf.log indicates that the reason is the account for enrollment does not have permissions. When I manually enrolled it (you can see this at the end of the log) with an account we use with our QuickAdd packages it worked fine. Because of the certificate change, I thought about how our default Casper Imaging setting is “Allow untrusted JSS certificate” so I tried unchecking that, but it still showed the same issues.

I reverted to using a self-signed certificate, and the issue is still occurring, so I do not believe that is the cause but I wanted to highlight the only change made. The vexing thing about this is our test environment (which is functionally identical and had an SSL certificate installed in the same way) did not show this issue at all. Does anyone have any idea what the cause could be?

[jinpeng]

i have seen this before

[powellbc]

Do you know what the cause was?

[powellbc]

The only other symptom of note is after imaging, the machines seem really sluggish. Logging in is subject to lost of beach balling and pauses.

[powellbc · Accepted solution]

It seems last night in my testing (after the cert install) I stumbled upon an existing issue which presents itself in a specific scenario. Our images have a first run script which deletes the .AppleSetupDone file. A second reboot is necessary to initiate the script which forces the setup assistant to run.

What I discovered is after the initial reboot, some of the processes are still running in the background which allow the machine to be enrolled as well as preparing the script which forces the setup assistant. If you initiate the reboot too quickly (which I was doing last night) it will interrupt these processes and cause the issues I described above. Simply waiting about 5 minutes after the first reboot allowed everything to work normally.

So, in summary, the SSL cert had nothing to do with it. Rebooting before the first run scripts were prepared was the cause.