This is a step in the right direction, but with the amount of email everyone get's nowadays these emails could be easily overlooked. I think the problem with patches is that they involve too much work, this is why so many servers go unpatched. You have to find and download the patch, stop the server, update, restart, etc.
It's not just being aware of the patch and physically installing it. While this may help for some users, there can be reluctance to install patches even when they are known in the enterprise. Typically the environment is controlled and carefully tested - and by installing a patch you are introducing an unknown, untested element which may have other, adverse side effects.
So you have two choices:
- Spend considerable time testing a patch before deployment, against nearly everything in the environment (application or otherwise)
- Trust that the patch works as prescribed, with no additional side effects
Given the nature and frequency of these patches from Microsoft, it's somewhat unrealistic to do thorough testing each time. And it might be even more difficult to trust the patch - if they didn't get it right the first time, how can you be sure the patch isn't going to cause further unexpected issues?
With patches available, Microsoft isn't totally to blame for a lot of these worms, but I don't think automatic update is the answer. Many organizations explicitly disable this, because, as I said earlier, control over the environment is an important thing.
The real solution here is to put out a more secure product in the first place. While it is inevitable that some patches will be needed, there shouldn't be as many critical updates as there are. Having patches few and far between would make it more feasible for all users to stay up-to-date with patches.