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 ;)