VNC usage

Generally these suggestions apply to either RealVNC or Ultr@VNC. The differences are mostly in the capabilities of the program once you get it running, rather than in how you get it running. Interoperability between the two seems to work well, but you only get the more limited feature set of RealVNC if either party is running RealVNC.

There are different options for remotely accessing another machine, which work for different circumstances. I find option 1 the most useful, and it is certainly the most secure.

Option 1 - using the VNC Listening Daemon

The Listening Daemon is the most secure way of connecting multiple machines. It works well when a single person is trying to help support multiple mobile machines, whose connection might be dialup one minute, but might sit behind someone's cable or DSL router/firewall the next minute. This technique would also generally work for supporting a machine that is behind a corporate firewall.

The support person runs the VNC Listening Daemon. This can be done by dragging the "listener" or "listen mode" shortcut from the VNC viewer menu on the Start Menu, into the Start Menu's startup folder, if you want to run it all the time. Alternately, you can just choose to run it on demand, from the Start Menu itself.

It is helpful if the support person has a named machine, or a fixed IP address, that they can give out to people that need help. You can get a name for your machine free from DynDNS,No-IP or probably other places as well. If your primary use for such a name is VNC usage, No-IP offers subdomains from the myvnc.com domain, which is on-topic. If the support person is behind a firewall/router, it is the name or IP of the router that must be handed out or given a name, and the firewall must open ports 5400 and 5500 and the router must forward ports 5400 and 5500 to the machine of the support person. If running XP, make sure that its firewall is either turned off, or allows those ports, as well as any 3rd party software firewall, and any hardware/router firewall.

The people that need support, then, must each install the VNC software. They can take all the defaults during the install. Then to establish a connection, the instructions for them are as follows:

Install VNC if it isn't already installed. The default settings are all acceptable for this option.
Start / [All] Programs / RealVNC (or Ultr@VNC) / Run *VNC Server (Not the menu name *VNC Server)
If newly installed or never before used, find the VNC server icon in the system tray, right cilck it, choose Properties, make up and type in a gibberish password of 8 characters for the box in the upper left corner of the dialog, and click the OK button on the dialog.
Find the VNC Server icon in the system tray, right click it, and choose Add New Client from the popup menu
In the popup dialog box, where it asks for hostname, type in <whatever name or IP the support person tells you>

For step 5 above, the support person would tell the name of their machine that runs the listening daemon, or its IP address.

Steps 2, 4, & 5 above can be replaced by a shortcut containing a Target command such as:

"C:\Program Files\UltraVNC\winvnc.exe" -connect <hostname>

where <hostname> gets replaced by the support person's host name or fixed IP address.

It is helpful if the supported machine's operator communicates to the support person in some manner (Instant Messaging?, Telephone?, email? These are my preferences in order) before establishing a connection, otherwise the support person may be rather surprised at windows appearing on their screen. If there isn't IM or telephone access during the VNC session, a simple notepad window can be popped up for communication.

Pros:

Works well for supporting machines that are behind firewalls
Works well for supporting machines that are at unknown (dialup or dynamic) IP addresses, with no names
Works well for supporting machines that are behind NAT routers.
Highly secure. If someone "breaks in" to a listening VNC daemon, the net result for them is that they can turn control of their machine over to the machine that they have broken into. This is not generally the goal of a break in!
Highly secure. Machines to be supported need not even run the VNC server except during the moments that they need support.
There is no need to teach the supported user how to determine what their own IP address is.
The operator of the supported machine realizes that getting support is a voluntary thing, and that control of when their machine is accessed is chosen by them.

Cons:

There is no access to supported machines between support sessions
There must be a person at the supported machine to establish the connection, and they must be told/taught how to establish the connection.

Option 2 - runninng the VNC Server

In this scenario, each supported machine gets VNC Server installed on it, with a password known to the support person. The VNC Server should be run as a service, if you want it to run all the time, or else you need to teach the machine's user how to start it when appropriate (Start / Programs / RealVNC (or Ultr@VNC) / Run VNC Server -- or copy that shortcut from the menu to the desktop or toolbar, or somewhere where they can find it).

If the supported machine is behind a firewall and/or NAT router, that firewall and/or NAT router needs to be configured appropriately (they are all different, so I can't tell you how). The goal is that the ports used by VNC (5800 & 5900) need to be permitted and routed to the machine. If there is more than one machine behind the same NAT router, each needs to use a different "display", which gets added to the port numbers mentioned, so that each such machine can have their own routing configuration, within the limits of each router in the path to do so.

If the supported machine gets a dynamic IP address from some DHCP server or ISP, either the supported machine or operator must learn how to tell the support person what that IP address is... or possibly the IP address of the NAT router if one exists. One way doing that is with DynDNS, and associated utility programs. Other ways could be invented.

Pros:

Supported machine can be accessed at any time (when it is online and running the VNC Server), whether a person is available there or not.
The machine operator may not need to learn anything to permit access, if the support person can set up the supported machine

Cons:

When the supported machine is running the VNC Server, the 8 character password provides little security
More setup work must be done on each supported machine to make an installation work effectively, especially behind a firewall, a NAT router, or for dynamic or dialup IP addresses.
The operator of the supported machine may feel that VNC can be used to spy on them. It isn't unobtrusive, so it doesn't make the greatest spyware... the icon appears in the system tray, the wallpaper generally gets disabled, the performance generally slows down, etc.