"Rick Brandt" <ri*********@hotmail.com> wrote in
news:r7*****************@newssvr12.news.prodigy.co m:
"(PeteCresswell)" <x@y.z.invalid> wrote in message
news:jt********************************@4ax.com... Per David W. Fenton:Also, keep in mind that you get the advantage of centralized
administration.
I'm guessing that the same technology allows somebody to set up a
sort of 'server' that many people can hook into - each running
their own vitrual PC.
Have I got it right? Or do the clients need a separate onsite PC
for each person connecting?
With Windows Server you can have as many remote users as your
resources will support. With normal WinXP you can have only two
connections and they have to have admin authorities. Technically
the "remote desktop" feature is intended for doing administration
on the box from another location and while it is in use the PC
cannot be used locally.
I was not talking at all about workstation-to-workstation Remote
Desktop -- I think that's a valid configuration for deploying an
Access app only in the must rare of circumstances, e.g., like what
we recently discussed here in the newsgroup where someone had two
offices and was carrying data back and forth, but was only ever in
one office at a time (with no other people using the PCs, either).
For him, workstation-to-workstation remote desktop was perfect,
since it was two PCs used by one person.
I was suggesting Windows Terminal Server, which comes as a part of
Windows Server starting with Windows 2000 Server. By default, it,
too, supports the two administrative users, but in multi-user mode.
That is, somebody can be at the server console while someone is also
running a remote session (I'm not sure if that extends to one at the
console with two remote sessions, though).
To have non-administrative users run an app on WTS, you need to buy
the CALs to enable additional logons. They run $30-40 each (no
volume discounts), depending on academic discounts and so forth.
It should be pointed out to that the remote users still have to
have licenses for all the software on the server that they use in
addition to a CAL license to use the server at all. It solves
some remote performance problems, but it is not necessarily
inexpensive and while it solves some administration issues it
introduces a few of its own (Email and printing being two notable
ones).
But the licensing is fairly loose -- old versions of MS Office apps
get you permission to use later versions (I don't have Office 2K3,
but I can run Access 2K3 on one of my client's WTS installation).
Of course, you *do* have to have *some* version of Access, or, at
least, of Office (not sure whether Office apps bring cross-licensing
for using different apps you don't have installed). In all the
circumstances where I've implemented it, we were replacing
locally-run apps, so everybody had Access locally installed.
Also, Win2K3 Server comes with pretty good printer redirection
(i.e., when you're logged on to the WTS, your local printer gets
detected and you have the ability to print from the remoted WTS
session and have it print on your local printer), while if I'm not
mistaken, Win2K Server had none unless you bought the Citrix
extensions. However, it's no panacea -- the WTS server's Windows
installation can only detect printers for which it has the drivers
already installed. That means that if the remote users have printers
that predate the release of Win2K3 Server, they'll be golden, but if
they have newer printers, it won't. Installation of the newer
printer drivers on the server takes care of it, which is fine if
you've got a bunch of remote users with the same brand of printer
(since most printer installers install classes of drivers, not just
for an individual printer), but if you've got a mix of printers,
it's more of a problem. I've only had the former experience, since
everyone connecting was under the same purchasing authority and had
compatible printers (i.e., only a couple of printers had to be
installed on the server).
The other gotcha is the weird licensing server software. You have a
choice between device licenses and user licenses (not both), which
means that licenses are allocated either to the connecting PC or
tied to the user logon. The system was designed on the assumption
that everyone would choose the former, so that when you use the
latter (which makes more sense to *me*), there are weird
inconsistencies (such as lack of reporting of license use and
availability in the licensing manager -- minor detail -- *NOT*!).
But once it's up and running, it's great.
I do replication now only with laptop users and the occasional
two-PC operation where they want to share data between a couple of
locations. I'm partnering in a project with one of my clients who
already had a replicated back end, and I'm now doing indirect
replication via Replication Manager between their main PC and mine
across a Win2K-to-Win2K VPN (using the default Windows VPN client).
It's a breeze, and works very well (with broadband cable on both
ends). The only hitches have been figuring out exactly which ports I
need to authorize the client's PC through my software firewall (that
wouldn't be an issue with a hardware firewall, because everything
would be going through the VPN's port(s)).
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
