One big difference between just a VPN and Terminal Services is that a client can run applications like an ERP or CRM remotely with Terminal Services. This is not likely with clients connecting to a remote site simply with a VPN. The nature of these types of applications that require a back-end database would be so painfully slow due to the heavy network traffic would not be feasable without Terminal Services.
There is also the benefit of having more control in enforcing policies and the users environment with Terminal Services, as it would be under the direct reign of the organizations IT staff.
With VPN's, the company somewhat takes ownership of the users PC. This can present much more administrative overhead to the IT staff, as far as supporting an empoloyees PC and trying to keep track of licensing and what not.
I understand that the speed issue can be a pain from remote locations. The VPN thru the firewall really slows things down.
Using my own company's CRM application as an example, if we introduced Terminal Services, how would people logon remotely? Would they use Windows Authentication to a statically assigned external IP to that box and run a web-ex like session?
Right on. You've got the idea. Probably would want to create an A record for the address with your registrar as well, just to make it easier for your users to remember the address. You can also implement Terminal Services over SSL, for added security.
cirulent, don't confuse Terminal Services and Remote Desktop Client with WebEx. WebEx is aimed towards presentation purposes, as for sharing one's desktop or workspace with a group of attendee's. Terminal Services is more a production environment, meant to distribute a workspace to single-user sessions.
Generally, this would be setup in an AD environment where a user would logon with their regular credentials as they would in the office. This wouldn't usually be a standalone box, where accounts reside on the local machine.
markdmac makes a good point about the web interface. However, that could also be misconstrued as a web application. In fact, the web interface is merely a "portal" for initiating the session and logging into the Terminal Server. After that, the Remote Desktop Client (RDP) is launched.
Thanks for your input. I'm beginning to get a good picture of what this would look like.
It sounds like if a person uses Terminal Services, once they login, they would have access to mapped network drives (via AD login scripts) just as if they were working on their own desktop. Plus they would have access to any application such as MS Office that's installed on the Terminal Server box.
Since we are an Action Pack subscriber, I wonder if I still need to add the license server since we don't have any actual licenses, but do for Win2K3 R2.
I try to stay away from MS licensing altogether. It's too confusing, especially these days! I let the licensing manager take care of that stuff...
However, I'm pretty sure you'll need to setup a license server if you're planning to have clients connecting to the Terminal Server. Of course, you get 2 free connections to every server for administrative purposes. But, once you enable the server to run in application mode for general users, you'll only have a few months before you realize you need to purchase TS licenses. MS gives you, I believe, 120-180 days to run in application mode with temporary licensing. But after that you'll no longer be able to connect without purchasing.
Jonathan is correct. You will definately need to set up a TS License Server or your clients will stop connecting after the temporary licenses expire.
And just to help complete the picture for you. The TS connection is just sending Keyboard, Video & Mouse (and if you select printer redirection and sound) over the wire. All of the actual processing takes place at the server side. So a user working remotely is actually running their applications back at the server and just seeing that locally.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.