There are a lot of things you can do to make your life easier as a server admin. I'll try to gather some of them on this page as they come up. Now, in no particular order, here is some random advice :)
Always make sure your changes are going to work before you foist them off on your players. I personally use MultiMC to iterate on client changes (and id conflict resolution) until I'm comfortable adding a new mod to the mix. Then I set up a local server and update a local copy of the serverpack.xml - loaded from a different place than the players download their live configs. This way I can test updating and connecting several times before I upload the changes to the production environment.
When a patch is ready, I will usually warn active players in chat and upload the new serverpack. While they log out to apply the patch, I upload the updated mods & configs to the server itself, save, and shut it down. Then I take a backup of the world before upgrading the server's mods and rebooting. By then, my players have probably finished updating as well and are ready to get back to it - and I am reliably confident that nothing is going to break for them :)
A corollary to this is making sure your XML is well-formed. There's nothing so obnoxious as a missing / somewhere that a good XML editor (or at least one with good syntax highlighting). Save yourself a few headaches, and let the computer validate things for you wherever possible.
Always always provide an MD5 checksum for any mods or configfiles you reference. This will save tons of downloading time on the part of your players - and can change a 5 minute update into a 30 second update. Any file that matches its provided MD5 after being downloaded will be cached - then the next time an update runs, the locally cached version of the file will just be used instead.
The things to remember when using MD5's:
If you specify
<Required>false</Required> in a module definition, the player will not be required to download it to play on your server. When working with optional mods, you can set
<IsDefault>true</IsDefault> to tick the checkbox by default - requiring players to opt out rather than opt in to the mod.
This is good for things like a minimap mod or optifine or something that may or may not be of universal interest - but is the kind of thing you can assume people will want. Personally, I flag everything that isn't actually required to log in to the server as optional just in case someone needs to remove it for one reason or another.
If you have a question or problem setting things up that these docs don't answer, feel free to ask. We hang out in #MCUpdater on esper.net and are usually willing to help people figure out problems if we're no busy with family or work or something. While we won't just build your serverpack for you, we can probably look at what you've come up with yourself to help you figure out why it isn't working.
revision attribute on server definitions is a way for you to identify different builds of your serverpack. Every time you change a config file or module, you should increment the revision somehow. Revisions don't need to be integers - or even numerical for that matter but I recommend you stick with something sane and obvious.
On my server, the current serverpack revision is 0.3.1.8. The previous revision players saw was 0.3.1.7, but the rev before that was 0.2.6. The update to 0.3.0 (MC 1.4.6 from 1.4.5) did not go smoothly and I had to update to 0.3.1 almost immediately. Then, I had to iterate a bunch on config files and minor tweaks as the bugfixes trickled out in the wake of the MC 1.4.6 release. My next planned version is 0.3.2, unless something big happens, then I might jump to 0.4.0. The individual numbers don't matter to MCU - just as long as they change every time a new update goes out to the players. I use this sort of numbering scheme to help myself keep track of changes.
Not that I officially recommend this method - especially not in the long run - but it is an option for cases where you want to get up and running as quickly as possible.
Simply bundle as many mods and configs as possible into a big fat zip file ala a typical modpack. Then define it all as a single Module. Once your players are using MCU and are playing on the server, start moving mods out of the zip and into their own directives for better update support.
<Module name='Bundle'> <URL>http://example.com/lazy-bundle.zip</URL> <Required>true</Required> <Extract>true</Extract> <InRoot>true</InRoot> </Module>
Another slightly less lazy way of doing this is by packaging a mod's configs together with it in a single zip.
Sometimes you want to deliver something to the players that isn't actually a mod, like a texturepack or something. If the thing you're delivering is multiple files, you can always just zip it up and tell the serverpack to extract it to the root.
Another way to manage this is by providing an empty file as the “module” and specifying the not-mod file as a config. You can repeat the process multiple times by using the same empty file (and its associated md5) for all of the config files you are delivering in this way. This is how I provide easy download links for texturepacks.
<Module name='Faithful 32'> <URL>http://example.com/dummy.txt</URL> <MD5>d41d8cd98f00b204e9800998ecf8427e</MD5> <Required>false</Required> <IsDefault>false</IsDefault> <ConfigFile> <URL>http://example.com/texturepacks/faithful32.zip</URL> <Path>texturepacks/faithful32.zip</Path> </ConfigFile> </Module> <Module name='Sphax 128'> <URL>http://example.com/dummy.txt</URL> <MD5>d41d8cd98f00b204e9800998ecf8427e</MD5> <Required>false</Required> <IsDefault>false</IsDefault> <ConfigFile> <URL>http://example.com/texturepacks/sphax128.zip</URL> <Path>texturepacks/sphax128.zip</Path> </ConfigFile> </Module>
Sometimes Windows doesn't like running jars directly - and it certainly doesn't like running them as an admin user. The easiest way to get around this restriction is by using a simple batchfile like this:
SET BINDIR=%~dp0 CD /D "%BINDIR%" "%ProgramFiles%\Java\jre7\bin\java.exe" -jar MCUpdater.jar PAUSE
Obviously, if your MCU jar is named something different, or your JRE is installed to a different directory, you'll have to edit it accordingly, but this is a good starting point.