There is no known bad side-effect to sharing the same DH parameters with other people / servers. This is in fact the common case in elliptic-curve DH, because generating your own curve is substantially more difficult than generating your own prime modulus for classical DH, and usual implementation of elliptic curves are tied to a specific curve or a small set of curve (because this is easier and more efficient to write that way).
There has been some theoretical concern about how an attacker might invest a lot of work into "breaking" discrete logarithm modulo a specific prime and then reusing the intermediate calculations to quickly break many DH instances which work modulo that specific prime. In that sense, reusing common DH parameters might imply an extra power of nuisance for the attacker. But this kind of cost sharing does not work for all DL-breaking algorithms, and this also assumes that the attacker could break DL modulo the prime, i.e. that the prime was too short or "special form". This would be a much more pressing reason not to use that prime: not that it is shared, but that it is weak.
Thus, using existing, shared DH parameters is not a problem as long as you can make sure that the said parameters have not been specially "cooked" to allow for a fast(er) break. This usually means that the generating algorithm has been fully specified and can be verified to have been faithfully followed (e.g. see these ones).
Using custom DH parameters should work with all clients, because there is no implementation advantage to tying an implementation to a specific modulus (contrary to elliptic curves). As long as your modulus fits in the size requirements of a specific implementation, things ought to be fine (some older implementations have trouble with sizes beyond 1024 bits; other won't like a modulus whose size is not a multiple of 32 or 64 bits).
