In NTLM (both v1 and v2), the authentication protocol itself is not bad -- as long as you play it within a secured connection. Indeed:
Active attackers, who can eavesdrop on the network and also inject pakcets of their own, can hijack open connections at will. If your authentication protocol is performed on a basic TCP connection, an attacker just has to wait for a normal connection from an authorized user, and steal it once the authentication step is done.
Even passive attackers, observing the protocol messages, will obtain enough information to run an offline dictionary attack: they can try potential password until one is found that matches the messages seen on the wire; and they can do that on the privacy of their own machines (that's the "offline" part).
SSL/TLS fixes both issues. If the client first opens a SSL connection to the server (with due server authentication through its certificate and so on), and the rest of the communication (including the password-based authentication protocol) occurs within the encrypted tunnel, then you will be safe from attackers. However, under these conditions, a simpler "show the password" protocol, in which the client simply sends the password "as is" (in the SSL tunnel), would be better.
Indeed, attackers are inventive, and they don't restrict themselves to simply spying on the network. It often happens (much too often) that attackers gain some glimpses of server data, e.g. through SQL injections, or by recovering old hard disks from dumpsters. This is why servers should store only hashed passwords. But there are good hash functions for that, and there are also bad hash functions (see this answer for a lot of details). When using the simple "show the password" protocol, the server is free to use any password hashing function that it sees fit; however, when using NTLM, the server must store the hashed value that the protocol mandates, i.e. "NT Hash" or "LM Hash".
Unfortunately, NT Hash is very weak against a brute forcing attacker: it is very fast (an attacker with a PC+GPU can try billions of passwords per second) and it is unsalted (attackers can collude and use precomputed tables, such as rainbow tables, to run attacks almost for free). LM Hash is even worse.
So you really should not use NTLM if you can avoid it.
A weak password is weak, however you put it, because attackers can also perform online dictionary attacks by simply speaking themselves to the server. Under these conditions, a weak password can be tolerated only with strict lockout procedures, such as closing the user account if four consecutive bad passwords are entered. This is what most smartcards do. However, this is hardly appropriate for a server, because it would make it too easy for evil-intentioned person to lock the accounts of other people.
So you need to educate your users into choosing strong passwords. For that matter, NTLMv1 adds some extra insult to the injury, through LM Hash, which restricts passwords to 14 characters and maps lowercase letters to uppercase. Password strength depends on the entropy: a measure of what the password could have been. Entropy needs some room; especially because humans are involved. Humans are bad at making random choices, but also at remembering random choices; their task is made easier if they are allowed to choose long passwords. But LM Hash does not allow long passwords. The next best thing, then, is to add extra entropy by, for instance, making each letter uppercase or lowercase on a random basis. But LM Hash prevents that, too !