Just when you thought you seen all error messages during ConfigMgr deployment, there's a new one popping up: "An error occurred while starting the task sequence (0x8007000E)". This on multiple systems randomly showed, before task sequence is starting. When starting deployment again it's possible that it's working, or showing the error message again. That's definitely not what you want.
When looking on Microsoft TechNet i found the following post: An error occurred while starting the task sequence (0x8007000E). It mentions:
-Actually, 0x8007000e ="Not enough storage is available to complete this operation." This refers to memory (RAM), not disk storage.
-The task sequence could not save the policy to the TS Environment. The TS environment has run our of space. Your task sequence has too many apps, or too many updates, or too many steps, or too many referenced packages.
-The task sequence will try to download all polices that at targeted to the client machine. So, if you targeted updates to a collection and the client machine is a member of that collection, the task sequence will download the policy for those updates. The task sequence cannot distinguish what the policies mean unless it downloads them. All it knows is that they are meant for that client. So, if a lot of policies are targeted to the client, the task sequence will run out of environment space.
-This issue is not fixed in 2012 SP1 :-(
-One note: In SCCM 2012 R2, the XML max size goes up to 32MB. So, you can have over 3 times as many deployments in R2 without hitting that barrier. (That's the sales pitch for R2 today) I still recommend that you break your WSUS deployments out. I'm seeing much better SQL performance by doing this.
-Deleting the old software update groups, and clean up WSUS then restarting the server worked for me too.
Long story short, I found 66 Software Update Groups (SUGs) in ConfigMgr, for only 4 Automatic Deployment Rules. Most has lots of expired and superseded updates. I deleted most of them, and leave only the SUGs needed. You can choose "Add to an existing SUG" instead of "Create a new SUG" for that and remove all old SUGs left. After that deployment was working immediately again!
Another reason for me to put updates in an existing SUG always! That's better for overview, keeping ConfigMgr fast/clean, and less deployment issues too. Problem solved ;)
When using Automatic Deployment Rules (ADR) in ConfigMgr 2012 you have a choice at "Each time the rule runs and finds new updates" on the General tab. The choice is about "Add to an existing Software Update Group" and "Create a new Software Update Group". An Software Update Group will be named SUG from now on.
Not sure why this choice can be made, but with monthly Windows updates it can be handy to create a new SUG every month. That way you know which updates are deployed every month. When using an ADR for Endpoint Protection (SCEP) definition updates it's recommended to use an existing SUG. Otherwise every 8 hours or day (as configured) a new SUG will be created. The old SUGs will be kept with expired definition updates in it. Not that it's not a good configuration, but WBEM cannot deal with lots of SUGs, with expired definition updates in it.
Here's the trick. When having lots of SUGs, with expired definition updates in it make WBEM run wild and unstable. WBEM is a sub component of WMI, which in turn is contained in svchost.exe. To stop this, remove all software update deployments especially those for Endpoint Protection; the WBEM should calm down in an hour or so. If the WBEM repository is corrupt, it may take hours for WBEM to calm down. WBEM needs to detect the corruption and run a repair. Deleting the WBEM repository should be avoided.
Looking on MS TechNet I found the following post: SCCM 2012 Agent and high CPU utilization. Deleting the SUGs indeed did the trick in my case. It seems to be a known Microsoft bug and may be solved later.
