This load balancing solution will cost you a grand total of about 10 minutes of time.  Now I will say that it's definitely not the best load balancing solution out there, but it's cheap and works amazingly well for something so simple.

First I need to explain a feature of ASX files that makes this somewhat bullet proof.  ASX files have the very awesomely cool feature of allowing you to specify a rollover URL within an entry tag.  This allows you to specify a primary and backup (or many different backups) URL.  You do this by specifying multiple ref tags within a single entry tag.  This tells the player that if the first one fails, roll to the next ref URL.

<asx version ="3.0">
 <entry>
  <ref href="mms://server1/video.wmv"/>
  <ref href="mms://server2/video.wmv"/>
 </entry>
</asx>

So if for whatever reason our connection to server1 fails we'll rollover to the URL pointing to server2.  This works great if all you need is a backup server in case the first one goes down but it doesn't make any attempt to balance the load.

I love random numbers.  Note the blog name.  Here's an instance where they really work to our advantage.  In the code below I use the randomize function to generate a random number between 0 and 1.  I use this as the deciding factor on how to order my ASX file.  Depending on what the random number is, if it's below .5 then you will start with server2 and fail over to server1.  If it's above .5 then you start with server1 and fail over to server2:

<% Response.ContentType="video/x-ms-asf" %><ASX version="3.0">
 <entry>
<% randomize
   if rnd > .5 then
%>  <Ref href="mms://server1/live"/>
  <Ref href="mms://server2/live"/><% else %>  <Ref href="mms://server2/live"/>
  <Ref href="mms://server1/live"/><% end if %>
 </entry>
</asx>

You could easily expand this example to include 3 or more servers.  You'd need to use some else if statements and divide the number of servers into 1 to give you the numbers to check for.  For example, if you have 3 servers you'll need to check to see if the random number is below .33 or above .66 (with the else being between the two).

You could also do something more complicated by maintaing state on the web server to keep track of what the last response to the client was so that you're always going from server1 to server2 to server1, etc.  But I've found that to be fairly unnecessary if you're dealing with more than just a handfull of clients.  It is possible, but not likely, that one server could just happen to have a lower load because everyone that's connected to it is watching very short clips.  Again, I did say this wasn't the best solution out there, but it's definitely cheap.  Oh, and it's better than just doing DNS round-robin because with DNS you don't necessarily know if a particular server is down and don't get failover.

--Updated March 23, 2010 to fix the first ASX list