Okay, so in my previous post I recommended copying the svchost.exe binary from the servicepackfiles\i386 directory. While in most cases this should work fine, there is still a possibility of version issues doing this. The better solution(although somewhat more tedious) would be to load the extra.dat file, and then go into the virusscan console, unlock it, and release svchost.exe from the quarantine. This should give you back the exact svchost binary that was removed before. I don't know if there's anyway to script releasing from quarantine, so that makes this somewhat less favourable of a solution from a wide scale deployment standpoint. However, this does guarantee that you'll get the EXACT same binary back that you lost. I've heard that Ford in particular is having an issue due to some special svchost binary they were using in their image. Because the version didn't match when they did the fix, it supposedly preventing the os from booting properly. For most people, either way will work fine, I just have to advise caution. I don't want somebody getting mad at me later because the fix I posted 'didn't work'.
This is another reason why I don't think it'd be a good idea for me to post the binary we created for the fix. It is using the specific svchost binary from our standard image and may not be right for everyone. Thanks to everyone who's been commenting/discussing here. I like seeing people helping each other out.
UPDATE: I thought this went without saying, but I'll make sure I mention it anyways. Please make sure to also add the extra.dat to your epo repositories. At this point, with 5959 out it probably is a moot point, but better safe than sorry.