Vizioncore's VSS driver shipped with vRanger Pro 4.5 must be deployed as a runtime process in Windows 2003 and 2008 guests. What does this save you? You do not require open ports in the guests.
With alternative implementations, open ports in the guests are required. In fact, depending on the implementation, an entire range of ports may not be available for general use but must be reserved for backup communications.
What are the challenges with having to reserve open ports in the guests?
In simple words, with other implementations: the backup server initiates RPC communication with the VM through one port, but the RPC server on the VM responds on a different port which is taken from a pool of available ports. With other solutions, you need to tell the RPC server not to use any available port out of this pool but rather use a defined range of ports. This range is configured in the registry on the VM. This range of ports also needs to be opened on the firewall to allow communication from the rpc server on the VM back to the backup server.
In short, the one-time need to copy the VSS file into the guest is far simpler to manage and less restrictive in its operation than having to configure each VM and the firewall to keep open ports available for RPC communications.
With vRanger Pro, you still gain the full advantage of an agent-free implementation for backup and recovery. Vizioncore's patented binary-injection process works with VMware vCenter to know which ESX systems are present in the environment with which VMs. In the event that ESX systems and VM guests and applications are upgraded, vRanger Pro selects the appropriate binary version to inject when it initiates the backup.
What does this save you?
For more information on when you need the Vizioncore VSS driver, see this previous post on its operations.