ZXTM is described by its manufacturer as an "Application Delivery Controller"- which basically means it's a combined caching, acceleration, load balancing and traffic prioritisation system. It's available in three forms: as a software product, as a "virtual application" that runs on Windows Virtual Server 2005, and as a hardware application.
We tried the virtual application flavour on a 64-bit WS2003 box. (Initially we'd tried on WS2008, but there was so much farting about to do to persuade Virtual Server to coexist with IIS 7 that we switched back, much more successfully, to WS2003). First, you'll obviously need to install Virtual Server 2005 R2 if you haven't already; although a reboot isn't official obligatory, we found that it wouldn't work without one. Once VS2005 is done, you just run the ZXTM installer and wait (this is one installer where "Starting service: this could take a few minutes" really does mean that).
Our installation chose to attach itself to port 9090 on a new DHCP-acquired IP address, so we pointed a browser at it and we were away (it's an HTTPS connection, so we had to go through the "Yes, I know the SSL certificate is invalid, please let me go there anyway" step). The first time you connect you're walked through a setup wizard that asks you to accept a socking great licence agreement, select a permanent IP address, choose an "admin" password, pick a timezone, and upload a licence file. Hit "OK", wait a minute for the network settings to refresh, reconnect on the permanent IP address you just gave it, and you're away.
The front screen is clean and simple, with a set of round buttons along the top representing the various categories of configuration you can do, and each category being represented by a tabbed page. The first thing you'll probably do is define your server "pools" - groups of server nodes within which connections will be load-balanced. You give each pool a name and a list of the servers that belong therein, and select a method by which the server can monitor whether each server is up; this can be a simple "ping", or a more complex test such as a full round-trip HTTP fetch. The server list is entered as a comma-separated list of entries of the form :, and although this isn't as elegant as, say, having a list of servers to pick from, it's simple enough and it tells you if you've typed anything invalid.
Having created a pool, you can then configure the way that pool works - and there's a shedload of parameters you can configure. Load balancing can be as simple as a round-robin algorithm or as complex as a heuristic based on observed behaviour; you can also give it different weightings for different servers if, say, you have one spanky new big one and one less beefy, older machine. Session persistence (ensuring that all connections relating to a session go to the same server) has a variety of flavours, again ranging from the simple (based on client IP address) to the complex (watching things like J2EE or ASP.NET session cookies). Bandwidth management is much simpler than the previous two tools, allowing you simply to define the bandwidth limit for any connection in the given pool. Next on the list is the ability to add further monitoring types (if you have a multi-purpose pool you might want to monitor, say, HTTP, HTTPS and FTP). Then we have some options for SSL processing, such as choosing whether to SSL-encrypt data before sending it to the back-end server, and finally some assorted connection-oriented settings such as whether or not to make the client's IP address transparent to the back-end server, and whether to try to improve HTTP performance using "keep-alives" - i.e. connections that stay up instead of being torn down at the end of each request.
Once you've defined and configured a server pool, you can create a Virtual Server - an entity that listens for connections and delivers traffic to the pool for processing. A virtual server can listen on all the machine's IP addresses, but you're more likely to want it to listen for connections destined for just a particular set of IP addresses and/or hostnames. The virtual serve configuration screen, like the pool configuration interface, has a pile of different options you can configure: traffic rules, whether to decrypt SSL traffic before passing it to the back-end servers, overload protection, service level monitoring, caching, selective compression of the responses from the server before passing them to the client, and of course access logging.