Re: Newbie: Access as International solution?

"Rick Brandt" <rickbrandt2@xxxxxxxxxxx> wrote in
news:MN6Ne.3061$Z%6.2513@xxxxxxxxxxxxxxxxxxxxxxxxxx:

> PC Data*** wrote:
>> Rick,
>>
>> 1. How does one set up a Terminal Server application? Is there
>> special
> software for this?
>
> You would need a box set up with Windows Server Edition. . . .

All copies of Win2K and Win2K3 Server support WTS out of the box.
They come with two administrative remote logons enabled. To add more
users you have to add client access licenses, which cost somewhere
in the neighborhood of $40 each (no volume discounts).

> . . . This
> comes with "Terminal Services" which allows anyone who can connect
> to the box to run applications (or whole desktops) on the server
> provided that they have permissions. Remote Desktop is the same
> technology except that Remote Desktop with normal Windows can only
> support 2 sessions (XP Pro) that must have admin authority and a
> local session cannot be used at the same time as a remote session.
> Basically Microsoft throttles the service so it can only be used
> to remotely administer the box.

Off on a tangent:

I don't know if others have heard of this, but this is a good
opportunity to mention the new service, Copolit.com, which is a
product built around TightVNC that provides a reflector service so
that both ends of the process are only making outgoing connections.
This allows it to be easily set up without having to worry about
firewalls and port redirection. It was created by a summer intern
project fun at Joel Sposky's FogBugz software company.

The history of the development project (a very interesting read):

http://www.projectaardvark.com/

Joel's blog (lots of fascinating articles):

http://joelonsoftware.com/

If you have to do remote support, this could definitely be a useful
service for you.

But it's only tangential to the discussion of using Terminal
Services to run an Access application.

> Remote users (individually) must still hold valid licenses for any
> software that they run via Terminal Server and each must also have
> a CAL license just for the privilege of connecting at all so it is
> not a "free lunch". This is Microsoft after all.

If you're contemplating an Access application, chances are good your
users are already going to have the necessary licenses. Believe it
or not, MS is pretty free with version cross licensing. I have only
Office 2K and Access XP on my machine and I'm able to run Access 2K3
on one of my clients' terminal servers.

>> 2. Is the database application a typical Access app - are there
>> any "gotchas"?
>
> You set it up the same way you would set up any Access multi-user
> app except each user's "local copy" of the front end is in a
> separate folder on the server instead of actually being on their
> local system. The way we set it up is to create "published
> applications" that poiunt to batch files. The batch files
> configures the user's profile, copies the MDE to their personal
> folder and then launches it. When used as a published application
> the user has no way to get at other resources on the server. When
> he closes the Access app he is automatically disconnected.

I use Tony Toews AutoUpdater for this kind of thing:

http://www.granite.ab.ca/access/autofe.htm

There are a couple of things you want to be careful about. You
mustn't hardwire any drive letters and folder names into your
application. For instance, for an app running on a terminal server,
you can't assume that users will be allowed access to C:\Program
Files, so you probably won't want your front end stored there.

Secondly, keep in mind that it's a multi-user environment, so you
wouldn't want to put any thing there, anyway, because then all your
users would be sharing the same file. You have to think in terms of
the home directories for the logged on users, which you can get
through the environment variable, %HomePath% or %UserProfile%.

>> 3. What is a VPN connection? How is it set up? Special
>> software/hardware?
>
> "Virtual Private Network". I am not an expert, but basically it
> is a technology that creates a secure "tunnel" between two systems
> over the internet so that they can communicate as if on a LAN
> securely. The VPN is not a technical requirement but it would be
> dangerous to run this setup without it.

If you use a VPN across a WAN, the remote users are connected to
your LAN with exactly the same access as a user connected in the
physical office where the application is hosted. They are just much
more distant. The VPN connection can also be encrypted (it's not in
the default Microsoft VPN client configuration; it probably will be
if you use a different VPN client) in order to make the connection
very safe.

But the VPN is not required. The Terminal Server port could be
exposed directly to the Internet, and you could allow remote users
to simply connect across the Internet.

But I wouldn't recommend that -- it's an open invitation to hackers.

The VPN connection means that the VPN port has to be open, but it's
already set up for the purpose of security, and can server as a
single port for all forms of remote access to the network. Opening
up the TS port is just an open invitation for someone to try to hack
your network.

>> 4. Can all the above be set up on a desktop?
>
> Not sure what you mean. You could do this against any Windows XP
> box if it was dedicated to one or two remote users and was not
> expected to be used locally. Anything beyond that and you need a
> server.

The VPN can be set up between two desktops, though, and if you only
need to use one of them at a time, it could work.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
.