The .NET platform was intended to be as language-agnostic as possible from the beginning -- one runtime (the CLR, a virtual machine) running its machine instructions (IL, or Intermediate Language) compiled from source code created in any of a number of languages. There was Visual Basic .NET for programmers who were comfortable working in the VB idiom, J# for the Java-inclined, and C# for those used to working in C and C++. (This was at a time in the great Long Ago, before there were any real language alternatives for the JVM.) Java and the C family of languages are very similar to begin with, inheriting their basic syntactical structure from Algol; the primary difference between J# and C# was at the level of minor differences in language keywords and operator characters. The reason there were two such similar languages to begin with was to flatten out the learning curve -- a developer would have to spend a considerable amount of time learning the libraries, but shouldn't have to stop and think about basic language details. There was more apparent similarity between C# and Java arising from the way libraries are accessed than from the languages themselves.
There has been an increasing amount of convergence between C# and Java, and it hasn't all been because of movement on Microsoft's part. Java has learned a few tricks from C# over the years as well. And J#? Well, it was never too popular to begin with. It didn't use the standard Java libraries (it used the .NET libraries, of course) so the convenience of keeping a handful keywords intact was far outweighed by the need to forget all of the no-brainer library functions (standard class methods for data types you'd use every day without thinking). Add to that the history of enmity with Sun over Java implementations, and the cost of maintaining the language just wasn't worth the bother.
As for why a whole new VM was deemed necessary, well, that had mostly to do with the corporate desktop. Have you ever run a major desktop application written in Java (especially those written circa 2003, like the then-current versions of OpenOffice.org or Eclipse)? Have you tried to run it on a typical corporate "we'll upgrade the hardware every seven years whether we need to or not" machine? JNI and SWT didn't begin to make up for the performance and resource problems. VB6 was good for RAD GUI apps, but it had some major limitations (especially data type incompatibilities when accessing external DLLs) and Visual C++ was inaccessible to the average cubicle drone. The .NET platform killed a lot of birds with the fling of a single stone (common data types across languages, optimized access to the native platform APIs, etc.).
Note: I'm not a .NET fanboy, nor do I develop anything on that platform these days, but I do understand the corporate dev environment. C#, and the .NET platform, filled a major void at the time, and its acceptance had at least as much to do with the merits of the solution as it did with Steve Balmer yelling "developers, developers, developers!!!" on stage.