Jump to content

Recommended Posts

Posted

I've got 3 machines out of 32 that are failing to complete their rebuild using MDT.

 

They get to about 65-70% then just sit as running. The computers are ready to login but without all the software deployed.

 

My attempts to restart the process or even to start again are getting me no where.

 

I've even put new flash drives in to get a fresh start but they hang at the same point.

 

Any thoughts please?

Posted
How is your MDT naming your machines when it builds them? I have had a similar issue before and it was because I named my machines via serial number and the name it was being given wasn't valid.
Posted
How is your MDT naming your machines when it builds them? I have had a similar issue before and it was because I named my machines via serial number and the name it was being given wasn't valid.

 

I'm using the same computer name they already had, i.e. 6LZ-17 for 6th form learning zone machine number 17

Posted
Monitoring is good, but I prefer server-side logging as described here:

https://www.brandonlawson.com/deployment/when-mdt-starts-breaking-bad/

 

Basically MDT keeps a running copy of the deployment logs on your share in real-time. Then you can run CMTrace against the log file to narrow it down pretty quickly.

 

Is the task sequence stalling out installing a particular application?

 

Hi, it fails at 70% on three machines. It's after the restart and before installing the applications. It seems to have an issue with the boot disk (hard drive).

 

I've then gone on to manually install the applications so I can put it back in service but after a reboot it logs on as local administrator as if it's going to continue with MDT... but it doesn't.

Posted

Grab the logs from C:\MININT if the process fails

 

If that folder doesn't exist then check out C:\windows\temp\ I think by memory there is a folder called osdlogs or something like that anyway which contains the logs from the last build.

 

Use cmtrace.exe from the SCCM utilities to read the file and find the errors. It should shed more info into whats going on.

 

Regards

James

  • Thanks 1
Posted (edited)

State Restore failures are no fun - and the one case where server-side logging really doesn't help because the last entry in the server log is "restarting" ...

 

The BDD.log file off the client should tell you where it failed, should be in

C:\MININT\SMSOSD\OSDLOGS

Grab a copy of CMTRACE (free) from MS, it parses the log files into human-readable form and flags warnings and errors in red and yellow to call them out for you. Two things off the top of my head that would stop it cold are failing to re-connect to the share and getting dropped into an OU where script execution is blocked by GPO - entirely different essays!

 

(Edit) Walked away mid-post and see James wrote pretty much the same thing before I finished

Edited by KevinH
  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...