User profile paths in RemoteApp sessions

Question

I try to setup a terminal services farm, serving some of our LOB applications. The main goal is to use them as RemoteApps through Terminal Services Gateway for the users, who are somewhere away from the headquarters. I've got no big problems setting up a farm, web-service and the gateway. My headache is now about user profiles.

Imagine you run Excel application as a RemoteApp from external network. Then you click "Save" and you get the profile's Documents path on the TS-Server by default. Users won't understand it's not local, save the file, and after some time discover it is "lost". Unfortunately, we don't use roaming profiles throughout our organization, so it's not the way to go. Besides that, user on the external network won't have access to them itself. So the only way is using local profiles on user's machines for storing the results of their work.

I am trying to get it to work - the GPO makes a couple of things - it runs simple commands:

net use x: \\tsclient\c
md x:\ts_remote

I use x:\ts_remote path, because the user named "John_Woo" in our corporate network can be named just "User" on his private local machine, not joined in the domain, so I can't use default user's C:\Documents and Settings\%username%. Then I am launching a little script:

Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal", "X:\ts_remote"
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\My Pictures", "X:\ts_remote"
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop", "X:\ts_remote"

Though it somehow works, I really don't like my setup. The first big problem is that X: disk (user's C:) is sometimes not mapped at all for some weird reasons. Or it is mapped, but in some "offline" state and activates only when you click on it. The second thing - mapped X: works sometimes extremely slow! I mean really bad performance, it can take 15-20 seconds to open Save dialogue box, and then about twice longer to really save the empty Excel spreadsheet.

The most strange is that sometimes maps, sometimes not. Sometimes it works fast, but again - I don't understand the reasons, when it gets really slow. That are not network issues for sure or server's performance. My main question is - Do anybody have some advices and practices, redirecting profile's paths to client's disks? Maybe I am going not the right way at all. Thank you.

Answer 1

I'm not surprised you're having problems mapping to shares on the client. WAN connections seem fast right up to point where you run SMB traffic over them, and then they slow to a crawl.

If you must have access to drives on your users' PCs how about using the local drive mapping facilities in TS. Bear in mind that you're exposing your server to all the viruses and malware on the remote PCs.

I don't have a really good answer to this problem except for user eductaion and that's on of the standard IT oxymorons. Could you use some other mechanism for users to get at files stored on the office servers? A web interface possibly, or rsync?

JR

Answer 2

I'm going to echo what John Rennie said already: You're never going to get what you're trying to do to be reliable. You're trying to re-purpose functionality that wasn't designed for what you're using it for. You've tried this route, found that it leads to a blind alley, and now it's time to turn around and look for a different solution.

Several times in my career I've run into wildly sub-optimal solutions that were put in place because "They just want it to work" (as you put it in your comment to John Rennie). There's trying to meet user requirements and expectations, and then there's tilting against windmills. If management asked you to reverse the flow of time, or exceed the speed of light, you'd laugh at them. Unless you're going to write code to solve your problem, trying to "change the rules" of how an existing piece of software works is a lot like trying to re-write the laws of physics. There may be some hacks that "sort of" work, but fundamentally software works like it was designed to work.

The erratic performance you're seeing is because you're trying to use a feature in a way it wasn't designed to be used in, and because transient network "weather" between the client computer and server computer is affecting transfer speeds and latency. I can't imagine that the "client drive mapping" protocol-extension to RDP is really forgiving of dodgy network connectivity, either.

To my mind, you want "Terminal Services Roaming User Profiles" (look on the "Terminal Services" tab of an Active Directory user's properties). If you need these files to be accessible to applications running locally on client comptuers, you need to expose those files to the clients, either through a VPN, or through something like WebDAV over SSL.

While I understand that your "higher-ups" would like things to "just work", there's a limit to what you can do w/o shelling out the "big bucks" for custom software.