Gavin’s Digital Diner

I didn’t set out to spend my pre-Fourth of July weekend playing with Microsoft’s “Server 2008 Beta 3,” but that’s how it ended up anyway. I’d been travelling too much recently, so it was nice to spend some time at home, curled up with a warm keyboard and a cold LCD screen. My goal was simple — to take a quick look at something called RemoteApps. It’s a new “Terminal Server” feature in Microsoft’s next server OS, codename “Longhorn” (AKA Server 2008). I wanted to see if it could work its magic with one particular (and crucial for me) application called Gifts. If there was to be trouble, it would be with Gifts.

RemoteApps, by the way, was supposed to “way cool”— letting you “publish” (via a terminal session wrapper) a stand-alone application. Done right, it supposedly would look to the end-user as if the software program were running directly on their PC. In all actuality, it would really be running, remotely, on a terminal server, in the next room, the next building, the next county, or half-way across the world. This would solve some niggling issues I have with the current version of Terminal Server.

I know. There are similar “application publishing” features available with Citrix. But they cost more and, of course, add more complications. Having this particular feature as part of the standard TS product would be terrific. So, I set out to see what was up. I downloaded the beta and built a version on a virtual server to see what could be seen. (Got to love virtualization, it sure does make all this evaluation stuff that much easier.)

Let me add a little perspective before we start:

I already think Terminal Services (TS) is the cat’s pajamas. Without it, I’d be up a creek, without a proverbial paddle, with a half-a-dozen line o’ business (LOB) applications and no way to serve them to software-hungry folks scattered from here to Timbuktu (or at least Johannesburg). We use TS every day. I use it day and night. Without it, our field office (and travelling) staff couldn’t do their jobs.

As well, IMHO, with software applications that are not totally “webified” — mind you that’s most of them really, despite the hype — remote desktop software like TS is a godsend. If your organization is geographically distributed, if you’ve got people who like to work odd-hours, in odd places, or you’ve got folks that travel, TS simplifies access to legacy (or not-so-legacy) applications. Of course you need the bandwidth and the hardware to run it all. That’s a given.

Writ large, to my mind, here’s what’s happening:

Terminal Services, Citrix, et al, are blurring the lines between thin client and fat client applications. With that blurring comes some tremendous efficiency. You see, it’s just plain easier to “move people to data” than try to move “data to people.” Distributed, remotely updated, synchronized databases are just one tremendous pain in the tuchus. Sure, with increasing ubiquitous broadband, databases that replicate themselves, and other fancy tools, that is not quite as true as it used to be, but, they’re still a pain. I’d rather have it all centralized — it’s easier to update, maintain, secure, and support.

Now, with the ability to publish not only remote desktops, but individual applications themselves, the distinction is becoming meaningless. With somewhat decent bandwidth, full size applications are just as svelte as you need them to be. That’s what RemoteApps is all about — serving individual applications inside a TS wrapper, moving the people to the centralized data, and doing it so they don’t even notice.

While we’re on the subject, clearly there are lots of choices for remote access. I’m not religious about it, either. Trust me when I say that for more than twenty years, I’ve tweaked and twiddled with remote connections, remote terminals, remote controls, and remote viewing. [I've never had much luck with the remote viewing, but it hasn't stopped me from trying.] I’ve been from Tucson to Tucumcari, Tehachapi to Tonopah. I’ve used most every kind of remote software that’s ever been made, including things like PC-Anywhere, CarbonCopy, Xwindows, to VNC (in multiple flavors) to Terminal Services and Citrix. Nothing compares to the terminal services experience; in its ease of use, ubiquitous availability of the client software, and ease of adoption. Nothing.

Before we go any further, too, let me state I’m pretty agnostic about server OS’s. They’re, well…, ahh…, well, they’re server OS’s. They’re nothing to get in a tizzy about, really. They’re not that sexy, not really that exciting, a pretty lousy date for the weekend, if you ask me.

If they do their jobs, I’m happy. If they don’t, I’m not. Depending on what you’re doing, for whom, and at what cost, I’m as happy with one as another. I know that’s not that PC of me, but I just can’t get evangelical over an OS. Feel free to slap me.

Terminal Services, well, it’s a great thing. It lets fat clients be thin. It lets you deliver some very fat applications across a very thin wire, to some very remote places. It’s the fat cat’s pajamas.

Here is what it does: It runs on the Windows Server product line. It works well. It’s relatively easy to support. The interface is familiar to the casual user. Moreover, since anybody with XP has the client, it’s nigh-on universally available, whether you’re visiting your mother in Ashtabula, or at a game lodge in the Okavango Delta. There are even Linux clients, wholly Java clients, even (said with a slight hush in my voice) Apple clients… (Will wonders ever cease?)

My one critique is that the XP version of the client software is absolutely buried in the XP “Start” menu. Microsoft (again) seems to have branding issues — it’s called RDC, it uses RDP, you connect to a Terminal Server, running Terminal Services. The branding could be improved. While you’re at it, please, dear god, choose a better name — Terminal Services sounds like it involves a headstone and the gravedigger’s union. I absolutely hate standing up in front of a crowd and saying, “Today, we’re going to talk about terminal services…” I feel like an undertaker.

Branding aside, there are a couple of problems with TS. One is bandwidth, or more importantly, lag. If you’re way way down a very thin wire, packet lag is trouble. At more than 300ms ping times, I’ve found it torture to use. You type… you wait… your keystrokes show up a few seconds later. Argh. Bandwidth in and out of Africa is always a problem.

The second problem is user support. It’s a conceptual more than anything. Those pesky end users simply have a hard time understanding what’s “local” and what’s “remote;” where their PC stops and the (terminal) server begins. And, that line is blurring more and more, every day. I don’t blame them. It’s confusing stuff.

Finally, the third problem is printers; they’re always problems. The 2003 version is better than the 2000 version, but it still seems to involve mystical incantations rather than science. Some printers work, sometimes; some don’t. Printers on a remote network are a pain. Moreover, having to install a printer driver on the server for every variation and permutation of every printer you just might ever have attached to a remote machine is just downright aggravating, and impossible.

With those all those thoughts swirling around in my mind, the simple goal of my weekend katzenjammer pajama party was to see if RemoteApps could or would help alleviate the second problem. You see, it seemed to me that if I could publish just the application — and make it look like it was running on the remote machine — it would eliminate the support headaches. In reality the conceptual problem would actually be worse, but it would be hidden and hence no longer an issue. Hope springs eternal.

I started the process on Friday, around 8:00 … two days later, when I looked up from the keyboard, I found myself impressed with the new OS, and impressed with RemoteApps (and kind of curious about something called Terminal Server Gateway – perhaps I’ll talk about some other time).

The server, well, it’s built on the Vista kernel. I will admit that had me slightly worried. But in the end, it seemed innocuous enough. There were no big, glaring problems, or meltdowns. But, I’ll admit, I didn’t look very closely, or push that hard.

Should you care, it’s nice to note that Longhorn will let you run the OS bare-bones — called “server core” — stripping out all the unneeded Windows-like stuff, including the GUI, 32-bit color, and all that other stuff you really don’t need on machine that sits in a closet. It’s a version of windows that doesn’t use Windows! Go figure. Plus ça change, plus c’est la même chose. Instead, you can choose to run with a command line interface, a la Linux, or Netware, or DOS. Supposedly it takes one-sixth the disk space! Now, ain’t that grand. The reason, simple: Why waste resources on such crap when you don’t need it? Relax, for those that love the gooey GUI, you can manage it remotely, with full GUI support, from another machine, or choose to include the GUI if you want.

To the point: RemoteApps, well, it dresses that cat in no ordinary PJ’s — no, these are silk, tailored, and suave; and puts out a warm plate of milk to boot.

Serving an application “encapsulated” in a TS wrapper is simple as pie. Click a few buttons, and you’ve got a distributable installer or a RDP definition file. Once installed, it looks — for all intents and purposes — like a locally installed application. If you use the MSI installer, it will even put a nice icon-shortcut on the desktop. Not only that, it will associate local files, by file type, with the remote software. Yes, I said it — you can double-click a local file and it will open it with the remote application. Very nice.

Setting up a remote application, by the way, is absolutely simple:

1. First, install the app using the “install terminal server application” wizard from the control panel.
2. Then, run the wizard to prepare a “Remote Application” — selecting from any application installed on the server.
3. The wizard allows you to create either an MSI installation or a RDP file with all the appropriate settings.
4. Distribute and install the MSI, or drop a copy of the RDP file, on the remote PC.
5. You’re done. Make some tea.

In just a few minutes, with no problem, I successfully published versions of the various pieces of Office 2007, various other programs, including IE7 (I know – that’s stupid – but I was playing around). You can even choose to serve up the RemoteApps via a browser front-end (below).

Four test applications published as RemoteApps

Before you ask: no it doesn’t run them in the browser, it just offers them up as options in a browser window. If you click on one of those icons, it still launches the RDP (terminal services) client. On the plus side, though, it does all this using RDP over HTTPS (SSL). Hence, you need only open a single port in your firewall to allow the SSL traffic, and no worries about “man-in-the-middle” attacks.

The ability to “publish” an application remotely to another person’s PC, so they can use it as if they had a local copy — and I mean just about any application — is downright revolutionary.

You could, for example, have a run-of-the-mill PC, with nothing but an OS, and use a complete set of up-to-date applications, served centrally from a “Godzilla” of a server. You’d get great performance from full-featured, fat, state-o’the-bloat (err, …art) applications, that would otherwise never run acceptably.

Moreover, if the bandwidth gods were smiling (and everything works as it supposed to) you wouldn’t even know the difference. It would look to the user like the apps were running on their machine, even down to file associations. Yep – I kid you not — you can double-click a known file type and have the remote application start up, and load the file. Pretty damn sweet.

This is kind of like Google apps done better. Only unlike Google, the apps are full featured versions of Word, Excel, Visio – maybe even InfoPath. No muss, no fuss, no kitchen drudgery. No need for multiple IT monkeys to maintain a fleet of app-fat PCs.

Finally, I have to report that not everything was totally hunky-dory — there were wrinkles in the PJ’s. It failed on one application. It just happened to be the ONE, the whole damn reason for this adventure in terminal services in the first place. Nevertheless, fail it did, and I, as yet, don’t know why. I have my suspicions.

The whole goal of my little exercise was to look at how it handled one crucial LOB application — a database application for managing and tracking grants. It’s called Gifts and it’s a weird beast. It’s a SQL application, built in Access code from the 90’s. It runs off a central executable, located on a server share. Basically, the only footprint on the end-user workstation is an .INI file and some shortcuts. In the final analysis, I think that may be the problem — ’cause when I published it as a RemoteApp and tried to start it up (remotely) I basically got an error message that said “file not found.”

I tried my tricks — created short cuts and published them; created batch files that called the application and then published the batch file, cursed, rebooted and cursed again, faced (approximately) Redmond and bowed my head. I messed with the drive mappings, and server shares. Nothing worked. Finally, I copied the program files from the share to the server drive… and it worked, sort of. Gifts started up… but then it choked because it wasn’t happy about its installation.

I think the solution might be to actually install the application on the server, saying to hell with mapped drives, shares, and off-the-cuff file copies. I think TS just doesn’t like running an app that’s located somewhere else… And Gifts needs to be properly installed to run (d’oh). But that will have to wait for another day, perhaps another beta release. I’ll let you know.

Trackback URI | Comments RSS