The task planner service ...?
I'm assuming you're talking about the provisioned device (purely to clarify -- so no scheduler service dies on the Core)?
Are we talking about the "Task Scheduler" service? In which case, that's a Win 10 / Microsoft native service ... which doesn't really have anything to do with us / our agent. How odd (and interesting). So ... first troubleshooting would be to look at whether there's any useful log entries (such as NT Application Event Log) about why it refuses to start / googling around on Microsoft's pages. Could lead to useful info - worth checking at least.
Another thing you may want to check into, is which SU are you on for 2016.3? Remember that Anniversary edition came out after 2016.3 came out (obviously), so you may want / need to up-lift your Core & agent install binaries to a newer service update so that things work as expected with Win 10 build 1709.
You can get the latest SU from support (I think it should be SU 7 for 2016.3 at the time of writing?) ... they may also be a bit more aware of of any problems with 1709 specifically. I'd be a bit surprised/confused how/why installing our agent should somehow torpedo a Microsoft service of all things but "this is IT" and I have seen stranger things. Either way, worth looking into / checking in with them, as they should have better visibility on whether there's any reports on that sort of stuff.
Hope that helps?
YES it's very crazy. Here you see our provisioning tasks. After 1st reboot everything is ok, but the second one kills the Taskplaner. :-( (and when the taskplaner is dead, Office can not be installed)
I tried this:
1. after the first reboot I config a "Wait" step
2. after 1st boot I delete any Software, and put only one Software between the two reboots (VLC, and next try 7-zip)
3. I config the step "Disable -Admin Password expire" after the 2nd reboot
Everytime the same Error!
I also checked all dependent services for the taskplaner but the taskplaner will not start! Then I installed Win10 from USB-stick, everything ok.
Now I installed the same paket with 1703 everything is ok.
where can Ifind some interesting log-files?
Well - since the problem is less with Provisioning per se and rather with the Windows stuff, go look there.
- So check the NT Application event log, in case the task scheduler logs anything there about why it's not starting. It's a common enough starting point.
- Check the Microsoft pages - maybe there's someone else who's had issues with the service / the service has its own log somewhere .
- As another option, tools like PROCESS MONITOR (from SysInternals) do have a "integrated into boot up" mode, and you can try to trace what's going on with that binary ... except that it's not a "simple" dedicatefd binary, in the way that (for instance) our inventory service is, but somethig like "C:\WINDOWS\system32\svchost.exe -k netsvcs -p" which is more than a little annoying, as SVCHOST does a lot of things.
... so *initially* at least (to find out why the service isn't starting), I'd say follow regular M$ resources. Once you've got some sort of error message / error code to look for, that's your first breadcrumb.
I'd also suggest checking in with support in case they're aware of other people who have a similar problem. I wouldn't be too surprised if 1709 caused some "unexpected issues" somewhere (it's not like any of M$'s major updates "went smoothly" for pretty much any IT guys I know sadly), but at least it's good to check their radar.
Hope that helps.
We ran into problems but not this one, if when we made the image for 1709 that ALL the windows updates had not been installed before capturing.
Just a thought.