I think the best thing to do is just checking for password weakness on server side, this can be an expensive operation (in example lookup from dictionaries). Also passwords commonly used or checked for attacks are a good bet.
It is possible MS first try to hash the password and compare it with a list of unsecure passwords (that are actually not used by any real user). If the hash fail, then it could in example try to look for password strenght with another euristic, finally it can either refuse or accept the password and forget it in its non-hashed version. If the password is refused it is likely it is added to unsecure hash list.
Password weakness check can also keep into account common used attacks, so it has to be a evolving algorithm.
This has either 2 advantages:
- You do not need to store ALL unsecure passwords' hashes.
- You can ban altogheter collisions in hashes (in example a strong password with same hash of a weak password).
Of course those are just speculations, we cannot know password security measures taken by such a big corp like microsoft.
As final measure I would just use a different hash for weak passwords compared to real user passwords.
Why even weak passwords should be hashed? To me there's no need for strong hashing, but hashing weak passwords would allow at least to "secure" valuable data. It is no cost do some simple hashing, but if any database data leak, you know at least competitors won't be able to easily reverse weak passwords, wich may still be a security concern for services that do not use the ban list or at least may just cause a minor economical advantage.
So to answer GroundZero comment: No, to me neither weak passwords should stored in plain text. A simple hash would benefit the corporation anyway. This is because there are passwords that are culture specific, gather that information would require massive investement, so why should you store valuable info in an easy to retrieve way?