This page will lead you through the process of setting up a VssConnect server for the first time. The process can be split into two phases; Installation of the VssConnect server software and configuration of your firewall to allow access to the server.

The VssConnect server should be installed on either the machine hosting your SourceSafe database or a machine that can access the SourceSafe database via a network share. Installing the server on the machine hosting the SourceSafe database will offer the best performance. The machine will also need to be accessible from the Internet. Often this will require you to configure your company's firewall to forward packets from the Internet to the VssConnect server machine. We will discuss this later.

The VssConnect server may be installed on Windows 2000 Professional/Server, Windows XP or Windows 2003 Server. Before installing the VssConnect server, make sure that SourceSafe is installed on the machine. VoxCode recommends either SourceSafe 6.0d build 31222 or SourceSafe 2005. The only way to install SourceSafe 6.0d build 31222 is to install SourceSafe 6.0 and then install Visual Studio 6, Service Pack 6. Don't worry if you don't have Visual Studio 6 installed on the VssConnect server machine, the service pack will simply upgrade SourceSafe. SourceSafe 2005 is preferred, because it allows the VssConnect service to run under the local system account. Using SourceSafe 2005 also allows VssConnect users to enter checkout comments and support for pinned files is improved.

Once the VssConnect server is installed, it will need to be configured. The simplest way to do this is to use the VssConnect configuration wizard. Launch the VssConnect server admin program. If the configuration wizard doesn't run automatically, click the button labeled Run Configuration Wizard.

SourceSafe Database Path: This is where the path of the default SourceSafe database is defined. Enter the path to the srcsafe.ini file or use the ... button to browse for the file.

Service Account: VssConnect operates in one of two modes. When SourceSafe 6.0 is installed on the VssConnect server machine, the SourceSafe database is accessed using the service account defined for the VssConnect server. Because of this, the account assigned to the service is very important. It must have full read and write permissions for the SourceSafe database files. When SourceSafe 2005 is installed on the VssConnect server machine, VssConnect can be configured to access the SourceSafe database using the account information supplied by the VssConnect client. In this configuration, the account assigned to the service does not need to have permission to access the SourceSafe database files (e.g. you can usually use the local system account).

Username/Password Control or Enable OS Authentication: When this option is enabled, the VssConnect server will authenticate each connected user's username and password with the operating system. If it is not enabled, VssConnect relies on SourceSafe to authenticate the user. When using SourceSafe 6.0 on the VssConnect server machine, this option simply provides more security. However, when using SourceSafe 2005, this option controls which user account is used when accessing the SourceSafe database. If the option is off, VssConnect uses the account defined for the service. If the option is on, VssConnect uses the account supplied by each VssConnect client.

GTCP Port: The VssConnect server supports two protocols, GTCP and GHTTP. Each protocol needs to be assigned a unique port number i.e. a port number that is currently not being used on the machine. VssConnect defaults to port 5555 which will suffice in most cases. If the user decides that they want to disable the use of GTCP, 0 must be entered. If the user chooses a port that is in use, an exception will be generated when the server is started. This will be located in the event log.

GHTTP: The second protocol supported by VssConnect is an HTTP based one. This is useful when the VssConnect client needs to be able to connect via an HTTP proxy server. Again, a unique port number must be entered and 0 will disable the protocol.

Once the VssConnect server has been configured, it is a good idea to test the server locally. Start the server and check that there are no exceptions in the message list. Then install the VssConnect client on the VssConnect server machine. Start VssConnect and connect to localhost using the port number that was assigned when configuring the VssConnect server. Make sure that you also use the correct protocol for that port number. When entering the username you may need to prepend a domain name e.g. MYDOMAIN\username. This is very likely if your network is on a domain. One problem you may run into is that your SourceSafe user password may not match your domain password. If this happens you will receive a message from VssConnect indicating this situation. The only solution is to either turn off OS authentication on the server (not recommended) or to switch to SourceSafe 2005 on the VssConnect server machine. When using SourceSafe 2005, VssConnect can take advantage of SourceSafe's behavior of assuming a user is authenticated if the user's username matches the SourceSafe username (even if the passwords do not match). Of course, another solution is to change one of the passwords so that they match.

Once the VssConnect server has been configured and you have verified it's operation locally, it's time to think about making the server available from the Internet. The steps required to do this vary depending on your company's network configuration. The first thing you may need to do is open up the VssConnect server ports on the software firewall that may be installed on your VssConnect server machine. For example Windows XP has a built in firewall that may block VssConnect. Open up the firewall configuration application and add the VssConnect server port or ports as exceptions. To be safe you may want to test this by installing the VssConnect client on a machine on your local area network and then connect to the VssConnect server from this machine. This will verify that the software firewall on the VssConnect server machine is not blocking the VssConnect server.

If you connect to your company's network using a VPN connection you may not have to deal with any further firewall issues. The only problem you may run into is a VPN network that only allows clients to connect to servers that are listening on certain approved ports. You will know this is the problem if you can connect to the VssConnect server from a machine on your LAN but not using the VPN connection. To resolve this issue, either ask your system admin if they can allow the VssConnect ports or configure the VssConnect server to use one of the approved ports numbers (e.g. 21 or 80).

If you do not use a VPN then you may have to deal with the configuration of the firewall device between the VssConnect server machine and the Internet. Since there are so many firewall devices in use, all we can do is describe the general procedure. The basic idea is to configure your firewall to forward TCP packets from the Internet to the VssConnect server machine on the port that was defined when configuring the server. This is often called configuring the NAT or port forwarding. For example, the following command configures the NAT of a Cisco 675 DSL modem/firewall:

set nat entry add 10.0.0.5 5555 65.102.245.230 5555 tcp

This tells the firewall to forward tcp packets from the external Internet IP of 65.102.245.230, port 5555 to the internal address of 10.0.0.5, port 5555.

If you run into problems during firewall configuration you may find a port scanner tool useful. This can tell you if a particular port is listening at a certain address.

If you come up against insurmountable firewall problems, you may want to consider a peer to peer VPN solution such as Hamachi. We have tested Hamachi with VssConnect and it works very well through almost all firewalls.