WDS slow WINPE boot speed with SCCM 2012 and 2016

Default out-of-the-box booting on WinPE with SCCM 2012/2016 is quite slow; I’ve seen boot times up to 20 minutes.
This is because System Center Configuration Manager 2012/2016 uses small TFTP block sizes of 512 bytes.

This behavior is set because it’s compatible with all network configurations; but the result is that the PXE boot speed can be very slow using Operating System Deployment with SCCM.

Slow WINPE with SCCM

To increase the PXE boot speed, we need to modify TFTP Block Size.
In the registry editor:
Name :  RamDiskTFTPBlockSize
Type :    REG_DWORD
Value :   16384 (decimal)

Change RamDisk TFTPBlockSize
16384 is the maximum supported value.
If it is bigger, you can have corrupted data.
However I recommend to do some test with values :
– 4096,
– 8192,
– 16384.
Depends on your network configuration, a lower value can be used.

Restart the Windows Deployment Services Service. (WDS)

Problem solved!

The location of SMSTS log files during SCCM OSD

The location of the SMSTS.log moves around depending on the phase in the deployment via SCCM/OSD.To troubleshoot this it’s important to know where the log files are located.

If you enable “Command Support” during the OSD you can press the F8 key during the OSD.

Before your hard drive is formatted and partitioned

After HDD format
x:\smstslog\smsts.log and then copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log

You can check for the below three locations for smsts.log file after OSD and when the OS is installed.
Before SCCM agent installed

If Windows OS is 32-bit, after SCCM agent installed

If Windows OS is 64-bit, after SCCM agent installed

You can check for the below two locations for smsts.log file after the task sequence is complete.
If Windows OS is 32-bit, after Task Sequence has finished running

If Windows OS is 64-bit, after Task Sequence has finished  running


SCCM – Cannot edit the object, which is in use by ‘domain\SCCM-ADMIN’ at site P01

During the configuration of an OSD our SCCM 2016 console crashed and afterwards we suddenly found ourselves without any ability to make changes.

The error was “Cannot edit the object, which is in use by ‘domain\SCCM-ADMIN’ at site P01”.Locked screen
Because of the console crash SCCM still thinks that the object is being edited.
This is because ConfigMgr 2012/2016 handles editing of objects through something called “SEDO” or “Serialized Editing of Data Objects.”.
Locked objects can be found in the SEDO_LockState table in the ConfigMgr database.

You can locate the record in question by searching for LockStateID that’s not zero, or by the user ID that ConfigMgr says is editing the object (‘AssignedUser’).
On the database server run the following query against the CCM_01 database:
select * from SEDO_LockState where LockStateID <> 0

Locked in SCCM

Use the LockedID with the appropriate information to remove the record related to the object*.
DELETE from SEDO_LockState where LockID = ‘<LockID of the record identified in the previous query>’
ScreenHunter_66 Jul. 01 10.42
Once the record is removed, you should be able to modify the object.