Jamf Nation Community

Chriskmpruitt · ‎04-16-2014

During the imaging process, some of our computer just skip the post image policys. We have our policys ran on a trigger called postimage. Sometimes it works flawless and sometimes it just skips them. After the computer is done imaging, we can run the postimage command manually and works that way. Just wondering if other people have had this same problem

golbiga · ‎04-17-2014

Sounds like the enroll.sh issue that drove me to move away from using Casper Imaging. The clients that are failing to run your triggered policy aren't being enrolled into your JSS when they first reboot. So the designed behavior is to wait five minutes for the machine to attempt to enroll itself again. You could add a script to the beginning of your first run script that checks to see if the machine is enrolled and if not wait 5 minutes. Not desirable but it works.

Allen

acdesigntech · ‎04-17-2014

what are the contents of the jamf.log file on a machine that skips the post-imaging setup?

I've had this issue before where if a policy that needs to mount the CasperShare is kicked off while the post-imaging policy is running, the post-imaging policy will just skip the rest of whatever it's working on.

It has to do with Casper inability to mount two of the same casper share simultaneously and run individual policies. Allegedly switching to http/s distribution points rather than AFP/SMB resolves that problem.

lwindram · ‎04-17-2014

I had the same issue here. Multiple WebEx's did not result in remediation. We were getting inconsistent (but almost always incorrect) results when imaging with the packaged OS. Either the computer would never be enrolled, or the computer would enroll again, creating a duplicate record. So our imaging process always involved a tech having to manually enroll each machine using jamf enroll -prompt, then verify that there was only a single record in the JSS. This added a lot of extra time to the imaging process.

I spent my "spring break" at my desk trying to resolve this issue. I ended up switching form a packaged OS (made with composer) and quick-add to an apple installer (made with AutoDMG) combined with a first-run script (credit to Rich Trouton).

QuickAdd only installs the JAMF binary and runs a few commands with it. It also contains a multi-use enrollment invitation. If you drag the package into composer and convert it into source, you can grab the relevant components.

The two lines that I ended up using in my firstrun script were:
/usr/sbin/jamf createConf -url 'https://CASPER.xxxx.xxx:8443/' -k
/usr/sbin/jamf enroll -invitation 99999999999999999999999999999999

I run these at the end of the script. The users are created, wi-fi is setup, time server is set, machine is bound, etc first. The enroll switch causes a recon, so I don't run a discrete recon. I have only imaged about 20 this way, but I have been pleased with the results.

bentoms · ‎04-18-2014

We saw this, but it was due to the JSS using the wrong DP.

The DP it used was an HTTPS one with the SSL from our root CA. Our CA's cert is deployed via a config profile, but only happens post enrolment.

Other than that issue, it's been rock solid for us.

Chriskmpruitt · ‎04-18-2014

finally got one to brake. Of course when you need it to brake it works. But here are the jamf logs

Fri Apr 18 10:38:49 101631 jamf[146]: There was an error.

Connection failure: "The host kibsdjss.kibsd.org is not accessible."

Fri Apr 18 10:38:59 101631 jamf[3068]: There was an error.