In 9.x series, how do your techs know imaging is complete?

[CasperSally]

Prior to 9.x, at the end of our image process as the last item of our post image scripts, we used to reboot the macs using shutdown -r command so when the macs were at login screen (with config profile based login window banner appearing), the techs knew imaging was complete and computer was getting config profiles properly. Techs need to do this visual check for config profiles for security on every Mac imaged.

In 9.x, this shutdown command no longer works because jamf helper doesn't consider the script as completed, so it doesn't clean them out of Library - App Support - JAMF - FirstRun, so when the computer comes back up, it runs all post image scripts again (creating a lovely loop).

If you set packages to install on boot drive (such as adobe apps), this problem takes care of itself (techs know when at login screen imaging is done, no longer logged into the adobe account), but we install as much during imaging via compiled image as we can.

Anyone else out there that doesn't install packages on boot drive, how do your techs know when post image at reboot scripts are done running)? Checking policy logs or logging into each machine isn't practical for thousands of machines.

jamf displayMessage doesn't seem to work at login window.

Thanks for any ideas

[davidacland]

Could you just use something like the first boot package from Rich: https://derflounder.wordpress.com/2014/10/19/first-boot-package-install-generator-app/

Or could you just add in a payload free package to be installed at reboot to force the process to work?

[CasperSally]

Thanks @davidacland

I happened to try this at the end of our last imaging script and it seems to do the job in my so far limited testing. Even better than the reboot maybe

Reloads login window and shows login window text (so tech knows config profiles came down).

launchctl unload /System/Library/LaunchDaemons/com.apple.loginwindow.plist
sleep 15
launchctl load /System/Library/LaunchDaemons/com.apple.loginwindow.plist

[jescala]

You may want to vote up this feature request:

https://jamfnation.jamfsoftware.com/featureRequest.html?id=200

[Look]

How about trying to use

shutdown -r +1 &

It will shutdown in 1 minute but move it to another task allowing the current script time to finish.
Well at least I think it will :)

[bentoms]

@CasperSally We're on 9.63 & our workflow is detailed here.

Techs no a Mac has been imaged as the post flight config policy called has a restart command.

As we edit the login window, techs see the edited login window & know the Macs been imaged.

Not had to changed from 7-9.

[Nix4Life]

+1 on what @bentoms said, plus munki updates start

LK

[CasperSally]

Unfortunately for us, it looks like we have to add the quickadd package back at reboot for imaging to work, so techs will know imaging complete when out of the adobe account. Thanks for all of the replies, I hope someday the imaging process will work like it should for us and not require the quickadd and I'll try some of the suggestions here.

[bentoms]

@CasperSally It may be worth investigation what is failing for you as it's working for others..

[CasperSally]

You're preaching to the choir @bentoms - been working with support since Dec. Had similar issue in summer 2014, which apparently is same root issue.

Apparently major code changes are needed to address issues with certs/enrollment/etc. Makes it so frustrating to get emails to 'see what we've been working out all winter during the Ice Out' knowing that the issue I reported first week of Dec that needs major code changes to address is still an issue, without a timeline for those code changes taking place.

[bentoms]

@CasperSally I'm wondering what differs between your workflow & mine

[CasperSally]

I'm not sure what makes our environment different, I try to keep things as basic as possible, but we seem to have constantly had issues with cert based communication & enrollment.

We actually had cert issues in 8.x series, but we used MCX back then and it didn't ever cause a pain point in our workflow. I remember support telling me if I ran X command it would be fixed going forward, but I think it never was.

When I upgraded to the 9.x series and started using config profiles instead of MCX, I started seeing "unable to decrypt profile" errors.

Over the summer I got a band aid fix for that and was able to move on with special build of 9.32. Issue came right back in my 9.65 testing. Support had me change a flag in mysql to stop that issue as a test which seemingly worked. The sql change doesn't fix the actual code issue, but allows config profiles to come down as they should.

Then, in further 9.65 testing, I started running across the device signature issue which caused me to have to put quickadd back in the workflow like @loceee. I only see this with Autorun data stored, but autorun is something we depend on.

[bentoms]

@CasperSally Ah, auto run data. We don't use it. So that's the differing factor. :(