PXE Boot | Boot into WinPE then Immediate RestartS HERE
I recently came across a little issue where I was PXE Booting a machine into the WinPE environment to start a Task Sequence to image the machine. Once it had loaded and it had passed the “Loading Network Settings” window, it immediately restarted.
The most common cause for this is that you don’t have the correct NIC drivers. I rebooted again, then pressed F8 which brought me to a command prompt. Once I was there, I waited until it went past the “Loading Network Settings” page, then ran an IPCONFIG to see whether I got an IP address. In this case I did. That means it wasn’t a NIC driver issue.
The next thing to check is the BIOS time. Make sure this is accurate. In my case, this wasn’t accurate at all. Once I reset this, I rebooted again into WinPE, and the Task Sequence started without any problem.
A quick 5 second fix could help you save an hour of troubleshooting!
OSD Task Sequence Failure | 0x80072EE2 | Network Connectivity Issues
Recently when I was out at a client, they were running OSD (Operating System Deployment) on a particular model of machine (Dell Optiplex 7040) and it started throwing up error messages during the “Download Operating System” step. The error message was 0x80072EE2.
When pressing F8 to check smsts.log, there was nothing there out of the ordinary. The only interesting thing I could see there, was that it hadn’t added in the latest log data yet, so as far as it was concerned, there was nothing wrong with the OSD.
I checked my IP, which was fine. I tried pinging the SCCM server (and any other server on the network) and noticed that I was getting a lot of packet loss. This explains the issue that I was getting. Essentially, the network connectivity would be completely find up until a point where it would start getting massive packet loss, and then fail during the download.
I ruled out a physical issue with cabling, patching and the device by trying different network ports on the wall, and also trying different Dell machines (all 7040 however). I received the issue on all of the machines, virtually at the same point in the Task Sequence.
I attempted to inject different drivers into the Boot image, but that didn’t help either. I was happy that this wasn’t a driver issue, and it wasn’t a physical networking issue. The look continues!
I added in three Task Sequence Variables into the beginning of my OSD Task Sequence. The idea behind these was to make the deployment less delicate, and to continuing working through the TS if there’s some packet loss etc.
The variables I added are the following:
After adding these TS Variables in there, I restarted the machine and went through the OSD sequence. This time it completed without any issues.
Essentially the issue was that with the drivers and WinPE versions on this particular machine, the NIC was a bit flakey. Packets were dropped etc which originally caused it to fail. These variables just told the Task Sequence to be less particular when it comes to timing out. There will still be that intermittent packet loss when doing the TS, but this time it won’t cause it to fail.
SCCM | Editing Object | Cannot edit the object, which is in use by ‘’ at Site ‘’
Recently I have been working on a client’s SCCM server, and it has been crashing a lot. The problem with crashing, is that it doesn’t update SQL to tell it that the item is no longer in use, therefore it remains ‘locked’. This means that if you try to open the object (in this case it’s a boot image), it will say “Cannot edit the object, which is in use by <username> at site <sitename>.
You can try to resolve the issue by clicking ‘retry edit’, but it usually fails.
In order to get around this, there are two SQL queries that you will need to do which will allow you to edit the object immediately. They are the following:
select * from SEDO_LockState where LockStateID <> 0
and
DELETE from SEDO_LockState where LockID = ‘<LockID of the record identified in the previous query>’
That’s it! Once you’ve done that, you should be able to go into the ConfigMgr console and open up the object that was previously locked.
