“socket ‘connect’ failed; 8007274d” during Operating System Deployment

Logged in SMSTS.log

Scenario:

1. Some devices fail with the above error during an OS Task Sequence deployment
2. Some devices run the same TS perfectly fine
3. When devices do fail with this error, they fail at the same step in the TS.
4. (Unconfirmed if definitely related or not) The TS step type is “Install Application” and is set to “Install applications according to a dynamic variable list”

Troubleshooting:

Within SMSTS.log:

There’s a lot going on in this screenshot which needs to be called out:

1. Regarding the context of this step, this is one of the first steps that occurs after the OS image has been applied, the Config Manager client has been installed, and the PC boots into Windows setup. ie: the PC has just been “created” and is coming to life for the first time. It has no real prior knowledge of your SCCM environment or domain apart from the few details given to it during the domain join step and the Config Manager Client install parameters.
2. Purple highlight: The Task Sequence Engine has started up (that’s how these logs exist) but the CcmExec service was not running/ready initially. This is reflective of the computer restart step that had occurred immediately before this step. This isn’t an issue/error but it’s important to note because it shows the computer (and CCM’s components) are still starting up. It takes about 20 seconds from the Task Sequence engine detecting the CcmExec service isn’t ready, to the service actually being ready. Once the CcmExec service is ready the Task Sequence Engine immediately continues with the TS step.
3. Green highlight: The Management Point that the device is using is blank. This is probably the most important line in this whole post. The Task Sequence step has begun running and the client currently has no idea what Management Point it should be using.
4. Red highlight: The device tries and retries to contact a Management Point via HTTP and then HTTPS. The client has no assigned MP so it hasn’t actually tried to contact anything. The logs (not obviously) show this issue as there is no hostname before the port. You would normally expect to see “hostname:443”

Jumping over to the ClientLocation.log:

The timestamp of this log vs the SMSTS.log previously is the important piece: the client begins searching for an MP and chooses one at at 10:51:12am. In the previous SMSTS.log screenshot the TS step continued executing at 10:51:07am and attempts the first connection with the (blank) MP at 10:51:09am.

If we merge SMSTS.log and ClientLocation.log together:

The TS step has begun execution before the client has chosen the MP that it will communicate with.

I’m going to make an assumption about the internal logic of the Task Sequence Engine and say that the TS step retrieves the list of known MPs from WMI once and no check is done to ensure the list is not empty. The step will try and hit <blank> MP and obviously fail. The step sleeps for a few seconds and tries hitting the same (blank) MP. Even though the client has since updated its assigned MP in between these retires, the TS step doesn’t re-retrieve the MP list from WMI. Eventually the TS step runs out of retires.

This issue is likely only possible on the first ever bootup of a machine as the CcmExec service has to communicate with remote systems to retrieve the list of available MPs in your environment. Once the service has gotten this list for the first time it is stored locally and loaded quickly into WMI when the service starts up with Windows.

Solution:

A quick solution is to add a new TS step to “sleep” after the PC restart to give the client time to retrieve the MP list. I went with 30 seconds and this has worked so far.

A more complex solution would be to write a script that retrieves the assigned MP information from WMI and check if it is blank or not. If it is blank, sleep some time and then recheck. Repeat. You’d need to add a timeout just in case, too.