Today going to share complete OSD Troubleshooting, This post will help on details the Windows Deployment configuration error issues that will be deployed to the last endpoint level. The solution utilizes Configuration Manager and the Operating System Deployment capabilities to provide a dynamic and maintainable Windows deployment trouble shooting steps with form of error, their cause and resolutions.
Deployment will be on below and each step have unique view, logs, and errors. I will be sharing details view and how to resolve and where to look on which step deployment we are running.
If any error PXE DHCP response steps, Refer DHCP Error guide
If any error after PXE Boot steps, Refer PXE Error guide
If any error after WinPE, Refer WINPE Guide
If Any Task sequence error steps, refer Task sequence error guide.
For detail process understanding, refer below Follow:
To setup our self for operating system deployment troubleshooting we needed to understand below key points:
-
Tracert.exe
-
Enable command line support within your boot images:
a. Go to the properties of your boot image(s) (right click and choose Properties)
b. Go to the Windows PE tab and tick the Enable command support (testing only) option.
c. When prompted, click on Yes to update your distribution points.
d. From within your boot image (Windows PE) environment, you can now press F8 to Open up a command window — very useful for troubleshooting.
-
Familiar with OS Logs
Windows Update log files
The following table describes the log files created by Windows Update:
Log file |
Location |
Description |
When to use |
windowsupdate.log |
C:\Windows\Logs\WindowsUpdate |
Starting in Windows 8.1 and continuing in Windows 10, Windows Update client uses Event Tracing for Windows (ETW) to generate diagnostic logs. |
If you receive an error message when you run Windows Update, you can use the information that is included in the Windowsupdate.log log file to troubleshoot the issue. |
UpdateSessionOrchestration.etl |
C:\ProgramData\USOShared\Logs |
Starting Windows 10, the Update Orchestrator is responsible for sequence of downloading and installing various update types from Windows Update. And the events are logged to these .etl files. |
When you see that the updates are available but download is not getting triggered.
|
NotificationUxBroker.etl |
C:\ProgramData\USOShared\Logs |
Starting Windows 10, the notification toast or the banner is triggered by NotificationUxBroker.exe. |
When you want to check whether the notification was triggered or not. |
CBS.log |
%systemroot%\Logs\CBS |
This log provides insight on the update installation part in the servicing stack. |
To troubleshoot the issues related to Windows Update installation. |
Generating WindowsUpdate.log for reference how to execute command and understanding each windows update component refer Microsoft doc
Refer Microsoft Docs for details understanding
MCEM OSD Logs
The root of all Task Sequence troubleshooting is called smsts.log and this log is always the first step to troubleshooting any TS issue if you have an issue, look in here first!
Unfortunately, the smsts.log can be stored in one of 7 locations, depending on the stage of the build and
-
WindowsPE, before HDD format
X:\Windows\temp\smstslog\smsts.log
-
WindowsPE, before HDD format
x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
-
\Full version windows, Before SCCM agent installed:
c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
-
Full version windows, after SCCM agent installed:
c:\windows\system32\ccm\logs\Smstslog\smsts.log
-
Full version x64 windows, after SCCM agent installed:
c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
-
After Task Sequence has finished running
c:\windows\system32\ccm\logs\smsts.log
-
After Task Sequence has finished running(x64)
c:\windows\sysWOW64\ccm\logs\smsts.log
Information is also logged as SCCM client events, which can be viewed by running the SCCM report:
Last 1000 messages for a specific computer (Errors, warnings and information)
As a general rule, the SMSTS.log provides more detail, however the SCCM client events are easier to read, and, for simple issues, can lead you to the root cause very quickly.
Alternatively, you can create status message query which will help you to monitor
select SMS_StatusMessage.*,SMS_StatMsgInsStrings.*,SMS_StatMsgAttributes.*,SMS_StatMsgAttributes.AttributeTime from SMS_StatusMessage left join SMS_StatMsgInsStrings on SMS_StatMsgInsStrings.RecordID = SMS_StatusMessage.RecordID left join SMS_StatMsgAttributes on SMS_StatMsgAttributes.RecordID = SMS_StatusMessage.RecordID where SMS_StatMsgAttributes.AttributeID = 401 and SMS_StatMsgAttributes.AttributeValue = “1002000B” and SMS_StatMsgAttributes.AttributeTime >= ##PRM:SMS_StatMsgAttributes.AttributeTime## order by SMS_StatMsgAttributes.AttributeTime DESC
In console, we have default report called
-
Task Sequence – Deployment Status / Status of a specific task sequence deployment for a specific computer
-
Task Sequence – Deployment Status / History of a task sequence deployment on a computer
