No.

They are two separate issues.

VPN: A VPN provides an Internet-connected user with a connection to
the homebase that runs Windows networking, and can thus support
communication between two synchronizers. This means you're on the
home network, though at a relatively low bandwidth with high
latency. Because of these last two, you can't run Access like you
can on a LAN, but it works extremely well for indirect replication.
Absent a VPN, indirect synchronization over the Internet requires
Internet replication, which involves running IIS on the home server
and on all the remote machines. It means keeping the FTP servers on
each of these machines functioning correctly. To me, IIS is a
massive security hole, so I don't want it running anywhere. It also
adds yet another component that has to be managed and kept running
properly so that your synchronization doesn't faile.

WTS: with a Windows Terminal Server, all those problems are absent.
The user is running the Access application in the RAM of the server
at homebase, with her own desktop (and her own copy of the front
end) and all edits are real time on the home copy of the data file.
Replication is not needed at all for this scenario, since there's
only one authoritative data file in use, the one that is used by the
people in the home office (which now includes the remote users who
are running the app on the WTS).

Now, I would recommend for security purposes that you run a WTS
behind a firewall (i.e., the WTS port is *not* exposed directly to
the Internet), and require that remote users connect to the VPN,
which puts them *inside* the firewall to connect to the WTS machine.

But many people in comp.databases.ms-access consider this too much
trouble.

I think those people are complete fools, however.

An open WTS port is an open invitation for somebody to try hacking
your network. A VPN is much safer, as it requires authorization and
certificate exchange (assuming you're using something more robust
than the Windows VPN client in its default configuration, which
isn't secure -- you have to turn on IPSEC). The VPN also has
advantages to the remote user that WTS without VPN does not, such as
access to network resources across the VPN (i.e., you can copy files
from your remote machine to the home network and vice versa; this is
not supported with WTS alone).

That's not running it across the Internet -- that's the same as
Windows Terminal Server, because the copy of Access that's editing
the data is in the RAM of the machine where you're accesing the
data.

What I mean is this:

1. server in home office.

2. laptop remote, connected to home office by Internet connection.

3. Access front end MDB on laptop with linked tables that point to a
data file on the server in the home office.

This can be done, but:

1. it is very, very, very, very, very, very, very slow in comparison
to even the slowest LAN (compare 10Mbps to a T1 at 1.5Mbps both ways
to a typical ADSL connection which is, perhaps, 1.5Mbps download but
384K upload; do the math and then multiply by 10 for the LAN to
compare it to the typical 100Mbps LAN).

2. it is very, very, very, very, very, very, very unsafe because a
dropped connection can every easily corrupt your data file. If the
Internet connection is lost or times out, it is no different than if
on a LAN somebody pulled the LAN cable while in the middle of an
edit.

All the solutions to this problem involve removing the requirement
to move the data across the Internet, either by making it local (via
replication) and pushing only changes across the Internet at
appropriate times. This has the advantage of being efficient, but
has high latency in terms of everyone seeing everyone else's
changes. With many applications, that is not really a problem,
because many times users are concerned only with their own data.

The other way to remove the requirement of moving the data across
the Internet is to run the whole application remotely, as with
PCAnywhere or WTS. PCAnywhere is not multi-user, and is not using
native Windows graphics calls, so it's not appropriate (it requires
one dedicated PC in the home office per remote user, and is much,
much slower than WTS; it also often makes a PC unstable because of
its installation requirements).

WTS, on the other hand, was designed from the ground up to support
multiple users. It also works by sending only the Windows graphics
commands across the wire, the same information that is sent from the
Windows kernel to your graphics card at a local console, so it's
very efficient, especially with broadband.

Some issues with WTS:

1. hardware: you need quite a bit of it. I tend to spec out 128MBs
of RAM on the terminal server per simultaneous user. That means if
you want to support 5 people running at a time, you need at least
640MBs of memory available for the WTS users. That means you need to
start with at least about 1GB of RAM for a terminal server that you
want to serve 5 users simultaneously. This level of RAM in servers
has become very cheap. A client of mine put in a dedicated terminal
server last winter for less than $2,000 with 2GBs of RAM, and it was
a nice Compaq rack server, so they didn't do it on the cheap,
either.

2. licensing: remote users must have compatible licenses on their
remote machine for the software they want to run on the terminal
server. That means that if they want to run Access on WTS they need
to have Access installed on their laptop. It's not quite that
strict, though -- there seem to be certainly cross-compatibilities,
especially between versions (you don't have to have the exact same
versions installed on both ends), and, perhaps, between the Office
suite as a whole (I don't know the details on this, as I've never
tried to set this up with anything other than full Office on all the
remote machines). You also have to buy client access licenses to
install on the WTS, but these cost only $30-40 apiece, so that's not
a very high cost.

3. printing: with Windows 2000 Server, there is no remote mapping of
printers without buying the Citrix extensions. What this means is
that a remote user running on WTS can't print to her local printer,
unless you buy the Citrix extensions for this. Windows 2003 Server
adds pretty good support for this, as long as the printer drivers
for your local printer are already installed in W2K3 Server. When
that's the case, your local printer is automatically detected in
your WTS session and mapped as your default printer -- you don't
have to do anything. However, if you have a printer that's newer
than the release of W2K3, the drivers need to be installed on the
W2K3 server in order for you to be able to print to your local
printer. Surprisingly, this is much less of an issue than I had
every suspected it would be, but it depends entirely on what kind of
printers your remote users have. I don't know about whether or not
you can print using compatible older drivers or not, as none of my
users has ended up with a problem so far (my latest client with this
was lucky in having the remote printers at their 5 sites all being
the same model, so they just installed the drivers for that one
model on their terminal server and everyone was OK).

4. deployment of the app: there are no differences running on
terminal server than in a regular configuration. You supply each
users with an individual copy of the front end MDB, which is stored
in the user's profile on the terminal server box. You may have to
futz around with some registry keys to turn off the macro security
notifications (I did it with one key), and you may have some
difficulties on Win2K3 Server if the user tries to execute UNC paths
(Win2K3 thinks they are Internet sites and gives you a warning until
you put the machines in their Intranet security group in Internet
Options; yes, this is a stupid situation, as Win2K3 Server ought to
be smart enough to detect machines on its own LAN segement -- it
can't even recognize a UNC path that refers to *itself*; that is, if
you're terminal server is called \\Server and your Access database
is in D:\Data\AccessDBs on that server, D:\Data\AccessDB\MyDB.mdb is
OK, but \\Server\AccessDB\MyDB.mdb provokes an Internet warning;
yes, you read it right, and yes, it's very stupid). The easiest way
to automate distribution of the front end to new users is to use
Tony Toew's Auto Front End Updater for this purpose, found at
http://www.granite.ab.ca/access/autofe.htm . It's a little tricky to
set up (though much simpler than it used to be), but once working,
it's transparent to the users.

But, again, if anyone needs to update data when they *don't* have an
Internet connection, replication is going to be needed anyway.

However, the number of clients I have who need replication these
days is much fewer than it used to be. Indeed, the cases where I
used replication so that my clients could have multiple offices have
all been replaced with WTS solutions. I now use replication only to
support wandering users with laptops.