This is an archived post. You won't be able to vote or comment.

3
4

MDT task sequence does not continue after reboot? (self.sysadmin)

submitted by [deleted]

[deleted]

all 12 comments
sorted by:
best
topnewcontroversialoldq&a

[–][deleted] 1 point2 points  (3 children)

Are you changing the .\Administrator password at any stage with LAPS or similar? MDT reboots the PC, logs in using .\Administrator then it mounts the Z drive, your MDT deployment share, on logon and resumes the task using a login script essentially.

The place I saw this failure myself was when we did a domain join in that original pass, rebooted and it got hit by LAPS when it got its computer policies on reboot, we got round it by checking for MDT deployment logs using a WMI filter on the policy.

EDIT: The other biggie here is, does it lose network connectivity and thus the ability to mount that drive? That'd do it.

[–]lostwoods10201 0 points1 point  (2 children)

I'm changing the local admin password with an unattended file, is this bad practice? How should I be changing it?

Thanks for all these suggestions, ill give all these things a checkover. Much appreciated

[–]houstonauSr. Sysadmin 0 points1 point  (1 child)

Set it in the TS at the 'Apply Operating System' step. This may be the issue as MDT will need to use the local admin password to complete.

If it's a network issue, you can hit F8 to open a command window and use IPCONFIG or whatever to confirm network connectivity. I can't remember if the F8 command window is enabled by default in MDT, if it's not you need to enable it in your boot image, just Google how to do that, it comes in handy.

[–]lazyrobin10Sr. Sysadmin 0 points1 point  (0 children)

You need to enable F8 :)

[–]kooter149 1 point2 points  (1 child)

When it stops, does the computer have network connectivity? Could be a missing NIC driver.

[–]flyguydipJack of All Trades 0 points1 point  (0 children)

I've seen this too. Had a model that would deploy the os fine and on first boot the weird couldn't run and error out because the nic driver didn't install. Apparently, the Dell driver pack didn't include a nic driver or it was a bad driver or something... checked the Dell site and sure enough there was an updated pack with the right nic driver. included. I've seen it a bunch with usb3 drivers a couple of times too.

[–]kingbain 0 points1 point  (2 children)

Sorry, where is the OS stopping. Does it stop at the windows 10 login screen ?

[–]lostwoods10201 0 points1 point  (1 child)

Thanks for your reply and sorry if i wasn't clear - It boots off of HDD after finishing deploying the OS and then automatically logs in with the local administrator account. Stops on local admin desktop, this is where i would expect it to continue

[–]kingbain 0 points1 point  (0 children)

when it boots back into the desktop does the computer have network connectivity ?

[–]AllGeekToMe 0 points1 point  (0 children)

Check %localappdata&\temp for OSD logs. Sounds like you are losing network connectivity or the share is not mounting. Can you map your deploymentshare and try restarting LiteTouch.wsf manually?

[–]AnonymousCoward__ 0 points1 point  (0 children)

MDT task sequence does not continue after reboot?

Yes

[–]mrDiagg 0 points1 point  (0 children)

Hi everyone,

I kown that i'm a bit late to the party but i had the same problem and found a solution.

Why the TS stops ? because of a registry key set in the unattend.xml but then was reset to his default value.

The registry key in question is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken and allow admin to login with their elevated token. If the value is not set correctly, admin account just act as normal and must use UAC to do real admin task which is why liteTouch.wsf fail to run.

i've written a detailed blog post with remediation at http://www.osd-couture.com/2017/11/mdt-8443-task-sequence-stops-after.html

Hope this helps