The best thing to do is just checking for password weakness on server side. This can be an expensive operation (for example lookup from dictionaries). Also, passwords commonly used or checked for attacks are a good bet.
It is possible Microsoft hashes the password and compares it to a list of insecure passwords, not actually used by any real user. If the hash fails, then they could check password strength with another heuristic. Finally the system can either refuse or accept the password and discard its unhashed version. If the password is refused it is likely it is added to insecure 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 insecure passwords' hashes.
- You can ban collisions in hashes altogether (e.g. a strong password with the same hash as a weak password).
Of course those are just speculations. We cannot know password security measures taken by such a big corporation like Microsoft unless they tell us.
As final measure, I would just use a different hash for weak passwords compared to real user passwords.
Edit: Why should weak passwords be hashed? 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, which 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's comment: No, not even 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, gathering that information would require massive investment, so why should you store valuable info in an easy to retrieve way?