Timed out waiting for CcmExex service to be fully operational

The mis-spelling above is intentional BTW, this is how it appears in the SMSTSLOG.log file. Typically a task sequence will be ticking along then something will happen after which the above error is displayed, almost always when it is trying to install either a ConfigMgr package or a ConfigMgr application (ie not a command-line). This is because the client isn’t actually required to execute, for example, a Powershell command line, but it must be initiated if a package or application is called on.

Ultimately, in my experience, this always comes down to one issue – an inability to reach the Management Point. There maybe various reasons for this and one such reason is described here.

However in my case this wasn’t the problem. Following a task sequence upgrade to 1909, I found all our laptops failing with this same error. These laptops were all on the internal network (ie not connected via VPN/DA, etc). If I logged on locally, I found that while I was able to ping machines, I was unable to reach shares from other machines on the network. Something was very wrong with networking (and obviously why the build was failing).

Running an IPCONFIG /all revealed that the broken laptops were all trying to use the IP/HTTPS Tunnel Adapter Interface. This synthetic interface is typically used for Direct Access which these laptops were certainly not using at the time. On further investigation, if I removed the group policies the laptops inherited for the duration of the upgrade I was then able to complete the upgrade without issue.

THE SOLUTION

The group policies are causing the tunnel adaptor to become active albeit briefly (haven’t got to the bottom of why this happens BTW). Unfortunately the adaptor isn’t able to communicate with the MP as it should. Then I read an article about a bug found in the 1909/2004 OS’s. You must ensure this patch (Oct 2020 update) is applied to the installation media prior to upgrade. Essentially, the certificates were disappearing causing the communication problem with the Tunnel adaptors on the laptop models. Once the patch was added, all was well.

Configmgr client application stuck at 0% downloading

I’ve been meaning to do a quick blog about this issue for some time now especially as I have witnessed this incredibly frustrating problem at two separate clients during roll-outs, particularly OS deployments that also require updated applications, etc. A Google search will reveal many different ‘fixes’ for this issue, most common of which tends to involve re-installing the ConfigMgr client. Indeed this is an approach I took first time round and usually seemed to work but it isn’t really a fix as such.

In the latest instalment, this approach just didn’t work at all so I needed to find what else was causing the issue. If I left the offending application to time out – this might take several hours btw – I could usually restart it and it would go ahead and download. However this was still unacceptable.

SOLUTION

Turns out the answer, with hindsight, was the same in both instances – too many policies. Essentially in both circumstances, the machines experiencing the issue had a lot of applications and/or task sequences deployed to them. Task sequences in particular usually have many steps and this seems to flood the client causing it to display this ‘stuck at 0%’ behaviour. Try removing the machine from all unnecessary collections, leave for an hour or so for the machine to expunge any of the old deployments and try again.

This still feels like a Microsoft issue to me but until it’s addressed this is the workaround.