You have to upgrade to a new version of Jamf Pro to image on a system with OS X 10.12, because the command as changed and the /SBin folder as been move in OS X 10.12 or higher.

Just download the Jamf Pro 10.4 and run the installer to upgrade the server. Change the Jamf Imaging in Netboot NBI and that should work.
Also Autorun does not start automatically in the New Jamf Imaging, it will need a password to start.

https://www.jamf.com/jamf-nation/discussions/24148/sierra-imaging

There is still no solution to this. We are using SSD Drive imager, with restorable dmg made out of AutoCasperNBI. Used 10.13 hfs and 10.12 both not working, Using latest Jamf Pro Imaging app 10.4, no go. Used below script to run last, still no go.

#!/bin/sh
bless -mount /Volumes/Macintosh HD -setBoot
systemsetup -setstartupdisk /Volumes/Macintosh HD

Is this Apple issue or Jamf Imaging?

I am yet to see a solution for 10.13 imaging, after finding the same results last year when it was released, I bit the bullet and moved to an app deployment method instead, it took a while but the long term benefit is I wont be making images anymore.

Here's my method
Starting with creating bulk USB's to erase and format and reinstall 10.13 with APFS on all devices, that have data pre installed - if your not concerned over the existing software state of devices you can skip to manually naming and enrolling the device against the user - although you could be inviting end user bugs from their pre-exhisting setup.
If they are fresh out of the box - hopping they have high sierra you can start by setting them up as outlined below.

Set up with a management admin account, using space bar as the password - just makes getting past all the security admin account prompts easier.

Manually name the device, and enrol the device manually against the user.

Distribute key apps through enrolment policy.

Set most of your larger apps to install using smart groups to detect if the software isn't present - and to exclude devicesenrolled after 2 weeks - a lot of the adobe apps have a tendency to fail over due to the installer - not the device or network, so having these apps to install on not present, rather than on enrolment, improves the experience. The smart groups to do this though, does add load on your MDM. If your dealing with young adults, have them to patiently install the software via self-service. So the hard work and waiting is shifted onto your end users.

use a policy to change the management account password
use a script to move the account to the /var folder and hide the user:

!/bin/bash

sudo dscl . create /Users/account IsHidden 1
if [ -d "/Users/account" ]; then sudo mv /Users/account /var/account
fi
if [ -d "/Users/account" ]; then
sudo dscl . -create /Users/account NFSHomeDirectory /var/account
fi
if [ -d "/Users/account" ]; then
sudo dscl . -delete "/SharePoints/account's Public Folder"
fi

exit

-optional and will depend on on your environment
bind the device to AD using policy

add a wifi profile which is a insecure profile that you can use to allow devices to connect to, in times of head aches, opening up a insecure hot spot for the purpose of the devices to connect to and update and receive profile/config changes can be a real time saver - especially when dealing with wpa2 enterprise networks.

the device will still need wifi profile for authenticating their user over wifi for the first time. - There is a bit to fiddle with here, but you can use a auth on login wpa2 enterprise wifi profile, that removes itself after a set number of days. These profiles, dont allow for the automatic update of certificates for the, so when the wifi cert expires you will find your self with alot of wifi issues, unless the user has this removed later on - unless the devices to be designed as shared devices, and then you will just have to update each device, come the time of the expiry of the certificate - Hence the suggestion to have a second open wifi - that you leave closed unless needed to amend the problem via the MDM - a non network 4g hotspot also works well and is more secure for this purpose - as long as you have public access to your mdm.

apply all your standard config profiles and remaining policies as required

The only downside to the process is its not management friendly if you have to reinstall the device - due to the formatting step at the start.
If they are given fresh out of the box devices , you can basically provide the end user a set of steps to follow allowing them to setup a brand new device - but factors regarding device naming can be a challenge to overcome. we use a series of acronym letters followed by the year and usercode

e.g. p-M-18-AAA0001
-p- for personal purchase
-m- for macbook or -ws- for shared workstation based device
-18- for the year
and then the usercode its to be assigned to
setting a config profile to prevent naming convention and to enforce device name based on the MDM set name - this is needed as if you clear out /library/preferences/systemconfiguration it will wipe the device name - it will also wipe their proxy details and the authenticate computer against wifi before sign in option. - but when you start loosing control over your machine names it can be very hard to manage them or track them.

Good luck.

Same here - we have been fighting this issue since probably around the time of updating to Jamf Pro 10. I know that my early High Sierra imaging process was working flawlessly for awhile, then quit without any of the workflow being changed. On Pro 10.4 now, using the latest client software and a new Autodmg of 10.13.4 still fails to restart into post-imaging process when disconnected and shutdown from target disk mode.

We have found a workaround here, after shutting down target disk mode reboot holding your CMD+R keys. Once recovery has loaded, select your internal startup disk and reboot = Jamf post-imaging workflow continues flawlessly.

PS: Go Whovians!

@cboatwright

FYI, you could just hold Option on boot and select the drive there (don't need to boot up into the Recovery Partition).

Pro tip: Hold Ctrl key when selecting the drive and the arrow turns into a circle arrow thingy. Click while still holding Ctrl and it will boot to that drive and set it as the default boot drive going forward.

@tuinte Hey a pro-tip that I didn't know! Thanks!

You may want to try this...worked for me...after your imaging script magic, add some line somewhere to edit that target drive's root drive kernel flag property which is found in: $2/Library/Preferences/SystemConfiguration/com.apple.Boot.plist...you specifically want to add rd=diskxsx for the kernel flags key...eg

<key>Kernel Flags</key>
<string>rd=disk1s1</string>