Is my app ‘Terminal Services Compatible"?

Miscellaneous Forums/General Discussion/Is my app ‘Terminal Services Compatible"?

Hi there,

I've just been asked this question by a tech guy re my Blitzmax-based Mysql (or, depending on the version) Sqlite database application. What does he mean? Will my app be accessible via Remote Desktop? Or something else?

Being clueless on this - all clues gratefully received! :-)

After a bit more research:

"The new Terminal Services features provide a substantial upgrade in functionality, performance, and user experience. Terminal Services now provides centralized access to individual applications without the need to provide the whole remote desktop. Applications running remotely are integrated with the local user's desktop - looking, feeling, and behaving like local applications."

Which sounds to me like user settings files could throw a spanner in the works. Or maybe not? Still guessing, really.

Has anyone used a setup like this? I'd imagine these remotely accessed apps would run slower/be less responsive, despite the marketing blurb?

Well, it sounds as if your app will most likely be installed on a Windows Server 2000/2003/2008 running in Terminal Server mode, and several people will use it concurrently and remotely through either the Microsoft Remote Desktop or the Citrix ICA Client over a LAN or the Internet. The Terminal Server session might also be running within a VPN tunnel.

There are a few rules you have to follow in order to have a terminal services "compatible" application ('safe' or 'compliant' might be better words here). It's basically all about having multiple users using your program on the --same-- machine at the --same-- time, probably with (very) restricted access privileges.

This is important: All instances of the app will run on the very same Terminal Server, NOT on the workstations of the users!

It should be possible to launch multiple instances of your application simultaneously and each with an individual (session) state but allowing concurrent access to its data and files.

You program should also use the user's "Documents and Settings" path for temporary files and individual data instead of a unified location; if you have more than one user running the app at the same time, you must make sure that they do not interfere with one another. It's also very likely that the user won't have file access permissions anywhere else.

The app should not be too heavy on graphical output or run too many screen refreshes -- a terminal session can be used over a slow modem connection, and then screen refreshes are painful for the user.

Your databases: Make sure you use transactions (if possible and supported by the engine) and proper locking mechanisms on write operations. Otherwise you -will- corrupt your database.

Printing through Terminal Services can also be a royal pain in the neck. Make sure your app can use full UNC pathes for printers, files and everything.

You should also note that Citrix Terminal Services usually do not have a "C:" drive; they default to M: for their local C: drive, and the C: drive that you see on the Terminal Server usually is the hard disk of your workstation. Pure Microsoft Terminal Servers on the other hand do NOT re-map their own drive letters - the C: on a MS-TS is the server's C: drive, and your workstation's C: drive will appear as a mapped network drive somewhere.

My recommendation: Download a 120-days trial version of Windows Server 2003 from the Microsoft website and install it as a Terminal Server within a VM. Then you can see what it looks and feels like and play with it. It's an amazing and extremely useful technology, I love it. ;-)

PS: I have been using this stuff in one form or the other at work since 1999. It allowed me to run nightshifts from home.

The problem is that for obvious reasons I cannot give you access to a "real" system, and I do not have a "sandbox" machine around. Your best option really is to download one of those 120-days trial versions from Microsoft.

Your question about the speed: Citrix ICA sessions are usable at 14.4kbps and begin to feel almost like a locally running app at around 128kbps connection speed. Microsoft-TS requires more bandwidth than ICA; it is almost usable at a 56kbps modem connection and also nice at 128kbps or more.

Of course, you --always-- feel that it is not a local app, even on a 100Mpbs LAN connection there still is a difference. Which is why you won't play Quake through a Terminal Server session. ;-)

Winni, thanks so much for such a great answer :-)

Wow, sounds like royal headache to be honest! The front end of my app is one big canvas and is very graphically intensive (well, for a business app!) - to the extent that it runs a little slow in Parallels compared to native. So does the server do all the rendering and then sends the resultant image to the client computer - like an app specific VNC?

The installation would be 100Mbps LAN, so I wouldn't have to worry about dialup speeds (thankfully). But as far as I'm aware the client in question is only running 3 terminals (2 having very light use) and this really seems like overkill to me.

But yes - good call. I'm going to have to download and play with the trial version, it's the only way I can be sure. I suppose it doesn't hurt to code in support for it regardless.

David

VNC is a good deal slower than RDP and ICA, and VNC is usually only used to connect the currently running desktop, while the Terminal Server creates a desktop for each user that remote connects. I don't think that a remote session will ever get anywhere near the performance of a Parallels session, but I'd say that it will always be faster than good old VNC.

They actually send bitmaps over the air and the clients use a local "bitmap cache". So, yes, the server does all the rendering.

Since you have Windows in Parallels:

Try downloading the Microsoft RDP Client for Mac from http://www.microsoft.com/mac/downloads.mspx and connecting to your XP installation running in Parallels.

You'll have to enable Remote Desktop in XP, switch off the XP firewall (or allow the exception for RDP) and you probably also have to (re-)configure Parallels to use Bridget Networking and give the XP "machine" an own network address that is reachable from OS X.

But then you can already get your first impression what an RDP connection will look like on a local network. Just launch RDC for OS X and type in the IP address of the XP VM. It's basically the same technology as in Windows Server, the main difference is that XP is limited to one connection only and that you cannot use the "console" while a remote session is running -- meaning that you'll see the logon screen in Parallels while you are connected via RDC.

Since Windows Server 2003, remote sessions can be forced to "console mode", meaning that they are treated the same way as if you were typing on the server's own keyboard, with the same privileges. Before Win2003, this was not possible and imposed several restrictions on the remote users. However, I think there can still only be one console session running, and I do not know if the Mac RDC client supports console mode at all. On Windows, you have to launch the RDC client with an additional parameter to enable console mode.

Another important thing when you are installing software on a Terminal Software: Make sure you always do it through Control Panel/Add or Remove programs --OR-- manually switch the server to "Installation Mode" via typing in a command on the command prompt. (Can't remember what it was, but try HELP. ;-) Since Win 2003 things became quite stable and robust, but forgetting this in an older version of Windows Server your corrupt the entire server (no, I am NOT kidding -- I've killed a few NT 4 Terminal Servers in my time by not entering INSTALL MODE).

Ok, it's early in the morning again - bedtime for little Winni.

Good luck! :)

while the Terminal Server creates a desktop for each user that remote connects.

Which is pretty impressive! I imagine you'd need a gung-ho server for this all to run smoothly.

The absolutely bizarre coincidence (synchronicity?) here is that in the 7 hours since I posted this question I've been offered an IT support job where I'll be trained in Windows Server 2003. I'm sure the been-there-done-that among you are screaming "run for your life" at the sound of that; but it's such a big gap in my knowledge base that I'm going to need to fill if I'm to sound remotely confident when selling my app to larger corporations with this kind of setup. So I'm taking it as a "sign" :-)

Once again, really appreciate your help Winni.

- David

I have a HP ProLiant at work which only runs two 36 GB SCSI disks (RAID 1, big enough for the OS plus standard applications), 4 GB RAM and two 3 GHz Xeon CPUs with HyperThreading. I'd usually trust such a machine to host 30 to 50 concurrent users running Outlook, Word and Excel.

The Win2003 Terminal Server has quite an optimized memory management concept, so it's not as if each session automatically allocates hundreds of megabytes. Microsoft and Citrix did a very good job with their Terminal Services.

I've been working in Windows-based systems development and systems administration throughout the last decade, and I won't say "run for your life". Windows Server 2003 --IS-- very stable and reliable and except for one encounter with W32.Blaster it never failed on me. Windows XP is a stable client OS these days - not really user friendly, but stable. And since SP1, even Vista is almost acceptable, except for the few random blue screens that it still fires.

It won't be the system software that will drive you crazy in such a job. In my experience, it's some of your users that ultimately will. That, and the boredom of an admin position. You -will- get bored with your work, and that in combination with one or two annoying users is the most difficult part to handle on the long run.

Hearing "Winni, I don't know how to print an email" from an administrative assistant who has a higher salary than me still is my favorite one. And the one business trip she made to Russia also was, hm, "interesting": She really expected her notebook to have a "built-in Internet" and was furious on the phone and screamed and yelled at me when she turned it on and the Outlook Web Access did not magically work. Oh, she's always been good at losing her temper and screaming and shouting. Must be her Russian temperament.

The good news is that there is such a huge demand for IT staff out there that you just don't have to stay in a work place that turned sour (which is what they usually do). So in case you wonder: After sucking it all up for three and a half years, I finally resigned from that job three weeks ago and at the moment it pretty much looks as if I will be going back to Technical Documentation in an interesting software development company. I'd still rather found an own startup company, but I am not getting the financial side sorted out at the moment, so this probably won't work. Anyway, that's another story.