It's probably possible to use the scenario you suggested if you can set up all the clients exactly the same. This also means: make sure nobody moves ANY application window or desktop icon on any client, or installs extra software on seperate clients (if it means extra "start-menu" items) because that will break your mouse input. I would consider this too easy to break, and too annoying to check and fix when it breaks.

The reason I suggested Win32::GuiTest was not to stress the servers directly, but to control the client applications that stress the server, instead of using mouse/keyboard input. Since you're only using win32 clients anyway, the windows specific nature of the module doesn't matter.

Ofcourse this would probably mean spending extra time writing the test scripts, but you only have to do that once for every scenario, you can probably reuse a lot of code for different scenarios, and you then have an automated solution that can basically run unattended, whenever you want to, and it will probably be a lot more robust than trying to keep 100 clients completely in sync.

By the way, I've just seen a demonstration of Win32::IE::Mechanize which looks neat if you need to test webapps that use a lot of javascript.

update: if you're using an in-house developed app to stress the server, you can probably make that application more easy to control from scripts. You could even consider embedding a perl interpreter in it. See perlembed.