TS does things exactly as Nick says. Think of TS as pcAnywhere on Steroids.

At my workplace we run a FPW2.6 application with over 100 users on a farm of 20 servers. Some are just file servers and others are TServers. We also use Raid5 drives and Gigabytes of memory. Each FPW session takes approx 8 to 12 Mb per user. Some of the servers are dual processor screamers, though TS can work with more.

Users also run other applications like Word, Excel, Outlook etc from their TS sessions.

Logins are thru the "farm" which offloads you thru a "load balancing" system to any free (resource) server.

We also run VFP apps on the TS and therein lies the problem. VFP is designed to use as much memory and resources as it can get and does so. You can only limit the Foreground/background usage with the SYS() commands but there are processes ( large SQL selects, Scans etc) that gobble memory over and above this. And processor time as well.

Maybe MS included it with the latest version of Server2003 but for the older versions there is NO mapping of the COM ports natively. You need to buy 3rd party apps to do this. Citrix from a few years ago had this ability but not TS. Or use a file based VFP application to "pass" the COM port info to your TS app:)

There can also be some errant VFP processes that will flatline the server's resources.

HTH

>I am not a Terminal Server expert and don't know all the technical details - that's our IT servers department doing, but there are 3 Terminal Server boxes (so called Server Farm) and when the remote user logs into thing called Load Balancer, that decides which actual box the user will be connected to.
>
>See for example
>http://www.microsoft.com/windowsserver2003/techinfo/overview/sessiondirectory.mspx for more details on that.
>
>Since Windows 2000 Advanced Server can address more than 4 GB RAM, the required memory is only a money problem. :)
>
>I found that the response times for remote users are actually better than for local network users of the same application. I was told that Terminal Servers have better and faster network connection than the average local network user.
>
>>>Yes, there are 60 copies of VFP app running on the Terminal Server.
>>
>>Thats very impressive.. if 60 copies of VFP are running at the same time. how much memory is on the Terminal Server and does it have any effect on Response Times ?
>>
>>Regards,
>>
>>Gerard
>>
>>
>>
>>
>>>Hi Gerard,
>>>
>>>Every terminal server user has it's own copy of EXE in user's share on the Terminal Server. No EXEs are installed on the remote users PC's, since Terminal Services transmit only the user interface of the program to the client and pass back the keyboard and mouse input (as you know already).
>>>
>>>The only reason for each terminal server user to have a disk copy of application EXE in the user share on the server is the chosen method of distributing the new versions of EXE both for local and remote users. It is done through the Launcher EXE, that copies the new version from some shared folder on the network to the local hard drive of the user's desktop PC, or to the remote user's share on the terminal server which, in terminal server case, plays the role of the local hard drive.
>>>
>>>Yes, there are 60 copies of VFP app running on the Terminal Server. And it's not only my app those Terminal servers run for the remote users. But that's what the Terminal Server designed to do - run the applications for the remote users. The server load and corresponding memory/resources requirements is the responsibility of IT personnel. :)
>>>
>>>
>>>BTW, because of Terminal Server technology existense, the argument in favor of SQL Server like: "How will you run a SQL query against the big tables in VFP over the WAN???" (that you could see here often and even in some recent threads) is absolutely meaningless. Who would want to do such a thing? :)
>>>
>>>I have another FoxPro application (also used over the WAN) that uses Foxpro data well over 2 GB. The way data are split, any present or future SQL query will take the same (split second) time, no matter if it's 2GB or 200 GB.
>>>
>>>
>>>>Hi Nick, thanks for your reply.
>>>>
>>>>...each remote user has their own copy in the personal space on the Terminal server ...
>>>>
>>>>What exactly do you mean here.
>>>>Is it
>>>>(a)A copy of the APP downloaded and run on the Hard Disk of the remote PC
>>>>(B)The app run from the Terminal Server for each user
>>>> (i.e. If 60 users are logged on at the same time, there are 60 copies of VFP running on the Terminal Server. If this is the case, does it not caise a Memory/Resources priblem.
>>>>
>>>>Thanks for any assistance
>>>>
>>>>Regards,
>>>>
>>>>Gerard
>>>>
>>>>
>>>>>Hi Gerard,
>>>>>
>>>>>I have two VFP apps that are also accessed through Terminal Server from Toronto and Montreal. Each app has over a hundred everyday users, (plus about a hundred casual users). The EXEs are distributed locally (each remote user has their own copy in the personal space on the Terminal server). The apps are run through the launcher (the same one I have here posted in Downloads section), so the EXE updates are done automatically whenever the master copy in the certain network share changes.
>>>>>
>>>>>
>>>>>
>>>>>>Hi.
>>>>>>We are about to deploy our app on Terminal Server, to be used with upt to 4 remote locations and am lookinf for some advice/pointers.
>>>>>>
>>>>>>Initially, set up will be as follows:
>>>>>>Central Location: 10 users
>>>>>>Remote loc 1: 2 users
>>>>>>Remotre Location 2 5 users
>>>>>>Remote location 3 8 users
>>>>>>Using Broadband through Internet for connection
>>>>>>
>>>>>>(There is also a slight possibility of another remote site with 40 users)
>>>>>>
>>>>>>The sort of queries I have are:
>>>>>>Will I need a sparate Comms Server at the Central Location
>>>>>>(i.e. 2 servers, one for VFP data and one to handle traffic )
>>>>>>What Spec of Server/Servers will I need
>>>>>>What is response times likely to be
>>>>>>Do I need a server at each remote location or will a Router do
>>>>>>
>>>>>>I would really appreciate feedback from anyone who has already done this
>>>>>>Regards.
>>>>>>
>>>>>>Gerard