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.
To increase the PXE boot speed, we need to modify TFTP Block Size.
In the registry editor:
Path : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\DP
Name : RamDiskTFTPBlockSize
Type : REG_DWORD
Value : 16384 (decimal)
16384 is the maximum supported value.
If it is bigger, you can have corrupted data.
However I recommend to do some test with values :
Depends on your network configuration, a lower value can be used.
Restart the Windows Deployment Services Service. (WDS)
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
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”.
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
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>’
Once the record is removed, you should be able to modify the object.