(Note: This is only applicable to TMG v5.x and later.)

Sharing TMG Between Multiple Users

A Case History

By Warren Culpepper

Lew Griffin is resident in Phoenix, and I in the Atlanta area. For the past several years, we have collaborated on building a world-wide Culpepper family tree (based mainly on Lew's work of the past 25 years) and publishing it on the Web, utilizing the Web server at my computer industry research firm in Alpharetta, GA. The Culpepper Connections! Family history Web site may be seen at <gen.culpepper.com>.

For the first several years, we used Ultimate Family Tree (UFT) for our genealogy program, and Lew did most of the data set updates. Periodically, he would send me a backup (.SQZ) file of the current project, I would apply additional updates for a week or two, post the new project on the Web (using GED2HTML), and then send an updated project .SQZ file back to Lew. This cycle was repeated at 3-4 month intervals for about four years. It worked, but it was very awkward to have to send the file back and forth for each to be able to do our own updates.

Recently, we converted to TMG 5.0 and are using Second Site for Web publishing. We are quite pleased with both software products, and with our newly acquired ability to do simultaneous updates to the TMG data set. The first Web version of the family tree using TMG and Second Site was published in September 2002, and the current version of it may be viewed at <gen.culpepper.com/index.htm>.

Through a lengthy trial and error process, we discovered several network configurations that will work technically. Each group of potential sharers of a common TMG data set will have to conclude for themselves which of these best fits their own situation.

It should also be noted that all but the first configuration described below might pose a technological challenge to most genealogists. Both Lew and I are quite computer literate and have worked with many different computer systems (from PCs to mainframes). But we believe we may have never worked our way through all the technical challenges were it not for the assistance of a very bright and knowledgeable young network administrator.

The configurations below start with the most simplistic and progress to the most complex. In every case, the configurations involve running TMG version 5.0, and using Windows XP on desktop computers. We did not try other versions of TMG or operating systems and can offer no opinions concerning these.

1. LAN Configuration with Data Set Sharing.

Perhaps many have already successfully used this simple configuration. Two computers within the same Local Area Network (LAN) can each have their own copy of TMG and then share a single copy of the TMG data set resident on one of those computers. Lew and his wife have tried this, and it works fine for two genealogists like them resident in the same household. Of course, this does not meet the needs of two or more people in different locations.

2. WAN Configuration with Data Set Sharing.

In this second configuration, the two computers are in different locations and connect via a Wide Area Network (WAN) over the Internet. This can be done if the remote users each have routers that permit an IPSEC VPN connection across the Internet. For simplicity, each user should have an identical router. The VPN connection creates a secure connection between the LANs at each remote location. Then the two remote people can operate as if they were within the same LAN and share the data set as in Configuration 1 above. However, when Lew and I tried this, the performance was so bad across the Internet as to render this solution practically useless. There appears to be so much interactivity between TMG and its data set that the two cannot be separated by a slow Internet connection, even at broadband speeds. Ideally, the TMG program and its data set should be resident on the same computer. Or if not, they should be connected within a 10Mbs or faster network. Such speeds are not available to most people across the Internet. However, if two locations were each connected to the Internet with T3 lines, as many large businesses are, then the program/data set separation should not be a limiting factor.

3. WAN Configuration using a Remote Desktop Connection and a single desktop computer at the host site.

To get around the performance problems posed by the program and data set being separated, the users can use the Remote Desktop Connection (RDC) facility of Windows XP for the remote user to actually log on as a user to the host computer where both TMG and its data set reside. In this case, you can get adequate performance using a broadband Internet connection. During the course of testing by Lew and me, we used cable, DSL and even 2-channel ISDN connections to the Internet. With such connections, no meaningful difference in program performance was perceived when compared to just running the program and data set on our own computers. However, I believe that performance would suffer across a standard analog modem connection at 56Kbs or less. And whatever the connection speed, there are several other drawbacks to Configuration 3.

a) To handle a Remote Desktop connection, the host computer must be running Windows XP Professional edition (at about $200), not the Home edition (at about $100).

b) RDC access requires the hosting genealogist to personally trust his remote user, for the remote user has access to the host's computer. But, the exposure can be minimized through careful setting of permissions on the host computer.

c) Although it is not required, the safest way to make the remote connection would be to establish an IPSEC VPN connection between the two computers (discussed in Configuration 2 above), and this may add further to the cost and complexity due to the requirement that each site must employ a router between its Internet modem and its LAN.

c) If you were to use RDC without VPN, there are significant security considerations, as the RDC port has to be opened on the host site's router, and the host wouldn't have the security that VPN is designed to provide. Thus, the host computer becomes more susceptible to an external hacker cruising around looking for open ports. Of course, if the open port were found, the hacker would still have to figure out the login ID and password. Note, if you do use an RDC-without-VPN configuration, as Lew and I did for a while, make sure that you adjust your OS settings to not redisplay the user ID of the last user logged on. For convenience, most computers are setup to do the redisplay, and when your only security exposure is to others within your household, most people would never worry about this weaker level of security. But if an Internet hacker is presented with a valid login ID, then all he has to do is figure out the password, and that means he's half way home to being able to do his mischief. So disable the automatic redisplay of the most recent login ID if you are going to run the risk of allowing someone to use RDC-without-VPN to access your computer.

d) Another drawback to Configuration 3 exists if: (i) you're not using VPN, or (ii) you have an ISP connection that is less than rock solid 100% of the time. Repeated, albeit unsuccessful attempts by a hacker to breaking in a system not protected by a router and VPN connections may result in a legitimate remote user being inadvertently locked out. Or even if you are using a router and VPN, the Internet connection may fail and somehow lockup the modem and/or the router. In either the hacker or Internet glitch situation, a reboot of the router, modem and/or computer may be required before the remote user can access the system again. (When Lew and I encountered this, it was never clear in advance as to what was going to be necessary to re-establish the connection). The result of all of this is the probability that the system will often not be available to the remote user, even if the host thinks everything is setup for his remote buddy to use.

e) The final and perhaps most significant drawback to Configuration 3 is that only one user at a time can be logged on to an XP system. So the host computer with TMG and its data set cannot be used locally while the remote user is logged on. Thus, scheduling and cooperation between the two users is required.

4. WAN Configuration using a Remote Desktop Connection and two desktop computers at the host site.

This configuration is a combination of Configurations 1 and 3, and it does support the true simultaneous update to a TMG data set by two users remote from each other. It requires that two computers be connected via a LAN at the host site, and both TMG and its data set must reside on the host computer. The remote user employs RDC (preferably via a VPN connection) to access TMG and its data set on the host. And the host user performs his updates from his second computer, on which a copy of TMG, but not the data set, must be installed. On this second computer, he can open TMG and access the TMG data set on his host computer. As a result, both the local and remote user can be updating a single TMG data set on the host at the same time, and performance will appear normal to both. While simultaneous updates are now possible, this configuration still has all the other remote user drawbacks listed in Configuration 3. Those drawbacks notwithstanding, this is probably the most practical configuration in most situations for two remote users who wish to have simultaneous update capability. It worked fine for Lew and me except for the too-frequent lockouts I experienced as the remote user. Once or twice a day I would have to ask Lew to clear up the lockout condition. As Lew is in a time zone three hours earlier than mine, I would often find myself locked out early in the morning, and I didn't think it a good idea to waken him at 4:00 AM to clear it up.

5. Server-based Configuration.

While this final configuration will not be practical for many, if you do have the environment to support it, it appears to be the best solution, hands down. This solution utilizes a Windows 2000 server within a commercial network environment. Windows XP is used on the desktops but can not be used on the server as XP does not support multiple simultaneous users. A single copy of TMG and its data set are installed on a Windows 2000 server running in Terminal Server Application Mode. This also requires Terminal License Server to be present on the network. The server network could exist at the site of one of the users. Or more likely, it will be resident in a business that is remote to each of the genealogy users. Each of the remote users employs VPN and RDC to connect to the host server. This is the configuration that Lew and I are now successfully using, and theoretically, it should support a large number of simultaneous users. The server is managed by a business that I own and run, and it has a quite competent technical support staff. So I have total control over the environment, excellent technical support, and none of the program restrictions that one might have with a third-party provider. If any of these environmental attributes were different, then the server-based configuration could be more expensive and problematic.

In case anyone is interested in the truly nitty-gritty technical detail, the server and network specifications used within our environment are:

TMG Server

This server is not dedicated to TMG, and is primarily used by several business researchers running shared statistical applications. Also, until very recently, a five-year old underpowered server [twin, 200Mhz processors] was being used, and TMG's performance was still adequate. The current server is configured as follows:

- Dell PowerEdge 1650 Server
- Single Pentium III 1.26 Mhz processor using ServerWorks HE-SL Chipset
- 1.256 GB of 133MHz ECC SDRAM Memory
- Integrated dual-channel Ultra3 SCSI controller
- 36GB Ultra 160 SCSI Hard Disk Drive
- Dual Gigabit NICs
- Windows 2000 Server running in Terminal Server Application Mode (requires Terminal License Server to be present on network)
- FrontPage 2002
- TMG 5.0
- SecondSite (for Web page generation directly from the TMG data set )

Other Network Servers

There are 8-9 other Windows 2000 servers present in the network, but the only one of substance that is used for genealogical purposes is the web server running IIS that has long hosted the Culpepper Connections web site.

Network Environment

- Windows 2000 Active Directory Network.
Consisting of 2 Windows 2000 Domain Controllers (needed for VPN, RDC, and filesharing to work)
- 10/100/1000 Switched Backbone
- APC Matrix 5000 UPS provides over 3 hours of battery run time.
- Microsoft ISA Firewall handles VPN connections
- Cisco 2600 Router
- Sprint 1.54MB T1

Return to the TMG Tips User Tutorials Page.

Return to the TMGW v5.0  Tips and Suggestions

Last revised:

Webpage design by Lee Hoffman